OpenPGP Certificate Grammar

3.1. Certification Signature Types (0x10..0x13)

Section 5.2.1 of [RFC9580] defines four types of certification signature (0x10..0x13). All may be created by either the key owner or a third party, and may be calculated over either a User ID packet or a User Attribute packet. In addition, a Certification Revocation signature revokes signatures of all four types.¶

Historically, certifications were only made by third parties. First-party self-certifications only became customary later, and were made mandatory when preference subpackets were introduced.¶

3.2. Primary Key Binding Signature (Type 0x19)

Section 5.2.1.9 of [RFC9580] defines the Primary Key Binding Signature as:¶

• This signature is a statement by a signing subkey, indicating that it is owned by the primary key.¶

Section 10.1.5 of [RFC9580] gives additional details:¶

• For subkeys that can issue signatures, the Subkey Binding signature MUST contain an Embedded Signature subpacket with a Primary Key Binding signature (Type ID 0x19) issued by the subkey on the top-level key.¶

The motivation for this requirement is not contained in any of the RFCs, and the terms "signing subkey" and "subkeys that can issue signatures" are imprecise. We hereby address these omissions by modifying the above text to read:¶

• A Subkey Binding signature MUST contain an Embedded Signature subpacket with a Primary Key Binding signature (Type ID 0x19) issued by the subkey on the top-level key, if the Subkey Binding signature contains a Key Flags subpacket permitting that subkey to create OpenPGP signatures. A receiving implementation MUST reject any Subkey Binding signature that permits the creation of OpenPGP signatures by that subkey and does not contain a valid Subkey Binding signature. A Primary Key Binding signature is OPTIONAL otherwise.¶

  An attacker could issue a Subkey Binding signature over a public subkey that belongs to a victim, and publish it as part of the attacker's own certificate. A third party might then look up the subkey using the Issuer Key ID or Issuer Fingerprint subpacket from a signature made by the victim, and find the attacker's certificate instead. The attacker could then use this to impersonate the victim to the third party. The Primary Key Binding signature mitigates this attack, by requiring the subkey's owner to consent for it to be bound to a particular primary key.¶

3.3. Primary Key Revocation Signature (Type 0x20)

Section 5.2.1.11 of [RFC9580] defines the Key Revocation Signature as:¶

• This signature is calculated directly on the key being revoked. A revoked key is not to be used. Only Revocation Signatures by the key being revoked, or by a (deprecated) Revocation Key, should be considered valid Revocation Signatures.¶

The name and description are potentially confusing, as it can only revoke a Primary Key and not a Subkey -- other OpenPGP artifacts that are named "Key" without a qualifier (such as the "Key Flags" and "Key Expiration Time" subpackets) apply to both Primary Keys and Subkeys.¶

We therefore rename the 0x20 signature type to "Primary Key Revocation Signature" for clarity, and update its definition as follows:¶

• This signature is calculated directly on the primary key being revoked. A revoked primary key is not to be used. Only Revocation Signatures by the primary key being revoked, or by a (deprecated) Revocation Key, should be considered valid Primary Key Revocation Signatures.¶

3.4. Subkey Revocation Signature (Type 0x28)

Section 5.2.1.11 of [RFC9580] defines the Subkey Revocation Signature as:¶

• This signature is calculated directly on the primary key and the subkey being revoked. A revoked subkey is not to be used. Only Revocation Signatures by the top-level signature key that is bound to this subkey, or by a (deprecated) Revocation Key, should be considered valid Revocation Signatures.¶

The phrasing "top-level signature key that is bound to this subkey" is confusing. Instead, we update the definition for clarity:¶

• This signature is calculated directly on the primary key and the subkey being revoked. A revoked subkey is not to be used. Only Revocation Signatures by the primary key, or by a (deprecated) Revocation Key, should be considered valid Subkey Revocation Signatures.¶

There are several other places in [RFC9580] that use the term "top-level key" instead of "Primary Key", but this is not explicitly defined. It MUST be interpreted as a synonym for "Primary Key" in all these contexts.¶

3.5. Certification Revocation Signature (Type 0x30)

Section 5.2.1.13 of [RFC9580] defines the Certification Revocation Signature as:¶

• This signature revokes an earlier User ID certification signature (Type IDs 0x10 through 0x13) or Direct Key signature (Type ID 0x1F). It should be issued by the same key that issued the revoked signature or by a (deprecated) Revocation Key. The signature is computed over the same data as the certification that it revokes, and it should have a later creation date than that certification.¶

