XMSS: eXtended Merkle Signature Scheme
draft-irtf-cfrg-xmss-hash-based-signatures-12

Request for posting confirmation emailed to previous authors: Aziz Mohaisen , Joost Rijneveld , Stefan-Lukas Gazdag , cfrg-chairs@ietf.org, irtf-chair@irtf.org, Denis Butin , Andreas Huelsing

(Via drafts-eval@iana.org): IESG/Authors/WG Chairs:

The IANA Services Operator has completed its review of draft-irtf-cfrg-xmss-hash-based-signatures-10. If any part of this review is inaccurate, please let us know.

The IANA Services Operator has questions about the actions requested in the IANA Considerations section of this document.

One question is for the IESG: this document may be creating registries that use the Specification Required registration procedure, which involves review by a designated expert. Can the IESG designate experts for IRTF-created registries?

The IANA Services Operator understands that, upon approval of this  document, there are three actions which we must complete.

IANA understands that this document requests the creation of three new
registries (see below).

IANA QUESTION -> Where should these new regsitries be located? If you want us to create a new registry page, 1) what should be the title of the page, and 2) should we create a new category at http://www.iana.org/protocols or use an existing category?

IANA QUESTION -> The authors request that "assignments SHOULD use the smallest available palindromic number" for this registry. Could the authors provide a more detailed description of how they intend the registries to be limited to palindromic numbers? For instance, do the authors mean that "0x09000009" would be a palindromic value, but "0x90000009" "0x0000909" would not? As if the octets were individual characters, and a leading "0" can only be treated as padding within the octet? In examining the initial registrations, does "0x05050505" also count as a palindromic number for the purposes of this registries? Is the numeric Identifier "0x00000000" a legitimate candidate for registration in these new registries?

IANA QUESTION --> The authors request that the new registries be maintained using "a specification be documented in an RFC or another permanent and readily available reference in sufficient detail to make interoperability between independent implementations possible." IANA cannot determine whether a specification is sufficient. Do the authors intend to use the "Specification Required" registry maintenance requirement as outlined in RFC8126 for this registry? IANA requests that the authors consult [RFC8126], Section 4 and use a Well-Known registration policy (or policies) for these three registries. If the authors decide  that "Expert Review" or "Specification Required" is the correct policy, they are requested to specify how Expert Review will be conducted for non-IETF documents.

First, a new registry is to be created called the WOTS+ Signatures registry. The new registry will be located in a place to determined (see  above). The registration policy for the new registry will be determined in consultation with the authors (see above). There are initial registrations in the new registry as follows:

Numeric Identifier Name Reference
-------------------+--------------------+--------------------------
0x01000001 WOTSP-SHA2_256 [ RFC-to-be ]; Section 5.2
0x02000002 WOTSP-SHA2_512 [ RFC-to-be ]; Section 5.2
0x03000003 WOTSP-SHAKE_256 [ RFC-to-be ]; Section 5.2
0x04000004 WOTSP-SHAKE_512 [ RFC-to-be ]; Section 5.2
0xDDDDDDDD-0xFFFFFFFF Reserved for Private Use

Second, a new registry is to be created called the XMSS Signatures
registry. The new registry will be located in a place to determined (see
above). The registration policy for the new registry will be determined
in consultation with the authors (see above). There are initial
registrations in the new registry as follows:

Numeric Identifier Name Reference
-------------------+--------------------+--------------------------
0x01000001 XMSS-SHA2_10_256 [ RFC-to-be ]; Section 5.3
0x02000002 XMSS-SHA2_16_256 [ RFC-to-be ]; Section 5.3
0x03000003 XMSS-SHA2_20_256 [ RFC-to-be ]; Section 5.3
0x04000004 XMSS-SHA2_10_512 [ RFC-to-be ]; Section 5.3
0x05000005 XMSS-SHA2_16_512 [ RFC-to-be ]; Section 5.3
0x06000006 XMSS-SHA2_20_512 [ RFC-to-be ]; Section 5.3
0x07000007 XMSS-SHAKE_10_256 [ RFC-to-be ]; Section 5.3
0x08000008 XMSS-SHAKE_16_256 [ RFC-to-be ]; Section 5.3
0x09000009 XMSS-SHAKE_20_256 [ RFC-to-be ]; Section 5.3
0x0a00000a XMSS-SHAKE_10_512 [ RFC-to-be ]; Section 5.3
0x0b00000b XMSS-SHAKE_16_512 [ RFC-to-be ]; Section 5.3
0x0c00000c XMSS-SHAKE_20_512 [ RFC-to-be ]; Section 5.3
0xDDDDDDDD-0xFFFFFFFF Reserved for Private Use

