using various subkeys [HOWTO]

[Adrian 'Dagurashibanipal' von Bidder]

--=-ltNXZ9Xi2GyappWj40yW
Content-Type: text/plain
Content-Transfer-Encoding: quoted-printable

Yo!

As promised, here is a short writeup about using multiple subkeys, why
and how. As soon as I can get some spare time this will find its way to
my gpg page, too (right now it's only a personal 'here's-my-key' blurb.
Nothing interesting). Most of the following has been covered in the
discussion in this thread, some entries in the 'Problems' section have
not been addressed before, though (in this thread, that is. Don't know
about the mailing list in general, although I haven't seen the issues
over the last few weeks).

-------------
GPG Multiple Subkeys micro-HOWTO


Motivation:

For a time, I've had two different gpg keys - one at home on my=20
presumably secure machine, one at the office, whith NFS mounted home
directory and quite a few people having accounts everywhere. This works,
but the problem is that when signing keys I always have 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 whole key if the key at the office is compromised.

NOTE: Most of the following can apply to both signing and encrypting
subkeys. Encryption subkeys are not particularly useful, though, please
see the 'Problems' section further down.


Basics:

Generate a normal key, or use an existing key. Usually this will be a
DSA/ElGamal key (this is what I used), 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.

Now you should also back up your keyrings.

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').=20

'gpg --export-secret-subkeys <keyid> > crippled.seckey' will then export
the remaining subkeys, without the keymaterial of the main 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 crippled.seckey pubkey'
(the same files you've generated above) and you now can use gpg with the
subkey(s). To verify that you really don't have any secret keys you
don't want, use 'gpg --export-secret-keys | gpg --list-packets'; your
primary secret key should be marked with 'gnu-dummy S2K'.

Of course, you'll have to publish your new public key, so people can
verify your signatures and send you encrypted mail.


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 probably the most important effect of the whole thing.

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

If you're signing documents, gpg will always try to use a subkey if one
is available. Verifying such subkeys will display a message like 'using
secondary key BDDF997A instead of primary key 92082481'. If you want to
use a specific subkey (or the primary key), you have to specify it with
the <keyid>! syntax.


Problems:

The above approach has several problems that may lead to you not doing
things like this.

First, it only makes sense with signing subkeys. You can have multiple
encryption subkeys, but you can't force people sending you encrypted
mail to use a specific subkey. (Of course, if you're using encryption
for yourself, you can chose the encryption key to use with the <keyid>!
syntax, as with signing).

Existing PGP versions apparently can't cope with such keys. I didn't
verify this, but I think the problem is that it just doesn't expect
signatures by any other than the primary key.

Most keyservers can not handle keys with multiple subkeys. Some of them
even make these keys unusable. This should get better now, as JHarris
has written a patch for the pks keyserver, and keyservers with other
software that handles this are deployed more widely.

Finally, keyhandling is not comfortable with such keys, the user
interface of gpg has some weaknesses. I don't know what the state is for
gpg 1.2, the following is valid with gpg 1.0.7.

  o  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,
though.)
  o  gpg --list-secret-keys does not show whether the listed primary
keys are 'real' primary keys or just dummies. IMHO this should be made
clear (or the non-present secret keys should not be listed at all).
Reading --list-packets output is not everybody's idea of how to use gpg.
  o  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.


Acknowledgments

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 pk to accept keys
with multiple subkeys, I hope this patch spreads real fast as soon as it
is officially out.

--------------


Hope this helps somebody. Feel free to do whatever you like with this
material. I appreciate it if yo mention me as the author, though.

Thanks & hava a nice day.
cheers
-- vbi

--=20
secure email with gpg                      http://fortytwo.ch/gpg

WARNING: keyserver.kjsl.com *only* carries a valid copy of my key

--=-ltNXZ9Xi2GyappWj40yW
Content-Type: application/pgp-signature; name=signature.asc
Content-Description: This is a digitally signed message part

-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.0.7 (GNU/Linux)

iHQEABECADQFAj1rgYktGmh0dHA6Ly9mb3J0eXR3by5jaC9ncGcvcG9saWN5L2Vt
YWlsLjIwMDIwODIyAAoJECqqZti935l6F9gAoKPlUzUKqx+cOeLXfWxnMnR2lX4G
AKCJcgf/CEkhwDkRpf3aS8BhFQ1CSQ==
=3Ne3
-----END PGP SIGNATURE-----
Signature policy: http://fortytwo.ch/gpg/policy/email.20020822

--=-ltNXZ9Xi2GyappWj40yW--