IANA Registry Updates for OpenPGP

This document instructs IANA to make changes to a number of OpenPGP-related IANA registries . These changes were motivated by recently proposed extensions to OpenPGP. Modelled after , the document performs a similar function in modifying existing IANA registry policies for OpenPGP . The changes introduced by this document are intended to be comprehensive, proposed after a thorough review of existing registry policy and values. Changes include updating of registry policy, filling in missing values, providing recommendation of registered items and general housekeeping. The document lists out each OpenPGP registry individually and provides the rationale for changes and the required changes themselves. Specifically, the following changes are pursued: Alignment of registry policies with ; Consistency of existing OpenPGP registries, for example, some registries have the prefix "PGP" while some others don’t; Missing values in registries while having been defined in <<RFC4880>; Creating a missed registry defined in , namely the "OpenPGP Signature Notation Data Subpacket Flags" registry; A number of references in the registries point to documents that detail a certain algorithm, but should refer to a document (and the relevant section if appropriate) that details the implementation requirements of that algorithm within the context of OpenPGP.

The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in BCP 14 when, and only when, they appear in all capitals, as shown here. The key words "Private Use", "Experimental Use", "Hierarchical Allocation", "First Come First Served", "Expert Review", "Specification Required", "RFC Required", "IETF Review", "Standards Action" and "IESG Approval" in this document are to be interpreted as described in Section 4 of .

The OpenPGP IANA registries and their policies defined in pre-date which defined the term "IETF Review" instead of the now-outdated term "IETF Consensus" . This draft updates policies of the OpenPGP IANA registries to align with the terms specified in .

Registry names of IANA OpenPGP registries SHOULD be consistent. The following registries originally have the "PGP" prefix, and the prefix SHOULD be changed to "OpenPGP": PGP String-to-Key (S2K) Registry () PGP Packet Types/Tags Registry () PGP User Attribute Types Registry () The prefix "OpenPGP" SHOULD be added to the following registries: Image Format Subpacket Types Registry () Signature Subpacket Types Registry () Signature Notation Data Subpacket Notation Types Registry () Key Server Preference Extensions Registry () Reason for Revocation Extensions Registry () Implementation Features Registry () New Packet Versions Registry () Public Key Algorithms Registry () Symmetric Key Algorithms Registry () Hash Algorithms Registry () Compression Algorithms Registry () This renaming is not necessary for the "OpenPGP Signature Notation Data Subpacket Notation Flags Registry" () since it is newly created according to this convention. For specific recommendations, please see the corresponding sections in .

The feature set of OpenPGP is an evolving one. In some cases, it has been unclear whether implementation of a certain feature would actually be beneficial for interoperability or create fragmentation of implementations. Moreover, the fast-moving nature of cryptography directly impacts the security of OpenPGP implementations, and an algorithm once considered secure may be subject to cryptanalytic results that advise otherwise. For example, this has been demonstrated by the widespread obsolescence of SHA-1 . It is therefore beneficial for all OpenPGP interested parties that implementers can follow a stable reference on what is considered best practice in OpenPGP implementations. There are two types of recommendations considered here: Recommended for security (abbreviated as "REC-S" in this document) Recommended for interoperability (abbreviated as "REC-I" in this document)

Recommendations for security are usually critical and urgent. The following registries shall have the "Security Recommendation" column added: PGP String-to-Key (S2K) Registry Public Key Algorithms Registry Symmetric Key Algorithms Registry Hash Algorithms Registry The allowed values for this column are: Yes: Recommended, this algorithm is considered secure; No: Not recommended, this algorithm is considered insecure; Empty: No comment, there is no recommendation on this algorithm. A "Security Recommendation" MUST only be accepted through an Expert Review described in .

Cryptographic algorithms and parameters will be broken or weakened over time. Blindly implementing cipher suites listed in the registries is not advised. Implementers and users SHOULD check that the cryptographic algorithms listed continue to provide the expected level of security.

