A: 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. If you trust Joe to identify John, 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 over exactly how many levels this chain of trust is allowed to proceed.
The options in PGP's configuration 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 How do I get PGP to display the trust parameters on a key?. 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.
A: 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.
A: Yes, you should sign each personal ID on your key, which is why in PGP 5.x+ and GNU Privacy Guard newly generated keys are signed by default. 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 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], PGP 5.x and GNU Privacy Guard automatically sign each user ID you add to your own key.
A: 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 Mallet over there." Mallet may be an ax murderer; you don't become tainted with his crime just because you can pick him out of a crowd.
A: 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 passport. Do make sure to observe the standard keysigning security steps described in How do I know someone hasn't sent me a bogus key to sign?.
A: 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 or keyservers are bit harder to tamper with, but not impossible.
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 Can a public key be forged? 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: 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, making it easier for you to find one or more trusted paths to someone whose public key you didn't have.
Kevin Herron has an example of a keysigning party announcement page.
A: 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 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:
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.
You compile the public keys into a single keyring, run pgp -kvc on that keyring, and save the output to a file.
Print out N copies of the pgp -kvc file onto hardcopy, and bring this and the keyring on media to the meeting.
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).
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").
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.
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.
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.