rfc9814.original   rfc9814.txt 
Network Working Group R. Housley Internet Engineering Task Force (IETF) R. Housley
Internet-Draft Vigil Security Request for Comments: 9814 Vigil Security
Intended status: Standards Track S. Fluhrer Category: Standards Track S. Fluhrer
Expires: 17 July 2025 Cisco Systems ISSN: 2070-1721 Cisco Systems
P. Kampanakis P. Kampanakis
Amazon Web Services Amazon Web Services
B. Westerbaan B. Westerbaan
Cloudflare Cloudflare
13 January 2025 July 2025
Use of the SLH-DSA Signature Algorithm in the Cryptographic Message Use of the SLH-DSA Signature Algorithm in the Cryptographic Message
Syntax (CMS) Syntax (CMS)
draft-ietf-lamps-cms-sphincs-plus-19
Abstract Abstract
SLH-DSA is a stateless hash-based signature scheme. This document SLH-DSA is a stateless hash-based signature scheme. This document
specifies the conventions for using the SLH-DSA signature algorithm specifies the conventions for using the SLH-DSA signature algorithm
with the Cryptographic Message Syntax (CMS). In addition, the with the Cryptographic Message Syntax (CMS). In addition, the
algorithm identifier and public key syntax are provided. algorithm identifier and public key syntax are provided.
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 17 July 2025. Information about the current status of this document, any errata,
and how to provide feedback on it may be obtained at
https://www.rfc-editor.org/info/rfc9814.
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 . . . . . . . . . . . . . . . . . . . . . . . . 2 1. Introduction
1.1. ASN.1 . . . . . . . . . . . . . . . . . . . . . . . . . . 3 1.1. ASN.1
1.2. Motivation . . . . . . . . . . . . . . . . . . . . . . . 3 1.2. Motivation
1.3. Terminology . . . . . . . . . . . . . . . . . . . . . . . 3 1.3. Terminology
2. SLH-DSA Hash-based Signature Algorithm Overview . . . . . . . 3 2. SLH-DSA Hash-Based Signature Algorithm Overview
3. SLH-DSA Public Key Identifier . . . . . . . . . . . . . . . . 4 3. SLH-DSA Public Key Identifier
4. Signed-data Conventions . . . . . . . . . . . . . . . . . . . 7 4. Signed-Data Conventions
5. Security Considerations . . . . . . . . . . . . . . . . . . . 9 5. Security Considerations
6. Operational Considerations . . . . . . . . . . . . . . . . . 10 6. Operational Considerations
7. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 11 7. IANA Considerations
8. References . . . . . . . . . . . . . . . . . . . . . . . . . 11 8. References
8.1. Normative References . . . . . . . . . . . . . . . . . . 11 8.1. Normative References
8.2. Informative References . . . . . . . . . . . . . . . . . 12 8.2. Informative References
Appendix A. ASN.1 Module . . . . . . . . . . . . . . . . . . . . 13 Appendix A. ASN.1 Module
Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . . 19 Acknowledgements
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 19 Authors' Addresses
1. Introduction 1. Introduction
This document specifies the conventions for using the SLH-DSA hash- This document specifies the conventions for using the SLH-DSA hash-
based signature algorithm [FIPS205] with the Cryptographic Message based signature algorithm [FIPS205] with the Cryptographic Message
Syntax (CMS) [RFC5652] signed-data content type. Syntax (CMS) [RFC5652] signed-data content type.
SLH-DSA offers two signature modes: pure mode and pre-hash mode. SLH-DSA offers two signature modes: pure mode and pre-hash mode.
SLH-DSA signature operations include a context string as input. The SLH-DSA signature operations include a context string as input. The
context string has a maximum length of 255 bytes. By default, the context string has a maximum length of 255 bytes. By default, the
skipping to change at page 2, line 48 skipping to change at line 90
use of pure mode with an empty context string for the CMS signed-data use of pure mode with an empty context string for the CMS signed-data
content type. content type.
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 provide 128 bits of security, 192 bits security levels were chosen to provide 128 bits of security, 192 bits
of security, and 256 bits of security. Separate algorithm of security, and 256 bits of security. Separate algorithm
identifiers have been assigned for SLH-DSA at each of these security identifiers have been assigned for SLH-DSA at each of these security
levels. levels.
SLH-DSA is a stateless hash-based signature algorithm. Other hash- SLH-DSA is a stateless hash-based signature algorithm. Other hash-
based signature algorithms are stateful, including HSS/LMS [RFC8554] based signature algorithms are stateful, including Hierarchical
and XMSS [RFC8391]. Without the need for state kept by the signer, Signature System (HSS) / Leighton-Micali Signatures (LMS) [RFC8554]
SLH-DSA is much less fragile than the stateful hash-based signature and eXtended Merkle Signature Scheme (XMSS) [RFC8391]. Without the
algorithms. need for state kept by the signer, SLH-DSA is much less fragile than
the stateful hash-based signature algorithms.
1.1. ASN.1 1.1. ASN.1
CMS values are generated using ASN.1 [X680], using the Basic Encoding CMS values are generated using ASN.1 [X680], using the Basic Encoding
Rules (BER) and the Distinguished Encoding Rules (DER) [X690]. Rules (BER) and the Distinguished Encoding Rules (DER) [X690].
1.2. Motivation 1.2. Motivation
There have been recent advances in cryptanalysis and advances in the There have been recent advances in cryptanalysis and advances in the
development of quantum computers. Each of these advances pose a development of quantum computers. Each of these advances pose a
threat to widely deployed digital signature algorithms. threat to widely deployed digital signature algorithms.
If cryptographically relevant quantum computers (CRQC) are ever If Cryptographically Relevant Quantum Computers (CRQCs) are ever
built, they will be able to break many of the public-key built, they will be able to break many of the public key
cryptosystems currently in use, including RSA, DSA, ECDSA, and EdDSA. cryptosystems currently in use, including RSA, DSA, Elliptic Curve
A post-quantum cryptosystem (PQC) is secure against quantum computers Digital Signature Algorithm (ECDSA), and Edwards-curve Digital
that have more than a trivial number of quantum bits (qu-bits). It Signature Algorithm (EdDSA). A Post-Quantum Cryptosystem (PQC) is
is open to conjecture when it will be feasible to build such quantum secure against quantum computers that have more than a trivial number
computers; however, it is prudent to use cryptographic algorithms of quantum bits (qu-bits). It is open to conjecture when it will be
that remain secure if a CRQC is invented. SLH-DSA is a PQC signature feasible to build such quantum computers; however, it is prudent to
algorithm. use cryptographic algorithms that remain secure if a CRQC is
invented. SLH-DSA is a PQC signature algorithm.
1.3. Terminology 1.3. Terminology
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.
2. SLH-DSA Hash-based Signature Algorithm Overview 2. SLH-DSA Hash-Based Signature Algorithm Overview
SLH-DSA is a hash-based signature scheme. SLH-DSA makes use of a few SLH-DSA is a hash-based signature scheme. SLH-DSA makes use of a few
time signature construction, namely Forest of Random Subsets (FORS) time signature constructions, namely Forest of Random Subsets (FORS)
and a hypertree. FORS signs a message with a private key. The and a hypertree. FORS signs a message with a private key. The
corresponding FORS public keys are the leaves in k binary trees. The corresponding FORS public keys are the leaves in k binary trees. The
roots of these trees are hashed together to form a FORS root. SLH- roots of these trees are hashed together to form a FORS root. SLH-
DSA uses a one-time signature scheme called WOTS+. The FORS tree DSA uses a one-time signature scheme called Winternitz One-Time
roots are signed by a WOTS+ one-time signature private key. The Signature Plus (WOTS+). The FORS tree roots are signed by a WOTS+
corresponding WOTS+ public keys form the leaves in d-layers of Merkle one-time signature private key. The corresponding WOTS+ public keys
subtrees in the SLH-DSA hypertree. The bottom layer of that form the leaves in d-layers of Merkle subtrees in the SLH-DSA
hypertree signs the FORS roots with WOTS+. The root of the bottom hypertree. The bottom layer of that hypertree signs the FORS roots
Merkle subtrees are then signed with WOTS+ and the corresponding with WOTS+. The roots of the bottom Merkle subtrees are then signed
WOTS+ public keys form the leaves of the next level up subtree. with WOTS+ and the corresponding WOTS+ public keys form the leaves of
Subtree roots are consequently signed by their corresponding subtree the next-level-up subtree. Subtree roots are consequently signed by
layers until the top subtree is reached. The top layer subtree forms their corresponding subtree layers until the top subtree is reached.
the hypertree root which is trusted at the verifier. The top-layer subtree forms the hypertree root, which is trusted at
the verifier.
A SLH-DSA signature consists of the randomization string, the FORS An SLH-DSA signature consists of the randomization string, the FORS
signature, the WOTS+ signature in each layer, and the path to the signature, the WOTS+ signature in each layer, and the path to the
root of each subtree until the root of the hypertree is reached. root of each subtree until the root of the hypertree is reached.
A SLH-DSA signature is verified by verifying the FORS signature, the An SLH-DSA signature is verified using the FORS signature, the WOTS+
WOTS+ signatures and the path to the root of each subtree. When signatures, and the path to the root of each subtree. When reaching
reaching the root of the hypertree, the signature verifies only if it the root of the hypertree, the signature verifies only if it hashes
hashes to the pre-trusted root of the SLH-DSA hypertree. to the pre-trusted root of the SLH-DSA hypertree.
SLH-DSA is a stateless hash-based signature algorithm. Stateful SLH-DSA is a stateless hash-based signature algorithm. Stateful
hash-based signature schemes require that the WOTS+ private key hash-based signature schemes require that the WOTS+ private key
(generated by using a state index) is never reused or the scheme (generated by using a state index) never be reused or the scheme
loses it security. Although its security decreases, FORS which is loses its security. Although its security decreases, FORS, which is
used at the bottom of the SLH-DSA hypertree does not collapse if the used at the bottom of the SLH-DSA hypertree, does not collapse if the
same private key used to sign two or more different messages like in same private key used to sign two or more different messages like in
stateful hash-based signature schemes. Without the need for state stateful hash-based signature schemes. Without the need for state
kept by the signer to ensure it is not reused, SLH-DSA is much less kept by the signer to ensure it is not reused, SLH-DSA is much less
fragile. fragile.
SLH-DSA was designed to sign up to 2^64 messages and offers three SLH-DSA was designed to sign up to 2^64 messages and offers three
security levels. The parameters of the SLH-DSA hypertree include the security levels. The parameters of the SLH-DSA hypertree include the
security parameter, the hash function, the tree height, the number of security parameter, the hash function, the tree height, the number of
layers of subtrees, the Winternitz parameter of WOTS+, the number of layers of subtrees, the Winternitz parameter of WOTS+, and the number
FORS trees and leaves in each. The parameters for each of the of FORS trees and leaves in each. The parameters for each of the
security levels were chosen to at least as secure as a generic block security levels were chosen to be at least as secure as a generic
cipher of 128, 192, or 256 bits. block cipher of 128, 192, or 256 bits.
3. SLH-DSA Public Key Identifier 3. SLH-DSA Public Key Identifier
The AlgorithmIdentifier for a SLH-DSA public key MUST use one of the The AlgorithmIdentifier for an SLH-DSA public key MUST use one of the
twelve id-slh-dsa object identifiers listed below, based on the twelve id-slh-dsa object identifiers listed below, based on the
security level used to generate the SLH-DSA hypertree, the small or security level used to generate the SLH-DSA hypertree, the small or
fast version of the algorithm, and the use of SHA2 [FIPS180] or SHAKE fast version of the algorithm, and the use of SHA2 [FIPS180] or SHAKE
[FIPS202]. For example, id-slh-dsa-shake-256s represents the 256-bit [FIPS202]. For example, id-slh-dsa-shake-256s represents the 256-bit
security level, the small version of the algorithm, and the use of security level, the small version of the algorithm, and the use of
SHAKE256. The parameters field of the AlgorithmIdentifier for the SHAKE256. The parameters field of the AlgorithmIdentifier for the
SLH-DSA public key MUST be absent. SLH-DSA public key MUST be absent.
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 7, line 37 skipping to change at line 313
SLH-DSA-PrivateKey ::= OCTET STRING (SIZE (64 | 96 | 128)) SLH-DSA-PrivateKey ::= OCTET STRING (SIZE (64 | 96 | 128))
No additional encoding of the SLH-DSA public key is applied in the No additional encoding of the SLH-DSA public key is applied in the
SubjectPublicKeyInfo field of an X.509 certificate [RFC5280]. SubjectPublicKeyInfo field of an X.509 certificate [RFC5280].
No additional encoding of the SLH-DSA private key is applied in the No additional encoding of the SLH-DSA private key is applied in the
PrivateKeyInfo field of the privateKey field of the OneAsymmetricKey PrivateKeyInfo field of the privateKey field of the OneAsymmetricKey
type of an Asymmetric Key Package [RFC5958]. type of an Asymmetric Key Package [RFC5958].
When a SLH-DSA public key appears outside of a SubjectPublicKeyInfo When an SLH-DSA public key appears outside of a SubjectPublicKeyInfo
type in an environment that uses ASN.1 encoding, the SLH-DSA public type in an environment that uses ASN.1 encoding, the SLH-DSA public
key can be encoded as an OCTET STRING by using the SLH-DSA-PublicKey key can be encoded as an OCTET STRING by using the SLH-DSA-PublicKey
type. type.
When a SLH-DSA private key appears outside of an Asymmetric Key When an SLH-DSA private key appears outside of an Asymmetric Key
Package in an environment that uses ASN.1 encoding, the SLH-DSA Package in an environment that uses ASN.1 encoding, the SLH-DSA
private key can be encoded as an OCTET STRING by using the SLH-DSA- private key can be encoded as an OCTET STRING by using the SLH-DSA-
PrivateKey type. PrivateKey type.
4. Signed-data Conventions 4. Signed-Data Conventions
As specified in CMS [RFC5652], the digital signature is produced from As specified in CMS [RFC5652], the digital signature is produced from
the message digest and the signer's private key. The signature is the message digest and the signer's private key. The signature is
computed over different values depending on whether signed attributes computed over different values depending on whether signed attributes
are absent or present. are absent or present.
When signed attributes are absent, the SLH-DSA (pure mode) signature When signed attributes are absent, the SLH-DSA (pure mode) signature
is computed over the content. When signed attributes are present, a is computed over the content. When signed attributes are present, a
hash MUST be computed over the content using the same hash function hash MUST be computed over the content using the same hash function
that is used in the SLH-DSA tree. The signed attributes MUST include that is used in the SLH-DSA tree. The signed attributes MUST include
a content-type attribute and a message-digest attribute. The a content-type attribute and a message-digest attribute. The
message-digest attribute contains the hash value of the content. The message-digest attribute contains the hash value of the content. The
SLH-DSA signature is computed over the DER encoding of the set of SLH-DSA signature is computed over the DER encoding of the set of
signed attributes. The SLH-DSA signature generation operation is signed attributes. The SLH-DSA signature-generation operation is
called slh_sign; see Section 10.2.1 of [FIPS205]. In summary: called slh_sign; see Section 10.2.1 of [FIPS205]. In summary:
IF (signed attributes are absent) IF (signed attributes are absent)
THEN slh_sign(content) THEN slh_sign(content)
ELSE message-digest attribute = Hash(content); ELSE message-digest attribute = Hash(content);
slh_sign(DER(SignedAttributes)) slh_sign(DER(SignedAttributes))
In some implementations, performance may be significantly improved by In some implementations, performance may be significantly improved by
signing and verifying DER(SignedAttributes) when the content is signing and verifying DER(SignedAttributes) when the content is
large. That is, passing an entire large message content to the large. That is, passing an entire large message content to the
signing function or the signature validation function can have an signing function or the signature validation function can have an
impact on performance. When the signed attributes are present, impact on performance. When the signed attributes are present,
Section 5.3 of [RFC5652] requires the inclusion of the content-type Section 5.3 of [RFC5652] requires the inclusion of the content-type
attribute and the message-digest attribute. Other attributes can attribute and the message-digest attribute. Other attributes can
also be included. also be included.
When using SLH-DSA and signed attributes are present in the When using SLH-DSA and signed attributes are present in the
SignerInfo, the digestAlgorithms field in the SignedData MUST include SignerInfo, the digestAlgorithm field in the SignedData MUST include
the identifier for the one-way hash function used to compute the the identifier for the one-way hash function used to compute the
message digest. message digest.
When using SLH-DSA, the fields in the SignerInfo are used as follows: When using SLH-DSA, the fields in the SignerInfo are used as follows:
digestAlgorithm: digestAlgorithm:
The digestAlgorithm MUST identify a one-way hash function. When The digestAlgorithm MUST identify a one-way hash function. When
signed attributes are absent, the digestAlgorithm identifier MUST signed attributes are absent, the digestAlgorithm identifier MUST
match the hash function used in the SLH-DSA tree (as shown in the match the hash function used in the SLH-DSA tree (as shown in the
list below). When signed attributes are present, to ensure list below). When signed attributes are present, to ensure
collision resistance, the identified hash function MUST produce a collision resistance, the identified hash function MUST produce a
hash value that is at least twice the size of the hash function hash value that is at least twice the size of the hash function
used in the SLH-DSA tree. The hash functions defined in [FIPS180] used in the SLH-DSA tree. The hash functions defined in [FIPS180]
and [FIPS202] MUST be supported for use with the variants of SLH- and [FIPS202] MUST be supported for use with the variants of SLH-
DSA as shown below: DSA as shown below:
id-slh-dsa-sha2-128s: SHA-256 id-slh-dsa-sha2-128s: SHA-256
id-slh-dsa-sha2-128f: SHA-256 id-slh-dsa-sha2-128f: SHA-256
id-slh-dsa-sha2-192s: SHA-512 id-slh-dsa-sha2-192s: SHA-512
id-slh-dsa-sha2-192f: SHA-512 id-slh-dsa-sha2-192f: SHA-512
id-slh-dsa-sha2-256s: SHA-512 id-slh-dsa-sha2-256s: SHA-512
id-slh-dsa-sha2-256f: SHA-512 id-slh-dsa-sha2-256f: SHA-512
id-slh-dsa-shake-128s: SHAKE128 with 256 bit output id-slh-dsa-shake-128s: SHAKE128 with 256-bit output
id-slh-dsa-shake-128f: SHAKE128 with 256 bit output id-slh-dsa-shake-128f: SHAKE128 with 256-bit output
id-slh-dsa-shake-192s: SHAKE256 with 512 bit output id-slh-dsa-shake-192s: SHAKE256 with 512-bit output
id-slh-dsa-shake-192f: SHAKE256 with 512 bit output id-slh-dsa-shake-192f: SHAKE256 with 512-bit output
id-slh-dsa-shake-256s: SHAKE256 with 512 bit output id-slh-dsa-shake-256s: SHAKE256 with 512-bit output
id-slh-dsa-shake-256f: SHAKE256 with 512 bit output id-slh-dsa-shake-256f: SHAKE256 with 512-bit output
The object identifiers for SHA-256 and SHA-512 are included The object identifiers for SHA-256 and SHA-512 are included in
in [RFC5754]. The object identifiers for SHAKE128 and [RFC5754]. The object identifiers for SHAKE128 and SHAKE256 are
SHAKE256 are included in [RFC8702]. In all four cases, the included in [RFC8702]. In all four cases, the AlgorithmIdentifier
AlgorithmIdentifier SHOULD NOT include parameters. SHOULD NOT include parameters.
signatureAlgorithm: signatureAlgorithm:
The signatureAlgorithm MUST contain one of the the SLH-DSA The signatureAlgorithm MUST contain one of the SLH-DSA algorithm
algorithm identifiers, and the algorithm parameters field MUST be identifiers, and the algorithm parameters field MUST be absent.
absent. The algorithm identifier MUST be one of the following: The algorithm identifier MUST be one of the following:
id-slh-dsa-sha2-128s, id-slh-dsa-sha2-128f, id-slh-dsa-sha2-128s, id-slh-dsa-sha2-128f,
id-slh-dsa-sha2-192s, id-slh-dsa-sha2-192f, id-slh-dsa-sha2-192s, id-slh-dsa-sha2-192f,
id-slh-dsa-sha2-256s, id-slh-dsa-sha2-256f, id-slh-dsa-sha2-256s, id-slh-dsa-sha2-256f,
id-slh-dsa-shake-128s, id-slh-dsa-shake-128f, id-slh-dsa-shake-128s, id-slh-dsa-shake-128f,
id-slh-dsa-shake-192s, id-slh-dsa-shake-192f, id-slh-dsa-shake-192s, id-slh-dsa-shake-192f,
id-slh-dsa-shake-256s, id-slh-dsa-shake-256f. id-slh-dsa-shake-256s, id-slh-dsa-shake-256f.
signature: signature:
The signature contains the signature value resulting from the SLH- The signature contains the signature value resulting from the SLH-
DSA signing operation with the parameters associated with the DSA signing operation with the parameters associated with the
selected signatureAlgorithm. The SLH-DSA signature generation selected signatureAlgorithm. The SLH-DSA signature-generation
operation is specified in Section 10.2.1 of [FIPS205], and the operation is specified in Section 10.2.1 of [FIPS205], and the
SLH-DSA signature verification operation is specified in SLH-DSA signature verification operation is specified in
Section 10.3 of [FIPS205]. Signature verification MUST include Section 10.3 of [FIPS205]. Signature verification MUST include
checking that the signatureAlgorithm field identifies SLH-DSA checking that the signatureAlgorithm field identifies SLH-DSA
parameters that are consistent with public key used to validate parameters that are consistent with public key used to validate
the signature. the signature.
5. Security Considerations 5. Security Considerations
Implementations MUST protect the private keys. Compromise of the Implementations MUST protect the private keys. Compromise of the
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.
A SLH-DSA tree MUST NOT be used for more than 2^64 signing A 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
force searching the whole key space. The generation of quality brute-force searching the whole key space. The generation of quality
random numbers is difficult, and [RFC4086] offers important guidance random numbers is difficult, and [RFC4086] offers important guidance
in this area. in this area.
To avoid algorithm substitution attacks, the CMSAlgorithmProtection To avoid algorithm-substitution attacks, the CMSAlgorithmProtection
attribute defined in [RFC6211] SHOULD be included in signed attribute defined in [RFC6211] SHOULD be included in signed
attributes. attributes.
Implementers should consider their particular use cases and may Implementers should consider their particular use cases and may
choose to implement optional fault attack countermeasures [CMP2018] choose to implement optional fault-attack countermeasures [CMP2018]
[Ge2023]. Verifying a signature before releasing the signature value [Ge2023]. Verifying a signature before releasing the signature value
is a typical fault attack countermeasure; however, this is a typical fault-attack countermeasure; however, this
countermeasure is not effective for SLH-DSA [Ge2023]. Redundancy by countermeasure is not effective for SLH-DSA [Ge2023]. Redundancy by
replicating the signature generation process MAY be used as an replicating the signature-generation process MAY be used as an
effective fault attack countermeasure for SLH-DSA [Ge2023]; however, effective fault-attack countermeasure for SLH-DSA [Ge2023]; however,
the SLH-DSA signature generation is already considered slow. the SLH-DSA signature generation is already considered slow.
Likewise, Implementers should consider their particular use cases and Likewise, implementers should consider their particular use cases and
may choose to implement protections against passive power and may choose to implement protections against passive power and
emissions side-channel attacks [SLotH]. emissions side-channel attacks [SLotH].
6. Operational Considerations 6. Operational Considerations
If slh_sign is implemented in a hardware device such as hardware If slh_sign is implemented in a hardware device such as Hardware
security module (HSM) or portable cryptographic token, Security Module (HSM) or portable cryptographic token,
implementations can avoid sending the full content to the device. By implementations can avoid sending the full content to the device. By
including signed attributes, which necessarily include the message- including signed attributes, which necessarily include the message-
digest attribute and the content-type attribute as described in digest attribute and the content-type attribute as described in
Section 5.3 of [RFC5652], the much smaller set of signed attributes Section 5.3 of [RFC5652], the much smaller set of signed attributes
are sent to the device for signing. are sent to the device for signing.
By including signed attributes in the SignerInfo, one can obtain By including signed attributes in the SignerInfo, one can obtain
similar interface characteristics to SLH-DSA in pre-hash mode. With similar interface characteristics to SLH-DSA in pre-hash mode. With
pre-hash mode, the hash of the content is passed to the SLH-DSA pre-hash mode, the hash of the content is passed to the SLH-DSA
signature operation instead of the full message content. By signature operation instead of the full message content. By
skipping to change at page 11, line 23 skipping to change at line 485
of stream-based APIs, implementers SHOULD include signed attributes of stream-based APIs, implementers SHOULD include signed attributes
within any SignerInfo that uses SLH-DSA as signature algorithm. within any SignerInfo that uses SLH-DSA as signature algorithm.
Doing so allows the recipient implementation to avoid keeping the Doing so allows the recipient implementation to avoid keeping the
signed content in memory. Recall that when signed attributes are signed content in memory. Recall that when signed attributes are
present, they MUST contain a content-type attribute and a message- present, they MUST contain a content-type attribute and a message-
digest attribute, and they SHOULD contain a CMSAlgorithmProtection digest attribute, and they SHOULD contain a CMSAlgorithmProtection
attribute. attribute.
7. IANA Considerations 7. IANA Considerations
For the ASN.1 Module in the Appendix of this document, IANA is For the ASN.1 Module in Appendix A, IANA has assigned an Object
requested to assign an object identifier (OID) for the module Identifier (OID) for the module identifier (81) with a Description of
identifier (TBD1) with a Description of "id-mod-slh-dsa-2024". The "id-mod-slh-dsa-2024". The OID for the module has been allocated in
OID for the module should be allocated in the "SMI Security for S/ the "SMI Security for S/MIME Module Identifier
MIME Module Identifier" (1.2.840.113549.1.9.16.0). (1.2.840.113549.1.9.16.0)" registry.
8. References 8. References
8.1. Normative References 8.1. Normative References
[FIPS180] National Institute of Standards and Technology (NIST), [FIPS180] National Institute of Standards and Technology (NIST),
"Secure Hash Standard (SHS)", FIPS PUB 180-4, August 2015. "Secure Hash Standard (SHS)", NIST FIPS 180-4,
DOI 10.6028/NIST.FIPS.180-4, August 2015,
<https://doi.org/10.6028/NIST.FIPS.180-4>.
[FIPS202] National Institute of Standards and Technology (NIST), [FIPS202] National Institute of Standards and Technology (NIST),
"SHA-3 Standard: Permutation-Based Hash and Extendable- "SHA-3 Standard: Permutation-Based Hash and Extendable-
Output Functions", FIPS PUB 202, August 2015. Output Functions", NIST FIPS 202,
DOI 10.6028/NIST.FIPS.202, August 2015,
<https://doi.org/10.6028/NIST.FIPS.202>.
[FIPS205] National Institute of Standards and Technology (NIST), [FIPS205] National Institute of Standards and Technology (NIST),
"Stateless Hash-Based Digital Signature Standard", FIPS "Stateless Hash-Based Digital Signature Standard", NIST
PUB 205, 13 August 2024, FIPS 205, DOI 10.6028/NIST.FIPS.205, 13 August 2024,
<https://doi.org/10.6028/NIST.FIPS.205>. <https://doi.org/10.6028/NIST.FIPS.205>.
[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>.
[RFC5652] Housley, R., "Cryptographic Message Syntax (CMS)", STD 70, [RFC5652] Housley, R., "Cryptographic Message Syntax (CMS)", STD 70,
RFC 5652, DOI 10.17487/RFC5652, September 2009, RFC 5652, DOI 10.17487/RFC5652, September 2009,
<https://www.rfc-editor.org/rfc/rfc5652>. <https://www.rfc-editor.org/info/rfc5652>.
[RFC5754] Turner, S., "Using SHA2 Algorithms with Cryptographic [RFC5754] Turner, S., "Using SHA2 Algorithms with Cryptographic
Message Syntax", RFC 5754, DOI 10.17487/RFC5754, January Message Syntax", RFC 5754, DOI 10.17487/RFC5754, January
2010, <https://www.rfc-editor.org/rfc/rfc5754>. 2010, <https://www.rfc-editor.org/info/rfc5754>.
[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>.
[RFC6211] Schaad, J., "Cryptographic Message Syntax (CMS) Algorithm [RFC6211] Schaad, J., "Cryptographic Message Syntax (CMS) Algorithm
Identifier Protection Attribute", RFC 6211, Identifier Protection Attribute", RFC 6211,
DOI 10.17487/RFC6211, April 2011, DOI 10.17487/RFC6211, April 2011,
<https://www.rfc-editor.org/rfc/rfc6211>. <https://www.rfc-editor.org/info/rfc6211>.
[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>.
[RFC8702] Kampanakis, P. and Q. Dang, "Use of the SHAKE One-Way Hash [RFC8702] Kampanakis, P. and Q. Dang, "Use of the SHAKE One-Way Hash
Functions in the Cryptographic Message Syntax (CMS)", Functions in the Cryptographic Message Syntax (CMS)",
RFC 8702, DOI 10.17487/RFC8702, January 2020, RFC 8702, DOI 10.17487/RFC8702, January 2020,
<https://www.rfc-editor.org/rfc/rfc8702>. <https://www.rfc-editor.org/info/rfc8702>.
[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 -- ASN.1 encoding rules: [X690] ITU-T, "Information technology -- ASN.1 encoding rules:
Specification of Basic Encoding Rules (BER), Canonical Specification of Basic Encoding Rules (BER), Canonical
Encoding Rules (CER) and Distinguished Encoding Rules Encoding Rules (CER) and Distinguished Encoding Rules
(DER)", ITU-T Recommendation X.690, ISO/IEC 8825-1-2021, (DER)", ITU-T Recommendation X.690, ISO/IEC 8825-1-2021,
February 2021, <https://www.itu.int/rec/T-REC-X.690>. February 2021, <https://www.itu.int/rec/T-REC-X.690>.
8.2. Informative References 8.2. Informative References
[CMP2018] Castelnovi, L., Martinelli, A., 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",
Post-Quantum Cryptography pp. 165-184, PQCrypto 2018, Post-Quantum Cryptography (PQCrypto 2018), Lecture Notes
Lecture Notes in Computer Science vol 10786, 2018, in Computer Science, vol. 10786, pp. 165-184,
DOI 10.1007/978-3-319-79063-3_8, 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>.
[Ge2023] Genêt, A., "On Protecting SPHINCS+ Against Fault Attacks", [Ge2023] Genêt, A., "On Protecting SPHINCS+ Against Fault Attacks",
TCHES 2023/02, DOI 10.46586/tches.v2023.i2.80-114, 2023, IACR Transactions on Cryptographic Hardware and Embedded
Systems, vol. 2023, no. 2, pp. 80-114,
DOI 10.46586/tches.v2023.i2.80-114, 2023,
<https://tches.iacr.org/index.php/TCHES/article/ <https://tches.iacr.org/index.php/TCHES/article/
view/10278/9726>. view/10278/9726>.
[RFC4086] Eastlake 3rd, D., Schiller, J., and S. Crocker, [RFC4086] Eastlake 3rd, D., Schiller, J., and S. Crocker,
"Randomness Requirements for Security", BCP 106, RFC 4086, "Randomness Requirements for Security", BCP 106, RFC 4086,
DOI 10.17487/RFC4086, June 2005, DOI 10.17487/RFC4086, June 2005,
<https://www.rfc-editor.org/rfc/rfc4086>. <https://www.rfc-editor.org/info/rfc4086>.
[RFC5911] Hoffman, P. and J. Schaad, "New ASN.1 Modules for [RFC5911] Hoffman, P. and J. Schaad, "New ASN.1 Modules for
Cryptographic Message Syntax (CMS) and S/MIME", RFC 5911, Cryptographic Message Syntax (CMS) and S/MIME", RFC 5911,
DOI 10.17487/RFC5911, June 2010, DOI 10.17487/RFC5911, June 2010,
<https://www.rfc-editor.org/rfc/rfc5911>. <https://www.rfc-editor.org/info/rfc5911>.
[RFC8391] Huelsing, A., Butin, D., Gazdag, S., Rijneveld, J., and A. [RFC8391] Huelsing, A., Butin, D., Gazdag, S., Rijneveld, J., and A.
Mohaisen, "XMSS: eXtended Merkle Signature Scheme", Mohaisen, "XMSS: eXtended Merkle Signature Scheme",
RFC 8391, DOI 10.17487/RFC8391, May 2018, RFC 8391, DOI 10.17487/RFC8391, May 2018,
<https://www.rfc-editor.org/rfc/rfc8391>. <https://www.rfc-editor.org/info/rfc8391>.
[RFC8554] McGrew, D., Curcio, M., and S. Fluhrer, "Leighton-Micali [RFC8554] McGrew, D., Curcio, M., and S. Fluhrer, "Leighton-Micali
Hash-Based Signatures", RFC 8554, DOI 10.17487/RFC8554, Hash-Based Signatures", RFC 8554, DOI 10.17487/RFC8554,
April 2019, <https://www.rfc-editor.org/rfc/rfc8554>. April 2019, <https://www.rfc-editor.org/info/rfc8554>.
[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
Archive, Paper 2024/367, 2024,
<https://eprint.iacr.org/2024/367.pdf>. <https://eprint.iacr.org/2024/367.pdf>.
Appendix A. ASN.1 Module Appendix A. ASN.1 Module
This ASN.1 Module builds upon the conventions established in This ASN.1 Module builds upon the conventions established in
[RFC5911]. [RFC5911].
<CODE BEGINS> <CODE BEGINS>
SLH-DSA-Module-2024 SLH-DSA-Module-2024
{ 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(TBD1) } id-smime(16) id-mod(0) id-mod-slh-dsa-2024(81) }
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 [RFC5911] FROM AlgorithmInformation-2009 -- in [RFC5911]
{ 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)
 End of changes. 56 change blocks. 
147 lines changed or deleted 155 lines changed or added

This html diff was produced by rfcdiff 1.48.