]> PGPKeys.EU

andrewg@andrewg.com

int openpgp Internet-Draft This document specifies several updates and clarifications to the grammar and semantics of OpenPGP messages. 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 messages have a complex grammar and sometimes poorly-understood semantics. 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. This document does not specify any new wire formats.

Conventions and Definitions 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.

Signed Messages There are two forms of signed message in OpenPGP. In a prefix-signed message, the Signature packet or packets precede the signed data. In a one-pass signed message, one or more One-Pass Signature packets precede the signed data, and the corresponding Signature packet(s) follow it. 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 sequence of packets, but this usage is deprecated . See for an alternative construction. 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 not signed over by the current OPS. 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. 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, however it is not clear whether any current implementation supports this. This is further expanded in . This still leaves us with an overly complex grammar that resists rigorous formalization. We attempt to improve the formalism below.

Prefix-Signed Message Constraints Prefixed signatures are deprecated, and their use is hereby restricted: A prefixed Signature packet MUST be followed by one Literal Data packet and no other packets except further prefixed Signature packets, and Marker packets. A prefixed Signature packet MUST NOT have a version number greater than 4. Prefixed signatures SHOULD NOT be generated, but MAY be interpreted. A receiving implementation MAY convert a prefixed signature to the equivalent OPS signature, by moving the signature after the Literal Data packet and prefixing an appropriate OPS packet.

OPS Message Constraints We constrain OPS structures to a subset of previously-allowed configurations: Prefixed signatures and OPS signatures MUST NOT both be used in the same message. When generating an OPS packet that is followed by another OPS packet, the nesting octet SHOULD be set to 0. Otherwise, the nesting octet SHOULD be set to 1. When consuming an OPS packet, the nesting octet MUST be ignored. This effectively deprecates the nesting octet, while maintaining backwards compatibility with legacy code.

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 or Timestamping categories () 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. The format, filename and timestamp fields are discarded. 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 (). If the Cleartext Signature Framework is being used, dash-escaping is also applied (see ). 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 . A signature of Type 0x01 MUST NOT be made over arbitrary binary data, only over UTF-8 text.

Line Ending Normalization When normalizing line endings, only bare linefeeds (an LF control character that is not preceded by a CR) are normalized to CRLF. In particular, bare carriage returns MUST NOT be converted to CRLF. Instead, carriage returns SHOULD be treated as horizontal whitespace, similarly to tab characters. This means that a carriage return at the end of a signed message, if not followed by a linefeed, SHOULD be stripped.

Signatures over Signed Messages It has been previously suggested (for example in ) that a non-zero nesting octet in a non-innermost OPS packet might be used to sign over an already-signed message, including some or all of its signatures. This construction has never been formally specified, and such a message SHOULD NOT be created. A receiving implementation that follows the guidance in [ops-message-constraints] will automatically invalidate some or all of its 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(s) 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(s) will no longer validate.

Formal Grammar The message grammar in is therefore updated to: 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 Session Key)*, Encrypted Data. Prefixed Signed Message:
(Signature Packet)+, Literal Data Packet. One-Pass Signed Message:
(OPS Packet (nest=0)){n>=0}, OPS Packet (nest=1), Literal Data Packet, (Signature Packet){n+1}. Signed Message:
Prefixed Signed Message | One-Pass Signed Message. Optionally Signed Message:
Signed Message | Literal Data Packet. Unencrypted Message:
Compressed Data Packet | Optionally Signed Message. Optionally Padded Unencrypted Message:
Unencrypted Message, (Padding Packet)*. OpenPGP Message:
Encrypted Message | Unencrypted Message. In addition to these rules, a Marker packet () can appear anywhere in the sequence. In a One-Pass Signed Message, the OPS packets and Signature packets SHOULD appear in bracketed pairs, as per . If a Signature packet does not match its corresponding OPS packet, then that particular signature is invalid but the entire packet sequence SHOULD NOT be rejected.

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 MUST 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 Optionally Signed Message.

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 also include: If a receiving implementation encounters a Marker Packet with any other contents, it is "a critical packet where the packet type is unknown", and the entire sequence MUST be rejected. See . 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.

Security Considerations The OPS nesting octet is not signed over and is malleable in principle. An intermediary could swap an outer OPS with its inner OPS by also swapping the nesting octets. The order of OPS nesting therefore MUST NOT be considered meaningful. In addition, the normalization applied during Literal Data 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 Data normalization is applied. It is not known whether such a pair of colliding packet sequences might also have different semantics.

IANA Considerations

OpenPGP Packet Types Registry IANA is requested to update the following existing entries in the registry, to add a reference to this document: Marker Packet OPS Packet

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"). PGPKeys.EU This document specifies several updates and clarifications to the grammar and semantics of OpenPGP signatures. 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.

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

Document History Note to RFC Editor: this section should be removed before publication.

Changes Between draft-gallagher-openpgp-messages-00 and draft-gallagher-openpgp-messages-01 Added missing dash-escape step in type-specific data. Clarified treatment of trailing carriage return characters. Reworked formal grammar to be more human-readable.