OpenPGP Signatures and Signed Messages

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:¶

• 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.¶

  A Primary Key Binding signature is REQUIRED in any Subkey Binding signature that contains one or more Key Flags whose specification requires one. A receiving implementation MUST reject any Subkey Binding signature that contains one or more of these Key Flags and does not contain a valid Subkey Binding signature. A Primary Key Binding signature is OPTIONAL otherwise.¶

Initially, the only Key Flags for which a Primary Key Binding signature is REQUIRED are 0x02 (Literal Data Signature Category), 0x0008 (Timestamping Category) and ((TBC)) (Countersignature Category) (Section 11.2).¶

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.¶

(See also Section 6.1)¶

3.6. Timestamp Signature (0x40)

Section 6.2.1 of [RFC1991] defined the Timestamp signature as:¶

• <40> - time stamping ("I saw this document")¶

  Type <40> is intended to be a signature of a signature, as a notary seal on a signed document.¶

The second statement implies that a v3 0x40 sig is made over a signature packet. But the first statement implies a signature over a document, just with different semantics.¶

By Section 5.2.1.14 of [RFC9580], this has changed to:¶

• 0x40: Timestamp signature. This signature is only meaningful for the timestamp contained in it.¶

This avoids the apparent contradiction of [RFC1991], but is less informative. And there is no explicit construction given in Section 5.2.4 of [RFC9580].¶

We note also that [RFC9580] introduced a Key Flag for timestamping. This indicates that timestamping documents is sufficiently different from signing them that separate keys should be used. This is consistent with the idea that "I wrote this document" and "I saw this document" are distinct statements with different consequences. This is crucial in the case of an automated timestamping service that makes no claims about the accuracy of document contents.¶

We define type 0x40 Timestamp signatures as follows:¶

• A type 0x40 Timestamp signature is made over a Literal Data Packet, and is constructed the same way as a type 0x00 Binary Document Signature. If the message is a text document, it MUST already be in Canonical Text form. By default a Timestamp signature conveys no opinion about the validity of the document; it only claims that the document existed at the timestamp of signature creation. This interpretation MAY be modified by adding notation subpackets, the meaning of which are application-dependent. It can be made over an otherwise unsigned document, or it can be one of many signatures over the same document. The Cleartext Signature Framework MUST NOT be used with Timestamp signatures.¶

Countersigning a Signature packet only (including blind countersigning) is done using the type 0x50 Third-Party Confirmation signature.¶

3.7. Third-Party Confirmation Signature (0x50)

Section 5.2.1.15 of [RFC9580] defines a Third-Party Confirmation signature as:¶

• This signature is a signature over some other OpenPGP Signature packet(s). It is analogous to a notary seal on the signed data. A Third-Party Confirmation signature SHOULD include a Signature Target subpacket that identifies the confirmed signature.¶

A concrete construction is provided, but the placement and semantics are still not well-defined. We clarify these as follows:¶

• By default, a Third-Party Confirmation signature makes no claim about the validity of the other signature, just its existence, and makes no claim whatsoever about the subject of that signature. This interpretation MAY be modified by adding notation subpackets, the meaning of which are application-dependent. It MAY be included in an Embedded Signature packet in the unhashed area of the signature it notarizes. Otherwise, it SHOULD be distributed as a detached signature. A Signature Target subpacket SHOULD NOT be included.¶

4.1. OPS Message Constraints

We constrain OPS structures to a subset of previously-allowed configurations:¶

• A prefixed Signature packet signs over the next literal or compressed packet, ignoring any intervening signature or OPS packets.¶

• Prefixed signatures and OPS signatures MUST NOT both be used in the same message.¶

• When generating an OPS packet that is not followed by another OPS packet, the nesting octet SHOULD be set to 1.¶

  • Otherwise, the nesting octet SHOULD be set to 0.¶

• When consuming an OPS packet, the nesting octet MUST be ignored.¶

This effectively deprecates the nesting octet, while maintaining backwards compatibility with legacy code.¶

4.2. Subject Normalization

The subject of an OpenPGP signature refers to the packet(s) that are signed over. The type-specific data of an OpenPGP signature refers to the section of the data stream that is passed to the signature's digest function after the optional salt and before the trailer. The type-specific data differs from the subject in that it has been normalized, the details of which are dependent on the signature type.¶

The subject of a signature in the Literal Data category (Section 6) is the Literal Data packet that immediately follows one or more prefixed signatures, or is enclosed by one or more OPS constructions. If no Literal Data packet is present, the signature is malformed.¶

