]> PGPKeys.EU

andrewg@andrewg.com

int openpgp Internet-Draft This document specifies several updates and clarifications to the OpenPGP signature and message format specifications. The latest revision of this draft can be found at . Status information for this document may be found at . Discussion of this document takes place on the OpenPGP Working Group mailing list (), which is archived at . Subscribe at . Source for this draft and an issue tracker can be found at .

Introduction OpenPGP signatures have a rich vocabulary, however this is often under-specified. This document attempts to address this by: Expanding on specifications where does not fully describe the existing or expected behaviour of deployed implementations. Adding clarification where deployed implementations differ in their interpretation of and its predecessors. Deprecating unused or error-prone features. Constraining the formal message grammar. This document does not specify any new wire formats.

Conventions and Definitions The term "OpenPGP Certificate" is used in this document interchangeably with "OpenPGP Transferable Public Key", as defined in . The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in BCP 14 when, and only when, they appear in all capitals, as shown here.

Signature Types Several signature types are specified in incomplete, confusing or contradictory ways. We update their specifications as follows.

Certification Signature Types (0x10..0x13) 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. The semantic distinctions between the certification signature types were left ill-defined and most software treats them as equivalent. The following convention has evolved over time , and is hereby specified: 0x10 Generic Certification SHOULD only be used for third-party certifications. 0x11 Persona Certification is deprecated and SHOULD NOT be created. 0x12 Casual Certification is deprecated and SHOULD NOT be created. 0x13 Positive Certification SHOULD only be used for self-certifications. A receiving implementation MUST treat a third-party certification of any of the above types as equivalent to a type 0x10 signature, and a first-party certification of any of the above types as equivalent to a type 0x13 signature.

Primary Key Revocation Signature (Type 0x20) 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.

Subkey Revocation Signature (Type 0x28) 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.

Certification Revocation Signature (Type 0x30) 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.

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 , except for the "or Direct Key Signature" clause which was added to the first sentence in . 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. (See also )

Timestamp Signature (0x40) 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 , this has changed to:

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

This avoids the apparent contradiction of , but is less informative. And there is no explicit construction given in . Note also that introduced a Key Flag for timestamping. This would appear to indicate 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. An OPS packet contains a "nesting" octet that controls whether an inner OPS signature is included in the data signed over by the outer OPS signature (see ). By reference to , we can reconcile the above variations in semantics. We define type 0x40 Timestamp signatures as follows:

• A type 0x40 Timestamp signature is made over an OpenPGP Message, and constructed the same way as a type 0x00 Binary Document Signature. If the message is a text document, it SHOULD 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.

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

Third Party Confirmation Signature (0x50) 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 notarises; if it is so located, a Signature Target SHOULD NOT be included. Otherwise, it SHOULD be distributed as a detached signature.

Signature Target Subpacket The Signature Target subpacket is not a unique identifier of a signature packet () and so does not fulfil its design goals. It is deprecated for use in revocation signatures by ((TBC: this is just an issue for now, not in the draft)), and we hereby deprecate it entirely. ((TODO: use the Approved Certifications subpacket instead! But rename it to "target signatures"...))

Use of Third Party Confirmation Signatures by Applications We may wish to allow the application layer to make validity claims using countersignatures. For example, a key server may wish to record that it has verified a User ID by automated means. The key server may not wish to make a Certification signature, to prevent the cumulation of many such automated signatures (). For the same reason, it may not wish to embed its countersignature in an unhashed area of a signature packet in the certificate. It could make a Third-Party Confirmation signature over the most recent self-certification, and distribute it as a detached signature, perhaps in a mixed keyring (). ((TBC))

Message Grammar The accepted convention is that a prefixed Signature packet signs over the next literal packet only, skipping any intervening signatures - however this is not explicitly specified in . Historically, PGP 2.X treated a prefixed Signature packet as applying to the entire following message, but this usage is deprecated (). In addition, One-Pass Signature (OPS) nesting semantics are complex, and under-specified (). defines the nesting octet as:

• A 1-octet number holding a flag showing whether the signature is nested. A zero value indicates that the next packet is another One-Pass Signature packet that describes another signature to be applied to the same message data.

