PGP Key Management Guide for NetBSD developers
The topic of this guide is PGP key management. It assumes that you understand the concept of asymmetric cryptography (using a private and a public key), that you know how to create and use PGP keys, and that you know how to integrate PGP support into your favourite e-mail client. It assumes that you understand the concept of signing, and encrypting, a digital message.
More information about using PGP keys can be found at:
The NetBSD project needs to be able to establish the authenticity of requests and other communications originating from project members around the world. The simplest way to do this is to establish a PGP web-of-trust amongst its members.
Typical examples activities requiring this web of trust are:
-
the ability to sign messages to admins, e.g. for mails pertaining to the change of account details
-
the ability to sign someone else's key (to build a project wide web-of-trust, see below), and to be able to sign an applicants key
-
the ability to receive encrypted e-mails, e.g. in communications about security issues not to be disclosed to the outside
The most popular program for creating, managing, and using PGP keys is probably gpg (GNU Privacy Guard), readily available as security/gnupg from pkgsrc. Examples given in this document use gnupg (rather than the alternative, pgp).
Everyone can create an arbitrary number of keys: any key with any identity; it may not be her/his real identity. He or she may upload these keys to any key server. This implies that a person could pretend to be the key owner (who is given as the user-id) although she/he isn't.
There are two fundamentally different concepts to address the problem of how one can establish that a certain PGP key belongs to a specific person:
-
Certification Authority (CA), usually under control of a government, verifies the identity of a person and testifies that a certain key belongs to a person (or organization). This service usually costs money.
-
Web-of-trust: whenever two PGP key holders meet, they verify their identity and sign each other's keys (see below about the significance of signing someone's key). Although not controlled by a government, if a key is signed by many persons you know you can be pretty sure about it's authenticity. Crucial to the web-of-trust approach is that many key holders participate.
In a web-of-trust approach, if A has signed the key of B and B has signed the Key of C, then A can be confident about the authenticity of C. For this to work, A has to trust B not to make irresponsible signatures. The path from A to C is referred to as "chain-of-trust".
Often one encounters statements like: "I do not approve of Foo's actions, therefore I will not sign his key." or "If Foo signs his threat mail with a key that carries my signature that means that I will be held legally liable." These and similar statements are false.
What it means when you sign someone's PGP key with your signature is: "I have verified that PGP key x belongs to person y." Not more, not less.
There's no reason not to sign someone's key, provided you have carefully verified his identity.
First of all, to ensure maximum security over time, it is advisable to choose long key lengths. The key size limitation of a maximum of 1024 bits in the current DSA standard may limit the security of DSA. For maximum security it is therefore advisable to use 2048-bit RSA keys for both, encrypting and signing. Unfortunately, gnupg does not make it simple to create this type of key (gnupg defaults to creating 1024-bit DSA/ElGamal keys).
In brief, you must first generate a "sign-only" RSA key by selecting that option from the --gen-key menu; then you must use --edit-key on that key, and use the "addkey" command to add an RSA encryption subkey (gnupg dialogue trimmed for brevity):
% gpg --gen-key
Please select what kind of key you want:
(1) DSA and ElGamal (default)
(2) DSA (sign only)
(4) ElGamal (sign and encrypt)
(5) RSA (sign only)
Your selection? 5
What keysize do you want? (1024) 2048
Requested keysize is 2048 bits
Please specify how long the key should be valid.
0 = key does not expire
<n> = key expires in n days
<n>w = key expires in n weeks
<n>m = key expires in n months
<n>y = key expires in n years
Key is valid for? (0) 0
Key does not expire at all
Is this correct (y/n)? y
You need a User-ID to identify your key; the software constructs the user id
from Real Name, Comment and Email Address in this form:
"Heinrich Heine (Der Dichter) <heinrichh@duesseldorf.de>"
Real name: Joe Doe
Email address: joe@doe.org
Comment: (NetBSD)
You selected this USER-ID: "Joe Doe (NetBSD) joe@doe.org"
Enter passphrase:
Repeat passphrase:
public and secret key created and signed.
key marked as ultimately trusted.
pub 2048R/8385E7E3 2004-02-09 Joe Doe (NetBSD) <joe@doe.org>
Key fingerprint = 9DDA CB87 9FF2 9950 1F5A 7F79 F38C E6DE 8385 E7E3
Note that this key cannot be used for encryption. You may want to use
the command "--edit-key" to generate a secondary key for this purpose.
% gpg --edit-key 8385E7E3
Secret key is available.
gpg: checking the trustdb
gpg: checking at depth 0 signed=0 ot(-/q/n/m/f/u)=0/0/0/0/0/1
pub 2048R/8385E7E3 created: 2004-02-09 expires: never trust: u/u
(1). Joe Doe (NetBSD) <joe@doe.org>
Command> addkey
Key is protected.
You need a passphrase to unlock the secret key for
user: "Joe Doe (NetBSD) joe@doe.org"
2048-bit RSA key, ID 8385E7E3, created 2004-02-09
Enter passphrase:
Please select what kind of key you want:
(2) DSA (sign only)
(3) ElGamal (encrypt only)
(4) ElGamal (sign and encrypt)
(5) RSA (sign only)
(6) RSA (encrypt only)
Your selection? 6
What keysize do you want? (1024) 2048
Requested keysize is 2048 bits
Please specify how long the key should be valid.
0 = key does not expire
<n> = key expires in n days
<n>w = key expires in n weeks
<n>m = key expires in n months
<n>y = key expires in n years
Key is valid for? (0) 0
Key does not expire at all
Is this correct (y/n)? y
Really create? y
pub 2048R/8385E7E3 created: 2004-02-09 expires: never trust: u/u
sub 2048R/7BD27991 created: 2004-02-09 expires: never
(1). "Joe Doe (NetBSD) joe@doe.org"
Command> save
%
|
... and you're done!
Another question is whether a key should initially have an expiration date, or not. As the expiration date can set or changed later on (unlike PGP 2.x keys), this question is mostly a matter of personal choice. A good reason to put an expiration date on a key is that people sometimes forget their passphrase or lose the secret key. With an expiration date, there is a drop-dead date after which the key is not going to be used.
After key creation, uids for all e-mail addressed you use should be added to your key. Don't forget to add a @NetBSD.org uid! Consider making your @NetBSD.org uid the primary uid.
As soon as you have created a PGP key pair, you may want to create a blank revocation certificate, so that you will be able to revoke your key in the event that it is compromised, or that you lose the private key (disk crash) or forget the passphrase. Be sure to store the revocation certificate in a safe place, preferably separate from the private key. Printing it out and keeping it in a safe is a good idea.
Always keep your private PGP keys on a machine to which only you have administrative access, or better yet, store your private key only on a removable USB stick (the tiniest ones sold are sufficient). Remove the USB stick whenever you are not using the key.
Protect your private PGP keys with strong passphrases.
Regularly backup your keys.
In a public/private key model, it is essential that the private key is guarded securely, while the public key is distributed as widely as possible. Anyone wanting to send you an encrypted message, or wanting to verify your signature needs your public key.
Therefore you should:
-
submit your public key to public key servers
-
commit your key to localsrc/security/publickeys/developers
The canonical key servers these days are www.pgp.net, pgp.mit.edu, and www.keyserver.net. The default keyserver can be specified in ~/.gnupg/gpg.conf with:
localsrc/security/publickeys/developers/README describes how to commit your public PGP key to NetBSD's local source repository. Having the public PGP keys of all developers in this directory makes it very easy to import all keys (with all signatures) with just one command.
Important: Do not sign a key without checking the components of the key and without checking the authenticity. Make sure the key belongs to the person who pretends to be the key owner. Keep in mind that not you, but others will rely on your signature!
Here is the recommended step-by-step procedure:
-
Prepare a "business card" type of document with the following information on your PGP key:
Key length
Key type
Key Id
Creation date
Expiration date, if any
all uids
Public key fingerprint
The output of "gpg --fingerprint" for your key provides exactly what is needed. (You may want to redirect the output of "gpg --fingerprint" into a file, duplicate the entries multiple times, and print it with "a2ps -2 --borders no -B ..." cut out the individual stripes and staple them.)
-
Carry this PGP "business card" and a solid photo ID (passport) with you when you're going to meet another developer (or any PGP key holder).
-
When you meet another developer in person, give him one of your PGP "business cards" and hand him over your passport for inspection. Likewise, obtain his PGP "business card" and his passport. Verify his identity by checking his passport and compare the name on his PGP "business card" with the name mentioned in his passport.
Be extremely pedantic with checking the person's identity, doing this correctly is what signing PGP keys is all about.
It may happen that the person's name on a PGP key uid does not exactly correspond to the name in his passport. Common examples are the use of "Bill" instead of "William" or "Dick" instead of "Richard" as first names. If you're in doubt whether you should confirm the identity of a person with your signature, don't do it. Instead, ask the other party to add a new uid with his name, exactly as in the photo ID, to his key, and sign that uid.
If everything matches, make a note on his PGP "business card" that the identity check was successful (with date). This does seem an odd thing to do when you meet a single developer, but is really the only way to reliably keep track of things at key signing parties and therefore is considered good practice.
-
When back at your computer, import the other party's public key (either from a public key server, or from localsrc). With gnupg, this is simply done with:
% gpg --import moe_pgp_key.ascImporting the same key multiple times does not cause problems.
Importing from a public key server is done with:
% gpg --recv-key <keyid> -
Verify that at least the following key components of the freshly imported PGP key correspond to the information on his PGP "business card":
Key type
Key length
Key ID
Key fingerprint
It is possible to generate keys for any given Key ID, and it is (due to a design flaw) even possible to create PGP keys for every fingerprint! These keys will, however, have odd key lengths.
It is currently thought impossible to generate a key for a given arbitrary tuple of (key length, key ID, key fingerprint).
If all components described above on the PGP key correspond to their counterparts on the PGP "business card" you can be sure that the public PGP key really belongs to the person that gave you the PGP "business card".
-
The remaining task prior to signing is to determine whether the other party has control over the e-mails given in all uids. To check this, generate a random number and send this number, encrypted with his key, to the other party. The task of the other party is to encrypt the random number and send it back, this time encrypted with your public key (the requirement for the encrypted return channel is to spoil any crypto-analysis attacks).
If you're checking multiple uids for one PGP key, keep track of which random number you send to which e-mail address.
Here is an example of step 6 using gnupg:
% cat >> moe@doe.org Hi Moe, please return this message to me. Please sign and encrypt it. Thanks, Joe ^D % dd if=/dev/urandom count=1 | md5 >> moe@doe.org % gpg --armor --encrypt moe@doe.org > moe@doe.org.asc -
Once you've received his reply, decrypt it and check his signature. If that is successful, that concludes the necessary tests and you can signs his public key.
Using GPG, signing a key is done like this:
% gpg --edit-key <Key ID> sign -
The last step of the procedure is to export the freshly signed PGP key and to send it to the owner.
Note: You should not directly send someone else's PGP key to a public key server, unless you received it from that key server in the first place. Although you signed it, and although it is called a "public" key, it is up to the key holder to decide how he wants to distribute his key. Instead, send the signed key to the key holder and let him deal with distributing the key.
% gpg --armor --export <Key ID>or, if you use mutt, you can take advantage of mutt's "mail-key" function:
% mutt <ESC>k To: moe@NetBSD.org Subject: Your signed PGP key Please enter the key ID: 4461CF46 <Select key> ...Finally, you may want to update the public keys on your key ring with new signatures. This can be done using the command
% gpg --refresh-keys [--keyserver ...]which retrieves and merges in any extra signatures that have been published on the keyserver since you received the key.
The Executive Committee for Membership requires that membership applicants send e-mails pertaining to their account creation signed with a PGP key which bears the signature of a current NetBSD developer. This requirement entails that the applicant must have met a current NetBSD developer prior to his account creation. At that time, his @NetBSD.org uid can not yet be signed. It is, of course, worthwhile that his @NetBSD.org uid be signed as soon as his account has been created, without requiring a new meeting. This can easily be achieved:
The key signing procedure for the applicant is performed as described above. Of course, initially only his non-NetBSD uids are signed. After his @NetBSD.org account has been created, steps 6 to 8 of the procedure are carried out for his @NetBSD.org uid. There is no need for an additional meeting with the applicant, as the correspondence of key and person have been checked previously.
Copyright © 1994-2004 The NetBSD Foundation, Inc. ALL RIGHTS RESERVED.