Code Point Exhaustion in OpenPGP

4.1. UTF-8ish Encoding

For registries other than subpacket types or packet types, we use a similar encoding scheme to UTF-8, but with two- and four-octet encodings omitted, i.e.:¶

if the 1st octet <  128, then
    lengthOfEncoding = 1
    codePoint = 1st_octet

if the 1st octet >= 224 and < 240, then
   lengthOfEncoding = 3
    codePoint = ((1st_octet - 224) << 12) + ((2nd_octet - 128) << 6) + (3rd_octet - 128)

if the 1st octet >= 240, then
    lengthOfEncoding = 1
    codePoint = 1st_octet

The second and third octets MUST be >= 128 and < 192. This ensures that none of the octets in a multi-octet encoding can be incorrectly interpreted as a single-octet encoding of another code point. This means that strings of multi-octet code points are self-synchronising.¶

• single-octet encodings have an octet value < 128 and are fully backwards compatible¶

• octet values in the range 192..223 correspond to the first octet of two-octet UTF-8 encodings and MUST NOT be used¶

• three-octet encodings have a first octet in the range 224..239, and represent code points in the range 128..65535¶

• octet values in the range 240..247 correspond to the first octet of four-octet UTF-8 encodings and MUST NOT be used¶

• legacy single-octet encodings have an octet value in the range 248..255¶

• overlong encodings MUST NOT be used¶

We reserve initial octet values in the range 248..255, which are not used in UTF-8, for legacy single-octet encodings of code points with the same values. This ensures backwards compatibility of existing secret key encryption (S2K Usage) code points. Since Secret Key Encryption code points in this range are in current use, they MUST be represented by legacy single-octet encodings. Legacy single-octet encodings MUST NOT be used in any other context. The corresponding code points 248..255 will be reserved in the Symmetric Encryption Algorithms registry to avoid ambiguity.¶

The top half of the extended range (code points 32768..65535) is reserved for additional private and experimental use code points in registries that already contain a private and experimental use range.¶

Two- and four-octet encodings are not used, for the reasons outlined in Section 5.3.4 below.¶

4.2. Subpacket Type Encoding

The criticality bit means that the first octet of any multi-octet signature subpacket type encoding is effectively limited to values less than 128. We therefore cannot use UTF-8ish encoding for signature subpacket types, and cannot make use of its self-synchronisation properties. Luckily, subpacket types are only found as the second field of a subpacket, immediately after the packet length, so self-synchronisation is not required.¶

Code point 127 is reserved as a surrogate code point to indicate that the actual subpacket type is encoded in the following two octets.¶

The standard subpacket type encoding (including criticality bit) continues to represent code points 0..126 as usual, as well as the surrogate code point 127. Surrogate subpacket type encoding is used to represent code points 128..65535, and MUST NOT be used to represent code points 0..127.¶

The criticality bit is the most significant bit of the first octet when surrogate encoding is used, but applies to the specific subpacket type being encoded, not the use of 127 as a surrogate code point.¶

The top half of the extended range (code points 32768..65535) is reserved for additional private or experimental use code points.¶

For consistency, User Attribute Subpackets use the same surrogate encoding format as Signature Subpackets, even though they don't have a criticality bit. The most significant bit of the surrogate octet is therefore always 0.¶

4.3. Packet Type Encoding

It may eventually become necessary to also expand the Packet Type registry, which currently has 24 of 64 possible entries allocated. The encoding space is highly restricted due to the small number of free bits available in the OpenPGP packet framing.¶

Code point 16 was initially intended to indicate a "comment" packet but was never used, and is not encodable in Legacy packet framing. We therefore reserve it as a surrogate code point to indicate that the actual packet type is encoded in the two octets immediately following the length field.¶

The OpenPGP packet type encoding continues to represent code points 0..63 as usual, including the surrogate code point 16. Surrogate packet type encoding is used to represent code points 64..65535, and MUST NOT be used to represent code points 0..63.¶

Code points in the range 64..16383 represent non-critical packets. Code points in the range 16384..32767 represent critical packets. The top half of the extended range (code points 32768..65535) is reserved for additional private or experimental use code points.¶

5.1. v6 Key Material Packets

After the packet version identifier, a v6 key material packet contains the following fields:¶

• Creation time¶

• Public key algorithm¶

• Length of public key material¶

It is therefore theoretically possible for a continuation octet of a UTF-8ish encoding of the public key algorithm to be misinterpreted as the first octet of the following length parameter, resulting in a mis-parsing of the remaining packet data, and a possible out of bounds read. This introduces no new vulnerabilities however, as an attacker can already create a key material packet with an incorrect "length of public key material" parameter, and so a compliant implementation SHOULD already have protections against out of bounds read of the remaining packet.¶

