rfc9909.original   rfc9909.txt 
LAMPS - Limited Additional Mechanisms for PKIX and SMIME K. Bashiri Internet Engineering Task Force (IETF) K. Bashiri
Internet-Draft BSI Request for Comments: 9909 BSI
Intended status: Standards Track S. Fluhrer Category: Standards Track S. Fluhrer
Expires: 1 January 2026 Cisco Systems ISSN: 2070-1721 Cisco Systems
S. Gazdag S. Gazdag
genua GmbH genua GmbH
D. Van Geest D. Van Geest
CryptoNext Security CryptoNext Security
S. Kousidis S. Kousidis
BSI BSI
30 June 2025 December 2025
Internet X.509 Public Key Infrastructure: Algorithm Identifiers for SLH- Internet X.509 Public Key Infrastructure: Algorithm Identifiers for
DSA SLH-DSA
draft-ietf-lamps-x509-slhdsa-09
Abstract Abstract
Digital signatures are used within X.509 Public Key Infrastructure Digital signatures are used within the X.509 Public Key
such as X.509 certificates, Certificate Revocation Lists (CRLs), and Infrastructure such as X.509 certificates, Certificate Revocation
to sign messages. This document specifies the conventions for using Lists (CRLs), and to sign messages. This document specifies the
the Stateless Hash-Based Digital Signature Algorithm (SLH-DSA) in conventions for using the Stateless Hash-Based Digital Signature
X.509 Public Key Infrastructure. The conventions for the associated Algorithm (SLH-DSA) in the X.509 Public Key Infrastructure. The
signatures, subject public keys, and private keys are also specified. conventions for the associated signatures, subject public keys, and
private keys are also specified.
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-slhdsa/.
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-slhdsa.
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 1 January 2026. 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/rfc9909.
Copyright Notice Copyright Notice
Copyright (c) 2025 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
1.1. Notation . . . . . . . . . . . . . . . . . . . . . . . . 4 1.1. Notation
2. Conventions and Definitions . . . . . . . . . . . . . . . . . 4 2. Conventions
3. Algorithm Identifiers . . . . . . . . . . . . . . . . . . . . 4 3. Algorithm Identifiers
4. SLH-DSA Signatures . . . . . . . . . . . . . . . . . . . . . 7 4. SLH-DSA Signatures
5. Subject Public Key Fields . . . . . . . . . . . . . . . . . . 8 5. Subject Public Key Fields
6. Key Usage Bits . . . . . . . . . . . . . . . . . . . . . . . 13 6. Key Usage Bits
7. Private Key Format . . . . . . . . . . . . . . . . . . . . . 14 7. Private Key Format
8. Operational Considerations . . . . . . . . . . . . . . . . . 15 8. Operational Considerations
9. Security Considerations . . . . . . . . . . . . . . . . . . . 16 9. Security Considerations
10. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 17 10. IANA Considerations
11. References . . . . . . . . . . . . . . . . . . . . . . . . . 17 11. References
11.1. Normative References . . . . . . . . . . . . . . . . . . 17 11.1. Normative References
11.2. Informative References . . . . . . . . . . . . . . . . . 18 11.2. Informative References
Appendix A. ASN.1 Module . . . . . . . . . . . . . . . . . . . . 19 Appendix A. ASN.1 Module
Appendix B. Security Strengths . . . . . . . . . . . . . . . . . 27 Appendix B. Security Strengths
Appendix C. Examples . . . . . . . . . . . . . . . . . . . . . . 28 Appendix C. Examples
C.1. Example Public Key . . . . . . . . . . . . . . . . . . . 28 C.1. Example Public Key
C.2. Example Private Key . . . . . . . . . . . . . . . . . . . 29 C.2. Example Private Key
C.3. Example Certificate . . . . . . . . . . . . . . . . . . . 29 C.3. Example Certificate
Acknowledgments
Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . . . 43 Authors' Addresses
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 43
1. Introduction 1. Introduction
The Stateless Hash-Based Digital Signature Algorithm (SLH-DSA) is a The Stateless Hash-Based Digital Signature Algorithm (SLH-DSA) is a
quantum-resistant digital signature scheme standardized in [FIPS205] quantum-resistant digital signature scheme standardized in [FIPS205]
by the US National Institute of Standards and Technology (NIST) PQC by the US National Institute of Standards and Technology (NIST) Post-
project [NIST-PQC]. Prior to standardization, the algorithm was Quantum Cryptography (PQC) project [NIST-PQC]. Prior to
known as SPHINCS+. SLH-DSA and SPHINCS+ are not compatible. This standardization, the algorithm was known as SPHINCS+. SLH-DSA and
document defines the ASN.1 Object Identifiers (OIDs) and conventions SPHINCS+ are not compatible. This document defines the ASN.1 Object
for the encoding of SLH-DSA digital signatures, public keys and Identifiers (OIDs) and conventions for the encoding of SLH-DSA
private keys in the X.509 Public Key Infrastructure. digital signatures, public keys, and private keys in the X.509 Public
Key Infrastructure.
SLH-DSA offers three security levels. The parameters for each of the 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 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 block cipher of 128, 192, or 256 bits. There are small (s) and fast
(f) versions of the algorithm, and the option to use the SHA2 (f) versions of the algorithm, and there is also the option to use
algorithm family [FIPS180] or SHAKE256 [FIPS202] as internal the SHA-2 algorithm family [FIPS180] or SHAKE256 [FIPS202] as
functions. While the fast versions are optimized for key generation internal functions. While the fast versions are optimized for key
and signing speed, they are actually slower at verification than the generation and signing speed, they are actually slower at
SLH-DSA small parameter sets. The small versions are optimized for verification than the SLH-DSA small parameter sets. The small
signature size, see Table 1. As an example, id-slh-dsa-shake-256s versions are optimized for signature size; see Table 1. As an
represents the 256-bit security level, the small version of the example, id-slh-dsa-shake-256s represents the 256-bit security level,
algorithm, and the use of SHAKE256. the small version of the algorithm, and the use of SHAKE256.
NIST [CSOR] has assigned separate algorithm identifiers for SLH-DSA NIST [CSOR] has assigned separate algorithm identifiers for SLH-DSA
for each combination of these security levels, fast vs small, SHA2 vs for each combination of these security levels: fast vs. small, SHA-2
SHAKE256, and pure mode vs pre-hash mode. vs. SHAKE256, and pure mode vs. pre-hash mode.
SLH-DSA signature operations include as input an optional context SLH-DSA signature operations include an optional context string (ctx)
string (ctx), defined in Section 10.2 of [FIPS205]. The context as input, defined in Section 10.2 of [FIPS205]. The context string
string has a maximum length of 255 bytes. By default, the context has a maximum length of 255 bytes. By default, the context string is
string is the empty string. This document only specifies the use of the empty string. This document only specifies the use of the empty
the empty context string for use in the X.509 Public Key context string for use in the X.509 Public Key Infrastructure.
Infrastructure.
SLH-DSA offers two signature modes: pure mode, where the entire 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 directly, and pre-hash mode, where a digest of the
content is signed. This document uses the term SLH-DSA to refer to 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 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. differentiated, the terms Pure SLH-DSA and HashSLH-DSA are used.
This document specifies the use of both Pure SLH-DSA and HashSLH-DSA This document specifies the use of both Pure SLH-DSA and HashSLH-DSA
in Public Key Infrastructure X.509 (PKIX) certificates and in Public Key Infrastructure X.509 (PKIX) certificates and
Certificate Revocation Lists (CRLs). Certificate Revocation Lists (CRLs).
1.1. Notation 1.1. Notation
The following notation is used in this document: The following notation is used in this document:
* a || b: concatenation of a and b a || b: Concatenation of a and b.
* id-slh-dsa-*: A shorthand to refer to all 12 OIDs used to specify id-slh-dsa-*: A shorthand to refer to all 12 OIDs used to specify
the different parameter combinations for Pure SLH-DSA. the different parameter combinations for Pure SLH-DSA.
* id-hash-slh-dsa-*: A shorthand to refer to all 12 OIDs used to id-hash-slh-dsa-*: A shorthand to refer to all 12 OIDs used to
specify the different parameter combinations for HashSLH-DSA. specify the different parameter combinations for HashSLH-DSA.
2. Conventions and Definitions 2. Conventions
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. Algorithm Identifiers 3. Algorithm Identifiers
The AlgorithmIdentifier type is defined in [RFC5912] as follows: The AlgorithmIdentifier type is defined in [RFC5912] as follows:
skipping to change at page 4, line 49 skipping to change at line 168
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 identifies the cryptographic algorithm with an object
identifier. identifier.
* parameters, which are optional, are the associated parameters for * parameters, which are optional, are the associated parameters for
the algorithm identifier in the algorithm field. the algorithm identifier in the algorithm field.
The object identifiers for SLH-DSA are defined in the NIST Computer The object identifiers for SLH-DSA are defined in the NIST Computer
Security Objects Register [CSOR], and are reproduced here for Security Objects Register [CSOR] and are reproduced here for
convenience. The same algorithm identifiers are used for identifying convenience. The same algorithm identifiers are used for identifying
a public key, a private key, and a signature. a public key, a private key, and a signature.
The Pure SLH-DSA OIDs are defined in The Pure SLH-DSA OIDs are defined in the ASN.1 module in [RFC9814]
[I-D.ietf-lamps-cms-sphincs-plus]'s ASN.1 module and reproduced here and reproduced here for convenience:
for convenience:
nistAlgorithms OBJECT IDENTIFIER ::= { joint-iso-itu-t(2) nistAlgorithms OBJECT IDENTIFIER ::= { joint-iso-itu-t(2)
country(16) us(840) organization(1) gov(101) csor(3) 4 } country(16) us(840) organization(1) gov(101) csor(3) 4 }
sigAlgs OBJECT IDENTIFIER ::= { nistAlgorithms 3 } sigAlgs OBJECT IDENTIFIER ::= { nistAlgorithms 3 }
id-slh-dsa-sha2-128s OBJECT IDENTIFIER ::= { sigAlgs 20 } id-slh-dsa-sha2-128s OBJECT IDENTIFIER ::= { sigAlgs 20 }
id-slh-dsa-sha2-128f OBJECT IDENTIFIER ::= { sigAlgs 21 } id-slh-dsa-sha2-128f OBJECT IDENTIFIER ::= { sigAlgs 21 }
skipping to change at page 7, line 13 skipping to change at line 258
absent. absent.
4. SLH-DSA Signatures 4. SLH-DSA Signatures
SLH-DSA is a digital signature scheme built upon hash functions. The SLH-DSA is a digital signature scheme built upon hash functions. The
security of SLH-DSA relies on the security properties of the security of SLH-DSA relies on the security properties of the
underlying hash functions, such as the presumed difficulty of finding underlying hash functions, such as the presumed difficulty of finding
preimages. preimages.
Signatures can be placed in a number of different ASN.1 structures. Signatures can be placed in a number of different ASN.1 structures.
The top level structure for a certificate is given below as being The top-level structure for a certificate is given below as being
illustrative of how signatures are frequently encoded with an illustrative of how signatures are frequently encoded with an
algorithm identifier and a location for the signature. algorithm identifier and a location for the signature.
Certificate ::= SIGNED{ TBSCertificate } Certificate ::= SIGNED{ TBSCertificate }
SIGNED{ToBeSigned} ::= SEQUENCE { SIGNED{ToBeSigned} ::= SEQUENCE {
toBeSigned ToBeSigned, toBeSigned ToBeSigned,
algorithmIdentifier SEQUENCE { algorithmIdentifier SEQUENCE {
algorithm SIGNATURE-ALGORITHM. algorithm SIGNATURE-ALGORITHM.
&id({SignatureAlgorithms}), &id({SignatureAlgorithms}),
parameters SIGNATURE-ALGORITHM. parameters SIGNATURE-ALGORITHM.
&Params({SignatureAlgorithms} &Params({SignatureAlgorithms}
{@algorithmIdentifier.algorithm}) {@algorithmIdentifier.algorithm})
OPTIONAL OPTIONAL
}, },
signature BIT STRING (CONTAINING SIGNATURE-ALGORITHM.&Value( signature BIT STRING (CONTAINING SIGNATURE-ALGORITHM.&Value(
{SignatureAlgorithms} {SignatureAlgorithms}
{@algorithmIdentifier.algorithm})) {@algorithmIdentifier.algorithm}))
} }
| The above syntax is from [RFC5912] and is compatible with the | NOTE: The above syntax is from [RFC5912] and is compatible with
| 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 same algorithm identifiers are used for signatures as are used The same algorithm identifiers are used for signatures as are used
for public keys. When used to identify signature algorithms, the for public keys. When used to identify signature algorithms, the
parameters MUST be absent. parameters MUST be absent.
The data to be signed is prepared for SLH-DSA. Then, a private key The data to be signed is prepared for SLH-DSA. Then, a private key
operation is performed to generate the raw signature value. operation is performed to generate the raw signature value.
When signing data using the Pure SLH-DSA signature algorithm, When signing data using the Pure SLH-DSA signature algorithm,
skipping to change at page 8, line 9 skipping to change at line 303
from Section 10.3 of [FIPS205] is used. When signing data using the from Section 10.3 of [FIPS205] is used. When signing data using the
HashSLH-DSA signature algorithm, Algorithm 23 (hash_slh_sign) from HashSLH-DSA signature algorithm, Algorithm 23 (hash_slh_sign) from
Section 10.2.2 of [FIPS205] is used. When verifying HashSLH-DSA Section 10.2.2 of [FIPS205] is used. When verifying HashSLH-DSA
signed data, Algorithm 25 (hash_slh_verify) from Section 10.3 of signed data, Algorithm 25 (hash_slh_verify) from Section 10.3 of
[FIPS205] is used. All four of these algorithms create a message, [FIPS205] is used. All four of these algorithms create a message,
M', from the message to be signed along with other data, and M' is M', from the message to be signed along with other data, and M' is
operated on by internal SLH-DSA algorithms. M' may be constructed operated on by internal SLH-DSA algorithms. M' may be constructed
outside the module that performs the internal SLH-DSA algorithms. outside the module that performs the internal SLH-DSA algorithms.
In the case of HashSLH-DSA, there is a pre-hash component (PH_M) of In the case of HashSLH-DSA, there is a pre-hash component (PH_M) of
M'. PH_M may be computed in the signing/verifying module, in which M'. PH_M may be computed in the signing/verifying module; in which
case the entire message to be signed is sent to the module. case, the entire message to be signed is sent to the module.
Alternatively, PH_M may be computed in a different module. In this Alternatively, PH_M may be computed in a different module. In this
case, either PH_M is sent to the signing/verifying module, which case, either PH_M is sent to the signing/verifying module, which
creates M', or M' is created outside the signing/verifying module and creates M', or M' is created outside the signing/verifying module and
is sent to the module. HashSLH-DSA allows this implementation is sent to the module. HashSLH-DSA allows this implementation
flexibility in order to reduce, and make consistent, the amount of flexibility in order to reduce, and make consistent, the amount of
data transferred to signing/verifying modules. The hash algorithm or data transferred to signing/verifying modules. The hash algorithm or
XOF used to generate the pre-hash when signing and verifying with extendable-output function (XOF) used to generate the pre-hash when
HashSLH-DSA is specified after the "-with-" component of the signing and verifying with HashSLH-DSA is specified after the
signature algorithm name. For example, when signing with id-hash- "-with-" component of the signature algorithm name. For example,
slh-dsa-sha2-128s-with-sha256, SHA-256 is used as the pre-hash when signing with id-hash-slh-dsa-sha2-128s-with-sha256, SHA-256 is
algorithm. When pre-hashing is performed using SHAKE128, the output used as the pre-hash algorithm. When pre-hashing is performed using
length is 256 bits. When pre-hashing is performed using SHAKE256, SHAKE128, the output length is 256 bits. When pre-hashing is
the output length is 512 bits. performed using SHAKE256, the output length is 512 bits.
Section 9.2 of [FIPS205] defines an SLH-DSA signature as three 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 elements: R, SIG_FORS, and SIG_HT. The raw octet string encoding of
an SLH-DSA signature is the concatenation of these three elements, an SLH-DSA signature is the concatenation of these three elements,
i.e. R || SIG_FORS || SIG_HT. The raw octet string representing the i.e., R || SIG_FORS || SIG_HT. The raw octet string representing the
signature is encoded directly in the BIT STRING without adding any signature is encoded directly in the BIT STRING without adding any
additional ASN.1 wrapping. For example, in the Certificate additional ASN.1 wrapping. For example, in the Certificate
structure, the raw signature value is encoded in the "signature" BIT structure, the raw signature value is encoded in the "signature" BIT
STRING field. STRING field.
5. Subject Public Key Fields 5. Subject Public Key Fields
In the X.509 certificate, the subjectPublicKeyInfo field has the In the X.509 certificate, the subjectPublicKeyInfo field has the
SubjectPublicKeyInfo type, which has the following ASN.1 syntax: SubjectPublicKeyInfo type, which has the following ASN.1 syntax:
SubjectPublicKeyInfo {PUBLIC-KEY: IOSet} ::= SEQUENCE { SubjectPublicKeyInfo {PUBLIC-KEY: IOSet} ::= SEQUENCE {
algorithm AlgorithmIdentifier {PUBLIC-KEY, {IOSet}}, algorithm AlgorithmIdentifier {PUBLIC-KEY, {IOSet}},
subjectPublicKey BIT STRING } subjectPublicKey BIT STRING }
| The above syntax is from [RFC5912] and is compatible with the | NOTE: The above syntax is from [RFC5912] and is compatible with
| 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 SubjectPublicKeyInfo have the following meanings: The fields in SubjectPublicKeyInfo have the following meanings:
* algorithm is the algorithm identifier and parameters for the * algorithm is the algorithm identifier and parameters for the
public key (see above). public key (see above).
* subjectPublicKey contains the byte stream of the public key. * subjectPublicKey contains the byte stream of the public key.
[I-D.ietf-lamps-cms-sphincs-plus] defines the following public key [RFC9814] defines the following public key identifiers for Pure SLH-
identifiers for Pure SLH-DSA: DSA:
pk-slh-dsa-sha2-128s PUBLIC-KEY ::= { pk-slh-dsa-sha2-128s PUBLIC-KEY ::= {
IDENTIFIER id-slh-dsa-sha2-128s IDENTIFIER id-slh-dsa-sha2-128s
-- KEY no ASN.1 wrapping -- -- KEY no ASN.1 wrapping --
CERT-KEY-USAGE CERT-KEY-USAGE
{ digitalSignature, nonRepudiation, keyCertSign, cRLSign } { digitalSignature, nonRepudiation, keyCertSign, cRLSign }
-- PRIVATE-KEY no ASN.1 wrapping -- } -- PRIVATE-KEY no ASN.1 wrapping -- }
pk-slh-dsa-sha2-128f PUBLIC-KEY ::= { pk-slh-dsa-sha2-128f PUBLIC-KEY ::= {
IDENTIFIER id-slh-dsa-sha2-128f IDENTIFIER id-slh-dsa-sha2-128f
skipping to change at page 12, line 41 skipping to change at line 526
-- PRIVATE-KEY no ASN.1 wrapping -- } -- PRIVATE-KEY no ASN.1 wrapping -- }
pk-hash-slh-dsa-shake-256f-with-shake256 PUBLIC-KEY ::= { pk-hash-slh-dsa-shake-256f-with-shake256 PUBLIC-KEY ::= {
IDENTIFIER id-hash-slh-dsa-shake-256f-with-shake256 IDENTIFIER id-hash-slh-dsa-shake-256f-with-shake256
-- KEY no ASN.1 wrapping -- -- KEY no ASN.1 wrapping --
CERT-KEY-USAGE CERT-KEY-USAGE
{ digitalSignature, nonRepudiation, keyCertSign, cRLSign } { digitalSignature, nonRepudiation, keyCertSign, cRLSign }
-- PRIVATE-KEY no ASN.1 wrapping -- } -- PRIVATE-KEY no ASN.1 wrapping -- }
Section 9.1 of [FIPS205] defines an SLH-DSA public key as two n-byte 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 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. 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 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 16, 24, or 32, depending on the SLH-DSA parameter set. When used in
a SubjectPublicKeyInfo type, the subjectPublicKey BIT STRING contains a SubjectPublicKeyInfo type, the subjectPublicKey BIT STRING contains
the raw octet string encoding of the public key. the raw octet string encoding of the public key.
[I-D.ietf-lamps-cms-sphincs-plus] defines the SLH-DSA-PublicKey and [RFC9814] defines the SLH-DSA-PublicKey and SLH-DSA-PrivateKey ASN.1
SLH-DSA-PrivateKey ASN.1 OCTET STRING types to provide an option for OCTET STRING types to provide an option for encoding a Pure SLH-DSA
encoding a Pure SLH-DSA public or private key in an environment that public or private key in an environment that uses ASN.1 encoding but
uses ASN.1 encoding but doesn't define its own mapping of an SLH-DSA doesn't define its own mapping of an SLH-DSA raw octet string to
raw octet string to ASN.1. HashSLH-DSA public and private keys can ASN.1. HashSLH-DSA public and private keys can use SLH-DSA-PublicKey
use SLH-DSA-PublicKey and SLH-DSA-PrivateKey in the same way. To map and SLH-DSA-PrivateKey in the same way. To map an SLH-DSA-PublicKey
an SLH-DSA-PublicKey OCTET STRING to a SubjectPublicKeyInfo, the OCTET STRING to a SubjectPublicKeyInfo, the OCTET STRING is mapped to
OCTET STRING is mapped to the subjectPublicKey field (a value of type the subjectPublicKey field (a value of type BIT STRING) as follows:
BIT STRING) as follows: the most significant bit of the OCTET STRING The most significant bit of the OCTET STRING value becomes the most
value becomes the most significant bit of the BIT STRING value, and significant bit of the BIT STRING value, and so on; the least
so on; the least significant bit of the OCTET STRING becomes the significant bit of the OCTET STRING becomes the least significant bit
least significant bit of the BIT STRING. of the BIT STRING.
The AlgorithmIdentifier for an SLH-DSA public key MUST use one of the The AlgorithmIdentifier for an SLH-DSA public key MUST use one of the
id-slh-dsa-* or id-hash-slh-dsa-* object identifiers from Section 3. id-slh-dsa-* or id-hash-slh-dsa-* object identifiers from Section 3.
The parameters field of the AlgorithmIdentifier for the SLH-DSA The parameters field of the AlgorithmIdentifier for the SLH-DSA
public key MUST be absent. public key MUST be absent.
Appendix C.1 contains an example of an id-slh-dsa-sha2-128s public Appendix C.1 contains an example of an id-slh-dsa-sha2-128s public
key encoded using the textual encoding defined in [RFC7468]. key encoded using the textual encoding defined in [RFC7468].
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; see Section 4.2.1.3 of [RFC5280]. If the certificate extension; see Section 4.2.1.3 of [RFC5280]. If the
keyUsage extension is present in a certificate that indicates an id- keyUsage extension is present in a certificate that indicates an id-
slh-dsa-* (Pure SLH-DSA) or id-hash-slh-dsa-* (HashSLH-DSA) slh-dsa-* (Pure SLH-DSA) or id-hash-slh-dsa-* (HashSLH-DSA)
identifier in the SubjectPublicKeyInfo, then at least one of the identifier in the SubjectPublicKeyInfo, then at least one of the
following MUST be present: following MUST be present:
digitalSignature * digitalSignature
nonRepudiation
keyCertSign * nonRepudiation
cRLSign
* keyCertSign
* cRLSign
If the keyUsage extension is present in a certificate that indicates If the keyUsage extension is present in a certificate that indicates
an id-slh-dsa-* (Pure SLH-DSA) or id-hash-slh-dsa-* (HashSLH-DSA) an id-slh-dsa-* (Pure SLH-DSA) or id-hash-slh-dsa-* (HashSLH-DSA)
identifier in the SubjectPublicKeyInfo, then the following MUST NOT identifier in the SubjectPublicKeyInfo, then the following MUST NOT
be present: be present:
keyEncipherment, * keyEncipherment
dataEncipherment,
keyAgreement, * dataEncipherment
encipherOnly, and
decipherOnly. * keyAgreement
* encipherOnly
* decipherOnly
Requirements about the keyUsage extension bits defined in [RFC5280] Requirements about the keyUsage extension bits defined in [RFC5280]
still apply. still apply.
7. Private Key Format 7. Private Key Format
"Asymmetric Key Packages" [RFC5958] describes how to encode a private "Asymmetric Key Packages" [RFC5958] describes how to encode a private
key in a structure that both identifies what algorithm the private key in a structure that both identifies what algorithm the private
key is for and optionally allows for the public key and additional key is for and optionally allows for the public key and additional
attributes about the key to be included as well. For illustration, attributes about the key to be included as well. For illustration,
skipping to change at page 14, line 27 skipping to change at line 611
attributes [0] IMPLICIT Attributes OPTIONAL, attributes [0] IMPLICIT Attributes OPTIONAL,
..., ...,
[[2: publicKey [1] IMPLICIT PublicKey OPTIONAL ]], [[2: publicKey [1] IMPLICIT PublicKey OPTIONAL ]],
... ...
} }
PrivateKey ::= OCTET STRING PrivateKey ::= OCTET STRING
PublicKey ::= BIT STRING PublicKey ::= BIT STRING
| The above syntax is from [RFC5958] and is compatible with the | NOTE: The above syntax is from [RFC5958] and is compatible with
| 2021 ASN.1 syntax [X680]. | the 2021 ASN.1 syntax [X680].
Section 9.1 of [FIPS205] defines an SLH-DSA private key as four 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 n-byte elements: SK.seed, SK.prf, PK.seed, and PK.root. The raw
string encoding of an SLH-DSA private key is the concatenation of octet string encoding of an SLH-DSA private key is the concatenation
these four elements, i.e. SK.seed || SK.prf || PK.seed || PK.root. of these four elements, i.e., SK.seed || SK.prf || PK.seed ||
The octet string length is 4*n bytes, where n is 16, 24, or 32, PK.root. The octet string length is 4*n bytes, where n is 16, 24, or
depending on the SLH-DSA parameter set. When used in a 32, depending on the SLH-DSA parameter set. When used in a
OneAsymmetricKey type, the privateKey OCTET STRING contains the raw OneAsymmetricKey type, the privateKey OCTET STRING contains the raw
octet string encoding of the private key. octet string encoding of the private key.
When an SLH-DSA public key is included in a OneAsymmetricKey type, it When an SLH-DSA public key is included in a OneAsymmetricKey type, it
is encoded in the same manner as in a SubjectPublicKeyInfo type. is encoded in the same manner as in a SubjectPublicKeyInfo type.
That is, the publicKey BIT STRING contains the raw octet string That is, the publicKey BIT STRING contains the raw octet string
encoding of the public key. encoding of the public key.
Appendix C.2 contains an example of an id-slh-dsa-sha2-128s private Appendix C.2 contains an example of an id-slh-dsa-sha2-128s private
key encoded using the textual encoding defined in [RFC7468]. key encoded using the textual encoding defined in [RFC7468].
NOTE: There exist some private key import functions that have not | NOTE: There exist some private key import functions that have
picked up the new ASN.1 structure OneAsymmetricKey that is defined in | not picked up the new ASN.1 structure OneAsymmetricKey, which
[RFC5958]. This means that they will not accept a private key | is defined in [RFC5958]. This means that they will not accept
structure that contains the public key field. This means a balancing | a private key structure that contains the public key field.
act needs to be done between being able to do a consistency check on | This means a balancing act needs to be done between being able
the key pair and widest ability to import the key. | to do a consistency check on the key pair and widest ability to
| import the key.
8. Operational Considerations 8. Operational Considerations
SLH-DSA uses the same OID to identify a public key and a signature SLH-DSA uses the same OID to identify a public key and a signature
algorithm. The implication of this is that, despite being algorithm. The implication of this is that, despite being
mathematically possible, an SLH-DSA key identified by a Pure SLH-DSA 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 OID is not permitted to be used to generate or verify a signature
identified by an HashSLH-DSA OID, and vice-versa. identified by a HashSLH-DSA OID, and vice versa.
CA operators will need to decide in advance whether their CA Certification authority (CA) operators will need to decide in advance
certificates will use Pure SLH-DSA or HashSLH-DSA and assign the whether their CA certificates will use Pure SLH-DSA or HashSLH-DSA
appropriate OID to the public and private keys when generating their and assign the appropriate OID to the public and private keys when
certificate. Some of the following considerations may affect this generating their certificate. Some of the following considerations
decision. may affect this decision.
* When using an external signing module, such as an HSM, the size of * When using an external signing module, such as a Hardware Security
data that can be transferred to and processed by the signature Module (HSM), the size of data that can be transferred to and
module may be limited. SLH-DSA performs two passes on the processed by the signature module may be limited. SLH-DSA
internal M' message, so it must be held in memory. Using HashSLH- performs two passes on the internal M' message, so it must be held
DSA reduces the size of M'. in memory. Using HashSLH-DSA reduces the size of M'.
* Large CRLs might also exceed the size limits of HSM signing * Large CRLs might also exceed the size limits of HSM signing
operations when using Pure SLH-DSA. One way to limit the size of operations when using Pure SLH-DSA. One way to limit the size of
CRLs is to make use of CRL Distribution Points and Issuing CRLs is to make use of CRL Distribution Points and Issuing
Distribution Points to create partitioned CRLs in accordance with Distribution Points to create partitioned CRLs in accordance with
Section 5.2.5 of [RFC5280]. Section 5.2.5 of [RFC5280].
* EE certificates with many SANs might also exceed the size limits * End Entity (EE) certificates with many subject alternative names
of HSM signing operations. (SANs) might also exceed the size limits of HSM signing
operations.
* Potential verifiers' environments might need to be considered. * Potential verifiers' environments might need to be considered.
The entire certificate or CRL needs to be held in memory during The entire certificate or CRL needs to be held in memory during
SLH-DSA signature verification, it cannot be streamed. In SLH-DSA signature verification; it cannot be streamed. In
particular, there is a randomizer (R) which is extracted from the particular, there is a randomizer (R) that is extracted from the
SLH-DSA signature and fed to a digest function before M' is. SLH-DSA signature and fed to a digest function before M' is.
Thus, to stream a message for SLH-DSA verification the signature Thus, to stream a message for SLH-DSA verification, the signature
must come before the message. This is not the case for must come before the message. This is not the case for
certificates and CRLs. Using HashSLH-DSA reduces the size of the certificates and CRLs. Using HashSLH-DSA reduces the size of the
M' being held in memory. M' being held in memory.
An SLH-DSA private key has a very large (2^64) number of signatures An SLH-DSA private key has a very large (2^64) number of signatures
it can safely generate (see Section 9). If an operator might it can safely generate (see Section 9). If an operator might
conceivably generate a number of signatures approaching this limit, conceivably generate a number of signatures approaching this limit,
they should mitigate potential harm by tracking the number of they should mitigate potential harm by tracking the number of
signatures generated and destroying the private key once an signatures generated and destroying the private key once an
appropriate limit is reached, or by setting the "Not After" appropriate limit is reached or by setting the "Not After"
(expiration) date of the certificate such that the the limit couldn't (expiration) date of the certificate such that the limit couldn't
possibly be surpassed given the rate of signing. possibly be surpassed given the rate of signing.
9. Security Considerations 9. Security Considerations
The security considerations of [RFC5280] apply accordingly. The security considerations of [RFC5280] apply accordingly.
Moreover, the security aspects mentioned throughout [FIPS205] should Moreover, the security aspects mentioned throughout [FIPS205] should
be taken into account; see for instance Sections 3.1 and 3.2 or the be taken into account; for instance, see Sections 3.1 and 3.2 or the
beginning of Section 11. beginning of Section 11.
The security of SLH-DSA relies on the security properties of the The security of SLH-DSA relies on the security properties of the
internal hash and XOF functions. In particular, it relies on these internal hash and XOF functions. In particular, it relies on these
functions being preimage resistant, but it does not rely on them functions being preimage resistant, but it does not rely on them
being collision resistant. Since HashSLH-DSA performs a pre-hash being collision resistant. Since HashSLH-DSA performs a pre-hash
before signing, it relies on both preimage resistance and collision before signing, it relies on both preimage resistance and collision
resistance of the pre-hash function. In order to achieve an resistance of the pre-hash function. In order to achieve an
appropriate level of collision resistance, the output length of the appropriate level of collision resistance, the output length of the
pre-hash functions used for HashSLH-DSA is twice the length of the pre-hash functions used for HashSLH-DSA is twice the length of the
skipping to change at page 16, line 33 skipping to change at line 716
private keys may result in the ability to forge signatures. private keys may result in the ability to forge signatures.
When generating an SLH-DSA key pair, an implementation MUST generate When generating an SLH-DSA key pair, an implementation MUST generate
each key pair independently of all other key pairs in the SLH-DSA each key pair independently of all other key pairs in the SLH-DSA
hypertree. hypertree.
An SLH-DSA tree MUST NOT be used for more than 2^64 signing An SLH-DSA tree MUST NOT be used for more than 2^64 signing
operations. operations.
The generation of private keys relies on random numbers. The use of The generation of private keys relies on random numbers. The use of
inadequate pseudo-random number generators (PRNGs) to generate these inadequate pseudorandom number generators (PRNGs) to generate these
values can result in little or no security. An attacker may find it values can result in little or no security. An attacker may find it
much easier to reproduce the PRNG environment that produced the keys, much easier to reproduce the PRNG environment that produced the keys,
searching the resulting small set of possibilities, rather than brute searching the resulting small set of possibilities, rather than brute
force searching the whole key space. The generation of quality force searching the whole key space. The generation of quality
random numbers is difficult; see Section 3.1 of [FIPS205] for some random numbers is difficult; see Section 3.1 of [FIPS205] for some
additional information. additional information.
Fault attacks can lead to forgeries of message signatures [CMP2018] Fault attacks can lead to forgeries of message signatures; see
and [Ge2023]. Verifying a signature before releasing the signature [CMP2018] and [Ge2023]. Verifying a signature before releasing the
value is a typical fault attack countermeasure; however, this signature value is a typical fault attack countermeasure; however,
countermeasure is not effective for SLH-DSA [Ge2023]. Redundancy by this countermeasure is not effective for SLH-DSA [Ge2023].
replicating the signature generation process can be used as an Redundancy by replicating the signature generation process can be
effective fault attack countermeasure for SLH-DSA [Ge2023]; however, used as an effective fault attack countermeasure for SLH-DSA
the SLH-DSA signature generation is already considered slow. [Ge2023]; however, the SLH-DSA signature generation is already
considered slow.
Likewise, passive power and emissions side-channel attacks can leak Likewise, passive power and emissions side-channel attacks can leak
the SLH-DSA private signing key, and countermeasures can be taken the SLH-DSA private signing key, and countermeasures can be taken
against these attacks [SLotH]. against these attacks [SLotH].
10. IANA Considerations 10. IANA Considerations
For the ASN.1 Module in Appendix A of this document, IANA is For the ASN.1 module in Appendix A of this document, IANA has
requested to assign an object identifier (OID) for the module assigned an object identifier (OID) for the module identifier (120)
identifier (TBD1) with a Description of "id-mod-x509-slh-dsa-2024". with a Description of "id-mod-x509-slh-dsa-2024". The OID for the
The OID for the module should be allocated in the "SMI Security for module has been allocated in the "SMI Security for PKIX Module
PKIX Module Identifier" registry (1.3.6.1.5.5.7.0). Identifier" registry (1.3.6.1.5.5.7.0).
11. References 11. References
11.1. Normative References 11.1. Normative References
[CSOR] NIST, "Computer Security Objects Register", 20 August [CSOR] NIST, "Computer Security Objects Register (CSOR)", 13 June
2024, <https://csrc.nist.gov/projects/computer-security- 2025, <https://csrc.nist.gov/projects/computer-security-
objects-register/algorithm-registration>. objects-register/algorithm-registration>.
[FIPS205] National Institute of Standards and Technology (NIST), [FIPS205] NIST, "Stateless Hash-Based Digital Signature Standard",
"Stateless Hash-Based Digital Signature Standard", FIPS NIST FIPS 205, DOI 10.6028/NIST.FIPS.205, 13 August 2024,
PUB 205, 13 August 2024, <https://nvlpubs.nist.gov/nistpubs/FIPS/
<https://doi.org/10.6028/NIST.FIPS.205>. NIST.FIPS.205.pdf>.
[I-D.ietf-lamps-cms-sphincs-plus]
Housley, R., Fluhrer, S., Kampanakis, P., and B.
Westerbaan, "Use of the SLH-DSA Signature Algorithm in the
Cryptographic Message Syntax (CMS)", Work in Progress,
Internet-Draft, draft-ietf-lamps-cms-sphincs-plus-19, 13
January 2025, <https://datatracker.ietf.org/doc/html/
draft-ietf-lamps-cms-sphincs-plus-19>.
[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>.
[RFC5958] Turner, S., "Asymmetric Key Packages", RFC 5958, [RFC5958] Turner, S., "Asymmetric Key Packages", RFC 5958,
DOI 10.17487/RFC5958, August 2010, DOI 10.17487/RFC5958, August 2010,
<https://www.rfc-editor.org/rfc/rfc5958>. <https://www.rfc-editor.org/info/rfc5958>.
[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>.
[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/RFC9814, July 2025,
<https://www.rfc-editor.org/info/rfc9814>.
[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>.
11.2. Informative References 11.2. Informative References
[CMP2018] Castelnovi, L., A, Martinelli, and T. Prest, "Grafting [CMP2018] Castelnovi, L., Martinelli, A., and T. Prest, "Grafting
Trees: A Fault Attack Against the SPHINCS Framework", Trees: A Fault Attack Against the SPHINCS Framework",
Lecture Notes in Computer Science vol 10786, Post-Quantum Cryptography (PQCrpyto 2018), Lecture Notes
PQCrypto 2018, Post-Quantum Cryptography pp. 165-184, in Computer Science, vol. 10786, pp. 165-184, 2018,
2018, <https://link.springer.com/ <https://link.springer.com/
chapter/10.1007/978-3-319-79063-3_8>. chapter/10.1007/978-3-319-79063-3_8>.
[FIPS180] Dang, Q. H. and NIST, "Secure Hash Standard", NIST Federal [FIPS180] NIST, "Secure Hash Standard (SHS)", NIST FIPS 180-4,
Information Processing Standards Publications 180-4, DOI 10.6028/NIST.FIPS.180-4, August 2015,
DOI 10.6028/NIST.FIPS.180-4, July 2015,
<https://nvlpubs.nist.gov/nistpubs/FIPS/ <https://nvlpubs.nist.gov/nistpubs/FIPS/
NIST.FIPS.180-4.pdf>. NIST.FIPS.180-4.pdf>.
[FIPS202] Dworkin, M., Dworkin, M. J., and NIST, "SHA-3 Standard: [FIPS202] NIST, "SHA-3 Standard: Permutation-Based Hash and
Permutation-Based Hash and Extendable-Output Functions", Extendable-Output Functions", NIST FIPS 202,
FIPS PUB 202, NIST Federal Information Processing
Standards Publications 202, DOI 10.6028/nist.fips.202,
DOI 10.6028/NIST.FIPS.202, August 2015, DOI 10.6028/NIST.FIPS.202, August 2015,
<http://nvlpubs.nist.gov/nistpubs/FIPS/NIST.FIPS.202.pdf>. <http://nvlpubs.nist.gov/nistpubs/FIPS/NIST.FIPS.202.pdf>.
[Ge2023] Genêt, A., "On Protecting SPHINCS+ Against Fault Attacks", [Ge2023] Genêt, A., "On Protecting SPHINCS+ Against Fault Attacks",
TCHES 2023/02, n.d., TCHES, vol. 2023, no. 2, pp. 80-114,
DOI 10.46586/tches.v2023.i2.80-114, March 2023,
<https://doi.org/10.46586/tches.v2023.i2.80-114>. <https://doi.org/10.46586/tches.v2023.i2.80-114>.
[I-D.ietf-lamps-dilithium-certificates] [NIST-PQC] NIST, "Post-Quantum Cryptography (PQC)", 28 July 2025,
Massimo, J., Kampanakis, P., Turner, S., and B.
Westerbaan, "Internet X.509 Public Key Infrastructure -
Algorithm Identifiers for the Module-Lattice-Based Digital
Signature Algorithm (ML-DSA)", Work in Progress, Internet-
Draft, draft-ietf-lamps-dilithium-certificates-12, 26 June
2025, <https://datatracker.ietf.org/doc/html/draft-ietf-
lamps-dilithium-certificates-12>.
[NIST-PQC] National Institute of Standards and Technology, "Post-
Quantum Cryptography Project", 20 December 2016,
<https://csrc.nist.gov/projects/post-quantum- <https://csrc.nist.gov/projects/post-quantum-
cryptography>. cryptography>.
[RFC7468] Josefsson, S. and S. Leonard, "Textual Encodings of PKIX, [RFC7468] Josefsson, S. and S. Leonard, "Textual Encodings of PKIX,
PKCS, and CMS Structures", RFC 7468, DOI 10.17487/RFC7468, PKCS, and CMS Structures", RFC 7468, DOI 10.17487/RFC7468,
April 2015, <https://www.rfc-editor.org/rfc/rfc7468>. April 2015, <https://www.rfc-editor.org/info/rfc7468>.
[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>.
[RFC9881] Massimo, J., Kampanakis, P., Turner, S., and B. E.
Westerbaan, "Internet X.509 Public Key Infrastructure --
Algorithm Identifiers for the Module-Lattice-Based Digital
Signature Algorithm (ML-DSA)", RFC 9881,
DOI 10.17487/RFC9881, October 2025,
<https://www.rfc-editor.org/info/rfc9881>.
[SLotH] Saarinen, M-J., "Accelerating SLH-DSA by Two Orders of [SLotH] Saarinen, M-J., "Accelerating SLH-DSA by Two Orders of
Magnitude with a Single Hash Unit", 2024, Magnitude with a Single Hash Unit", Cryptology ePrint
<https://eprint.iacr.org/2024/367.pdf>. Archive, Paper 2024/367, DOI 10.1007/978-3-031-68376-3_9,
2024, <https://eprint.iacr.org/2024/367.pdf>.
Appendix A. ASN.1 Module Appendix A. ASN.1 Module
This appendix includes the ASN.1 module [X680] for SLH-DSA. Note This appendix includes the ASN.1 module [X680] for SLH-DSA. Note
that as per [RFC5280], certificates use the Distinguished Encoding that as per [RFC5280], certificates use the Distinguished Encoding
Rules; see [X690]. This module imports objects from [RFC5912] and Rules; see [X690]. This module imports objects from [RFC5912] and
[I-D.ietf-lamps-cms-sphincs-plus]. [RFC9814].
| RFC EDITOR: Please replace [I-D.ietf-lamps-cms-sphincs-plus]
| throughout this document with a reference to the published RFC.
<CODE BEGINS> <CODE BEGINS>
X509-SLH-DSA-Module-2024 X509-SLH-DSA-Module-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-x509-slh-dsa-2024(TBD1) } mechanisms(5) pkix(7) id-mod(0) id-mod-x509-slh-dsa-2024(120) }
DEFINITIONS IMPLICIT TAGS ::= BEGIN DEFINITIONS IMPLICIT TAGS ::= BEGIN
EXPORTS ALL; EXPORTS ALL;
IMPORTS IMPORTS
PUBLIC-KEY, SIGNATURE-ALGORITHM, SMIME-CAPS PUBLIC-KEY, SIGNATURE-ALGORITHM, SMIME-CAPS
FROM AlgorithmInformation-2009 -- in [RFC5912] FROM AlgorithmInformation-2009 -- in [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)
skipping to change at page 20, line 33 skipping to change at line 889
pk-slh-dsa-sha2-256s, pk-slh-dsa-sha2-256f, pk-slh-dsa-sha2-256s, pk-slh-dsa-sha2-256f,
pk-slh-dsa-shake-128s, pk-slh-dsa-shake-128f, pk-slh-dsa-shake-128s, pk-slh-dsa-shake-128f,
pk-slh-dsa-shake-192s, pk-slh-dsa-shake-192f, pk-slh-dsa-shake-192s, pk-slh-dsa-shake-192f,
pk-slh-dsa-shake-256s, pk-slh-dsa-shake-256f, pk-slh-dsa-shake-256s, pk-slh-dsa-shake-256f,
sa-slh-dsa-sha2-128s, sa-slh-dsa-sha2-128f, sa-slh-dsa-sha2-128s, sa-slh-dsa-sha2-128f,
sa-slh-dsa-sha2-192s, sa-slh-dsa-sha2-192f, sa-slh-dsa-sha2-192s, sa-slh-dsa-sha2-192f,
sa-slh-dsa-sha2-256s, sa-slh-dsa-sha2-256f, sa-slh-dsa-sha2-256s, sa-slh-dsa-sha2-256f,
sa-slh-dsa-shake-128s, sa-slh-dsa-shake-128f, sa-slh-dsa-shake-128s, sa-slh-dsa-shake-128f,
sa-slh-dsa-shake-192s, sa-slh-dsa-shake-192f, sa-slh-dsa-shake-192s, sa-slh-dsa-shake-192f,
sa-slh-dsa-shake-256s, sa-slh-dsa-shake-256f sa-slh-dsa-shake-256s, sa-slh-dsa-shake-256f
FROM SLH-DSA-Module-2024 -- in [I-D.ietf-lamps-cms-sphincs-plus] FROM SLH-DSA-Module-2024 -- in [RFC9814]
{ 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-slh-dsa-2024(81) } ; id-smime(16) id-mod(0) id-mod-slh-dsa-2024(81) } ;
-- --
-- HashSLH-DSA object identifiers from [CSOR] -- HashSLH-DSA object identifiers from [CSOR]
-- --
nistAlgorithms OBJECT IDENTIFIER ::= { joint-iso-itu-t(2) nistAlgorithms OBJECT IDENTIFIER ::= { joint-iso-itu-t(2)
country(16) us(840) organization(1) gov(101) csor(3) 4 } country(16) us(840) organization(1) gov(101) csor(3) 4 }
skipping to change at page 27, line 17 skipping to change at line 1210
END END
<CODE ENDS> <CODE ENDS>
Appendix B. Security Strengths Appendix B. Security Strengths
Instead of defining the strength of a quantum algorithm in a Instead of defining the strength of a quantum algorithm in a
traditional manner using precise estimates of the number of bits of traditional manner using precise estimates of the number of bits of
security, NIST defined a collection of broad security strength security, NIST defined a collection of broad security strength
categories. Each category is defined by a comparatively easy-to- categories. Each category is defined by a comparatively easy-to-
analyze reference primitive that cover a range of security strengths analyze reference primitive that covers a range of security strengths
offered by existing NIST standards in symmetric cryptography, which offered by existing NIST standards in symmetric cryptography, which
NIST expects to offer significant resistance to quantum NIST expects to offer significant resistance to quantum
cryptanalysis. These categories describe any attack that breaks the cryptanalysis. These categories describe any attack that breaks the
relevant security definition that must require computational relevant security definition that must require computational
resources comparable to or greater than those required for: Level 1 - resources comparable to or greater than those required for:
key search on a block cipher with a 128-bit key (e.g., AES128), Level
2 - collision search on a 256-bit hash function (e.g., SHA256/
SHA3-256), Level 3 - key search on a block cipher with a 192-bit key
(e.g., AES192), Level 4 - collision search on a 384-bit hash function
(e.g. SHA384/SHA3-384), Level 5 - key search on a block cipher with
a 256-bit key (e.g., AES 256).
The SLH-DSA parameter sets defined for NIST security levels 1, 3 and * Level 1 - key search on a block cipher with a 128-bit key (e.g.,
5 are listed in Table 1, along with the resulting signature size, AES128),
public key, and private key sizes in bytes. The HashSLH-DSA
parameter sets have the same values as the Pure SLH-DSA equivalents.
+==============================+============+=======+======+=======+ * Level 2 - collision search on a 256-bit hash function (e.g.,
| OID | NIST Level | Sig. | Pub. | Priv. | SHA256/ SHA3-256),
* Level 3 - key search on a block cipher with a 192-bit key (e.g.,
AES192),
* Level 4 - collision search on a 384-bit hash function (e.g.,
SHA384/SHA3-384), and
* Level 5 - key search on a block cipher with a 256-bit key (e.g.,
AES 256).
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.
+==============================+============+======================+
| OID | NIST Level | Size (in bytes) |
| | +=======+======+=======+
| | | Sig. | Pub. | Priv. |
| | | | Key | Key | | | | | Key | Key |
+==============================+============+=======+======+=======+ +==============================+============+=======+======+=======+
| id-(hash-)slh-dsa-sha2-128s | 1 | 7856 | 32 | 64 | | id-(hash-)slh-dsa-sha2-128s | 1 | 7856 | 32 | 64 |
+------------------------------+------------+-------+------+-------+ +------------------------------+------------+-------+------+-------+
| id-(hash-)slh-dsa-sha2-128f | 1 | 17088 | 32 | 64 | | id-(hash-)slh-dsa-sha2-128f | 1 | 17088 | 32 | 64 |
+------------------------------+------------+-------+------+-------+ +------------------------------+------------+-------+------+-------+
| id-(hash-)slh-dsa-sha2-192s | 3 | 16224 | 48 | 96 | | id-(hash-)slh-dsa-sha2-192s | 3 | 16224 | 48 | 96 |
+------------------------------+------------+-------+------+-------+ +------------------------------+------------+-------+------+-------+
| id-(hash-)slh-dsa-sha2-192f | 3 | 35664 | 48 | 96 | | id-(hash-)slh-dsa-sha2-192f | 3 | 35664 | 48 | 96 |
+------------------------------+------------+-------+------+-------+ +------------------------------+------------+-------+------+-------+
skipping to change at page 28, line 34 skipping to change at line 1268
+------------------------------+------------+-------+------+-------+ +------------------------------+------------+-------+------+-------+
| id-(hash-)slh-dsa-shake-192s | 3 | 16224 | 48 | 96 | | id-(hash-)slh-dsa-shake-192s | 3 | 16224 | 48 | 96 |
+------------------------------+------------+-------+------+-------+ +------------------------------+------------+-------+------+-------+
| id-(hash-)slh-dsa-shake-192f | 3 | 35664 | 48 | 96 | | id-(hash-)slh-dsa-shake-192f | 3 | 35664 | 48 | 96 |
+------------------------------+------------+-------+------+-------+ +------------------------------+------------+-------+------+-------+
| id-(hash-)slh-dsa-shake-256s | 5 | 29792 | 64 | 128 | | id-(hash-)slh-dsa-shake-256s | 5 | 29792 | 64 | 128 |
+------------------------------+------------+-------+------+-------+ +------------------------------+------------+-------+------+-------+
| id-(hash-)slh-dsa-shake-256f | 5 | 49856 | 64 | 128 | | id-(hash-)slh-dsa-shake-256f | 5 | 49856 | 64 | 128 |
+------------------------------+------------+-------+------+-------+ +------------------------------+------------+-------+------+-------+
Table 1: SLH-DSA security strengths Table 1: SLH-DSA Security Strengths
Appendix C. Examples Appendix C. Examples
This appendix contains examples of SLH-DSA public keys, private keys This appendix contains examples of SLH-DSA public keys, private keys,
and certificates. and certificates.
C.1. Example Public Key C.1. Example Public Key
An example of an SLH-DSA public key using id-slh-dsa-sha2-128s: An example of an SLH-DSA public key using id-slh-dsa-sha2-128s:
-----BEGIN PUBLIC KEY----- -----BEGIN PUBLIC KEY-----
MDAwCwYJYIZIAWUDBAMUAyEAK4EJ7Hd8qk4fAkzPz5SX2ZGAUJKA9CVq8rB6+AKJ MDAwCwYJYIZIAWUDBAMUAyEAK4EJ7Hd8qk4fAkzPz5SX2ZGAUJKA9CVq8rB6+AKJ
tJQ= tJQ=
-----END PUBLIC KEY----- -----END PUBLIC KEY-----
skipping to change at page 43, line 16 skipping to change at line 1968
oclhl0rmOqsWZLPfFlre5fm6XX3rBPX08PB95Bp0/H0DFqTK9uAFleD6nYAHWLQS oclhl0rmOqsWZLPfFlre5fm6XX3rBPX08PB95Bp0/H0DFqTK9uAFleD6nYAHWLQS
XjRDBK2Qnz++Mco908nQt5HHXNArgXM0v8qlbiNPs/O0vwP0va/91wmLZaMMdtwe XjRDBK2Qnz++Mco908nQt5HHXNArgXM0v8qlbiNPs/O0vwP0va/91wmLZaMMdtwe
fJfSvoXUZW35PW6ubFf0EEAh1gQtm5vllZCcUqitYYvNsBLBEybDTY4igoKb/m0B fJfSvoXUZW35PW6ubFf0EEAh1gQtm5vllZCcUqitYYvNsBLBEybDTY4igoKb/m0B
5zxlebR5n56wEN1ealdDjGtB1earlLrHZ6W0QdgQDP0pd+ILzSmALq5epYWjogkx 5zxlebR5n56wEN1ealdDjGtB1earlLrHZ6W0QdgQDP0pd+ILzSmALq5epYWjogkx
UYKYCyx6a5bvjcD1H5i09iK2IW4247sY2h0kRg1lKLZq UYKYCyx6a5bvjcD1H5i09iK2IW4247sY2h0kRg1lKLZq
-----END CERTIFICATE----- -----END CERTIFICATE-----
Acknowledgments Acknowledgments
Much of the structure and text of this document is based on [RFC8410] Much of the structure and text of this document is based on [RFC8410]
and [I-D.ietf-lamps-dilithium-certificates]. The remainder comes and [RFC9881]. The remainder comes from [RFC9814]. Thanks to the
from [I-D.ietf-lamps-cms-sphincs-plus]. Thanks to those authors, and authors of those documents, and the ones they based their work on,
the ones they based their work on, for making our work easier. for making our work easier. "Copying always makes things easier and
"Copying always makes things easier and less error prone" - less error prone" [RFC8411]. Thanks to Sean Turner for helpful text
[RFC8411]. Thanks to Sean Turner for helpful text and to Markku- and to Markku-Juhani O. Saarinen for side-channel clarifications.
Juhani O. Saarinen for side-channel clarifications.
Authors' Addresses Authors' Addresses
Kaveh Bashiri Kaveh Bashiri
BSI BSI
Email: kaveh.bashiri.ietf@gmail.com Email: kaveh.bashiri.ietf@gmail.com
Scott Fluhrer Scott Fluhrer
Cisco Systems Cisco Systems
Email: sfluhrer@cisco.com Email: sfluhrer@cisco.com
 End of changes. 73 change blocks. 
268 lines changed or deleted 259 lines changed or added

This html diff was produced by rfcdiff 1.48.