OpenPGP Certification Practice Statement
Author | Ian Maxwell |
---|---|
Canonical URL | https://ian.maxwell.name/pgp/cps-2022-05-21.xhtml |
Publication date | |
Last updated | |
Current status | Active |
This document describes the practices that I, Ian Maxwell, will follow in issuing digital OpenPGP UID and UAT certifications
- using the master key with ID 0x7B9F12B9B5EF0DA1,
- on or after the date of publication of this document,
- until it has been superseded or obsoleted,
- whose policy URI packet, if present, contains the canonical URL above.
I intend to follow these practices for all certifications issued on or after the publication date above. In the event this document is superseded or otherwise made obsolete, it will remain in place, but with the Current status field above updated accordingly.
A digital signature for this document may be found here: [Signature]
Tl;dr
- I only issue 0x10 (
generic
) certificates. - If I’ve known you for a year or longer by the name in your UID, I will certify it as long as I can verify the email address belongs to you. You will have to meet me in person or by secure video call over an established channel, so I know it’s really you.
- If I don’t know you, or don’t know you well, then your UID must contain your legal name, you must prove this via photo ID, and we will have to meet in person to do this. I will still have to verify the email address is yours.
- To verify your email address, you’ll have to demonstrate the ability to apply your key to mail sent to that address, either by signing and returning a specific message sent to it or by receiving an encrypted message sent to it.
- If I certify your UID, I will also certify your photo UAT as long as it looks like a photo of you.
- If you are not an individual person but an organization or group, my critera for certification will be ad hoc but require at a minimum that I have a standing relationship with you in which I have made use of that key in exchanging information with you.
Key security
So that my certifications can be trusted as genuinely mine, these are the measures I take to maintain exclusive control of my private master key.
For regular use, my private master key is stored on a Yubico-brand smart card, from which it cannot be extracted by any practically feasible means known to me or the general public. This smart card is protected by a strong random PIN which I have memorized and have not written down, nor used for any other purpose.
A backup copy of this key exists, on an AES-encrypted filesystem on a bootable USB drive containing a live GNU/Linux distribution. After the initial installation and update of this software, the drive has been connected only to a powered-down air-gapped computer for the purpose of booting into GNU/Linux to create and access my master key. This USB drive is stored in a locked box when not in use.
In the event that either my smart card or my backup USB drive is lost, confiscated, or stolen, I will not necessarily consider my key compromised, since it is vanishingly unlikely that anyone would be able to gain control of my private key from either. For this reason I will likewise not necessarily revoke my key in this case, but will do so only if I have reason to believe it was taken for the specific purpose of gaining control over my private keys. As a matter of transparency I will state publicly if this ever happens, so that others can draw their own conclusions about how much trust to put in my key.
Certification semantics
This section describes what I intend a 0x10
(generic
) certificate to mean
when I issue one
with this key.
Note that I do not issue 0x11 (persona
) or
0x12 (casual
) certificates with this key at
all, and issue 0x13 (positive
) certificates only for my
own keys. I will not entertain requests to issue certificates
at any level other than 0x10. I feel that the proliferation of
certificate types, none of them clearly defined and most of them
never used, only overcomplicates and sows confusion as to what any
certificate actually means.
At a minimum, by certifying anything attached to a key, I express that to my knowledge none of the keys thereon had been compromised at the time that signature was made. In addition to this, I express one or more of the following assertions, depending on the nature of the certified packet.
- Personal names: By certifying a UID containing the name of a person, I express my high confidence based on personal verification that the name in the UID is the real name of the keyholder. A real name, for purposes of this certification, may be either a legally recognized name or a name by which the person is well-known in a social or professional context, but in any case must be firmly connected to their public identity as a whole.
- Organizational names: By certifying a UID containing the name of a group or organization, I express that the entity named in the UID is known to me, and that with high confidence based on personal verification the key is controlled by a person or persons acting on behalf of that entity.
- Mailboxes: By certifying a UID containing a mailbox address, I express my high confidence based on personal verification that the mailbox is owned by or delegated to the keyholder.
- Images: By certifying a UAT containing an image, I express that the image is an accurate photorealistic representation of the individual who holds the key.
- Nonstandard UIDs and UATs:
I do not certify nonstandard UATs, but may be convinced
to certify a UID containing no name or mailbox information,
provided it contains some falsifiable information about
the keyholder and I am also able to certify at
least one other, more typical UID for the same key. If I
do so, I will include a notation of form
cert-explanation@ian.maxwell.name=$VALUE
, where the$VALUE
field will contain the URL of a document giving the meaning of and justification for that certificate.
I disregard the comment field for purposes of verification, and my certification of a UID that includes a comment expresses no judgment whatsoever of the comment or its veracity.
Certification process
This section describes the process by which I verify and certify UIDs and image UATs.
Keys belonging to individuals
In order for me to certify anything attached to a key belonging to an individual person, all of the following must be true.
- The key must have at least one signing-capable subkey or one encryption-capable subkey (or be signing- or encryption-capable itself).
- The key must have at least one UID with a non-empty name field, and at least one UID with a mailbox address, or some address capable of receiving and sending private messages. (These need not be the same UID.)
- I must either have known the person for a minimum of one year by the name in the UID, or they must have and be willing to furnish a government-issued photo ID, such as a driver’s license, state identification card, or passport. I reserve the right to require ID at my discretion even for individuals whom I know.
- The person must be willing to meet with me in person, or, for those with whom I have an existing relationship and already know their telephone number, via video call though the Signal messenger app.
To verify and certify the UID(s) for a person’s key, I will take the following steps:
- We will arrange to meet either in person or via Signal video call, as appropriate. For people I do not know well, this meeting must be in a public place.
- During our meeting, I will ask the person to show me their photo ID, if necessary, and then confirm with me the full fingerprint of the key they wish me to certify, as well as which UIDs/UATs they wish me to certify. If I have not already retrieved their public key, I will also ask that they supply me with either the key or a link thereto at this time.
-
During or after our meeting (usually after), I will verify
control of the key and of each mailbox in one of the following
two ways:
- If the key is not encryption-capable, I will send a challenge to that mailbox in the form of a short statement containing a randomly generated code, and ask them to return that same statement signed with their key. Once I receive it and confirm that the signature is valid, I will send the certificate for that UID to the same mailbox.
- If the key is encryption-capable, I will simply send the certificate for each UID to the corresponding mailbox, encrypted. In this way the person will prove their ownership of the mailbox and key by eing able to receive and decrypt the certificate to make use of it.
- For image UATs, and for UIDs containing only a name, I will send certificates for these alongside those for the mailboxes I certify.
- For nonstandard UIDs, I will work out some variant of the proof protocol for mailboxes that logically establishes control of the resource named in the UID, and carry that out. In this case I will still only deliver the certificate to a mailbox specified in a UID attached to the key, unless the person has already proven control of one such mailbox to my satisfaction, in which case I may release it by whatever means we can agree upon.
Keys belonging to organizations
I have no fixed process for certifying keys belonging to groups or organizations. I will certify these on an ad hoc basis for organizations with which I have a standing relationship in which I have made use of those keys.
Other considerations
Cryptographic security requirments
I do not make any requirement on the choice of algorithm or cryptographic strength of a key, in order to certify its associated UIDs. This is for two reasons:
- Fundamentally I am certifying UIDs, not keys. My certification attests only to the truth of the information in the UID to which it is issued. It does not, and should never be taken to, attest to the security level of the key itself, so my opinion of what constitutes adequate security is irrelevant.
- In any case, even the weakest asymmetric-key ciphers available in any modern PGP implementation are strong enough for typical use cases and certainly stronger than not using cryptography at all.
Recertification
If you have a new master key and I have previously certified at least one UID under your old one, I will generally be willing to certify any identical UIDs under the new one, by an expedited process. This assumes you are still able to use the old key; if not, we will have to start over again.
- Send me, or point me to, a key transition statement: a message, signed with both your old and new keys, stating that the old key is superseded by the new one. Include in the message a copy of, or a URL for, your new public key.
- I will certify all UIDs on the new key that match those I have already certified for the old, and send those certifications to you in the same manner I did before.
If your name changes, I will certify new UIDs under your new name provided you provide me in person with legal documentation of the name change, or if I know you well personally and know you to be going by the new name in general. In this case I will not require recertification of existing mailboxes and can provide you with the certificate by whatever means you prefer.
If you have a new email (or other) address, no expedited process is available for certifying the corresponding UID. This is because I would still require an in-person or secure video meetup for you to confirm your key has not been compromised, which together with the verification of your address makes up the bulk of my certification process anyway.
Revocation
I will revoke all certifications I have made on a key if I am given good reason to believe either
- that the information I attested via the certificate is in fact false, or
- that the key has been compromised and is no longer safe to use.
I will also revoke any certification by request of the keyholder, if they send me a signed message requesting that I do so.
I will release all revocations publicly, both on my own web space and on multiple keyservers.
Reciprocity
As a matter of courtesy, if you want me to certify a UID for your key I will ask that you agree to certify mine as well, according to whatever verification process is typical for you. This is particularly the case if I do not know you well and you are actively soliciting a certificate from me. Usually it will be most convenient if we both do our verifications during the same meeting.
If you are for whatever reason unwilling to do this, I expect that you will disclose that before we arrange to meet, so that I can decide in advance whether it is worth my time to go to the trouble of verifying your identity. I may be willing to accept some other consideration in lieu of reciprocal certification; feel free to make an offer.
Right of refusal
Nothing in this document constitutes a promise or contract. I reserve the right to refuse certification to anyone, in part or in full, with or without a stated reason, unless I have actually entered a contract stipulating otherwise; and I will not enter any contract in which I agree to certify a UID without due verification.
Document version history
This section contains a dated list of changes that have been made to this document since its original publication. These changes are only clarifications, rewordings, or corrections to obvious errors, and not intended to change what is communicated by the document. If I make a substantial change to my policy, I will not modify this document except to mark it as superseded with a pointer to its replacement.
Date | Change notes | Initial publication. |
---|