PGP Corp. on Key Management and the Cloud
PGP Corporation’s Perspectives Blog offers some insight on how new cloud-based products can be secure and offer identity management (in a curiously unsigned post). The first generation of products we have seen centers on API keys, except for a few products which require you to submit your username and password for remote use. Both of these solutions are insecure for the same reasons.
Lately, a few cloud products at the bleeding edge of development have offered a new solution. GitHub, BitBucket, and Heroku have offered authentication solutions based on SSH keys. While these are development tools, their inherent focus on distributed data management suggests where next generation cloud services will solve authentication problems.
Publishing PGP Keys in DNS
Dan Mahoney has written a new overview of publishing PGP keys via DNS:
Publishing PGP keys is a pain. There are many disjoint keyservers, three or four networks of which, which do (or don’t) share information with each other. Some are corporate, some are private. And it’s a crapshoot as to whose key is going to be on which, or worse, which will have the latest copy of a person’s key.
For a long time, GPG has had a way to publish keys in DNS, but it hasn’t been well documented. This document hopes to change that.
I do not work with DNS much any more, so I have not tried it.
Personal and Profesional Identities on One Key
OpenPGP provides the ability to associate a key with multiple email addresses. This is handy if you are both john.doe@example.com and jd@example.com at work and adding both identities to your OpenPGP key is best because you cannot control what address outsiders use for you. But you might also have a personal email account at Gmail or Hotmail. Should you add this identity to the same key as your work addresses?
If the key is only used to provide digital signatures, the only question is whether you want the email address to actually be associated with you. If your personal email address is john.doe@gmail.com or something similarly innocuous, you will be fine.
But encryption keys are another matter. If a recipient has multiple encryption subkeys on their OpenPGP key, they cannot specify a prefered key for any purpose. The sender is free to choose. So one subkey cannot be designated as professional versus another. As a result, an employer may well suggest that an encryption subkey stays with the business, since a subkey will always decrypt corresponding ciphertext, even if revoked.
There are a few considerations that suggest it may not be worth while, however. Encryption tools are not electronic methods for solving social problems. If an employee wants to steal data from the business, forcing them to use separate keys will not prevent them doing so. Especially since they may steal deciphered plain text or even the encryption keys. And employers may need to securely contact employees in a personal capacity, for instance, during a continuity of operations event, and establishing a consistent set of trusted keys for personnel can smooth communications.
