| RFC 9814 | SLH-DSA Signature Algorithm in CMS | July 2025 |
| Housley, et al. | Standards Track | [Page] |
SLH-DSA is a stateless hash-based signature algorithm. This documentspecifies the conventions for using the SLH-DSA signature algorithmwith the Cryptographic Message Syntax (CMS). In addition, thealgorithm identifier and public key syntax are provided.¶
This is an Internet Standards Track document.¶
This document is a product of the Internet Engineering Task Force (IETF). It represents the consensus of the IETF community. It has received public review and has been approved for publication by the Internet Engineering Steering Group (IESG). Further information on Internet Standards is available in Section 2 of RFC 7841.¶
Information about the current status of this document, any errata, and how to provide feedback on it may be obtained athttps://www.rfc-editor.org/info/rfc9814.¶
Copyright (c) 2025 IETF Trust and the persons identified as the document authors. All rights reserved.¶
This document is subject to BCP 78 and the IETF Trust's Legal Provisions Relating to IETF Documents (https://trustee.ietf.org/license-info) in effect on the date of publication of this document. Please review these documents carefully, as they describe your rights and restrictions with respect to this document. Code Components extracted from this document must include Revised BSD License text as described in Section 4.e of the Trust Legal Provisions and are provided without warranty as described in the Revised BSD License.¶
This document specifies the conventions for using the SLH-DSA hash-basedsignature algorithm[FIPS205] with the Cryptographic MessageSyntax (CMS)[RFC5652] signed-data content type.¶
SLH-DSA offers two signature modes: pure mode and pre-hash mode. SLH-DSAsignature operations include a context string as input. The context stringhas a maximum length of 255 bytes. By default, the context string is theempty string. This document only specifies the use of pure mode with an emptycontext string for the CMS signed-data content type.¶
SLH-DSA offers three security levels. The parameters for each of thesecurity levels were chosen to provide 128 bits of security, 192 bits ofsecurity, and 256 bits of security. Separate algorithm identifiers havebeen assigned for SLH-DSA at each of these security levels.¶
SLH-DSA is a stateless hash-based signature algorithm. Other hash-basedsignature algorithms are stateful, including Hierarchical Signature System (HSS) / Leighton-Micali Signatures (LMS)[RFC8554] andeXtended Merkle Signature Scheme (XMSS)[RFC8391]. Without the need for state kept by the signer,SLH-DSA is much less fragile than the stateful hash-based signature algorithms.¶
CMS values are generated with ASN.1[X680] using the BasicEncoding Rules (BER) and the Distinguished Encoding Rules(DER)[X690].¶
There have been recent advances in cryptanalysis and advances in thedevelopment of quantum computers. Each of these advances pose athreat to widely deployed digital signature algorithms.¶
If Cryptographically Relevant Quantum Computers (CRQCs) are ever built, theywill be able to break many of the public key cryptosystems currently in use,including RSA, DSA, Elliptic Curve Digital Signature Algorithm (ECDSA), and Edwards-curve Digital Signature Algorithm (EdDSA). A Post-Quantum Cryptosystem (PQC) issecure against quantum computers that have more than a trivial number of quantumbits (qu-bits). It is open to conjecture when it will be feasible to buildsuch quantum computers; however, it is prudent to use cryptographicalgorithms that remain secure if a CRQC is invented. SLH-DSA is a PQCsignature algorithm.¶
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in BCP 14[RFC2119][RFC8174] when, and only when, they appear in all capitals, as shown here.¶
SLH-DSA is a stateless hash-based signature algorithm. SLH-DSA makes use of a few-time signature construction (Forest of Random Subsets (FORS))and a hypertree. FORS signs a message with a private key. Thecorresponding 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 Winternitz One-Time Signature Plus (WOTS+). The FORStree roots are signed by a WOTS+ privatekey. The corresponding WOTS+ public keys form the leaves in d-layersof Merkle subtrees in the SLH-DSA hypertree. The bottom layer ofthat hypertree signs the FORS roots with WOTS+. The roots of thebottom Merkle subtrees are then signed with WOTS+ and thecorresponding WOTS+ public keys form the leaves of the next-level-upsubtree. Subtree roots are consequently signed by their correspondingsubtree layers until the top subtree is reached. The top-layer subtreeforms the hypertree root, which is trusted at the verifier.¶
An 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.¶
An SLH-DSA signature is verified using the FORS signature, theWOTS+ signatures, and the path to the root of each subtree. When reachingthe root of the hypertree, the signature verifies only if it hashes tothe pre-trusted root of the SLH-DSA hypertree.¶
SLH-DSA is a stateless hash-based signature algorithm. Statefulhash-based signature schemes require that the WOTS+ private key(generated by using a state index) never be reused or the schemeloses its security. FORS is used at the bottom of the SLH-DSA hypertree. Security decreases if the same private key is used to sign two or more different messages, butsecurity does not collapse, as is the case in stateful hash-based signaturealgorithms. Without the need forstate kept by the signer to ensure it is not reused, SLH-DSA is much less fragile.¶
SLH-DSA was designed to sign up to 264 messages and offers threesecurity levels. The parameters of the SLH-DSA hypertree include thesecurity parameter, the hash function, the tree height, the number oflayers of subtrees, the Winternitz parameter of WOTS+, and the number of FORStrees and leaves in each. The parameters for each of the security levelswere chosen to be at least as secure as a generic block cipher of 128, 192,or 256 bits.¶
The AlgorithmIdentifier for an SLH-DSA public keyMUST use one of thetwelve id-slh-dsa object identifiers listed below, based on thesecurity level used to generate the SLH-DSA hypertree, the small or fastversion of the algorithm, and the use of SHA2[FIPS180] orSHAKE[FIPS202]. For example, id-slh-dsa-shake-256srepresents the 256-bit security level, the small version of thealgorithm, and the use of SHAKE256. The parameters field of theAlgorithmIdentifier for the SLH-DSA public keyMUST be absent.¶
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-slh-dsa-sha2-128s OBJECT IDENTIFIER ::= { sigAlgs 20 } id-slh-dsa-sha2-128f OBJECT IDENTIFIER ::= { sigAlgs 21 } id-slh-dsa-sha2-192s OBJECT IDENTIFIER ::= { sigAlgs 22 } id-slh-dsa-sha2-192f OBJECT IDENTIFIER ::= { sigAlgs 23 } id-slh-dsa-sha2-256s OBJECT IDENTIFIER ::= { sigAlgs 24 } id-slh-dsa-sha2-256f OBJECT IDENTIFIER ::= { sigAlgs 25 } id-slh-dsa-shake-128s OBJECT IDENTIFIER ::= { sigAlgs 26 } id-slh-dsa-shake-128f OBJECT IDENTIFIER ::= { sigAlgs 27 } id-slh-dsa-shake-192s OBJECT IDENTIFIER ::= { sigAlgs 28 } id-slh-dsa-shake-192f OBJECT IDENTIFIER ::= { sigAlgs 29 } id-slh-dsa-shake-256s OBJECT IDENTIFIER ::= { sigAlgs 30 } id-slh-dsa-shake-256f OBJECT IDENTIFIER ::= { sigAlgs 31 }¶When this AlgorithmIdentifier appears in the SubjectPublicKeyInfo field ofan X.509 certificate[RFC5280], the certificate key usage extensionMAYcontain digitalSignature, nonRepudiation, keyCertSign, and cRLSign; thecertificate key usage extensionMUST NOT contain other values.¶
pk-slh-dsa-sha2-128s PUBLIC-KEY ::= { IDENTIFIER id-slh-dsa-sha2-128s -- KEY no ASN.1 wrapping -- CERT-KEY-USAGE { digitalSignature, nonRepudiation, keyCertSign, cRLSign } -- PRIVATE-KEY no ASN.1 wrapping -- } pk-slh-dsa-sha2-128f PUBLIC-KEY ::= { IDENTIFIER id-slh-dsa-sha2-128f -- KEY no ASN.1 wrapping -- CERT-KEY-USAGE { digitalSignature, nonRepudiation, keyCertSign, cRLSign } -- PRIVATE-KEY no ASN.1 wrapping -- } pk-slh-dsa-sha2-192s PUBLIC-KEY ::= { IDENTIFIER id-slh-dsa-sha2-192s -- KEY no ASN.1 wrapping -- CERT-KEY-USAGE { digitalSignature, nonRepudiation, keyCertSign, cRLSign } -- PRIVATE-KEY no ASN.1 wrapping -- } pk-slh-dsa-sha2-192f PUBLIC-KEY ::= { IDENTIFIER id-slh-dsa-sha2-192f -- KEY no ASN.1 wrapping -- CERT-KEY-USAGE { digitalSignature, nonRepudiation, keyCertSign, cRLSign } -- PRIVATE-KEY no ASN.1 wrapping -- } pk-slh-dsa-sha2-256s PUBLIC-KEY ::= { IDENTIFIER id-slh-dsa-sha2-256s -- KEY no ASN.1 wrapping -- CERT-KEY-USAGE { digitalSignature, nonRepudiation, keyCertSign, cRLSign } -- PRIVATE-KEY no ASN.1 wrapping -- } pk-slh-dsa-sha2-256f PUBLIC-KEY ::= { IDENTIFIER id-slh-dsa-sha2-256f -- KEY no ASN.1 wrapping -- CERT-KEY-USAGE { digitalSignature, nonRepudiation, keyCertSign, cRLSign } -- PRIVATE-KEY no ASN.1 wrapping -- } pk-slh-dsa-shake-128s PUBLIC-KEY ::= { IDENTIFIER id-slh-dsa-shake-128s -- KEY no ASN.1 wrapping -- CERT-KEY-USAGE { digitalSignature, nonRepudiation, keyCertSign, cRLSign } -- PRIVATE-KEY no ASN.1 wrapping -- } pk-slh-dsa-shake-128f PUBLIC-KEY ::= { IDENTIFIER id-slh-dsa-shake-128f -- KEY no ASN.1 wrapping -- CERT-KEY-USAGE { digitalSignature, nonRepudiation, keyCertSign, cRLSign } -- PRIVATE-KEY no ASN.1 wrapping -- } pk-slh-dsa-shake-192s PUBLIC-KEY ::= { IDENTIFIER id-slh-dsa-shake-192s -- KEY no ASN.1 wrapping -- CERT-KEY-USAGE { digitalSignature, nonRepudiation, keyCertSign, cRLSign } -- PRIVATE-KEY no ASN.1 wrapping -- } pk-slh-dsa-shake-192f PUBLIC-KEY ::= { IDENTIFIER id-slh-dsa-shake-192f -- KEY no ASN.1 wrapping -- CERT-KEY-USAGE { digitalSignature, nonRepudiation, keyCertSign, cRLSign } -- PRIVATE-KEY no ASN.1 wrapping -- } pk-slh-dsa-shake-256s PUBLIC-KEY ::= { IDENTIFIER id-slh-dsa-shake-256s -- KEY no ASN.1 wrapping -- CERT-KEY-USAGE { digitalSignature, nonRepudiation, keyCertSign, cRLSign } -- PRIVATE-KEY no ASN.1 wrapping -- } pk-slh-dsa-shake-256f PUBLIC-KEY ::= { IDENTIFIER id-slh-dsa-shake-256f -- KEY no ASN.1 wrapping -- CERT-KEY-USAGE { digitalSignature, nonRepudiation, keyCertSign, cRLSign } -- PRIVATE-KEY no ASN.1 wrapping -- } SLH-DSA-PublicKey ::= OCTET STRING (SIZE (32 | 48 | 64)) SLH-DSA-PrivateKey ::= OCTET STRING (SIZE (64 | 96 | 128))¶No additional encoding of the SLH-DSA public key is applied in theSubjectPublicKeyInfo field of an X.509 certificate[RFC5280].¶
No additional encoding of the SLH-DSA private key is applied in thePrivateKeyInfo field of the privateKey field of the OneAsymmetricKeytype of an Asymmetric Key Package[RFC5958].¶
When an SLH-DSA public key appears outside of a SubjectPublicKeyInfo typein an environment that uses ASN.1 encoding, the SLH-DSA public keycan be encoded as an OCTET STRING by using the SLH-DSA-PublicKey type.¶
When an SLH-DSA private key appears outside of an Asymmetric Key Packagein an environment that uses ASN.1 encoding, the SLH-DSA private keycan be encoded as an OCTET STRING by using the SLH-DSA-PrivateKey type.¶
As specified in CMS[RFC5652], the digital signature is produced fromthe message digest and the signer's private key. The signature is computedover different values depending on whether signed attributes are absent orpresent.¶
When signed attributes are absent, the SLH-DSA (pure mode) signature is computed overthe content. When signed attributes are present, a hashSHOULD be computed overthe DER-encoded signed attributes using the same hash function that is used in the SLH-DSA tree. Thesigned attributesMUST include a content-type attribute and a message-digestattribute. The message-digest attribute contains the hash value of thecontent. The SLH-DSA signature is computed over the DER encoding of the setof signed attributes. The SLH-DSA signature-generation operation is calledslh_sign; see Section 10.2.1 of[FIPS205]. In summary:¶
IF (signed attributes are absent) THEN slh_sign(content) ELSE signed attributes message-digest attribute = Hash(content); slh_sign(DER(SignedAttributes))¶
In some implementations, performance may be significantly improved bysigning and verifying DER(SignedAttributes) when the content is large. Thatis, passing an entire large message content to the signing function or thesignature validation function can have an impact on performance. When thesigned attributes are present,Section 5.3 of [RFC5652] requires theinclusion of the content-type attribute and the message-digest attribute. Otherattributes can also be included.¶
When using SLH-DSA and signed attributes are present in the SignerInfo, thedigestAlgorithms field in the SignedDataMUST include the identifier for theone-way hash function used to compute the message digest.¶
When using SLH-DSA, the fields in the SignerInfo are used as follows:¶
The digestAlgorithmMUST identify a one-way hash function. When signedattributes are absent, the digestAlgorithm identifierSHOULD match the hashfunction used in the SLH-DSA tree (as shown in the list below). The digestAlgorithm does not have any significance when signedattributes are absent as it is not used to pre-hash the message. When there is a concern for failures with legacy implementations that do not support all hash functions, signersMAY choose to always use the SHA-256 algorithm identifier as the digestAlgorithm when signed attributes are absent. When signed attributes are present, to ensure collision resistance, the identified hashfunctionMUST produce a hash value that is at least twice the size of thehash function used in the SLH-DSA tree. The hash functions defined in[FIPS180] and[FIPS202]MUST be supported for use with the variants of SLH-DSA as shown below:¶
id-slh-dsa-sha2-128s: SHA-256 id-slh-dsa-sha2-128f: SHA-256 id-slh-dsa-sha2-192s: SHA-512 id-slh-dsa-sha2-192f: SHA-512 id-slh-dsa-sha2-256s: SHA-512 id-slh-dsa-sha2-256f: SHA-512 id-slh-dsa-shake-128s: 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-192f: 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¶
The object identifiers for SHA-256 and SHA-512 are included in[RFC5754]. The object identifiers for SHAKE128 and SHAKE256 are included in[RFC8702]. In all four cases, the AlgorithmIdentifierSHOULD NOT include parameters.¶
The signatureAlgorithmMUST contain one of the SLH-DSA algorithmidentifiers, and the algorithm parameters fieldMUST be absent. Thealgorithm identifierMUST be one of the following:¶
id-slh-dsa-sha2-128s, id-slh-dsa-sha2-128f, id-slh-dsa-sha2-192s, id-slh-dsa-sha2-192f, id-slh-dsa-sha2-256s, id-slh-dsa-sha2-256f, id-slh-dsa-shake-128s, id-slh-dsa-shake-128f, id-slh-dsa-shake-192s, id-slh-dsa-shake-192f, id-slh-dsa-shake-256s, id-slh-dsa-shake-256f.¶
The signature contains the signature value resulting from theSLH-DSA signing operation with the parameters associated with theselected signatureAlgorithm. The SLH-DSA signature-generationoperation is specified in Section 10.2.1 of[FIPS205], and theSLH-DSA signature verification operation is specified inSection 10.3 of[FIPS205]. Signature verificationMUST includechecking that the signatureAlgorithm field identifies SLH-DSAparameters that are consistent with public key used to validatethe signature.¶
ImplementationsMUST protect the private keys. Compromise of theprivate keys may result in the ability to forge signatures.¶
When generating an SLH-DSA key pair, an implementationMUST generateeach key pair independently of all other key pairs in the SLH-DSAhypertree.¶
A SLH-DSA treeMUST NOT be used for more than 264 signing operations.¶
The generation of private keys relies on random numbers. The useof inadequate Pseudorandom Number Generators (PRNGs) to generatethese values can result in little or no security. An attacker mayfind it much easier to reproduce the PRNG environment that producedthe keys, searching the resulting small set of possibilities, ratherthan brute-force searching the whole key space. The generation ofquality random numbers is difficult, and[RFC4086] offersimportant guidance in this area.¶
To avoid algorithm-substitution attacks, the CMSAlgorithmProtection attributedefined in[RFC6211]SHOULD be included in signed attributes.¶
Implementers should consider their particular use cases and maychoose to implement optional fault-attack countermeasures[CMP2018][Ge2023]. Verifying a signature before releasing thesignature value is a typical fault-attack countermeasure; however, thiscountermeasure is not effective for SLH-DSA[Ge2023]. Redundancyby replicating the signature-generation processMAY be used as aneffective fault-attack countermeasure for SLH-DSA[Ge2023];however, the SLH-DSA signature generation is already considered slow.¶
Likewise, implementers should consider their particular use cases and maychoose to implement protections against passive power and emissionsside-channel attacks[SLotH].¶
If slh_sign is implemented in a hardware device such as HardwareSecurity Module (HSM) or portable cryptographic token, implementationscan avoid sending the full content to the device. By including signedattributes, which necessarily include the message-digest attribute andthe content-type attribute as described inSection 5.3 of [RFC5652],the much smaller set of signed attributes are sent to the device for signing.¶
By including signed attributes in the SignerInfo, one can obtain similarinterface characteristics to SLH-DSA in pre-hash mode. With pre-hash mode, thehash of the content is passed to the SLH-DSA signature operation instead of thefull message content. By including signed attributes in the SignerInfo, arelatively small to-be-signed value is passed to the SLH-DSA signatureoperation. For this reason, SLH-DSA pre-hash mode is not specified for usewith the CMS SignedData. Note SLH-DSA pre-hash mode always yields a differentsignature value than SLH-DSA pure mode, even if the to-be-signed content isthe same.¶
When using SLH-DSA in pure mode, it is not possible to single-pass processthe content to verify a SignedData message that does not contain signedattributes. To assist recipients that might make use of stream-based APIs,implementersSHOULD include signed attributes within any SignerInfo that usesSLH-DSA as signature algorithm. Doing so allows the recipient implementationto avoid keeping the signed content in memory. Recall that when signedattributes are present, theyMUST contain a content-type attribute and amessage-digest attribute, and theySHOULD contain a CMSAlgorithmProtectionattribute.¶
For the ASN.1 Module inAppendix A, IANAhas assigned an Object Identifier (OID) for the moduleidentifier (81) with a Description of "id-mod-slh-dsa-2024".The OID for the module has been allocated in the"SMI Security for S/MIME Module Identifier (1.2.840.113549.1.9.16.0)" registry.¶
This ASN.1 Module builds upon the conventions established in[RFC5911].¶
<CODE BEGINS>SLH-DSA-Module-2024 { 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) }DEFINITIONS IMPLICIT TAGS ::= BEGINEXPORTS ALL;IMPORTS PUBLIC-KEY, SIGNATURE-ALGORITHM, SMIME-CAPS FROM AlgorithmInformation-2009 -- in [RFC5911] { iso(1) identified-organization(3) dod(6) internet(1) security(5) mechanisms(5) pkix(7) id-mod(0) id-mod-algorithmInformation-02(58) } ;---- Object Identifiers--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-slh-dsa-sha2-128s OBJECT IDENTIFIER ::= { sigAlgs 20 }id-slh-dsa-sha2-128f OBJECT IDENTIFIER ::= { sigAlgs 21 }id-slh-dsa-sha2-192s OBJECT IDENTIFIER ::= { sigAlgs 22 }id-slh-dsa-sha2-192f OBJECT IDENTIFIER ::= { sigAlgs 23 }id-slh-dsa-sha2-256s OBJECT IDENTIFIER ::= { sigAlgs 24 }id-slh-dsa-sha2-256f OBJECT IDENTIFIER ::= { sigAlgs 25 }id-slh-dsa-shake-128s OBJECT IDENTIFIER ::= { sigAlgs 26 }id-slh-dsa-shake-128f OBJECT IDENTIFIER ::= { sigAlgs 27 }id-slh-dsa-shake-192s OBJECT IDENTIFIER ::= { sigAlgs 28 }id-slh-dsa-shake-192f OBJECT IDENTIFIER ::= { sigAlgs 29 }id-slh-dsa-shake-256s OBJECT IDENTIFIER ::= { sigAlgs 30 }id-slh-dsa-shake-256f OBJECT IDENTIFIER ::= { sigAlgs 31 }---- Signature Algorithm, Public Key, and Private Key--sa-slh-dsa-sha2-128s SIGNATURE-ALGORITHM ::= { IDENTIFIER id-slh-dsa-sha2-128s PARAMS ARE absent PUBLIC-KEYS { pk-slh-dsa-sha2-128s } SMIME-CAPS { IDENTIFIED BY id-slh-dsa-sha2-128s } }sa-slh-dsa-sha2-128f SIGNATURE-ALGORITHM ::= { IDENTIFIER id-slh-dsa-sha2-128f PARAMS ARE absent PUBLIC-KEYS { pk-slh-dsa-sha2-128f } SMIME-CAPS { IDENTIFIED BY id-slh-dsa-sha2-128f } }sa-slh-dsa-sha2-192s SIGNATURE-ALGORITHM ::= { IDENTIFIER id-slh-dsa-sha2-192s PARAMS ARE absent PUBLIC-KEYS { pk-slh-dsa-sha2-192s } SMIME-CAPS { IDENTIFIED BY id-slh-dsa-sha2-192s } }sa-slh-dsa-sha2-192f SIGNATURE-ALGORITHM ::= { IDENTIFIER id-slh-dsa-sha2-192f PARAMS ARE absent PUBLIC-KEYS { pk-slh-dsa-sha2-192f } SMIME-CAPS { IDENTIFIED BY id-slh-dsa-sha2-192f } }sa-slh-dsa-sha2-256s SIGNATURE-ALGORITHM ::= { IDENTIFIER id-slh-dsa-sha2-256s PARAMS ARE absent PUBLIC-KEYS { pk-slh-dsa-sha2-256s } SMIME-CAPS { IDENTIFIED BY id-slh-dsa-sha2-256s } }sa-slh-dsa-sha2-256f SIGNATURE-ALGORITHM ::= { IDENTIFIER id-slh-dsa-sha2-256f PARAMS ARE absent PUBLIC-KEYS { pk-slh-dsa-sha2-256f } SMIME-CAPS { IDENTIFIED BY id-slh-dsa-sha2-256f } }sa-slh-dsa-shake-128s SIGNATURE-ALGORITHM ::= { IDENTIFIER id-slh-dsa-shake-128s PARAMS ARE absent PUBLIC-KEYS { pk-slh-dsa-shake-128s } SMIME-CAPS { IDENTIFIED BY id-slh-dsa-shake-128s } }sa-slh-dsa-shake-128f SIGNATURE-ALGORITHM ::= { IDENTIFIER id-slh-dsa-shake-128f PARAMS ARE absent PUBLIC-KEYS { pk-slh-dsa-shake-128f } SMIME-CAPS { IDENTIFIED BY id-slh-dsa-shake-128f } }sa-slh-dsa-shake-192s SIGNATURE-ALGORITHM ::= { IDENTIFIER id-slh-dsa-shake-192s PARAMS ARE absent PUBLIC-KEYS { pk-slh-dsa-shake-192s } SMIME-CAPS { IDENTIFIED BY id-slh-dsa-shake-192s } }sa-slh-dsa-shake-192f SIGNATURE-ALGORITHM ::= { IDENTIFIER id-slh-dsa-shake-192f PARAMS ARE absent PUBLIC-KEYS { pk-slh-dsa-shake-192f } SMIME-CAPS { IDENTIFIED BY id-slh-dsa-shake-192f } }sa-slh-dsa-shake-256s SIGNATURE-ALGORITHM ::= { IDENTIFIER id-slh-dsa-shake-256s PARAMS ARE absent PUBLIC-KEYS { pk-slh-dsa-shake-256s } SMIME-CAPS { IDENTIFIED BY id-slh-dsa-shake-256s } }sa-slh-dsa-shake-256f SIGNATURE-ALGORITHM ::= { IDENTIFIER id-slh-dsa-shake-256f PARAMS ARE absent PUBLIC-KEYS { pk-slh-dsa-shake-256f } SMIME-CAPS { IDENTIFIED BY id-slh-dsa-shake-256f } }pk-slh-dsa-sha2-128s PUBLIC-KEY ::= { IDENTIFIER id-slh-dsa-sha2-128s -- KEY no ASN.1 wrapping -- CERT-KEY-USAGE { digitalSignature, nonRepudiation, keyCertSign, cRLSign } -- PRIVATE-KEY no ASN.1 wrapping -- }pk-slh-dsa-sha2-128f PUBLIC-KEY ::= { IDENTIFIER id-slh-dsa-sha2-128f -- KEY no ASN.1 wrapping -- CERT-KEY-USAGE { digitalSignature, nonRepudiation, keyCertSign, cRLSign } -- PRIVATE-KEY no ASN.1 wrapping -- }pk-slh-dsa-sha2-192s PUBLIC-KEY ::= { IDENTIFIER id-slh-dsa-sha2-192s -- KEY no ASN.1 wrapping -- CERT-KEY-USAGE { digitalSignature, nonRepudiation, keyCertSign, cRLSign } -- PRIVATE-KEY no ASN.1 wrapping -- }pk-slh-dsa-sha2-192f PUBLIC-KEY ::= { IDENTIFIER id-slh-dsa-sha2-192f -- KEY no ASN.1 wrapping -- CERT-KEY-USAGE { digitalSignature, nonRepudiation, keyCertSign, cRLSign } -- PRIVATE-KEY no ASN.1 wrapping -- }pk-slh-dsa-sha2-256s PUBLIC-KEY ::= { IDENTIFIER id-slh-dsa-sha2-256s -- KEY no ASN.1 wrapping -- CERT-KEY-USAGE { digitalSignature, nonRepudiation, keyCertSign, cRLSign } -- PRIVATE-KEY no ASN.1 wrapping -- }pk-slh-dsa-sha2-256f PUBLIC-KEY ::= { IDENTIFIER id-slh-dsa-sha2-256f -- KEY no ASN.1 wrapping -- CERT-KEY-USAGE { digitalSignature, nonRepudiation, keyCertSign, cRLSign } -- PRIVATE-KEY no ASN.1 wrapping -- }pk-slh-dsa-shake-128s PUBLIC-KEY ::= { IDENTIFIER id-slh-dsa-shake-128s -- KEY no ASN.1 wrapping -- CERT-KEY-USAGE { digitalSignature, nonRepudiation, keyCertSign, cRLSign } -- PRIVATE-KEY no ASN.1 wrapping -- }pk-slh-dsa-shake-128f PUBLIC-KEY ::= { IDENTIFIER id-slh-dsa-shake-128f -- KEY no ASN.1 wrapping -- CERT-KEY-USAGE { digitalSignature, nonRepudiation, keyCertSign, cRLSign } -- PRIVATE-KEY no ASN.1 wrapping -- }pk-slh-dsa-shake-192s PUBLIC-KEY ::= { IDENTIFIER id-slh-dsa-shake-192s -- KEY no ASN.1 wrapping -- CERT-KEY-USAGE { digitalSignature, nonRepudiation, keyCertSign, cRLSign } -- PRIVATE-KEY no ASN.1 wrapping -- }pk-slh-dsa-shake-192f PUBLIC-KEY ::= { IDENTIFIER id-slh-dsa-shake-192f -- KEY no ASN.1 wrapping -- CERT-KEY-USAGE { digitalSignature, nonRepudiation, keyCertSign, cRLSign } -- PRIVATE-KEY no ASN.1 wrapping -- }pk-slh-dsa-shake-256s PUBLIC-KEY ::= { IDENTIFIER id-slh-dsa-shake-256s -- KEY no ASN.1 wrapping -- CERT-KEY-USAGE { digitalSignature, nonRepudiation, keyCertSign, cRLSign } -- PRIVATE-KEY no ASN.1 wrapping -- }pk-slh-dsa-shake-256f PUBLIC-KEY ::= { IDENTIFIER id-slh-dsa-shake-256f -- KEY no ASN.1 wrapping -- CERT-KEY-USAGE { digitalSignature, nonRepudiation, keyCertSign, cRLSign } -- PRIVATE-KEY no ASN.1 wrapping -- }SLH-DSA-PublicKey ::= OCTET STRING (SIZE (32 | 48 | 64))SLH-DSA-PrivateKey ::= OCTET STRING (SIZE (64 | 96 | 128))---- Expand the signature algorithm set used by CMS [RFC5911]--SignatureAlgorithmSet 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, ... }---- Expand the S/MIME capabilities set used by CMS [RFC5911]--SMimeCaps SMIME-CAPS ::= { sa-slh-dsa-sha2-128s.&smimeCaps | sa-slh-dsa-sha2-128f.&smimeCaps | sa-slh-dsa-sha2-192s.&smimeCaps | sa-slh-dsa-sha2-192f.&smimeCaps | sa-slh-dsa-sha2-256s.&smimeCaps | sa-slh-dsa-sha2-256f.&smimeCaps | sa-slh-dsa-shake-128s.&smimeCaps | sa-slh-dsa-shake-128f.&smimeCaps | sa-slh-dsa-shake-192s.&smimeCaps | sa-slh-dsa-shake-192f.&smimeCaps | sa-slh-dsa-shake-256s.&smimeCaps | sa-slh-dsa-shake-256f.&smimeCaps, ... }END<CODE ENDS>¶Thanks toMike Ounsworth,Tomas Gustavsson,Daniel Van Geest,Carl Wallace,Phillip Hallam-Baker,Dieter Bratko,Vijay Gurbani,Paul Wouters, andRoman Danyliwfor their careful review and constructive comments.¶