Section 5.2.4 of [RFC9580] is clear that Direct Key signatures and Certification Signatures have completely different constructions. This implies that there are two different ways to construct a Type 0x30 signature, each of which appears in a different part of an OpenPGP certificate.¶

The above definition dates back to [RFC2440], except for the "or Direct Key Signature" clause which was added to the first sentence in [RFC4880]. But the third sentence still defines the construction unconditionally by reference to "the certification that it revokes", even though it does not necessarily revoke a certification.¶

The use of a Certification Revocation Signature to revoke a Direct Key Signature is imprecise and not widely supported, and is hereby deprecated. Since Direct Key Signatures have no intrinsic semantics, the ability to revoke a Direct Key Signature is not necessary. To retract a previous statement made by a Direct Key Signature, it is sufficient to create a new Direct Key Signature with a different set of subpackets.¶

We therefore update the definition to remove the reference to Direct Key Signatures:¶

• This signature revokes an earlier User ID certification signature (Type IDs 0x10 through 0x13). It should be issued by the same key that issued the revoked signature or by a (deprecated) Revocation Key. The signature is computed over the same data as the certification that it revokes, and it should have a later creation date than that certification.¶

4.1. Conflicting Requirements in Current Specifications

Section 5.2.3.10 of [RFC9580] states:¶

• An implementation that encounters multiple self-signatures on the same object MUST select the most recent valid self-signature and ignore all other self-signatures.¶

But Section 5.2.3.31 of [RFC9580] states:¶

• If a key has been revoked because of a compromise, all signatures created by that key are suspect.¶

These requirements are in explicit conflict and must be resolved by further specification.¶

In addition, the use of the unqualified term "valid" is ambiguous. If read inclusively to mean that expired or revoked signatures are not "valid" for the purposes of this statement, it results in complex key validity calculations with questionable added utility and obscure failure modes.¶

We therefore update the first statement above to read:¶

• An implementation that encounters multiple self-signatures on the same object MUST select the most recent cryptographically valid self-signature and ignore all other self-signatures, unless there is a revocation signature over the same object.¶

4.2. Key and Certification Validity Periods

Key Expiration Time subpackets are a rich source of footguns:¶

1. They specify an offset rather than an timestamp, but are not usable without first converting to a timestamp.¶

2. The offset is calculated relative to the creation timestamp of a different packet (the component key packet).¶

3. Some implementations interpret them as being inheritable in their raw form, so that the same offset value gets applied to different creation timestamps.¶

4. It is unclear how to interpret Key Expiration Time subpackets in a v4 self-signature over a non-Primary User ID.¶

Further, their semantics overlaps that of Signature Expiration Time:¶

1. If the binding signature over a key expires, but the key does not, the key is nevertheless unusable due to lack of signatures.¶

2. If a key expires, but the signature over it does not, the signature is unusable.¶

This means there are effectively two expiration dates on a Key Binding signature, the key expiration and the signature expiration, but without distinct semantics.¶

In addition, the Signature Creation Time subpacket has an overloaded meaning in both Key Binding and Certification signatures:¶

1. It is used as the "valid from" timestamp of the object being signed over¶

2. It is used to order multiple similar signatures to determine which is valid¶

If this is interpreted strictly, it means that it is not possible to create a new Key Binding signature that reliably leaves the starting date of the key's validity unchanged. Some implementations have worked around this by generating signatures with creation dates backdated to one second after that of the previous signature.¶

The ability to create a new signature with an unchanged valid-from date allows historical signatures to be losslessly cleaned from a TPK, saving space. It is also more compatible with the historical interpretation favoured by PGP and GnuPG.¶

Finally, both Expiration Time subpackets use zero to mean "the infinite future", which requires explicit handling of the special case.¶

4.3. Key Binding Temporal Validity

To clean up the ambiguity in Key Binding signatures, we specify the following:¶

1. Key Binding signatures other than self-certifications over v4 Primary User IDs (Subkey Binding signatures, Primary Key Binding signatures, and Direct Key signatures) SHOULD NOT contain Signature Expiration Time subpackets, and any such subpackets MUST be ignored.¶

2. The validity of a component key extends from its creation time until its revocation or key expiration time.¶

3. If the most recent Key Binding signature has no Key Expiration Time subpacket, then the key does not expire.¶

4. Key Binding signatures cannot be directly revoked; the corresponding revocation signatures affect the key, not the binding.¶

