]> Vigil Security, LLC

housley@vigilsec.com

Cisco Systems

sfluhrer@cisco.com

Amazon Web Services

kpanos@amazon.com

Cloudflare

bas@westerbaan.name

Security Internet-Draft SLH-DSA is a stateless hash-based signature scheme. This document specifies the conventions for using the SLH-DSA signature algorithm with the Cryptographic Message Syntax (CMS). In addition, the algorithm identifier and public key syntax are provided.

Introduction NOTICE: This document will be adjusted to match the final FIPS 205 specification that is published by NIST. Until that happens, just about everything in this document is likely to change. This document specifies the conventions for using the SLH-DSA hash-based signature algorithm with the Cryptographic Message Syntax (CMS) signed-data content type. SLH-DSA offers three security levels. The parameters for each of the security levels were chosen to provide 128 bits of security, 192 bits of security, and 256 bits of security. A separate algorithm identifier has been assigned for SLH-DSA at each of these security levels. SLH-DSA is a stateless hash-based signature algorithm. Other hash-based signature algorithms are stateful, including HSS/LMS and XMSS . Without the need for state kept by the signer, SLH-DSA is much less fragile.

ASN.1 CMS values are generated using ASN.1 , using the Basic Encoding Rules (BER) and the Distinguished Encoding Rules (DER) .

Motivation There have been recent advances in cryptanalysis and advances in the development of quantum computers. Each of these advances pose a threat to widely deployed digital signature. If large-scale quantum computers are ever built, they will be able to break many of the public-key cryptosystems currently in use, including RSA, DSA, ECDSA, and EdDSA. A post-quantum cryptosystem (PQC) is secure against quantum computers that have more than a trivial number of quantum bits (qu-bits). It is open to conjecture when it will be feasible to build such quantum computers; however, it is prudent to use cryptographic algorithms that remain secure if a large-scale quantum computer is invented. SLH-DSA is a PQC signature algorithm. One use of a PQC signature algoritm is the protection of software updates, perhaps using the format described in , to enable deployment of software that implements other new PQC algorithms for key management and confidentiality.

Terminology The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in BCP 14 when, and only when, they appear in all capitals, as shown here.

SLH-DSA Hash-based Signature Algorithm Overview SLH-DSA is a hash-based signature scheme which consists of a few time signature construction, namely Forest of Random Subsets (FORS) and a hypertree. FORS signs a message with a private key. 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-DSA uses a one-time signature scheme called WOTS+. The FORS tree roots are signed by a WOTS+ one-time signature private key. The corresponding WOTS+ public keys form the leaves in d-layers of Merkle subtrees in the SLH-DSA hypertree. The bottom layer of that hypertree signs the FORS roots with WOTS+. The root of the bottom Merkle subtrees are then signed with WOTS+ and the corresponding WOTS+ public keys form the leaves of the next level up subtree. Subtree roots are consequently signed by their corresponding subtree layers until we reach the top subtree. 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 signature, the WOTS+ signature in each layer, and the path to the root of each subtree until the root of the hypertree is reached. A SLH-DSA signature is verified by verifying the FORS signature, the WOTS+ signatures and the path to the root of each subtree. When reaching the root of the hypertree, the signature verifies only if it hashes to the pre-trusted root of the SLH-DSA hypertree. SLH-DSA is a stateless hash-based signature algorithm. Stateful hash-based signature schemes require that the WOTS+ private key (generated by using a state index) is never reused or the scheme loses it security. Although its security decreases, FORS which is 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 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 fragile. 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 parameter, the hash function, the tree height, the number of layers of subtrees, the Winternitz parameter of WOTS+, the number of FORS trees and leaves in each. The parameters for each of the security levels were chosen to provide 128 bits of security, 192 bits of security, and 256 bits of security.

SLH-DSA Public Key Identifier The AlgorithmIdentifier for a SLH-DSA public key MUST use one of the eight id-alg-slh-dsa object identifiers listed below, based on the security level used to generate the SLH-DSA hypertree, the small or fast version of the algorithm, and the use of SHA-256 or SHAKE256 . For example, id-alg-slh-dsa-256s-shake represents the 256-bit security level, the small version of the algorithm, and the use of SHAKE256. The parameters field of the AlgorithmIdentifier for the SLH-DSA public key MUST be absent. When this AlgorithmIdentifier appears in the SubjectPublicKeyInfo field of an X.509 certificate , the certificate key usage extension MAY contain digitalSignature, nonRepudiation, keyCertSign, and cRLSign; the certificate key usage extension MUST NOT contain other values. NOTE: The values for these object identifiers will be assigned by NIST. Once assigned, they will be added to a future revision of this document. The SLH-DSA public key value is an OCTET STRING. The SLA-DSA private key value is an OCTET STRING.

