]> BSI

kaveh.bashiri.ietf@gmail.com

Cisco Systems

sfluhrer@cisco.com

genua GmbH

ietf@gazdag.de

CryptoNext Security

daniel.vangeest@cryptonext-security.com

BSI

kousidis.ietf@gmail.com

sec LAMPS - Limited Additional Mechanisms for PKIX and SMIME SLH-DSA SPHINCS+ PQ Signatures post-quantum X.509 Digital signatures are used within X.509 Public Key Infrastructure such as X.509 certificates, Certificate Revocation Lists (CRLs), and to sign messages. This document describes the conventions for using the Stateless Hash-Based Digital Signature Algorithm (SLH-DSA) in X.509 Public Key Infrastructure. The conventions for the associated signatures, subject public keys, and private keys are also described. About This Document Status information for this document may be found at . Discussion of this document takes place on the LAMPS Working Group mailing list (), which is archived at . Subscribe at . Source for this draft and an issue tracker can be found at .

Introduction The Stateless Hash-Based Digital Signature Algorithm (SLH-DSA) is a quantum-resistant digital signature scheme standardized in by the US National Institute of Standards and Technology (NIST) PQC project . Prior to standardization, the algorithm was known as SPHINCS+. SLH-DSA and SPHINCS+ are not compatible. This document defines the ASN.1 Object Identifiers (OIDs) and conventions for the encoding of SLH-DSA 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 security levels were chosen to be at least as secure as a generic block cipher of 128, 192, or 256 bits. There are small (s) and fast (f) versions of the algorithm, and the option to use SHA-256 or SHAKE256 as internal hash functions. While the fast versions are optimized for key generation and signing speed, they are actually slower at verification than the SLH-DSA small parameter sets. For example, id-slh-dsa-shake-256s represents the 256-bit security level, the small version of the algorithm, and the use of SHAKE256. Separate algorithm identifiers have been assigned for SLH-DSA at each of these security levels, fast vs small, and SHA-256 vs SHAKE256. 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 is the empty string. This document only specifies the use of the empty context string for use in the X.509 Public Key Infrastructure. SLH-DSA offers two signature modes: pure mode, where the entire content is signed directly, and pre-hash mode, where a digest of the content is signed. This document uses the term SLH-DSA to refer to the algorithm in general. When a pure or pre-hash mode needs to be differentiated, the terms Pure SLH-DSA and HashSLH-DSA are used. This document specifies the use of Pure SLH-DSA in Public Key Infrastructure X.509 (PKIX) certificates and Certificate Revocation Lists (CRLs) as well as the use of HashSLH-DSA public keys only in end-entity certificates.

Conventions and Definitions 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.

Algorithm Identifiers The AlgorithmIdentifier type, is defined as follows: The fields in AlgorithmIdentifier have the following meanings:

• algorithm identifies the cryptographic algorithm with an object identifier.
• parameters, which are optional, are the associated parameters for the algorithm identifier in the algorithm field.

The object identifiers for SLH-DSA are defined in the NIST Computer Security Objects Register , and are reproduced here for convenience. The same OID is used to identify an SLH-DSA public key and its associated signature algorithm. The Pure SLH-DSA OIDs are: The HashSLH-DSA OIDs are: The contents of the parameters component for each algorithm MUST be absent.

SLH-DSA Signatures SLH-DSA is a digital signature scheme built upon hash functions. The security of SLH-DSA relies on the presumed difficulty of finding preimages for hash functions as well as several related properties of the same hash functions. Signatures can be placed in a number of different ASN.1 structures. The top level structure for a certificate is given below as being illustrative of how signatures are frequently encoded with an algorithm identifier and a location for the signature. The same algorithm identifiers are used for signatures as are used for public keys. When used to identify signature algorithms, the parameters MUST be absent. The data to be signed is prepared for SLH-DSA. Then, a private key operation is performed to generate the raw signature value. Section 9.2 of defines an SLH-DSA signature as three elements, R, SIG_FORS and SIG_HT. The raw octet string encoding of an SLH-DSA public key is the concatenation of these three elements, i.e. R || SIG_FORS || SIG_HT. The raw octet string representing the signature is encoded directly in the BIT STRING without adding any additional ASN.1 wrapping. For example, in the Certificate structure, the raw signature value is encoded in the "signatureValue" BIT STRING field. This document does not define the use of HashSLH-DSA to sign certificates or CRLs, but it does allow the use of HashSLH-DSA public keys in end-entity certificates for use by protocols that may need pre-hashing. Pre-hashing is performed using the hash algorithm or XOF specified after "with" in the object identifier string. For example, SHA-256 is used for pre-hashing with id-hash-slh-dsa-sha2-128s-with-sha256. When pre-hashing is performed using SHAKE128, the output length is 256 bits. When pre-hashing is performed using SHAKE256, the output length is 512 bits.