5. A Key Binding signature is temporally valid if its creation time is later than the creation time of the primary key that made it.¶

6. A Key Binding signature is temporally valid even if the primary has been hard-revoked (so that we can still associate the primary key with its subkeys).¶

7. The creation time of the Key Binding signature is used only for ordering, not for calculation of signature validity.¶

8. Key Expiration Time subpackets are only meaningful in Key Binding signatures (including self-certifications over v4 Primary User IDs); an implementation MUST ignore a Key Expiration Time subpacket in any other signature.¶

A signature other than a Key Binding signature is temporally valid if it was made by a component key during its validity period.¶

(See also [RFC4880BIS-71], [OPENPGPJS-1800]).¶

4.4. Certification Temporal Validity

To clean up the ambiguity in Certification signatures, we specify the following:¶

1. Certification signatures other than self-certifications over v4 Primary User IDs SHOULD NOT contain Key Expiration Time subpackets, and any such subpackets MUST be ignored.¶

2. The validity of a User ID or User Attribute extends from the Primary Key's creation time until the User ID or User Attribute's revocation or signature expiration time.¶

3. If the most recent Certification signature has no Signature Expiration Time subpacket, then the ID or attribute does not expire.¶

4. A Certification signature is NOT valid if the primary has been hard-revoked.¶

5. The creation time of the Certification signature is used only for ordering, not for calculation of signature validity.¶

4.5. Cumulation of Signatures

A cryptographically valid Key Binding, Certification or Literal Data signature automatically and permanently supersedes any earlier signature of the same Signature Category, by the same key pair, over the same subject. If a later such signature expires before an earlier one, the earlier signature does not become valid again.¶

For the purposes of the above:¶

• "same key pair" refers to the public key packet as identified by the Issuer KeyID or Issuer Fingerprint subpacket.¶

• "same subject" refers only to the packets being signed over, and not to the metadata contained in the Signature packets (including subpackets) or any corresponding OPS packet.¶

Note however that this does not apply to revocation signatures, which have their own cumulation rules (Section 5).¶

(See also [SCHAUB2021])¶