Recommendations for interoperability are generally less urgent but greatly beneficial for the OpenPGP user experience. The following registries shall have the "Interoperability Recommendation" column added: PGP String-to-Key (S2K) Registry PGP Packet Types/Tags Registry PGP User Attribute Types Registry Image Format Subpacket Types Registry Signature Subpacket Types Registry Key Server Preference Extensions Registry Reason for Revocation Extensions Registry Implementation Features Registry New Packet Versions Registry Key Flags Extensions Registry Public Key Algorithms Registry Symmetric Key Algorithms Registry Hash Algorithms Registry Compression Algorithms Registry The allowed values for this column are: Yes: Recommended, implementation of this feature enhances interoperability for OpenPGP; No: Not recommended, implementation of this feature reduces interoperability for OpenPGP; Empty: No comment, there is no recommendation on this feature on interoperability. An "Interoperability Recommendation" MUST only be accepted through an Expert Review described in .

An item not marked as "Recommended" does not mean it is "Not Recommended". This could simply be a reflection that this item has not been through Expert Review, has limited applicability, is intended only for specific use cases, or for other reasons. Not all newly defined parameters in a Standards Track document need to be marked as "Recommended".

Proposed changes to the registry: Rename the registry to "OpenPGP String-to-Key (S2K) Algorithms" Change registry policy to Specification Required. Update its "Reference" to also refer to this document. A Standards Track document is required to register an S2K algorithm with the value "Yes" in any recommendation. Add the following note:

Update the following registrations: ID S2K Type REC-S REC-I Reference 0 Simple S2K No Yes Section 3.7.1.1 of 1 Salted S2K No Yes Section 3.7.1.2 of 2 Reserved Section 3.7.1 of 3 Iterated and Salted S2K Yes Yes Section 3.7.1.3 of 4-99 Unassigned 100-110 Private or Experimental Use Section 3.7.1 of 111-255 Unassigned

Proposed changes to the registry: Rename the registry to "OpenPGP Packet Types" Rename the column "Attribute" to "Packet Type" Change registry policy to RFC Required. Update its "Reference" to also refer to this document. A Standards Track document is required to register a Packet Type with the value "Yes" in any recommendation. Add the following note:

Update the following registrations: Value Packet Type REC-S REC-I Reference 0 Reserved - a packet tag MUST NOT have this value No Yes 1 Public-Key Encrypted Session Key Packet Yes Yes 2 Signature Packet Yes Yes 3 Symmetric-Key Encrypted Session Key Packet Yes Yes 4 One-Pass Signature Packet Yes Yes 5 Secret Key Packet Yes Yes 6 Public Key Packet Yes Yes 7 Secret Subkey Packet Yes Yes 8 Compressed Data Packet Yes Yes 9 Symmetrically Encrypted Data Packet No Yes 10 Marker Packet No No 11 Literal Data Packet No Yes 12 Trust Packet No 13 User ID Packet Yes 14 Public Subkey Packet Yes Yes 15-16 Unknown 17 User Attribute Packet Yes 18 Sym. Encrypted and Integrity Protected Data Packet Yes Yes 19 Modification Detection Code Packet Yes Yes 20-59 Unassigned 60-63 Private or Experimental Use

Proposed changes to the registry: Rename the registry to "OpenPGP User Attribute Subpacket Types" Rename the column "Attribute" to "User Attribute Type" Change registry policy to Specification Required. Update its "Reference" to also refer to this document. A Standards Track document is required to register an Attribute Type algorithm with the value "Yes" in any recommendation. Add the following note:

Update the following registrations: Value Attribute Type REC-I Reference 0 Reserved 1 image Yes 2-99 Unassigned 100-110 Private or Experimental Use 111-255 Unassigned

Proposed changes to the registry: Rename the registry to "OpenPGP Image Format Subpacket Types" Rename the column "Attribute" to "Image Format Type" Change registry policy to Specification Required. Update its "Reference" to also refer to this document. A Standards Track document is required to register a Packet Type/Tag with the value "Yes" in any recommendation. Add the following note:

Update the following registrations: Value Image Format Type REC-I Reference 0 Reserved 1 JPEG Yes 2-99 Unassigned 100-110 Private or Experimental Use 111-255 Unassigned