Subject Public Key Fields In the X.509 certificate, the subjectPublicKeyInfo field has the SubjectPublicKeyInfo type, which has the following ASN.1 syntax: The fields in SubjectPublicKeyInfo have the following meanings:

• algorithm is the algorithm identifier and parameters for the public key (see above).
• subjectPublicKey contains the byte stream of the public key.

defines the following public key identifiers for Pure SLH-DSA: The public key identifiers for HashSLH-DSA are defined here: Section 9.1 of defines an SLH-DSA public key as two n-byte elements, PK.seed and PK.root. The raw octet string encoding of an SLH-DSA public key is the concatenation of these two elements, i.e. PK.seed || PK.root. The octet string length is 2*n bytes, where n is 16, 24, or 32, depending on the SLH-DSA parameter set. When used in a SubjectPublicKeyInfo type, the subjectPublicKey BIT STRING contains the raw octet string encoding of the public key. defines the SLH-DSA-PublicKey and SLH-DSA-PrivateKey ASN.1 OCTET STRING types to provide an option for encoding a Pure SLH-DSA public or private key in an environment that uses ASN.1 encoding but doesn't define its own mapping of an SLH-DSA raw octet string to ASN.1. HashSLH-DSA public and private keys can use SLH-DSA-PublicKey and SLH-DSA-PrivateKey in the same way. To map an SLH-DSA-PublicKey OCTET STRING to a SubjectPublicKeyInfo, the OCTET STRING is mapped to the subjectPublicKey field (a value of type BIT STRING) as follows: the most significant bit of the OCTET STRING value becomes the most significant bit of the BIT STRING value, and so on; the least significant bit of the OCTET STRING becomes the least significant bit of the BIT STRING. The AlgorithmIdentifier for an SLH-DSA public key MUST use one of the id-slh-dsa-* or id-hash-slh-dsa-* object identifiers from . The parameters field of the AlgorithmIdentifier for the SLH-DSA public key MUST be absent. contains an example of an id-slh-dsa-sha2-128s public key encoded using the textual encoding defined in .

Key Usage Bits The intended application for the key is indicated in the keyUsage certificate extension; see . If the keyUsage extension is present in a certificate that indicates an id-slh-dsa-* (Pure SLH-DSA) identifier in the SubjectPublicKeyInfo, then at least one of the following MUST be present: If the keyUsage extension is present in a certificate that indicates an id-slh-dsa-* (Pure SLH-DSA) identifier in the SubjectPublicKeyInfo, then the following MUST NOT be present: If the keyUsage extension is present in a certificate that indicates an id-hash-slh-dsa-* (HashSLH-DSA) identifier in the SubjectPublicKeyInfo, then at least one of the following MUST be present: If the keyUsage extension is present in a certificate that indicates an id-hash-slh-dsa-* (HashSLH-DSA) identifier in the SubjectPublicKeyInfo, then the following MUST NOT be present: Requirements about the keyUsage extension bits defined in still apply.

