GPG Keysigning Policy — Whose Key Do You Sign?

There was a GPG [1] Keysigning session at LISA’13. Thirteen people exchanged fingerprints for eighteen keys and verified each others’ identification credentials. One of the discussions that several participants had was what kind of validation should be done before signing someone’s key.

When you sign a GPG key, you are creating a digital signature packet that associates a user id (UID) packet with the fingerprint of a public key, signed with your secret key. Your signature on the key is your statement “I certify that I have made some effort to check that the owner of the key is the person described by the user ID.” What does that mean? Different GPG users have different standards for when they will sign someone else’s key(s). Some GPG users publish their key-signing policies explicitly, most do not.

RFC 4880, Section 5.2.1 describes four certification types for UID signatures: Generic (0x10), Persona (0x11), Casual (0x12) and Positive (0x13). However, there are no guidelines for what constitutes an adequate threshold for each level of certification. If the GPG user publishes their key-signing policy and when they will issue each level of certification, then the certification levels can be meaningful. Otherwise the levels don’t seem to mean much. A key signed with a Persona Certification probably should not have been signed at all.

Key signatures are the basis of the GPG Web of Trust (WoT). In an ideal universe, we could conveniently meet every person, face-to-face, whose GPG key we might ever use … before we needed to use it … and we could verify their identity and their key fingerprint and sign their key for our own keyring. That is not likely to happen in this universe. Our compromise is to look at a chain of signatures from your own key, or a key that you trust to a key that you want to use. For each link in that chain of signatures you have to ask yourself whether you trust the signer’s standard for key signing to introduce the signed key to you. Again, published policies are very helpful here.

These are, in my opinion, the minimum standards for verification before signing a UID on the GPG key of a human being [2], at any level:

  1. You’ve made an effort to verify the identity of the person claiming ownership of the key that you will sign. You do this by examining their identifying documents, in person, for consistency between the name on their ID and the name in the UID that you will sign. The identifying document(s) should be in the form of a picture ID. This step should be done face-to-face, in person so that you can verify the face of the person whose ID you are certifying, and that you can examine the identifying document(s) in hand.[3]
  2. You have verified that the key fingerprint of the GPG public key that you will sign matches the fingerprint that the key owner recited or otherwise presented to you, in person, asserting that it is the fingerprint to a keypair that they own.
  3. You have verified that the person claiming ownership of the GPG public key actually has control of the corresponding secret key. This is usually verified by having them decrypt a message encrypted to their public key, and verifying a signature made by their public key.
  4. You have verified that the person claiming ownership has control of or access to each email address in the UID that you will sign.

Some key signing policies have more stringent standards for signing keys.

I am in the process of formalizing my own written key-signing policy. I have been gathering up other key-signing policies for examples of what I want to say about my policy.

It is important to avoid conflation of owner trust with ownership certification. A key signature is a certification that you have verified the identity of the key owner in comparison to the information in the UID. A key signature makes no statement about whether you trust the signatures made by that key owner on other UIDs. Trust of a key owner’s signing policies is not generally reflected in a key signature. You can mark your trust in the signatures created by a key in the trustdb values you assign to a key in GPG.


1. Rather than use terms “PGP and GPG and OpenPGP” and “PGP or GPG or OpenPGP” or anything like that, I’m just going to refer to Gnu Privacy Guard (GPG) with the qualifier that everything said applies to most implementations of PGP and that the keys are consistent with the OpenPGP data format, unless otherwise noted.

2. Organizational keys may have to be handled differently, and your key signing policy should refer to those exceptions.  Signing-only keys may also have to be handled differently.

3. There was a point when I was considering whether it would be possible to do a verification of a picture ID through a videoconference system. In fact, unless you are dealing with someone with whom you already have a personal trust relationship, wherein you have no reason to believe that the person would try to present you with fake identifying credentials, this really can’t work.