While there are several sources of technical information on using pgp in general, and key signing in particular, this article emphasizes social aspects of key signing that are too often ignored, misleading or incorrect in the technical literature. There are also technical issues pointed out where I believe other documentation to be lacking. It is important to acknowledge and address social aspects in a system such as pgp, because the weakest link in the system is the human that is using it. The algorithms, protocols and applications used as part of a pgp system are relatively difficult to compromise or 'break', but the human user can often be easily fooled. Since the human is the weak link in this chain, attention must be paid to actions and decisions of that human; users must be aware of the pitfalls and know how to avoid them.

AUDIENCE

This document is intended to be of use to those wishing to participate in the exchange of signatures on their OpenPGP keys. It is assumed that the reader has a basic understanding of pgp, what it's used for and how to use it. Those more experienced with pgp may wish to skip the sections they are familiar with, but it is suggested that even the basic information be reviewed.

RELEVANT TERMINOLOGY

Alice, Bob et al: Following cryptographic convention, Alice and Bob represent two people who wish to communicate with each other. Trent is a trusted third party. Eve is a passive eavesdropper. Mallory is a malicious active attacker.

certificate: see signature

GnuPG: The Gnu Privacy Guard. This is an application that processes OpenPGP data. It is freely distributed under the terms of the GNU General Public License.

gpg: GnuPG

OpenPGP: As defined in RFC2440, this defines a message format concerning encrypted and/or authenticated data.

PGP (uppercase): This refers to a specific application that processes OpenPGP data. PGP is a registered trademark of whichever company currently owns the rights to it.

pgp (lowercase): Depending on context this may refer to the OpenPGP protocol or any application that uses it, such as PGP or GnuPG.

signature: A digital signature of data. A signature of a pgp key is often called a certificate or certification.

secure: This is a subjective term that is frequently misused as an absolute term (similar to terms such as 'easy' and 'fast'). Used as a noun, 'secure' means nothing meaningful unless it is qualified by an adjective. Used as an adjective, it means nothing meaningful unless it is qualified by an adverb. Something may be secure against fire, flood, eavesdropping, cryptanalysis, high explosives, alien technology, etc. It is generally believed that there is no such thing as absolute security, thus nothing may be considered absolutely secure. Only when a threat model is evaluated can one properly define what 'secure' means in a given context. If 'secure' is used without qualification, it must be interpreted by the reader based on their own needs and perceptions. If 'secure' is used in an advertisement or press release, it's meaning deserves suspicion and scrutiny.

UID: User Identification field. This is a component of a pgp key that contains information about the key's owner. Usually a UID includes both a person's (or group's) name and a valid email address where the person (or group) may be contacted. Optionally, a comment may also be included in the UID.

OBSERVATIONS ON GENERATING AND MAINTAINING KEYS

When one first generates a key, it is important that it be done on a secure machine in a secure environment. One attack against pgp that is rarely mentioned allows Mallory to steal or even replace a pgp key before it is distributed. Mallory would need to compromise Bob's computer prior to Bob's creation of a key.

Mallory could then eavesdrop on Bob as he types the pgp passphrase for the first time, and steal the passphrase along with the secret key. In this case Bob's key is compromised before it even exists.

If at any time Mallory is able to break into Bob's computer, she can steal his private key and wait for him to type in his pgp passphrase. Mallory may use a virus or trojan to accomplish this. A screwdriver or bootable CD can compromise the private key. A spy camera or key-logger can compromise the passphrase. This would allow Mallory to read any message ever encrypted to Bob and sign any message or key with Bob's signature.

Aside from keeping his personal computer secure, Bob should save a copy of his private key in a secure, off-line, off-site location. This off-line and off-site backup keeps Bob's private key secure against loss from such things as disk crash or his computer being stolen by either common or government thieves. Depending on who is out to get him, he may consider it more secure to burn his private key onto a CD and store it in a bank safe, or print it onto paper and hide it inside a painting. As always, the most appropriate meaning of 'secure' is left to the needs and perceptions of the reader.

Note that it is often unnecessary to make a backup copy of a public key for two reasons: 1) if it is publicly available and can be retrieved from a keyserver and 2) the "gpgsplit" command has a "secret-to-public" option that can recover a public key from a private key. Note that gpgsplit may not recover accurate expiration dates and preferences if they were updated after the key was created.

One should never sign a key (or use pgp at all) on an untrusted computer or in an untrusted environment. Gather the information needed to sign a key and sign it when you get home. If your home computer and environment are not trusted, you have bigger problems to worry about.

REQUISITES OF KEY SIGNING

One should generally consider signing a key only after the following three requirements have been met in a way that the signer considers acceptable: 1) The fingerprint of the key being signed has been accurately verified; 2) the owner of the key being signed has asserted (or preferably proven) that they 'own' or control the private component of that key and; 3) the owner has proven that they are who they claim to be, and their key represents them as such.

PROVING IDENTITY AND ASSIGNING A CHECK LEVEL

