Key Signatures
========
6. Key Signatures
========
6.1. What is key signing?
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. Be careful about keys that are several levels removed from
your immediate trust.
========
6.2. How do I sign a key?
Execute the following command from the command prompt:
PGP -ks [-u yourid]
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 ").
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.
It is not considered proper to send his updated key to a key server
yourself unless he has given you explicit permission to do so. After
all, he may not wish to have his key appear on a public server. By
the same token, you should expect that any key that you give out will
probably find its way onto the public key servers, even if you really
didn't want it there, since anyone having your public key can upload
it.
========
6.3. Should I sign my own key?
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. Anyone adding or
changing a user id on your key will be unable to sign the entry,
making it stand out like a sore thumb since all of the other entries
are signed. Do this even if you are the only person signing your key.
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/0353E385 1994/06/17 Jeff Licquia
sig 0353E385 Jeff Licquia
========
6.4. Should I sign X's 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.
========
6.5. How do I verify someone's identity?
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.
========
6.6. How do I know someone hasn't sent me a bogus key to sign?
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 ).
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.
========
6.7. What's a key signing party?
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.
========
6.8. How do I organize a key signing party?
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:
1. You announce the keysinging 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.
This seems to work well -- it worked well at the IETF meeting last
month in Toronto, and I plan to try it at future dates.