]> PGPKeys.EU

andrewg@andrewg.com

int openpgp Internet-Draft This document reserves code points in various OpenPGP registries for use in interoperability testing, by analogy with GREASE in TLS. 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 GREASE is an existing specification to ensure forwards compatibility of assigned code points in TLS. We wish to specify a similar mechanism for OpenPGP. This will be particularly useful in the OpenPGP Interoperability Test Suite , but is not restricted to controlled environments. It is expected that implementations will include PGP-GREASE code points in real-world artifacts on an ongoing basis, to encourage forwards-compatible coding across multiple implementations.

Conventions and Definitions The term "OpenPGP Certificate" is used in this document interchangeably with "OpenPGP Transferable Public Key", as defined in . For avoidance of confusion with GREASE in TLS, we will use the term "PGP-GREASE" for the equivalent mechanism in OpenPGP. 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.

Reservation of PGP-GREASE Code Points We assign the following one-octet code points to PGP-GREASE: Sequence Code Point (Decimal) Code Point (Hexadecimal) 1 123 0x7b 2 44 0x2c 3 55 0x37 4 66 0x42 5 77 0x4d 6 88 0x58 7 99 0x63 8 111 0x6f These code points will be reserved for PGP-GREASE in the following registries: Registry Name Notes OpenPGP String-to-Key (S2K) Types (1) OpenPGP User Attribute Subpacket Types   OpenPGP Image Attribute Encoding Format   OpenPGP Signature Subpacket Types (2) OpenPGP Reason for Revocation (Revocation Octet) (1) OpenPGP Public Key Algorithms   OpenPGP Symmetric Key Algorithms   OpenPGP Hash Algorithms   OpenPGP Compression Algorithms   OpenPGP Secret Key Encryption (S2K Usage Octet) (3) OpenPGP Signature Types   OpenPGP Image Attribute Versions   OpenPGP AEAD Algorithms   OpenPGP Key and Signature Versions   The use of PGP-GREASE code points in the String-to-Key Types and Reason for Revocation registries is not currently specified, however the code points will be reserved for consistency. When PGP-GREASE code points from the Signature Subpacket Types registry are used, the critical bit MUST NOT be set. All code points allocated in the Symmetric Key Algorithms registry are automatically also allocated in the S2K Usage Octet registry. Due to the smaller number of allocatable code points (63) in the OpenPGP Packet Types registry, most PGP-GREASE values cannot be used as Packet Types. In addition, implementations pre-dating are not required to ignore unknown packet types. A Marker packet () SHOULD therefore be used instead. Packet Types 44 and 55 MAY be used if it is known that the receiving implementation supports . Note that currently uses signature version 23 as a de-facto GREASE code point. This is intentionally not included here, as we prefer code points that are available for reservation across multiple registries.

Usage of PGP-GREASE Code Points An implementation MAY insert dummy packets or subpackets into otherwise valid packet sequences. It MAY also include dummy code points in preference lists. The data section of dummy packets and subpackets SHOULD contain only the ten octets "PGP-GREASE", in UTF-8 encoding. All other fields of dummy packets and subpackets SHOULD correspond to those of a real packet or subpacket. A generating implementation SHOULD choose code points deterministically, while ensuring that all PGP-GREASE code points are eventually used. (TODO: how often should we add GREASE?) A receiving implementation MUST gracefully ignore unknown code points when required to by , including PGP-GREASE code points. It MUST NOT treat PGP-GREASE code points any differently from other unknown code points; this includes detecting or indicating the presence of PGP-GREASE code points. PGP-GREASE codepoints MAY be used in either certificates or messages. Since existing legacy implementations have not consistently followed the requirement to ignore unknown code points, a generating implementation is RECOMMENDED to introduce PGP-GREASE code points gradually, over several release cycles. This should ensure that legacy receiving implementations are not overwhelmed by errors in a short period of time.

Certificates An implementation MAY use PGP-GREASE codepoints in the following certificate contexts: Dummy algorithm IDs in algorithm-preference signature subpackets (subpacket types 11, 21, 22, and 39). Signature subpacket IDs of dummy signature subpackets, in either the hashed or unhashed area. User attribute subpacket types, versions and encoding formats of dummy user attribute subpackets. Packet versions and algorithm IDs in dummy subkey packets. Signature and hash algorithm IDs and signature version numbers in dummy third-party certification signatures. Hash algorithm IDs in dummy self-signatures. Packet and signature types in dummy packets. A generating implementation MAY also generate dummy primary keys with PGP-GREASE version numbers or algorithm IDs.

Messages An implementation MAY use PGP-GREASE codepoints in the following message contexts: Signature subpacket IDs of dummy signature subpackets in the hashed or unhashed signature subpacket area. Signature and hash algorithm IDs and signature version numbers in dummy document signature packets and their corresponding OPS packets. Packet and signature types in dummy packets. Note that when an OPS packet is present, any PGP-GREASE code points it contains MUST be duplicated in the corresponding signature packet.

Security Considerations Legacy implementations that do not properly ignore unknown code points will experience failures; this is intentional. None of these failures should have security consequences in themselves, unless other coding errors are present in the legacy implementation. While this should result in increased security in the long term, exposing such bugs may cause problems in the short term. Generating implementations are therefore RECOMMENDED to be cautious in deploying PGP-GREASE initially. In particular, implementations SHOULD NOT generate PGP-GREASE code points in production unless they have been tested first in a controlled environment such as the Interoperability Test Suite .

IANA Considerations IANA is requested to allocate the code points listed in in each of the registries listed in , with the note "Reserved (PGP-GREASE)" and a reference pointing to this document. IANA is also requested to allocate code points 44 and 55 in the "OpenPGP Packet Types" registry, with the note "Reserved (PGP-GREASE)" and a reference pointing to this document.

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. This document describes GREASE (Generate Random Extensions And Sustain Extensibility), a mechanism to prevent extensibility failures in the TLS ecosystem. It reserves a set of TLS protocol values that may be advertised to ensure peers correctly handle unknown values.

Acknowledgments The author would like to thank Daniel Huigens for inspiring this work.