1.1. Terms

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

The key words "Private Use", "Specification Required", and "RFC Required" that appear in this document when used to describe namespace allocation are to be interpreted as described in [RFC8126].¶

Some terminology used in this document has been improved from previous versions of the OpenPGP specification. See Appendix B.1 for more details.¶

2.1. Confidentiality via Encryption

OpenPGP combines symmetric-key encryption and (optionally) public-key encryption to provide confidentiality. When using public keys, first the object is encrypted using a symmetric encryption algorithm. Each symmetric key is used only once, for a single object. A new "session key" is generated as a random number for each object (sometimes referred to as a "session"). Since it is used only once, the session key is bound to the message and transmitted with it. To protect the key, it is encrypted with the receiver's public key. The sequence is as follows:¶

1. The sender creates a message.¶
2. The sending OpenPGP implementation generates a random session key for this message.¶
3. The session key is encrypted using each recipient's public key. These "encrypted session keys" start the message.¶
4. The sending OpenPGP implementation optionally compresses the message and then encrypts it using a message key derived from the session key. The encrypted message forms the remainder of the OpenPGP message.¶
5. The receiving OpenPGP implementation decrypts the session key using the recipient's private key.¶
6. The receiving OpenPGP implementation decrypts the message using the message key derived from the session key. If the message was compressed, it will be decompressed.¶

When using symmetric-key encryption, a similar process as described above is used, but the session key is encrypted with a symmetric algorithm derived from a shared secret.¶

Both digital signature and confidentiality services may be applied to the same message. First, a signature is generated for the message and attached to the message. Then, the message plus signature is encrypted using a symmetric message key derived from the session key. Finally, the session key is encrypted using public-key encryption and prefixed to the encrypted block.¶

2.2. Authentication via Digital Signature

The digital signature uses a cryptographic hash function and a public-key signature algorithm. The sequence is as follows:¶

1. The sender creates a message.¶
2. The sending implementation generates a hash digest of the message.¶
3. The sending implementation generates a signature from the hash digest using the sender's private key.¶
4. The signature is attached to or transmitted alongside the message.¶
5. The receiving implementation obtains a copy of the message and the message signature.¶
6. The receiving implementation generates a new hash digest for the received message and verifies it using the message's signature. If the verification is successful, the message is accepted as authentic.¶

2.3. Compression

An OpenPGP implementation MAY support the compression of data. Many existing OpenPGP messages are compressed. Implementers, such as those working on constrained implementations that do not want to support compression, might want to consider at least implementing decompression.¶

2.4. Conversion to Base64

OpenPGP's underlying native representation for encrypted messages, signatures, keys, and certificates is a stream of arbitrary octets. Some systems only permit the use of blocks consisting of seven-bit, printable text. For transporting OpenPGP's native raw binary octets through channels that are not safe to transport raw binary data, a printable encoding of these binary octets is defined. The raw 8-bit binary octet stream can be converted to a stream of printable ASCII characters using base64 encoding in a format called "ASCII Armor" (see Section 6).¶

Implementations SHOULD support base64 conversions.¶

2.5. Signature-Only Applications

OpenPGP is designed for applications that use both encryption and signatures, but there are a number of use cases that only require a signature-only implementation. Although this specification requires both encryption and signatures, it is reasonable for there to be subset implementations that are non-conformant only in that they omit encryption support.¶

3.1. Scalar Numbers

Scalar numbers are unsigned and always stored in big-endian format. Using n[k] to refer to the kth octet being interpreted, the value of a two-octet scalar is ((n[0] << 8) + n[1]). The value of a four-octet scalar is ((n[0] << 24) + (n[1] << 16) + (n[2] << 8) + n[3]).¶

3.2. Multiprecision Integers

Multiprecision Integers (MPIs) are unsigned integers used to hold large integers such as the ones used in cryptographic calculations.¶

An MPI consists of two pieces: a two-octet scalar that is the length of the MPI in bits, followed by a string of octets that contain the actual integer.¶

These octets form a big-endian number; a big-endian number can be made into an MPI by prefixing it with the appropriate length.¶

Examples:¶

(Note that all numbers in the octet strings identified by square brackets are in hexadecimal.)¶

• The string of octets [00 00] forms an MPI with the value 0.¶
• The string of octets [00 01 01] forms an MPI with the value 1.¶
• The string [00 09 01 FF] forms an MPI with the value 511.¶

Additional rules:¶

• The size of an MPI is ((MPI.length + 7) / 8) + 2 octets.¶
• The length field of an MPI describes the length starting from its most significant non-zero bit. Thus, the MPI [00 02 01] is not formed correctly. It should be [00 01 01]. When parsing an MPI in a v6 Key, Signature, or Public-Key Encrypted Session Key (PKESK) packet, the implementation MUST check that the encoded length matches the length starting from the most significant non-zero bit; if it doesn't match, reject the packet as malformed.¶
• Unused bits of an MPI MUST be zero.¶

3.3. Key IDs and Fingerprints

A Key ID is an eight-octet scalar that identifies a key. Implementations SHOULD NOT assume that Key IDs are unique. A fingerprint is more likely to be unique than a key ID. The fingerprint and key ID of a key are calculated differently according to the version of the key.¶

Section 5.5.4 describes how Key IDs and Fingerprints are formed.¶

3.4. Text

Unless otherwise specified, the character set for text is the UTF-8 [RFC3629] encoding of Unicode [ISO10646].¶

3.5. Time Fields

A time field is an unsigned four-octet number containing the number of seconds elapsed since midnight, 1 January 1970 UTC.¶

3.6. Keyrings

A keyring is a collection of one or more keys in a file or database. Traditionally, a keyring is simply a sequential list of keys, but it may be any suitable database. It is beyond the scope of this specification to discuss the details of keyrings or other databases.¶

3.7. String-to-Key (S2K) Specifier

A string-to-key (S2K) specifier type is used to convert a passphrase string into a symmetric-key encryption/decryption key. Passphrases requiring use of S2K conversion are currently used in two places: to encrypt the secret part of private keys and for symmetrically encrypted messages.¶

  Octet 0:        0x00
  Octet 1:        hash algorithm

  Octet 0:        0x01
  Octet 1:        hash algorithm
  Octets 2-9:     8-octet salt value

  Octet  0:        0x03
  Octet  1:        hash algorithm
  Octets 2-9:      8-octet salt value
  Octet  10:       count; a one-octet coded value

  #define EXPBIAS 6
      count = ((Int32)16 + (c & 15)) << ((c >> 4) + EXPBIAS);

  Octet  0:        0x04
  Octets 1-16:     16-octet salt value
  Octet  17:       one-octet number of passes t
  Octet  18:       one-octet degree of parallelism p
  Octet  19:       one-octet encoded_m, specifying the exponent of
                      the memory size

  04 XX XX XX XX XX XX XX XX XX XX XX XX XX XX XX
  XX 01 04 15

4.1. Overview

An OpenPGP message is constructed from a number of records that are traditionally called packets. A packet is a chunk of data that has a type ID specifying its meaning. An OpenPGP message, keyring, certificate, detached signature, and so forth consists of a number of packets. Some of those packets may contain other OpenPGP packets (for example, a compressed data packet, when uncompressed, contains OpenPGP packets).¶

Each packet consists of a packet header, followed by the packet body. The packet header is of variable length.¶

When handling a stream of packets, the length information in each packet header is the canonical source of packet boundaries. An implementation handling a packet stream that wants to find the next packet MUST look for it at the precise offset indicated in the previous packet header.¶

Additionally, some packets contain internal length indicators (for example, a subfield within the packet). In the event that a subfield length indicator within a packet implies inclusion of octets outside the range indicated in the packet header, a parser MUST abort without writing outside the indicated range and MUST treat the packet as malformed and unusable.¶

An implementation MUST NOT interpret octets outside the range indicated in the packet header as part of the contents of the packet.¶

4.2. Packet Headers

The first octet of the packet denotes the format of the rest of the header, and it encodes the Packet Type ID, indicating the type of the packet (see Section 5). The remainder of the packet header is the length of the packet.¶

There are two packet formats: 1) the (current) OpenPGP packet format specified by this document and its predecessors [RFC4880] and [RFC2440] and 2) the Legacy packet format as used by implementations predating any IETF specification of the protocol.¶

Note that the most significant bit is the leftmost bit, called "bit 7". A mask for this bit is 0x80 in hexadecimal.¶

                          +---------------+
  Encoded Packet Type ID: |7 6 5 4 3 2 1 0|
                          +---------------+
  OpenPGP format:
    Bit 7 -- always one
    Bit 6 -- always one
    Bits 5 to 0 -- packet type ID

  Legacy format:
    Bit 7 -- always one
    Bit 6 -- always zero
    Bits 5 to 2 -- packet type ID
    Bits 1 to 0 -- length-type

Bit 6 of the first octet of the packet header indicates whether the packet is encoded in the OpenPGP or Legacy packet format. The Legacy packet format MAY be used when consuming packets to facilitate interoperability and accessing archived data. The Legacy packet format SHOULD NOT be used to generate new data, unless the recipient is known to only support the Legacy packet format. This latter case is extremely unlikely, as the Legacy packet format was obsoleted by [RFC2440] in 1998.¶

An implementation that consumes and redistributes pre-existing OpenPGP data (such as Transferable Public Keys) may encounter packets framed with the Legacy packet format. Such an implementation MAY either redistribute these packets in their Legacy format or transform them to the current OpenPGP packet format before redistribution.¶

Note that Legacy format headers only have 4 bits for the packet type ID and hence can only encode packet type IDs less than 16, whereas the OpenPGP format headers can encode IDs as great as 63.¶

  bodyLen = 1st_octet;

  bodyLen = ((1st_octet - 192) << 8) + (2nd_octet) + 192

  bodyLen = (2nd_octet << 24) | (3rd_octet << 16) |
            (4th_octet << 8)  | 5th_octet

  partialBodyLen = 1 << (1st_octet & 0x1F);

4.3. Packet Criticality