The terminology is imprecise, and non-zero "nesting" flags are completely unspecified. One self-consistent interpretation is as follows: A zero nesting octet means that the following OPS and its counterpart signature are stripped from the signature's subject. This process is recursive if multiple sequential OPS packets have a nesting octet of zero. To add multiple OPS signatures over the same message data, all OPS constructions except the innermost one have the nesting octet zeroed. It is not clear what happens if the innermost nesting octet is zero but no OPS packet follows; such a sequence SHOULD NOT be generated. The above implies that an OPS with a nonzero nesting octet signs over all packets between the OPS packet and its matching signature packet, including any further signatures. This is further expanded in . This still leaves us with an overly complex grammar that resists rigorous formalisation. We attempt to improve the formalism below.

OPS Subject Types The subject of an OpenPGP signature is the section of the data stream that is passed to the signature's digest function, aside from any metadata or fixed data. This data may undergo normalisation, depending on the signature context. suggests that a three-state nesting flag is required for an unambiguous treatment of all possible OPS subjects. We constrain OPS structures to a subset of configurations, and fully specify the handling of OPS signature subjects. The OPS nesting octet is renamed to "OPS Subject Type" to better convey its semantics, and the following values are specified: Type Description 0 Nested 1 Literal Body 2 Verbatim A prefixed Signature packet signs over the next literal or compressed packet, ignoring any intervening signature or OPS packets. When one or more prefixed signature packets and one or more one-pass signatures sign over the same subject, the prefixed Signature packet(s) MUST precede the OPS packet(s); this is only permitted if the OPS uses the Literal Body Subject Type.

Nested Subject Type The subject is identical to that of the following OPS packet. If no well-formed OPS packet follows, the signature is malformed. This subject type is used to create additional One-Pass Signatures over the same subject. The ordering of nested One-Pass Signatures is not meaningful (see ).

Literal Body Subject Type The subject is the body of the following Literal Data packet. The Literal Data packet MAY be encoded in a Compressed Data packet. If no Literal Data or Compressed Data packet follows, or if the Compressed Data packet does not decompress to a Literal packet, the signature is malformed. This subject type is used to create Document Signatures. A Literal Body 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. The following normalisation steps are applied to the subject when calculating the signature digest: Any Compressed Data packet is replaced by its uncompressed contents, which MUST be a Literal Data packet. The Literal Data packet is then replaced by its body. If the Signature Type is 0x01, the body is then converted to Canonical Text.

Verbatim Subject Type The subject is the exact sequence of packets between the end of the current One-Pass Signature packet and the beginning of its corresponding Signature packet. No normalisations are applied to the subject, not even conversion to Canonical Text. Beware that the signature will thus be sensitive to the packet framing, i.e. the otherwise inconsequential choice of packet header format and partial body lengths. If a packet sequence is parsed and re-serialised unmodified, but using a different framing, a Verbatim OPS will no longer validate. This subject type MUST NOT be used to create Document signatures.

Formal Grammar The message grammar in is therefore updated to: OpenPGP Message:
Encrypted Message | Unencrypted Message. Unencrypted Message:
Signed Message | Unsigned Message. Unsigned Message:
Compressed Message | Literal Message. Compressed Message:
Compressed Data Packet. Literal Message:
Literal Data Packet. ESK:
Public Key Encrypted Session Key Packet | Symmetric Key Encrypted Session Key Packet. ESK Sequence:
ESK | ESK Sequence, ESK. Encrypted Data:
Symmetrically Encrypted Data Packet | Symmetrically Encrypted and Integrity Protected Data Packet. Encrypted Message:
Encrypted Data | ESK Sequence, Encrypted Data. Nested One-Pass Signed Message:
Nested One-Pass Signature Packet, One-Pass Signed Message, Corresponding Signature Packet. Literal Body One-Pass Signed Message:
Literal Body One-Pass Signature Packet, Unsigned Message, Corresponding Signature Packet. Verbatim One-Pass Signed Message:
Verbatim One-Pass Signature Packet, Unencrypted Message, Corresponding Signature Packet. One-Pass Signed Message:
Nested One-Pass Signed Message | Literal Body One-Pass Signed Message | Verbatim One-Pass Signed Message. Signed Message:
Signature Packet, Unencrypted Message | One-Pass Signed Message. Optionally Padded Unencrypted Message:
Unencrypted Message | Unencrypted Message, Padding Packet. In addition to these rules, a Marker packet () can appear anywhere in the sequence.

