rfc9802.original   rfc9802.txt 
LAMPS - Limited Additional Mechanisms for PKIX and SMIME D. Van Geest Internet Engineering Task Force (IETF) D. Van Geest
Internet-Draft CryptoNext Security Request for Comments: 9802 CryptoNext Security
Intended status: Standards Track K. Bashiri Category: Standards Track K. Bashiri
Expires: 15 June 2025 BSI ISSN: 2070-1721 BSI
S. Fluhrer S. Fluhrer
Cisco Systems Cisco Systems
S. Gazdag S. Gazdag
genua GmbH genua GmbH
S. Kousidis S. Kousidis
BSI BSI
12 December 2024 June 2025
Use of the HSS and XMSS Hash-Based Signature Algorithms in Internet Use of the HSS and XMSS Hash-Based Signature Algorithms in Internet
X.509 Public Key Infrastructure X.509 Public Key Infrastructure
draft-ietf-lamps-x509-shbs-13
Abstract Abstract
This document specifies algorithm identifiers and ASN.1 encoding This document specifies algorithm identifiers and ASN.1 encoding
formats for the stateful hash-based signature (HBS) schemes formats for the following stateful Hash-Based Signature (HBS)
Hierarchical Signature System (HSS), eXtended Merkle Signature Scheme schemes: Hierarchical Signature System (HSS), eXtended Merkle
(XMSS), and XMSS^MT, a multi-tree variant of XMSS. This Signature Scheme (XMSS), and XMSS^MT (a multi-tree variant of XMSS).
specification applies to the Internet X.509 Public Key infrastructure This specification applies to the Internet X.509 Public Key
(PKI) when those digital signatures are used in Internet X.509 Infrastructure (PKI) when digital signatures are used to sign
certificates and certificate revocation lists. certificates and certificate revocation lists (CRLs).
About This Document
This note is to be removed before publishing as an RFC.
Status information for this document may be found at
https://datatracker.ietf.org/doc/draft-ietf-lamps-x509-shbs/.
Discussion of this document takes place on the LAMPS Working Group
mailing list (mailto:spasm@ietf.org), which is archived at
https://mailarchive.ietf.org/arch/browse/spasm/. Subscribe at
https://www.ietf.org/mailman/listinfo/spasm/.
Source for this draft and an issue tracker can be found at
https://github.com/x509-hbs/draft-x509-shbs.
Status of This Memo Status of This Memo
This Internet-Draft is submitted in full conformance with the This is an Internet Standards Track document.
provisions of BCP 78 and BCP 79.
Internet-Drafts are working documents of the Internet Engineering
Task Force (IETF). Note that other groups may also distribute
working documents as Internet-Drafts. The list of current Internet-
Drafts is at https://datatracker.ietf.org/drafts/current/.
Internet-Drafts are draft documents valid for a maximum of six months This document is a product of the Internet Engineering Task Force
and may be updated, replaced, or obsoleted by other documents at any (IETF). It represents the consensus of the IETF community. It has
time. It is inappropriate to use Internet-Drafts as reference received public review and has been approved for publication by the
material or to cite them other than as "work in progress." Internet Engineering Steering Group (IESG). Further information on
Internet Standards is available in Section 2 of RFC 7841.
This Internet-Draft will expire on 15 June 2025. Information about the current status of this document, any errata,
and how to provide feedback on it may be obtained at
https://www.rfc-editor.org/info/rfc9802.
Copyright Notice Copyright Notice
Copyright (c) 2024 IETF Trust and the persons identified as the Copyright (c) 2025 IETF Trust and the persons identified as the
document authors. All rights reserved. document authors. All rights reserved.
This document is subject to BCP 78 and the IETF Trust's Legal This document is subject to BCP 78 and the IETF Trust's Legal
Provisions Relating to IETF Documents (https://trustee.ietf.org/ Provisions Relating to IETF Documents
license-info) in effect on the date of publication of this document. (https://trustee.ietf.org/license-info) in effect on the date of
Please review these documents carefully, as they describe your rights publication of this document. Please review these documents
and restrictions with respect to this document. Code Components carefully, as they describe your rights and restrictions with respect
extracted from this document must include Revised BSD License text as to this document. Code Components extracted from this document must
described in Section 4.e of the Trust Legal Provisions and are include Revised BSD License text as described in Section 4.e of the
provided without warranty as described in the Revised BSD License. Trust Legal Provisions and are provided without warranty as described
in the Revised BSD License.
Table of Contents Table of Contents
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 3 1. Introduction
2. Conventions and Definitions . . . . . . . . . . . . . . . . . 3 2. Conventions and Definitions
3. Use Cases of Stateful HBS Schemes in X.509 . . . . . . . . . 4 3. Use Cases of Stateful HBS Schemes in X.509
4. Algorithm Identifiers and Parameters . . . . . . . . . . . . 5 4. Algorithm Identifiers and Parameters
4.1. HSS Algorithm Identifier . . . . . . . . . . . . . . . . 5 4.1. HSS Algorithm Identifier
4.2. XMSS Algorithm Identifier . . . . . . . . . . . . . . . . 6 4.2. XMSS Algorithm Identifier
4.3. XMSS^MT Algorithm Identifier . . . . . . . . . . . . . . 6 4.3. XMSS^MT Algorithm Identifier
5. Public Key Identifiers . . . . . . . . . . . . . . . . . . . 7 5. Public Key Identifiers
5.1. HSS Public Keys . . . . . . . . . . . . . . . . . . . . . 7 5.1. HSS Public Keys
5.2. XMSS Public Keys . . . . . . . . . . . . . . . . . . . . 7 5.2. XMSS Public Keys
5.3. XMSS^MT Public Keys . . . . . . . . . . . . . . . . . . . 8 5.3. XMSS^MT Public Keys
6. Key Usage Bits . . . . . . . . . . . . . . . . . . . . . . . 8 6. Key Usage Bits
7. Signature Algorithms . . . . . . . . . . . . . . . . . . . . 9 7. Signature Algorithms
7.1. HSS Signature Algorithm . . . . . . . . . . . . . . . . . 9 7.1. HSS Signature Algorithm
7.2. XMSS Signature Algorithm . . . . . . . . . . . . . . . . 9 7.2. XMSS Signature Algorithm
7.3. XMSS^MT Signature Algorithm . . . . . . . . . . . . . . . 10 7.3. XMSS^MT Signature Algorithm
8. Key Generation . . . . . . . . . . . . . . . . . . . . . . . 10 8. Key Generation
9. ASN.1 Module . . . . . . . . . . . . . . . . . . . . . . . . 10 9. ASN.1 Module
10. Security Considerations . . . . . . . . . . . . . . . . . . . 12 10. Security Considerations
11. Backup and Restore Management . . . . . . . . . . . . . . . . 13 11. Backup and Restore Management
12. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 13 12. IANA Considerations
13. References . . . . . . . . . . . . . . . . . . . . . . . . . 14 13. References
13.1. Normative References . . . . . . . . . . . . . . . . . . 14 13.1. Normative References
13.2. Informative References . . . . . . . . . . . . . . . . . 15 13.2. Informative References
Appendix A. HSS X.509 v3 Certificate Example . . . . . . . . . . 17 Appendix A. HSS X.509 v3 Certificate Example
Appendix B. XMSS X.509 v3 Certificate Example . . . . . . . . . 20 Appendix B. XMSS X.509 v3 Certificate Example
Appendix C. XMSS^MT X.509 v3 Certificate Example . . . . . . . . 26 Appendix C. XMSS^MT X.509 v3 Certificate Example
Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . . . 35 Acknowledgments
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 35 Authors' Addresses
1. Introduction 1. Introduction
Stateful HBS schemes such as HSS, XMSS and XMSS^MT combine Merkle Stateful Hash-Based Signature (HBS) schemes such as the Hierarchical
trees with One Time Signatures (OTS) in order to provide digital Signature System (HSS), eXtended Merkle Signature Scheme (XMSS), and
signature schemes that remain secure even when quantum computers XMSS^MT combine Merkle trees with One-Time Signatures (OTS). This is
become available. Their theoretic security is well understood and done in order to provide digital signature schemes that remain secure
depends only on the security of the underlying hash function. As even when quantum computers become available. Their theoretic
such they can serve as an important building block for quantum security is well understood and depends only on the security of the
computer resistant information and communication technology. underlying hash function. As such, they can serve as an important
building block for quantum computer resistant information and
communication technology.
A stateful HBS private key consists of a finite collection of OTS A stateful HBS private key consists of a finite collection of OTS
keys, along with state information that tracks the usage of these keys, along with state information that tracks the usage of these
keys to ensure the security of the scheme. Only a limited number of keys to ensure the security of the scheme. Only a limited number of
messages can be signed and the private key's state must be updated messages can be signed, and the private key's state must be updated
and persisted after signing to prevent reuse of OTS keys. While the and persisted after signing to prevent reuse of OTS keys. While the
right selection of algorithm parameters would allow a private key to right selection of algorithm parameters would allow a private key to
sign a virtually unbounded number of messages (e.g. 2^60), this is at sign a virtually unbounded number of messages (e.g., 2^60), this is
the cost of a larger signature size and longer signing time. Because at the cost of a larger signature size and longer signing time.
the private key in stateful HBS schemes is stateful and the number of Because the private key in stateful HBS schemes is stateful and the
signatures that can be generated is limited, these schemes may be number of signatures that can be generated is limited, these schemes
unsuitable for use in interactive protocols. However, in some use may be unsuitable for use in interactive protocols. However, in some
cases the deployment of stateful HBS schemes may be appropriate. use cases, the deployment of stateful HBS schemes may be appropriate.
Such use cases are described and discussed in Section 3. Such use cases are described and discussed in Section 3.
2. Conventions and Definitions 2. Conventions and Definitions
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
"SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and
"OPTIONAL" in this document are to be interpreted as described in "OPTIONAL" in this document are to be interpreted as described in
BCP 14 [RFC2119] [RFC8174] when, and only when, they appear in all BCP 14 [RFC2119] [RFC8174] when, and only when, they appear in all
capitals, as shown here. capitals, as shown here.
3. Use Cases of Stateful HBS Schemes in X.509 3. Use Cases of Stateful HBS Schemes in X.509
As described in the Security Considerations of Section 10, it is As described in the Security Considerations in Section 10, it is
imperative that stateful HBS implementations do not reuse OTS imperative that stateful HBS implementations do not reuse OTS
signatures. This makes stateful HBS algorithms inappropriate for signatures. This makes stateful HBS algorithms inappropriate for
general use cases. The exact conditions under which stateful HBS general use cases. The exact conditions under which stateful HBS
certificates may be used is left to certificate policies [RFC3647]. certificates may be used is left to certificate policies [RFC3647].
However the intended use of stateful HBS schemes as described by However, the intended use of stateful HBS schemes as described by
[SP800208] can be used as a guideline: [SP800208] can be used as a guideline:
| 1) it is necessary to implement a digital signature scheme in the | stateful HBS schemes are primarily intended for applications with
| near future; | the following characteristics: 1) it is necessary to implement a
| 2) the implementation will have a long lifetime; and | digital signature scheme in the near future; 2) the implementation
| 3) it would not be practical to transition to a different digital | will have a long lifetime; and 3) it would not be practical to
| signature scheme once the implementation has been deployed. | transition to a different digital signature scheme once the
| implementation has been deployed.
In addition, since a stateful HBS private key can only generate a In addition, since a stateful HBS private key can only generate a
finite number of signatures, use cases for stateful HBS public keys finite number of signatures, use cases for stateful HBS public keys
in certificates should have a predictable range of the number of in certificates should have a predictable range of the number of
signatures that will be generated, falling safely below the maximum signatures that will be generated, falling safely below the maximum
number of signatures that a private key can generate. number of signatures that a private key can generate.
Use cases where stateful HBS public keys in certificates may be Use cases where stateful HBS public keys in certificates may be
appropriate due to the relatively small number of signatures appropriate due to the relatively small number of signatures
generated and the signer's ability to enforce security restrictions generated and the signer's ability to enforce security restrictions
on the signing environment include: on the signing environment include:
* Firmware signing (Section 1.1 of [SP800208], Table IV of * Firmware signing (see Section 1.1 of [SP800208], [CNSA2.0], and
[CNSA2.0], Section 6.7 of [BSI]) Section 6.7 of [BSI])
* Software signing (Table IV of [CNSA2.0], [ANSSI]) * Software signing ([CNSA2.0] and [ANSSI])
* Certification Authority (CA) certificates. * Certification Authority (CA) certificates
In each of these cases the operator tightly controls their secured In each of these cases, the operator tightly controls their secured
signing environment and can mitigate OTS key reuse by employing state signing environment and can mitigate OTS key reuse by employing state
management strategies such as those in Section 10. Also for secure management strategies such as those in Section 10. Also, for secure
private key backup and restoration, adequate mechanisms have to be private key backup and restoration, adequate mechanisms have to be
implemented (Section 11). implemented (see Section 11).
Generally speaking, stateful HBS public keys are not appropriate for Generally speaking, stateful HBS public keys are not appropriate for
use in end-entity certificates, however in the firmware and software use in end-entity certificates, however, in the firmware and software
signing cases signature generation will often be more tightly signing cases, signature generation will often be more tightly
controlled. Some manufactures use common and well-established key controlled. Some manufactures use common and well-established key
formats like X.509 for their code signing and update mechanisms. formats like X.509 for their code signing and update mechanisms.
Also there are multi-party IoT ecosystems where publicly trusted code Also, there are multi-party Internet of Things (IoT) ecosystems where
signing certificates are useful. publicly trusted code signing certificates are useful.
In general, root CAs [RFC4949] generate signatures in a more secure In general, root CAs [RFC4949] generate signatures in a more secure
environment and issue fewer certificates than subordinate CAs environment and issue fewer certificates than subordinate CAs
[RFC4949]. This makes the use of stateful HBS public keys more [RFC4949]. This makes the use of stateful HBS public keys more
appropriate in root CA certificates than in subordinate CA appropriate in root CA certificates than in subordinate CA
certificates. However, if a subordinate CA can match the security certificates. However, if a subordinate CA can match the security
and signature count restrictions of a root CA, for example if the and signature count restrictions of a root CA, for example, if the
subordinate CA only issues code-signing certificates, then using a subordinate CA only issues code-signing certificates, then using a
stateful HBS public key in the subordinate CA certificate may be stateful HBS public key in the subordinate CA certificate may be
practical. practical.
4. Algorithm Identifiers and Parameters 4. Algorithm Identifiers and Parameters
In this document, we define new object identifiers (OIDs) for In this document, we define new Object Identifiers (OIDs) for
identifying the different stateful hash-based signature algorithms. identifying the different stateful hash-based signature algorithms.
An additional OID is defined in [I-D.ietf-lamps-rfc8708bis] and An additional OID is defined in [RFC9708] and repeated here for
repeated here for convenience. convenience.
The AlgorithmIdentifier type is defined in [RFC5912] as follows: The AlgorithmIdentifier type is defined in [RFC5912] as follows:
AlgorithmIdentifier{ALGORITHM-TYPE, ALGORITHM-TYPE:AlgorithmSet} ::= AlgorithmIdentifier{ALGORITHM-TYPE, ALGORITHM-TYPE:AlgorithmSet} ::=
SEQUENCE { SEQUENCE {
algorithm ALGORITHM-TYPE.&id({AlgorithmSet}), algorithm ALGORITHM-TYPE.&id({AlgorithmSet}),
parameters ALGORITHM-TYPE. parameters ALGORITHM-TYPE.
&Params({AlgorithmSet}{@algorithm}) OPTIONAL &Params({AlgorithmSet}{@algorithm}) OPTIONAL
} }
| NOTE: The above syntax is from [RFC5912] and is compatible with | NOTE: The above syntax is from [RFC5912] and is compatible with
| the 2021 ASN.1 syntax [X680]. See [RFC5280] for the 1988 ASN.1 | the 2021 ASN.1 syntax [X680]. See [RFC5280] for the 1988 ASN.1
| syntax. | syntax.
The fields in AlgorithmIdentifier have the following meanings: The fields in AlgorithmIdentifier have the following meanings:
* algorithm identifies the cryptographic algorithm with an object algorithm: this identifies the cryptographic algorithm with an OID.
identifier.
* parameters, which are optional, are the associated parameters for parameters: these are optional and are the associated parameters for
the algorithm identifier in the algorithm field. the algorithm identifier in the algorithm field.
The parameters field of the AlgorithmIdentifier for HSS, XMSS, and The parameters field of the AlgorithmIdentifier for HSS, XMSS, and
XMSS^MT public keys MUST be absent. XMSS^MT public keys MUST be absent.
4.1. HSS Algorithm Identifier 4.1. HSS Algorithm Identifier
The object identifier and public key algorithm identifier for HSS is The OID and public key algorithm identifier for HSS is defined in
defined in [I-D.ietf-lamps-rfc8708bis]. The definitions are repeated [RFC9708]. The definitions are repeated here for reference.
here for reference.
The AlgorithmIdentifier for an HSS public key MUST use the id-alg- The AlgorithmIdentifier for an HSS public key MUST use the id-alg-
hss-lms-hashsig object identifier. hss-lms-hashsig OID.
id-alg-hss-lms-hashsig OBJECT IDENTIFIER ::= { id-alg-hss-lms-hashsig OBJECT IDENTIFIER ::= {
iso(1) member-body(2) us(840) rsadsi(113549) pkcs(1) pkcs9(9) iso(1) member-body(2) us(840) rsadsi(113549) pkcs(1) pkcs9(9)
smime(16) alg(3) 17 } smime(16) alg(3) 17 }
Note that the id-alg-hss-lms-hashsig algorithm identifier is also Note that the id-alg-hss-lms-hashsig algorithm identifier is also
referred to as id-alg-mts-hashsig. This synonym is based on the referred to as id-alg-mts-hashsig. This synonym is based on the
terminology used in an early draft of the document that became terminology used in an early draft of the document that became
[RFC8554]. [RFC8554].
The public key and signature values identify the hash function and The public key and signature values identify the hash function and
the height used in the HSS tree. [RFC8554] and [SP800208] define the height used in the HSS tree. [RFC8554] and [SP800208] define
these values, but an IANA registry [IANA-LMS] permits the these values, and additional identifiers can be registered in the
registration of additional identifiers in the future. “Leighton-Micali Signatures (LMS)” registry [IANA-LMS].
4.2. XMSS Algorithm Identifier 4.2. XMSS Algorithm Identifier
The AlgorithmIdentifier for an XMSS public key MUST use the id-alg- The AlgorithmIdentifier for an XMSS public key MUST use the id-alg-
xmss-hashsig object identifier. xmss-hashsig OID.
id-alg-xmss-hashsig OBJECT IDENTIFIER ::= { id-alg-xmss-hashsig OBJECT IDENTIFIER ::= {
iso(1) identified-organization(3) dod(6) internet(1) iso(1) identified-organization(3) dod(6) internet(1)
security(5) mechanisms(5) pkix(7) algorithms(6) 34 } security(5) mechanisms(5) pkix(7) algorithms(6) 34 }
The public key and signature values identify the hash function and The public key and signature values identify the hash function and
the height used in the XMSS tree. [RFC8391] and [SP800208] define the height used in the XMSS tree. [RFC8391] and [SP800208] define
these values, but an IANA registry [IANA-XMSS] permits the these values, and additional identifiers can be registered in the
registration of additional identifiers in the future. “Leighton-Micali Signatures (LMS)” registry [IANA-XMSS].
4.3. XMSS^MT Algorithm Identifier 4.3. XMSS^MT Algorithm Identifier
The AlgorithmIdentifier for an XMSS^MT public key MUST use the id- The AlgorithmIdentifier for an XMSS^MT public key MUST use the id-
alg-xmssmt-hashsig object identifier. alg-xmssmt-hashsig OID.
id-alg-xmssmt-hashsig OBJECT IDENTIFIER ::= { id-alg-xmssmt-hashsig OBJECT IDENTIFIER ::= {
iso(1) identified-organization(3) dod(6) internet(1) iso(1) identified-organization(3) dod(6) internet(1)
security(5) mechanisms(5) pkix(7) algorithms(6) 35 } security(5) mechanisms(5) pkix(7) algorithms(6) 35 }
The public key and signature values identify the hash function and The public key and signature values identify the hash function and
the height used in the XMSS^MT tree. [RFC8391] and [SP800208] define the height used in the XMSS^MT tree. [RFC8391] and [SP800208] define
these values, but an IANA registry [IANA-XMSS] permits the these values, and additional identifiers can be registered in the
registration of additional identifiers in the future. “Leighton-Micali Signatures (LMS)” registry [IANA-XMSS].
5. Public Key Identifiers 5. Public Key Identifiers
Certificates conforming to [RFC5280] can convey a public key for any Certificates conforming to [RFC5280] can convey a public key for any
public key algorithm. The certificate indicates the algorithm public key algorithm. The certificate indicates the algorithm
through an algorithm identifier. An algorithm identifier consists of through an algorithm identifier. An algorithm identifier consists of
an OID and optional parameters. an OID and optional parameters.
[RFC8554] defines the encoding of HSS public keys and [RFC8391] [RFC8554] defines the encoding of HSS public keys, and [RFC8391]
defines the encodings of XMSS and XMSS^MT public keys. When used in defines the encodings of XMSS and XMSS^MT public keys. When used in
a SubjectPublicKeyInfo type, the subjectPublicKey BIT STRING contains a SubjectPublicKeyInfo type, the subjectPublicKey BIT STRING contains
these encodings of the public key. these encodings of the public key.
This document defines ASN.1 [X680] OCTET STRING types for encoding This document defines ASN.1 [X680] OCTET STRING types for encoding
the public keys when not used in a SubjectPublicKeyInfo. The OCTET the public keys when not used in a SubjectPublicKeyInfo. The OCTET
STRING is mapped to a subjectPublicKey (a value of type BIT STRING) STRING is mapped to a subjectPublicKey (a value of type BIT STRING)
as follows: the most significant bit of the OCTET STRING value as follows: the most significant bit of the OCTET STRING value
becomes the most significant bit of the BIT STRING value, and so on; becomes the most significant bit of the BIT STRING value, and so on;
the least significant bit of the OCTET STRING becomes the least the least significant bit of the OCTET STRING becomes the least
skipping to change at page 7, line 44 skipping to change at line 300
{ digitalSignature, nonRepudiation, keyCertSign, cRLSign } } { digitalSignature, nonRepudiation, keyCertSign, cRLSign } }
The HSS public key is defined as follows: The HSS public key is defined as follows:
HSS-LMS-HashSig-PublicKey ::= OCTET STRING HSS-LMS-HashSig-PublicKey ::= OCTET STRING
[RFC8554] defines the encoding of an HSS public key using the [RFC8554] defines the encoding of an HSS public key using the
hss_public_key structure. See [SP800208] and [RFC8554] for more hss_public_key structure. See [SP800208] and [RFC8554] for more
information on the contents and format of an HSS public key. Note information on the contents and format of an HSS public key. Note
that the Leighton-Micali Signature (LMS) single-tree signature scheme that the Leighton-Micali Signature (LMS) single-tree signature scheme
is instantiated as HSS with number of levels being equal to 1. is instantiated as HSS with the number of levels being equal to 1.
5.2. XMSS Public Keys 5.2. XMSS Public Keys
The XMSS public key identifier is as follows: The XMSS public key identifier is as follows:
pk-XMSS-HashSig PUBLIC-KEY ::= { pk-XMSS-HashSig PUBLIC-KEY ::= {
IDENTIFIER id-alg-xmss-hashsig IDENTIFIER id-alg-xmss-hashsig
-- KEY no ASN.1 wrapping -- -- KEY no ASN.1 wrapping --
PARAMS ARE absent PARAMS ARE absent
CERT-KEY-USAGE CERT-KEY-USAGE
skipping to change at page 8, line 43 skipping to change at line 344
XMSSMT-HashSig-PublicKey ::= OCTET STRING XMSSMT-HashSig-PublicKey ::= OCTET STRING
[RFC8391] defines the encoding of an XMSS^MT public key using the [RFC8391] defines the encoding of an XMSS^MT public key using the
xmssmt_public_key structure. See [SP800208] and [RFC8391] for more xmssmt_public_key structure. See [SP800208] and [RFC8391] for more
information on the contents and format of an XMSS^MT public key. information on the contents and format of an XMSS^MT public key.
6. Key Usage Bits 6. Key Usage Bits
The intended application for the key is indicated in the keyUsage The intended application for the key is indicated in the keyUsage
certificate extension [RFC5280]. When id-alg-hss-lms-hashsig, id- certificate extension [RFC5280]. When id-alg-hss-lms-hashsig, id-
alg-xmss-hashsig or id-alg-xmssmt-hashsig appears in the alg-xmss-hashsig, or id-alg-xmssmt-hashsig appears in the
SubjectPublicKeyInfo field of a CA X.509 certificate [RFC5280], the SubjectPublicKeyInfo field of a CA X.509 certificate [RFC5280], the
certificate key usage extension MUST contain at least one of the certificate key usage extension MUST contain at least one of the
following values: digitalSignature, nonRepudiation, keyCertSign, or following values: digitalSignature, nonRepudiation, keyCertSign, or
cRLSign. However, it MUST NOT contain other values. cRLSign. However, it MUST NOT contain other values.
When id-alg-hss-lms-hashsig, id-alg-xmss-hashsig or id-alg-xmssmt- When id-alg-hss-lms-hashsig, id-alg-xmss-hashsig, or id-alg-xmssmt-
hashsig appears in the SubjectPublicKeyInfo field of an end entity hashsig appears in the SubjectPublicKeyInfo field of an end entity
X.509 certificate [RFC5280], the certificate key usage extension MUST X.509 certificate [RFC5280], the certificate key usage extension MUST
contain at least one of the following values: digitalSignature, contain at least one of the following values: digitalSignature,
nonRepudiation or cRLSign. However, it MUST NOT contain other nonRepudiation or cRLSign. However, it MUST NOT contain other
values. values.
7. Signature Algorithms 7. Signature Algorithms
The same OIDs used to identify HSS, XMSS, and XMSS^MT public keys are The same OIDs used to identify HSS, XMSS, and XMSS^MT public keys are
also used to identify their respective signatures. When these also used to identify their respective signatures. When these
skipping to change at page 9, line 28 skipping to change at line 373
That is, the AlgorithmIdentifier SHALL be a SEQUENCE of one That is, the AlgorithmIdentifier SHALL be a SEQUENCE of one
component, one of the OIDs defined in the following subsections. component, one of the OIDs defined in the following subsections.
When the signature algorithm identifiers described in this document When the signature algorithm identifiers described in this document
are used to create a signature on a message, no digest algorithm is are used to create a signature on a message, no digest algorithm is
applied to the message before signing. That is, the full data to be applied to the message before signing. That is, the full data to be
signed is signed rather than a digest of the data. signed is signed rather than a digest of the data.
The format of an HSS signature is described in Section 6.2 of The format of an HSS signature is described in Section 6.2 of
[RFC8554]. The format of an XMSS signature is described in [RFC8554]. The format of an XMSS signature is described in
Appendix B.2 of [RFC8391] and the format of an XMSS^MT signature is Appendix B.2 of [RFC8391], and the format of an XMSS^MT signature is
described in Appendix C.2 of [RFC8391]. The octet string described in Appendix C.2 of [RFC8391]. The octet string
representing the signature is encoded directly in a BIT STRING representing the signature is encoded directly in a BIT STRING
without adding any additional ASN.1 wrapping. For the Certificate without adding any additional ASN.1 wrapping. For the Certificate
and CertificateList structures, the octet string is encoded in the and CertificateList structures, the octet string is encoded in the
"signatureValue" BIT STRING field. "signatureValue" BIT STRING field.
7.1. HSS Signature Algorithm 7.1. HSS Signature Algorithm
The id-alg-hss-lms-hashsig OID is used to specify that an HSS The id-alg-hss-lms-hashsig OID is used to specify that an HSS
signature was generated on the full message, i.e. the message was not signature was generated on the full message, i.e., the message was
hashed before being processed by the HSS signature algorithm. not hashed before being processed by the HSS signature algorithm.
See [SP800208] and [RFC8554] for more information on the contents and See [SP800208] and [RFC8554] for more information on the contents and
format of an HSS signature. format of an HSS signature.
7.2. XMSS Signature Algorithm 7.2. XMSS Signature Algorithm
The id-alg-xmss-hashsig OID is used to specify that an XMSS signature The id-alg-xmss-hashsig OID is used to specify that an XMSS signature
was generated on the full message, i.e. the message was not hashed was generated on the full message, i.e., the message was not hashed
before being processed by the XMSS signature algorithm. before being processed by the XMSS signature algorithm.
See [SP800208] and [RFC8391] for more information on the contents and See [SP800208] and [RFC8391] for more information on the contents and
format of an XMSS signature. format of an XMSS signature.
The signature generation MUST be performed according to 7.2 of The signature generation MUST be performed according to Section 7.2
[SP800208]. of [SP800208].
7.3. XMSS^MT Signature Algorithm 7.3. XMSS^MT Signature Algorithm
The id-alg-xmssmt-hashsig OID is used to specify that an XMSS^MT The id-alg-xmssmt-hashsig OID is used to specify that an XMSS^MT
signature was generated on the full message, i.e. the message was not signature was generated on the full message, i.e., the message was
hashed before being processed by the XMSS^MT signature algorithm. not hashed before being processed by the XMSS^MT signature algorithm.
See [SP800208] and [RFC8391] for more information on the contents and See [SP800208] and [RFC8391] for more information on the contents and
format of an XMSS^MT signature. format of an XMSS^MT signature.
The signature generation MUST be performed according to 7.2 of The signature generation MUST be performed according to Section 7.2
[SP800208]. of [SP800208].
8. Key Generation 8. Key Generation
The key generation for XMSS and XMSS^MT MUST be performed according The key generation for XMSS and XMSS^MT MUST be performed according
to 7.2 of [SP800208] to Section 7.2 of [SP800208].
9. ASN.1 Module 9. ASN.1 Module
For reference purposes, the ASN.1 syntax is presented as an ASN.1 For reference purposes, the ASN.1 syntax is presented as an ASN.1
module here [X680]. Note that as per [RFC5280], certificates use the module here [X680]. Note that as per [RFC5280], certificates use the
Distinguished Encoding Rules; see [X690]. This ASN.1 Module builds Distinguished Encoding Rules; see [X690]. This ASN.1 module builds
upon the conventions established in [RFC5912]. This module imports upon the conventions established in [RFC5912]. This module imports
objects from [RFC5912] and [I-D.ietf-lamps-rfc8708bis]. objects from [RFC5912] and [RFC9708].
RFC EDITOR: Please replace [I-D.ietf-lamps-rfc8708bis] in the module
with a reference to the published RFC.
X509-SHBS-2024 X509-SHBS-2024
{ iso(1) identified-organization(3) dod(6) internet(1) security(5) { iso(1) identified-organization(3) dod(6) internet(1) security(5)
mechanisms(5) pkix(7) id-mod(0) id-mod-pkix1-shbs-2024(TBD) } mechanisms(5) pkix(7) id-mod(0) id-mod-pkix1-shbs-2024(114) }
DEFINITIONS IMPLICIT TAGS ::= BEGIN DEFINITIONS IMPLICIT TAGS ::= BEGIN
EXPORTS ALL; EXPORTS ALL;
IMPORTS IMPORTS
PUBLIC-KEY, SIGNATURE-ALGORITHM PUBLIC-KEY, SIGNATURE-ALGORITHM
FROM AlgorithmInformation-2009 -- [RFC5912] FROM AlgorithmInformation-2009 -- [RFC5912]
{ iso(1) identified-organization(3) dod(6) internet(1) { iso(1) identified-organization(3) dod(6) internet(1)
security(5) mechanisms(5) pkix(7) id-mod(0) security(5) mechanisms(5) pkix(7) id-mod(0)
id-mod-algorithmInformation-02(58) } id-mod-algorithmInformation-02(58) }
sa-HSS-LMS-HashSig, pk-HSS-LMS-HashSig sa-HSS-LMS-HashSig, pk-HSS-LMS-HashSig
FROM MTS-HashSig-2013 -- [I-D.ietf-lamps-rfc8708bis] FROM MTS-HashSig-2013 -- [RFC9708]
{ iso(1) member-body(2) us(840) rsadsi(113549) pkcs(1) pkcs9(9) { iso(1) member-body(2) us(840) rsadsi(113549) pkcs(1) pkcs9(9)
id-smime(16) id-mod(0) id-mod-mts-hashsig-2013(64) }; id-smime(16) id-mod(0) id-mod-mts-hashsig-2013(64) };
-- --
-- Object Identifiers -- Object Identifiers
-- --
-- id-alg-hss-lms-hashsig is defined in [I-D.ietf-lamps-rfc8708bis] -- id-alg-hss-lms-hashsig is defined in [RFC9708]
id-alg-xmss-hashsig OBJECT IDENTIFIER ::= { id-alg-xmss-hashsig OBJECT IDENTIFIER ::= {
iso(1) identified-organization(3) dod(6) internet(1) security(5) iso(1) identified-organization(3) dod(6) internet(1) security(5)
mechanisms(5) pkix(7) algorithms(6) 34 } mechanisms(5) pkix(7) algorithms(6) 34 }
id-alg-xmssmt-hashsig OBJECT IDENTIFIER ::= { id-alg-xmssmt-hashsig OBJECT IDENTIFIER ::= {
iso(1) identified-organization(3) dod(6) internet(1) security(5) iso(1) identified-organization(3) dod(6) internet(1) security(5)
mechanisms(5) pkix(7) algorithms(6) 35 } mechanisms(5) pkix(7) algorithms(6) 35 }
-- --
-- Signature Algorithms and Public Keys -- Signature Algorithms and Public Keys
-- --
-- sa-HSS-LMS-HashSig is defined in [I-D.ietf-lamps-rfc8708bis] -- sa-HSS-LMS-HashSig is defined in [RFC9708]
sa-XMSS-HashSig SIGNATURE-ALGORITHM ::= { sa-XMSS-HashSig SIGNATURE-ALGORITHM ::= {
IDENTIFIER id-alg-xmss-hashsig IDENTIFIER id-alg-xmss-hashsig
PARAMS ARE absent PARAMS ARE absent
PUBLIC-KEYS { pk-XMSS-HashSig } PUBLIC-KEYS { pk-XMSS-HashSig }
SMIME-CAPS { IDENTIFIED BY id-alg-xmss-hashsig } } SMIME-CAPS { IDENTIFIED BY id-alg-xmss-hashsig } }
sa-XMSSMT-HashSig SIGNATURE-ALGORITHM ::= { sa-XMSSMT-HashSig SIGNATURE-ALGORITHM ::= {
IDENTIFIER id-alg-xmssmt-hashsig IDENTIFIER id-alg-xmssmt-hashsig
PARAMS ARE absent PARAMS ARE absent
PUBLIC-KEYS { pk-XMSSMT-HashSig } PUBLIC-KEYS { pk-XMSSMT-HashSig }
SMIME-CAPS { IDENTIFIED BY id-alg-xmssmt-hashsig } } SMIME-CAPS { IDENTIFIED BY id-alg-xmssmt-hashsig } }
-- pk-HSS-LMS-HashSig is defined in [I-D.ietf-lamps-rfc8708bis] -- pk-HSS-LMS-HashSig is defined in [RFC9708]
pk-XMSS-HashSig PUBLIC-KEY ::= { pk-XMSS-HashSig PUBLIC-KEY ::= {
IDENTIFIER id-alg-xmss-hashsig IDENTIFIER id-alg-xmss-hashsig
-- KEY no ASN.1 wrapping -- -- KEY no ASN.1 wrapping --
PARAMS ARE absent PARAMS ARE absent
CERT-KEY-USAGE CERT-KEY-USAGE
{ digitalSignature, nonRepudiation, keyCertSign, cRLSign } } { digitalSignature, nonRepudiation, keyCertSign, cRLSign } }
XMSS-HashSig-PublicKey ::= OCTET STRING XMSS-HashSig-PublicKey ::= OCTET STRING
skipping to change at page 12, line 41 skipping to change at line 528
} }
END END
10. Security Considerations 10. Security Considerations
The security requirements of [SP800208] MUST be taken into account. The security requirements of [SP800208] MUST be taken into account.
As stateful HBS private keys can only generate a limited number of As stateful HBS private keys can only generate a limited number of
signatures, a user needs to be aware of the total number of signatures, a user needs to be aware of the total number of
signatures they intend to generate in their use case, otherwise they signatures they intend to generate in their use case; otherwise, they
risk exhausting the number of OTS keys in their private key. risk exhausting the number of OTS keys in their private key.
For stateful HBS schemes, it is crucial to stress the importance of For stateful HBS schemes, it is crucial to stress the importance of
correct state management. If an attacker were able to obtain correct state management. If an attacker were able to obtain
signatures for two different messages created using the same OTS key, signatures for two different messages created using the same OTS key,
then it would become computationally feasible for that attacker to then it would become computationally feasible for that attacker to
create forgeries [BH16]. As noted in [MCGREW] and [ETSI-TR-103-692], create forgeries [BH16]. As noted in [MCGREW] and [ETSI-TR-103-692],
extreme care needs to be taken in order to avoid the risk that an OTS extreme care needs to be taken in order to avoid the risk that an OTS
key will be reused accidentally. This is a new requirement that most key will be reused accidentally. This is a new requirement that most
developers will not be familiar with and requires careful handling. developers will not be familiar with and requires careful handling.
Various strategies for a correct state management can be applied: Various strategies for a correct state management can be applied:
* Implement a record of all signatures generated by a key pair * Implement a record of all signatures generated by a key pair
associated with a stateful HBS instance, for example by logging associated with a stateful HBS instance, for example, by logging
the OTS key indexes as signatures are generated. This record may the OTS key indexes as signatures are generated. This record may
be stored outside the device which is used to generate the be stored outside the device that is used to generate the
signature. Check the record to prevent OTS key reuse before a new signature. Check the record to prevent OTS key reuse before a new
signature is released. If OTS key reuse is detected, freeze all signature is released. If OTS key reuse is detected, freeze all
new signature generation by the private key, re-audit previously new signature generation by the private key, re-audit previously
released signatures (possibly revoking the private key if released signatures (possibly revoking the private key if
previously released signatures showed OTS key reuse), and perform previously released signatures showed OTS key reuse), and perform
a post-failure audit. a post-failure audit.
* Use a stateful HBS instance only for a moderate number of * Use a stateful HBS instance only for a moderate number of
signatures such that it is always practical to keep a consistent signatures such that it is always practical to keep a consistent
record and be able to unambiguously trace back all generated record and be able to unambiguously trace back all generated
signatures. signatures.
* Apply the state reservation strategy described in Section 5 of * Apply the state reservation strategy described in Section 5 of
[MCGREW], where upcoming states are reserved in advance by the [MCGREW], where upcoming states are reserved in advance by the
signer. In this way the number of state synchronisations between signer. In this way, the number of state synchronizations between
nonvolatile and volatile memory is reduced. nonvolatile and volatile memory is reduced.
11. Backup and Restore Management 11. Backup and Restore Management
Certificate Authorities have high demands in order to ensure the Certificate authorities have high demands in order to ensure the
availability of signature generation throughout the validity period availability of signature generation throughout the validity period
of signing key pairs. of signing key pairs.
Usual backup and restore strategies when using a stateless signature Some usual backup and restore strategies when using a stateless
scheme (e.g. SLH-DSA) are to duplicate private keying material and signature scheme (e.g., SLH-DSA) are to:
to operate redundant signing devices or to store and safeguard a copy
of the private keying material such that it can be used to set up a * duplicate private keying material and operate redundant signing
new signing device in case of technical difficulties. devices.
* store and safeguard a copy of the private keying material such
that it can be used to set up a new signing device in case of
technical difficulties.
For stateful HBS schemes, such straightforward backup and restore For stateful HBS schemes, such straightforward backup and restore
strategies will lead to OTS reuse with high probability as a correct strategies will lead to OTS reuse with high probability as a correct
state management is not guaranteed. Strategies for maintaining state management is not guaranteed. Strategies for maintaining
availability and keeping a correct state are described in Section 7 availability and keeping a correct state are described in Section 7
of [SP800208] and [I-D.draft-wiggers-hbs-state]. of [SP800208] and [S-HBS].
12. IANA Considerations 12. IANA Considerations
One object identifier for the ASN.1 module in Section 9 is requested IANA has registered the following OID for the ASN.1 module (see
for the SMI Security for PKIX Module Identifiers (1.3.6.1.5.5.7.0) Section 9) in the "SMI Security for PKIX Module Identifier"
registry: (1.3.6.1.5.5.7.0) registry:
+=========+========================+====================+ +=========+========================+============+
| Decimal | Description | References | | Decimal | Description | References |
+=========+========================+====================+ +=========+========================+============+
| TBD | id-mod-pkix1-shbs-2024 | [EDNOTE: THIS RFC] | | 114 | id-mod-pkix1-shbs-2024 | RFC 9802 |
+---------+------------------------+--------------------+ +---------+------------------------+------------+
Table 1 Table 1
IANA has updated the "SMI Security for PKIX Algorithms" IANA has registered the following entries in the "SMI Security for
(1.3.6.1.5.5.7.6) registry [SMI-PKIX] with two additional entries: PKIX Algorithms" (1.3.6.1.5.5.7.6) registry [SMI-PKIX]:
+=========+=======================+====================+ +=========+=======================+============+
| Decimal | Description | References | | Decimal | Description | References |
+=========+=======================+====================+ +=========+=======================+============+
| 34 | id-alg-xmss-hashsig | [EDNOTE: THIS RFC] | | 34 | id-alg-xmss-hashsig | RFC 9802 |
+---------+-----------------------+--------------------+ +---------+-----------------------+------------+
| 35 | id-alg-xmssmt-hashsig | [EDNOTE: THIS RFC] | | 35 | id-alg-xmssmt-hashsig | RFC 9802 |
+---------+-----------------------+--------------------+ +---------+-----------------------+------------+
Table 2 Table 2
13. References 13. References
13.1. Normative References 13.1. Normative References
[I-D.ietf-lamps-rfc8708bis]
Housley, R., "Use of the HSS/LMS Hash-Based Signature
Algorithm in the Cryptographic Message Syntax (CMS)", Work
in Progress, Internet-Draft, draft-ietf-lamps-rfc8708bis-
03, 19 September 2024,
<https://datatracker.ietf.org/doc/html/draft-ietf-lamps-
rfc8708bis-03>.
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
Requirement Levels", BCP 14, RFC 2119, Requirement Levels", BCP 14, RFC 2119,
DOI 10.17487/RFC2119, March 1997, DOI 10.17487/RFC2119, March 1997,
<https://www.rfc-editor.org/rfc/rfc2119>. <https://www.rfc-editor.org/info/rfc2119>.
[RFC5280] Cooper, D., Santesson, S., Farrell, S., Boeyen, S., [RFC5280] Cooper, D., Santesson, S., Farrell, S., Boeyen, S.,
Housley, R., and W. Polk, "Internet X.509 Public Key Housley, R., and W. Polk, "Internet X.509 Public Key
Infrastructure Certificate and Certificate Revocation List Infrastructure Certificate and Certificate Revocation List
(CRL) Profile", RFC 5280, DOI 10.17487/RFC5280, May 2008, (CRL) Profile", RFC 5280, DOI 10.17487/RFC5280, May 2008,
<https://www.rfc-editor.org/rfc/rfc5280>. <https://www.rfc-editor.org/info/rfc5280>.
[RFC5912] Hoffman, P. and J. Schaad, "New ASN.1 Modules for the [RFC5912] Hoffman, P. and J. Schaad, "New ASN.1 Modules for the
Public Key Infrastructure Using X.509 (PKIX)", RFC 5912, Public Key Infrastructure Using X.509 (PKIX)", RFC 5912,
DOI 10.17487/RFC5912, June 2010, DOI 10.17487/RFC5912, June 2010,
<https://www.rfc-editor.org/rfc/rfc5912>. <https://www.rfc-editor.org/info/rfc5912>.
[RFC8174] Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC [RFC8174] Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC
2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174, 2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174,
May 2017, <https://www.rfc-editor.org/rfc/rfc8174>. May 2017, <https://www.rfc-editor.org/info/rfc8174>.
[RFC8391] Huelsing, A., Butin, D., Gazdag, S., Rijneveld, J., and A. [RFC8391] Huelsing, A., Butin, D., Gazdag, S., Rijneveld, J., and A.
Mohaisen, "XMSS: eXtended Merkle Signature Scheme", Mohaisen, "XMSS: eXtended Merkle Signature Scheme",
RFC 8391, DOI 10.17487/RFC8391, May 2018, RFC 8391, DOI 10.17487/RFC8391, May 2018,
<https://www.rfc-editor.org/rfc/rfc8391>. <https://www.rfc-editor.org/info/rfc8391>.
[RFC8554] McGrew, D., Curcio, M., and S. Fluhrer, "Leighton-Micali [RFC8554] McGrew, D., Curcio, M., and S. Fluhrer, "Leighton-Micali
Hash-Based Signatures", RFC 8554, DOI 10.17487/RFC8554, Hash-Based Signatures", RFC 8554, DOI 10.17487/RFC8554,
April 2019, <https://www.rfc-editor.org/rfc/rfc8554>. April 2019, <https://www.rfc-editor.org/info/rfc8554>.
[SP800208] National Institute of Standards and Technology (NIST), [RFC9708] Housley, R., "Use of the HSS/LMS Hash-Based Signature
"Recommendation for Stateful Hash-Based Signature Algorithm in the Cryptographic Message Syntax (CMS)",
Schemes", 29 October 2020, RFC 9708, DOI 10.17487/RFC9708, January 2025,
<https://www.rfc-editor.org/info/rfc9708>.
[SP800208] Cooper, D., Apon, D., Dang, Q., Davidson, M., Dworkin, M.,
and C. Miller, "Recommendation for Stateful Hash-Based
Signature Schemes", NIST SP 800-208,
DOI 10.6028/nist.sp.800-208, 29 October 2020,
<https://doi.org/10.6028/NIST.SP.800-208>. <https://doi.org/10.6028/NIST.SP.800-208>.
[X680] ITU-T, "Information technology - Abstract Syntax Notation [X680] ITU-T, "Information technology - Abstract Syntax Notation
One (ASN.1): Specification of basic notation", ITU-T One (ASN.1): Specification of basic notation", ITU-T
Recommendation X.680, ISO/IEC 8824-1:2021, February 2021, Recommendation X.680, ISO/IEC 8824-1:2021, February 2021,
<https://www.itu.int/rec/T-REC-X.680>. <https://www.itu.int/rec/T-REC-X.680>.
[X690] ITU-T, "Information technology - Abstract Syntax Notation [X690] ITU-T, "Information technology: ASN.1 encoding rules:
One (ASN.1): ASN.1 encoding rules: Specification of Basic Specification of Basic Encoding Rules (BER), Canonical
Encoding Rules (BER), Canonical Encoding Rules (CER) and Encoding Rules (CER) and Distinguished Encoding Rules
Distinguished Encoding Rules (DER)", ITU-T (DER)", ITU-T Recommendation X.690, ISO/IEC 8825-1:2021,
Recommendation X.690, ISO/IEC 8825-1:2021, February 2021, February 2021, <https://www.itu.int/rec/T-REC-X.690>.
<https://www.itu.int/rec/T-REC-X.690>.
13.2. Informative References 13.2. Informative References
[ANSSI] Agence nationale de la sécurité des systèmes d'information [ANSSI] Agence nationale de la sécurité des systèmes d'information
(ANSSI), "ANSSI views on the Post-Quantum Cryptography (ANSSI), "ANSSI views on the Post-Quantum Cryptography
transition (2023 follow up)", 21 December 2023, transition (2023 follow up)", 21 December 2023,
<https://cyber.gouv.fr/sites/default/files/document/follow <https://cyber.gouv.fr/sites/default/files/document/follow
_up_position_paper_on_post_quantum_cryptography.pdf>. _up_position_paper_on_post_quantum_cryptography.pdf>.
[BH16] Bruinderink, L. and S. Hülsing, "Oops, I did it again – [BH16] Bruinderink, L. and S. Hülsing, "Oops, I did it again –
Security of One-Time Signatures under Two-Message Security of One-Time Signatures under Two-Message
Attacks.", 2016, <https://eprint.iacr.org/2016/1042.pdf>. Attacks.", Cryptology ePrint Archive, Paper 2016/1042,
2016, <https://eprint.iacr.org/2016/1042>.
[BSI] Bundesamt für Sicherheit in der Informationstechnik (BSI), [BSI] Bundesamt für Sicherheit in der Informationstechnik (BSI),
"Quantum-safe cryptography – fundamentals, current "Quantum-safe cryptography – fundamentals, current
developments and recommendations", 18 May 2022, developments and recommendations", 18 May 2022,
<https://www.bsi.bund.de/SharedDocs/Downloads/EN/BSI/ <https://www.bsi.bund.de/SharedDocs/Downloads/EN/BSI/
Publications/Brochure/quantum-safe-cryptography.pdf>. Publications/Brochure/quantum-safe-cryptography.pdf>.
[CNSA2.0] National Security Agency (NSA), "Commercial National [CNSA2.0] National Security Agency (NSA), "The Commercial National
Security Algorithm Suite 2.0 (CNSA 2.0) Cybersecurity Security Algorithm Suite 2.0 and Quantum Computing FAQ", 7
Advisory (CSA)", 7 September 2022, September 2022, <https://media.defense.gov/2022/
<https://media.defense.gov/2022/Sep/07/2003071834/-1/-1/0/ Sep/07/2003071836/-1/-1/0/CSI_CNSA_2.0_FAQ_.PDF>.
CSA_CNSA_2.0_ALGORITHMS_.PDF>.
[ETSI-TR-103-692] [ETSI-TR-103-692]
European Telecommunications Standards Institute (ETSI), European Telecommunications Standards Institute (ETSI),
"State management for stateful authentication mechanisms", "CYBER; State management for stateful authentication
November 2021, <https://www.etsi.org/deliver/ mechanisms", ETSI TR 103 692 v1.1.1, November 2021,
<https://www.etsi.org/deliver/
etsi_tr/103600_103699/103692/01.01.01_60/ etsi_tr/103600_103699/103692/01.01.01_60/
tr_103692v010101p.pdf>. tr_103692v010101p.pdf>.
[I-D.draft-wiggers-hbs-state] [IANA-LMS] IANA, "Leighton-Micali Signatures (LMS)",
Wiggers, T., Bashiri, K., Kölbl, S., Goodman, J., and S.
Kousidis, "Hash-based Signatures: State and Backup
Management", Work in Progress, Internet-Draft, draft-
wiggers-hbs-state-01, 24 September 2024,
<https://datatracker.ietf.org/doc/html/draft-wiggers-hbs-
state-01>.
[IANA-LMS] IANA, "Leighton-Micali Signatures (LMS)", n.d.,
<https://www.iana.org/assignments/leighton-micali- <https://www.iana.org/assignments/leighton-micali-
signatures/>. signatures/>.
[IANA-XMSS] [IANA-XMSS]
IANA, "XMSS: Extended Hash-Based Signatures", n.d., IANA, "XMSS: Extended Hash-Based Signatures",
<https://iana.org/assignments/xmss-extended-hash-based- <https://iana.org/assignments/xmss-extended-hash-based-
signatures/>. signatures/>.
[MCGREW] McGrew, D., Kampanakis, P., Fluhrer, S., Gazdag, S., [MCGREW] McGrew, D., Kampanakis, P., Fluhrer, S., Gazdag, S.,
Butin, D., and J. Buchmann, "State Management for Hash- Butin, D., and J. Buchmann, "State Management for Hash-
Based Signatures", 2 November 2016, Based Signatures", Cryptology ePrint Archive, Paper
2016/357, 2 November 2016,
<https://eprint.iacr.org/2016/357>. <https://eprint.iacr.org/2016/357>.
[RFC3279] Bassham, L., Polk, W., and R. Housley, "Algorithms and [RFC3279] Bassham, L., Polk, W., and R. Housley, "Algorithms and
Identifiers for the Internet X.509 Public Key Identifiers for the Internet X.509 Public Key
Infrastructure Certificate and Certificate Revocation List Infrastructure Certificate and Certificate Revocation List
(CRL) Profile", RFC 3279, DOI 10.17487/RFC3279, April (CRL) Profile", RFC 3279, DOI 10.17487/RFC3279, April
2002, <https://www.rfc-editor.org/rfc/rfc3279>. 2002, <https://www.rfc-editor.org/info/rfc3279>.
[RFC3647] Chokhani, S., Ford, W., Sabett, R., Merrill, C., and S. [RFC3647] Chokhani, S., Ford, W., Sabett, R., Merrill, C., and S.
Wu, "Internet X.509 Public Key Infrastructure Certificate Wu, "Internet X.509 Public Key Infrastructure Certificate
Policy and Certification Practices Framework", RFC 3647, Policy and Certification Practices Framework", RFC 3647,
DOI 10.17487/RFC3647, November 2003, DOI 10.17487/RFC3647, November 2003,
<https://www.rfc-editor.org/rfc/rfc3647>. <https://www.rfc-editor.org/info/rfc3647>.
[RFC4949] Shirey, R., "Internet Security Glossary, Version 2", [RFC4949] Shirey, R., "Internet Security Glossary, Version 2",
FYI 36, RFC 4949, DOI 10.17487/RFC4949, August 2007, FYI 36, RFC 4949, DOI 10.17487/RFC4949, August 2007,
<https://www.rfc-editor.org/rfc/rfc4949>. <https://www.rfc-editor.org/info/rfc4949>.
[RFC8410] Josefsson, S. and J. Schaad, "Algorithm Identifiers for [RFC8410] Josefsson, S. and J. Schaad, "Algorithm Identifiers for
Ed25519, Ed448, X25519, and X448 for Use in the Internet Ed25519, Ed448, X25519, and X448 for Use in the Internet
X.509 Public Key Infrastructure", RFC 8410, X.509 Public Key Infrastructure", RFC 8410,
DOI 10.17487/RFC8410, August 2018, DOI 10.17487/RFC8410, August 2018,
<https://www.rfc-editor.org/rfc/rfc8410>. <https://www.rfc-editor.org/info/rfc8410>.
[RFC8411] Schaad, J. and R. Andrews, "IANA Registration for the [RFC8411] Schaad, J. and R. Andrews, "IANA Registration for the
Cryptographic Algorithm Object Identifier Range", Cryptographic Algorithm Object Identifier Range",
RFC 8411, DOI 10.17487/RFC8411, August 2018, RFC 8411, DOI 10.17487/RFC8411, August 2018,
<https://www.rfc-editor.org/rfc/rfc8411>. <https://www.rfc-editor.org/info/rfc8411>.
[SMI-PKIX] IANA, "SMI Security for PKIX Algorithms", n.d., [S-HBS] Wiggers, T., Bashiri, K., Kölbl, S., Goodman, J., and S.
<https://www.iana.org/assignments/smi-numbers/smi- Kousidis, "Hash-based Signatures: State and Backup
numbers.xhtml#smi-numbers-1.3.6.1.5.5.7.6>. Management", Work in Progress, Internet-Draft, draft-
wiggers-hbs-state-02, 1 April 2025,
<https://datatracker.ietf.org/doc/html/draft-wiggers-hbs-
state-02>.
[SMI-PKIX] IANA, "SMI Security for PKIX Algorithms",
<https://www.iana.org/assignments/smi-numbers>.
Appendix A. HSS X.509 v3 Certificate Example Appendix A. HSS X.509 v3 Certificate Example
This section shows a self-signed X.509 v3 certificate using HSS. This section shows a self-signed X.509 v3 certificate using HSS.
Certificate: Certificate:
Data: Data:
Version: 3 (0x2) Version: 3 (0x2)
Serial Number: Serial Number:
e8:91:d6:06:91:4f:ce:f3 e8:91:d6:06:91:4f:ce:f3
skipping to change at page 35, line 7 skipping to change at line 1573
Pa6OUVQ3Za0KySigPwTtVFnEnx09cJdf+URT/xWfAxN7QWvA94+jJysDOTePvZFl Pa6OUVQ3Za0KySigPwTtVFnEnx09cJdf+URT/xWfAxN7QWvA94+jJysDOTePvZFl
TXSpn0VqpCXcTPl+WfxOk3yJj3GOpplmXmolpMCm+iX3aFyKAvV7Sc2J4Xd4lRup TXSpn0VqpCXcTPl+WfxOk3yJj3GOpplmXmolpMCm+iX3aFyKAvV7Sc2J4Xd4lRup
IXhu9HriBOUOIVK/BM0MaV3X8ldxn9gB4PMQzBUt/Zl4/9wfj6kxDQ+f9CyhPU+y IXhu9HriBOUOIVK/BM0MaV3X8ldxn9gB4PMQzBUt/Zl4/9wfj6kxDQ+f9CyhPU+y
UZJo8OzYX8RVoUzIEukFfgWTX/l2mYUYKSRgFF2zeflLfOQicYrCZkXSQRRdWUwK UZJo8OzYX8RVoUzIEukFfgWTX/l2mYUYKSRgFF2zeflLfOQicYrCZkXSQRRdWUwK
tSurvcZQ+Ic3QubUlnLPRfDUvw3FF5/xuRJcqHSJnlYHz4+YmtrX23/H0DoKFM1a tSurvcZQ+Ic3QubUlnLPRfDUvw3FF5/xuRJcqHSJnlYHz4+YmtrX23/H0DoKFM1a
ZgzrAnag1Fbm6L6h8Mcjs0+GkBpaFo4HDSTR7gOYnw== ZgzrAnag1Fbm6L6h8Mcjs0+GkBpaFo4HDSTR7gOYnw==
-----END CERTIFICATE----- -----END CERTIFICATE-----
Acknowledgments Acknowledgments
Thanks for Russ Housley, Panos Kampanakis, Michael StJohns and Corey Thanks to Russ Housley, Panos Kampanakis, Michael StJohns, and Corey
Bonnell for helpful suggestions and reviews. Bonnell for their helpful suggestions and reviews.
This document uses a lot of text from similar documents [SP800208], This document uses a lot of text from similar documents, including:
([RFC3279] and [RFC8410]) as well as [I-D.ietf-lamps-rfc8708bis]. [SP800208], [RFC3279] and [RFC8410], as well as [RFC9708]. Thanks
Thanks go to the authors of those documents. "Copying always makes goes to the authors of those documents. "Copying always makes things
things easier and less error prone" - [RFC8411]. easier and less error prone" [RFC8411].
Authors' Addresses Authors' Addresses
Daniel Van Geest Daniel Van Geest
CryptoNext Security CryptoNext Security
Email: daniel.vangeest@cryptonext-security.com Email: daniel.vangeest@cryptonext-security.com
Kaveh Bashiri Kaveh Bashiri
BSI BSI
Email: kaveh.bashiri.ietf@gmail.com Email: kaveh.bashiri.ietf@gmail.com
 End of changes. 88 change blocks. 
236 lines changed or deleted 217 lines changed or added

This html diff was produced by rfcdiff 1.48.