OpenPGP Message Grammar

Status of This Memo

This Internet-Draft is submitted in full conformance with the provisions of BCP 78 and BCP 79.¶

Internet-Drafts are working documents of the Internet Engineering Task Force (IETF). Note that other groups may also distribute working documents as Internet-Drafts. The list of current Internet-Drafts is at https://datatracker.ietf.org/drafts/current/.¶

Internet-Drafts are draft documents valid for a maximum of six months and may be updated, replaced, or obsoleted by other documents at any time. It is inappropriate to use Internet-Drafts as reference material or to cite them other than as "work in progress."¶

This Internet-Draft will expire on 6 December 2026.¶

Copyright Notice

Copyright (c) 2026 IETF Trust and the persons identified as the document authors. All rights reserved.¶

This document is subject to BCP 78 and the IETF Trust's Legal Provisions Relating to IETF Documents (https://trustee.ietf.org/license-info) in effect on the date of publication of this document. Please review these documents carefully, as they describe your rights and restrictions with respect to this document. Code Components extracted from this document must include Revised BSD License text as described in Section 4.e of the Trust Legal Provisions and are provided without warranty as described in the Revised BSD License.¶

Table of Contents

1. Introduction

OpenPGP messages have a complex grammar and sometimes poorly-understood semantics. This document attempts to address this by:¶

• Expanding on specifications where [RFC9580] does not fully describe the existing or expected behaviour of deployed implementations.¶

• Adding clarification where deployed implementations differ in their interpretation of [RFC9580] and its predecessors.¶

• Deprecating unused or error-prone features.¶

This document does not specify any new wire formats.¶

2. 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 [RFC2119] [RFC8174] when, and only when, they appear in all capitals, as shown here.¶

3. Signed Messages

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 [RFC9580]. Historically, PGP 2.X treated a prefixed Signature packet as applying to the entire following sequence of packets, but this usage is deprecated [FINNEY1998]. See Section 3.4 for an alternative construction.¶

In addition, One-Pass Signature (OPS) nesting semantics are complex, and under-specified [SCHAUB2022]. Section 5.4 of [RFC9580] 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 [OPENPGPDEVBOOK].¶

This still leaves us with an overly complex grammar that resists rigorous formalization. We attempt to improve the formalism below.¶

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

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

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

7. IANA Considerations

8. References

Appendix A. Acknowledgments

This document would not have been possible without the extensive work of the authors of [OPENPGPDEVBOOK].¶

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

Author's Address