The following normalization steps are applied to the subject of the signature to produce the type-specific data:¶

• The framing of the Literal Data packet is discarded, and any partial-length packets are concatenated.¶

• If the Signature Type is 0x01, the Literal Data packet body is converted to Canonical Text, by converting line endings to CRLF and removing any trailing whitespace (Section 4.2.1).¶

A One-Pass Signature over a Literal Data packet, a prefixed Signature over the same packet, and a detached signature over a file containing the body of the same packet are all calculated the same way. This means that they can be losslessly transformed into each other with the exception of the Literal Data metadata fields, which an application MAY assume contain their recommended default values as per Section 5.9 of [RFC9580].¶

A signature of Type 0x01 MUST NOT be made over arbitrary binary data, only over UTF-8 text.¶

4.3. Nested Signatures

To sign over an entire signed message together with its signatures, the wire format of the inner message SHOULD first be encapsulated in a Literal Data packet. A Canonical Text signature MUST NOT be made over such a nested message, and the Cleartext Signature Framework MUST NOT be used.¶

Beware that the outer signature will thus be sensitive to the inner message's packet framing, i.e. the otherwise inconsequential choice of packet header format and partial body lengths. If the inner message is parsed and re-serialized unmodified, but using a different framing, the outer signature will no longer validate.¶

4.4. Formal Grammar

The message grammar in Section 10.3 of [RFC9580] is therefore updated to:¶

• Literal Message:
  Literal Data Packet.¶

• Encrypted Session Key:
  Public Key Encrypted Session Key Packet | Symmetric Key Encrypted Session Key Packet.¶

• Encrypted Data:
  Symmetrically Encrypted Data Packet | Symmetrically Encrypted and Integrity Protected Data Packet.¶

• Encrypted Message:
  Encrypted Data | Encrypted Session Key, Encrypted Message.¶

• Prefixed Signed Message: Signature Packet, Prefixed Signed Message | Literal Message.¶

• Multiply One-Pass Signed Message:
  One-Pass Signature Packet (with nesting octet 0), One-Pass Signed Message, Corresponding Signature Packet.¶

• Singly One-Pass Signed Message:
  One-Pass Signature Packet (with nesting octet 1), Literal Message, Corresponding Signature Packet.¶

• One-Pass Signed Message:
  Multiply One-Pass Signed Message | Singly One-Pass Signed Message.¶

• Signed Message:
  Prefixed Signed Message | One-Pass Signed Message.¶

• Optionally Signed Message:
  Signed Message | Literal Message.¶

• Compressed Message:
  Compressed Data Packet.¶

• Unencrypted Message:
  Compressed Message | Optionally Signed Message.¶

• Optionally Padded Unencrypted Message:
  Unencrypted Message | Unencrypted Message, Padding Packet.¶

• OpenPGP Message:
  Encrypted Message | Unencrypted Message.¶

In addition to these rules, a Marker packet (Section 5.8 of [RFC9580]) can appear anywhere in the sequence.¶

4.5. Unwrapping Encrypted and Compressed Messages

[RFC9580] permits an encrypted message to contain another encrypted message, and a compressed message to contain another compressed message, possibly recursively. Such messages require potentially unbounded resources for negligible added utility, and therefore MUST NOT be created.¶

In addition, encrypt-then-sign messages are not idiomatic OpenPGP, and MUST NOT be generated.¶

The guidance in Section 10.3.1 of [RFC9580] is therefore updated to:¶

• Decrypting a version 2 Symmetrically Encrypted and Integrity Protected Data packet MUST yield a valid Optionally Padded Decrypted Message.¶

• Decrypting a version 1 Symmetrically Encrypted and Integrity Protected Data packet or -- for historic data -- a Symmetrically Encrypted Data packet MUST yield a valid Decrypted Message.¶

• Decompressing a Compressed Data packet MUST yield a valid Optionally Signed Message.¶

4.6. Marker Packet

Section 5.8 of [RFC9580] defines the Marker Packet as follows:¶

• The body of the Marker packet consists of:¶

  • The three octets 0x50, 0x47, 0x50 (which spell "PGP" in UTF-8).¶

  Such a packet MUST be ignored when received.¶

We update this to include:¶

• If a receiving implementation encounters a Marker Packet with any other contents, the entire packet sequence SHOULD be rejected.¶

