rfc9802v1.txt   rfc9802.txt 
skipping to change at line 24 skipping to change at line 24
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
Abstract Abstract
This document specifies algorithm identifiers and ASN.1 encoding This document specifies algorithm identifiers and ASN.1 encoding
formats for the following stateful Hash-Based Signature (HBS) formats for the following stateful Hash-Based Signature (HBS)
schemes: Hierarchical Signature System (HSS), eXtended Merkle schemes: Hierarchical Signature System (HSS), eXtended Merkle
Signature Scheme (XMSS), and XMSS^MT (a multi-tree variant of XMSS). Signature Scheme (XMSS), and XMSS^MT (a multi-tree variant of XMSS).
This specification applies to the Internet X.509 Public Key This specification applies to the Internet X.509 Public Key
infrastructure (PKI) when those digital signatures are used in Infrastructure (PKI) when digital signatures are used to sign
Internet X.509 certificates and certificate revocation lists. certificates and certificate revocation lists (CRLs).
Status of This Memo Status of This Memo
This is an Internet Standards Track document. This is an Internet Standards Track document.
This document is a product of the Internet Engineering Task Force This document is a product of the Internet Engineering Task Force
(IETF). It represents the consensus of the IETF community. It has (IETF). It represents the consensus of the IETF community. It has
received public review and has been approved for publication by the received public review and has been approved for publication by the
Internet Engineering Steering Group (IESG). Further information on Internet Engineering Steering Group (IESG). Further information on
Internet Standards is available in Section 2 of RFC 7841. Internet Standards is available in Section 2 of RFC 7841.
skipping to change at line 132 skipping to change at line 132
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 in 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; 2) the implementation will have a long lifetime; and | the following characteristics: 1) it is necessary to implement a
| 3) it would not be practical to transition to a different digital | digital signature scheme in the near future; 2) the implementation
| signature scheme once the implementation has been deployed. | will have a long lifetime; and 3) it would not be practical to
| 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 (see Section 1.1 of [SP800208], Table IV of * Firmware signing (see Section 1.1 of [SP800208], [CNSA2.0], and
[CNSA2.0], and Section 6.7 of [BSI]) Section 6.7 of [BSI])
* Software signing (see Table IV of [CNSA2.0] and [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 (see 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
skipping to change at line 201 skipping to change at line 203
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: this identifies the cryptographic algorithm with an algorithm: this identifies the cryptographic algorithm with an OID.
object identifier.
parameters: these are optional and 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 [RFC9708]. The definitions are repeated here for [RFC9708]. The definitions are repeated here for reference.
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, and additional identifiers can be registered in the these values, and additional identifiers can be registered in the
“Leighton-Micali Signatures (LMS)” registry [IANA-LMS]. “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, and additional identifiers can be registered in the these values, and additional identifiers can be registered in the
“Leighton-Micali Signatures (LMS)” registry [IANA-XMSS]. “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, and additional identifiers can be registered in the these values, and additional identifiers can be registered in the
“Leighton-Micali Signatures (LMS)” registry [IANA-XMSS]. “Leighton-Micali Signatures (LMS)” registry [IANA-XMSS].
skipping to change at line 565 skipping to change at line 565
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 synchronizations 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 [S-HBS]. of [SP800208] and [S-HBS].
12. IANA Considerations 12. IANA Considerations
IANA has registered the following object identifier for the ASN.1 IANA has registered the following OID for the ASN.1 module (see
module (see Section 9) in the "SMI Security for PKIX Module Section 9) in the "SMI Security for PKIX Module Identifier"
Identifier" (1.3.6.1.5.5.7.0) registry: (1.3.6.1.5.5.7.0) registry:
+=========+========================+============+ +=========+========================+============+
| Decimal | Description | References | | Decimal | Description | References |
+=========+========================+============+ +=========+========================+============+
| 114 | id-mod-pkix1-shbs-2024 | RFC 9802 | | 114 | id-mod-pkix1-shbs-2024 | RFC 9802 |
+---------+------------------------+------------+ +---------+------------------------+------------+
Table 1 Table 1
IANA has registered the following entries in the "SMI Security for IANA has registered the following entries in the "SMI Security for
skipping to change at line 682 skipping to change at line 686
Security of One-Time Signatures under Two-Message Security of One-Time Signatures under Two-Message
Attacks.", Cryptology ePrint Archive, Paper 2016/1042, Attacks.", Cryptology ePrint Archive, Paper 2016/1042,
2016, <https://eprint.iacr.org/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),
"CYBER; State management for stateful authentication "CYBER; State management for stateful authentication
mechanisms", ETSI TR 103 692 v1.1.1, November 2021, mechanisms", ETSI TR 103 692 v1.1.1, November 2021,
<https://www.etsi.org/deliver/ <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>.
[IANA-LMS] IANA, "Leighton-Micali Signatures (LMS)", [IANA-LMS] IANA, "Leighton-Micali Signatures (LMS)",
skipping to change at line 1573 skipping to change at line 1576
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 to Russ Housley, Panos Kampanakis, Michael StJohns, and Corey Thanks to Russ Housley, Panos Kampanakis, Michael StJohns, and Corey
Bonnell for their 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 [RFC9708]. Thanks goes to the [SP800208], [RFC3279] and [RFC8410], as well as [RFC9708]. Thanks
authors of those documents. "Copying always makes things easier and goes to the authors of those documents. "Copying always makes things
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. 14 change blocks. 
35 lines changed or deleted 38 lines changed or added

This html diff was produced by rfcdiff 1.48.