A secret key material packet further contains a Secret Key Encryption (S2K Usage) parameter, followed by variable fields that cannot be parsed if the Secret Key Encryption parameter is not supported. These variable fields may include an S2K specifier, which always begins with an S2K specifier type. The remainder of the S2K specifier cannot be parsed if the S2K specifier type is not supported.¶

UTF-8ish encodings are therefore safe in v6 key material packets.¶

5.2. v6 Signature Packets

After the packet version identifier, a v6 signature packet contains a string of three potentially UTF-8ish code point fields:¶

• Signature Type ID¶

• public key algorithm¶

• hash algorithm¶

The remainder of the packet cannot be parsed if the public key and hash algorithm code points are unsupported, and a signature digest cannot be constructed if the signature type is unsupported.¶

The trailer contains the same UTF-8ish fields, however the following features prevent malleability:¶

• The trailer contains a length field that covers the UTF-8ish fields.¶

• All octets used in UTF-8ish encoding map to currently unassigned octet values.¶

UTF-8ish encodings are therefore safe in v6 signature packets.¶

5.3. Signature Subpackets

Signature subpackets are prefixed by a length and a type parameter. The remainder of each subpacket cannot be parsed if the type parameter is not supported.¶

The same considerations apply to User Attribute Subpackets, as they are constructed identically.¶

UTF-8ish and surrogate encodings are generally safe in subpackets, subject to constraints:¶

5.4. v6 One-Pass Signature Packets

After the packet version identifier, a v6 OPS packet contains a string of three potentially UTF-8ish code point fields:¶

• Signature type ID¶

• Hash algorithm¶

• Public key algorithm¶

The remainder of the packet cannot be parsed if the hash algorithm code point is unsupported.¶

UTF-8ish encodings are therefore safe in v6 OPS packets.¶

5.5. v6 PKESK Packets

A v6 PKESK packet contains two potentially UTF-8ish code point fields, the fingerprint version number and the algorithm identifier. The fingerprint version is covered by a preceding length field that allows unsupported fingerprints to be safely skipped. The algorithm identifier is immediately followed by a variable-length field that cannot be parsed if the algorithm is unsupported.¶

UTF-8ish encodings are therefore safe in v6 PKESK packets.¶

5.6. v6 SKESK Packets

A v6 SKESK packet contains the following fields:¶

• Symmetric algorithm ID¶

• AEAD algorithm ID¶

• S2K specifier length¶

• S2K specifier¶

• An initialisation value¶

All five fields are covered by a preceding length field, and the string-to-key specifier is further covered by its own length field. The S2K specifier always begins with an S2K specifier type, and the remainder of the S2K specifier cannot be parsed if the S2K specifier type is not supported. The length of the initialisation value depends on the AEAD algorithm, and therefore cannot be parsed if the AEAD algorithm is not supported.¶

Secret Key Encryption (S2K Usage) parameters are not supplied in a v6 SKESK, as AEAD mode is always used.¶

UTF-8ish encodings are therefore safe in v6 SKESK packets.¶

5.7. Image Attribute Subpackets

Image Attribute Subpackets are prefixed by the following fields:¶

• Header length (2 octets)¶

• Image Attribute Version¶

• Image Attribute Type¶

The remainder of the subpacket cannot be parsed if the version and type are not supported.¶

UTF-8ish encodings are therefore safe in Image Attribute subpackets.¶

5.8. v2 SEIPD Packets

After the packet version identifier, a v2 SEIPD packet contains the following fields:¶

• Symmetric cipher algorithm ID¶

• AEAD algorithm identifier¶

• A 1-octet chunk size¶

• 32 octets of salt¶

• Encrypted data (variable length)¶

If the values of the symmetric cipher algorithm and the AEAD algorithm were not checked immediately, it might be possible for legacy code to misidentify the field boundaries and pass incorrectly bounded fields to the HKDF function. Even if this were the case, the decryption process would not be able to proceed any further without the symmetric and AEAD algorithms being supported, so it is highly unlikely that any information could be leaked to an attacker.¶

UTF-8ish encodings are therefore almost certainly safe in v2 SEIPD packets.¶

5.9. Compressed Data Packets

A compressed data packet consists of a compression algorithm ID followed by data that cannot be parsed if the compression algorithm is unsupported.¶

UTF-8ish encodings are therefore safe in compressed data packets.¶