The comp.security.pgp FAQ

OK, you just got a copy of John Smith's public encryption key. How do you know that the key really belongs to John Smith and not to some impostor? The answer to this is key signatures. They are similar to message signatures in that they can't be forged. Let's say that you don't know that you have John Smith's real key. But let's say that you DO have a trusted key from Joe Blow. Let's say that you trust Joe Blow and that he has added his signature to John Smith's key. By inference, you can now trust that you have a valid copy of John Smith's key. That is what key signing is all about. This chain of trust can be carried to several levels, such as A trusts B who trusts C who trusts D, therefore A can trust D. You have control in the PGP configuration file over exactly how many levels this chain of trust is allowed to proceed.

The options (which can be set in PGP's configuration file, CONFIG.TXT) to control this are

Cert_Dept = n

This indicates the maximum depth of your "web of trust". A key which is n keys "away" from your own key will not be used to introduce other keys.

Completes_Needed = n

This indicates the number of completely trusted keys required to make a key valid. A key is completely trusted if it is valid, and you choose option "4. Yes, always" when PGP asked you if you trust this person to introduce others.

Marginals_Needed = n

This indicates the number of marginally trusted keys required to make a key valid. A key is marginally trusted if you answered "3. Sometimes" to the question above. In all other cases, the key is not trusted at all.

You can display the trust parameters for a key with pgp -kc. See also question 4.7. Be careful about keys that are several levels removed from your immediate trust.

The PGP trust model is discussed in more detail by Alfarez Abdul-Rahman.

Execute the following command from the command prompt:
PGP -ks [-u yourid] <keyid>

This adds your signature (signed with the private key for yourid, if you specify it) to the key identified with keyid. If keyid is a user ID, you will sign that particular user ID; otherwise, you will sign the default user ID on that key (the first one you see when you list the key with pgp -kv <keyid>).

Next, you should extract a copy of this updated key along with its signatures using the "-kxa" option. An armored text file will be created. Give this file to the owner of the key so that he may propagate the new signature to whomever he chooses.

Be very careful with your secret keyring. Never be tempted to put a copy in somebody else's machine so you can sign their public key - they could have modified PGP to copy your secret key and grab your pass phrase.

Yes, you should sign each personal ID on your key. This will help to prevent anyone from placing a phony address in the ID field of the key and possibly having your mail diverted to them. Of course they can't read the encrypted mail, but you won't see it at all. And even worse, adding a fake user ID reading "Please use key 0x416A1A35 from now on" can mean someone else will use the imposter's key with your name on it, rather than your own.

It is very easy to add user IDs to someone else's key. All it takes is a binary editor or some knowledge of the PGP public key format. But since you are the only person who can sign your own user IDs, the fake ones will not be signed, and so anyone who gets the key can immediately spot the fake ones. For example, my entry in the public key ring now appears as follows if you use the "-kvv" command:

Type Bits/KeyID    Date       User ID
pub  1024/416A1A35 1994/10/01 Arnoud Engelfriet <galactus@stack.nl>
sig       416A1A35             Arnoud Engelfriet <galactus@stack.nl>
                              *** <galactus@stack.urc.tue.nl> now INVALID!
sig       416A1A35             Arnoud Engelfriet <galactus@stack.nl>
                              Galactus <galactus@stack.urc.tue.nl>
sig       3602A619             Stephen Hopkins <shopkins@coventry.ac.uk>
sig       DD63EF3D             Frank Castle <Frank_Castle@panther.pphost.nl>
sig       416A1A35             Arnoud Engelfriet <galactus@stack.nl>
                              Arnoud Engelfriet <galactus@stack.urc.tue.nl>
sig       390E3FB1             Martijn Heemels <M.A.L.Heemels@stud.tue.nl>
sig       DA87C0C7             Edgar W. Swank   <EdgarSwank@Juno.com>
sig       416A1A35             Arnoud Engelfriet <galactus@stack.nl>

For a more detailed discussion of why you should sign your own key, see "Why you should sign your own key" by Walther Soldierer.

Note that PGP 2.6.3[i] automatically signs each user ID you add to your own key.

Signing someone's key is your indication to the world that you believe that key to rightfully belong to that person, and that person is who he purports to be. Other people may rely on your signature to decide whether or not a key is valid, so you should not sign capriciously.

Some countries require respected professionals such as doctors or engineers to endorse passport photographs as proof of identity for a passport application - you should consider signing someone's key in the same light. Alternatively, when you come to sign someone's key, ask yourself if you would be prepared to swear in a court of law as to that person's identity.

Remember that signing a person's key says nothing about whether you actually like or trust that person or approve of his/her actions. It's just like someone pointing to someone else at a party and saying, "Yeah, that's Joe Blow over there." Joe Blow may be an ax murderer; you don't become tainted with his crime just because you can pick him out of a crowd.

It all depends on how well you know them. Relatives, friends and colleagues are easy. People you meet at conventions or key-signing sessions require some proof like a driver's license or credit card.

It is very easy for someone to generate a key with a false ID and send e-mail with fraudulent headers, or for a node which routes the e-mail to you to substitute a different key. Finger servers are harder to tamper with, but not impossible. The problem is that while public key exchange does not require a secure channel (eavesdropping is not a problem) it does require a tamper-proof channel (key-substitution is a problem).

If it is a key from someone you know well and whose voice you recognize then it is sufficient to give them a phone call and have them read their key's fingerprint (obtained with pgp -kvc <userid>). To be sure, also ask them for the key size and its key ID. There are ways to create a forged key with an identical fingerprint (see question 4.10 for details). You can of course also check these details in another way, for example if he has printed it on his business card.

If you don't know the person very well then the only recourse is to exchange keys face-to-face and ask for some proof of identity. Don't be tempted to put your public key disk in their machine so they can add their key - they could maliciously replace your key at the same time. If the user ID includes an e-mail address, verify that address by exchanging an agreed encrypted message before signing. Don't sign any user IDs on that key except those you have verified.

A key signing party is a get-together with various other users of PGP for the purpose of meeting and signing keys. This helps to extend the "web of trust" to a great degree.

Though the idea is simple, actually doing it is a bit complex, because you don't want to compromise other people's private keys or spread viruses (which is a risk whenever floppies are swapped willy-nilly). Usually, these parties involve meeting everyone at the party, verifying their identity and getting key fingerprints from them, and signing their key at home.

Derek Atkins <warlord@mit.edu> has recommended this method:

There are many ways to hold a key-signing session. Many viable suggestions have been given. And, just to add more signal to this newsgroup, I will suggest another one which seems to work very well and also solves the N-squared problem of distributing and signing keys. Here is the process:

1. You announce the keysigning session, and ask everyone who plans to come to send you (or some single person who will be there) their public key. The RSVP also allows for a count of the number of people for step 3.
2. You compile the public keys into a single keyring, run pgp -kvc on that keyring, and save the output to a file.
3. Print out N copies of the pgp -kvc file onto hardcopy, and bring this and the keyring on media to the meeting.
4. At the meeting, distribute the printouts, and provide a site to retreive the keyring (an ftp site works, or you can make floppy copies, or whatever -- it doesn't matter).
5. When you are all in the room, each person stands up, and people vouch for this person (e.g., "Yes, this really is Derek Atkins -- I went to school with him for 6 years, and lived with him for 2").
6. Each person securely obtains their own fingerprint, and after being vouched for, they then read out their fingerprint out loud so everyone can verify it on the printout they have.
7. After everyone finishes this protocol, they can go home, obtain the keyring, run pgp -kvc on it themselves, and re-verify the bits, and sign the keys at their own leisure.
8. To save load on the keyservers, you can optionally send all signatures to the original person, who can coalate them again into a single keyring and propagate that single keyring to the keyservers and to each individual.