Skip to main content

XMSS: eXtended Merkle Signature Scheme
RFC 8391

Revision differences

Document history

Date Rev. By Action
2020-01-21
12 (System) Received changes through RFC Editor sync (added Verified Errata tag)
2018-12-11
12 (System) Received changes through RFC Editor sync (added Errata tag)
2018-06-01
12 (System) IANA registries were updated to include RFC8391
2018-05-31
12 (System)
Received changes through RFC Editor sync (created alias RFC 8391, changed title to 'XMSS: eXtended Merkle Signature Scheme', changed abstract to 'This note describes …
Received changes through RFC Editor sync (created alias RFC 8391, changed title to 'XMSS: eXtended Merkle Signature Scheme', changed abstract to 'This note describes the eXtended Merkle Signature Scheme (XMSS), a hash-based digital signature system that is based on existing descriptions in scientific literature.  This note specifies Winternitz One-Time Signature Plus (WOTS+), a one-time signature scheme; XMSS, a single-tree scheme; and XMSS^MT, a multi-tree variant of XMSS.  Both XMSS and XMSS^MT use WOTS+ as a main building block.  XMSS provides cryptographic digital signatures without relying on the conjectured hardness of mathematical problems.  Instead, it is proven that it only relies on the properties of cryptographic hash functions.  XMSS provides strong security guarantees and is even secure when the collision resistance of the underlying hash function is broken.  It is suitable for compact implementations, is relatively simple to implement, and naturally resists side-channel attacks.  Unlike most other signature systems, hash-based signatures can so far withstand known attacks using quantum computers.', changed pages to 74, changed standardization level to Informational, changed state to RFC, added RFC published event at 2018-05-31, changed IRTF state to Published RFC)
2018-05-31
12 (System) RFC published
2018-05-29
12 (System) RFC Editor state changed to AUTH48-DONE from AUTH48
2018-04-30
12 (System) RFC Editor state changed to AUTH48 from RFC-EDITOR
2018-04-18
12 (System) RFC Editor state changed to RFC-EDITOR from AUTH
2018-03-29
12 (System) RFC Editor state changed to AUTH from EDIT
2018-02-20
12 (System) IANA Action state changed to RFC-Ed-Ack from Waiting on RFC Editor
2018-02-19
12 (System) IANA Action state changed to Waiting on RFC Editor from In Progress
2018-02-19
12 (System) IANA Action state changed to In Progress from Waiting on Authors
2018-02-16
12 (System) IANA Action state changed to Waiting on Authors from In Progress
2018-02-14
12 (System) RFC Editor state changed to EDIT from AUTH
2018-02-13
12 (System) RFC Editor state changed to AUTH from EDIT
2018-02-13
12 (System) RFC Editor state changed to EDIT
2018-02-12
12 (System) IANA Action state changed to In Progress
2018-02-10
12 Allison Mankin IRTF state changed to Sent to the RFC Editor from In IESG Review
2018-02-10
12 Allison Mankin Sent request for publication to the RFC Editor
2018-01-10
12 Amanda Baber IANA Review state changed to IANA OK - Actions Needed from Version Changed - Review Needed
2018-01-10
12 Stefan-Lukas Gazdag New version available: draft-irtf-cfrg-xmss-hash-based-signatures-12.txt
2018-01-10
12 (System) New version approved
2018-01-10
12 (System) Request for posting confirmation emailed to previous authors: Joost Rijneveld , Stefan-Lukas Gazdag , Denis Butin , Andreas Huelsing , Aziz Mohaisen
2018-01-10
12 Stefan-Lukas Gazdag Uploaded new revision
2017-12-13
11 (System) IANA Review state changed to Version Changed - Review Needed from IANA - Not OK
2017-12-13
11 Stefan-Lukas Gazdag New version available: draft-irtf-cfrg-xmss-hash-based-signatures-11.txt
2017-12-13
11 (System) New version approved
2017-12-13
11 (System)
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 …
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
2017-12-13
11 Stefan-Lukas Gazdag Uploaded new revision
2017-11-27
10 (System) IANA Review state changed to IANA - Not OK
2017-11-27
10 Amanda Baber
(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 …
(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
2017-11-21
10 Alexey Melnikov IRTF state changed to In IESG Review from In IRSG Poll
2017-11-11
10 Allison Mankin IETF conflict review initiated - see conflict-review-irtf-cfrg-xmss-hash-based-signatures
2017-10-29
10 Alexey Melnikov To finish on November 19th.
2017-10-29
10 Alexey Melnikov IRTF state changed to In IRSG Poll from Waiting for IRTF Chair
2017-07-24
10 Stefan-Lukas Gazdag New version available: draft-irtf-cfrg-xmss-hash-based-signatures-10.txt
2017-07-24
10 (System) New version approved
2017-07-24
10 (System) Request for posting confirmation emailed to previous authors: Aziz Mohaisen , Stefan-Lukas Gazdag , cfrg-chairs@ietf.org, irtf-chair@irtf.org, Denis Butin , Andreas Huelsing
2017-07-24
10 Stefan-Lukas Gazdag Uploaded new revision
2017-03-30
09 Stefan-Lukas Gazdag New version available: draft-irtf-cfrg-xmss-hash-based-signatures-09.txt
2017-03-30
09 (System) New version approved
2017-03-30
09 (System) Request for posting confirmation emailed to previous authors: Stefan-Lukas Gazdag , Denis Butin , Andreas Huelsing , Aziz Mohaisen
2017-03-30
09 Stefan-Lukas Gazdag Uploaded new revision
2017-03-21
08 Kenny Paterson I (Kenny Paterson) have reviewed this document, and it is ready for ISRG review.
2017-03-21
08 Kenny Paterson IRTF state changed to Waiting for IRTF Chair from Waiting for Document Shepherd
2017-03-10
08 Stefan-Lukas Gazdag New version available: draft-irtf-cfrg-xmss-hash-based-signatures-08.txt
2017-03-10
08 (System) New version approved
2017-03-10
08 (System) Request for posting confirmation emailed to previous authors: Stefan-Lukas Gazdag , Denis Butin , Andreas Huelsing , Aziz Mohaisen
2017-03-10
08 Stefan-Lukas Gazdag Uploaded new revision
2016-10-28
07 Kenny Paterson Kenny Paterson will act as document shepherd and will complete review by 4th November 2016.
2016-10-19
07 Stefan-Lukas Gazdag New version available: draft-irtf-cfrg-xmss-hash-based-signatures-07.txt
2016-10-19
07 (System) New version approved
2016-10-19
06 (System) Request for posting confirmation emailed to previous authors: "Andreas Huelsing" , "Stefan-Lukas Gazdag" , "Denis Butin" , "Aziz Mohaisen"
2016-10-19
06 Stefan-Lukas Gazdag Uploaded new revision
2016-07-06
06 Stefan-Lukas Gazdag New version available: draft-irtf-cfrg-xmss-hash-based-signatures-06.txt
2016-06-23
05 Stefan-Lukas Gazdag New version available: draft-irtf-cfrg-xmss-hash-based-signatures-05.txt
2016-06-23
05 Stefan-Lukas Gazdag New version available: draft-irtf-cfrg-xmss-hash-based-signatures-05.txt
2016-06-22
04 Stefan-Lukas Gazdag New version available: draft-irtf-cfrg-xmss-hash-based-signatures-04.txt
2016-05-29
03 Alexey Melnikov Changed consensus to Yes from Unknown
2016-05-29
03 Alexey Melnikov IRTF state changed to Waiting for Document Shepherd from In RG Last Call
2016-05-29
03 Alexey Melnikov Intended Status changed to Informational from None
2016-03-16
03 Kenny Paterson IRTF state changed to In RG Last Call from Active RG Document
2016-03-01
03 Alexey Melnikov Chairs to review if the document is ready for RGLC.
2016-03-01
03 Alexey Melnikov IRTF state changed to Active RG Document
2016-02-15
03 Stefan-Lukas Gazdag New version available: draft-irtf-cfrg-xmss-hash-based-signatures-03.txt
2016-01-03
02 Stefan-Lukas Gazdag New version available: draft-irtf-cfrg-xmss-hash-based-signatures-02.txt
2015-07-03
01 Stefan-Lukas Gazdag New version available: draft-irtf-cfrg-xmss-hash-based-signatures-01.txt
2015-04-08
00 Andreas Huelsing New version available: draft-irtf-cfrg-xmss-hash-based-signatures-00.txt