idnits 2.17.1 draft-openpgp-iana-registry-updates-01.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- No issues found here. Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- No issues found here. Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- == There are 23 instances of lines with non-RFC6890-compliant IPv4 addresses in the document. If these are example addresses, they should be changed. -- The draft header indicates that this document updates RFC4880, but the abstract doesn't seem to directly say this. It does mention RFC4880 though, so this could be OK. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust and authors Copyright Line does not match the current year == The document seems to lack the recommended RFC 2119 boilerplate, even if it appears to use RFC 2119 keywords. (The document does seem to have the reference to RFC 2119 which the ID-Checklist requires). (Using the creation date from RFC4880, updated by this document, for RFC5378 checks: 1999-12-21) -- The document seems to lack a disclaimer for pre-RFC5378 work, but may have content which was first submitted before 10 November 2008. If you have contacted all the original authors and they are all willing to grant the BCP78 rights to the IETF Trust, then this is fine, and you can ignore this comment. If not, you may need to add the pre-RFC5378 disclaimer. (See the Legal Provisions document at https://trustee.ietf.org/license-info for more information.) -- The document date (April 13, 2018) is 2205 days in the past. Is this intentional? Checking references for intended status: Informational ---------------------------------------------------------------------------- == Unused Reference: 'RFC2440' is defined on line 1402, but no explicit reference was found in the text == Outdated reference: A later version (-05) exists of draft-ietf-tls-iana-registry-updates-04 -- Obsolete informational reference (is this intentional?): RFC 1991 (Obsoleted by RFC 4880) -- Obsolete informational reference (is this intentional?): RFC 2434 (Obsoleted by RFC 5226) -- Obsolete informational reference (is this intentional?): RFC 2440 (Obsoleted by RFC 4880) Summary: 0 errors (**), 0 flaws (~~), 5 warnings (==), 6 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 Security Area Advisory Group R. Tse 3 Internet-Draft Ribose 4 Updates: 4880 (if approved) W. Koch 5 Intended status: Informational April 13, 2018 6 Expires: October 15, 2018 8 IANA Registry Updates for OpenPGP 9 draft-openpgp-iana-registry-updates-01 11 Abstract 13 This document describes a number of changes to the OpenPGP (RFC 4880) 14 IANA registries that range from adding notes to the registry to 15 changing registration policies. These changes were motivated by 16 recently proposed extensions to OpenPGP. Existing IANA OpenPGP 17 registry policies are defined by RFC 4880. 19 Status of This Memo 21 This Internet-Draft is submitted in full conformance with the 22 provisions of BCP 78 and BCP 79. 24 Internet-Drafts are working documents of the Internet Engineering 25 Task Force (IETF). Note that other groups may also distribute 26 working documents as Internet-Drafts. The list of current Internet- 27 Drafts is at https://datatracker.ietf.org/drafts/current/. 29 Internet-Drafts are draft documents valid for a maximum of six months 30 and may be updated, replaced, or obsoleted by other documents at any 31 time. It is inappropriate to use Internet-Drafts as reference 32 material or to cite them other than as "work in progress." 34 This Internet-Draft will expire on October 15, 2018. 36 Copyright Notice 38 Copyright (c) 2018 IETF Trust and the persons identified as the 39 document authors. All rights reserved. 41 This document is subject to BCP 78 and the IETF Trust's Legal 42 Provisions Relating to IETF Documents 43 (https://trustee.ietf.org/license-info) in effect on the date of 44 publication of this document. Please review these documents 45 carefully, as they describe your rights and restrictions with respect 46 to this document. Code Components extracted from this document must 47 include Simplified BSD License text as described in Section 4.e of 48 the Trust Legal Provisions and are provided without warranty as 49 described in the Simplified BSD License. 51 Table of Contents 53 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 3 54 2. Terms and Definitions . . . . . . . . . . . . . . . . . . . . 4 55 3. Alignment Amongst OpenPGP Registries . . . . . . . . . . . . 4 56 3.1. Policy Conventions Given In RFC 8126 . . . . . . . . . . 4 57 3.2. Registry Naming . . . . . . . . . . . . . . . . . . . . . 4 58 4. Providing Recommendations Via The "Recommended" Column . . . 5 59 4.1. Security Recommendations . . . . . . . . . . . . . . . . 6 60 4.1.1. Weakening Of Cryptographic Algorithms And Parameters 6 61 4.2. Interoperability Recommendations . . . . . . . . . . . . 6 62 4.3. No Recommendation . . . . . . . . . . . . . . . . . . . . 7 63 5. IANA OpenPGP Registries . . . . . . . . . . . . . . . . . . . 8 64 5.1. PGP String-to-Key (S2K) Registry . . . . . . . . . . . . 8 65 5.2. PGP Packet Types/Tags Registry . . . . . . . . . . . . . 8 66 5.3. PGP User Attribute Types Registry . . . . . . . . . . . . 10 67 5.4. Image Format Subpacket Types Registry . . . . . . . . . . 10 68 5.5. Signature Subpacket Types Registry . . . . . . . . . . . 11 69 5.6. Signature Notation Data Subpacket Notation Types Registry 12 70 5.7. Key Server Preference Extensions Registry . . . . . . . . 13 71 5.8. Reason for Revocation Extensions Registry . . . . . . . . 14 72 5.9. Implementation Features Registry . . . . . . . . . . . . 15 73 5.10. New Packet Versions Registry . . . . . . . . . . . . . . 16 74 5.11. Key Flags Extensions Registry . . . . . . . . . . . . . . 18 75 5.12. Public Key Algorithms Registry . . . . . . . . . . . . . 19 76 5.13. Symmetric Key Algorithms Registry . . . . . . . . . . . . 21 77 5.14. Hash Algorithms Registry . . . . . . . . . . . . . . . . 22 78 5.15. Compression Algorithms Registry . . . . . . . . . . . . . 24 79 5.16. New Registry: OpenPGP Signature Notation Data Subpacket 80 Notation Flags Registry . . . . . . . . . . . . . . . . . 25 81 6. Registries With The "Specification Required" Policy . . . . . 26 82 6.1. Registration Request Procedure . . . . . . . . . . . . . 27 83 6.2. Registration Request Outcome . . . . . . . . . . . . . . 27 84 6.3. Temporary Registrations . . . . . . . . . . . . . . . . . 27 85 7. Designated Experts . . . . . . . . . . . . . . . . . . . . . 27 86 7.1. IANA Registration . . . . . . . . . . . . . . . . . . . . 28 87 7.2. Eligibility Criteria . . . . . . . . . . . . . . . . . . 28 88 7.3. Selection Criteria And Pool . . . . . . . . . . . . . . . 28 89 7.4. Designated Expert Review . . . . . . . . . . . . . . . . 28 90 7.4.1. Review Procedure . . . . . . . . . . . . . . . . . . 28 91 7.4.2. Review Criteria . . . . . . . . . . . . . . . . . . . 28 92 7.5. Review Outcomes . . . . . . . . . . . . . . . . . . . . . 29 93 7.6. Review Appeals . . . . . . . . . . . . . . . . . . . . . 29 94 8. Security Considerations . . . . . . . . . . . . . . . . . . . 29 95 9. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 30 96 10. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 30 97 11. References . . . . . . . . . . . . . . . . . . . . . . . . . 30 98 11.1. Normative References . . . . . . . . . . . . . . . . . . 30 99 11.2. Informative References . . . . . . . . . . . . . . . . . 31 100 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 32 102 1. Introduction 104 This document instructs IANA to make changes to a number of OpenPGP- 105 related IANA registries [RFC4880]. These changes were motivated by 106 recently proposed extensions to OpenPGP. 108 Modelled after [I-D.ietf-tls-iana-registry-updates], the document 109 performs a similar function in modifying existing IANA registry 110 policies for OpenPGP [RFC4880]. 112 The changes introduced by this document are intended to be 113 comprehensive, proposed after a thorough review of existing registry 114 policy and values. Changes include updating of registry policy, 115 filling in missing values, providing recommendation of registered 116 items and general housekeeping. 118 The document lists out each OpenPGP registry individually and 119 provides the rationale for changes and the required changes 120 themselves. 122 Specifically, the following changes are pursued: 124 o Alignment of registry policies with [RFC8126]; 126 o Consistency of existing OpenPGP registries, for example, some 127 registries have the prefix "PGP" while some others don't; 129 o Missing values in registries while having been defined in 130 <; 132 o Creating a missed registry defined in [RFC4880], namely the 133 "OpenPGP Signature Notation Data Subpacket Flags" registry; 135 o A number of references in the registries point to documents that 136 detail a certain algorithm, but should refer to a document (and 137 the relevant section if appropriate) that details the 138 implementation requirements of that algorithm within the context 139 of OpenPGP. 141 2. Terms and Definitions 143 The key words "*MUST*", "*MUST NOT*", "*REQUIRED*", "*SHALL*", 144 "*SHALL NOT*", "*SHOULD*", "*SHOULD NOT*", "*RECOMMENDED*", "*NOT 145 RECOMMENDED*", "*MAY*", and "*OPTIONAL*" in this document are to be 146 interpreted as described in BCP 14 [RFC2119] [RFC8174] when, and only 147 when, they appear in all capitals, as shown here. 149 The key words "*Private Use*", "*Experimental Use*", "*Hierarchical 150 Allocation*", "*First Come First Served*", "*Expert Review*", 151 "*Specification Required*", "*RFC Required*", "*IETF Review*", 152 "*Standards Action*" and "*IESG Approval*" in this document are to be 153 interpreted as described in Section 4 of [RFC8126]. 155 3. Alignment Amongst OpenPGP Registries 157 3.1. Policy Conventions Given In RFC 8126 159 The OpenPGP IANA registries and their policies defined in [RFC4880] 160 pre-date [RFC8126] which defined the term "IETF Review" instead of 161 the now-outdated term "IETF Consensus" [RFC2434]. 163 This draft updates policies of the OpenPGP IANA registries to align 164 with the terms specified in [RFC8126]. 166 3.2. Registry Naming 168 Registry names of IANA OpenPGP registries *SHOULD* be consistent. 170 The following registries originally have the "PGP" prefix, and the 171 prefix *SHOULD* be changed to "OpenPGP": 173 o PGP String-to-Key (S2K) Registry (Section 5.1) 175 o PGP Packet Types/Tags Registry (Section 5.2) 177 o PGP User Attribute Types Registry (Section 5.3) 179 The prefix "OpenPGP" *SHOULD* be added to the following registries: 181 o Image Format Subpacket Types Registry (Section 5.4) 183 o Signature Subpacket Types Registry (Section 5.5) 185 o Signature Notation Data Subpacket Notation Types Registry 186 (Section 5.5) 188 o Key Server Preference Extensions Registry (Section 5.7) 189 o Reason for Revocation Extensions Registry (Section 5.8) 191 o Implementation Features Registry (Section 5.9) 193 o New Packet Versions Registry (Section 5.10) 195 o Public Key Algorithms Registry (Section 5.12) 197 o Symmetric Key Algorithms Registry (Section 5.13) 199 o Hash Algorithms Registry (Section 5.14) 201 o Compression Algorithms Registry (Section 5.15) 203 This renaming is not necessary for the "OpenPGP Signature Notation 204 Data Subpacket Notation Flags Registry" (Section 5.16) since it is 205 newly created according to this convention. 207 For specific recommendations, please see the corresponding sections 208 in Section 5. 210 4. Providing Recommendations Via The "Recommended" Column 212 The feature set of OpenPGP is an evolving one. In some cases, it has 213 been unclear whether implementation of a certain feature would 214 actually be beneficial for interoperability or create fragmentation 215 of implementations. 217 Moreover, the fast-moving nature of cryptography directly impacts the 218 security of OpenPGP implementations, and an algorithm once considered 219 secure may be subject to cryptanalytic results that advise otherwise. 220 For example, this has been demonstrated by the widespread 221 obsolescence of SHA-1 [SHA1-Coll] [RFC6194]. 223 It is therefore beneficial for all OpenPGP interested parties that 224 implementers can follow a stable reference on what is considered best 225 practice in OpenPGP implementations. 227 There are two types of recommendations considered here: 229 o Recommended for security (abbreviated as "REC-S" in this document) 231 o Recommended for interoperability (abbreviated as "REC-I" in this 232 document) 234 4.1. Security Recommendations 236 Recommendations for security are usually critical and urgent. 238 The following registries shall have the "Security Recommendation" 239 column added: 241 o PGP String-to-Key (S2K) Registry 243 o Public Key Algorithms Registry 245 o Symmetric Key Algorithms Registry 247 o Hash Algorithms Registry 249 The allowed values for this column are: 251 o Yes: Recommended, this algorithm is considered secure; 253 o No: Not recommended, this algorithm is considered insecure; 255 o Empty: No comment, there is no recommendation on this algorithm. 257 A "Security Recommendation" *MUST* only be accepted through an Expert 258 Review described in Section 7.4. 260 4.1.1. Weakening Of Cryptographic Algorithms And Parameters 262 Cryptographic algorithms and parameters will be broken or weakened 263 over time. Blindly implementing cipher suites listed in the 264 registries is not advised. 266 Implementers and users *SHOULD* check that the cryptographic 267 algorithms listed continue to provide the expected level of security. 269 4.2. Interoperability Recommendations 271 Recommendations for interoperability are generally less urgent but 272 greatly beneficial for the OpenPGP user experience. 274 The following registries shall have the "Interoperability 275 Recommendation" column added: 277 o PGP String-to-Key (S2K) Registry 279 o PGP Packet Types/Tags Registry 281 o PGP User Attribute Types Registry 282 o Image Format Subpacket Types Registry 284 o Signature Subpacket Types Registry 286 o Key Server Preference Extensions Registry 288 o Reason for Revocation Extensions Registry 290 o Implementation Features Registry 292 o New Packet Versions Registry 294 o Key Flags Extensions Registry 296 o Public Key Algorithms Registry 298 o Symmetric Key Algorithms Registry 300 o Hash Algorithms Registry 302 o Compression Algorithms Registry 304 The allowed values for this column are: 306 o Yes: Recommended, implementation of this feature enhances 307 interoperability for OpenPGP; 309 o No: Not recommended, implementation of this feature reduces 310 interoperability for OpenPGP; 312 o Empty: No comment, there is no recommendation on this feature on 313 interoperability. 315 An "Interoperability Recommendation" *MUST* only be accepted through 316 an Expert Review described in Section 7.4. 318 4.3. No Recommendation 320 An item not marked as "Recommended" does not mean it is "Not 321 Recommended". This could simply be a reflection that this item has 322 not been through Expert Review, has limited applicability, is 323 intended only for specific use cases, or for other reasons. 325 Not all newly defined parameters in a Standards Track document need 326 to be marked as "Recommended". 328 5. IANA OpenPGP Registries 330 5.1. PGP String-to-Key (S2K) Registry 332 Proposed changes to the registry: 334 o Rename the registry to "OpenPGP String-to-Key (S2K) Algorithms" 336 o Change registry policy to *Specification Required*. 338 o Update its "Reference" to also refer to this document. 340 o A Standards Track document is required to register an S2K 341 algorithm with the value "Yes" in any recommendation. 343 Add the following note: 345 Note: Experts are to verify that the proposed registration 346 provides a publicly-available standard that can be implemented 347 in an interoperable way, with notable benefits for the wider 348 OpenPGP community. 350 Update the following registrations: 352 +---------+--------------------+-------+-------+--------------------+ 353 | ID | S2K Type | REC-S | REC-I | Reference | 354 +---------+--------------------+-------+-------+--------------------+ 355 | 0 | Simple S2K | No | Yes | Section 3.7.1.1 of | 356 | | | | | [RFC4880] | 357 | 1 | Salted S2K | No | Yes | Section 3.7.1.2 of | 358 | | | | | [RFC4880] | 359 | 2 | Reserved | | | Section 3.7.1 of | 360 | | | | | [RFC4880] | 361 | 3 | Iterated and | Yes | Yes | Section 3.7.1.3 of | 362 | | Salted S2K | | | [RFC4880] | 363 | 4-99 | Unassigned | | | | 364 | 100-110 | Private or | | | Section 3.7.1 of | 365 | | Experimental Use | | | [RFC4880] | 366 | 111-255 | Unassigned | | | | 367 +---------+--------------------+-------+-------+--------------------+ 369 5.2. PGP Packet Types/Tags Registry 371 Proposed changes to the registry: 373 o Rename the registry to "OpenPGP Packet Types" 375 o Rename the column "Attribute" to "Packet Type" 376 o Change registry policy to *RFC Required*. 378 o Update its "Reference" to also refer to this document. 380 o A Standards Track document is required to register a Packet Type 381 with the value "Yes" in any recommendation. 383 Add the following note: 385 Note: Due to the scarcity of codepoints in this registry, 386 experts are to verify that the proposed registration 387 *MUST* provide notable benefits for the wider OpenPGP community, 388 and provides a publicly-available standard that can be implemented in 389 an interoperable way. 391 Update the following registrations: 393 +-------+-------------------------------+-------+-------+-----------+ 394 | Value | Packet Type | REC-S | REC-I | Reference | 395 +-------+-------------------------------+-------+-------+-----------+ 396 | 0 | Reserved - a packet tag *MUST | No | Yes | [RFC4880] | 397 | | NOT* have this value | | | | 398 | 1 | Public-Key Encrypted Session | Yes | Yes | [RFC4880] | 399 | | Key Packet | | | | 400 | 2 | Signature Packet | Yes | Yes | [RFC4880] | 401 | 3 | Symmetric-Key Encrypted | Yes | Yes | [RFC4880] | 402 | | Session Key Packet | | | | 403 | 4 | One-Pass Signature Packet | Yes | Yes | [RFC4880] | 404 | 5 | Secret Key Packet | Yes | Yes | [RFC4880] | 405 | 6 | Public Key Packet | Yes | Yes | [RFC4880] | 406 | 7 | Secret Subkey Packet | Yes | Yes | [RFC4880] | 407 | 8 | Compressed Data Packet | Yes | Yes | [RFC4880] | 408 | 9 | Symmetrically Encrypted Data | No | Yes | [RFC4880] | 409 | | Packet | | | | 410 | 10 | Marker Packet | No | No | [RFC4880] | 411 | 11 | Literal Data Packet | No | Yes | [RFC4880] | 412 | 12 | Trust Packet | | No | [RFC4880] | 413 | 13 | User ID Packet | | Yes | [RFC4880] | 414 | 14 | Public Subkey Packet | Yes | Yes | [RFC4880] | 415 | 15-16 | Unknown | | | [RFC4880] | 416 | 17 | User Attribute Packet | | Yes | [RFC4880] | 417 | 18 | Sym. Encrypted and Integrity | Yes | Yes | [RFC4880] | 418 | | Protected Data Packet | | | | 419 | 19 | Modification Detection Code | Yes | Yes | [RFC4880] | 420 | | Packet | | | | 421 | 20-59 | Unassigned | | | | 422 | 60-63 | Private or Experimental Use | | | [RFC4880] | 423 +-------+-------------------------------+-------+-------+-----------+ 425 5.3. PGP User Attribute Types Registry 427 Proposed changes to the registry: 429 o Rename the registry to "OpenPGP User Attribute Subpacket Types" 431 o Rename the column "Attribute" to "User Attribute Type" 433 o Change registry policy to *Specification Required*. 435 o Update its "Reference" to also refer to this document. 437 o A Standards Track document is required to register an Attribute 438 Type algorithm with the value "Yes" in any recommendation. 440 Add the following note: 442 Note: Experts are to verify that the proposed registration 443 *SHOULD* provide notable benefits for the wider OpenPGP community, 444 and provides a publicly-available standard that can be implemented in 445 an interoperable way. 447 Update the following registrations: 449 +---------+-----------------------------+-------+------------+ 450 | Value | Attribute Type | REC-I | Reference | 451 +---------+-----------------------------+-------+------------+ 452 | 0 | Reserved | | [RFC4880] | 453 | 1 | image | Yes | [RFC4880] | 454 | 2-99 | Unassigned | | | 455 | 100-110 | Private or Experimental Use | | [RFC4880] | 456 | 111-255 | Unassigned | | | 457 +---------+-----------------------------+-------+------------+ 459 5.4. Image Format Subpacket Types Registry 461 Proposed changes to the registry: 463 o Rename the registry to "OpenPGP Image Format Subpacket Types" 465 o Rename the column "Attribute" to "Image Format Type" 467 o Change registry policy to *Specification Required*. 469 o Update its "Reference" to also refer to this document. 471 o A Standards Track document is required to register a Packet Type/ 472 Tag with the value "Yes" in any recommendation. 474 Add the following note: 476 Note: Experts are to verify that the proposed registration 477 *SHOULD* provide notable benefits for the wider OpenPGP community, 478 and provides a publicly-available standard that can be implemented in 479 an interoperable way. 481 Update the following registrations: 483 +---------+-----------------------------+-------+------------+ 484 | Value | Image Format Type | REC-I | Reference | 485 +---------+-----------------------------+-------+------------+ 486 | 0 | Reserved | | [RFC4880] | 487 | 1 | JPEG | Yes | [RFC4880] | 488 | 2-99 | Unassigned | | | 489 | 100-110 | Private or Experimental Use | | [RFC4880] | 490 | 111-255 | Unassigned | | | 491 +---------+-----------------------------+-------+------------+ 493 5.5. Signature Subpacket Types Registry 495 Proposed changes to the registry: 497 o Rename the registry to "OpenPGP Signature Subpacket Types". 499 o Rename the column "Attribute" to "Signature Subpacket Type" 501 o Change registry policy to *Specification Required*. 503 o Update its "Reference" to also refer to this document. 505 o A Standards Track document is required to register a Signature 506 Subpacket Type with the value "Yes" in any recommendation. 508 Add the following note: 510 Note: Experts are to verify that the proposed registration 511 *SHOULD* provide notable benefits for the wider OpenPGP community, 512 and provides a publicly-available standard that can be implemented in 513 an interoperable way. 515 Update the following registrations: 517 +---------+----------------------------------+-------+------------+ 518 | Value | Image Format Type | REC-I | Reference | 519 +---------+----------------------------------+-------+------------+ 520 | 0-1 | Reserved | | [RFC4880] | 521 | 2 | Signature Creation Time | Yes | [RFC4880] | 522 | 3 | Signature Expiration Time | Yes | [RFC4880] | 523 | 4 | Exportable Certification | Yes | [RFC4880] | 524 | 5 | Trust Signature | Yes | [RFC4880] | 525 | 6 | Regular Expression | | [RFC4880] | 526 | 7 | Revocable | Yes | [RFC4880] | 527 | 8 | Reserved | | [RFC4880] | 528 | 9 | Key Expiration Time | Yes | [RFC4880] | 529 | 11 | Preferred Symmetric Algorithms | Yes | [RFC4880] | 530 | 12 | Revocation Key | Yes | [RFC4880] | 531 | 13-15 | Reserved | | [RFC4880] | 532 | 16 | Issuer Key ID | Yes | [RFC4880] | 533 | 17-19 | Reserved | | [RFC4880] | 534 | 20 | Notation Data | Yes | [RFC4880] | 535 | 21 | Preferred Hash Algorithms | Yes | [RFC4880] | 536 | 22 | Preferred Compression Algorithms | Yes | [RFC4880] | 537 | 23 | Key Server Preferences | | [RFC4880] | 538 | 24 | Preferred Key Server | | [RFC4880] | 539 | 25 | Primary User ID | Yes | [RFC4880] | 540 | 26 | Policy Uri | | [RFC4880] | 541 | 27 | Key Flags | Yes | [RFC4880] | 542 | 28 | Signer's User ID | Yes | [RFC4880] | 543 | 29 | Reason For Revocation | Yes | [RFC4880] | 544 | 30 | Features | Yes | [RFC4880] | 545 | 31 | Signature Target | Yes | [RFC4880] | 546 | 32 | Embedded Signature | Yes | [RFC4880] | 547 | 33-99 | Unassigned | | [RFC4880] | 548 | 100-110 | Private or Experimental Use | | [RFC4880] | 549 | 111-127 | Unassigned | | | 550 +---------+----------------------------------+-------+------------+ 552 5.6. Signature Notation Data Subpacket Notation Types Registry 554 This registry is currently empty. 556 However, the existing IANA registry contains an erroneous note that 557 the registry is about "User Notations". According to [RFC4880] which 558 defined this registry, "[n]otations contain a user space that is 559 completely unmanaged". This registry should be for the [RFC4880] 560 "IETF (name)space". 562 Proposed changes to the registry: 564 o Rename the registry to "OpenPGP Notation Data Subpacket Notation 565 Types". 567 o Change registry policy to *Specification Required*. 569 o Update its "Reference" to also refer to this document. 571 Update its erroneous "Note" that says: 573 Notation names are arbitrary strings encoded in UTF-8. They reside two 574 name spaces: The IETF name space and the user name space. 576 The IETF name space is registered with IANA. These names MUST NOT 577 contain the "@" character (0x40). This is a tag for the user name 578 space. 580 To: 582 Notation names are arbitrary strings encoded in UTF-8, and there are 583 two namespaces: 585 * IETF namespace: keys are of any string but *MUST NOT* contain the 586 "@" character (0x40). Allowed keys *MUST* by registered in this 587 registry. 589 * User namespace: keys are of form "[name]@[domain]", these are 590 unmanaged keys and NOT maintained by this registry. 592 Note: Experts are to verify that the proposed registration 593 is necessary and *SHOULD* provide general benefits for the wider 594 OpenPGP community. 596 5.7. Key Server Preference Extensions Registry 598 Proposed changes to the registry: 600 o Rename the registry to "OpenPGP Key Server Preferences" 602 o Rename the column "First octet" to "Flag" 604 o Add a column "Octet Ordinal" to indicate the ordinal of the octet 605 of which the "Flag" field is read from. 607 o Rename the column "Extension" to "Description" 609 o Change registry policy to *Specification Required*. 611 o Update its "Reference" to also refer to this document. 613 o A Standards Track document is required to register an item with 614 the value "Yes" in any recommendation. 616 Add the following note: 618 This is a variable-length bit field. 620 Note: Experts are to verify that the proposed registration 621 *SHOULD* provide notable benefits for the wider OpenPGP community, 622 and provides a publicly-available standard that can be implemented in 623 an interoperable way. 625 Update existing registrations: 627 +-------------+------+-------------+-------+------------------------+ 628 | Octet | Flag | Description | REC-I | Reference | 629 | Ordinal | | | | | 630 +-------------+------+-------------+-------+------------------------+ 631 | 1 | 0x01 | Unassigned | | | 632 | 1 | 0x02 | Unassigned | | | 633 | 1 | 0x04 | Unassigned | | | 634 | 1 | 0x08 | Unassigned | | | 635 | 1 | 0x10 | Unassigned | | | 636 | 1 | 0x20 | Unassigned | | | 637 | 1 | 0x40 | Unassigned | | | 638 | 1 | 0x80 | No-Modify | Yes | Section 5.3.2.17 of | 639 | | | | | [RFC4880] | 640 | 2- | | Unassigned | | | 641 +-------------+------+-------------+-------+------------------------+ 643 5.8. Reason for Revocation Extensions Registry 645 Proposed changes to the registry: 647 o Rename the registry to "OpenPGP Reasons for Revocation" 649 o Rename the column "Flag" to "Reason" 651 o Change registry policy to *Specification Required*. 653 o Update its "Reference" to also refer to this document. 655 o A Standards Track document is required to register an item with 656 the value "Yes" in any recommendation. 658 o Add the following note: 660 Note: Experts are to verify that the proposed registration 661 *SHOULD* provide notable benefits for the wider OpenPGP community, 662 and provides a publicly-available standard that can be implemented in 663 an interoperable way. 665 Update the following registrations: 667 +---------+-------------------------------+-------+-----------------+ 668 | Value | Reason | REC-I | Reference | 669 +---------+-------------------------------+-------+-----------------+ 670 | 0 | No reason specified (key | Yes | Section | 671 | | revocations or cert | | 5.2.3.23 of | 672 | | revocations) | | [RFC4880] | 673 | 1 | Key is superseded (key | Yes | Section | 674 | | revocations) | | 5.2.3.23 of | 675 | | | | [RFC4880] | 676 | 2 | Key material has been | Yes | Section | 677 | | compromised (key revocations) | | 5.2.3.23 of | 678 | | | | [RFC4880] | 679 | 3 | Key is retired and no longer | Yes | Section | 680 | | used (key revocations) | | 5.2.3.23 of | 681 | | | | [RFC4880] | 682 | 4-31 | Unassigned | | Section | 683 | | | | 5.2.3.23 of | 684 | | | | [RFC4880] | 685 | 32 | User ID information is no | Yes | Section | 686 | | longer valid (cert | | 5.2.3.23 of | 687 | | revocations) | | [RFC4880] | 688 | 33-99 | Unassigned | | | 689 | 100-110 | Private Use | | Section | 690 | | | | 5.2.3.23 of | 691 | | | | [RFC4880] | 692 | 111-255 | Unassigned | | | 693 +---------+-------------------------------+-------+-----------------+ 695 5.9. Implementation Features Registry 697 Proposed changes to the registry: 699 o Rename the registry to "OpenPGP Features" 701 o Mark value "First Octet, 0x80" as "Private Use" in the registry. 703 o Rename the column "Value" to "Flag" 705 o Add a column "Octet Ordinal" to indicate the ordinal of the octet 706 of which the "Flag" field is read from. 708 o Change registry policy to *Specification Required*. 710 o Update its "Reference" to also refer to this document. 712 o A Standards Track document is required to register an item with 713 the value "Yes" in any recommendation. 715 Add the following note: 717 This is a variable-length bit field. 719 Note: Experts are to verify that the proposed registration 720 *SHOULD* provide notable benefits for the wider OpenPGP community, 721 and provides a publicly-available standard that can be implemented in 722 an interoperable way. 724 Update the following registrations: 726 +---------+------+------------------+-------+-------+---------------+ 727 | Octet | Flag | Feature | REC-S | REC-I | Reference | 728 | Ordinal | | | | | | 729 +---------+------+------------------+-------+-------+---------------+ 730 | 1 | 0x01 | Modification | Yes | Yes | Section | 731 | | | Detection | | | 5.2.3.24 of | 732 | | | (packets 18 and | | | [RFC4880] | 733 | | | 19) | | | | 734 | 1 | 0x02 | Unassigned | | | | 735 | 1 | 0x04 | Unassigned | | | | 736 | 1 | 0x08 | Unassigned | | | | 737 | 1 | 0x10 | Unassigned | | | | 738 | 1 | 0x20 | Unassigned | | | | 739 | 1 | 0x40 | Unassigned | | | | 740 | 1 | 0x80 | Unassigned | | | | 741 | 2- | | Unassigned | | | | 742 +---------+------+------------------+-------+-------+---------------+ 744 5.10. New Packet Versions Registry 746 This registry is currently empty. 748 Proposed changes to the registry: 750 o Rename the registry to "OpenPGP Packet Type Versions" 752 o It should have the following columns: "Packet Type", "Version", 753 "Security Recommended", "Interoperability Recommended", 754 "Reference" 756 o Change registry policy to *RFC Required*. 758 o Update its "Reference" to also refer to this document. 760 o Add the following note: 762 Note: Experts are to verify that the proposed registration 763 *SHOULD* provide notable benefits for the wider OpenPGP community, 764 and provides a publicly-available standard that can be implemented in 765 an interoperable way. 767 o A Standards Track document is required to register a Packet Type 768 with the value "Yes" in any recommendation. 770 Add in the existing (but missing) registrations: 772 +-------------+---------+-------+-------+---------------------------+ 773 | Packet Type | Version | REC-S | REC-I | Reference | 774 +-------------+---------+-------+-------+---------------------------+ 775 | 1 | 3 | Yes | Yes | Section 5.1 of [RFC4880] | 776 | 2 | 3 | No | Yes | Section 5.2.2 of | 777 | | | | | [RFC4880] | 778 | 2 | 4 | Yes | Yes | Section 5.2.3 of | 779 | | | | | [RFC4880] | 780 | 3 | 4 | Yes | Yes | Section 5.3 of [RFC4880] | 781 | 4 | 3 | Yes | Yes | Section 5.4 of [RFC4880] | 782 | 5 | 3 | Yes | Yes | Section 5.5.1.3 of | 783 | | | | | [RFC4880] | 784 | 5 | 4 | Yes | Yes | Section 5.5.1.3 of | 785 | | | | | [RFC4880] | 786 | 6 | 3 | Yes | Yes | Section 5.5.1.1 of | 787 | | | | | [RFC4880] | 788 | 6 | 4 | Yes | Yes | Section 5.5.1.1 of | 789 | | | | | [RFC4880] | 790 | 7 | 3 | Yes | Yes | Section 5.5.1.4 of | 791 | | | | | [RFC4880] | 792 | 7 | 4 | Yes | Yes | Section 5.5.1.4 of | 793 | | | | | [RFC4880] | 794 | 14 | 3 | Yes | Yes | Section 5.5.1.2 of | 795 | | | | | [RFC4880] | 796 | 14 | 4 | Yes | Yes | Section 5.5.1.2 of | 797 | | | | | [RFC4880] | 798 | 18 | 1 | Yes | Yes | Section 5.13 of [RFC4880] | 799 +-------------+---------+-------+-------+---------------------------+ 801 5.11. Key Flags Extensions Registry 803 Proposed changes to the registry: 805 o Rename the registry to "OpenPGP Key Flags" 807 o Rename the column "Value" to "Flag" 809 o Add a column "Octet Ordinal" to indicate the ordinal of the octet 810 of which the "Flag" field is read from. 812 o Rename the column "Extension" to "Description" 814 o Mark value "First Octet, 0x40" as "Unassigned" in the registry. 816 o Remove ending periods for all values in "Description" for 817 consistency with other registries. 819 o Change registry policy to *Specification Required*. 821 o Update its "Reference" to also refer to this document. 823 o A Standards Track document is required to register an item with 824 the value "Yes" in any recommendation. 826 Add the following note: 828 This is a variable-length bit field. 830 Note: Experts are to verify that the proposed registration 831 *SHOULD* provide notable benefits for the wider OpenPGP community, 832 and provides a publicly-available standard that can be implemented in 833 an interoperable way. 835 Update existing registrations: 837 +---------+------+----------------------------+-------+-------------+ 838 | Octet | Flag | Description | REC-I | Reference | 839 | Ordinal | | | | | 840 +---------+------+----------------------------+-------+-------------+ 841 | 1 | 0x01 | This key may be used to | Yes | Section | 842 | | | certify other keys | | 5.2.3.21 of | 843 | | | | | [RFC4880] | 844 | 1 | 0x02 | This key may be used to | Yes | Section | 845 | | | sign data | | 5.2.3.21 of | 846 | | | | | [RFC4880] | 847 | 1 | 0x04 | This key may be used to | Yes | Section | 848 | | | encrypt communications | | 5.2.3.21 of | 849 | | | | | [RFC4880] | 850 | 1 | 0x08 | This key may be used to | Yes | Section | 851 | | | encrypt storage | | 5.2.3.21 of | 852 | | | | | [RFC4880] | 853 | 1 | 0x10 | The private component of | Yes | Section | 854 | | | this key may have been | | 5.2.3.21 of | 855 | | | split by a secret-sharing | | [RFC4880] | 856 | | | mechanism | | | 857 | 1 | 0x20 | This key may be used for | Yes | Section | 858 | | | authentication | | 5.2.3.21 of | 859 | | | | | [RFC4880] | 860 | 1 | 0x40 | Unassigned | | | 861 | 1 | 0x80 | The private component of | Yes | Section | 862 | | | this key may be in the | | 5.2.3.21 of | 863 | | | possession of more than | | [RFC4880] | 864 | | | one person | | | 865 +---------+------+----------------------------+-------+-------------+ 867 5.12. Public Key Algorithms Registry 869 Proposed changes to the registry: 871 o Rename registry to "OpenPGP Public Key Algorithms". 873 o Change registry policy to *Specification Required*. 875 o Update its "Reference" to also refer to this document. 877 o A Standards Track document is required to register an item with 878 the value "Yes" in any recommendation. 880 o Existing registrations with a "Reference" value pointing to a non- 881 IETF published document should be checked to see if an IETF- 882 published document is available, and if so, update the reference 883 to point to the IETF-published document instead for consistency. 885 Add the following note: 887 Note: Experts are to verify that the proposed registration 888 *SHOULD* provide notable benefits for the wider OpenPGP community, 889 and provides a publicly-available standard that can be implemented in 890 an interoperable way. References to IETF-published documents are 891 preferred. The "Reference" value should point to a document that 892 details the implementation of this algorithm in OpenPGP, not of 893 the algorithm itself. 895 Update the following registrations: 897 +---------+---------------------------+-------+-------+-------------+ 898 | ID | Algorithm | REC-S | REC-I | Reference | 899 +---------+---------------------------+-------+-------+-------------+ 900 | 1 | RSA (Encrypt or Sign) | Yes | Yes | Section | 901 | | | | | 13.5 of | 902 | | | | | [RFC4880] | 903 | 2 | RSA Encrypt-Only | | No | Section | 904 | | | | | 13.5 of | 905 | | | | | [RFC4880] | 906 | 3 | RSA Sign-Only | | No | Section | 907 | | | | | 13.5 of | 908 | | | | | [RFC4880] | 909 | 4-15 | Unassigned | | | Section | 910 | | | | | 13.5 of | 911 | | | | | [RFC4880] | 912 | 16 | Elgamal (Encrypt-Only) | Yes | Yes | [RFC4880] | 913 | 17 | DSA (Digital Signature | Yes | Yes | Section | 914 | | Algorithm) | | | 13.6 of | 915 | | | | | [RFC4880] | 916 | 18 | ECDH public key algorithm | Yes | Yes | [RFC6637] | 917 | 19 | ECDSA public key | Yes | Yes | [RFC6637] | 918 | | algorithm | | | | 919 | 20 | Reserved (formerly | | | Section 9.1 | 920 | | Elgamal Encrypt or Sign) | | | of | 921 | | | | | [RFC4880] | 922 | 21 | Reserved for Diffie- | | | Section 9.1 | 923 | | Hellman (X9.42, as | | | of | 924 | | defined for IETF-S/MIME) | | | [RFC4880] | 925 | 22-99 | Unassigned | | | | 926 | 100-110 | Private or Experimental | | | Section | 927 | | Use | | | 13.5 of | 928 | | | | | [RFC4880] | 929 | 111-255 | Unassigned | | | | 930 +---------+---------------------------+-------+-------+-------------+ 932 5.13. Symmetric Key Algorithms Registry 934 Proposed changes to the registry: 936 o Rename registry to "OpenPGP Symmetric Key Algorithms". 938 o Algorithm descriptions have been simplified and applicable 939 references moved to the "Reference" column. 941 o All algorithm descriptions with "[n+] bit" is updated to 942 "[n+]-bit" for consistency, for example, the phrase "128 bit key" 943 becomes "128-bit key". 945 o Change registry policy to *Specification Required*. 947 o Update its "Reference" to also refer to this document. 949 o A Standards Track document is required to register an item with 950 the value "Yes" in any recommendation. 952 o Existing registrations with a "Reference" value pointing to a non- 953 IETF published document should be checked to see if an IETF- 954 published document is available, and if so, update the reference 955 to point to the IETF-published document instead for consistency. 957 Add the following note: 959 Note: Experts are to verify that the proposed registration 960 *SHOULD* provide notable benefits for the wider OpenPGP community, 961 and provides a publicly-available standard that can be implemented in 962 an interoperable way. References to IETF-published documents are 963 preferred. The "Reference" value should point to a document that 964 details the implementation of this algorithm in OpenPGP, not of 965 the algorithm itself. 967 Update the following registrations: 969 +---------+------------------------+-------+-------+----------------+ 970 | ID | Algorithm | REC-S | REC-I | Reference | 971 +---------+------------------------+-------+-------+----------------+ 972 | 0 | Plaintext | | Yes | Section 13.4 | 973 | | | | | of [RFC4880] | 974 | 1 | IDEA | No | No | Section 6.4.1 | 975 | | | | | of [RFC1991] | 976 | 2 | TripleDES (DES-EDE, | No | Yes | Section 13.2 | 977 | | 168-bit key derived | | | of [RFC4880] | 978 | | from 192-bit key) | | | | 979 | 3 | CAST5 (128-bit key) | No | Yes | Section 9.2 of | 980 | | | | | [RFC4880] | 981 | | | | | [RFC2144] | 982 | 4 | Blowfish (128-bit key, | | | Section 9.2 of | 983 | | 16 rounds) | | | [RFC4880] | 984 | 5-6 | Reserved | | | Section 9.1 of | 985 | | | | | [RFC4880] | 986 | 7 | AES with 128-bit key | Yes | Yes | Section 9.2 of | 987 | | | | | [RFC4880] | 988 | 8 | AES with 192-bit key | Yes | | Section 9.2 of | 989 | | | | | [RFC4880] | 990 | 9 | AES with 256-bit key | Yes | Yes | Section 9.2 of | 991 | | | | | [RFC4880] | 992 | 10 | Twofish with 256-bit | | | Section 9.2 of | 993 | | key | | | [RFC4880] | 994 | 11 | Camellia with 128-bit | | | [RFC5581] | 995 | | key | | | | 996 | 12 | Camellia with 192-bit | | | [RFC5581] | 997 | | key | | | | 998 | 13 | Camellia with 256-bit | | | [RFC5581] | 999 | | key | | | | 1000 | 14-99 | Unassigned | | | | 1001 | 100-110 | Private or | | | Section 9.2 of | 1002 | | Experimental Use | | | [RFC4880] | 1003 | 111-255 | Unassigned | | | | 1004 +---------+------------------------+-------+-------+----------------+ 1006 5.14. Hash Algorithms Registry 1008 Proposed changes to the registry: 1010 o Rename registry to "OpenPGP Hash Key Algorithms". 1012 o Change registry policy to *Specification Required*. 1014 o Update its "Reference" to also refer to this document. 1016 o A Standards Track document is required to register an item with 1017 the value "Yes" in any recommendation. 1019 o Existing registrations with a "Reference" value pointing to a non- 1020 IETF published document should be checked to see if an IETF- 1021 published document is available, and if so, update the reference 1022 to point to the IETF-published document instead for consistency. 1024 Add the following note: 1026 Note: Experts are to verify that the proposed registration 1027 *SHOULD* provide notable benefits for the wider OpenPGP community, 1028 and provides a publicly-available standard that can be implemented in 1029 an interoperable way. References to IETF-published documents are 1030 preferred. The "Reference" value should point to a document that 1031 details the implementation of this algorithm in OpenPGP, not of 1032 the algorithm itself. 1034 Update the following registrations: 1036 +----------+-------------+--------------+-------+-------+-----------+ 1037 | ID | Algorithm | Text Name | REC-S | REC-I | Reference | 1038 +----------+-------------+--------------+-------+-------+-----------+ 1039 | 1 | MD5 | "MD5" | No | No | Section | 1040 | | | | | | 9.4 of | 1041 | | | | | | [RFC4880] | 1042 | 2 | SHA-1 | "SHA1" | No | Yes | Section | 1043 | | | | | | 9.4 of | 1044 | | | | | | [RFC4880] | 1045 | 3 | RIPE-MD/160 | "RIPEMD160" | Yes | | Section | 1046 | | | | | | 9.4 of | 1047 | | | | | | [RFC4880] | 1048 | 4-7 | Reserved | | | | Section | 1049 | | | | | | 9.4 of | 1050 | | | | | | [RFC4880] | 1051 | 8 | SHA256 | "SHA256" | Yes | Yes | Section | 1052 | | | | | | 9.4 of | 1053 | | | | | | [RFC4880] | 1054 | 9 | SHA384 | "SHA384" | Yes | | Section | 1055 | | | | | | 9.4 of | 1056 | | | | | | [RFC4880] | 1057 | 10 | SHA512 | "SHA512" | Yes | Yes | Section | 1058 | | | | | | 9.4 of | 1059 | | | | | | [RFC4880] | 1060 | 11 | SHA224 | "SHA224" | Yes | | Section | 1061 | | | | | | 9.4 of | 1062 | | | | | | [RFC4880] | 1063 | 12-99 | Unassigned | | | | | 1064 | | 100-110 | Private or | | | | 1065 | | | Experimental | | | | 1066 | | | Use | | | | 1067 | Section | 111-255 | Unassigned | | | | 1068 | 9.4 of [ | | | | | | 1069 | RFC4880] | | | | | | 1070 +----------+-------------+--------------+-------+-------+-----------+ 1072 5.15. Compression Algorithms Registry 1074 Proposed changes to the registry: 1076 o Rename registry to "OpenPGP Compression Key Algorithms". 1078 o Change registry policy to *Specification Required*. 1080 o Update its "Reference" to also refer to this document. 1082 o A Standards Track document is required to register an item with 1083 the value "Yes" in any recommendation. 1085 o Existing registrations with a "Reference" value pointing to a non- 1086 IETF published document should be checked to see if an IETF- 1087 published document is available, and if so, update the reference 1088 to point to the IETF-published document instead for consistency. 1090 Add the following note: 1092 Note: Experts are to verify that the proposed registration 1093 *SHOULD* provide notable benefits for the wider OpenPGP community, 1094 and provides a publicly-available standard that can be implemented in 1095 an interoperable way. References to IETF-published documents are 1096 preferred. 1098 Update the following registrations: 1100 +---------+-------------------------+-------+-----------------------+ 1101 | ID | Algorithm | REC-I | Reference | 1102 +---------+-------------------------+-------+-----------------------+ 1103 | 0 | Uncompressed | Yes | Section 9.3 of | 1104 | | | | [RFC4880] | 1105 | 1 | ZIP | Yes | Section 9.3 of | 1106 | | | | [RFC4880] | 1107 | 2 | ZLIB | Yes | Section 9.3 of | 1108 | | | | [RFC4880] | 1109 | 3 | BZip2 | | Section 9.3 of | 1110 | | | | [RFC4880] | 1111 | 4-99 | Unassigned | | | 1112 | 100-110 | Private or Experimental | | Section 9.3 of | 1113 | | Use | | [RFC4880] | 1114 | 111-255 | Unassigned | | | 1115 +---------+-------------------------+-------+-----------------------+ 1117 5.16. New Registry: OpenPGP Signature Notation Data Subpacket Notation 1118 Flags Registry 1120 This registry is created in accordance with Section 5.2.3.16 of 1121 [RFC4880]. 1123 The registry: 1125 o Contain the columns "Flag", "Description", "Security Recommended", 1126 "Interoperability Recommended", Reference" 1128 o Registry policy is *Specification Required*. 1130 o Its "Reference" should refer to [RFC4880] and this document. 1132 Add the following note: 1134 This is a variable-length bit field. 1136 Note: Experts are to verify that the proposed registration 1137 *SHOULD* provide notable benefits for the wider OpenPGP community, 1138 and provides a publicly-available standard that can be implemented in 1139 an interoperable way. 1141 The registry *SHOULD* be initialized to the following values: 1143 +---------+------+-------------------+-------+-------+--------------+ 1144 | Octet | Flag | Description | REC-S | REC-I | Reference | 1145 | Ordinal | | | | | | 1146 +---------+------+-------------------+-------+-------+--------------+ 1147 | 1 | 0x01 | Unassigned. | | | Section | 1148 | | | | | | 5.2.3.16 of | 1149 | | | | | | [RFC4880] | 1150 | 1 | 0x02 | Unassigned. | | | Section | 1151 | | | | | | 5.2.3.16 of | 1152 | | | | | | [RFC4880] | 1153 | 1 | 0x04 | Unassigned. | | | Section | 1154 | | | | | | 5.2.3.16 of | 1155 | | | | | | [RFC4880] | 1156 | 1 | 0x08 | Unassigned. | | | Section | 1157 | | | | | | 5.2.3.16 of | 1158 | | | | | | [RFC4880] | 1159 | 1 | 0x10 | Unassigned. | | | Section | 1160 | | | | | | 5.2.3.16 of | 1161 | | | | | | [RFC4880] | 1162 | 1 | 0x20 | Unassigned. | | | Section | 1163 | | | | | | 5.2.3.16 of | 1164 | | | | | | [RFC4880] | 1165 | 1 | 0x40 | Unassigned. | | | Section | 1166 | | | | | | 5.2.3.16 of | 1167 | | | | | | [RFC4880] | 1168 | 1 | 0x80 | This note value | | Yes | Section | 1169 | | | is human-readable | | | 5.2.3.16 of | 1170 | | | text. | | | [RFC4880] | 1171 +---------+------+-------------------+-------+-------+--------------+ 1173 6. Registries With The "Specification Required" Policy 1175 Registration requests for a *Specification Required* and *Expert 1176 Review* registry must be submitted to the Expert Pool (Section 7) 1177 through the openpgp-reg-review@ietf.org mailing list. 1179 The registration request will be deemed successful after three 1180 approved Expert Reviews (Section 7.4), and the Designated Experts 1181 will request IANA to register the proposed registration. 1183 6.1. Registration Request Procedure 1185 Registration requests sent to the mailing list for review *SHOULD* 1186 use an appropriate subject (e.g., "Registration request: new 1187 algorithm in Symmetric Encryption registry"). 1189 Within the review period, the Designated Experts will either approve 1190 or deny the registration request, communicating this decision to the 1191 review list and IANA. 1193 6.2. Registration Request Outcome 1195 An outcome of a registration request is determined by results of 1196 Expert Reviews (Section 7.4). 1198 A registration request is approved once it receives a minimum of 1199 three Expert Reviews that result in approval. 1201 The outcomes of a request review are: 1203 o Approval: once there are three approved Designated Expert reviews 1204 within the review period; 1206 o Denial: there have been more than three Designated Expert reviews 1207 within the review period but have not met the approval threshold 1208 of three approvals. 1210 6.3. Temporary Registrations 1212 To allow for the allocation of values prior to publication, 1213 Designated Experts *MAY* approve a temporary registration once they 1214 are satisfied that such a specification will be published. 1216 This temporary registration has a 1 year validity, of which when 1217 expired will be automatically revoked. 1219 Once the specification that the proposal relies is published within 1220 this period, the Designated Experts *SHOULD* request IANA to convert 1221 this registration to an official one. 1223 7. Designated Experts 1225 Designated Experts are responsible for performing registration 1226 request reviews for *Expert Review* and *Specification Required* IANA 1227 OpenPGP registries. 1229 7.1. IANA Registration 1231 IANA *MUST* only accept registry updates from the Designated Experts 1232 and *SHOULD* direct all requests for registration to the review 1233 mailing list. 1235 7.2. Eligibility Criteria 1237 A Designated Expert *SHOULD* have a thorough understanding, 1238 demonstrated knowledge and experience of OpenPGP [RFC4880] and its 1239 Standards Track extensions. 1241 7.3. Selection Criteria And Pool 1243 Designated Experts are judged and selected by the IETF Area Director 1244 of which the "openpgp" workgroup belongs. 1246 The selected pool of Designated Experts *SHOULD* be able to represent 1247 the perspectives of different applications using this specification, 1248 in order to enable broadly informed review of registration decisions. 1250 7.4. Designated Expert Review 1252 7.4.1. Review Procedure 1254 On submission of a review request, five Designated Experts are sought 1255 out for the review of the request. These Designated Experts must 1256 provide a review decision response within 21 days of submission. 1258 If less than three Designated Experts have performed a review by the 1259 end of that period, an extension of 21 days will be granted and extra 1260 Designated Experts selected to complete the review. 1262 In cases where a review assignment could be perceived as creating a 1263 conflict of interest for a particular Designated Expert, that 1264 Designated Expert *SHOULD* defer review responsibility to another 1265 Designated Expert, as described in Section 5.2 of [RFC8126]. 1267 7.4.2. Review Criteria 1269 A Designated Expert *MUST* take the following criteria into account 1270 when reviewing registration requests. 1272 For *Specification Required* registries: 1274 o whether the proposed registration duplicates existing 1275 functionality; 1277 o the clarity of the proposed registration description; 1279 o whether the specification of the proposed registration item is 1280 publicly available; 1282 o whether the proposed registration would affect the security of 1283 users of OpenPGP; and 1285 o whether the proposed registration is likely to be of general 1286 applicability. 1288 7.5. Review Outcomes 1290 Approvals *MUST* include an explanation. 1292 Denials *MUST* include an explanation and, if applicable, 1293 constructive suggestions as to how to make the request successful. 1295 A Designated Expert *MAY* elect to provide more in depth reviews than 1296 required. Their review should not be taken as an endorsement of the 1297 feature or underlying primitives, such as cryptographic algorithms 1298 used by a registration. 1300 7.6. Review Appeals 1302 The review appeals process is in accordance with 10 [RFC8126], which 1303 specifies that the normal IETF appeals process as described in 1304 Section 6.5 of [RFC2026] should be followed. 1306 Review appeals *SHOULD* be directly brought to the IESG for 1307 resolution through the iesg@ietf.org mailing list. 1309 The following issues are eligible for the appeals process: 1311 o Registration requests that have not received any Designated Expert 1312 reviews for a period longer than 21 days. 1314 o A review was performed by an inappropriate Designated Expert, for 1315 example, who is strongly suspected of a conflict of interest or 1316 has demonstrated unprofessional behavior or impartiality. 1318 8. Security Considerations 1320 The change to *Specification Required* from *IETF Review* lowers the 1321 barrier to add functionality and cryptographic algorithms for 1322 OpenPGP. 1324 For registries that involve cryptographic algorithms, this change 1325 reflects the practical reality in that the "openpgp" mailing list is 1326 not responsible for cryptographic reviews, which is especially 1327 difficult for national cipher suites. 1329 Security Recommended algorithms are regarded as secure for general 1330 use at the time of registration. However, since cryptographic 1331 algorithms and parameters will be broken or weakened over time, it 1332 *MAY* be possible that the recommended status in the registry lags 1333 behind the most recent advances in cryptanalysis. Implementers and 1334 users *SHOULD* check that the cryptographic algorithms listed 1335 continue to provide the expected level of security desired. 1337 9. IANA Considerations 1339 This document specifies a number of changes to the IANA OpenPGP 1340 registries. 1342 10. Acknowledgements 1344 The authors would like to thank the following individuals for making 1345 this document possible: 1347 o Security Area Directors: Eric Rescola and Kathleen Moriarty; 1349 o The inaugural SECDISPATCH chairs: Tim Polk, Nancy Cam-Winget and 1350 Russ Housley; 1352 o Supporters of this revision scheme: Rich Salz, Sean Leonard, 1353 Richard Barnes, and Daniel Kahn Gillmor. 1355 11. References 1357 11.1. Normative References 1359 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 1360 Requirement Levels", BCP 14, RFC 2119, 1361 DOI 10.17487/RFC2119, March 1997, 1362 . 1364 [RFC4880] Callas, J., Donnerhacke, L., Finney, H., Shaw, D., and R. 1365 Thayer, "OpenPGP Message Format", RFC 4880, 1366 DOI 10.17487/RFC4880, November 2007, 1367 . 1369 [RFC8126] Cotton, M., Leiba, B., and T. Narten, "Guidelines for 1370 Writing an IANA Considerations Section in RFCs", BCP 26, 1371 RFC 8126, DOI 10.17487/RFC8126, June 2017, 1372 . 1374 [RFC8174] Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC 1375 2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174, 1376 May 2017, . 1378 11.2. Informative References 1380 [I-D.ietf-tls-iana-registry-updates] 1381 Salowey, J. and S. Turner, "IANA Registry Updates for TLS 1382 and DTLS", draft-ietf-tls-iana-registry-updates-04 (work 1383 in progress), February 2018. 1385 [RFC1991] Atkins, D., Stallings, W., and P. Zimmermann, "PGP Message 1386 Exchange Formats", RFC 1991, DOI 10.17487/RFC1991, August 1387 1996, . 1389 [RFC2026] Bradner, S., "The Internet Standards Process -- Revision 1390 3", BCP 9, RFC 2026, DOI 10.17487/RFC2026, October 1996, 1391 . 1393 [RFC2144] Adams, C., "The CAST-128 Encryption Algorithm", RFC 2144, 1394 DOI 10.17487/RFC2144, May 1997, 1395 . 1397 [RFC2434] Narten, T. and H. Alvestrand, "Guidelines for Writing an 1398 IANA Considerations Section in RFCs", RFC 2434, 1399 DOI 10.17487/RFC2434, October 1998, 1400 . 1402 [RFC2440] Callas, J., Donnerhacke, L., Finney, H., and R. Thayer, 1403 "OpenPGP Message Format", RFC 2440, DOI 10.17487/RFC2440, 1404 November 1998, . 1406 [RFC5581] Shaw, D., "The Camellia Cipher in OpenPGP", RFC 5581, 1407 DOI 10.17487/RFC5581, June 2009, 1408 . 1410 [RFC6194] Polk, T., Chen, L., Turner, S., and P. Hoffman, "Security 1411 Considerations for the SHA-0 and SHA-1 Message-Digest 1412 Algorithms", RFC 6194, DOI 10.17487/RFC6194, March 2011, 1413 . 1415 [RFC6637] Jivsov, A., "Elliptic Curve Cryptography (ECC) in 1416 OpenPGP", RFC 6637, DOI 10.17487/RFC6637, June 2012, 1417 . 1419 [SHA1-Coll] 1420 Wang, X., Yin, Y., and H. Yu, "Finding collisions in the 1421 full SHA-1", 2005, . 1423 Authors' Addresses 1425 Ronald Henry Tse 1426 Ribose 1427 Suite 1111, 1 Pedder Street 1428 Central, Hong Kong 1429 Hong Kong 1431 Email: ronald.tse@ribose.com 1432 URI: https://www.ribose.com 1434 Werner Koch 1436 Email: wk@gnupg.org