• A Marker Packet MAY be added by an application to notify non-OpenPGP software that a data stream contains OpenPGP data. If so, the Marker Packet SHOULD be the first packet in the sequence, and SHOULD NOT use a Legacy header, so that it can be easily detected.¶

5.1. Recursive Embedding Inside Signature Subpackets

Section 5.2.3 of [RFC9580] specifies two subpackets which could recursively include a signature inside a signature:¶

• Embedded Signature (type 32): contains a signature packet¶

• Key Block (type 38, experimental): contains an entire certificate, which may itself include signature packets¶

In order to prevent excessive recursion via nested signature subpackets:¶

• Signatures contained within Embedded Signature subpackets MUST NOT contain any Embedded Signature subpackets:¶

  • An Embedded Signature subpacket MUST contain a signature of an Embeddable signature type.¶

  • An Embeddable signature MUST NOT contain Embedded Signature subpackets.¶

  • Initially, only the Primary Key Binding and Third-Party Confirmation signature types are specified as Embeddable.¶

• A Key Block subpacket MUST only be used inside a signature type in the Literal Data Signature Category.¶

A receiving implementation MUST invalidate any signature that does not conform to the above guidance.¶

5.2. Subpackets with Conflicting Information

Section 5.2.3.9 of [RFC9580] gives a receiving implementation significant leeway in interpreting conflicting combinations of subpackets:¶

• It is certainly possible for a signature to contain conflicting information in subpackets. For example, a signature may contain multiple copies of a preference or multiple expiration times. In most cases, an implementation SHOULD use the last subpacket in the hashed section of the signature, but it MAY use any conflict resolution scheme that makes more sense.¶

We hereby tighten this guidance:¶

• A signature MUST NOT contain more than one subpacket of any given type in its hashed subpackets area, unless otherwise specified. A receiving implementation MUST invalidate a signature that contains in its hashed area more than one subpacket of any type for which this is not explicitly permitted.¶

Multiple copies of the following subpacket types are already explicitly permitted:¶

• Issuer Key ID Section 5.2.3.9 of [RFC9580]¶

• Notation Data Section 5.2.3.24 of [RFC9580]¶

• Intended Recipient Fingerprint Section 5.2.3.36 of [RFC9580]¶

In addition, the following interpretations are natural extensions of specified behaviour, and hereby permitted:¶

6.1. Key Flags

A Key Flags subpacket SHOULD be included in a Direct Key or Subkey Binding signature (or for v4 keys, a self-certification over the primary User ID). It applies only to a single key material packet; for a Direct Key signature (or primary User ID self-cert) it applies to the primary key only, and for a Subkey Binding signature, it applies only to that subkey.¶

Previously, it was also specified for use in third-party Certification Signatures. This is not widely supported and is hereby deprecated.¶

The following Key Flags permit the creation of signatures in one or more Signature Categories:¶

• 0x01.. Third-party signatures in the Certification and Certification Revocation Categories¶

• 0x02.. Literal Data Signature Category¶

• 0x0008.. Timestamping Category¶

• ((TBC)) Primary Key Revocation Category¶

• ((TBC)) Countersignature Category¶

The following exceptional usages are always permitted regardless of Key Flags:¶

• Primary keys are always permitted to make self-signatures in the Certification, Key Binding, Certification Revocation, Primary Key Revocation and Subkey Revocation Categories.¶

• Subkeys with signing-capable algorithms are always permitted to make Primary Key Binding signatures.¶

• Any key is permitted to make a signature in the Private and Experimental range.¶

Otherwise:¶

• A signature made by a key that does not have the corresponding Key Flag MUST be considered invalid.¶

• A key with no Key Flags subpacket MUST NOT create signatures.¶

Section 5.2.1.10 of [RFC9580] also explicitly allows keys with the 0x01 Key Flag to create third-party 0x1F Direct Key Signatures. These are used for trust delegation in [SQ-WOT].¶

6.2. Authentication Signatures

OpenPGP defines no authentication signature types, but does have an authentication Key Flag. Traditionally, authentication is performed by converting the key material into that of another protocol (usually OpenSSH) and performing authentication in that protocol.¶

Beware that cross-protocol usage can be exploited to evade the domain separation protections of Key Flags. For example, there is no distinction between document signing, certification and authentication usage in OpenSSH, and once converted an OpenPGP authentication key may be used as a OpenSSH CA or to sign git commits.¶

((TODO: Guidance for the use of authentication keys should be provided.))¶

7.1. General subpackets.

