This page describes my OpenPGP 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.
pub rsa4096/0x4E6C0EAA175F13A2 2021-03-12 [SC] [expires: 2025-03-12]
Key fingerprint = 07B1 A680 11CA 609C 8AB0 F67C 4E6C 0EAA 175F 13A2
uid [ultimate] Patrick Godschalk <patrick@kernelpanics.nl>
uid [ultimate] Patrick Godschalk <p.godschalk@ienpm.nl>
uid [ultimate] [jpeg image of size 5275]
sub rsa4096/0xDC5A4EE35F68AFAF 2021-03-12 [E] [expires: 2025-03-12] Why OpenPGP?
OpenPGP is a public key cryptographic system. It allows people to send and sign electronic messages in a secure and verifiable manner. OpenPGP 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 OpenPGP to sign some of my e-mails, 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 e-mail is in transit from one server to another, it is not encrypted, so anyone listening in could view its contents. OpenPGP encryption prevents this.)
My location
I am currently living in Leiden, The Netherlands.
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
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:
- 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 e-mail address to which signing requests will be sent in the next step
- After the meeting, the signee will send an e-mail to the signer's specified e-mail address for each UID they wish to have signed. Each e-mail must be signed with the signee's public key, and the sending e-mail 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 e-mail signed with my public key to the corresponding UID's e-mail address with the encrypted signed key attached
- When you receive this e-mail, 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 e-mail 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 e-mail account claimed by the UID and the OpenPGP 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 e-mail signed with your old key. This e-mail 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 e-mail is sent
- When I receive your message and verify its signature, I will send you a signed e-mail 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 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.