Signed-data Conventions As specified in CMS , the digital signature is produced from the message digest and the signer's private key. The signature is computed over different values depending on whether signed attributes are absent or present. When signed attributes are absent, the SLH-DSA signature is computed over the content. When signed attributes are present, a hash is computed over the content using the same hash function that is used in the SLH-DSA tree, and then a message-digest attribute is constructed to contain the resulting hash value, and then the result of DER encoding the set of signed attributes, which MUST include a content-type attribute and a message-digest attribute, and then the SLH-DSA signature is computed over the DER-encoded output. The SLH-DSA signature generation operation is called slh_sign; see Section 9.2 of . In summary: When using SLH-DSA, the fields in the SignerInfo are used as follows:

digestAlgorithm:

The digestAlgorithm MUST contain the one-way hash function used to in the SLH-DSA tree. The algorithm identifiers for and are repeated below for convenience.

signatureAlgorithm:

The signatureAlgorithm MUST contain one of the the SLH-DSA algorithm identifiers, and the algorithm parameters field MUST be absent. The algorithm identifier MUST be one of the following: id-alg-slh-dsa-128s-shake, id-alg-slh-dsa-128f-shake, id-alg-slh-dsa-128s-sha2, id-alg-slh-dsa-128f-sha2, id-alg-slh-dsa-192s-shake, id-alg-slh-dsa-192f-shake, id-alg-slh-dsa-256s-shake, or id-alg-slh-dsa-256f-shake.

signature:

The signature contains the signature value resulting from the SLH-DSA signing operation with the parameters associated with the selected signatureAlgorithm. The SLH-DSA signing operation and the signature verification operation are specified in .

Security Considerations Implementations MUST protect the private keys. Compromise of the private keys may result in the ability to forge signatures. When generating an SLH-DSA key pair, an implementation MUST generate each key pair independently of all other key pairs in the SLH-DSA hypertree. A SLH-DSA tree MUST NOT be used for more than 2^64 signing operations. The generation of private keys relies on random numbers. The use of inadequate pseudo-random number generators (PRNGs) to generate these values can result in little or no security. An attacker may find it much easier to reproduce the PRNG environment that produced the keys, searching the resulting small set of possibilities, rather than brute force searching the whole key space. The generation of quality random numbers is difficult, and offers important guidance in this area. When computing signatures, the same hash function SHOULD be used to compute the message digest of the content and the signed attributes, if they are present. When computing signatures, implementations SHOULD include protections against fault injection attacks . Protections against these attacks include signature verification prior to releasing the signature value to confirm that no error injected and generating the signature a few times to confirm that the same signature value is produced each time.

Operational Considerations If slh_sign is implemented in a hardware device such as hardware security module (HSM) or portable cryptographic token, implementations might want to avoid is sending the full content to the device. By including signed attributes, which necessarily include the message-digest attribute and the content-type attribute as described in , the much smaller set of signed attributes are sent to the device for signing.

IANA Considerations For the ASN.1 Module in the Appendix of this document, IANA is requested to assign an object identifier (OID) for the module identifier (TBD1) with a Description of "id-mod-slh-dsa-2023". The OID for the module should be allocated in the "SMI Security for PKIX Module Identifier" registry (1.3.6.1.5.5.7.0).

Acknowledgements Thanks to Mike Ounsworth and Tomas Gustavsson for their careful review and constructive comments.