Private Key Format "Asymmetric Key Packages" describes how to encode a private key in a structure that both identifies what algorithm the private key is for and optionally allows for the public key and additional attributes about the key to be included as well. For illustration, the ASN.1 structure OneAsymmetricKey is replicated below. Section 9.1 of defines an SLH-DSA private key as four n-byte elements, SK.seed, SK.prf, PK.seed and PK.root. The raw octet string encoding of an SLH-DSA private key is the concatenation of these four elements, i.e. SK.seed || SK.prf || PK.seed || PK.root. The octet string length is 4*n bytes, where n is 16, 24, or 32, depending on the SLH-DSA parameter set. When used in a OneAsymmetricKey type, the privateKey OCTET STRING contains the raw octet string encoding of the private key. When an SLH-DSA public key is included in a OneAsymmetricKey type, it is encoded in the same manner as in a SubjectPublicKeyInfo type. That is, the publicKey BIT STRING contains the raw octet string encoding of the public key. contains an example of an id-slh-dsa-sha2-128s private key encoded using the textual encoding defined in . NOTE: There exist some private key import functions that have not picked up the new ASN.1 structure OneAsymmetricKey that is defined in . This means that they will not accept a private key structure that contains the public key field. This means a balancing act needs to be done between being able to do a consistency check on the key pair and widest ability to import the key.

Security Considerations The security considerations of apply accordingly. Implementations MUST protect the private keys. Compromise of the private keys may result in the ability to forge signatures. When generating an SLH-DSA key pair, an implementation MUST generate each key pair independently of all other key pairs in the SLH-DSA hypertree. An SLH-DSA tree MUST NOT be used for more than 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. Implementers SHOULD consider their particular use cases and may choose to implement OPTIONAL fault attack countermeasures ,. Verifying a signature before releasing the signature value is a typical fault attack countermeasure; however, this countermeasure is not effective for SLH-DSA . Redundancy by replicating the signature generation process can be used as an effective fault attack countermeasure for SLH-DSA ; however, the SLH-DSA signature generation is already considered slow. Likewise, Implementers SHOULD consider their particular use cases and may choose to implement protections against passive power and emissions side-channel attacks .

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-x509-slh-dsa-2024". 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).

References Normative References ITU-T ITU-T National Institute of Standards and Technology 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. 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] Vigil Security, LLC Cisco Systems Amazon Web Services Cloudflare 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. This document defines the syntax for private-key information and a content type for it. Private-key information includes a private key for a specified public-key algorithm and a set of attributes. The Cryptographic Message Syntax (CMS), as defined in RFC 5652, can be used to digitally sign, digest, authenticate, or encrypt the asymmetric key format content type. This document obsoletes RFC 5208. [STANDARDS-TRACK] Informative References National Institute of Standards and Technology n.d. Information Technology Laboratory National Institute of Standards and Technology

US Gaithersburg

National Institute of Standards and Technology Information Technology Laboratory National Institute of Standards and Technology

US Gaithersburg

The Public Key Infrastructure using X.509 (PKIX) certificate 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 document describes and discusses the textual encodings of the Public-Key Infrastructure X.509 (PKIX), Public-Key Cryptography Standards (PKCS), and Cryptographic Message Syntax (CMS). The textual encodings are well-known, are implemented by several applications and libraries, and are widely deployed. This document articulates the de facto rules by which existing implementations operate and defines them so that future implementations can interoperate. 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 specifies algorithm identifiers and ASN.1 encoding formats for elliptic curve constructs using the curve25519 and curve448 curves. The signature algorithms covered are Ed25519 and Ed448. The key agreement algorithms covered are X25519 and X448. The encoding for public key, private key, and Edwards-curve Digital Signature Algorithm (EdDSA) structures is provided. AWS AWS sn3rd Cloudflare Digital signatures are used within X.509 certificates, Certificate Revocation Lists (CRLs), and to sign messages. This document describes the conventions for using FIPS 204, the Module-Lattice- Based Digital Signature Algorithm (ML-DSA) in Internet X.509 certificates and certificate revocation lists. The conventions for the associated signatures, subject public keys, and private key are also described. When the Curdle Security Working Group was chartered, a range of object identifiers was donated by DigiCert, Inc. for the purpose of registering the Edwards Elliptic Curve key agreement and signature algorithms. This donated set of OIDs allowed for shorter values than would be possible using the existing S/MIME or PKIX arcs. This document describes the donated range and the identifiers that were assigned from that range, transfers control of that range to IANA, and establishes IANA allocation policies for any future assignments within that range.

