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 really 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. (You may be surprised to learn that the vast majority of time an email is in transit from one server to another, it is not encrypted, so anyone listening in could view its contents. PGP/GPG encryption prevents this.) My Web of Trust
This is what my web of trust looks like, as of 2014-05-23 (generated by sig2dot; click for a larger PDF version; 26.6KB):
GPG Web of Trust GPG Web of Trust 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 identify, as described in RFC 4880:
0x10: Generic certification of a User ID and Public-Key packet The issuer of this certification does not make any particular assertion as to how well the certifier has checked that the owner of the key is in fact the person described by the User ID. 0x11: Persona certification of a User ID and Public-Key packet The issuer of this certification has not done any verification of the claim that the owner of this key is the User ID specified. 0x12: Casual certification of a User ID and Public-Key packet The issuer of this certification has done some casual verification of the claim of identity. 0x13: Positive certification of a User ID and Public-Key packet The issuer of this certification has done substantial verification of the claim of identity.
Because both 0x10 and 0x11 do not actually 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:
Meet in person, either individually or at some signing party Present at least one government-issued photo ID Give me a written copy of your key's fingerprint, so I can verify I received the correct key before signing it
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:
I need to know you personally, and feel comfortable that you really are who you claim to be, OR Someone whose key I have already signed with 0x13 will vouch for you
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:
Arrange to meet at some public location At the meeting, each person will identify themselves to the satisfaction of the other following established requirements for IDs, etc 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 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 I will then locally sign each uid requested 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 When you receive this email, you may import my signature, and then (if you wish, and I would recommend) 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. 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:
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). The old key cannot have expired or been revoked before the email is sent When I receive your message and verify its signature, I will send you a signed email acknowledging receipt 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 gaurantee 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
2017-01-01: Update my location 2012-01-28: Added a graph of my web of trust 2012-01-26: Added section on signing subsequent keys 2012-01-24: Initial publication