References Normative References National Institute of Standards and Technology (NIST) This memo profiles the X.509 v3 certificate and X.509 v2 certificate revocation list (CRL) for use in the Internet. An overview of this approach and model is provided as an introduction. The X.509 v3 certificate format is described in detail, with additional information regarding the format and semantics of Internet name forms. Standard certificate extensions are described and two Internet-specific extensions are defined. A set of required certificate extensions is specified. The X.509 v2 CRL format is described in detail along with standard and Internet-specific extensions. An algorithm for X.509 certification path validation is described. An ASN.1 module and examples are provided in the appendices. [STANDARDS-TRACK] This document describes the Cryptographic Message Syntax (CMS). This syntax is used to digitally sign, digest, authenticate, or encrypt arbitrary message content. [STANDARDS-TRACK] ITU-T ITU-T In many standards track documents several words are used to signify the requirements in the specification. These words are often capitalized. This document defines these words as they should be interpreted in IETF documents. This document specifies an Internet Best Current Practices for the Internet Community, and requests discussion and suggestions for improvements. RFC 2119 specifies common key words that may be used in protocol specifications. This document aims to reduce the ambiguity by clarifying that only UPPERCASE usage of the key words have the defined special meanings. Informative References Security systems are built on strong cryptographic algorithms that foil pattern analysis attempts. However, the security of these systems is dependent on generating secret quantities for passwords, cryptographic keys, and similar quantities. The use of pseudo-random processes to generate secret quantities can result in pseudo-security. A sophisticated attacker may find it easier to reproduce the environment that produced the secret quantities and to search the resulting small set of possibilities than to locate the quantities in the whole of the potential number space. Choosing random quantities to foil a resourceful and motivated adversary is surprisingly difficult. This document points out many pitfalls in using poor entropy sources or traditional pseudo-random number generation techniques for generating such quantities. It recommends the use of truly random hardware techniques and shows that the existing hardware on many systems can be used for this purpose. It provides suggestions to ameliorate the problem when a hardware solution is not available, and it gives examples of how large such quantities need to be for some applications. This document specifies an Internet Best Current Practices for the Internet Community, and requests discussion and suggestions for improvements. This document describes the use of the Cryptographic Message Syntax (CMS) to protect firmware packages, which provide object code for one or more hardware module components. CMS is specified in RFC 3852. A digital signature is used to protect the firmware package from undetected modification and to provide data origin authentication. Encryption is optionally used to protect the firmware package from disclosure, and compression is optionally used to reduce the size of the protected firmware package. A firmware package loading receipt can optionally be generated to acknowledge the successful loading of a firmware package. Similarly, a firmware package load error report can optionally be generated to convey the failure to load a firmware package. [STANDARDS-TRACK] The Cryptographic Message Syntax (CMS) format, and many associated formats, are expressed using ASN.1. The current ASN.1 modules conform to the 1988 version of ASN.1. This document updates those ASN.1 modules to conform to the 2002 version of ASN.1. There are no bits-on-the-wire changes to any of the formats; this is simply a change to the syntax. This document is not an Internet Standards Track specification; it is published for informational purposes. This note describes a digital-signature system based on cryptographic hash functions, following the seminal work in this area of Lamport, Diffie, Winternitz, and Merkle, as adapted by Leighton and Micali in 1995. It specifies a one-time signature scheme and a general signature scheme. These systems provide asymmetric authentication without using large integer mathematics and can achieve a high security level. They are suitable for compact implementations, are relatively simple to implement, and are naturally resistant to side-channel attacks. Unlike many other signature systems, hash-based signatures would still be secure even if it proves feasible for an attacker to build a quantum computer. This document is a product of the Crypto Forum Research Group (CFRG) in the IRTF. This has been reviewed by many researchers, both in the research group and outside of it. The Acknowledgements section lists many of them. This note describes the eXtended Merkle Signature Scheme (XMSS), a hash-based digital signature system that is based on existing descriptions in scientific literature. This note specifies Winternitz One-Time Signature Plus (WOTS+), a one-time signature scheme; XMSS, a single-tree scheme; and XMSS^MT, a multi-tree variant of XMSS. Both XMSS and XMSS^MT use WOTS+ as a main building block. XMSS provides cryptographic digital signatures without relying on the conjectured hardness of mathematical problems. Instead, it is proven that it only relies on the properties of cryptographic hash functions. XMSS provides strong security guarantees and is even secure when the collision resistance of the underlying hash function is broken. It is suitable for compact implementations, is relatively simple to implement, and naturally resists side-channel attacks. Unlike most other signature systems, hash-based signatures can so far withstand known attacks using quantum computers. National Institute of Standards and Technology (NIST) National Institute of Standards and Technology (NIST)

Appendix: ASN.1 Module This ASN.1 Module builds upon the conventions established in .