Unwrapping Encrypted and Compressed Messages 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 SHOULD NOT be generated. The guidance in is therefore updated to: Decrypting a version 2 Symmetrically Encrypted and Integrity Protected Data packet MUST yield a valid Optionally Padded Unencrypted 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 Unencrypted Message. Decompressing a Compressed Data packet MUST yield a valid Literal Message. ((TODO: is this too constraining on compressed data packet contents?))

Marker Packet 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 ignored. 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.

Recursive embedding inside Signature Subpackets 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 We wish to prevent infinite recursion via embedded signatures, in order to avoid resource exhaustion. This can be achieved as follows: 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 Document Signature Category. ((TODO: Key Block allows us to smuggle a key into the OpenPGP layer without requiring support by the application layer. We could instead update the message grammar to allow TPKs to be appended to a Literal Message. Going further, we could unify the packet sequence grammar so that there is only one kind of sequence, which would include both messages and keyrings. See also "mixed keyrings" in .))

Signature Categories Signature Type code points are spaced out into identifiable ranges of types with similar semantics. These also mostly correspond to the various Key Flags. These ranges and their mapping to the Key Flags are not specified in . We define Signature Categories to cover each range of type values: Document Signature Category (0x00..0x07) 0x00 Signature over a Binary document 0x01 Signature over a Canonical Text document 0x02 Standalone (null document) Unassigned (0x08..0x0F) Certification Category (0x10..0x17) 0x10 Generic cert 0x11 Persona cert 0x12 Casual cert 0x13 Positive cert (0x16 Approved certs) Key Binding Category (0x18..0x1F) 0x18 Subkey bind 0x19 Primary key bind 0x1F Direct key (self bind) Primary Key Revocation Category (0x20..0x37) 0x20 Primary Key revocation Subkey Revocation Category (0x28..0x2F) 0x28 Subkey revocation Certification Revocation Category (0x30..0x37) 0x30 Cert revocation Unassigned (0x38..0x3F) Timestamping Category (0x40..0x47) 0x40 Timestamp Unassigned (0x48..0x4F) Countersignature Category (0x50..0x57) 0x50 Third party confirmation Unassigned (0x58..0x67) Private and Experimental Range (0x68..0x6E) Unassigned (0x6F..0xFE) RESERVED (0xFF) We have defined a Private and Experimental signature type range. This is 0x68..0x6E (104..110) for consistency with the conventional 100..110 range in other registries. It does not form a Category and does not have a corresponding Key Flag. Self-certifications over v4 Primary User IDs are used to convey the same information as Key Binding signatures. Therefore, unless specifically stated otherwise, any stipulations that apply to Key Binding signatures also apply to self-certifications over v4 Primary User IDs.

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.. Document 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, 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. also explicitly allows keys with the 0x01 Key Flag to create third-party 0x1F Direct Key Signatures. This is not widely supported and is hereby deprecated.

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. It should be noted that cross-protocol usage can be exploited to evade the domain separation protections of Key Flags. For example, there is no distinction between signature, 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.))

Signature Subpacket Categories Signature subpacket types may also be categorised, depending on where they are used:

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 categorised here as general subpackets, however the notations within them may have arbitrary semantics at the application layer)

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

Direct subpackets. These are normally only meaningful in a direct self-sig (or for v4 keys, a self-cert over the primary User ID) and define usage preferences for the certificate as a whole. They MAY be used in self-certs over other User IDs, in which case they define usage preferences for just that User ID (but this is not always meaningful or universally supported). The Replacement Key subpacket MAY also be used as a key revocation subpacket. They SHOULD NOT be used elsewhere. They MUST be placed in the hashed area. Subpacket types: (Additional Decryption Key), Preferred Symmetric Ciphers, Revocation Key (deprecated), Preferred Hash Algorithms, Preferred Compression Algorithms, Key Server Preferences, Preferred Key Server, Features, (Preferred AEAD Algorithms), Preferred AEAD Ciphersuites, (Replacement Key).

