Signing someone's key is saying to the world I have verified the identify of this person to the extent which I put in the signing. I believe this key belongs to the name in it, and the email listed also belongs to that person. That's a pretty strong statement! As such there are certain precautions you should take.
So lets talk about each one of these verifications
In order to verify the key you'll want them to bring you a hard copy of their fingerprint. This is to check that the copy of the key you have obtained either from a keyserver or email is actually the key this person uses and you haven't somehow gotten a forged key. Therefore, this should be generated by them on the machine that holds their secret key or better yet, from their private key. If you or they generate this by grabbing their key from a server and comparing it to what you're about to sign, then you're not verifying anything! Think about it: if you're trying to verify the integrity of something, you can't use that something to do the verification.
In order to verify their identity, you'll need them to provide at least one form of photo ID. Even if you work with the person or know the person, it's important to do this step if you have never checked their legal identity. This is to be sure that this person has the legal right to use the name they are using. It is up to you how much ID you want to see and to what level you will set your verification of the key during signing. In order to set full verification (3), I require two forms of ID, at least one of which is photo ID, and at least one of which is government-issued.
This is one many people forget, but it's important. One of PGP's most common uses is to verify email, so verifying an email address is critical.
If you sign a key for Bill Doe and verify the identity, but don't verify the email which is, say, bill@whitehouse.gov,
you've now vouched for email signed by that key from that email.
There are many ways to do it. The one this site will concentrate on the simpler of the two, but in this section I'll explain both.
When signing the key (which is covered below) rather than the default of signing all UIDs on the key, you sign each UID separately.
You then encrypt-email the signed UID to the email address in that UID. In order for the person to get that signature and make it available
(by, for example, uploading it to keyservers), they have to have both the private key and the email address.
This ensures that the person who you are verifying has access to the private key and also owns that email address.
The other way is more complicated and I've only seen it practiced a few times. It goes like this.
Person 1 thinks of a number and word, which we'll call word1 and num1.
Person 2 does the same, we'll call them word2 and num2.
Person 1 and Person 2 tell each other their numbers but do not tell each other their words.
Person 1 sends an encrypted email to the email in the UID of Person 2's key.
This email contains num2 and word1.
The fact that this email has num2 lets Person 2 know that this email came from the person he spoke to earlier that day, namely Person 1 -
the only person he told the number to. We'll see why word1 was included in a moment.
Person 2 now sends an encrypted email back to Person 1 including word1, num2, and word2.
The only way word1 could be in this email is if the person who owns the key Person 2 presented also has access to the email -
they had to get the email and decrypt it. This combined with num2 which ensures that the email came from the person that Person 1 spoke to (namely Person 2) earlier that day comfirms to Person 1 that person he spoke to earlier owns that private key and that email address.
Person 1 now sends an encrypted email back with word2 in it.
Since Person 1 could only have this word by owning both the key and the email, this completes the process as now
Person 2 has the same verification of Person 1 that Person 2 has of Person 1.
This must be done for each UID (different word/num pairs). As such this doesn't scale well to a large keysigning party where you have to have a different pair for every UID each person has. As you can see it's also quite complicated, but you get the same verification from the first method. As such this site coveres only the first method.
OK, enough with the politics, how do we sign?
If they've provided you with a file with their key in it, import it.
$ gpg --import /tmp/fileIf you want to retrieve it from a keyserver, you can search for it by email.
$ gpg --search-keys them@something.comOr request it by keyid.
$ gpg --recv-keys FOODDEAD If searching a keyserver you may be given a choice of keys. Select the key you believe is theirs.
Have them come to your office/room/whatever with their fingerprint on a piece of paper (they should generate this by doing gpg -K --fingerprint them@something.com on the machine with their secret key!) and photo ID. Then type:
$ gpg --fingerprint them@something.com
And have them read off their fingerprint. If what you see and what you hear match, then you know you have the correct key.
Now make sure they are who they say they are (either with ID, or by knowing who they are).
Once you are positive the key they use is the key you are about to sign (they have the same fingerprint), and they are who they say they are...
areFirst we will cover the easy case where they only have one UID on their key.
$ gpg --sign-key --ask-cert-level them@something.compub 1024D/F00DDEAD created: 2005-09-05 expires: 2006-09-05 usage: CS trust: unknown validity: unknownsub 2048g/BEEFDEAD created: 2005-09-05 expires: 2006-09-05 usage: E [ unknown] (1). Them Something <them@something.com>pub 1024D/F00DDEAD created: 2005-09-05 expires: 2006-09-05 usage: CS trust: unknown validity: unknown Primary key fingerprint: FEED F00D DEAD BEEF DEAD BEEF F00D F000 000D DEAD Them Something <them@something.com>This key is due to expire on 2006-09-05.Do you want your signature to expire at the same time? (Y/n)To this you should say yes. Note that if the key does nto have an expiration date, you will not get this prompt.
How carefully have you verified the key you are about to sign actually belongsto the person named above? If you don't know what to answer, enter "0". (0) I will not answer. (default) (1) I have not checked at all. (2) I have done casual checking. (3) I have done very careful checking.Your selection? (enter `?' for more information):If you have performed the verification described above and are confident in asserting the validity of their identity, then you can choose 3.
If you are not sure of one of these or haven't verified very thoroughly, you should choose 2 or 1 as appropriate.
After you choose your level, it will ask for your passphrase so it can unlock your private key to use it to sign their public key, and then you're done with this step.
OK, what about the case where they have multiple UIDs. The process is rather tedious, so I recommend using PIUS,
a piece of software I wrote to automate this. However, I'll cover the manual process here.
For each UID, you'll want to repeat these steps. The first half is very similar to the above.
$ gpg --sign-key --ask-cert-level them@something.compub 1024D/F00DDEAD created: 2005-09-05 expires: 2006-09-05 usage: CS trust: unknown validity: unknownsub 2048g/BEEFDEAD created: 2005-09-05 expires: 2006-09-05 usage: E [ unknown] (1). Them Something <them@something.com>[ unknown] (2) Them Something <them@other.com>[ unknown] (3) Them Something <them@someplace.net>Really sign all user IDs? (y/N)To this, you'll want to say no. You'll then be dropped to a prompt.
Hint: Select the user IDs to signCommand>Type 1 to select the first UID.
pub 1024D/F00DDEAD created: 2005-09-05 expires: 2006-09-05 usage: CS trust: unknown validity: unknownsub 2048g/BEEFDEAD created: 2005-09-05 expires: 2006-09-05 usage: E [ unknown] (1)* Them Something <them@something.com>[ unknown] (2) Them Something <them@other.com>[ unknown] (3) Them Something <them@someplace.net>Command>Note that next to (1) is now an asterisk denoting this UID has been selected. You can now type sign to proceed with signing.
pub 1024D/F00DDEAD created: 2005-09-05 expires: 2006-09-05 usage: CS trust: unknown validity: unknown Primary key fingerprint: FEED F00D DEAD BEEF DEAD BEEF F00D F000 000D DEAD Them Something <them@something.com>This key is due to expire on 2006-09-05.Do you want your signature to expire at the same time? (Y/n)As with above, you will only get this prompt if their key has an expiration date. If you get this prompt, say yes.
How carefully have you verified the key you are about to sign actually belongsto the person named above? If you don't know what to answer, enter "0". (0) I will not answer. (default) (1) I have not checked at all. (2) I have done casual checking. (3) I have done very careful checking.Your selection? (enter `?' for more information): Again, if you have done all the proper verification then say yes. You will be prompted for your passphrase and dropped back to a Command> prompt.
This is where things change a lot. You need to first get out of the gpg shell by typing save. Then export the key with the signed UID.
$ gpg -a --export them@something.com > /tmp/them_at_something.com.ascNow you can either use PGP/Mime to send an encrypted email to them@something.com with the contents of that file in it or you can use gpg -a -e -r them@something.com -o /tmp/them_at_something.com_ENCRYPTED.asc /tmp/them_at_something.com.asc to make an encrypted file you can attach to an ordinary email.
Note well that traditionally-signed email (non-PGP/Mime) does not encrypt attachments. So if you don't use PGP/Mime, be sure to encrypt the file first!
Next up, you need to delete the key from your keyring and re-import a clean un-signed copy. If you don't do this than 2 UIDs will be signed on the version you send to the second ID and if they only have access to the second email, they've gotten verification on the first one without actually having access to it.
$ gpg --delete-key F00DDEADgpg (GnuPG) 1.4.9; Copyright (C) 2008 Free Software Foundation, Inc.This is free software: you are free to change and redistribute it.There is NO WARRANTY, to the extent permitted by law.pub 1024D/F00DDEAD 2005-09-05 Them Something <them@something.com>Delete this key from the keyring? (y/N)Say yes to this. Now, re-import the key using whatever method you used originally such as --import, --search-keys, or --recv-key.
Then repeat this process for each UID. Note well, it is important to re-verify the fingerprint each time if your method of re-import is from a keyserver. If it's from a file on your local machine than verifying the fingerprint once for the key is sufficient.
As you can see, this process is quite tedious, time-consuming, and error prone. To help with this I've published an open-source program called PIUS to make this process much simpler. It will prompt you to verify the fingerprint and then handle the import-sign-export details for each UID and either email the results to the respective emails or save them to files for you.
If you followed the single-UID method, you now need to send their signed key to them. If you followed the multiple-UID method, sending off the key was part of the process and you can skip this section.
The first step is to export the key.
$ gpg -a --export FOODDEAD > /tmp/them_at_something.com.ascNext, encrypt that file to them.
$ gpg -a -e -r them@something.com -o /tmp/them_at_something.com_ENCRYPTED.asc /tmp/them_at_something.com.ascAttach the encrypted file to an email and send it off to them.
If you use PGP/Mime to send encrypted mail you can attach the unencrypted file to an email and PGP/Mime encrypt the email. However, traditional signing does not encrypt attachments), so if you don't use PGP/Mime be sure to encrypt the file as shown above.
Once people have signed your key and send signed versions to you, you'll want to make this signatures available. The easiest way to do this is to import the signatures and then send your key to a keyserver. You can import the signature with --import.
$ gpg --import /tmp/file_with_signed_key.ascDon't worry about overwriting other signatures, the new signatures will be merged into your copy of your key, you will not lose anything. If the file you got was encrypted to you, before you import it, you'll have to decrypt it.
$ gpg -d /tmp/file_with_signed_key_ENCRYPTED.ascOnce you've imported the key, you can send it to your default keyserver.
$ gpg --send-key <your_keyid>There are three main rings of keyservers out there. Each group syncs within it's own pool well, and to the other pools with varying levels of success, so I recommend uploading to one of each. Something like this will work.
servers="x-hkp://pool.sks-keyservers.net pgp.mit.edu wwwkeys.ch.pgp.net"for server in $servers; do gpg --keyserver $server --send-key <your_keyid>doneThat's it! You're done!
If you are running a keysigning party, I recommend you use pius-keyring-mgr to build the keyring and pius-party-worksheet to generate the worksheet for the atendees. You can find both of them in PIUS version 2.0.9 or later.