Third, a new registry is to be created called the XMSS^MT Signatures
registry. The new registry will be located in a place to determined (see
above). The registration policy for the new registry will be determined
in consultation with the authors (see above). There are initial
registrations in the new registry as follows:

Numeric Identifier Name Reference
-------------------+----------------------+--------------------------
0x01000001 XMSSMT-SHA2_20/2_256 [ RFC-to-be ]; Section 5.4
0x02000002 XMSSMT-SHA2_20/4_256 [ RFC-to-be ]; Section 5.4
0x03000003 XMSSMT-SHA2_40/2_256 [ RFC-to-be ]; Section 5.4
0x04000004 XMSSMT-SHA2_40/4_256 [ RFC-to-be ]; Section 5.4
0x05000005 XMSSMT-SHA2_40/8_256 [ RFC-to-be ]; Section 5.4
0x06000006 XMSSMT-SHA2_60/3_256 [ RFC-to-be ]; Section 5.4
0x07000007 XMSSMT-SHA2_60/6_256 [ RFC-to-be ]; Section 5.4
0x08000008 XMSSMT-SHA2_60/12_256 [ RFC-to-be ]; Section 5.4
0x09000009 XMSSMT-SHA2_20/2_512 [ RFC-to-be ]; Section 5.4
0x0a00000a XMSSMT-SHA2_20/4_512 [ RFC-to-be ]; Section 5.4
0x0b00000b XMSSMT-SHA2_40/2_512 [ RFC-to-be ]; Section 5.4
0x0c00000c XMSSMT-SHA2_40/4_512 [ RFC-to-be ]; Section 5.4
0x0d00000d XMSSMT-SHA2_40/8_512 [ RFC-to-be ]; Section 5.4
0x0e00000e XMSSMT-SHA2_60/3_512 [ RFC-to-be ]; Section 5.4
0x0f00000f XMSSMT-SHA2_60/6_512 [ RFC-to-be ]; Section 5.4
0x01010101 XMSSMT-SHA2_60/12_512 [ RFC-to-be ]; Section 5.4
0x02010102 XMSSMT-SHAKE_20/2_256 [ RFC-to-be ]; Section 5.4
0x03010103 XMSSMT-SHAKE_20/4_256 [ RFC-to-be ]; Section 5.4
0x04010104 XMSSMT-SHAKE_40/2_256 [ RFC-to-be ]; Section 5.4
0x05010105 XMSSMT-SHAKE_40/4_256 [ RFC-to-be ]; Section 5.4
0x06010106 XMSSMT-SHAKE_40/8_256 [ RFC-to-be ]; Section 5.4
0x07010107 XMSSMT-SHAKE_60/3_256 [ RFC-to-be ]; Section 5.4
0x08010108 XMSSMT-SHAKE_60/6_256 [ RFC-to-be ]; Section 5.4
0x09010109 XMSSMT-SHAKE_60/12_256 [ RFC-to-be ]; Section 5.4
0x0a01010a XMSSMT-SHAKE_20/2_512 [ RFC-to-be ]; Section 5.4
0x0b01010b XMSSMT-SHAKE_20/4_512 [ RFC-to-be ]; Section 5.4
0x0c01010c XMSSMT-SHAKE_40/2_512 [ RFC-to-be ]; Section 5.4
0x0d01010d XMSSMT-SHAKE_40/4_512 [ RFC-to-be ]; Section 5.4
0x0e01010e XMSSMT-SHAKE_40/8_512 [ RFC-to-be ]; Section 5.4
0x0f01010f XMSSMT-SHAKE_60/3_512 [ RFC-to-be ]; Section 5.4
0x01020201 XMSSMT-SHAKE_60/6_512 [ RFC-to-be ]; Section 5.4
0x02020202 XMSSMT-SHAKE_60/12_512 [ RFC-to-be ]; Section 5.4

We understand that this is the complete list of actions required of the IANA Services Operator upon approval of this document. If there are more than three actions, or if any actions have been described incorrectly, please contact us as soon as possible.

Thank you,

Amanda Baber
Lead IANA Services Specialist