Revocation subpackets. These are only meaningful in signatures of the Key Revocation, Subkey Revocation or Certificate Revocation categories. They SHOULD NOT be used elsewhere. They MUST be placed in the hashed area. Subpacket types: Reason for Revocation.

Key Binding subpackets. These are only meaningful in a signature of the Key Binding category (or for v4 keys, a self-cert over the primary User ID) and define properties of that particular (sub)key. They SHOULD NOT be used elsewhere. They MUST be placed in the hashed area. Subpacket types: Key Expiration Time, Key Flags.

First-party Certification subpackets. These are only meaningful in a self-certification over a User ID, and define properties of that User ID. They SHOULD NOT be used elsewhere. They MUST be placed in the hashed area. Subpacket types: Primary User ID

Third-party Certification subpackets. These are only meaningful in third-party certification signatures and define properties of the Web of Trust. They SHOULD NOT be used elsewhere. They MUST be placed in the hashed area. Subpacket types: Exportable Certification, Trust Signature, Regular Expression, Revocable, Policy URI, (Trust Alias).

Document subpackets. These are only meaningful in signatures of the Document category, and define properties of the document or message. They SHOULD NOT be used elsewhere. Some of these subpackets are self-verifying (SV) and MAY be placed in the unhashed area. All other document subpackets MUST be placed in the hashed area. (Beware that the usefulness of all of these subpackets has been questioned) Subpacket types: Intended Recipient Fingerprint, (Key Block (SV)), (Literal Data Meta Hash).

Data type subpackets. These are only meaningful in signature types whose specification explicitly requires them. They SHOULD NOT be used elsewhere. They have no intrinsic semantics; all semantics are defined by the enclosing signature. Subpacket types: Signature Target, Embedded Signature, (Delegated Revoker), (Approved Certifications).

Subpackets summary Type Name Category Critical Self-Verifying Context Notes 0 Reserved -       never used 1 Reserved -       never used 2 Signature Creation Time General SHOULD     MUST always be present in hashed area 3 Signature Expiration Time General SHOULD       4 Exportable Certification Third MUST IFF false     boolean, default true 5 Trust Signature Third         6 Regular Expression Third SHOULD       7 Revocable Third       boolean, default false (deprecated in ) 8 Reserved -       never used 9 Key Expiration Time Key SHOULD       10 (Additional Decryption Key/ARR) Direct       PGP.com proprietary feature 11 Preferred Symmetric Ciphers Direct         12 Revocation Key (deprecated) Direct         13-15 Reserved -       never used 16 Issuer Key ID General   Yes   issuer fingerprint is preferred 17-19 Reserved -       never used 20 Notation Data General       notations may be further classified 21 Preferred Hash Algorithms Direct         22 Preferred Compression Algorithms Direct         23 Key Server Preferences Direct         24 Preferred Key Server Direct         25 Primary User ID First       boolean, default false 26 Policy URI Third       (effectively a human-readable notation) 27 Key Flags Key SHOULD       28 Signer's User ID General         29 Reason for Revocation Revocation       free text field is effectively a human-readable notation 30 Features Direct         31 Signature Target Data     0x50 3-p conf not a unique identifier () 32 Embedded Signature Data   Yes IFF it contains an 0x19 signature 0x18 sbind   33 Issuer Fingerprint General   Yes     34 (Preferred AEAD Algorithms) Direct       35 Intended Recipient Fingerprint Document SHOULD       36 (Delegated Revoker) Data MUST   TBD 37 (Approved Certifications) Data     0x16 1pa3pc 38 (Key Block) Document   Yes   39 Preferred AEAD Ciphersuites Direct         40 (Literal Data Meta Hash) Document       not yet implemented 41 (Trust Alias) Third       not yet implemented TBD (Replacement Key) Direct SHOULD NOT     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 document 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).

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.

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.

Time Evolution of Signatures