The Packet Type ID space is partitioned into critical packets and non-critical packets. If an implementation encounters a critical packet where the packet type is unknown in a packet sequence, it MUST reject the whole packet sequence (see Section 10). On the other hand, an unknown non-critical packet MUST be ignored.¶

Packets with Type IDs from 0 to 39 are critical. Packets with Type IDs from 40 to 63 are non-critical.¶

5.1. Public-Key Encrypted Session Key Packet (Type ID 1)

Zero or more PKESK packets and/or SKESK packets (Section 5.3) precede an encryption container (that is, a Symmetrically Encrypted Integrity Protected Data (SEIPD) packet or -- for historic data -- a Symmetrically Encrypted Data (SED) packet), which holds an encrypted message. The message is encrypted with the session key, and the session key is itself encrypted and stored in the Encrypted Session Key packet(s). The encryption container is preceded by one Public-Key Encrypted Session Key packet for each OpenPGP key to which the message is encrypted. The recipient of the message finds a session key that is encrypted to their public key, decrypts the session key, and then uses the session key to decrypt the message.¶

The body of this packet starts with a one-octet number giving the version number of the packet type. The currently defined versions are 3 and 6. The remainder of the packet depends on the version.¶

The versions differ in how they identify the recipient key and in what they encode. The version of the PKESK packet must align with the version of the SEIPD packet (see Section 10.3.2.1). Any new version of the PKESK packet should be registered in the registry established in Section 10.3.2.1.¶

5.2. Signature Packet (Type ID 2)

A Signature packet describes a binding between some public key and some data. The most common signatures are a signature of a file or a block of text and a signature that is a certification of a User ID.¶

Three versions of Signature packets are defined. Version 3 provides basic signature information, while versions 4 and 6 provide an expandable format with subpackets that can specify more information about the signature.¶

For historical reasons, versions 1, 2, and 5 of the Signature packet are unspecified. Any new Signature packet version should be registered in the registry established in Section 10.3.2.2.¶

An implementation MUST generate a version 6 signature when signing with a version 6 key. An implementation MUST generate a version 4 signature when signing with a version 4 key. Implementations MUST NOT create version 3 signatures; they MAY accept version 3 signatures. See Section 10.3.2.2 for more details about packet version correspondence between keys and signatures.¶

if the 1st octet <  192, then
    lengthOfLength = 1
    subpacketLen = 1st_octet

if the 1st octet >= 192 and < 255, then
    lengthOfLength = 2
    subpacketLen = ((1st_octet - 192) << 8) + (2nd_octet) + 192

if the 1st octet = 255, then
    lengthOfLength = 5
    subpacket length = [four-octet scalar starting at 2nd_octet]

09 02 09 03 13 02

5.3. Symmetric-Key Encrypted Session Key Packet (Type ID 3)

The Symmetric-Key Encrypted Session Key (SKESK) packet holds the symmetric-key encryption of a session key used to encrypt a message. Zero or more Public-Key Encrypted Session Key packets (Section 5.1) and/or Symmetric-Key Encrypted Session Key packets precede an encryption container (that is, a Symmetrically Encrypted Integrity Protected Data packet or -- for historic data -- a Symmetrically Encrypted Data packet) that holds an encrypted message. The message is encrypted with a session key, and the session key is itself encrypted and stored in the Encrypted Session Key packet(s).¶

If the encryption container is preceded by one or more Symmetric-Key Encrypted Session Key packets, each specifies a passphrase that may be used to decrypt the message. This allows a message to be encrypted to a number of public keys, and also to one or more passphrases.¶

The body of this packet starts with a one-octet number giving the version number of the packet type. The currently defined versions are 4 and 6. The remainder of the packet depends on the version.¶

The versions differ in how they encrypt the session key with the passphrase and in what they encode. The version of the SKESK packet must align with the version of the SEIPD packet (see Section 10.3.2.1). Any new version of the SKESK packet should be registered in the registry established in Section 10.3.2.1.¶

5.4. One-Pass Signature Packet (Type ID 4)

The One-Pass Signature packet precedes the signed data and contains enough information to allow the receiver to begin calculating any hashes needed to verify the signature. It allows the Signature packet to be placed at the end of the message so that the signer can compute the entire signed message in one pass.¶

The body of this packet consists of:¶

• A one-octet version number. The currently defined versions are 3 and 6. Any new One-Pass Signature packet version should be registered in the registry established in Section 10.3.2.2.¶

• A one-octet signature type ID. Signature types are described in Section 5.2.1.¶

• A one-octet number describing the hash algorithm used.¶

• A one-octet number describing the public-key algorithm used.¶

• Only for v6 packets, a variable-length field containing:¶

  • A one-octet salt size. The value MUST match the value defined for the hash algorithm as specified in Table 24.¶

  • The salt; a random value of the specified size. The value MUST match the salt field of the corresponding Signature packet.¶

• Only for v3 packets, an eight-octet number holding the Key ID of the signing key.¶

• Only for v6 packets, 32 octets of the fingerprint of the signing key. Since a v6 signature can only be made by a v6 key, the length of the fingerprint is fixed.¶

• A one-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.¶

When generating a one-pass signature, the OPS packet version MUST correspond to the version of the associated signature packet, except for the historical accident that v4 keys use a v3 one-pass signature packet (there is no v4 OPS). See Section 10.3.2.2 for the full correspondence of versions between Keys, Signatures, and One-Pass Signatures.¶

Note that if a message contains more than one one-pass signature, then the Signature packets bracket the message; that is, the first Signature packet after the message corresponds to the last one-pass packet and the final Signature packet corresponds to the first one-pass packet.¶

5.5. Key Material Packets

A key material packet contains all the information about a public or private key. There are four variants of this packet type: two major versions (versions 4 and 6) and two strongly deprecated versions (versions 2 and 3). Consequently, this section is complex.¶

For historical reasons, versions 1 and 5 of the key packets are unspecified.¶

def curve25519Legacy_MPI_from_random(octet_list):
    octet_list[0] &= 248
    octet_list[31] &= 127
    octet_list[31] |= 64
    mpi_header = [ 0x00, 0xFF ]
    return mpi_header || reversed(octet_list)

5.6. Compressed Data Packet (Type ID 8)

The Compressed Data packet contains compressed data. Typically, this packet is found as the contents of an encrypted packet, or following a Signature or One-Pass Signature packet, and contains a literal data packet.¶

The body of this packet consists of:¶

• One octet that gives the algorithm used to compress the packet.¶

• Compressed data, which makes up the remainder of the packet.¶

A Compressed Data packet's body contains data that is a compression of a series of OpenPGP packets. See Section 10 for details on how messages are formed.¶

A ZIP-compressed series of packets is compressed into raw DEFLATE blocks [RFC1951].¶

A ZLIB-compressed series of packets is compressed with raw ZLIB-style blocks [RFC1950].¶

A BZip2-compressed series of packets is compressed using the BZip2 [BZ2] algorithm.¶

An implementation that generates a Compressed Data packet MUST use the non-Legacy format for packet framing (see Section 4.2.1). It MUST NOT generate a Compressed Data packet with Legacy format (Section 4.2.2)¶

An implementation that deals with either historic data or data generated by legacy implementations predating support for [RFC2440] MAY interpret Compressed Data packets that use the Legacy format for packet framing.¶

5.7. Symmetrically Encrypted Data Packet (Type ID 9)

The Symmetrically Encrypted Data packet contains data encrypted with a symmetric-key algorithm. When it has been decrypted, it contains other packets (usually a literal data packet or compressed data packet, but in theory, it could be other Symmetrically Encrypted Data packets or sequences of packets that form whole OpenPGP messages).¶

This packet is obsolete. An implementation MUST NOT create this packet. An implementation SHOULD reject such a packet and stop processing the message. If an implementation chooses to process the packet anyway, it MUST return a clear warning that a non-integrity-protected packet has been processed.¶

This packet format is impossible to handle safely in general because the ciphertext it provides is malleable. See Section 13.7 about selecting a better OpenPGP encryption container that does not have this flaw.¶

The body of this packet consists of:¶

• A random prefix, containing block-size random octets (for example, 16 octets for a 128-bit block length) followed by a copy of the last two octets, encrypted together using Cipher Feedback (CFB) mode, with an IV of all zeros.¶

• Data encrypted using CFB mode, with the last block-size octets of the first ciphertext as the IV.¶

The symmetric cipher used may be specified in a Public-Key or Symmetric-Key Encrypted Session Key packet that precedes the Symmetrically Encrypted Data packet. In that case, the cipher algorithm ID is prefixed to the session key before it is encrypted. If no packets of these types precede the encrypted data, the IDEA algorithm is used with the session key calculated as the MD5 hash of the passphrase, though this use is deprecated.¶

The data is encrypted in CFB mode (see Section 12.9). For the random prefix, the IV is specified as all zeros. Instead of achieving randomized encryption through an IV, a string of length equal to the block size of the cipher plus two is encrypted for this purpose. The first block-size octets (for example, 16 octets for a 128-bit block length) are random, and the following two octets are copies of the last two octets of the first block-size random octets. For example, for a 16-octet block length, octet 17 is a copy of octet 15, and octet 18 is a copy of octet 16. For a cipher of block length 8, octet 9 is a copy of octet 7, and octet 10 is a copy of octet 8. (In both of these examples, we consider the first octet to be numbered 1.)¶

After encrypting these block-size-plus-two octets, a new CFB context is created for the encryption of the data, with the last block-size octets of the first ciphertext as the IV. (Alternatively and equivalently, the CFB state is resynchronized: the last block-size octets of ciphertext are passed through the cipher, and the block boundary is reset.)¶

The repetition of two octets in the random prefix allows the receiver to immediately check whether the session key is incorrect. See Section 13.4 for hints on the proper use of this "quick check".¶

5.8. Marker Packet (Type ID 10)

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

5.9. Literal Data Packet (Type ID 11)

A Literal Data packet contains the body of a message; that is, data that is not to be further interpreted.¶

The body of this packet consists of:¶

