Use of the SLH-DSA Signature Algorithm in the Cryptographic Message Syntax (CMS)
Extracted elements (27)
By including signed attributes (which necessarily include message-digest and content-type), implementations can avoid sending the full message content to an HSM or portable cryptographic token—only the much smaller signed-attributes set is transmitted for signing. This makes SLH-DSA practical with hardware security devices despite the algorithm's large signature-input requirements.
Only SLH-DSA pure mode with an empty context string is specified for CMS signed-data; pre-hash mode is intentionally excluded. When signed attributes are present, the small DER-encoded signed-attributes set is passed to the signing function instead of the full content, providing equivalent interface characteristics to pre-hash mode without requiring a separate mode specification.
SLH-DSA is motivated by the threat of Cryptographically Relevant Quantum Computers (CRQCs), which would break RSA, DSA, ECDSA, and EdDSA. As a post-quantum cryptosystem, SLH-DSA's security rests on hash-function properties rather than hard mathematical problems vulnerable to Grover's or Shor's algorithms.
SLH-DSA is stateless, unlike HSS/LMS and XMSS which require the signer to maintain state to prevent WOTS+ key reuse. Without that state requirement, SLH-DSA is considerably less operationally fragile, as accidental key reuse degrades but does not collapse security (unlike stateful schemes).
SLH-DSA pure mode and pre-hash mode always yield different signature values, even when signing the same content. Because this document exclusively specifies pure mode, implementations MUST NOT generate or accept pre-hash mode signatures under the OIDs defined here.
When an SLH-DSA public key or private key appears outside of a SubjectPublicKeyInfo or Asymmetric Key Package in an ASN.1 environment, it MAY be wrapped using the SLH-DSA-PublicKey or SLH-DSA-PrivateKey OCTET STRING types defined in this document.
When signed attributes are absent and there is concern about legacy implementations that do not support all hash functions, signers MAY choose to always use the SHA-256 algorithm identifier as the digestAlgorithm, even for SLH-DSA variants that internally use SHA-512 or SHAKE, since digestAlgorithm has no functional significance when signed attributes are absent.
Signature verification MUST include checking that the signatureAlgorithm field identifies SLH-DSA parameters that are consistent with the public key used to validate the signature.
The AlgorithmIdentifier for an SLH-DSA public key MUST use one of the twelve id-slh-dsa OIDs, and the parameters field of that AlgorithmIdentifier MUST be absent.
The signatureAlgorithm field in SignerInfo MUST contain one of the twelve SLH-DSA algorithm identifiers, and its parameters field MUST be absent.
To assist recipients using stream-based APIs, implementers SHOULD include signed attributes within any SignerInfo that uses SLH-DSA, allowing the recipient to avoid buffering the full signed content in memory. When signed attributes are present, they MUST contain content-type and message-digest attributes and SHOULD contain a CMSAlgorithmProtection attribute.
When an SLH-DSA AlgorithmIdentifier appears in an X.509 SubjectPublicKeyInfo, the certificate key usage extension MAY contain digitalSignature, nonRepudiation, keyCertSign, and cRLSign, and MUST NOT contain any other key usage values.
When signed attributes are present, a hash SHOULD be computed over the DER-encoded signed attributes using the same hash function that is used in the SLH-DSA tree. The signed attributes MUST include a content-type attribute and a message-digest attribute.
When signed attributes are present and SLH-DSA is used, the digestAlgorithms field in the SignedData MUST include the identifier for the one-way hash function used to compute the message digest.
When signed attributes are present, the digestAlgorithm in SignerInfo MUST identify a hash function that produces an output of at least twice the bit size of the hash function used internally in the SLH-DSA tree, to ensure collision resistance. Specific required pairings are defined: e.g., id-slh-dsa-sha2-128s/128f require SHA-256, 192-bit variants require SHA-512, and SHAKE variants require the corresponding SHAKE with doubled output.
SLH-DSA uses a Forest of Random Subsets (FORS) few-time signature scheme combined with a hypertree of WOTS+ one-time signatures across d layers of Merkle subtrees. A signature consists of a randomization string, the FORS signature, the WOTS+ signatures for each layer, and the authentication paths to the hypertree root. Verification succeeds only if the recomputed root matches the pre-trusted hypertree root.
The ASN.1 module SLH-DSA-Module-2024 (OID 1.2.840.113549.1.9.16.0.81) defines twelve SIGNATURE-ALGORITHM and twelve PUBLIC-KEY objects, the SLH-DSA-PublicKey and SLH-DSA-PrivateKey OCTET STRING types, and extends the CMS SignatureAlgorithmSet and SMimeCaps with all twelve SLH-DSA variants.
The CMS SignerInfo digestAlgorithm for each SLH-DSA variant is fixed: SHA-256 for 128-bit SHA-2 variants; SHA-512 for 192-bit and 256-bit SHA-2 variants; SHAKE128 with 256-bit output for 128-bit SHAKE variants; and SHAKE256 with 512-bit output for 192-bit and 256-bit SHAKE variants. In all four cases, the AlgorithmIdentifier SHOULD NOT include parameters.
Twelve algorithm identifier OIDs are defined for SLH-DSA, covering three security levels (128, 192, 256 bits), two performance variants (small 's' and fast 'f'), and two hash families (SHA-2 and SHAKE). OIDs range from id-slh-dsa-sha2-128s ({ sigAlgs 20 }) through id-slh-dsa-shake-256f ({ sigAlgs 31 }) under the NIST sigAlgs arc.
IANA assigned OID 81 with description 'id-mod-slh-dsa-2024' in the 'SMI Security for S/MIME Module Identifier (1.2.840.113549.1.9.16.0)' registry for the ASN.1 module defined in Appendix A.
Fault-attack countermeasures should be considered for SLH-DSA implementations. The typical countermeasure of verifying a signature before releasing its value is not effective against fault attacks on SLH-DSA [Ge2023]; redundancy by replicating the signature-generation process MAY be used instead, though SLH-DSA signature generation is already slow.
Implementations MUST protect SLH-DSA private keys; compromise allows signature forgery. Each key pair MUST be generated independently of all other key pairs in the SLH-DSA hypertree. A given SLH-DSA tree MUST NOT be used for more than 2^64 signing operations.
Implementers should consider protections against passive power and emissions side-channel attacks when deploying SLH-DSA, referencing the SLotH work on hardware acceleration that also demonstrates side-channel exposure.
Private key generation relies on random numbers, and use of inadequate PRNGs can result in little or no security. An attacker may reproduce the PRNG environment and search a small key space rather than brute-forcing the full space. RFC 4086 guidance on randomness MUST be followed.
To prevent algorithm-substitution attacks, the CMSAlgorithmProtection attribute (RFC 6211) SHOULD be included in signed attributes. Without it, an attacker could replace the signatureAlgorithm identifier with one that maps to a weaker or different algorithm.
SLH-DSA-PrivateKey is encoded as an OCTET STRING of SIZE (64 | 96 | 128) bytes for the 128-bit, 192-bit, and 256-bit security levels respectively. No additional ASN.1 wrapping is applied when it appears in the PrivateKeyInfo field of an Asymmetric Key Package.
SLH-DSA-PublicKey is encoded as an OCTET STRING of SIZE (32 | 48 | 64) bytes, corresponding to the 128-bit, 192-bit, and 256-bit security levels respectively. No additional ASN.1 wrapping is applied when the key appears in SubjectPublicKeyInfo.