]> PGPKeys.EU

andrewg@andrewg.com

int openpgp Internet-Draft This document reserves entries 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 values 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 51 0x33 2 58 0x3a 3 68 0x44 4 75 0x4b 5 85 0x55 6 92 0x5c 7 119 0x77 8 126 0x7e 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, and the division of the registry into critical and non-critical ranges, most PGP-GREASE values cannot be used as Packet Types. In addition, implementations pre-dating are not required to ignore unknown non-critical packet types. A Marker packet () SHOULD therefore be used instead. Packet Types 51 and 58 MAY be used if it is known, or it is reasonable to expect, that the receiving implementation supports . To avoid any potential ambiguity, no PGP-GREASE code points have been assigned in the Private and Experimental range. Note also that currently uses signature version 23 as a de-facto GREASE code point.

Reservation of PGP-GREASE Flag Bits We assign the following flag bits to PGP-GREASE: Sequence Flag Bit 1 0x40... 2 0x0020... 3 0x000010... 4 0x00000008... These flag bits will be reserved for PGP-GREASE in the following registries: Registry Name Notes OpenPGP Keyserver Preference Flags (1) OpenPGP Features Flags   OpenPGP Key Flags   OpenPGP Notation Flags   states that undefined Keyserver Flags "MUST be zero", but self-signatures containing undefined Keyserver Flags are not known to be rejected by any receiving implementation; we therefore interpret this narrowly, to mean only that undefined Keyserver Flags MUST be set to zero by the generating implementation. A receiving implementation MUST ignore unknown flag bits. Notation Flags are limited to four octets, while the other registries permit unlimited numbers of flag octets. No PGP-GREASE flag bits have been allocated outside the range of Notation Flags.

Usage of PGP-GREASE Code Points and Flag Bits An implementation MAY insert dummy packets or subpackets into otherwise valid packet sequences. It MAY also include PGP-GREASE values 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 PGP-GREASE values deterministically, while ensuring that all PGP-GREASE values are eventually used. (TODO: how often should we add GREASE?) A receiving implementation MUST gracefully ignore unknown code points or flag bits when required to by , including PGP-GREASE. It MUST NOT treat PGP-GREASE values any differently from other unknown values; this includes detecting or indicating the presence of PGP-GREASE. PGP-GREASE MAY be used in either certificates or messages. Since existing legacy implementations have not consistently followed the requirement to ignore unknown code points or flag bits, a generating implementation is RECOMMENDED to introduce PGP-GREASE 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 values in the following certificate contexts: Dummy algorithm IDs in algorithm-preference signature subpackets (subpacket types 11, 21, 22, and 39). Dummy flags in keyserver preferences, feature flags, key flags, and notation subpackets. 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 values 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.

Private and Experimental Ranges Unlike PGP-GREASE reservations, code points in the Private and Experimental ranges MAY be treated specially by a receiving implementation. This MAY include emitting an explicit warning that an unknown code point in the Private and Experimental range has been encountered. To simplify the recognition of Private and Experimental code points, each Private and Experimental range in the OpenPGP group of registries will be expanded to cover the code points 96-111, i.e. 0x60-0x6f. Aligning this range to nybble boundaries will allow the use of a bit mask, and will provide additional Private and Experimental code points for future use.

Security Considerations Legacy implementations that do not properly ignore unknown code points or flag bits 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 values 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 description "Reserved (PGP-GREASE)" and a reference pointing to this document. IANA is requested to allocate the flag bits listed in in each of the registries listed in , with the description "Reserved (PGP-GREASE)" and a reference pointing to this document. IANA is also requested to allocate code points 51 and 58 in the "OpenPGP Packet Types" registry, with the description "Reserved (PGP-GREASE)" and a reference pointing to this document. IANA is also requested to adjust the extent of the Private and Experimental range in each of the registries listed in , from "100-110" to "96-111".

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 GREASEy code points, and Daniel Kahn Gillmor for GREASEy flag bits.

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

Changes Between draft-gallagher-openpgp-grease-00 and draft-gallagher-openpgp-grease-01 Moved code points. Expanded private and experimental ranges. Added flag bits.