ASN.1 Module This appendix includes the ASN.1 module for SLH-DSA. Note that as per , certificates use the Distinguished Encoding Rules; see . This module imports objects from and . X509-SLH-DSA-Module-2024 { 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) } DEFINITIONS IMPLICIT TAGS ::= BEGIN EXPORTS ALL; IMPORTS PUBLIC-KEY, SIGNATURE-ALGORITHM FROM AlgorithmInformation-2009 -- in [RFC5912] { iso(1) identified-organization(3) dod(6) internet(1) security(5) mechanisms(5) pkix(7) id-mod(0) id-mod-algorithmInformation-02(58) } pk-slh-dsa-sha2-128s, pk-slh-dsa-sha2-128f, pk-slh-dsa-sha2-192s, pk-slh-dsa-sha2-192f, pk-slh-dsa-sha2-256s, pk-slh-dsa-sha2-256f, pk-slh-dsa-shake-128s, pk-slh-dsa-shake-128f, pk-slh-dsa-shake-192s, pk-slh-dsa-shake-192f, pk-slh-dsa-shake-256s, pk-slh-dsa-shake-256f, sa-slh-dsa-sha2-128s, sa-slh-dsa-sha2-128f, sa-slh-dsa-sha2-192s, sa-slh-dsa-sha2-192f, sa-slh-dsa-sha2-256s, sa-slh-dsa-sha2-256f, sa-slh-dsa-shake-128s, sa-slh-dsa-shake-128f, sa-slh-dsa-shake-192s, sa-slh-dsa-shake-192f, sa-slh-dsa-shake-256s, sa-slh-dsa-shake-256f FROM SLH-DSA-Module-2024 -- in [I-D.ietf-lamps-cms-sphincs-plus] { iso(1) member-body(2) us(840) rsadsi(113549) pkcs(1) pkcs9(9) id-smime(16) id-mod(0) id-mod-slh-dsa-2024(TBD2) } ; -- -- HashSLH-DSA object identifiers from [CSOR] -- nistAlgorithms OBJECT IDENTIFIER ::= { joint-iso-itu-t(2) country(16) us(840) organization(1) gov(101) csor(3) 4 } sigAlgs OBJECT IDENTIFIER ::= { nistAlgorithms 3 } id-hash-slh-dsa-sha2-128s-with-sha256 OBJECT IDENTIFIER ::= { sigAlgs 35 } id-hash-slh-dsa-sha2-128f-with-sha256 OBJECT IDENTIFIER ::= { sigAlgs 36 } id-hash-slh-dsa-sha2-192s-with-sha512 OBJECT IDENTIFIER ::= { sigAlgs 37 } id-hash-slh-dsa-sha2-192f-with-sha512 OBJECT IDENTIFIER ::= { sigAlgs 38 } id-hash-slh-dsa-sha2-256s-with-sha512 OBJECT IDENTIFIER ::= { sigAlgs 39 } id-hash-slh-dsa-sha2-256f-with-sha512 OBJECT IDENTIFIER ::= { sigAlgs 40 } id-hash-slh-dsa-shake-128s-with-shake128 OBJECT IDENTIFIER ::= { sigAlgs 41 } id-hash-slh-dsa-shake-128f-with-shake128 OBJECT IDENTIFIER ::= { sigAlgs 42 } id-hash-slh-dsa-shake-192s-with-shake256 OBJECT IDENTIFIER ::= { sigAlgs 43 } id-hash-slh-dsa-shake-192f-with-shake256 OBJECT IDENTIFIER ::= { sigAlgs 44 } id-hash-slh-dsa-shake-256s-with-shake256 OBJECT IDENTIFIER ::= { sigAlgs 45 } id-hash-slh-dsa-shake-256f-with-shake256 OBJECT IDENTIFIER ::= { sigAlgs 46 } -- -- HashSLH-DSA public key identifiers -- pk-hash-slh-dsa-sha2-128s-with-sha256 PUBLIC-KEY ::= { IDENTIFIER id-hash-slh-dsa-sha2-128s-with-sha256 -- KEY no ASN.1 wrapping -- CERT-KEY-USAGE { digitalSignature, nonRepudiation } -- PRIVATE-KEY no ASN.1 wrapping -- } pk-hash-slh-dsa-sha2-128f-with-sha256 PUBLIC-KEY ::= { IDENTIFIER id-hash-slh-dsa-sha2-128f-with-sha256 -- KEY no ASN.1 wrapping -- CERT-KEY-USAGE { digitalSignature, nonRepudiation } -- PRIVATE-KEY no ASN.1 wrapping -- } pk-hash-slh-dsa-sha2-192s-with-sha512 PUBLIC-KEY ::= { IDENTIFIER id-hash-slh-dsa-sha2-192s-with-sha512 -- KEY no ASN.1 wrapping -- CERT-KEY-USAGE { digitalSignature, nonRepudiation } -- PRIVATE-KEY no ASN.1 wrapping -- } pk-hash-slh-dsa-sha2-192f-with-sha512 PUBLIC-KEY ::= { IDENTIFIER id-hash-slh-dsa-sha2-192f-with-sha512 -- KEY no ASN.1 wrapping -- CERT-KEY-USAGE { digitalSignature, nonRepudiation } -- PRIVATE-KEY no ASN.1 wrapping -- } pk-hash-slh-dsa-sha2-256s-with-sha512 PUBLIC-KEY ::= { IDENTIFIER id-hash-slh-dsa-sha2-256s-with-sha512 -- KEY no ASN.1 wrapping -- CERT-KEY-USAGE { digitalSignature, nonRepudiation } -- PRIVATE-KEY no ASN.1 wrapping -- } pk-hash-slh-dsa-sha2-256f-with-sha512 PUBLIC-KEY ::= { IDENTIFIER id-hash-slh-dsa-sha2-256f-with-sha512 -- KEY no ASN.1 wrapping -- CERT-KEY-USAGE { digitalSignature, nonRepudiation } -- PRIVATE-KEY no ASN.1 wrapping -- } pk-hash-slh-dsa-shake-128s-with-shake128 PUBLIC-KEY ::= { IDENTIFIER id-hash-slh-dsa-shake-128s-with-shake128 -- KEY no ASN.1 wrapping -- CERT-KEY-USAGE { digitalSignature, nonRepudiation } -- PRIVATE-KEY no ASN.1 wrapping -- } pk-hash-slh-dsa-shake-128f-with-shake128 PUBLIC-KEY ::= { IDENTIFIER id-hash-slh-dsa-shake-128f-with-shake128 -- KEY no ASN.1 wrapping -- CERT-KEY-USAGE { digitalSignature, nonRepudiation } -- PRIVATE-KEY no ASN.1 wrapping -- } pk-hash-slh-dsa-shake-192s-with-shake256 PUBLIC-KEY ::= { IDENTIFIER id-hash-slh-dsa-shake-192s-with-shake256 -- KEY no ASN.1 wrapping -- CERT-KEY-USAGE { digitalSignature, nonRepudiation } -- PRIVATE-KEY no ASN.1 wrapping -- } pk-hash-slh-dsa-shake-192f-with-shake256 PUBLIC-KEY ::= { IDENTIFIER id-hash-slh-dsa-shake-192f-with-shake256 -- KEY no ASN.1 wrapping -- CERT-KEY-USAGE { digitalSignature, nonRepudiation } -- PRIVATE-KEY no ASN.1 wrapping -- } pk-hash-slh-dsa-shake-256s-with-shake256 PUBLIC-KEY ::= { IDENTIFIER id-hash-slh-dsa-shake-256s-with-shake256 -- KEY no ASN.1 wrapping -- CERT-KEY-USAGE { digitalSignature, nonRepudiation } -- PRIVATE-KEY no ASN.1 wrapping -- } pk-hash-slh-dsa-shake-256f-with-shake256 PUBLIC-KEY ::= { IDENTIFIER id-hash-slh-dsa-shake-256f-with-shake256 -- KEY no ASN.1 wrapping -- CERT-KEY-USAGE { digitalSignature, nonRepudiation } -- PRIVATE-KEY no ASN.1 wrapping -- } -- -- HashSLH-DSA signature algorithm identifiers -- -- EDNOTE: we did not include the optional SMIME-CAPS because -- HashSLH-DSA is not defined for use in CMS. Is this correct -- or should we still include SMIME-CAPS? sa-hash-slh-dsa-sha2-128s-with-sha256 SIGNATURE-ALGORITHM ::= { IDENTIFIER id-hash-slh-dsa-sha2-128s-with-sha256 PARAMS ARE absent PUBLIC-KEYS { pk-hash-slh-dsa-sha2-128s-with-sha256 } } sa-hash-slh-dsa-sha2-128f-with-sha256 SIGNATURE-ALGORITHM ::= { IDENTIFIER id-hash-slh-dsa-sha2-128f-with-sha256 PARAMS ARE absent PUBLIC-KEYS { pk-hash-slh-dsa-sha2-128f-with-sha256 } } sa-hash-slh-dsa-sha2-192s-with-sha512 SIGNATURE-ALGORITHM ::= { IDENTIFIER id-hash-slh-dsa-sha2-192s-with-sha512 PARAMS ARE absent PUBLIC-KEYS { pk-hash-slh-dsa-sha2-192s-with-sha512 } } sa-hash-slh-dsa-sha2-192f-with-sha512 SIGNATURE-ALGORITHM ::= { IDENTIFIER id-hash-slh-dsa-sha2-192f-with-sha512 PARAMS ARE absent PUBLIC-KEYS { pk-hash-slh-dsa-sha2-192f-with-sha512 } } sa-hash-slh-dsa-sha2-256s-with-sha512 SIGNATURE-ALGORITHM ::= { IDENTIFIER id-hash-slh-dsa-sha2-256s-with-sha512 PARAMS ARE absent PUBLIC-KEYS { pk-hash-slh-dsa-sha2-256s-with-sha512 } } sa-hash-slh-dsa-sha2-256f-with-sha512 SIGNATURE-ALGORITHM ::= { IDENTIFIER id-hash-slh-dsa-sha2-256f-with-sha512 PARAMS ARE absent PUBLIC-KEYS { pk-hash-slh-dsa-sha2-256f-with-sha512 } } sa-hash-slh-dsa-shake-128s-with-shake128 SIGNATURE-ALGORITHM ::= { IDENTIFIER id-hash-slh-dsa-shake-128s-with-shake128 PARAMS ARE absent PUBLIC-KEYS { pk-hash-slh-dsa-shake-128s-with-shake128 } } sa-hash-slh-dsa-shake-128f-with-shake128 SIGNATURE-ALGORITHM ::= { IDENTIFIER id-hash-slh-dsa-shake-128f-with-shake128 PARAMS ARE absent PUBLIC-KEYS { pk-hash-slh-dsa-shake-128f-with-shake128 } } sa-hash-slh-dsa-shake-192s-with-shake256 SIGNATURE-ALGORITHM ::= { IDENTIFIER id-hash-slh-dsa-shake-192s-with-shake256 PARAMS ARE absent PUBLIC-KEYS { pk-hash-slh-dsa-shake-192s-with-shake256 } } sa-hash-slh-dsa-shake-192f-with-shake256 SIGNATURE-ALGORITHM ::= { IDENTIFIER id-hash-slh-dsa-shake-192f-with-shake256 PARAMS ARE absent PUBLIC-KEYS { pk-hash-slh-dsa-shake-192f-with-shake256 } } sa-hash-slh-dsa-shake-256s-with-shake256 SIGNATURE-ALGORITHM ::= { IDENTIFIER id-hash-slh-dsa-shake-256s-with-shake256 PARAMS ARE absent PUBLIC-KEYS { pk-hash-slh-dsa-shake-256s-with-shake256 } } sa-hash-slh-dsa-shake-256f-with-shake256 SIGNATURE-ALGORITHM ::= { IDENTIFIER id-hash-slh-dsa-shake-256f-with-shake256 PARAMS ARE absent PUBLIC-KEYS { pk-hash-slh-dsa-shake-256f-with-shake256 } } -- -- Expand SignatureAlgorithms from RFC 5912 -- SignatureAlgorithms SIGNATURE-ALGORITHM ::= { sa-slh-dsa-sha2-128s | sa-slh-dsa-sha2-128f | sa-slh-dsa-sha2-192s | sa-slh-dsa-sha2-192f | sa-slh-dsa-sha2-256s | sa-slh-dsa-sha2-256f | sa-slh-dsa-shake-128s | sa-slh-dsa-shake-128f | sa-slh-dsa-shake-192s | sa-slh-dsa-shake-192f | sa-slh-dsa-shake-256s | sa-slh-dsa-shake-256f | sa-hash-slh-dsa-sha2-128s-with-sha256 | sa-hash-slh-dsa-sha2-128f-with-sha256 | sa-hash-slh-dsa-sha2-192s-with-sha512 | sa-hash-slh-dsa-sha2-192f-with-sha512 | sa-hash-slh-dsa-sha2-256s-with-sha512 | sa-hash-slh-dsa-sha2-256f-with-sha512 | sa-hash-slh-dsa-shake-128s-with-shake128 | sa-hash-slh-dsa-shake-128f-with-shake128 | sa-hash-slh-dsa-shake-192s-with-shake256 | sa-hash-slh-dsa-shake-192f-with-shake256 | sa-hash-slh-dsa-shake-256s-with-shake256 | sa-hash-slh-dsa-shake-256f-with-shake256, ... } -- -- Expand PublicKeyAlgorithms from RFC 5912 -- PublicKeyAlgorithms PUBLIC-KEY ::= { pk-slh-dsa-sha2-128s | pk-slh-dsa-sha2-128f | pk-slh-dsa-sha2-192s | pk-slh-dsa-sha2-192f | pk-slh-dsa-sha2-256s | pk-slh-dsa-sha2-256f | pk-slh-dsa-shake-128s | pk-slh-dsa-shake-128f | pk-slh-dsa-shake-192s | pk-slh-dsa-shake-192f | pk-slh-dsa-shake-256s | pk-slh-dsa-shake-256f | pk-hash-slh-dsa-sha2-128s-with-sha256 | pk-hash-slh-dsa-sha2-128f-with-sha256 | pk-hash-slh-dsa-sha2-192s-with-sha512 | pk-hash-slh-dsa-sha2-192f-with-sha512 | pk-hash-slh-dsa-sha2-256s-with-sha512 | pk-hash-slh-dsa-sha2-256f-with-sha512 | pk-hash-slh-dsa-shake-128s-with-shake128 | pk-hash-slh-dsa-shake-128f-with-shake128 | pk-hash-slh-dsa-shake-192s-with-shake256 | pk-hash-slh-dsa-shake-192f-with-shake256 | pk-hash-slh-dsa-shake-256s-with-shake256 | pk-hash-slh-dsa-shake-256f-with-shake256, ... } END ]]>

