This page is horribly outdated. Because it still got quite a number of hits and was mostly still relevant, I have asked around for somebody to continue maintaining this page. I thought I've found somebody, but haven't heard from him in some time, so this is -- again -- a plea for somebody to take over maintaining this page. So: take this page, if you want this information to be available in proper form, and drop me a note so I can replace this page with a link or redirect to the new location.
For a time, I've had two different gpg keys - one at home on my presumably secure machine, one at the office, with NFS mounted home directory and quite a few people having accounts everywhere. This worked, but the problem is that when exchanging key signatures I always had to beg people to sign both my keys.
With gpg and the possibility of having multiple subkeys, I can now have only one key, but still retain the security feature that I don't have to revoke my primary key (and lose all signatures on it) if the key at the office is compromised.
NOTE: Most of the following can apply to both signing and encrypting subkeys. Encryption subkeys can not be used to solve the multiple accounts problem, though, please see the Problems section further down. Also, note that I don't use multiple encryption subkeys, so I don't know if there are additional problems with them.
The following is based on gnupg 1.2.1. It should all work with newer versions, too. Older versions do not support everything and have some additional problems. As I really do recommend you use a recent gpg version, I have omitted anything related to older gpg versions.
Generate a normal key pair, or use an existing key. Usually this will be a DSA/ElGamal key (this is what I use), but using RSA or other keys is equally possible. Be sure to do this on a 'really secure' machine.
Then "gpg __edit keyid" the key and add a further subkey using "addkey". "save" will store the new subkey on the keyring. You'll want to save the whole key (secret and public) with "gpg __export keyid > pubkey" and "gpg __export-secret-key keyid > seckey". Best copy those files onto an offline storage, too. (A basic working knowledge of how to use a command line and how to deal with files is assumed. Also, you should know a bit how key handling in gpg works. If you can't see what the above commands do, you better do some reading before continuing here).
Now you should also back up your keyrings, as the following has to work on a keyring to work around some missing or broken gpg features.
As you probably will only take one of the subkeys to your not-so-secure location, "gpg __edit keyid and delete the subkeys you don't want to expose (mark them with "key n" and then delete them with "delkey").
"gpg __export-secret-subkeys keyid > crippled.seckey" will then export the remaining subkeys, without the keymaterial of the primary key.
Now, you can restore the keyrings (secret and public, since deleting the subkeys has also deleted the public subkeys!), and your secure machine is ready to use. Perhaps you don't want to use your 'insecure' subkey on your secure machine - again, "gpg __edit keyid", "key n" and "delkey" takes care of this; again, it is necessary to re-import the public key.
On your 'insecure' machine, you do "gpg __import pubkey crippled.seckey" (the same files you've generated above), now you're ready to use gpg on the 'insecure' machine. To verify that you really don't have any secret keys you don't want, have a look at the output of "gpg __list-secret-keys": all primary secret key where the key material is not present are marked with '#'.
$ gpg __list-secret-key testuser sec# 1024D/971B7A70 2003-01-03 testuser <testuser@mydomain.foo> ssb 1024g/ACDF80C4 2003-01-03 ssb 1024R/BE9CA308 2003-01-07
Of course, you'll have to publish your new public key, so people can verify your signatures and send you encrypted mail. Read the Problems section for a few comments about this.
Keys are always signed with your primary key, so you (or any attacker) won't be able to sign other keys with the key on the 'insecure' machine. This is why we started doing all this acrobatics after all.
You will always be able to revoke a subkey (just "gpg __edit keyid", "key n" and "revkey") when you have the primary secret key available, even if you lose your secret subkey. Meaning: you may use a secret subkey at an office location, and it is not strictly necessary to back it up on a secure location (It's still a good idea, though). The reason for this is that a revocation is really a signature on the subkey - and this signature is done with the primary key. Of course, this means that you can't revoke a subkey when you don't have the primary secret key.
If you're signing documents, gpg will always try to use a subkey if one is available, and announce this with a message like "1024-bit DSA key, ID E5A7F7D6, created 2002-08-22 (main key ID 92082481)" . Verifying such signatures used to cause a similar message, but at least with gpg 1.2.3 no indication is given that the signature was made with a subkey. If you want to use a specific subkey (or the primary key), you have to specify it with the "keyid!" syntax. I don't remember what happens if more than one signing subkey is available; I'm sure you can find details on this somewhere in the gnupg mailing list archives.
The above approach has several problems that may lead to you not doing things like this. These are not just possible problems. These are real, and will affect you! You have been warned.
First, distributing secret subkeys this way (one subkey for each account/machine you use) only makes sense with signing subkeys. You can have multiple encryption subkeys, but you can't force people sending you encrypted mail using a specific subkey. Naturally, if you're using encryption for yourself, you can chose the encryption key to use with the "keyid!" syntax. The presence of multiple encryption subkeys is, however, useful if you revoke an older one to replace it with a new one.
Old PGP versions apparently can't cope with such keys. I didn't verify this myself, but people on the gnupg-users mailing list said that current PGP versions (up to 7.x) can not verify signatures from a subkey. With PGP 8 the situation is a bit more complicated: PGP 8 can verify subkey signatures, but has still problems with multiple subkeys: a key with a signing subkey that is newer than the encryption subkey cannot be used for encryption in PGP 8. A key where the encryption subkey is newer than the signing subkey can be used for encryption. So, when you create your key, generate it as 'signing only' key first, then generate all the signing subkeys you need, and in the end generate the encryption subkey. (Thanks to David Shaw for this info).
Most keyservers can not handle keys with multiple subkeys. Some of them even make these keys unusable. This should get better soon, as JHarris has written a patch for the pks keyserver, and keyservers with other software that handles this are deployed more widely. The keyservers that can handle multiple subkeys are summarized as subkeys.pgp.net. GnuPG 1.2 added code to recover somewhat when a broken key is retrieved - one of the subkeys is useable (the others can't be used, as the signature binding the subkey to the primary is lost).
Besides corrupting keys with multiple subkeys, all of these old keyservers will also only search keys based on the primary key id - so, automatic key retrieval on signature verification will not work, too. Yet another reason to oonly use the subkeys.pgp.net keyservers.
Finally, keyhandling is not comfortable with such keys - the user interface of gpg could be better. The following is valid for gpg 1.2.1, some things may be fixed in newer versions.:
Some additional reading that might be interesting:
Of course, thanks to the gnupg crew for the cool software, and especially to Werner Koch and David Shaw for replying to my initial questions about this. And to Jason Harris for fixing pks to accept keys with multiple subkeys, I hope this patch spreads really fast as soon as it is officially out.