FIXME: what about signatures with the same creation time? (issue #9)¶

5.1. Revoking a Primary Key

A Key Revocation signature invalidates the Primary Key packet that it is made over. By implication, this revokes the entire certificate (Transferable Public Key) anchored by the Primary Key.¶

5.2. Revoking a Subkey

A Subkey packet may be revoked because its private key material has been compromised. It is possible for a Subkey to be compromised without the Primary Key being affected, for example if the private Subkey and Primary Key material are stored on separate devices. In such a case, it is not necessary for a Subkey Revocation Signature to be generated ahead of time and escrowed, since the Primary Key is still usable and can generate a revocation as required.¶

5.3. Revoking a Certification

User ID and User Attribute self-certifications and Direct Key self-signatures can be explicitly expired or replaced by the keyholder by issuing a superseding signature, so the only reason for a certification revocation is for third-party certifications.¶

Section 6.2.1 of [RFC1991] provided guidance for the interpretation of Certification Revocations as follows:¶

• <30> - public key packet and user ID packet, revocation ("I retract all my previous statements that this key is related to this user") (*)¶

While this language was not carried over into later specifications of the OpenPGP standard, neither was it explicitly contradicted.¶

When Alice revokes her third-party certification over Bob's Primary Key and User ID, she is saying one of the following:¶

• Key is Compromised (0x02): "I believe that this key has been compromised"¶

• User ID No Longer Valid (0x32): "I no longer believe that this primary key should be associated with this identity"¶

Hard third-party certification revocations are useful in an environment where Alice is treated as an authority (say as a member of a corporate IT department) but does not have control over Bob's key material or access to an escrowed revocation of Bob's key.¶

FIXME: we need to specify what a receiving application should do when seeing an 0x02 certification revocation made by a trusted authority (see #8)¶

Alice's Certification Revocation signature packet could get attached to Bob's certificate by several methods:¶

• By submitting it to a keystore that performs an unauthenticated merge; this is however vulnerable to abuse¶

• By submitting it to a keystore whose administrators can override Bob's published certificate, for example a corporate directory¶

• By attaching it to her own key as an Embedded Signature subpacket, as specified in Section 3.2.1.1 of [I-D.gallagher-openpgp-user-attributes]¶

Alice could issue a superseding certification of her own over Bob's User ID or User Attribute instead of using a soft revocation type, however she may wish to be explicit about the finality of her decision.¶

5.4. No Revocation Expiration

Key material can be marked with an expiration date (e.g. in a self-signature). Signatures themselves can also be marked with an expiration date.¶

While Revocation Signatures are signatures, the act of revocation is permanent, so expiration is not applicable to revocations.¶

An implementation generating a Revocation Signature MUST NOT include an Signature Expiration Time subpacket or a Key Expiration Time subpacket in either the hashed subpackets area or the unhashed subpackets area of the signature packet. An implementation encountering a Revocation Signature packet that contains either expiration subpacket MUST ignore the subpacket.¶

5.5. Revocation Signature Subpackets

When generating a revocation signature, an implementation:¶

• SHOULD include a Signature Creation Time subpacket¶

• SHOULD NOT set the critical bit for any subpacket¶

• MUST NOT set the critical bit for any subpacket other than Signature Creation Time¶

• MUST NOT place Signature Creation Time or Reason for Revocation packets in the unhashed area¶

When consuming a revocation signature, an implementation:¶

• MUST ignore the critical bit for every subpacket¶

• MUST ignore any Signature Creation Time or Reason for Revocation subpacket in the unhashed area¶

An implementation MUST support the Signature Creation Time subpacket. If a revocation signature does not contain a valid Signature Creation Time subpacket, a receiving implementation MAY treat it as if it was created in the infinite past.¶

5.6. Revocations From the Future

If a Revocation signature appears to have been made in the future, its interpretation will depend on whether it is hard or soft:¶

• If a hard revocation is from the future, then its creation date is irrelevant, since hard revocations are retrospective. Hard revocations MUST be treated as if their creation date was in the infinite past, regardless of the value of the creation date subpacket.¶

• If a soft revocation is from the future, then the revocation SHOULD NOT take effect until that date.¶

5.7. Dealing With Revoked Certificates

Implementations MUST NOT encrypt to a revoked certificate. Implementations MUST NOT accept a signature made by a revoked certificate as valid unless the revocation is "soft" (see Section 5.8) and the timestamp of the signature predates the timestamp of the revocation. Implementations MUST NOT use secret key material corresponding to a revoked certificate for signing, unless the secret key material also corresponds to a non-revoked certificate.¶

Implementations MAY use the secret key material corresponding to a revoked certificate.¶

5.8. Hard vs. Soft Revocations

Reasons for Revocation subpacket allows different values.¶

Some of them suggest that a verifier can still accept signatures from before the timestamp of the Revocation. These are "soft" revocations.¶

All the rest require that a verifier MUST treat the certificate as "hard" revoked, meaning that even signatures that have creation timestamps before the creation timestamp of the revocation signature should themselves be rejected.¶

5.9. Revocation Certificates

A revocation certificate indicates that a given primary key is revoked.¶

This can take two common forms. Each form is a sequence of OpenPGP packets:¶

• A standalone Key Revocation signature packet by key X over X (this form is valid only for primary keys earlier than version 6)¶

• Primary Key X + Key Revocation signature by X over X¶

Additionally, there is a deprecated form:¶

• Primary Key X + Direct Key Signature with Revocation Key subpacket pointing to Y + Key Revocation signature by Y over X (this form is valid only for primary keys earlier than version 6)¶

6.1. Freshness Considerations

6.2. Revocations Using Weak Cryptography

What if we find a Key Revocation signature made using SHA1 or MD5? Should we consider the indicated key revoked? (issue #2)¶

6.3. Shared Key Material

If a primary key is revoked with Reason for Revocation 2 (key has been compromised), then an implementation MAY infer that any other certificate containing the same key material has also been compromised. Note that testing key material for equality is nontrivial due to flexibility in representation, and is therefore outside the scope of this document.¶

If a primary key is revoked for any reason other than key compromise, an implementation MUST NOT infer anything about any other certificate containing the same key material.¶

If a subkey is revoked for any reason, an implementation MUST NOT infer anything about any other certificate containing the same key material. This is because a key owner can create a valid subkey revocation signature over a subkey containing arbitrary key material:¶

• embedded Primary Key Binding Signatures are not required in Subkey Revocation Signatures¶

• an earlier valid Subkey Binding Signature is not required to validate a later Subkey Revocation Signature¶

Encryption subkeys cannot create embedded Primary Key Binding Signatures, but a malicious subkey binding over an arbitrary encryption subkey has no security implications, since the only person adversely affected would be the attacker themselves, whose correspondents would encrypt to the wrong key. By contrast, if a malicious revocation over such a subkey was interpreted as a valid revocation over the original key material, the key's actual owner might no longer be able to receive encrypted messages at all.¶

Therefore, the meaning of a Subkey Revocation Signature MUST be limited to the context of the primary key that made the revocation signature.¶

6.4. Escrowed Revocation Certificates

An escrowed revocation certificate is just a valid revocation certificate that is not published. The parties who can retrieve or reassemble the escrowed revocation certificate can publish it to inform the rest of the world that the certificate has been revoked. It is described in Section 13.9 of [RFC9580].¶

Since the reason for publishing an escrowed revocation cannot be known in advance, escrowed revocations SHOULD NOT include a Reason for Revocation subpacket. If such a subpacket is included, it SHOULD explicitly state a reason of "none" (0x00).¶

Since the reason for publishing an escrowed revocation cannot be known in advance, escrowed revocations SHOULD NOT include a Reason for Revocation subpacket. If such a subpacket is included, it SHOULD explicitly state a reason of "none" (0x00).¶

In what circumstances does escrowed revocation work? When is it inappropriate? (issue #6)¶

8.1. OpenPGP Signature Types Registry

IANA is requested to update the following existing entries in the registry:¶

((TODO: avoid clash between the updates to 0x19 here and in draft-certificates))¶

8.2. OpenPGP Signature Subpacket Types Registry

The "Reason for Revocation Code" entry in the "OpenPGP Signature Subpacket Types" registry should have its References column updated to additionally point to this document.¶

8.3. OpenPGP Reason for Revocation Code Registry

The "OpenPGP Reason for Revocation Code" registry should add a column to indicate "Hard/Soft". Only "Key is Superseded" and "Key is retired and no longer used" are marked "Soft". All other values should be treated as "Hard".¶

9.1. Normative References

[RFC2119]

Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, DOI 10.17487/RFC2119, March 1997, <https://www.rfc-editor.org/rfc/rfc2119>.

[RFC8174]

Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC 2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174, May 2017, <https://www.rfc-editor.org/rfc/rfc8174>.

[RFC9580]

Wouters, P., Ed., Huigens, D., Winter, J., and Y. Niibe, "OpenPGP", RFC 9580, DOI 10.17487/RFC9580, July 2024, <https://www.rfc-editor.org/rfc/rfc9580>.

9.2. Informative References

[ASKCERTLEVEL]

Gillmor, D. K., "'gpg --ask-cert-level' Considered Harmful", 20 May 2013, <https://dkg.fifthhorseman.net/blog/gpg-ask-cert-level-considered-harmful.html>.

[I-D.dkg-openpgp-abuse-resistant-keystore]

Gillmor, D. K., "Abuse-Resistant OpenPGP Keystores", Work in Progress, Internet-Draft, draft-dkg-openpgp-abuse-resistant-keystore-06, 18 August 2023, <https://datatracker.ietf.org/doc/html/draft-dkg-openpgp-abuse-resistant-keystore-06>.

[I-D.gallagher-openpgp-user-attributes]

Gallagher, A., "User Attributes in OpenPGP", Work in Progress, Internet-Draft, draft-gallagher-openpgp-user-attributes-01, 3 November 2025, <https://datatracker.ietf.org/doc/html/draft-gallagher-openpgp-user-attributes-01>.

[OPENPGPJS-1800]

Hell, I., "'Signature creation time is in the future' error for apparently valid signature", 28 October 2024, <https://github.com/openpgpjs/openpgpjs/issues/1800>.

[RFC1991]

Atkins, D., Stallings, W., and P. Zimmermann, "PGP Message Exchange Formats", RFC 1991, DOI 10.17487/RFC1991, August 1996, <https://www.rfc-editor.org/rfc/rfc1991>.

[RFC2440]

Callas, J., Donnerhacke, L., Finney, H., and R. Thayer, "OpenPGP Message Format", RFC 2440, DOI 10.17487/RFC2440, November 1998, <https://www.rfc-editor.org/rfc/rfc2440>.

[RFC4880BIS-71]

Gallagher, A., "Deprecate the use of 'Key Expiration Time' packets (type 9) in V5 sigs", 8 January 2022, <https://gitlab.com/openpgp-wg/rfc4880bis/-/issues/71>.

[SCHAUB2021]

Schaub, P., "[openpgp] Question on Signature Expiration", 13 December 2021, <https://mailarchive.ietf.org/arch/msg/openpgp/C0P4MxwqJBbxS6H0YoXFF3oEJ3A/>.