As I understand it, keypairs used with gpg generally have more than one associated key: one for signing and one for encryption. How are these multiple keys managed when using gpg (to push to a keyserver, retrieve someone else's key, encrypt, or sign)? Will it automatically use the correct key for the correct action, or is that something the user needs to specify? How is the purpose of each key within a keypair identified?
| |||
|
feedback
|
|
What is often called a "GPG key" is more like a certificate. Just like in X.509, the certificate contains a lot more information than just the key(s): a 'primary' keypair and multiple 'subkey' keypairs, along with their usage flags and expiry dates, as well as multiple 'user IDs' and 'photo IDs' along with their signatures. When you upload your "keypair" to a keyserver, you are submitting everything that's public – key, subkeys, user IDs, signatures – as one single certificate. The 'primary' key identifies the entire certificate; its public key hash is the "fingerprint" you see, and the key ID is based on it. Normally, the primary key has "Sign" and "Certify" usage flags, for signing data and other keys respectively. By default, there is at least one "Encrypt" subkey created, for encrypting data. You can have multiple such subkeys – for example, with different expiry dates. I couldn't find any good source, but it seems that the newest valid (after starting date and not expired/revoked) subkey will be chosen for encryption. When decrypting data, all subkeys will be tried. (You might have noticed that Optionally you can add subkeys marked allowed to "Authenticate", which can then be used in protocols such as SSH (via gpg-agent, by extracting the raw RSA keypair) or SSL (implemented by GnuTLS as an alternative to X.509). Which subkeys are used depends on the specific implementation. You can see the full structure of a PGP certificate by using: | ||||
|
feedback
|
