RFC 9909: Internet X.509 Public Key Infrastructure -- Algorithm Identifiers for the Stateless Hash-Based Digital Signature Algorithm (SLH-DSA)
- K. Bashiri,
- S. Fluhrer,
- S. Gazdag,
- D. Van Geest,
- S. Kousidis
Abstract
Digital signatures are used within the X.509 Public Key Infrastructure, such as X.509 certificates and Certificate Revocation Lists (CRLs), as well as to sign messages. This document specifies the conventions for using the Stateless Hash-Based Digital Signature Algorithm (SLH-DSA) in the X.509 Public Key Infrastructure. The conventions for the associated signatures, subject public keys, and private keys are also specified.¶
Status of This Memo
This is an Internet Standards Track document.¶
This document is a product of the Internet Engineering Task Force (IETF). It represents the consensus of the IETF community. It has received public review and has been approved for publication by the Internet Engineering Steering Group (IESG). Further information on Internet Standards is available in Section 2 of RFC 7841.¶
Information about the current status of this document, any
errata, and how to provide feedback on it may be obtained at
https://
Copyright Notice
Copyright (c) 2025 IETF Trust and the persons identified as the document authors. All rights reserved.¶
This document is subject to BCP 78 and the IETF Trust's Legal
Provisions Relating to IETF Documents
(https://
1. Introduction
The Stateless Hash-Based Digital Signature Algorithm (SLH-DSA) is a quantum
SLH-DSA offers three security levels. The parameters for each of the security levels were chosen to be at least as secure as a generic block cipher of 128, 192, or 256 bits. There are small (s) and fast (f) versions of the algorithm, and there is also the option to use the SHA-2 algorithm family [FIPS180] or SHAKE256 [FIPS202] as internal functions. While the fast versions are optimized for key generation and signing speed, they are actually slower at verification than the SLH-DSA small parameter sets. The small versions are optimized for signature size; see Table 1. As an example, id
NIST [CSOR] has assigned separate algorithm identifiers for SLH-DSA for each combination of these security levels: fast vs. small, SHA-2 vs. SHAKE256, and pure mode vs. pre-hash mode.¶
SLH-DSA signature operations include an optional context string (ctx) as input, defined in Section 10.2 of [FIPS205]. The context string has a maximum length of 255 bytes. By default, the context string is the empty string. This document only specifies the use of the empty context string for use in the X.509 Public Key Infrastructure.¶
SLH-DSA offers two signature modes: pure mode, where the entire content is signed directly, and pre-hash mode, where a digest of the content is signed. This document uses the term SLH-DSA to refer to the algorithm in general. When a pure or pre-hash mode needs to be differentiated, the terms Pure SLH-DSA and HashSLH-DSA are used. This document specifies the use of both Pure SLH-DSA and HashSLH-DSA in Public Key Infrastructure X.509 (PKIX) certificates and Certificate Revocation Lists (CRLs).¶
2. Conventions
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in BCP 14 [RFC2119] [RFC8174] when, and only when, they appear in all capitals, as shown here.¶
3. Algorithm Identifiers
The Algorithm
The fields in Algorithm
The object identifiers for SLH-DSA are defined in the NIST Computer Security Objects Register [CSOR] and are reproduced here for convenience. The same algorithm identifiers are used for identifying a public key, a private key, and a signature.¶
The Pure SLH-DSA OIDs are defined in the ASN.1 module in [RFC9814] and reproduced here for convenience:¶
The HashSLH-DSA OIDs are:¶
The contents of the parameters component for each algorithm MUST be absent.¶
4. SLH-DSA Signatures
SLH-DSA is a digital signature scheme built upon hash functions. The security of SLH-DSA relies on the security properties of the underlying hash functions, such as the presumed difficulty of finding preimages.¶
Signatures can be placed in a number of different ASN.1 structures. The top-level structure for a certificate is given below as being illustrative of how signatures are frequently encoded with an algorithm identifier and a location for the signature.¶
The algorithm identifiers used for signatures are the same as those used for public keys. When used to identify signature algorithms, the parameters MUST be absent.¶
The data to be signed is prepared for SLH-DSA. Then, a private key operation is performed to generate the raw signature value.¶
When signing data using the Pure SLH-DSA signature algorithm, Algorithm 22 (slh_sign) from
Section 10.2.1 of [FIPS205] is used. When verifying Pure SLH-DSA signed data,
Algorithm 24 (slh_verify) from Section 10.3 of [FIPS205] is used.
When signing data using the HashSLH-DSA signature algorithm, Algorithm 23 (hash_slh_sign) from
Section 10.2.2 of [FIPS205] is used. When verifying HashSLH-DSA signed data,
Algorithm 25
In the case of HashSLH-DSA, there is a pre-hash component of M' referred to as PH_M. PH_M may be computed
in the signing
Section 9.2 of [FIPS205] defines an SLH-DSA signature as three elements: R, SIG_FORS, and SIG_HT. The raw octet string encoding of an SLH-DSA signature is the concatenation of these three elements, i.e., R || SIG_FORS || SIG_HT. The raw octet string representing the signature is encoded directly in the BIT STRING without adding any additional ASN.1 wrapping. For example, in the Certificate structure, the raw signature value is encoded in the "signature" BIT STRING field.¶
5. Subject Public Key Fields
In the X.509 certificate, the subject
The fields in Subject
[RFC9814] defines the following public key identifiers for Pure SLH-DSA:¶
The public key identifiers for HashSLH-DSA are defined here:¶
Section 9.1 of [FIPS205] defines an SLH-DSA public key as two n-byte elements:
PK.seed and PK.root. The raw octet string encoding of an SLH-DSA
public key is the concatenation of these two elements, i.e., PK.seed || PK.root. The octet
string length is 2*n bytes, where n is 16, 24, or 32, depending on the SLH-DSA parameter
set. When used in a Subject
[RFC9814] defines the SLH
The Algorithm
Appendix C.1 contains an example of an id
6. Key Usage Bits
The intended application for the key is indicated in the keyUsage certificate extension; see Section 4.2.1.3 of [RFC5280]. If the keyUsage extension is present in a certificate that indicates an id-slh-dsa-* (Pure SLH-DSA) or id
If the keyUsage extension is present in a certificate that indicates an id-slh-dsa-* (Pure SLH-DSA) or id
Requirements about the keyUsage extension bits defined in [RFC5280] still apply.¶
7. Private Key Format
"Asymmetric Key Packages" [RFC5958] describes how to encode a private
key in a structure that both identifies what algorithm the private
key is for and optionally allows for the public key and additional attributes
about the key to be included as well. For illustration, the ASN.1
structure One
Section 9.1 of [FIPS205] defines an SLH-DSA private key as four n-byte
elements: SK.seed, SK.prf, PK.seed, and PK.root. The raw octet string
encoding of an SLH-DSA private key is the concatenation of these four
elements, i.e., SK.seed || SK.prf || PK.seed || PK.root. The octet string
length is 4*n bytes, where n is 16, 24, or 32, depending on the SLH-DSA parameter
set. When used in a One
When an SLH-DSA public key is included in a One
Appendix C.2 contains an example of an id
8. Operational Considerations
SLH-DSA uses the same OID to identify a public key and a signature algorithm. The implication of this is that, despite being mathematically possible, an SLH-DSA key identified by a Pure SLH-DSA OID is not permitted to be used to generate or verify a signature identified by a HashSLH-DSA OID, and vice versa.¶
Certification authority (CA) operators will need to decide in advance whether their CA certificates will use Pure SLH-DSA or HashSLH-DSA and assign the appropriate OID to the public and private keys when generating their certificate. Some of the following considerations may affect this decision.¶
An SLH-DSA private key has a very large (264) number of signatures it can safely generate (see Section 9). If an operator might conceivably generate a number of signatures approaching this limit, they should mitigate potential harm by tracking the number of signatures generated and destroying the private key once an appropriate limit is reached or by setting the "Not After" (expiration) date of the certificate such that the limit couldn't possibly be surpassed given the rate of signing.¶
9. Security Considerations
The security considerations of [RFC5280] apply accordingly. Moreover, the security aspects mentioned throughout [FIPS205] should be taken into account; for instance, see Sections 3.1 and 3.2 or the beginning of Section 11.¶
The security of SLH-DSA relies on the security properties of the internal hash and XOF functions. In particular, it relies on these functions being preimage resistant, but it does not rely on them being collision resistant. Since HashSLH-DSA performs a pre-hash before signing, it relies on both preimage resistance and collision resistance of the pre-hash function. In order to achieve an appropriate level of collision resistance, the output length of the pre-hash functions used for HashSLH-DSA is twice the length of the internal hash and XOF functions.¶
Implementations MUST protect the private keys. Compromise of the private keys may result in the ability to forge signatures.¶
When generating an SLH-DSA key pair, an implementation MUST generate each key pair independently of all other key pairs in the SLH-DSA hypertree.¶
An SLH-DSA tree MUST NOT be used for more than 264 signing operations.¶
The generation of private keys relies on random numbers. The use of inadequate pseudorandom number generators (PRNGs) to generate these values can result in little or no security. An attacker may find it much easier to reproduce the PRNG environment that produced the keys, searching the resulting small set of possibilities, rather than brute force searching the whole key space. The generation of quality random numbers is difficult; see Section 3.1 of [FIPS205] for some additional information.¶
Fault attacks can lead to forgeries of message signatures; see [CMP2018] and [Ge2023]. Verifying a signature before releasing the signature value is a typical fault attack countermeasure; however, this countermeasure is not effective for SLH-DSA [Ge2023]. Redundancy by replicating the signature generation process can be used as an effective fault attack countermeasure for SLH-DSA [Ge2023]; however, the SLH-DSA signature generation is already considered slow.¶
Likewise, passive power and emissions side-channel attacks can leak the SLH-DSA private signing key, and countermeasures can be taken against these attacks [SLotH].¶
10. IANA Considerations
For the ASN.1 module in Appendix A of this document, IANA has assigned an object identifier (OID) for the module
identifier (120) with a Description of "id
11. References
11.1. Normative References
- [CSOR]
-
NIST, "Computer Security Objects Register (CSOR)", , <https://
csrc >..nist .gov /projects /computer -security -objects -register /algorithm -registration - [FIPS205]
-
NIST, "Stateless Hash-Based Digital Signature Standard", NIST FIPS 205, DOI 10
.6028 , , <https:///NIST .FIPS .205 nvlpubs >..nist .gov /nistpubs /FIPS /NIST .FIPS .205 .pdf - [RFC2119]
-
Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, DOI 10
.17487 , , <https:///RFC2119 www >..rfc -editor .org /info /rfc2119 - [RFC5280]
-
Cooper, D., Santesson, S., Farrell, S., Boeyen, S., Housley, R., and W. Polk, "Internet X.509 Public Key Infrastructure Certificate and Certificate Revocation List (CRL) Profile", RFC 5280, DOI 10
.17487 , , <https:///RFC5280 www >..rfc -editor .org /info /rfc5280 - [RFC5912]
-
Hoffman, P. and J. Schaad, "New ASN.1 Modules for the Public Key Infrastructure Using X.509 (PKIX)", RFC 5912, DOI 10
.17487 , , <https:///RFC5912 www >..rfc -editor .org /info /rfc5912 - [RFC5958]
-
Turner, S., "Asymmetric Key Packages", RFC 5958, DOI 10
.17487 , , <https:///RFC5958 www >..rfc -editor .org /info /rfc5958 - [RFC8174]
-
Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC 2119 Key Words", BCP 14, RFC 8174, DOI 10
.17487 , , <https:///RFC8174 www >..rfc -editor .org /info /rfc8174 - [RFC9814]
-
Housley, R., Fluhrer, S., Kampanakis, P., and B. Westerbaan, "Use of the SLH-DSA Signature Algorithm in the Cryptographic Message Syntax (CMS)", RFC 9814, DOI 10
.17487 , , <https:///RFC9814 www >..rfc -editor .org /info /rfc9814 - [X680]
-
ITU-T, "Information technology - Abstract Syntax Notation One (ASN.1): Specification of basic notation", ITU-T Recommendation X.680, ISO/IEC 8824-1:2021, , <https://
www >..itu .int /rec /T -REC -X .680 - [X690]
-
ITU-T, "Information technology - ASN.1 encoding rules: Specification of Basic Encoding Rules (BER), Canonical Encoding Rules (CER) and Distinguished Encoding Rules (DER)", ITU-T Recommendation X.690, ISO/IEC 8825-1:2021, , <https://
www >..itu .int /rec /T -REC -X .690
11.2. Informative References
- [CMP2018]
-
Castelnovi, L., Martinelli, A., and T. Prest, "Grafting Trees: A Fault Attack Against the SPHINCS Framework", Post-Quantum Cryptography (PQCrpyto 2018), Lecture Notes in Computer Science, vol. 10786, pp. 165-184, , <https://
link >..springer .com /chapter /10 .1007 /978 -3 -319 -79063 -3 _8 - [FIPS180]
-
NIST, "Secure Hash Standard (SHS)", NIST FIPS 180-4, DOI 10
.6028 , , <https:///NIST .FIPS .180 -4 nvlpubs >..nist .gov /nistpubs /FIPS /NIST .FIPS .180 -4 .pdf - [FIPS202]
-
NIST, "SHA-3 Standard: Permutation
-Based Hash and Extendable , NIST FIPS 202, DOI 10-Output Functions" .6028 , , <http:///NIST .FIPS .202 nvlpubs >..nist .gov /nistpubs /FIPS /NIST .FIPS .202 .pdf - [Ge2023]
-
Genêt, A., "On Protecting SPHINCS+ Against Fault Attacks", TCHES, vol. 2023, no. 2, pp. 80-114, DOI 10
.46586 , , <https:///tches .v2023 .i2 .80 -114 doi >..org /10 .46586 /tches .v2023 .i2 .80 -114 - [NIST-PQC]
-
NIST, "Post-Quantum Cryptography (PQC)", , <https://
csrc >..nist .gov /projects /post -quantum -cryptography - [RFC7468]
-
Josefsson, S. and S. Leonard, "Textual Encodings of PKIX, PKCS, and CMS Structures", RFC 7468, DOI 10
.17487 , , <https:///RFC7468 www >..rfc -editor .org /info /rfc7468 - [RFC8410]
-
Josefsson, S. and J. Schaad, "Algorithm Identifiers for Ed25519, Ed448, X25519, and X448 for Use in the Internet X.509 Public Key Infrastructure", RFC 8410, DOI 10
.17487 , , <https:///RFC8410 www >..rfc -editor .org /info /rfc8410 - [RFC8411]
-
Schaad, J. and R. Andrews, "IANA Registration for the Cryptographic Algorithm Object Identifier Range", RFC 8411, DOI 10
.17487 , , <https:///RFC8411 www >..rfc -editor .org /info /rfc8411 - [RFC9881]
-
Massimo, J., Kampanakis, P., Turner, S., and B. E. Westerbaan, "Internet X.509 Public Key Infrastructure -- Algorithm Identifiers for the Module
-Lattice , RFC 9881, DOI 10-Based Digital Signature Algorithm (ML-DSA)" .17487 , , <https:///RFC9881 www >..rfc -editor .org /info /rfc9881 - [SLotH]
-
Saarinen, M-J., "Accelerating SLH-DSA by Two Orders of Magnitude with a Single Hash Unit", Cryptology ePrint Archive, Paper 2024/367, DOI 10
.1007 , , <https:///978 -3 -031 -68376 -3 _9 eprint >..iacr .org /2024 /367 .pdf
Appendix A. ASN.1 Module
This appendix includes the ASN.1 module [X680] for SLH-DSA. Note that as per [RFC5280], certificates use the Distinguished Encoding Rules; see [X690]. This module imports objects from [RFC5912] and [RFC9814].¶
Appendix B. Security Strengths
Instead of defining the strength of a quantum algorithm using the number of bits of security, NIST defined a collection of broad security strength categories. Each category is defined by a comparatively easy-to-analyze reference primitive that covers a range of security strengths offered by existing NIST standards in symmetric cryptography, which NIST expects to offer significant resistance to quantum cryptanalysis. These categories describe any attack that breaks the relevant security definition that must require computational resources comparable to or greater than those required for:¶
The SLH-DSA parameter sets defined for NIST security levels 1, 3, and 5 are listed in Table 1, along with the resulting signature, public key, and private key sizes in bytes. The HashSLH-DSA parameter sets have the same values as the Pure SLH-DSA equivalents.¶
Appendix C. Examples
This appendix contains examples of SLH-DSA public keys, private keys, and certificates.¶
C.1. Example Public Key
An example of an SLH-DSA public key using id
C.2. Example Private Key
An example of an SLH-DSA private key without the public key using id
C.3. Example Certificate
An example of a self-signed SLH-DSA certificate using id
Acknowledgments
Much of the structure and text of this document is based on [RFC8410] and [RFC9881]. The remainder comes from [RFC9814]. Thanks to the authors of those documents, and the ones they based their work on, for making our work easier. "Copying always makes things easier and less error prone" [RFC8411]. Thanks to Sean Turner for helpful text and to Markku-Juhani O. Saarinen for side-channel clarifications.¶