Recipe 7.21 Obtaining Keys from a Keyserver

7.21.1 Problem

You want to obtain a public key from a keyserver.

7.21.2 Solution

If you have the key ID, you can import it immediately:

$ gpg --keyserver keyserver --recv-keys key_ID

Otherwise, to search for a key by the owner's name or email address, and match keys before importing them, use:

$ gpg --keyserver keyserver --search-keys string_to_match

To specify a default keyserver, so you need not use the --keyserver option above:

 ~/.gnupg/options:
keyserver keyserver_DNS_name_or_IP_address 

To have GnuPG automatically contact a keyserver and import keys whenever needed:

 ~/.gnupg/options:
keyserver keyserver_DNS_name_or_IP_address 
keyserver-options auto-key-retrieve

With this configuration, for example, if you were to verify the signature on some downloaded software signed with a key you didn't have (gpg —verify foo.tar.gz.sig), GnuPG would automatically download and import that key from your keyserver, if available.

Additionally, most keyservers have a web-based interface for adding and locating keys.

Remember to check the key fingerprint with the owner before trusting it. [Recipe 7.9]

7.21.3 Discussion

Importing a key does not verify its validity—it does not verify that the claimed binding between a user identity (name, email address, etc.) and the public key is legitimate. For example, if you use gpg —verify to check the signature of a key imported from a keyserver, GnuPG may still produce the following warning, even if the signature itself is good:

gpg: WARNING: This key is not certified with a trusted signature!
gpg:          There is no indication that the signature belongs to the owner.

A keyserver does absolutely nothing to assure the ownership of keys. Anyone can add a key to a keyserver, at any time, with any name whatsoever. A keyserver is only a convenient way to share keys and their associated certificates; all responsibility for checking keys against identities rests with you, the GnuPG user, employing the normal GnuPG web-of-trust techniques. To trust a given key K, either you must trust K directly, or you must trust another key which has signed K, and thus whose owner (recursively) trusts K.

The ultimate way to verify a key is to check its fingerprint with the key owner directly. [Recipe 7.9] If you need to verify a key and do not have a chain of previously verified and trusted keys leading to it, then anything you do to verify it involving only computers has some degree of uncertainty; it's just a question of how paranoid you are and how sure you want to be.

This situation comes up often when verifying signatures on downloaded software. [Recipe 7.15] You should always verify such signatures, since servers do get hacked and Trojan horses do get planted in commonly-used software packages. A server that contains some software (foo.tar.gz) and a signature (commonly foo.tar.gz.asc or foo.tar.gz.sig) should also have somewhere on it the public key used to generate the signature. If you have not previously obtained and verified this key, download it now and add it to your keyring. [Recipe 7.10] If the key is signed by other keys you already trust, you're set. If not, don't trust it simply because it came from the same server as the software! If the server were compromised and software modified, a savvy attacker would also have replaced the public key and generated new, valid signatures using that key. In this case, it is wise to check the key against as many other sources as possible. For instance:

• Check the key fingerprint against copies of the key stored elsewhere. [Recipe 7.9]

• Look who signed the key in question:

  $ gpg --list-sigs keyname

  Obtain those public keys, and verify these signatures. Try to pick well-known people or organizations.

• For both these operations, obtain the keys not only from keyservers, but also from web sites or other repositories belonging to the key owners. Use secure web sites if available (HTTPS/SSL), and verify the certificates and DNS names involved.

Try several of the above avenues together. None of them provides absolute assurance. But the more smartly selected checks you make, the more independent servers and systems an attacker would have to subvert in order to trick you—and thus the less likely it is that such an attack has actually occurred.

This process will also merge new signatures into an existing key on your key ring, if any are available from the keyserver.

7.21.4 See Also

For more information on the web of trust, visit http://webber.dewinter.com/gnupg_howto/english/GPGMiniHowto-1.html.