• A one-octet field that describes how the data is formatted.¶

  If it is a b (0x62), then the Literal packet contains binary data. If it is a u (0x75), then the Literal packet contains UTF-8-encoded text data and thus may need line ends converted to local form or other text mode changes.¶

  Previous versions of the OpenPGP specification used t (0x74) to indicate textual data but did not specify the character encoding. Implementations SHOULD NOT emit this value. An implementation that receives a literal data packet with this value in the format field SHOULD interpret the packet data as UTF-8 encoded text, unless reliable (not attacker-controlled) context indicates a specific alternate text encoding. This mode is deprecated due to its ambiguity.¶

  Some implementations predating [RFC2440] also defined a value of l as a "local" mode for machine-local conversions. [RFC1991] incorrectly states that this local mode flag is 1 (ASCII numeral one). Both of these local modes are deprecated.¶

• The file name as a string (one-octet length, followed by a file name). This may be a zero-length string. Commonly, if the source of the encrypted data is a file, it will be the name of the encrypted file. An implementation MAY consider the file name in the Literal packet to be a more authoritative name than the actual file name.¶

• A four-octet number that indicates a date associated with the literal data. Commonly, the date might be the modification date of a file, or the time the packet was created, or a zero that indicates no specific time.¶

• The remainder of the packet is literal data.¶

  Text data MUST be encoded with UTF-8 (see [RFC3629]) and stored with <CR><LF> text endings (that is, network-normal line endings). These should be converted to native line endings by the receiving implementation.¶

Note that OpenPGP signatures do not include the formatting octet, the file name, and the date field of the literal packet in a signature hash; therefore, those fields are not protected against tampering in a signed document. A receiving implementation MUST NOT treat those fields as though they were cryptographically secured by the surrounding signature when either representing them to the user or acting on them.¶