These may be attached to any signature type, and define properties of the signature itself. Some of these subpackets are self-verifying (SV), i.e. they contain hints to locate the issuing key that can be confirmed after the fact. It MAY be reasonable to place self-verifying general subpackets in the unhashed area. All other general subpackets MUST be placed in the hashed area.¶

Subpacket types: Signature Creation Time, Signature Expiration Time, Issuer Key ID (SV), Notation Data, Signer's User ID, Issuer Fingerprint (SV).¶

(Notation subpackets are categorized here as general subpackets, however the notations within them may have arbitrary semantics at the application layer)¶

7.2. Context subpackets.

These have semantics that are meaningful only when used in signatures of a particular type or category:¶

7.3. Subpackets summary

Three subpacket types are Boolean, with different default values for when they are absent (two true, one false). It is RECOMMENDED that these subpackets not be used to convey their default values, only the non-default value. The default value SHOULD instead be conveyed by the absence of the subpacket.¶

Unless otherwise indicated, subpackets SHOULD NOT be marked critical. In particular, a critical subpacket that invalidates a self-signature will leave the previous self-signature (or no self-signature!) as the most recent valid self-signature from the PoV of some receiving implementations. A generating implementation MUST be sure that all receiving implementations will behave as intended if a signature containing a critical subpacket is invalidated. Otherwise, with the possible exception of Literal Data signatures, it is NOT RECOMMENDED to set the critical bit.¶

It is RECOMMENDED that a signature's creator places all subpackets in the hashed area, even self-verifying subpackets for which this is not strictly necessary. The unhashed area MAY be used for informational subpackets attached by third parties (which can be safely stripped).¶

7.4. Guidance for management of the Signature Subpacket Registry

• Future boolean subpackets SHOULD NOT contain an explicit value; a value of TRUE SHOULD be indicated by the presence of the subpacket, and FALSE otherwise.¶

• Specification of new subpackets SHOULD address classification, criticality and self-verification as outlined above.¶

• Subpackets SHOULD be implemented in the private/experimental area first, then reassigned to a permanent code point.¶

7.5. Unhashed Subpacket Deduplication

Unhashed subpacket areas are malleable and so may have subpackets added or removed in transit, either innocently or maliciously. A receiving implementation SHOULD clean the unhashed area of subpackets that are not meaningful or trustworthy outside the hashed area. If two signature packets are bitwise identical apart from differences in their unhashed subpacket areas, an implementation MAY merge them into a single signature. If two unhashed subpackets in the merged signature are bitwise identical, they MUST be deduplicated. Otherwise, the unhashed subpacket area of the merged signature SHOULD contain the useful subpackets from both original signatures, even if this means multiple subpackets of the same type.¶

8.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.¶

8.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.¶

FIXME: are other kinds of subkey revocation meaningful, see draft-revocations #1 ABG¶

8.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; ABG¶

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.¶

FIXME: Given an initial certification at time T, if the superseding certification has a timestamp of T+1, then will a verifier that cares about the certification still accept signatures from the key based on the User ID that were made exactly at time T? Alternately, if the superseding certification has a timestamp of time T exactly, will verifiers prefer its expiration date or the initial certification's expiration date (or lack thereof)?¶

8.4. Challenges with OpenPGP Revocation

This section describes a number of outstanding challenges with implementing OpenPGP revocation in the state of the field before this document. Some of these problems are fixed by this document.¶

8.5. Revocation Signature Subpacket limitations

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.¶

8.6. What About 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.¶

8.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 8.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.¶

8.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.¶

8.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)¶

8.10. Escrowed Revocation Certificate

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?¶

8.11. Deprecation of the "Revocable" Signature Subpacket

The "Revocable" subpacket is not commonly supported, and when used as described is effectively non-functional. It is hereby deprecated.¶

9.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.¶

9.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.¶

9.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]).¶

9.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.¶

9.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 8).¶

(See also [SCHAUB2021])¶

11.1. OpenPGP Signature Types Registry

IANA is requested to add a column to the OpenPGP Signature Types registry, called "Embeddable". This column should be empty by default.¶

IANA is requested to register the following new entry in the registry:¶

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

11.2. OpenPGP Key Flags Registry

IANA is requested to add a column to the OpenPGP Key Flags registry, called "Primary Key Signature Required". This column should be empty by default.¶

IANA is requested to register the following new entry in the OpenPGP Key Flags registry:¶

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

11.3. OpenPGP Signature Subpacket Types Registry

IANA is requested to add columns for "Category", "Critical", and "Self-Verifying" to the OpenPGP Signature Subpacket Types registry, and populate them with initial values as listed in Table 1.¶

