Internet X.509 Public Key Infrastructure -- Algorithm Identifiers for the Stateless Hash-Based Digital Signature Algorithm (SLH-DSA)
Extracted elements (25)
HashSLH-DSA was introduced to accommodate Hardware Security Modules with data-transfer or memory limits: Pure SLH-DSA requires the entire certificate or CRL to be held in memory (the randomizer R must be extracted from the signature before M' is processed), while HashSLH-DSA reduces the size of M' by pre-hashing. This is also why streaming verification is not possible for certificates.
NIST defined separate OIDs for each combination of security level, fast vs. small, SHA-2 vs. SHAKE256, and pure vs. pre-hash mode rather than using parameters to distinguish them. This means 24 distinct OIDs total, consistent with the approach taken for other PQC algorithms like ML-DSA (RFC 9881).
SLH-DSA uses the same OID for both the public key and signature algorithm. Consequently, a key identified by a Pure SLH-DSA OID is not permitted to sign or verify using a HashSLH-DSA OID and vice versa, even though it is mathematically possible. CA operators must choose the mode at key generation time.
SLH-DSA and its predecessor SPHINCS+ are not compatible. The document uses SLH-DSA exclusively to refer to the FIPS 205 standardized algorithm.
Some private key import functions have not adopted the OneAsymmetricKey (RFC 5958) structure and will not accept a private key that includes the optional public key field, requiring a trade-off between key-pair consistency checking and broad import compatibility.
An SLH-DSA tree MUST NOT be used for more than 2^64 signing operations.
If the keyUsage extension is present in a certificate bearing an SLH-DSA or HashSLH-DSA public key, at least one of digitalSignature, nonRepudiation, keyCertSign, or cRLSign MUST be set; keyEncipherment, dataEncipherment, keyAgreement, encipherOnly, and decipherOnly MUST NOT be set.
Implementations MUST protect SLH-DSA private keys; compromise may result in the ability to forge signatures.
The AlgorithmIdentifier for an SLH-DSA public key MUST use one of the id-slh-dsa-* or id-hash-slh-dsa-* OIDs, and the parameters field MUST be absent.
The context string for SLH-DSA signature operations MUST be the empty string when used in the X.509 Public Key Infrastructure; the non-empty context string option defined in FIPS 205 Section 10.2 is not permitted.
The parameters component of AlgorithmIdentifier for all SLH-DSA and HashSLH-DSA algorithm identifiers MUST be absent, for both public key and signature uses.
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.
HashSLH-DSA pre-hash algorithm is embedded in the OID name after '-with-': SHA-256, SHA-512, SHAKE128 (256-bit output), or SHAKE256 (512-bit output), chosen to be twice the length of the internal hash/XOF for collision resistance. For example, id-hash-slh-dsa-sha2-128s-with-sha256 uses SHA-256 as the pre-hash.
SLH-DSA has 24 algorithm OIDs total: 12 for Pure SLH-DSA (id-slh-dsa-*) covering SHA-2 and SHAKE256 variants at 128s/128f/192s/192f/256s/256f parameter sets, and 12 for HashSLH-DSA (id-hash-slh-dsa-*) with the same parameter sets plus a pre-hash function suffix (e.g., -with-sha256). All OIDs are under the NIST sigAlgs arc (2.16.840.1.101.3.4.3), assigned values 20–31 for Pure and 35–46 for Hash variants.
SLH-DSA offers two signing modes: Pure SLH-DSA (slh_sign/slh_verify, Algorithms 22 and 24 of FIPS 205) signs the entire content directly, while HashSLH-DSA (hash_slh_sign/hash_slh_verify, Algorithms 23 and 25) pre-hashes the content before signing. This document specifies use of both modes in PKIX certificates and CRLs.
SLH-DSA parameter sets and their sizes at three NIST security levels: Level 1 (128s: 7856/32/64 bytes sig/pub/priv; 128f: 17088/32/64), Level 3 (192s: 16224/48/96; 192f: 35664/48/96), Level 5 (256s: 29792/64/128; 256f: 49856/64/128). Fast ('f') variants have larger signatures than small ('s') variants; HashSLH-DSA shares the same sizes as the corresponding Pure SLH-DSA parameter set.
SLH-DSA-PublicKey and SLH-DSA-PrivateKey are ASN.1 OCTET STRING types (defined in RFC 9814) that can be used to carry SLH-DSA or HashSLH-DSA keys in environments that use ASN.1 encoding but do not define their own raw-to-ASN.1 mapping. The bit ordering maps the most significant bit of the OCTET STRING to the most significant bit of the BIT STRING.
The ASN.1 module X509-SLH-DSA-Module-2025 imports Pure SLH-DSA public key and signature algorithm objects from RFC 9814 (SLH-DSA-Module-2024) and defines the 12 HashSLH-DSA public key identifiers, 12 HashSLH-DSA signature algorithm identifiers, and expanded SignatureAlgorithms and PublicKeyAlgorithms information object sets covering all 24 algorithm combinations.
IANA assigned OID 1.3.6.1.5.5.7.0.120 with description 'id-mod-x509-slh-dsa-2025' in the 'SMI Security for PKIX Module Identifier' registry for the ASN.1 module defined in Appendix A of this document.
Fault attacks can lead to signature forgeries for SLH-DSA (see CMP2018, Ge2023). The typical countermeasure of verifying before releasing a signature is not effective for SLH-DSA; instead, redundancy by replicating the signature generation process is recommended, though it adds to the already slow signing time.
Passive power and emissions side-channel attacks can leak the SLH-DSA private signing key; implementers should apply appropriate countermeasures such as those described in SLotH.
SLH-DSA security relies on preimage resistance of internal hash/XOF functions, not collision resistance; however, HashSLH-DSA additionally requires collision resistance of the pre-hash function, which is why pre-hash output lengths are twice the internal hash length. Inadequate PRNGs for key generation can critically weaken security.
An SLH-DSA private key is the raw concatenation of four n-byte elements: SK.seed || SK.prf || PK.seed || PK.root, yielding 4*n bytes total. In OneAsymmetricKey the privateKey OCTET STRING contains this raw encoding without ASN.1 wrapping.
An SLH-DSA public key is the raw concatenation of two n-byte elements PK.seed || PK.root, yielding 2*n bytes total where n is 16, 24, or 32 depending on the parameter set. In SubjectPublicKeyInfo the subjectPublicKey BIT STRING contains this raw octet string with no additional ASN.1 wrapping.
An SLH-DSA signature is the raw concatenation of three elements R || SIG_FORS || SIG_HT as defined in Section 9.2 of FIPS 205. The raw octet string is encoded directly in the BIT STRING field with no additional ASN.1 wrapping.