Key and Certification Validity Periods Key Expiration Time subpackets are a rich source of footguns: They specify an offset rather than an timestamp, but are not usable without first converting to a timetamp. The offset is calculated relative to the creation timestamp of a different packet (the (sub)key packet). Some implementations interpret them as being inheritable in their raw form, so that the same offset value gets applied to different creation timestamps. Further, their semantics overlaps that of Signature Expiration Time: If the binding signature over a key expires, but the key does not, the key is nevertheless unusable due to lack of signatures. 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: It is used as the "valid from" timestamp of the object being signed over 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.

Key Binding Temporal Validity To clean up the ambiguity in Key Binding signatures, we specify the following: Key Binding signatures (Subkey Binding signatures, Primary Key Binding signatures, Direct Key signatures, BUT NOT self-certifications over v4 Primary User IDs) SHOULD NOT contain Signature Expiration Time subpackets. The validity of a (sub)key extends from its creation time until its revocation or key expiration time. If the most recent Key Binding signature has no Key Expiration Time subpacket, then the key does not expire. A signature is valid if it was made by a (sub)key during its validity period. The creation time of the Key Binding signature is used only for ordering, not for calculation of signature validity. Key Expiration Time subpackets are only meaningful in Key Binding signatures; an implementation MUST ignore a Key Expiration Time subpacket in any other signature. We also specify that Key Binding signatures cannot be directly revoked; the corresponding revocation signatures affect the key, not the binding. (See also , , and ).

Certification Temporal Validity It is not customary for Certification signatures, even self-certifications over v4 Primary User IDs, to contain Key Expiration Time subpackets. Instead, the Signature Expiration Time subpacket is used. In addition, User IDs and User Attributes do not contain a creation time field. Together, this means that we cannot solve the temporal validity issue for Certifications as easily as we did for Key Bindings. Instead, we specify the following: ((TODO: who knows at this point, all the options have problems)) Option 1: new signature subpacket type that contains a Valid From time PRO: easy to implement CON: will need to exist in parallel with existing calculations Option 2: new Packet type that contains a User ID and a Valid From time PRO: also lets us use URIs instead of RFC822-ish CON: backwards compatibility Option 3: new User Attribute subpacket type that contains a User ID and a Valid From time PRO: as option 2 CON: as option 2, also UAT packets contain arbitrary content, cannot certify only one subpacket

Cumulation of Signatures A cryptographically valid Key Binding, certification or document 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 data fed into the signature digest function after the end of the salt (if appropriate) and before the beginning of the trailer. (See also )

Security Considerations The OPS Subject Type octet is not signed over and is malleable in principle. An intermediary could swap a Nested OPS with its inner OPS by also swapping the type octets. The order of OPS nesting therefore MUST NOT be considered meaningful. In addition, the subject transformations applied during Literal Body signature calculation may result in semantic collisions. It is possible to construct distinct sequences of packets that map to the same sequence of octets after Literal Body normalisation is applied. It is not known whether such a pair of colliding packet sequences might also have different semantics.

IANA Considerations

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: ID Name Embeddable Reference 0x68-0x6E Private or Experimental Use   IANA is requested to update the following existing entries in the registry: ID Name Embeddable Reference 0x10 Generic Certification Signature   , 0x11 Persona Certification Signature (Deprecated)   , 0x12 Casual Certification Signature (Deprecated)   , 0x13 Positive Certification Signature   , 0x19 Primary Key Binding Signature Yes , 0x20 Primary Key Revocation Signature   , 0x40 Timestamp Signature   , 0x50 Third Party Confirmation Signature Yes , ,

OpenPGP Key Flags Registry IANA is requested to register the following new entries in the OpenPGP Key Flags registry: Flag Definition Reference ((TBC)) This key may be used to make signatures in the Primary Key Revocation Category , ((TBC)) This key may be used to make signatures in the Countersignature Category IANA is requested to update the following existing entries in the registry: Flag Definition Reference 0x01.. This key may be used to make signatures over other keys, in the Certification and Certification Revocation Categories. 0x02... This key may be used to make signatures in the Document Signature Category. 0x0008... This key may be used to make signatures in the Timestamping Category.

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 .

