OpenPGP Certification Practice Statement

This document describes the practices that I, Ian Maxwell, will follow in issuing digital OpenPGP UID and UAT certifications

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]


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.

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.

  1. The key must have at least one signing-capable subkey or one encryption-capable subkey (or be signing- or encryption-capable itself).
  2. 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.)
  3. 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.
  4. 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:

  1. 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.
  2. 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.
  3. 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:
    1. 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.
    2. 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.
  4. For image UATs, and for UIDs containing only a name, I will send certificates for these alongside those for the mailboxes I certify.
  5. 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:

  1. 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.
  2. 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.


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.

  1. 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.
  2. 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.


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.


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.