Version 1.0, 11.07.2010
This page has been created as successor for the former fortytwo.ch/gpg/subkeys. Its author did not want to maintain it any longer. This page is not a pure update but my own description of the subject.
My web site contains more information pages about IT security in general and GnuPG but currently this is the only one in English. the German security main page
This page refers to gpg2 2.0.15.
Paragraphs with useless expert information are marked like this.
If you have a look at a keyring you will mostly see something like this:
start cmd:> gpg --list-keys B6A4593E Keyring: /home/hl/.gnupg/pubring.gpg ------------------------------------ pub 1024R/0xB6A4593E 2010-06-07 uid Test Schlüssel <test@key.invalid> sub 1024R/0xDA487B48 2010-06-07
The pub line shows the main key and the sub line shows a subkey. There is always only one main key and at least one UID. There need not be any subkey but many are possible (both expired and valid ones):
start cmd:> gpg --list-keys 71FDC5CB pub 1024D/71FDC5CB 2010-02-25 [expires: 2011-02-25] uid Test Key (Demo) <test@key.inv> sub 1024D/DE57F59A 2010-02-25 [expires: 2010-12-22] sub 1024R/BB8A54D2 2010-02-25 [expires: 2011-01-21] sub 512g/801FDB58 2010-02-25 [expires: 2010-12-22] sub 1024R/7D2C11A4 2010-02-25 [expires: 2011-01-21] sub 1024D/1C0A9017 2010-02-25 [expires: 2012-02-25] sub 1024R/027DBA86 2010-02-25 [expires: 2013-02-24]
The output shows length, type (D:DSA, R:RSA, g:ElGamal), (short) ID, and creation and expiration date of the main key and all subkeys.
gpg keys have four capabilities which can be combined (all or some) in one key and spread over several ones:
C: certification (signing other keys and subkeys)
S: signing (data)
E: encryption / decryption
A: authentication (not widely used)
Unfortunately --list-keys does not show the capabilities (unless used with --with-colons) so you need --edit-key instead:
start cmd:> gpg --edit-key 71FDC5CB
[...]
pub 1024D/71FDC5CB created: 2010-02-25 expires: 2011-02-25 usage: C
trust: ultimate validity: ultimate
sub 1024D/DE57F59A created: 2010-02-25 expires: 2010-12-22 usage: S
sub 1024R/BB8A54D2 created: 2010-02-25 expires: 2011-01-21 usage: S
sub 512g/801FDB58 created: 2010-02-25 expires: 2010-12-22 usage: E
sub 1024R/7D2C11A4 created: 2010-02-25 expires: 2011-01-21 usage: E
sub 1024D/1C0A9017 created: 2010-02-25 expires: 2012-02-25 usage: A
sub 1024R/027DBA86 created: 2010-02-25 expires: 2013-02-24 usage: A
[ uneing.] (1). Test Key (Demo) <test@key.inv>
Two subkeys each are capable of signing, encryption/decryption and authentication. The main key is the only one with certification ability. In this example every key has just one capability.
Every key has a main key. It may (and usually has) but need not have subkeys. Subkeys can differ from the main key in several ways:
A subkey can be of a different mathematical type (RSA, DSA, ElGamal).
Main key and sub key can have different lengths.
A subkey can have other capabilities than the main key. Exception: A subkey cannot be used for the certification of other keys. If both main key and subkey have the needed capability then gpg chooses the subkey.
Main key and subkey can have different expiration dates (though it does not make sense to have a subkey expire after the main key).
Both the main key and the subkeys have a secret and a public part each. Except for the management of subkeys (adding, revoking, chaning the expiration date) the user does not work with subkeys explicitely. gpg uses the suitable one automatically. A key is always referred to by the ID (or fingerprint) of the public main key.
You can use a subkey ID, too, but up to now you cannot force gpg to use a certain subkey. gpg checks all main keys for a suitable subkey in that case but after a match it uses the normal subkey selection procedure and ignores the given subkey ID.