Summary

  • RFC 9909 assigns distinct X.509 identities to Pure SLH-DSA and HashSLH-DSA. A key carrying one mode’s OID is not permitted to generate or verify a signature carrying the other mode’s OID, even if a mathematical operation could be assembled.
  • Conformance depends on exact evidence: AlgorithmIdentifier parameters are absent, raw key bytes have the specified length and wrapping, keyUsage permits signing, and a separate validator records signature, path and policy results.

The certificate laboratory showed two green indicators. The first said the parser knew SLH-DSA. The second said the object identifier existed in its algorithm table. The certificate still failed.

In the illustrative test, its SubjectPublicKeyInfo named a Pure SLH-DSA parameter set while the certificate signature named the corresponding pre-hash family. A second artifact used matching names but serialized a NULL in an AlgorithmIdentifier whose parameters were required to be absent. Neither example is a reported product defect or live incident. They expose the narrow but consequential boundary published in RFC 9909: recognition of an algorithm family is not acceptance of an X.509 object.

RFC 9909 is a December 2025 IETF Standards Track specification from the LAMPS working group. It maps NIST’s Stateless Hash-Based Digital Signature Algorithm into the Public-Key Infrastructure X.509 conventions for certificates, certificate revocation lists, public keys and private keys. NIST standardized SLH-DSA in FIPS 205. The earlier name SPHINCS+ remains familiar, but the RFC says the standardized algorithm and SPHINCS+ are not compatible. A migration inventory that treats the two labels as interchangeable has already lost evidence before parsing begins.

The identifier space is deliberately specific. RFC 9909 lists twelve OIDs for Pure SLH-DSA and twelve for HashSLH-DSA. Within those families, the identifier distinguishes 128-, 192- or 256-bit security levels, small or fast parameter sets, and SHA-2 or SHAKE internal functions. HashSLH-DSA identifiers also name the pre-hash function. The NIST Computer Security Objects Register publishes the same branches.

This is not merely a menu for a user interface. The same OID identifies the public key, private key and signature algorithm. RFC 9909 draws an operational conclusion from that choice: a key identified with a Pure OID is not permitted to sign or verify a HashSLH-DSA signature, and the reverse is also forbidden. The text acknowledges that the cross-mode operation may be mathematically possible. PKIX interoperability nevertheless depends on one unambiguous interpretation, not on a library inventing a permissive bridge.

That distinction is useful because “same algorithm” is too coarse for incident evidence. If a certificate chain fails on one implementation but passes another, the review needs the exact public-key OID and signature OID, not a dashboard field containing SLH-DSA. It also needs the encoded parameters state. RFC 9909 requires the parameters component to be absent for every covered identifier, both for public keys and signatures. DER NULL is a value. It is not absence.

AlgorithmIdentifier history makes this easy to mishandle. Some older algorithm profiles use NULL; others omit parameters; permissive parsers sometimes accept both. Copying that tolerance into SLH-DSA can produce artifacts that appear harmless inside one stack and fail in a stricter verifier. The standard’s thin common layer is the exact byte contract. Local convenience cannot silently widen it and still claim universal interoperability.

The key bytes have equally exact boundaries. An SLH-DSA public key is the concatenation PK.seed || PK.root. Its raw size is 2*n, where n is 16, 24 or 32 bytes. SubjectPublicKeyInfo carries those raw octets directly in its BIT STRING. It does not add another ASN.1 wrapper around them. A private key is SK.seed || SK.prf || PK.seed || PK.root, or 4*n bytes, carried as raw octets in the OneAsymmetricKey privateKey field.

One optional field creates a practical compatibility choice. OneAsymmetricKey may also carry the public key. That enables a consistency check between the private and public portions, but RFC 9909 notes that some import functions have not adopted that structure and will reject a package containing the publicKey field. The operator must choose between a stronger local consistency check and the widest import compatibility, then test the actual key-store path. Neither outcome can be inferred from the certificate profile alone.

Key purpose remains visible. If keyUsage is present, an SLH-DSA certificate must include at least one signing purpose: digitalSignature, nonRepudiation, keyCertSign or cRLSign. It must not include keyEncipherment, dataEncipherment, keyAgreement, encipherOnly or decipherOnly. This is a signature scheme, not a key-establishment mechanism. Passing that check still does not prove that the certificate’s path is trusted, current, correctly named or authorized for an application. RFC 5280 continues to govern the wider certificate and CRL profile.

Pure and HashSLH-DSA also create a deployment decision before a CA certificate is issued. Pure mode operates on the full prepared message. HashSLH-DSA adds a specified pre-hash and can reduce the amount of material transferred to or held by a signing module. RFC 9909 says SLH-DSA processes its internal message in two passes, so the data must be retained in memory. Large CRLs or certificates with many subject alternative names may exceed an HSM’s signing interface or memory ceiling in Pure mode.

The verifier has its own constraint. For a certificate or CRL, the full object must be held because a randomizer taken from the signature is processed before the message, while X.509 places the signature after the material it covers. The object therefore cannot simply be verified as a one-pass stream in encoding order. HashSLH-DSA reduces the buffered internal message, but it does not certify a particular HSM, library, CA or relying party.

RFC 9814 is a useful neighbour precisely because its contract differs. It specifies Pure SLH-DSA for CMS SignedData and can use signed attributes so a compact DER set, rather than the entire content, reaches the signing operation. That CMS technique must not be smuggled into PKIX as proof that every certificate or CRL follows the same performance path. Shared algorithms do not erase application profiles.

The key is stateless, not unlimited. RFC 9909 sets a ceiling of fewer than 2^64 signing operations for one SLH-DSA tree and tells operators who might approach it to count signatures, destroy the key at an appropriate limit or bound the certificate lifetime. Each key pair must be independently generated. Private-key protection, quality randomness, fault resistance and side-channel controls remain implementation obligations. A post-quantum label does not suspend ordinary key custody.

Even the document’s correction channel needs precise status. The RFC Editor’s RFC 9909 errata page listed two records at the evidence freeze. Both were Reported, not Verified. They may be relevant to future review, but a reported submission cannot be silently substituted for accepted normative text. Publication, report, verification and implementation change are four separate events.

The operational receipt for an SLH-DSA certificate should preserve the original DER and its fingerprint; public-key and signature OIDs; whether parameters were absent or encoded; raw key and signature lengths; keyUsage; context; issuer and subject; trust anchors; revocation inputs; validator and cryptographic-provider builds; signature result; path result; policy decision; and rejection reason. If a fallback exists, its selection is another event, not evidence that the SLH-DSA path succeeded.

Heng Lu’s Running-Code Primacy makes the order plain: the standard is executable evidence only when real software accepts the exact common contract and produces an observable result. Minimum Initial Specification argues for keeping that shared layer narrow while leaving adoption and future choices local. Reality Layers stops a registered name from being mistaken for an executed property.

RFC 9909 gives operators an unusually clean opportunity to keep those layers apart. OID registration coordinates a name. Encoding produces bytes. Parsing recognizes a structure. Profile checking tests mode, parameters, lengths and purpose. Cryptography verifies a signature. Path validation evaluates a chain. Policy decides whether a relying party will act. The certificate is not “working” merely because the first lamp turned green.

Sources