Proposed changes to the registry: Rename the registry to "OpenPGP Signature Subpacket Types". Rename the column "Attribute" to "Signature Subpacket Type" Change registry policy to Specification Required. Update its "Reference" to also refer to this document. A Standards Track document is required to register a Signature Subpacket Type with the value "Yes" in any recommendation. Add the following note:

Update the following registrations: Value Image Format Type REC-I Reference 0-1 Reserved 2 Signature Creation Time Yes 3 Signature Expiration Time Yes 4 Exportable Certification Yes 5 Trust Signature Yes 6 Regular Expression 7 Revocable Yes 8 Reserved 9 Key Expiration Time Yes 11 Preferred Symmetric Algorithms Yes 12 Revocation Key Yes 13-15 Reserved 16 Issuer Key ID Yes 17-19 Reserved 20 Notation Data Yes 21 Preferred Hash Algorithms Yes 22 Preferred Compression Algorithms Yes 23 Key Server Preferences 24 Preferred Key Server 25 Primary User ID Yes 26 Policy Uri 27 Key Flags Yes 28 Signer’s User ID Yes 29 Reason For Revocation Yes 30 Features Yes 31 Signature Target Yes 32 Embedded Signature Yes 33-99 Unassigned 100-110 Private or Experimental Use 111-127 Unassigned

This registry is currently empty. However, the existing IANA registry contains an erroneous note that the registry is about "User Notations". According to which defined this registry, "[n]otations contain a user space that is completely unmanaged". This registry should be for the "IETF (name)space". Proposed changes to the registry: Rename the registry to "OpenPGP Notation Data Subpacket Notation Types". Change registry policy to Specification Required. Update its "Reference" to also refer to this document. Update its erroneous "Note" that says:

To:

Proposed changes to the registry: Rename the registry to "OpenPGP Key Server Preferences" Rename the column "First octet" to "Flag" Add a column "Octet Ordinal" to indicate the ordinal of the octet of which the "Flag" field is read from. Rename the column "Extension" to "Description" Change registry policy to Specification Required. Update its "Reference" to also refer to this document. A Standards Track document is required to register an item with the value "Yes" in any recommendation. Add the following note:

Update existing registrations: Octet Ordinal Flag Description REC-I Reference 1 0x01 Unassigned 1 0x02 Unassigned 1 0x04 Unassigned 1 0x08 Unassigned 1 0x10 Unassigned 1 0x20 Unassigned 1 0x40 Unassigned 1 0x80 No-Modify Yes Section 5.3.2.17 of 2- Unassigned

Proposed changes to the registry: Rename the registry to "OpenPGP Reasons for Revocation" Rename the column "Flag" to "Reason" Change registry policy to Specification Required. Update its "Reference" to also refer to this document. A Standards Track document is required to register an item with the value "Yes" in any recommendation. Add the following note:

Update the following registrations: Value Reason REC-I Reference 0 No reason specified (key revocations or cert revocations) Yes Section 5.2.3.23 of 1 Key is superseded (key revocations) Yes Section 5.2.3.23 of 2 Key material has been compromised (key revocations) Yes Section 5.2.3.23 of 3 Key is retired and no longer used (key revocations) Yes Section 5.2.3.23 of 4-31 Unassigned Section 5.2.3.23 of 32 User ID information is no longer valid (cert revocations) Yes Section 5.2.3.23 of 33-99 Unassigned 100-110 Private Use Section 5.2.3.23 of 111-255 Unassigned

Proposed changes to the registry: Rename the registry to "OpenPGP Features" Mark value "First Octet, 0x80" as "Private Use" in the registry. Rename the column "Value" to "Flag" Add a column "Octet Ordinal" to indicate the ordinal of the octet of which the "Flag" field is read from. Change registry policy to Specification Required. Update its "Reference" to also refer to this document. A Standards Track document is required to register an item with the value "Yes" in any recommendation. Add the following note:

Update the following registrations: Octet Ordinal Flag Feature REC-S REC-I Reference 1 0x01 Modification Detection (packets 18 and 19) Yes Yes Section 5.2.3.24 of 1 0x02 Unassigned 1 0x04 Unassigned 1 0x08 Unassigned 1 0x10 Unassigned 1 0x20 Unassigned 1 0x40 Unassigned 1 0x80 Unassigned 2- Unassigned