This document specifies the message formats used in OpenPGP. OpenPGP provides encryption with public key or symmetric cryptographic algorithms, digital signatures, compression, and key management. This document is maintained in order to publish all necessary information needed to develop interoperable applications based on the OpenPGP format. It is not a step-by-step cookbook for writing an application. It describes only the format and methods needed to read, check, generate, and write conforming packets crossing any network. It does not deal with storage and implementation questions. It does, however, discuss implementation issues necessary to avoid security flaws. This document obsoletes RFCs 4880 ("OpenPGP Message Format"), 5581 ("The Camellia Cipher in OpenPGP"), and 6637 ("Elliptic Curve Cryptography (ECC) in OpenPGP"). In many standards track documents several words are used to signify the requirements in the specification. These words are often capitalized. This document defines these words as they should be interpreted in IETF documents. This document specifies an Internet Best Current Practices for the Internet Community, and requests discussion and suggestions for improvements. RFC 2119 specifies common key words that may be used in protocol specifications. This document aims to reduce the ambiguity by clarifying that only UPPERCASE usage of the key words have the defined special meanings. GnuPG e.V. Ribose { Work in progress to update the OpenPGP specification from RFC4880 } This document specifies the message formats used in OpenPGP. OpenPGP provides encryption with public-key or symmetric cryptographic algorithms, digital signatures, compression and key management. This document is maintained in order to publish all necessary information needed to develop interoperable applications based on the OpenPGP format. It is not a step-by-step cookbook for writing an application. It describes only the format and methods needed to read, check, generate, and write conforming packets crossing any network. It does not deal with storage and implementation questions. It does, however, discuss implementation issues necessary to avoid security flaws. Jabberwocky Tech PGPKeys.EU This document specifies a method in OpenPGP to suggest a replacement for an expired, revoked, or deprecated primary key. ACLU Cryptographic revocation is a hard problem. OpenPGP's revocation mechanisms are imperfect, not fully understood, and not as widely implemented as they could be. Additionally, some historical OpenPGP revocation mechanisms simply do not work in certain contexts. This document provides clarifying guidance on how OpenPGP revocation works, documents outstanding problems, and introduces a new mechanism for delegated revocations that improves on previous mechanism. ACLU An OpenPGP certificate can grow in size without bound when third- party certifications are included. This document describes a way for the owner of the certificate to explicitly approve of specific third- party certifications, so that relying parties can safely prune the certificate of any unapproved certifications. Jabberwocky Tech PGPKeys.EU This document specifies a series of conventions to implement an OpenPGP keyserver using the Hypertext Transfer Protocol (HTTP). As this document is a codification and extension of a protocol that is already in wide use, strict attention is paid to backward compatibility with these existing implementations. g10 Code GmbH Ribose This document specifies the message formats used in LibrePGP. LibrePGP is an extension of the OpenPGP format which provides encryption with public-key or symmetric cryptographic algorithms, digital signatures, compression and key management. This document is maintained in order to publish all necessary information needed to develop interoperable applications based on the LibrePGP format. It is not a step-by-step cookbook for writing an application. It describes only the format and methods needed to read, check, generate, and write conforming packets crossing any network. It does not deal with storage and implementation questions. It does, however, discuss implementation issues necessary to avoid security flaws. This document is based on: RFC 4880 (OpenPGP), RFC 5581 (Camellia in OpenPGP), and RFC 6637 (Elliptic Curves in OpenPGP). This document describes the format of "PGP files", i.e., messages that have been encrypted and/or signed with PGP. This memo provides information for the Internet community. This memo does not specify an Internet standard of any kind. This document is maintained in order to publish all necessary information needed to develop interoperable applications based on the OpenPGP format. [STANDARDS-TRACK] This document is maintained in order to publish all necessary information needed to develop interoperable applications based on the OpenPGP format. It is not a step-by-step cookbook for writing an application. It describes only the format and methods needed to read, check, generate, and write conforming packets crossing any network. It does not deal with storage and implementation questions. It does, however, discuss implementation issues necessary to avoid security flaws. OpenPGP software uses a combination of strong public-key and symmetric cryptography to provide security services for electronic communications and data storage. These services include confidentiality, key management, authentication, and digital signatures. This document specifies the message formats used in OpenPGP. [STANDARDS-TRACK]

Acknowledgments This document would not have been possible without the extensive work of the authors of . The author would also like to thank Daniel Kahn Gillmor, Justus Winter and Paul Schaub for additional discussions and suggestions.