Using multiple subkeys in GPG

Motivation

+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. +

Basics

+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. +

Effects

+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. +

Problems

+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.: +

+"gpg __import secret key" does not merge the keys properly. +If a secret key is already present, additional secret subkeys are not +imported. Also, a dummy primary key is not replaced by the real subkey on +import. Workaround is to shuffle around the keyrings, or do +"__export"s at all stages and use "__delete-secret-key" +often. (People with masochistic inclination may probably also use +combinations of gpgsplit, cat and "gpg __export" +and "__import. I've not tried this.) +
+"gpg __export-secret-key keyid!" and gpg +__export-secret-subkeys keyid!" should really only export the +named subkey (or the primary stripped of all subkeys). Much keyring shuffling +could be avoided. (2003-02-12:David Shaw added this to the development +branch of the gpg code. Great!) +

Acknowledgments