This registry is currently empty. Proposed changes to the registry: Rename the registry to "OpenPGP Packet Type Versions" It should have the following columns: "Packet Type", "Version", "Security Recommended", "Interoperability Recommended", "Reference" Change registry policy to RFC Required. Update its "Reference" to also refer to this document. Add the following note:

A Standards Track document is required to register a Packet Type with the value "Yes" in any recommendation. Add in the existing (but missing) registrations: Packet Type Version REC-S REC-I Reference 1 3 Yes Yes Section 5.1 of 2 3 No Yes Section 5.2.2 of 2 4 Yes Yes Section 5.2.3 of 3 4 Yes Yes Section 5.3 of 4 3 Yes Yes Section 5.4 of 5 3 Yes Yes Section 5.5.1.3 of 5 4 Yes Yes Section 5.5.1.3 of 6 3 Yes Yes Section 5.5.1.1 of 6 4 Yes Yes Section 5.5.1.1 of 7 3 Yes Yes Section 5.5.1.4 of 7 4 Yes Yes Section 5.5.1.4 of 14 3 Yes Yes Section 5.5.1.2 of 14 4 Yes Yes Section 5.5.1.2 of 18 1 Yes Yes Section 5.13 of

Proposed changes to the registry: Rename the registry to "OpenPGP Key Flags" Rename the column "Value" to "Flag" Add a column "Octet Ordinal" to indicate the ordinal of the octet of which the "Flag" field is read from. Rename the column "Extension" to "Description" Mark value "First Octet, 0x40" as "Unassigned" in the registry. Remove ending periods for all values in "Description" for consistency with other registries. Change registry policy to Specification Required. Update its "Reference" to also refer to this document. A Standards Track document is required to register an item with the value "Yes" in any recommendation. Add the following note:

Update existing registrations: Octet Ordinal Flag Description REC-I Reference 1 0x01 This key may be used to certify other keys Yes Section 5.2.3.21 of 1 0x02 This key may be used to sign data Yes Section 5.2.3.21 of 1 0x04 This key may be used to encrypt communications Yes Section 5.2.3.21 of 1 0x08 This key may be used to encrypt storage Yes Section 5.2.3.21 of 1 0x10 The private component of this key may have been split by a secret-sharing mechanism Yes Section 5.2.3.21 of 1 0x20 This key may be used for authentication Yes Section 5.2.3.21 of 1 0x40 Unassigned 1 0x80 The private component of this key may be in the possession of more than one person Yes Section 5.2.3.21 of

Proposed changes to the registry: Rename registry to "OpenPGP Public Key Algorithms". Change registry policy to Specification Required. Update its "Reference" to also refer to this document. A Standards Track document is required to register an item with the value "Yes" in any recommendation. Existing registrations with a "Reference" value pointing to a non-IETF published document should be checked to see if an IETF-published document is available, and if so, update the reference to point to the IETF-published document instead for consistency. Add the following note:

Update the following registrations: ID Algorithm REC-S REC-I Reference 1 RSA (Encrypt or Sign) Yes Yes Section 13.5 of 2 RSA Encrypt-Only No Section 13.5 of 3 RSA Sign-Only No Section 13.5 of 4-15 Unassigned Section 13.5 of 16 Elgamal (Encrypt-Only) Yes Yes 17 DSA (Digital Signature Algorithm) Yes Yes Section 13.6 of 18 ECDH public key algorithm Yes Yes 19 ECDSA public key algorithm Yes Yes 20 Reserved (formerly Elgamal Encrypt or Sign) Section 9.1 of 21 Reserved for Diffie-Hellman (X9.42, as defined for IETF-S/MIME) Section 9.1 of 22-99 Unassigned 100-110 Private or Experimental Use Section 13.5 of 111-255 Unassigned

Proposed changes to the registry: Rename registry to "OpenPGP Symmetric Key Algorithms". Algorithm descriptions have been simplified and applicable references moved to the "Reference" column. All algorithm descriptions with "[n+] bit" is updated to "[n+]-bit" for consistency, for example, the phrase "128 bit key" becomes "128-bit key". Change registry policy to Specification Required. Update its "Reference" to also refer to this document. A Standards Track document is required to register an item with the value "Yes" in any recommendation. Existing registrations with a "Reference" value pointing to a non-IETF published document should be checked to see if an IETF-published document is available, and if so, update the reference to point to the IETF-published document instead for consistency. Add the following note:

Update the following registrations: ID Algorithm REC-S REC-I Reference 0 Plaintext Yes Section 13.4 of 1 IDEA No No Section 6.4.1 of 2 TripleDES (DES-EDE, 168-bit key derived from 192-bit key) No Yes Section 13.2 of 3 CAST5 (128-bit key) No Yes Section 9.2 of 4 Blowfish (128-bit key, 16 rounds) Section 9.2 of 5-6 Reserved Section 9.1 of 7 AES with 128-bit key Yes Yes Section 9.2 of 8 AES with 192-bit key Yes Section 9.2 of 9 AES with 256-bit key Yes Yes Section 9.2 of 10 Twofish with 256-bit key Section 9.2 of 11 Camellia with 128-bit key 12 Camellia with 192-bit key 13 Camellia with 256-bit key 14-99 Unassigned 100-110 Private or Experimental Use Section 9.2 of 111-255 Unassigned

Proposed changes to the registry: Rename registry to "OpenPGP Hash Key Algorithms". Change registry policy to Specification Required. Update its "Reference" to also refer to this document. A Standards Track document is required to register an item with the value "Yes" in any recommendation. Existing registrations with a "Reference" value pointing to a non-IETF published document should be checked to see if an IETF-published document is available, and if so, update the reference to point to the IETF-published document instead for consistency. Add the following note:

Update the following registrations: ID Algorithm Text Name REC-S REC-I Reference 1 MD5 "MD5" No No Section 9.4 of 2 SHA-1 "SHA1" No Yes Section 9.4 of 3 RIPE-MD/160 "RIPEMD160" Yes Section 9.4 of 4-7 Reserved Section 9.4 of 8 SHA256 "SHA256" Yes Yes Section 9.4 of 9 SHA384 "SHA384" Yes Section 9.4 of 10 SHA512 "SHA512" Yes Yes Section 9.4 of 11 SHA224 "SHA224" Yes Section 9.4 of 12-99 Unassigned 100-110 Private or Experimental Use Section 9.4 of 111-255 Unassigned

Proposed changes to the registry: Rename registry to "OpenPGP Compression Key Algorithms". Change registry policy to Specification Required. Update its "Reference" to also refer to this document. A Standards Track document is required to register an item with the value "Yes" in any recommendation. Existing registrations with a "Reference" value pointing to a non-IETF published document should be checked to see if an IETF-published document is available, and if so, update the reference to point to the IETF-published document instead for consistency. Add the following note:

Update the following registrations: ID Algorithm REC-I Reference 0 Uncompressed Yes Section 9.3 of 1 ZIP Yes Section 9.3 of 2 ZLIB Yes Section 9.3 of 3 BZip2 Section 9.3 of 4-99 Unassigned 100-110 Private or Experimental Use Section 9.3 of 111-255 Unassigned

This registry is created in accordance with Section 5.2.3.16 of . The registry: Contain the columns "Flag", "Description", "Security Recommended", "Interoperability Recommended", Reference" Registry policy is Specification Required. Its "Reference" should refer to and this document. Add the following note:

The registry SHOULD be initialized to the following values: Octet Ordinal Flag Description REC-S REC-I Reference 1 0x01 Unassigned. Section 5.2.3.16 of 1 0x02 Unassigned. Section 5.2.3.16 of 1 0x04 Unassigned. Section 5.2.3.16 of 1 0x08 Unassigned. Section 5.2.3.16 of 1 0x10 Unassigned. Section 5.2.3.16 of 1 0x20 Unassigned. Section 5.2.3.16 of 1 0x40 Unassigned. Section 5.2.3.16 of 1 0x80 This note value is human-readable text. Yes Section 5.2.3.16 of

Registration requests for a Specification Required and Expert Review registry must be submitted to the Expert Pool () through the openpgp-reg-review@ietf.org mailing list. The registration request will be deemed successful after three approved Expert Reviews (), and the Designated Experts will request IANA to register the proposed registration.