Due to their inherent malleability, an implementation that generates a literal data packet SHOULD avoid storing any significant data in these fields. If the implementation is certain that the data is textual and is encoded with UTF-8 (for example, if it will follow this literal data packet with a signature packet of type 0x01 (see Section 5.2.1), it MAY set the format octet to u. Otherwise, it MUST set the format octet to b. It SHOULD set the filename to the empty string (encoded as a single zero octet) and the timestamp to zero (encoded as four zero octets).¶

An application that wishes to include such filesystem metadata within a signature is advised to sign an encapsulated archive (for example, [PAX]).¶

An implementation that generates a Literal Data packet MUST use the OpenPGP format for packet framing (see Section 4.2.1). It MUST NOT generate a Literal Data packet with Legacy format (Section 4.2.2).¶

An implementation that deals with either historic data or data generated by an implementation that predates support for [RFC2440] MAY interpret Literal Data packets that use the Legacy format for packet framing.¶

5.10. Trust Packet (Type ID 12)

The Trust packet is used only within keyrings and is not normally exported. Trust packets contain data that record the user's specifications of which keyholders are trustworthy introducers, along with other information that implementation uses for trust information. The format of Trust packets is defined by a given implementation.¶

Trust packets SHOULD NOT be emitted to output streams that are transferred to other users, and they SHOULD be ignored on any input other than local keyring files.¶

5.11. User ID Packet (Type ID 13)

A User ID packet consists of UTF-8 text that is intended to represent the name and email address of the keyholder. By convention, it includes a mail name-addr as described in [RFC2822], but there are no restrictions on its content. The packet length in the header specifies the length of the User ID.¶

5.12. User Attribute Packet (Type ID 17)

The User Attribute packet is a variation of the User ID packet. It is capable of storing more types of data than the User ID packet, which is limited to text. Like the User ID packet, a User Attribute packet may be certified by the key owner ("self-signed") or any other key owner who cares to certify it. Except as noted, a User Attribute packet may be used anywhere that a User ID packet may be used.¶

While User Attribute packets are not a required part of the OpenPGP specification, implementations SHOULD provide at least enough compatibility to properly handle a certification signature on the User Attribute packet. A simple way to do this is by treating the User Attribute packet as a User ID packet with opaque contents, but an implementation may use any method desired.¶

The User Attribute packet is made up of one or more attribute subpackets. Each subpacket consists of a subpacket header and a body. The header consists of:¶

• the subpacket length (1, 2, or 5 octets)¶

• the subpacket type ID (1 octet)¶

and is followed by the subpacket specific data.¶

The following table lists the currently known subpackets:¶

An implementation SHOULD ignore any subpacket of a type that it does not recognize.¶

5.13. Symmetrically Encrypted Integrity Protected Data Packet (Type ID 18)

The SEIPD packet contains integrity-protected and encrypted data. When it has been decrypted, it will contain other packets forming an OpenPGP Message (see Section 10.3).¶

The first octet of this packet is always used to indicate the version number, but different versions contain ciphertext that is structured differently. Version 1 of this packet contains data encrypted with a symmetric-key algorithm and is thus protected against modification by the SHA-1 hash algorithm. This mechanism was introduced in [RFC4880] and offers some protections against ciphertext malleability.¶

Version 2 of this packet contains data encrypted with an AEAD construction. This offers a more cryptographically rigorous defense against ciphertext malleability. See Section 13.7 for more details on choosing between these formats.¶

Any new version of the SEIPD packet should be registered in the registry established in Section 10.3.2.1.¶

  chunk_size = (uint32_t) 1 << (c + 6)

5.14. Padding Packet (Type ID 21)

The Padding packet contains random data and can be used to defend against traffic analysis (see Section 13.11) on version 2 SEIPD messages (see Section 5.13.2) and Transferable Public Keys (see Section 10.1).¶

Such a packet MUST be ignored when received.¶

Its contents SHOULD be random octets to make the length obfuscation it provides more robust even when compressed.¶

An implementation adding padding to an OpenPGP stream SHOULD place such a packet:¶

• At the end of a v6 Transferable Public Key that is transferred over an encrypted channel (see Section 10.1).¶

• As the last packet of an Optionally Padded Message within a version 2 Symmetrically Encrypted Integrity Protected Data packet (see Section 10.3.1).¶

An implementation MUST be able to process padding packets anywhere else in an OpenPGP stream so that future revisions of this document may specify further locations for padding.¶

Policy about how large to make such a packet to defend against traffic analysis is beyond the scope of this document.¶

6.1. Optional Checksum

The optional checksum is a 24-bit Cyclic Redundancy Check (CRC) converted to four characters of base64 encoding by the same MIME base64 transformation, preceded by an equal sign (=). The CRC is computed by using the generator 0x864CFB and an initialization of 0xB704CE. The accumulation is done on the data before it is converted to base64 rather than on the converted data. A sample implementation of this algorithm is in Section 6.1.1.¶

If present, the checksum with its leading equal sign MUST appear on the next line after the base64-encoded data.¶

An implementation MUST NOT reject an OpenPGP object when the CRC24 footer is present, missing, malformed, or disagrees with the computed CRC24 sum. When forming ASCII Armor, the CRC24 footer SHOULD NOT be generated, unless interoperability with implementations that require the CRC24 footer to be present is a concern.¶

The CRC24 footer MUST NOT be generated if it can be determined by the context or by the OpenPGP object being encoded that the consuming implementation accepts base64-encoded blocks without a CRC24 footer. Notably:¶

• An ASCII-armored Encrypted Message packet sequence that ends in a v2 SEIPD packet MUST NOT contain a CRC24 footer.¶

• An ASCII-armored sequence of Signature packets that only includes v6 Signature packets MUST NOT contain a CRC24 footer.¶

• An ASCII-armored Transferable Public Key packet sequence of a v6 key MUST NOT contain a CRC24 footer.¶

• An ASCII-armored keyring consisting of only v6 keys MUST NOT contain a CRC24 footer.¶

Rationale: Previous draft versions of this document stated that the CRC24 footer is optional, but the text was ambiguous. In practice, very few implementations require the CRC24 footer to be present. Computing the CRC24 incurs a significant cost, while providing no meaningful integrity protection. Therefore, generating it is now discouraged.¶

#define CRC24_INIT 0xB704CEL
#define CRC24_GENERATOR 0x864CFBL

typedef unsigned long crc24;
crc24 crc_octets(unsigned char *octets, size_t len)
{
    crc24 crc = CRC24_INIT;
    int i;
    while (len--) {
        crc ^= (*octets++) << 16;
        for (i = 0; i < 8; i++) {
            crc <<= 1;
            if (crc & 0x1000000) {
                crc &= 0XFFFFFF; /* Clear bit 25 to avoid overflow */
                crc ^= CRC24_GENERATOR;
            }
        }
    }
    return crc & 0xFFFFFFL;
}

6.2. Forming ASCII Armor

When OpenPGP encodes data into ASCII Armor, it puts specific headers around the base64-encoded data, so OpenPGP can reconstruct the data later. An OpenPGP implementation MAY use ASCII armor to protect raw binary data. OpenPGP informs the user what kind of data is encoded in the ASCII armor through the use of the headers.¶

Concatenating the following data creates ASCII Armor:¶

• An Armor Header Line, appropriate for the type of data¶

• Armor Headers¶

• A blank (zero length or containing only whitespace) line¶

• The ASCII-Armored data¶

• An optional Armor Checksum (discouraged; see Section 6.1)¶

• The Armor Tail, which depends on the Armor Header Line¶

7.1. Cleartext Signed Message Structure

An OpenPGP cleartext signed message consists of:¶

• The cleartext header -----BEGIN PGP SIGNED MESSAGE----- on a single line.¶

• One or more legacy Hash Armor Headers that MAY be included by some implementations and MUST be ignored when well formed (see Section 6.2.2.3).¶

• An empty line (not included in the message digest).¶

• The dash-escaped cleartext.¶

• A line ending separating the cleartext and following armored signature (not included in the message digest).¶

• The ASCII-armored signature(s), including the -----BEGIN PGP SIGNATURE----- Armor Header and Armor Tail Lines.¶

As with any other text signature (Section 5.2.1.2), a cleartext signature is calculated on the text using canonical <CR><LF> line endings. As described above, the line ending before the -----BEGIN PGP SIGNATURE----- Armor Header Line of the armored signature is not considered part of the signed text.¶

Also, any trailing whitespace -- spaces (0x20) and tabs (0x09) -- at the end of any line is removed before signing or verifying a cleartext signed message.¶

Between the -----BEGIN PGP SIGNED MESSAGE----- line and the first empty line, the only Armor Header permitted is a well-formed Hash Armor Header (see Section 6.2.2.3). To reduce the risk of confusion about what has been signed, a verifying implementation MUST decline to validate any signature in a cleartext message if that message has any other Armor Header present in this location.¶

7.2. Dash-Escaped Text

The cleartext content of the message must also be dash-escaped.¶

Dash-escaped cleartext is the ordinary cleartext where every line starting with a "-" (HYPHEN-MINUS, U+002D) is prefixed by the sequence "-" (HYPHEN-MINUS, U+002D) and " " (SPACE, U+0020). This prevents the parser from recognizing armor headers of the cleartext itself. An implementation MAY dash-escape any line, SHOULD dash-escape lines commencing in "From" followed by a space, and MUST dash-escape any line commencing in a dash. The message digest is computed using the cleartext itself, not the dash-escaped form.¶

When reversing dash-escaping, an implementation MUST strip the string - if it occurs at the beginning of a line, and it SHOULD provide a warning for - and any character other than a space at the beginning of a line.¶

7.3. Issues with the Cleartext Signature Framework

Since creating a cleartext signed message involves trimming trailing whitespace on every line, the Cleartext Signature Framework will fail to safely round-trip any textual stream that may include semantically meaningful whitespace.¶

For example, the Unified Diff format [UNIFIED-DIFF] contains semantically meaningful whitespace: an empty line of context will consist of a line with a single " " (SPACE, U+0020) character, and any line that has trailing whitespace added or removed will represent such a change with semantically meaningful whitespace.¶

Furthermore, a Cleartext Signature Framework message that is very large is unlikely to work well. In particular, it will be difficult for any human reading the message to know which part is covered by the signature because they can't understand the whole message at once, especially in the case where an Armor Header line is placed somewhere in the body. And, very large Cleartext Signature Framework messages cannot be processed in a single pass, since the signature salt and digest algorithms are only discovered at the end.¶

An implementation that knows it is working with a textual stream with any of the above characteristics SHOULD NOT use the Cleartext Signature Framework. Safe alternatives for a semantically meaningful OpenPGP signature over such a file format are:¶

• A Signed Message, as described in Section 10.3.¶

• A detached signature, as described in Section 10.4.¶

Either of these alternatives may be ASCII-armored (see Section 6.2) if they need to be transmitted across a text-only (or 7-bit clean) channel.¶

Finally, when a Cleartext Signature Framework message is presented to the user as is, an attacker can include additional text in the Hash header, which may mislead the user into thinking it is part of the signed text. The signature validation constraints described in Sections 6.2.2.3 and 7.1 help to mitigate the risk of arbitrary or misleading text in the Armor Headers.¶

9.1. Public-Key Algorithms

Implementations MUST implement Ed25519 (27) for signatures and X25519 (25) for encryption. Implementations SHOULD implement Ed448 (28) and X448 (26).¶

RSA (1) keys are deprecated and SHOULD NOT be generated but may be interpreted. RSA Encrypt-Only (2) and RSA Sign-Only (3) are deprecated and MUST NOT be generated (see Section 12.4). Elgamal (16) keys are deprecated and MUST NOT be generated (see Section 12.6). DSA (17) keys are deprecated and MUST NOT be generated (see Section 12.5). For notes on Elgamal Encrypt or Sign (20) and X9.42 (21), see Section 12.8. Implementations MAY implement any other algorithm.¶

Note that an implementation conforming to the previous version of this specification [RFC4880] has only DSA (17) and Elgamal (16) as the algorithms that MUST be implemented.¶

A compatible specification of ECDSA is given in [RFC6090] (as "KT-I Signatures") and in [SEC1]; ECDH is defined in Section 11.5 of this document.¶

9.2. ECC Curves for OpenPGP

The parameter curve OID is an array of octets that defines a named curve.¶

The table below specifies the exact sequence of octets for each named curve referenced in this document. It also specifies which public key algorithms the curve can be used with, as well as the size of expected elements in octets:¶

The "Field Size (fsize)" column represents the field size of the group in number of octets, rounded up, such that x or y coordinates for a point on the curve or native point representations for the curve can be represented in that many octets. The curves specified here, and scalars such as the base point order and the private key, can be represented in fsize octets. However, note that curves exist outside this specification where the representation of scalars requires an additional octet.¶

The sequence of octets in the third column is the result of applying the Distinguished Encoding Rules (DER) to the ASN.1 Object Identifier with subsequent truncation. The truncation removes the two fields of encoded Object Identifier. The first omitted field is one octet representing the Object Identifier tag, and the second omitted field is the length of the Object Identifier body. For example, the complete ASN.1 DER encoding for the NIST P-256 curve OID is "06 08 2A 86 48 CE 3D 03 01 07", from which the first entry in the table above is constructed by omitting the first two octets. Only the truncated sequence of octets is the valid representation of a curve OID.¶

The deprecated OIDs for Ed25519Legacy and Curve25519Legacy are used only in version 4 keys and signatures. Implementations MAY implement these variants for compatibility with existing v4 key material and signatures. Implementations MUST NOT accept or generate v6 key material using the deprecated OIDs.¶

9.3. Symmetric-Key Algorithms

Implementations MUST implement AES-128. Implementations SHOULD implement AES-256. Implementations MUST NOT encrypt data with IDEA, TripleDES, or CAST5. Implementations MAY decrypt data that uses IDEA, TripleDES, or CAST5 for the sake of reading older messages or new messages from implementations predating support for [RFC2440]. An Implementation that decrypts data using IDEA, TripleDES, or CAST5 SHOULD generate a deprecation warning about the symmetric algorithm, indicating that message confidentiality is suspect. Implementations MAY implement any other algorithm.¶

9.4. Compression Algorithms

Implementations MUST implement uncompressed data. Implementations SHOULD implement ZLIB. For interoperability reasons, implementations SHOULD be able to decompress using ZIP. Implementations MAY implement any other algorithm.¶

9.5. Hash Algorithms

Implementations MUST implement SHA2-256. Implementations SHOULD implement SHA2-384 and SHA2-512. Implementations MAY implement other algorithms. Implementations SHOULD NOT create messages that require the use of SHA-1, with the exception of computing version 4 key fingerprints for purposes of the MDC in version 1 Symmetrically Encrypted Integrity Protected Data packets. Implementations MUST NOT generate signatures with MD5, SHA-1, or RIPEMD-160. Implementations MUST NOT use MD5, SHA-1, or RIPEMD-160 as a hash function in an ECDH KDF. Implementations MUST NOT generate packets using MD5, SHA-1, or RIPEMD-160 as a hash function in an S2K KDF. Implementations MUST NOT decrypt a secret using MD5, SHA-1, or RIPEMD-160 as a hash function in an S2K KDF in a version 6 (or later) packet. Implementations MUST NOT validate any recent signature that depends on MD5, SHA-1, or RIPEMD-160. Implementations SHOULD NOT validate any old signature that depends on MD5, SHA-1, or RIPEMD-160 unless the signature's creation date predates known weakness of the algorithm used, and the implementation is confident that the message has been in the secure custody of the user the whole time.¶

9.6. AEAD Algorithms

Implementations MUST implement OCB. Implementations MAY implement EAX, GCM, and other algorithms.¶

10.1. Transferable Public Keys

OpenPGP users may transfer public keys. This section describes the structure of public keys in transit to ensure interoperability. An OpenPGP Transferable Public Key is also known as an OpenPGP certificate, in order to distinguish it from both its constituent Public-Key packets (Sections 5.5.1.1 and 5.5.1.2) and the underlying cryptographic key material.¶

Primary Key
   [Revocation Signature...]
    Direct Key Signature...
   [User ID or User Attribute
           [Certification Revocation Signature...]
           [Certification Signature...]]...
   [Subkey [Subkey Revocation Signature...]
           Subkey Binding Signature...]...
   [Padding]

Primary Key
    Revocation Signature

Primary Key
   [Revocation Signature]
   [Direct Key Signature...]
   [User ID or User Attribute [Signature...]]...
   [Subkey [Subkey Revocation Signature...]
           Subkey Binding Signature...]...

RSA Public Key
   [Revocation Signature]
    User ID [Signature...]
   [User ID [Signature...]]...

10.2. Transferable Secret Keys

OpenPGP users may transfer secret keys. The format of a transferable secret key is the same as a transferable public key except that Secret-Key and Secret-Subkey packets can be used in addition to the Public-Key and Public-Subkey packets. If a single Secret-Key or Secret-Subkey packet is included in a packet sequence, it is a transferable secret key and should be handled and marked as such (see Section 6.2). An implementation SHOULD include self-signatures on any User IDs and subkeys, as this allows for a complete public key to be automatically extracted from the transferable secret key. An implementation MAY choose to omit the self-signatures, especially if a transferable public key accompanies the transferable secret key.¶

10.3. OpenPGP Messages

An OpenPGP message is a packet or sequence of packets that correspond to the following grammatical rules (a comma (,) represents sequential composition, and a vertical bar (|) separates alternatives):¶

OpenPGP Message :-

Encrypted Message | Signed Message | Compressed Message | Literal Message.¶

Compressed Message :-

Compressed Data Packet.¶

Literal Message :-

Literal Data Packet.¶

ESK :-

Public-Key Encrypted Session Key Packet | Symmetric-Key Encrypted Session Key Packet.¶

ESK Sequence :-

ESK | ESK Sequence, ESK.¶

Encrypted Data :-

Symmetrically Encrypted Data Packet | Symmetrically Encrypted Integrity Protected Data Packet.¶

Encrypted Message :-

Encrypted Data | ESK Sequence, Encrypted Data.¶

One-Pass Signed Message :-

One-Pass Signature Packet, OpenPGP Message, Corresponding Signature Packet.¶

Signed Message :-

Signature Packet, OpenPGP Message | One-Pass Signed Message.¶

Optionally Padded Message :-

OpenPGP Message | OpenPGP Message, Padding Packet.¶

In addition to these rules, a marker packet (Section 5.8) can appear anywhere in the sequence.¶

10.4. Detached Signatures

Some OpenPGP applications use so-called "detached signatures". For example, a program bundle may contain a file, and with it a second file that is a detached signature of the first file. These detached signatures are simply one or more Signature packets stored separately from the data for which they are a signature.¶

In addition, a marker packet (Section 5.8) and a padding packet (Section 5.14) can appear anywhere in the sequence.¶

11.1. ECC Curves

This document references three named prime field curves defined in [FIPS186] as "Curve P-256", "Curve P-384", and "Curve P-521" and three named prime field curves defined in [RFC5639] as "brainpoolP256r1", "brainpoolP384r1", and "brainpoolP512r1". All six curves can be used with ECDSA and ECDH public key algorithms. They are referenced using a sequence of octets, referred to as the curve OID. Section 9.2 describes in detail how this sequence of octets is formed.¶

Separate algorithms are also defined for the use of X25519 and X448 [RFC7748] and Ed25519 and Ed448 [RFC8032]. Additionally, legacy OIDs are defined for "Curve25519Legacy" (for encryption using the ECDH algorithm) and "Ed25519Legacy" (for signing using the EdDSALegacy algorithm).¶

11.2. EC Point Wire Formats

A point on an elliptic curve will always be represented on the wire as an MPI. Each curve uses a specific point format for the data within the MPI itself. Each format uses a designated prefix octet to ensure that the high octet has at least one bit set to make the MPI a constant size.¶

B = 04 || x || y

B = 40 || p

11.3. EC Scalar Wire Formats

Some non-curve values in elliptic curve cryptography (for example, secret keys and signature components) are not points on a curve, but they are also encoded on the wire in OpenPGP as an MPI.¶

Because of different patterns of deployment, some curves treat these values as opaque bit strings with the high bit set, while others are treated as actual integers, encoded in the standard OpenPGP big-endian form. The choice of encoding is specific to the public key algorithm in use.¶

11.4. Key Derivation Function

A key derivation function (KDF) is necessary to implement EC encryption. The Concatenation Key Derivation Function (Approved Alternative 1) [SP800-56A] with the KDF hash function that is SHA2-256 [FIPS180] or stronger is REQUIRED.¶

For convenience, the synopsis of the encoding method is given below with significant simplifications attributable to the restricted choice of hash functions in this document. However, [SP800-56A] is the normative source of the definition.¶

//   Implements KDF( X, oBits, Param );
//   Input: point X = (x,y)
//   oBits - the desired size of output
//   hBits - the size of output of hash function Hash
//   Param - octets representing the parameters
//   Assumes that oBits <= hBits
// Convert the point X to the octet string:
//   ZB' = 04 || x || y
// and extract the x portion from ZB'
ZB = x;
MB = Hash ( 00 || 00 || 00 || 01 || ZB || Param );
return oBits leftmost bits of MB.

Note that ZB in the KDF description above is the compact representation of X as defined in Section 4.2 of [RFC6090].¶

11.5. EC DH Algorithm (ECDH)

The method is a combination of an ECC Diffie-Hellman method to establish a shared secret, a key derivation method to process the shared secret into a derived key, and a key wrapping method that uses the derived key to protect a session key used to encrypt a message.¶

The One-Pass Diffie-Hellman method C(1, 1, ECC CDH) [SP800-56A] MUST be implemented with the following restrictions: the ECC Cofactor Diffie-Hellman (CDH) primitive employed by this method is modified to always assume the cofactor is 1, the KDF specified in Section 11.4 is used, and the KDF parameters specified below are used.¶

The KDF parameters are encoded as a concatenation of the following 5 variable-length and fixed-length fields, which are compatible with the definition of the OtherInfo bit string [SP800-56A]:¶

• A variable-length field containing a curve OID, which is formatted as follows:¶

  • A one-octet size of the following field.¶

  • The octets representing a curve OID, as defined in Section 9.2.¶

• A one-octet public key algorithm ID, as defined in Section 9.1.¶

• A variable-length field containing KDF parameters, which are identical to the corresponding field in the ECDH public key and formatted as follows:¶

  • A one-octet size of the following fields; values 0 and 0xFF are reserved for future extensions.¶

  • A one-octet value 0x01, reserved for future extensions.¶

  • A one-octet hash function ID used with the KDF.¶

  • A one-octet algorithm ID for the symmetric algorithm that is used to wrap the symmetric key for message encryption; see Section 11.5 for details.¶

• 20 octets representing the UTF-8 encoding of the string Anonymous Sender, which is the octet sequence 41 6E 6F 6E 79 6D 6F 75 73 20 53 65 6E 64 65 72 20 20 20 20.¶

• A variable-length field containing the fingerprint of the recipient encryption subkey identifying the key material that is needed for decryption. For version 4 keys, this field is 20 octets. For version 6 keys, this field is 32 octets.¶

The size in octets of the KDF parameters sequence, as defined above, for encrypting to a v4 key is 54 for curve NIST P-256; 51 for curves NIST P-384 and NIST P-521; 55 for curves brainpoolP256r1, brainpoolP384r1, and brainpoolP512r1; or 56 for Curve25519Legacy. For encrypting to a v6 key, the size of the sequence is 66 for curve NIST P-256; 63 for curves NIST P-384 and NIST P-521; or 67 for curves brainpoolP256r1, brainpoolP384r1, and brainpoolP512r1.¶

The key wrapping method is described in [RFC3394]. The KDF produces a symmetric key that is used as a KEK as specified in [RFC3394]. Refer to Section 11.5.1 for the details regarding the choice of the KEK algorithm, which SHOULD be one of the three AES algorithms. Key wrapping and unwrapping is performed with the default initial value of [RFC3394].¶

To produce the input to the key wrapping method, first concatenate the following values:¶

• The one-octet algorithm identifier, if it was passed (in the case of a v3 PKESK packet).¶

• The session key.¶

• A two-octet checksum of the session key, equal to the sum of the session key octets, modulo 65536.¶

Then, the above values are padded to an 8-octet granularity using the method described in [RFC2898].¶

For example, in a v3 Public-Key Encrypted Session Key packet, an AES-256 session key is encoded as follows, forming a 40-octet sequence:¶

09 k0 k1 ... k31 s0 s1 05 05 05 05 05

The octets k0 to k31 above denote the session key, and the octets s0 and s1 denote the checksum of the session key octets. This encoding allows the sender to obfuscate the size of the symmetric encryption key used to encrypt the data. For example, assuming that an AES algorithm is used for the session key, the sender MAY use 21, 13, and 5 octets of padding for AES-128, AES-192, and AES-256, respectively, to provide the same number of octets, 40 total, as an input to the key wrapping method.¶

In a v6 Public-Key Encrypted Session Key packet, the symmetric algorithm is not included, as described in Section 5.1. For example, an AES-256 session key would be composed as follows:¶

k0 k1 ... k31 s0 s1 06 06 06 06 06 06

The octets k0 to k31 above again denote the session key, and the octets s0 and s1 denote the checksum. In this case, assuming that an AES algorithm is used for the session key, the sender MAY use 22, 14, and 6 octets of padding for AES-128, AES-192, and AES-256, respectively, to provide the same number of octets, 40 total, as an input to the key wrapping method.¶

The output of the method consists of two fields. The first field is the MPI containing the ephemeral key used to establish the shared secret. The second field is composed of the following two subfields:¶

• One octet encoding the size in octets of the result of the key wrapping method; the value 255 is reserved for future extensions.¶

• Up to 254 octets representing the result of the key wrapping method, applied to the 8-octet padded session key, as described above.¶

Note that for session key sizes 128, 192, and 256 bits, the size of the result of the key wrapping method is, respectively, 32, 40, and 48 octets, unless size obfuscation is used.¶

For convenience, the synopsis of the encoding method is given below; however, this section, [SP800-56A], and [RFC3394] are the normative sources of the definition.¶

• Obtain the authenticated recipient public key R¶

• Generate an ephemeral, single-use key pair {v, V=vG}¶

• Compute the shared point S = vR;¶

• m = symm_alg_ID || session key || checksum || pkcs5_padding;¶

• curve_OID_len = (octet)len(curve_OID);¶

• Param = curve_OID_len || curve_OID || public_key_alg_ID || 03 || 01 || KDF_hash_ID || KEK_alg_ID for AESKeyWrap || Anonymous Sender || recipient_fingerprint;¶

• Z_len = the key size for the KEK_alg_ID used with AESKeyWrap¶

• Compute Z = KDF( S, Z_len, Param );¶

• Compute C = AESKeyWrap( Z, m ); (per [RFC3394])¶

• Wipe the memory that contained S, v, and Z to avoid leaking ephemeral secrets¶

• VB = convert point V to the octet string¶

• Output (MPI(VB) || len(C) || C).¶

The decryption is the inverse of the method given. Note that the recipient with key pair (r,R) obtains the shared secret by calculating:¶

S = rV = rvG

12.1. PKCS#1 Encoding in OpenPGP

This specification makes use of the PKCS#1 functions EME-PKCS1-v1_5 and EMSA-PKCS1-v1_5. However, the calling conventions of these functions have changed in the past. To avoid potential confusion and interoperability problems, we are including local copies in this document, adapted from those in PKCS#1 v2.1 [RFC8017]. [RFC8017] should be treated as the ultimate authority on PKCS#1 for OpenPGP. Nonetheless, we believe that there is value in having a self-contained document that avoids problems in the future with needed changes in the conventions.¶

  EM = 0x00 || 0x02 || PS || 0x00 || M.

12.2. Symmetric Algorithm Preferences

The symmetric algorithm preference is an ordered list of algorithms that the keyholder accepts. Since it is found on a self-signature, it is possible that a keyholder may have multiple, different preferences. For example, Alice may have AES-128 only specified for "alice@work.com" but Camellia-256, Twofish, and AES-128 specified for "alice@home.org". Note that it is also possible for preferences to be in a subkey's binding signature.¶

Since AES-128 is the algorithm that MUST be implemented, if it is not explicitly in the list, it is tacitly at the end. However, it is good form to place it there explicitly. Note also that if an implementation does not implement the preference, then it is implicitly an AES-128-only implementation. Furthermore, note that implementations conforming to previous versions of this specification [RFC4880] have TripleDES as the only algorithm that MUST be implemented.¶

An implementation MUST NOT use a symmetric algorithm that is not in the recipient's preference list. When encrypting to more than one recipient, the implementation finds a suitable algorithm by taking the intersection of the preferences of the recipients. Note that the AES-128 algorithm MUST be implemented to ensure that the intersection is non-empty. The implementation may use any mechanism to pick an algorithm in the intersection.¶

If an implementation can decrypt a message that a keyholder doesn't have in their preferences, the implementation SHOULD decrypt the message anyway, but it MUST warn the keyholder that the protocol has been violated. For example, suppose that Alice (above) has an implementation that implements all algorithms in this specification. Nonetheless, she prefers subsets for work or home. If she is sent a message encrypted with IDEA, which is not in her preferences, the implementation warns her that someone sent an IDEA-encrypted message, but it would ideally decrypt it anyway.¶

12.3. Other Algorithm Preferences

Other algorithm preferences work similarly to the symmetric algorithm preference in that they specify which algorithms the keyholder accepts. There are two interesting cases in which further comments are needed: the compression preferences and the hash preferences.¶

12.4. RSA

The PKCS1-v1_5 padding scheme, used by the RSA algorithms defined in this document, is no longer recommended, and its use is deprecated by [SP800-131A]. Therefore, an implementation SHOULD NOT generate RSA keys.¶

There are algorithm types for RSA Sign-Only and RSA Encrypt-Only keys. These types are deprecated. The "key flags" subpacket in a signature is a much better way to express the same idea and generalize it to all algorithms. An implementation MUST NOT create such a key, but it MAY interpret it.¶

An implementation MUST NOT generate RSA keys of a size less than 3072 bits. An implementation SHOULD NOT encrypt, sign, or verify using RSA keys of a size less than 3072 bits. An implementation MUST NOT encrypt, sign, or verify using RSA keys of a size less than 2048 bits. An implementation that decrypts a message using an RSA secret key of a size less than 3072 bits SHOULD generate a deprecation warning that the key is too weak for modern use.¶

12.5. DSA

DSA is no longer recommended. It has also been deprecated in [FIPS186]. Therefore, an implementation MUST NOT generate DSA keys.¶

An implementation MUST NOT sign or verify using DSA keys.¶

12.6. Elgamal

The PKCS1-v1_5 padding scheme, used by the Elgamal algorithm defined in this document, is no longer recommended, and its use is deprecated by [SP800-131A]. Therefore, an implementation MUST NOT generate Elgamal keys.¶

An implementation MUST NOT encrypt using Elgamal keys. An implementation that decrypts a message using an Elgamal secret key SHOULD generate a deprecation warning that the key is too weak for modern use.¶

12.7. EdDSA

Although the EdDSA algorithm allows arbitrary data as input, its use with OpenPGP requires that a digest of the message be used as input (pre-hashed). See Section 5.2.4 for details. Truncation of the resulting digest is never applied; the resulting digest value is used verbatim as input to the EdDSA algorithm.¶

For clarity: while [RFC8032] describes different variants of EdDSA, OpenPGP uses the "pure" variant (PureEdDSA). The hashing that happens with OpenPGP is done as part of the standard OpenPGP signature process, and that hash itself is fed as the input message to the PureEdDSA algorithm.¶

As specified in [RFC8032], Ed448 also expects a "context string". In OpenPGP, Ed448 is used with the empty string as a context string.¶

12.8. Reserved Algorithm IDs

A number of algorithm IDs have been reserved for algorithms that would be useful to use in an OpenPGP implementation, yet there are issues that prevent an implementer from actually implementing the algorithm. These are marked as reserved in Section 9.1.¶

The reserved public-key algorithm X9.42 (21) does not have the necessary parameters, parameter order, or semantics defined. The same is currently true for reserved public-key algorithms AEDH (23) and AEDSA (24).¶

Previous versions of the OpenPGP specification permitted Elgamal [ELGAMAL] signatures with a public-key algorithm ID of 20. These are no longer permitted. An implementation MUST NOT generate such keys. An implementation MUST NOT generate Elgamal signatures; see [BLEICHENBACHER].¶

12.9. CFB Mode

The Cipher Feedback (CFB) mode used in this document is defined in Section 6.3 of [SP800-38A].¶

The CFB segment size s is equal to the block size of the cipher (i.e., n-bit CFB mode, where n is the block size used).¶

12.10. Private or Experimental Parameters

S2K specifiers, Signature subpacket type IDs, User Attribute subpacket type IDs, image format IDs, and the various algorithm IDs described in Section 9 all reserve the range 100 to 110 for Private and Experimental Use. Packet type IDs reserve the range 60 to 63 for Private and Experimental Use. These are intentionally managed by the Private Use method, as described in [RFC8126].¶

However, implementations need to be careful with these and promote them to full IANA-managed parameters when they grow beyond the original, limited system.¶

12.11. Meta Considerations for Expansion

If OpenPGP is extended in a way that is not backward compatible, meaning that old implementations will not gracefully handle their absence of a new feature, the extension proposal can be declared in the keyholder's self-signature as part of the Features signature subpacket.¶

We cannot state definitively what extensions will not be upward compatible, but typically new algorithms are upward compatible, whereas new packets are not.¶

If an extension proposal does not update the Features system, it SHOULD include an explanation of why this is unnecessary. If the proposal contains neither an extension to the Features system nor an explanation of why such an extension is unnecessary, the proposal SHOULD be rejected.¶

13.1. SHA-1 Collision Detection

As described in [SHAMBLES], the SHA-1 digest algorithm is not collision resistant. However, an OpenPGP implementation cannot completely discard the SHA-1 algorithm, because it is required for implementing v4 public keys. In particular, the v4 fingerprint derivation uses SHA-1. So as long as an OpenPGP implementation supports v4 public keys, it will need to implement SHA-1 in at least some scenarios.¶

To avoid the risk of uncertain breakage from a maliciously introduced SHA-1 collision, an OpenPGP implementation MAY attempt to detect when a hash input is likely from a known collision attack and then either reject the hash input deliberately or modify the hash output. This should convert an uncertain breakage (where it is unclear what the effect of a collision will be) to an explicit breakage, which is more desirable for a robust implementation.¶

[STEVENS2013] describes a method for detecting indicators of well-known SHA-1 collision attacks. Some example C code implementing this technique can be found at [SHA1CD].¶

13.2. Advantages of Salted Signatures

V6 signatures include a salt that is hashed first, and it's size depends on the hashing algorithm. This makes v6 OpenPGP signatures non-deterministic and protects against a broad class of attacks that depend on creating a signature over a predictable message. By selecting a new random salt for each signature made, the signed hashes and the signatures are not predictable.¶

While the material to be signed could be attacker controlled, hashing the salt first means that there is no attacker-controlled hashed prefix. An example of this kind of attack is described in the paper "SHA-1 is a Shambles" [SHAMBLES], which leverages a chosen prefix collision attack against SHA-1. This means that an adversary carrying out a chosen-message attack will not be able to control the hash that is being signed and will need to break second-preimage resistance instead of the simpler collision resistance to create two messages having the same signature. The size of the salt is bound to the hash function to match the expected collision-resistance level and is at least 16 octets.¶

In some cases, an attacker may be able to induce a signature to be made, even if they do not control the content of the message. In some scenarios, a repeated signature over the exact same message may risk leakage of part or all of the signing key; for example, see discussion of hardware faults over EdDSA and deterministic ECDSA in [PSSLR17]. Choosing a new random salt for each signature ensures that no repeated signatures are produced, which mitigates this risk.¶

13.3. Elliptic Curve Side Channels

Side-channel attacks are a concern when a compliant application's use of the OpenPGP format can be modeled by a decryption or signing oracle, for example, when an application is a network service performing decryption to unauthenticated remote users. ECC scalar multiplication operations used in ECDSA and ECDH are vulnerable to side-channel attacks. Countermeasures can often be taken at the higher protocol level, such as limiting the number of allowed failures or time-blinding the operations associated with each network interface. Mitigations at the scalar multiplication level seek to eliminate any measurable distinction between the ECC point addition and doubling operations.¶

13.4. Risks of a Quick Check Oracle

In winter 2005, Serge Mister and Robert Zuccherato from Entrust released a paper describing a way that the "quick check" in v1 SEIPD and SED packets can be used as an oracle to decrypt two octets of every cipher block [MZ05]. This check was intended for early detection of session key decryption errors, particularly to detect a wrong passphrase, since v4 SKESK packets do not include an integrity check.¶

There is a danger when using the quick check if timing or error information about the check can be exposed to an attacker, particularly via an automated service that allows rapidly repeated queries.¶

Disabling the quick check prevents the attack.¶

For very large encrypted data whose session key is protected by a passphrase using a version 4 SKESK, the quick check may be convenient to the user by informing them early that they typed the wrong passphrase. But the implementation should use the quick check with care. The recommended approach for secure and early detection of decryption failure is to encrypt data using v2 SEIPD. If the session key is public-key encrypted, the quick check is not useful as the public-key encryption of the session key should guarantee that it is the right session key.¶

The quick check oracle attack is a particular type of attack that exploits ciphertext malleability. For information about other similar attacks, see Section 13.7.¶

13.5. Avoiding Leaks from PKCS#1 Errors

The PKCS#1 padding (used in RSA-encrypted and ElGamal-encrypted PKESK) has been found to be vulnerable to attacks in which a system that allows distinguishing padding errors from other decryption errors can act as a decryption and/or signing oracle that can leak the session key or allow signing arbitrary data, respectively [BLEICHENBACHER-PKCS1]. The number of queries required to carry out an attack can range from thousands to millions, depending on how strict and careful an implementation is in processing the padding.¶

To make the attack more difficult, an implementation SHOULD implement strict, robust, and constant time padding checks.¶

To prevent the attack, in settings where the attacker does not have access to timing information concerning message decryption, the simplest solution is to report a single error code for all variants of PKESK processing errors as well as SEIPD integrity errors (this also includes session key parsing errors, such as on an invalid cipher algorithm for v3 PKESK, or a session key size mismatch for v6 PKESK). If the attacker may have access to timing information, then a constant time solution is also needed. This requires careful design, especially for v3 PKESK, where session key size and cipher information is typically not known in advance, as it is part of the PKESK encrypted payload.¶

13.6. Fingerprint Usability

This specification uses fingerprints in several places on the wire (e.g., Sections 5.2.3.23, 5.2.3.35, and 5.2.3.36) and in processing (e.g., in ECDH KDF Section 11.5). An implementation may also use the fingerprint internally, for example, as an index to a keystore.¶

Additionally, some OpenPGP users have historically used manual fingerprint comparison to verify the public key of a peer. For a version 4 fingerprint, this has typically been done with the fingerprint represented as 40 hexadecimal digits, often broken into groups of four digits with whitespace between each group.¶

When a human is actively involved, the result of such a verification is dubious. There is little evidence that most humans are good at precise comparison of high-entropy data, particularly when that data is represented in compact textual form like a hexadecimal [USENIX-STUDY].¶

The version 6 fingerprint makes the challenge for a human verifier even worse. At 256 bits (compared to v4's 160-bit fingerprint), a v6 fingerprint is even harder for a human to successfully compare.¶

An OpenPGP implementation should prioritize mechanical fingerprint transfer and comparison where possible and SHOULD NOT promote manual transfer or comparison of full fingerprints by a human unless there is no other way to achieve the desired result.¶

While this subsection acknowledges existing practice for human-representable v4 fingerprints, this document does not attempt to standardize any specific human-readable form of v6 fingerprint for this discouraged use case.¶

NOTE: the topic of interoperable human-in-the-loop key verification needs more work, which will be done in a separate document.¶

13.7. Avoiding Ciphertext Malleability

If ciphertext can be modified by an attacker but still subsequently decrypted to some new plaintext, it is considered "malleable". A number of attacks can arise in any cryptosystem that uses malleable encryption, so [RFC4880] and later versions of OpenPGP offer mechanisms to defend against it. However, OpenPGP data may have been created before these defense mechanisms were available. Because OpenPGP implementations deal with historic stored data, they may encounter malleable ciphertexts.¶

When an OpenPGP implementation discovers that it is decrypting data that appears to be malleable, it MUST generate a clear error message that indicates the integrity of the message is suspect, it SHOULD NOT attempt to parse nor release decrypted data to the user, and it SHOULD halt with an error. Parsing or releasing decrypted data before having confirmed its integrity can leak the decrypted data [EFAIL] [MRLG15].¶

In the case of AEAD encrypted data, if the authentication tag fails to verify, the implementation MUST NOT attempt to parse nor release decrypted data to the user, and it MUST halt with an error.¶

An implementation that encounters malleable ciphertext MAY choose to release cleartext to the user if it is not encrypted using AEAD, it is known to be dealing with historic archived legacy data, and the user is aware of the risks.¶

In the case of AEAD encrypted messages, if the message is truncated, i.e., the final zero-octet chunk and possibly (part of) some chunks before it are missing, the implementation MAY choose to release cleartext from the fully authenticated chunks before it to the user if it is operating in a streaming fashion, but it MUST indicate a clear error message as soon as the truncation is detected.¶

Any of the following OpenPGP data elements indicate that malleable ciphertext is present:¶

• All Symmetrically Encrypted Data packets (Section 5.7).¶

• Within any encrypted container, any Compressed Data packet (Section 5.6) where there is a decompression failure.¶

• Any version 1 Symmetrically Encrypted Integrity Protected Data packet (Section 5.13.1) where the internal Modification Detection Code does not validate.¶

• Any version 2 Symmetrically Encrypted Integrity Protected Data packet (Section 5.13.2) where the authentication tag of any chunk fails or where there is no final zero-octet chunk.¶

• Any Secret-Key packet with encrypted secret key material (Section 3.7.2.1) where there is an integrity failure, based on the value of the secret key protection octet:¶

  • Value 255 (MalleableCFB) or raw cipher algorithm: where the trailing 2-octet checksum does not match.¶

  • Value 254 (CFB): where the SHA1 checksum is mismatched.¶

  • Value 253 (AEAD): where the AEAD authentication tag is invalid.¶

To avoid these circumstances, an implementation that generates OpenPGP encrypted data SHOULD select the encrypted container format with the most robust protections that can be handled by the intended recipients. In particular:¶

• The SED packet is deprecated and MUST NOT be generated.¶

• When encrypting to one or more public keys:¶

  • If all recipient keys indicate support for version 2 of the Symmetrically Encrypted Integrity Protected Data packet in their Features subpacket (Section 5.2.3.32), if all recipient keys are v6 keys without a Features subpacket, or the implementation can otherwise infer that all recipients support v2 SEIPD packets, the implementation SHOULD encrypt using a v2 SEIPD packet.¶

  • If one of the recipients does not support v2 SEIPD packets, then the message generator MAY use a v1 SEIPD packet instead.¶

• Passphrase-protected secret key material in a v6 Secret Key or v6 Secret Subkey packet SHOULD be protected with AEAD encryption (S2K usage octet 253) unless it will be transferred to an implementation that is known to not support AEAD. An implementation should be aware that, in scenarios where an attacker has write access to encrypted private keys, CFB-encrypted keys (S2K usage octet 254 or 255) are vulnerable to corruption attacks that can cause leakage of secret data when the secret key is used [KOPENPGP] [KR02].¶

Implementers should implement AEAD (v2 SEIPD and S2K usage octet 253) promptly and encourage its spread.¶

Users are RECOMMENDED to migrate to AEAD.¶

13.8. Secure Use of the v2 SEIPD Session-Key-Reuse Feature

The salted key derivation of v2 SEIPD packets (Section 5.13.2) allows the recipient of an encrypted message to reply to the sender and all other recipients without needing their public keys but by using the same v6 PKESK packets it received and a different random salt value. This ensures a secure mechanism on the cryptographic level that enables the use of message encryption in cases where a sender does not have a copy of an encryption-capable certificate for one or more participants in the conversation and thus can enhance the overall security of an application. However, care must be taken when using this mechanism not to create security vulnerabilities, such as the following:¶

• Replying to only a subset of the original recipients and the original sender by use of the session-key-reuse feature would mean that the remaining recipients (including the sender) of the original message could read the encrypted reply message, too.¶

• Adding a further recipient to the reply that is encrypted using the session-key-reuse feature gives that further recipient also cryptographic access to the original message that is being replied to (and potentially to a longer history of previous messages).¶

• A modification of the list of recipients addressed in the above points also needs to be safeguarded when a message is initially composed as a reply with session-key reuse but then is stored (e.g., as a draft) and later reopened for further editing and to be finally sent.¶

• There is the potential threat that an attacker with network or mailbox access, who is at the same time a recipient of the original message, silently removes themselves from the message before the victim's client receives it. The victim's client that then uses the mechanism for replying with session-key reuse would unknowingly compose an encrypted message that could be read by the attacker. Implementations are encouraged to use the Intended Recipient Fingerprint subpacket (Section 5.2.3.36) when composing messages and checking the consistency of the set of recipients of a message before replying to it with session-key reuse.¶

• When using the session-key-reuse feature in any higher-layer protocol, care should be taken to ensure that there is no other potentially interfering practice of session-key reuse established in that protocol. Such interfering session-key reuse could be given, for instance, if an initial message is already composed by reusing the session key of an existing encrypted file the access to which may be shared among a group of users already. Using the session-key-reuse feature to compose an encrypted reply to such a message would unknowingly give this whole group of users cryptographic access to the encrypted message.¶

• Generally, the use of the session-key-reuse feature should be under the control of the user. Specifically, care should be taken so that this feature is not silently used when the user assumes that proper public-key encryption is used. This can be the case, for instance, when the public key of one of the recipients of the reply is known but has expired. Special care should be taken to ensure that users do not get caught in continued use of the session-key reuse unknowingly but instead receive the chance to switch to proper fresh public-key encryption as soon as possible.¶

• Whenever possible, a client should prefer a fresh public key encryption over the session-key reuse.¶

Even though this is not necessarily a security aspect, note that initially composing an encrypted reply using the session-key-reuse feature on one client and then storing it (e.g., as a draft) and later reopening the stored unfinished reply with another client that does not support the session-key-reuse feature may lead to interoperability problems.¶

Avoiding the pitfalls described above requires context-specific expertise. An implementation should only make use of the session-key-reuse feature in any particular application layer when it can follow reasonable documentation about how to deploy the feature safely in the specific application. At the time of this writing, there is no known documentation about safe reuse of OpenPGP session keys for any specific context. An implementer that intends to make use of this feature should publish their own proposed guidance for others to review.¶

13.9. Escrowed Revocation Signatures

A keyholder, Alice, may wish to designate a third party to be able to revoke her own key.¶

The preferred way for Alice to do this is to produce a specific Revocation Signature (signature type IDs 0x20, 0x28, or 0x30) and distribute it securely to a preferred revoker who can hold it in escrow. The preferred revoker can then publish the escrowed Revocation Signature at whatever time is deemed appropriate rather than generating the revocation signature themselves.¶

There are multiple advantages of using an escrowed Revocation Signature over the deprecated Revocation Key subpacket (Section 5.2.3.23):¶

• The keyholder can constrain what types of revocation the preferred revoker can issue, by only escrowing those specific signatures.¶

• There is no public/visible linkage between the keyholder and the preferred revoker.¶

• Third parties can verify the revocation without needing to find the key of the preferred revoker.¶

• The preferred revoker doesn't even need to have a public OpenPGP key if some other secure transport is possible between them and the keyholder.¶

• Implementation support for enforcing a revocation from an authorized Revocation Key subpacket is uneven and unreliable.¶

• If the fingerprint mechanism suffers a cryptanalytic flaw, the escrowed Revocation Signature is not affected.¶

A Revocation Signature may also be split up into shares and distributed among multiple parties, requiring some subset of those parties to collaborate before the escrowed Revocation Signature is recreated.¶

13.10. Random Number Generation and Seeding

OpenPGP requires a cryptographically secure pseudorandom number generator (CSPRNG). In most cases, the operating system provides an appropriate facility such as a getrandom() syscall on Linux or BSD, which should be used absent other (for example, performance) concerns. It is RECOMMENDED to use an existing CSPRNG implementation as opposed to crafting a new one. Many adequate cryptographic libraries are already available under favorable license terms. Should those prove unsatisfactory, [RFC4086] provides guidance on the generation of random values.¶

OpenPGP uses random data with three different levels of visibility:¶

• In publicly visible fields such as nonces, IVs, public padding material, or salts.¶

• In shared-secret values, such as session keys for encrypted data or padding material within an encrypted packet.¶

• In entirely private data, such as asymmetric key generation.¶

With a properly functioning CSPRNG, this range of visibility does not present a security problem, as it is not feasible to determine the CSPRNG state from its output. However, with a broken CSPRNG, it may be possible for an attacker to use visible output to determine the CSPRNG internal state and thereby predict less-visible data like keying material, as documented in [CHECKOWAY].¶

An implementation can provide extra security against this form of attack by using separate CSPRNGs to generate random data with different levels of visibility.¶

13.11. Traffic Analysis

When sending OpenPGP data through the network, the size of the data may leak information to an attacker. There are circumstances where such a leak could be unacceptable from a security perspective.¶

For example, if possible cleartext messages for a given protocol are known to be either yes (three octets) or no (two octets) and the messages are sent within a Symmetrically Encrypted Integrity Protected Data packet, the length of the encrypted message will reveal the contents of the cleartext.¶

In another example, sending an OpenPGP Transferable Public Key over an encrypted network connection might reveal the length of the certificate. Since the length of an OpenPGP certificate varies based on the content, an external observer interested in metadata (who is trying to contact whom) may be able to guess the identity of the certificate sent, if its length is unique.¶

In both cases, an implementation can adjust the size of the compound structure by including a Padding packet (see Section 5.14).¶

13.12. Surreptitious Forwarding

When an attacker obtains a signature for some text, e.g., by receiving a signed message, they may be able to use that signature maliciously by sending a message purporting to come from the original sender, with the same body and signature, to a different recipient. To prevent this, an implementation SHOULD implement the Intended Recipient Fingerprint signature subpacket (Section 5.2.3.36).¶

13.13. Hashed vs. Unhashed Subpackets

Each OpenPGP signature can have subpackets in two different sections. The first set of subpackets (the "hashed section") is covered by the signature itself. The second set has no cryptographic protections and is used for advisory material only, including locally stored annotations about the signature.¶

For example, consider an implementation working with a specific signature that happens to know that the signature was made by a certain key, even though the signature contains no Issuer Fingerprint subpacket (Section 5.2.3.35) in the hashed section. That implementation MAY synthesize an Issuer Fingerprint subpacket and store it in the unhashed section so that it will be able to recall which key issued the signature in the future.¶

Some subpackets are only useful when they are in the hashed section, and an implementation SHOULD ignore them when they are found with unknown provenance in the unhashed section. For example, a Preferred AEAD Ciphersuites subpacket (Section 5.2.3.15) in a direct key self-signature indicates the preferences of the keyholder when encrypting SEIPD v2 data to the key. An implementation that observes such a subpacket found in the unhashed section would open itself to an attack where the recipient's certificate is tampered with to encourage the use of a specific cipher or mode of operation.¶

13.14. Malicious Compressed Data

It is possible to form a compression quine that produces itself upon decompression, leading to infinite regress in any implementation willing to parse arbitrary numbers of layers of compression. This could cause resource exhaustion, which itself could lead to termination by the operating system. If the operating system would create a "crash report", that report could contain confidential information.¶

An OpenPGP implementation SHOULD limit the number of layers of compression it is willing to decompress in a single message.¶

14.1. Constrained Legacy Fingerprint Storage for v6 Keys

Some OpenPGP implementations have fixed length constraints for key fingerprint storage that will not fit all 32 octets of a v6 fingerprint. For example, [OPENPGPCARD] reserves 20 octets for each stored fingerprint.¶

An OpenPGP implementation MUST NOT attempt to map any part of a v6 fingerprint to such a constrained field unless the relevant specification for the constrained environment has explicit guidance for storing a v6 fingerprint that distinguishes it from a v4 fingerprint. An implementation interacting with such a constrained field SHOULD directly calculate the v6 fingerprint from public key material and associated metadata instead of relying on the constrained field.¶

15.1. Renamed Protocol Group

IANA bundles a set of registries associated with a particular protocol into a "protocol group". IANA has updated the name of the "Pretty Good Privacy (PGP)" protocol group (i.e., the group of registries described at <https://www.iana.org/assignments/pgp-parameters>) to "OpenPGP". IANA has arranged a permanent redirect from the existing URL to the new URL for the registries in this protocol group. All further updates specified below are for registries within this same OpenPGP protocol group.¶

15.2. Renamed and Updated Registries

IANA has renamed the "PGP String-to-Key (S2K)" registry to "OpenPGP String-to-Key (S2K) Types" and updated its content as shown in Table 1.¶

IANA has renamed the "PGP Packet Types/Tags" registry to "OpenPGP Packet Types" and updated its content as shown in Table 3.¶

IANA has renamed the "PGP User Attribute Types" registry to "OpenPGP User Attribute Subpacket Types" and updated its content as shown in Table 13.¶

IANA has renamed the "Image Format Subpacket Types" registry to "OpenPGP Image Attribute Encoding Format" and updated its content as shown in Table 15.¶

IANA has renamed the "Key Server Preference Extensions" registry to "OpenPGP Key Server Preference Flags" and updated its contents as shown in Table 8.¶

IANA has renamed the "Reason for Revocation Extensions" registry to "OpenPGP Reason for Revocation Code" and updated its contents as shown in Table 10.¶

IANA has renamed the "Key Flags Extensions" registry to "OpenPGP Key Flags" and updated its contents as shown in Table 9.¶

IANA has renamed the "Implementation Features" registry to "OpenPGP Features Flags" and updated its contents as shown in Table 11.¶

IANA has renamed the "Public Key Algorithms" registry to "OpenPGP Public Key Algorithms" and updated its contents as shown in Table 18.¶

IANA has renamed the "Symmetric Key Algorithms" registry to "OpenPGP Symmetric Key Algorithms" and updated its contents as shown in Table 22.¶

IANA has renamed the "Compression Algorithms" registry to "OpenPGP Compression Algorithms" and updated its contents as shown in Table 23.¶

IANA has renamed the "Hash Algorithms" registry to "OpenPGP Hash Algorithms" and updated its contents as shown in Table 24.¶

IANA has renamed the "Signature Subpacket Types" registry to "OpenPGP Signature Subpacket Types" and updated its contents as shown in Table 5.¶

15.3. Removed Registry

IANA has marked the empty "New Packet Versions" registry as OBSOLETE.¶

A tombstone note has been added to the OpenPGP protocol group with the following content:¶

Those wishing to use the removed "New Packet Versions" registry should instead register new versions of the relevant packets in the "OpenPGP Key and Signature Versions", "OpenPGP Key ID and Fingerprint", and "OpenPGP Encrypted Message Packet Versions" registries.¶

15.4. Added Registries

IANA has added the following registries in the OpenPGP protocol group. Note that the initial contents of each registry is shown in the corresponding table.¶

• "OpenPGP Secret Key Encryption (S2K Usage Octet)" (Table 2).¶

• "OpenPGP Signature Types" (Table 4).¶

• "OpenPGP Signature Notation Data Subpacket Notation Flags" (Table 6).¶

• "OpenPGP Signature Notation Data Subpacket Types" (Table 7).¶

• "OpenPGP Key ID and Fingerprint" (Table 12).¶

• "OpenPGP Image Attribute Version" (Table 14).¶

• "OpenPGP Armor Header Line" (Table 16).¶

• "OpenPGP Armor Header Key" (Table 17).¶

• "OpenPGP ECC Curve OID and Usage" (Table 19).¶

• "OpenPGP ECC Curve-Specific Wire Formats" (Table 21).¶

• "OpenPGP Hash Algorithm Identifiers for RSA Signatures' Use of EMSA-PKCS1-v1_5 Padding" (Table 25).¶

• "OpenPGP AEAD Algorithms" (Table 26).¶

• "OpenPGP Encrypted Message Packet Versions" (Table 27).¶

• "OpenPGP Key and Signature Versions" (Table 28).¶

• "OpenPGP Elliptic Curve Point Wire Formats" (Table 29).¶

• "OpenPGP Elliptic Curve Scalar Encodings" (Table 30).¶

• "OpenPGP ECDH KDF and KEK Parameters" (Table 31).¶

15.5. Registration Policies

All registries within the OpenPGP protocol group, with the exception of the registries listed in Section 15.5.1, use the Specification Required registration policy; see Section 4.6 of [RFC8126]. This policy means that review and approval by a designated expert is required and that the IDs and their meanings must be documented in a permanent and readily available public specification, in sufficient detail, so that interoperability between independent implementations is possible.¶

15.6. Designated Experts

The designated experts will determine whether the new registrations retain the security properties that are expected by the base implementation and whether these new registrations do not cause interoperability issues with existing implementations, other than not producing or consuming the IDs associated with these new registrations. Registration proposals that fail to meet these criteria could instead be proposed as new work items for the OpenPGP Working Group or its successor.¶

The subsections below describe specific guidance for classes of registry updates that a designated expert will consider.¶

The designated experts should also consider Section 12.11 when reviewing proposed additions to the OpenPGP protocol group.¶