Security Strengths Instead of defining the strength of a quantum algorithm in a traditional manner using precise estimates of the number of bits of security, NIST defined a collection of broad security strength categories. Each category is defined by a comparatively easy-to-analyze reference primitive that cover a range of security strengths offered by existing NIST standards in symmetric cryptography, which NIST expects to offer significant resistance to quantum cryptanalysis. These categories describe any attack that breaks the relevant security definition that must require computational resources comparable to or greater than those required for: Level 1 - 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 5 are listed in , along with the resulting signature size, public key, and private key sizes in bytes. The HashSLH-DSA parameter sets have the same values as the Pure SLH-DSA equivalents. SLH-DSA security strengths

OID	NIST Level	Sig.	Pub. Key	Priv. Key
id-slh-dsa-sha2-128s	1	7856	32	64
id-slh-dsa-sha2-128f	1	17088	32	64
id-slh-dsa-sha2-192s	3	16224	48	96
id-slh-dsa-sha2-192f	3	35664	48	96
id-slh-dsa-sha2-256s	5	29792	64	128
id-slh-dsa-sha2-256f	5	49856	64	128
id-slh-dsa-shake-128s	1	7856	32	64
id-slh-dsa-shake-128f	1	17088	32	64
id-slh-dsa-shake-192s	3	16224	48	96
id-slh-dsa-shake-192f	3	35664	48	96
id-slh-dsa-shake-256s	5	29792	64	128
id-slh-dsa-shake-256f	5	49856	64	128

Examples This appendix contains examples of SLH-DSA public keys, private keys and certificates.

Example Public Key An example of a SLH-DSA public key using id-slh-dsa-sha2-128s:

Example Private Key An example of a SLH-DSA private key without the public key using id-slh-dsa-sha2-128s:

Example Certificate An example of a self-signed SLH-DSA certificate using id-slh-dsa-sha2-128s:

Acknowledgments Much of the structure and text of this document is based on and . The remainder comes from . Thanks to those authors, and the ones they based their work on, for making our work easier. "Copying always makes things easier and less error prone" - .