When signing keys, OpenPGP allows one of 4 levels of verification to be used with each signature. This allows a means of communicating the level of confidence the signer has gained in establishing the identity of the key's owner:

0 - No particular claim is made (generic certification)
1 - No verification of identity (persona certification)
2 - Casual verification of identity (casual certification)
3 - Extensive verification of identity (positive certification)

The definitions of verification levels are vague by design, rather than by accident; this is a feature, not a flaw in the OpenPGP specification. What one person considers an "exhaustive verification," another person may consider little (insufficient) verification. Someone else may wish to avoid the issue altogether and simply sign with no particular claim. The level of verification associated with a signature rests entirely with the issuer of that signature. When signing a key, use whatever level you are most comfortable with, using your own interpretation of the four levels.

Issuing a level 1 signature should usually be avoided. Some pgp applications may consider a level 1 signature just as good as a level 3 signature. There's usually no reason to issue a signature unless some verification of identity has been done. In general it's better to not issue a signature than to issue a level 1 signature.

IDEAL CIRCUMSTANCES FOR CONFIRMING IDENTITY

Identity verification is straightforward when Alice and Bob are sister and brother: Having known each other their whole lives, they can each be certain that the other is who they claim to be, and their keys represent this known identity. After exchanging and verifying key information, they may confidently sign each others' keys with a verification level of 3.

THINGS CAN GET TRICKY WHEN CONFIRMING IDENTITY

What if Alice and Bob know each other only through their work? They can produce identification in various forms (driver license, passport, work ID, credit cards, etc) attempting to prove their identities to each other. If they consider this to be an exhaustive verification of identity, then they may choose to sign each others' keys with a verification level of 3. They may have known each other long enough that checking each others' identification seems unnecessary; the choice is theirs.

One or both of them might not trust any of the identification, since they know how easy it is to steal an identity or create a false identity. In this case, one or both of them might consider that their signature only deserves a verification level 0 or 2, depending on their confidence in determining each others' identity.

It is important to note that they do not have to agree on a level of verification for each other. Each of them may independently assign a level of verification to their signature.

If Mallory claims that her name is "Tony Soprano", or if she has six different passports with six different names, one might suspect that she isn't who she claims to be. One might decide not to sign any of the keys that Mallory presents.

THINGS CAN GET TRICKIER WHEN CONFIRMING A PSEUDONONYMOUS IDENTITY

What if Bob's key, instead of identifying him by his real name, identifies him as "The Bobster"? In this case, Bob is using a pseudononymous key. It is unlikely that Bob has any valid identification that can confirm this pseudononymous identity. It may seem like Alice shouldn't sign it, but that's up to Alice. If Alice can verify Bob's pseudononymous identity to her own satisfaction, then she may choose to sign his key with an appropriate level of verification (as determined by her). It is reasonable that Bob may earn a verification level dependent on how he is able to prove his identity. As always, if Bob wants Alice to sign his key, he has to prove to her satisfaction that he is who he claims to be, regardless of whether or not his key is pseudononymous.

It is important to note that some people may have strong reservations about signing pseudononymous keys. If you are using such a key, do not be offended if someone isn't comfortable signing it. Offer to sign their key anyway, if they have earned your signature.

LAST WORD ON CONFIRMING AN IDENTITY

You are never obligated to sign anyone's key. You are never obligated to sign a key with a particular level of verification.

If you do choose to sign someone's key, they are obligated to prove their identity to your satisfaction. Only sign their key with a verification level that you are comfortable with. This applies equally to pseudononymous keys, anonymous keys and keys using real names.

HOW TO SIGN A KEY

Throughout the next several sections, references will be made to "key information." This is the information required to confirm that a key is not mistaken for a different key. At a minimum, this information must include the UID and fingerprint. For older style (v2 or v3) keys this information must also include key type (most likely RSA), creation date and key size. Nearly all pgp keys currently in use are v4 keys and it's generally considered acceptable to verify just the UID and fingerprint.

Using GnuPG, this command will display all needed information (except creation date) for Bob's key:

gpg --fingerprint bob

HOW TO SIGN A KEY UNDER IDEAL CIRCUMSTANCES

Ideally, if Alice and Bob want to exchange key signatures, they will plan an in-person meeting for this purpose. Prior to meeting, each of them will print their key information on a small piece of paper and verify that the printout is correct. When they meet, they exchange their slips of paper. If required, they may take this opportunity to present each other with formal identification. After enjoying each others' company, they each return home, verify each others' key information to be correct (between the papers they exchanged and the keys they are about to sign), and sign each others' keys. They may then exchange signed keys.

ALICE AND BOB MEET ON THE TRAIN

Alice and Bob have been meaning to get together and exchange key signatures, but their busy schedules haven't allowed this. Alice gets on the train, where she's pleasantly surprised to see Bob. They weren't planning to meet, and neither of them has their key information with them. This may seem hopeless, but after verifying each others' identification (to the extent they both consider necessary) they exchange a secret passphrase. When they get home, each of them will print their key information to a file, and symmetrically encrypt this file to the passphrase known only between them. A command like this (on *nix) will export Bob's key information and use a passphrase to symmetrically encrypt it into a file:

