PGP Key Signing Policies

My Key

Any signatures made will be done with the following key.

pub   1024D/F3E97E1D 2005-02-16
      Key fingerprint = DD31 0922 A2C5 065C 4663  C5D7 E746 7957 F3E9 7E1D
uid                  David Alber
sub   2048g/A84C8D5C 2010-02-17 [expires: 2011-02-17]

This document has been strongly based on the key signing policy of Wren Hunt, which is, in turn, strongly based on the policies of Marcus Frings.

Location

I live and work in Redmond, WA. If you would like to meet to exchange key signatures, I am willing to consider meeting anywhere in the area.

Requirements to Receive My Signature

This section has been divided into four phases:

  1. What a signee needs to do prior to meeting with me.
  2. What happens when I meet with a signee.
  3. What a signee needs to do following the meeting.
  4. Final wrap-up.

Before Meeting

The key of the signee must be available on a public keyserver. Many public keyservers are available, and most of the keyservers are synchronized with one another. One possible choice is http://pgp.mit.edu/.

The Meeting

  • The identity of the signee must be proven to me in person. The signee can do this by presenting themselves and at least one government issued photo identity card (such as a driver’s license or passport). Two forms of identity are preferred. The name on the identity card must match the name in the key (i.e., no pseudonyms).
  • When the signee meets me in person, they should bring a strip of paper containing a printout (or neatly written) copy of their key’s fingerprint. In GnuPG, the fingerprint for the key with ID 0x12345678 is returned by the command
    gpg --fingerprint 0x12345678

After the Meeting

I will first verify that the fingerprint given to me by the signee matches the key that I have received from a public keyserver. If the fingerprints match then I will attempt to verify that all of the user IDs (UIDs) in the signee’s key are valid.

I will do this by sending an email encrypted with the signee’s public key to the email addresses associated with UIDs in the signee’s key. Each email will contain a (pseudo-)random string. Once the signee decrypts and sends the string back to me from each of the addresses, I will sign their UIDs.

If any of the UIDs fail the test, then the signing will be on hold until the problem is resolved.

I am currently leaning toward requiring all UIDs to be valid, so if the signee is unable to pass the test for a UID, then the problem will need to be resolved or that UID will need to be revoked before I will be willing to sign any of the UIDs.

Wrap-up

If all of the conditions above are met then I will be satisfied that the signee owns the key, UIDs in the key, and is properly identifying themselves in the key. With these conditions met, I will sign all of the UIDs in the signee’s key.

I expect that all key signings will be bidirectional. That is, I expect to have my key signed by the signee, assuming that I am able to satisfy the signee’s conditions. I will not go through this process if the other party has no intention of signing my key.