PGP/GPG Key Signing Policy

This page describes my PGP/GPG public key signing policy. I am more than happy to sign other people’s public keys, assuming the steps outlined in this document are followed.

If you’re looking for instructions on how to sign someone’s gpg key, please look at this page instead.

Why PGP/GPG?

PGP/GPG is a public key cryptographic system. It allows people to send and sign electronic messages in a secure and verifiable manner. PGP/GPG depends on building a web of trust among its users since there is no centralized authority. This web is built by people signing each other’s public keys, and the level of trust or confidence you can have when interacting with someone presenting a public key depends on who has signed it and how careful they were in validating the owner’s identity.

I use PGP/GPG to sign most of my emails, so if there is ever any need to verify that I sent it and the message is intact, that verification can be done. Additionally, sometimes I encrypt my messages when I want to ensure the confidentiality of the message. (Even in 2024 there are still servers that transmit emails without STARTTLS, so anyone listening in could view its contents. PGP/GPG encryption prevents this.)

My Web of Trust

This is what my web of trust currently looks like, as of October 2024. My two old (revoked) keys have a good number of signatures, but I’ve chosen not to show most of them to reduce clutter. A green border indicates a key (such as mine) that belongs to a Debian Developer (DD) in the Debian keyring.

GPG Web of Trust

Graph generated by a modified sig2dot2 (Click image for a larger PDF version; 133.1KB)

My Location

I am currently living in Albuquerque, NM. It would be easiest to arrange a meeting if you are in the Albuquerque area.

Signature Levels

There are four types of signatures used for certification of a key holder’s identity, as described in RFC 4880:

Because both 0x10 and 0x11 do not convey any useful information about how well the signer verified the signee’s identity, I will not sign public keys with either of these two levels.

For me to sign your public key with 0x12 (casual certification), the following requirements need to be met by the signee:

For me to sign your key with 0x13 (positive certification), the following in addition to the requirements for 0x12 need to be met by the signee:

Signing Process

When I agree to sign someone’s key, I expect that they will be willing and able to sign my public key in return. This helps to strengthen the web of trust with mutual verification.

These are the steps I will take to sign your public key:

  1. Arrange to meet at some public location
  2. At the meeting, each person will identify themselves to the satisfaction of the other following established requirements for IDs, etc
  3. Upon achieving positive identification, exchange written or printed copies of the public key’s fingerprint, along with the associated uid(s) to be signed and the signer’s email address to which signing requests will be sent in the next step
  4. After the meeting, the signee will send an email to the signer’s specified email address for each uid they wish to have signed. Each email must be signed with the signee’s public key, and the sending email address must match the uid exactly
  5. I will then locally sign each uid requested
  6. After signing your public key, I will encrypt the signed copy to the signee and send an email signed with my public key to the corresponding uid’s email address with the encrypted signed key attached
  7. When you receive this email, you may import my signature, and then (if you wish, and I would recommend it) push the signature to a public key server

Requiring the signee to send a signed email from each uid address and then sending the signed public keys back to the uid address encrypted ensures that the signee has control of both the email account claimed by the uid and the PGP/GPG public/private key pair used by the signee. Skipping either of these steps could potentially allow signatures to be made which do not accurately reflect the true identity of the signee.

Modified Signing Process for DebConf-style Keysigning Parties

When participating in a DebConf-style keysigning party, I follow a slightly modified series of steps to sign your public key:

  1. Prior to attending the keysigning party, all participants will send their public key fingerprint(s) to the organizer who will organize an authoritative list of attendees and their fingerprint(s)
  2. At the beginning of the keysigning party, all participants will verify that their public key fingerprint(s) is correct in the master list, and that the SHA256 hash of that document matches the value computed by every other participant
  3. For each participant, I will confirm they verified their fingerprint from the master list and check their photo ID
  4. I will then locally sign the participant’s public key
  5. After signing your public key, I will encrypt the signed copy to the signee with the encrypted signed key attached
  6. When you receive this email, you may import my signature, and then (if you wish, and I would recommend it) push the signature to a public key server

Signing Subsequent Keys Before Expiration / Revocation of Old Key

If I have signed your public key and it is set to expire in the near future, or if you decide to generate a new public key and revoke your old one, I will sign your new key without needing to meet in person if the following conditions are met:

  1. Send me an email signed with your old key. This email needs to list the full fingerprint of the new key, along with the new primary uid (even if it remains the same as the old key).
  2. The old key cannot have expired or been revoked before the email is sent
  3. When I receive your message and verify its signature, I will send you a signed email acknowledging the receipt
  4. Then follow the signing process as outlined above, beginning at step 4 using the newly generated key to perform the needed signings

Note: I will only guarantee to sign the new primary uid and any sub-uids that I had previously signed on the old key. New sub-uids will be signed at my discretion.

Revision History