IANA is requested to mark the "Revocable" subpacket entry as "deprecated", referencing this document, Section 8.11.¶

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

11.4. 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".¶

12.1. Normative References

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

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

[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>.

12.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>.

[FINNEY1998]

Finney, H., "Re: More spec-ulations - update", 26 March 1998, <https://mailarchive.ietf.org/arch/msg/openpgp/U4Qg3Z9bj-RDgpwW5nmRNetOZKY/>.

[I-D.dkg-openpgp-1pa3pc]

Gillmor, D. K., "First-Party Approved Third-Party Certifications in OpenPGP", Work in Progress, Internet-Draft, draft-dkg-openpgp-1pa3pc-02, 6 September 2024, <https://datatracker.ietf.org/doc/html/draft-dkg-openpgp-1pa3pc-02>.

[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.dkg-openpgp-revocation]

Gillmor, D. K. and A. Gallagher, "Revocation in OpenPGP", Work in Progress, Internet-Draft, draft-dkg-openpgp-revocation-02, 28 March 2025, <https://datatracker.ietf.org/doc/html/draft-dkg-openpgp-revocation-02>.

[I-D.gallagher-openpgp-hkp]

Shaw, D., Gallagher, A., and D. Huigens, "OpenPGP HTTP Keyserver Protocol", Work in Progress, Internet-Draft, draft-gallagher-openpgp-hkp-09, 3 November 2025, <https://datatracker.ietf.org/doc/html/draft-gallagher-openpgp-hkp-09>.

[I-D.gallagher-openpgp-literal-metadata]

Gallagher, A., "OpenPGP Literal Data Metadata Integrity", Work in Progress, Internet-Draft, draft-gallagher-openpgp-literal-metadata-00, 1 January 2024, <https://datatracker.ietf.org/doc/html/draft-gallagher-openpgp-literal-metadata-00>.

[I-D.ietf-openpgp-replacementkey]

Shaw, D. and A. Gallagher, "OpenPGP Key Replacement", Work in Progress, Internet-Draft, draft-ietf-openpgp-replacementkey-06, 13 October 2025, <https://datatracker.ietf.org/doc/html/draft-ietf-openpgp-replacementkey-06>.

[OPENPGPDEVBOOK]

"OpenPGP for Application Developers", 6 May 2024, <https://openpgp.dev/book/>.

[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>.

[RFC4880]

Callas, J., Donnerhacke, L., Finney, H., Shaw, D., and R. Thayer, "OpenPGP Message Format", RFC 4880, DOI 10.17487/RFC4880, November 2007, <https://www.rfc-editor.org/rfc/rfc4880>.

[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/>.

[SCHAUB2022]

Schaub, P., "[openpgp] Proposing a Simplification of Message Syntax", 7 October 2022, <https://mailarchive.ietf.org/arch/msg/openpgp/uepOF6XpSegMO4c59tt9e5H1i4g/>.

[SQ-WOT]

Walfield, N., "OpenPGP Web of Trust", 3 February 2022, <https://sequoia-pgp.gitlab.io/sequoia-wot/>.

B.1. Changes Between draft-gallagher-openpgp-signatures-01 and draft-gallagher-openpgp-signatures-02

• Merged in half of draft-dkg-openpgp-revocation and added DKG as co-author.¶

• Adapted key temporal validity rules for certification signatures.¶

• Specified use of Persona Certifications for non-trust statements.¶

• Added section for Primary Key Binding signatures.¶

• Added sections for conflicting subpackets and conflicting requirements.¶

• Specified line ending normalization of bare LF only.¶

• Deprecated revocation of Direct Key signatures.¶

• Deprecated Signature Target subpackets.¶

• Added section for issues with temporary identities.¶

• Refactored and constrained message grammar.¶

• Fixed some crufty terminology.¶

B.2. Changes Between draft-gallagher-openpgp-signatures-00 and draft-gallagher-openpgp-signatures-01

• Expanded temporal validity.¶

• Renamed "Document" and "Data Type" Signature Categories to "Literal Data" and "Attribute Value" respectively.¶

• Expanded experimental range to cover 0x60..0x6F (96..111).¶

• Add explicit category ranges to the Key Flags registry.¶

• Add explicit note about when to ignore Direct and Key Binding subpackets.¶

• Distinguish between signature subject and signature type-specific data.¶

• Deprecated the nesting octet.¶

• Minor errata.¶