Registration requests sent to the mailing list for review SHOULD use an appropriate subject (e.g., "Registration request: new algorithm in Symmetric Encryption registry"). Within the review period, the Designated Experts will either approve or deny the registration request, communicating this decision to the review list and IANA.

An outcome of a registration request is determined by results of Expert Reviews (). A registration request is approved once it receives a minimum of three Expert Reviews that result in approval. The outcomes of a request review are: Approval: once there are three approved Designated Expert reviews within the review period; Denial: there have been more than three Designated Expert reviews within the review period but have not met the approval threshold of three approvals.

To allow for the allocation of values prior to publication, Designated Experts MAY approve a temporary registration once they are satisfied that such a specification will be published. This temporary registration has a 1 year validity, of which when expired will be automatically revoked. Once the specification that the proposal relies is published within this period, the Designated Experts SHOULD request IANA to convert this registration to an official one.

Designated Experts are responsible for performing registration request reviews for Expert Review and Specification Required IANA OpenPGP registries.

IANA MUST only accept registry updates from the Designated Experts and SHOULD direct all requests for registration to the review mailing list.

A Designated Expert SHOULD have a thorough understanding, demonstrated knowledge and experience of OpenPGP and its Standards Track extensions.

Designated Experts are judged and selected by the IETF Area Director of which the "openpgp" workgroup belongs. The selected pool of Designated Experts SHOULD be able to represent the perspectives of different applications using this specification, in order to enable broadly informed review of registration decisions.

On submission of a review request, five Designated Experts are sought out for the review of the request. These Designated Experts must provide a review decision response within 21 days of submission. If less than three Designated Experts have performed a review by the end of that period, an extension of 21 days will be granted and extra Designated Experts selected to complete the review. In cases where a review assignment could be perceived as creating a conflict of interest for a particular Designated Expert, that Designated Expert SHOULD defer review responsibility to another Designated Expert, as described in Section 5.2 of .

A Designated Expert MUST take the following criteria into account when reviewing registration requests. For Specification Required registries: whether the proposed registration duplicates existing functionality; the clarity of the proposed registration description; whether the specification of the proposed registration item is publicly available; whether the proposed registration would affect the security of users of OpenPGP; and whether the proposed registration is likely to be of general applicability.

Approvals MUST include an explanation. Denials MUST include an explanation and, if applicable, constructive suggestions as to how to make the request successful. A Designated Expert MAY elect to provide more in depth reviews than required. Their review should not be taken as an endorsement of the feature or underlying primitives, such as cryptographic algorithms used by a registration.

The review appeals process is in accordance with 10, which specifies that the normal IETF appeals process as described in Section 6.5 of should be followed. Review appeals SHOULD be directly brought to the IESG for resolution through the iesg@ietf.org mailing list. The following issues are eligible for the appeals process: Registration requests that have not received any Designated Expert reviews for a period longer than 21 days. A review was performed by an inappropriate Designated Expert, for example, who is strongly suspected of a conflict of interest or has demonstrated unprofessional behavior or impartiality.

The change to Specification Required from IETF Review lowers the barrier to add functionality and cryptographic algorithms for OpenPGP. For registries that involve cryptographic algorithms, this change reflects the practical reality in that the "openpgp" mailing list is not responsible for cryptographic reviews, which is especially difficult for national cipher suites. Security Recommended algorithms are regarded as secure for general use at the time of registration. However, since cryptographic algorithms and parameters will be broken or weakened over time, it MAY be possible that the recommended status in the registry lags behind the most recent advances in cryptanalysis. Implementers and users SHOULD check that the cryptographic algorithms listed continue to provide the expected level of security desired.

This document specifies a number of changes to the IANA OpenPGP registries.

The authors would like to thank the following individuals for making this document possible: Security Area Directors: Eric Rescola and Kathleen Moriarty; The inaugural SECDISPATCH chairs: Tim Polk, Nancy Cam-Winget and Russ Housley; Supporters of this revision scheme: Rich Salz, Sean Leonard, Richard Barnes, and Daniel Kahn Gillmor.