gpg --fingerprint bob | gpg -ac > bob.keyinfo.asc
Enter passphrase:

Bob can mail that file to Alice, and after decrypting the file (using the passphrase known only to them) Alice can confirm that she is signing the correct key. Alice uses the same method to send her key information to Bob.

In order for this protocol to be secure a passphrase must be 'strong', must never be reused, and care must be taken that the passphrase isn't overheard (or otherwise made known) by anyone other than Alice and Bob. If Eve observes the passphrase being exchanged she may fool both Alice and Bob into signing the wrong keys.

KEY SIGNING PARTIES

If you are hosting a key signing party, be sure to read Len Sassaman's "Efficient Group Key Signing Method". If you are attending a key signing party, be sure that the host has read it.

Key signing parties are described on several web sites, negating any need to discuss them here in any great detail. However, much of the currently available information on the topic is dated, insecure, breaches proper etiquette or is just plain wrong. I suggest reading up on key signing parties to get a general idea of how they work, and then read the sections of this document referring to identity confirmation, etiquette, and exchange of signed keys.

KEY SIGNING ETIQUETTE

Usually (but not always), key signatures are mutually exchanged between two people. This is known as a reciprocal key-signing. This exchange usually (but not always) means that if Alice signs Bob's key, she expects Bob to sign her key. This may not always be practical or desired.

For any number of reasons (or no reason at all) Bob may not want Alice's signature on his key. An example might be a premature expiration date on the signature that Bob doesn't want. In order to accommodate this situation, proper key signing etiquette requires that Alice send Bob's signed key only to Bob. If Alice sends Bob's signed key to a keyserver it will remain in public circulation indefinitely and Bob has no control over it. If Alice sends Bob's signed key to another pgp user, it may find it's way to a keyserver and become publicly circulated. If Bob wants Alice's signature on his key to be circulated, then Bob may upload it to a key server or distribute it as he sees fit.

For any number of reasons (or no reason at all) Bob may not want to sign Alice's key. In order to accommodate this situation, proper key signing etiquette requires that Bob does not immediately distribute Alice's signature on his key. Bob should first ask Alice if it's OK with her that he circulate her signature on his key even though he does not intend to sign her key. If Alice does not want her signature used without receiving a signature in return, Bob should destroy his copy of Alice's signature and not distribute it.

You are under no obligation to sign anyone's key or sign it with a particular level of verification. For any number of reasons (or no reason at all) you may not want to sign someone else's key. Just because someone has signed your key does not obligate you to sign their key. If they have signed your key and uploaded it to a keyserver, they have violated this etiquette. Their breach of etiquette does not place you under any obligation to sign their key.

DELIVERY OF A SIGNED KEY

As described in the section on etiquette, a signed key should be emailed to the key's owner. For enhanced security the signed key should be encrypted, using the recipients public key. Alice encrypts Bob's signed key to Bob (using Bob's public key) and emails it to the address in the UID of Bob's key. If Bob has more than one UID on his key, with more than one address per key, Alice should sign each UID independently and send each signed UID to that address.

This provides one final test for Bob to prove his ownership of the key and accuracy of the UID: If Bob cannot receive or decrypt the signed key, Bob cannot (and should not) make use of that signature. This protocol is advantageous to both Alice and Bob. Alice is protected from having her signature circulated on a key with an incorrect email address or a key that is not controlled by a user of that address. Bob can review that the signature is acceptable to him before circulating it.

DELIVERY OF A SIGNED KEY BETWEEN UNTRUSTING PARTIES

Sometimes Alice and Bob may want to sign each others' keys, but they distrust each other. This is a reasonable situation since signing a key is a certification of identity, not character. Neither of them wants to offer a signed key until after the other has done so first. There are several impractical protocols for solving this. The most practical solution requires the help of Trent. Both Alice and Bob send each others' signed keys to Trent. Trent will pass along the signed keys only after both of them are received. This prevents Alice from withholding her signature from Bob after Bob delivers his signature to Alice. Biglumber.com provides exactly this service.

If the above protocol is used, it may not be practical to encrypt the signed key to its owner. It is therefore suggested that an encrypted and signed email exchange be made prior to exchanging signatures, to ensure that the key and the UID(s) are correct.

SUGGESTED FURTHER READING:

Bruce Schneier "Applied Cryptography"
Bruce Schneier "Secrets and Lies"

Len Sassaman "Efficient Group Key Signing Method"

Alice and Bob /wiki/Alice_and_Bob

Special proofreading and editorial thanks to:

Ed Moyle This email address is being protected from spambots. You need JavaScript enabled to view it.,
Duane Dunston This email address is being protected from spambots. You need JavaScript enabled to view it.,
Seth Hardy This email address is being protected from spambots. You need JavaScript enabled to view it.

###