Summary

  • RFC 9814 defines two different CMS evidence paths: Pure SLH-DSA signs the content when signed attributes are absent, but signs DER-encoded SignedAttributes when they are present.
  • In the attribute path, the content is joined to the signature through message-digest, the CMS type through content-type, and the algorithm choices preferably through CMSAlgorithmProtection; an HSM receipt for the final signature proves only one link.
  • This arrangement can keep large content out of an HSM and support streaming verification, but it is not the SLH-DSA pre-hash mode. Treating the two as equivalent corrupts interoperability claims and audit language.

The receipt that says too little

Imagine an archive service approving a six-gigabyte evidence package. Its audit record says: key K signed at 14:03; the HSM returned success; the CMS object verifies. Every statement may be accurate. None establishes, by itself, that the six gigabytes reviewed by the authorizer were the bytes represented by the signed object.

The ambiguity is not a defect in SLH-DSA. It arises from where CMS places the boundary between content processing and signature processing. RFC 9814, published on the Standards Track in July 2025, specifies Pure SLH-DSA with an empty context string for CMS SignedData. It does not define the HashSLH-DSA pre-hash mode for this CMS use. Yet CMS already has an attribute mechanism that can make the object handed to a signer much smaller than the content. Similar interface shape does not mean identical cryptographic mode.

Leaders therefore need a more exact sentence than “the HSM signed the archive.” In one RFC 9814 path, that sentence is close to literal. In the other, the HSM signs a canonical encoding of claims about the archive. The difference determines who controls the digest, which records must survive, and what a later verifier can reconstruct.

Path one: no signed attributes

When SignerInfo.signedAttrs is absent, RFC 9814 applies the Pure SLH-DSA signing operation directly to the content. In compact notation, the signature input is the content octet string. The empty SLH-DSA context required by the specification is part of the algorithm invocation, not a CMS field chosen by an operator.

This path has an appealingly short evidentiary explanation: the signature is over the content. It also has operational consequences. A Pure SLH-DSA implementation needs the message for the signing operation. A remote signer or hardware boundary cannot be given an arbitrary external digest and told that it has thereby performed the RFC 9814 operation. If a large detached object must be signed, the interface must accommodate the actual content path expected by the implementation.

SignerInfo.digestAlgorithm still appears in the CMS structure, but in this path it is not used to prehash the content for SLH-DSA. RFC 9814 explains that the field has no significance to the signature calculation when signed attributes are absent. An implementation may select a value consistent with the SLH-DSA tree hash, and legacy CMS behavior creates compatibility considerations, but the field cannot be cited as proof that HashSLH-DSA was used. A parser that sees sha256 and silently converts the operation into “sign SHA-256(content)” has changed the protocol.

The verification cost is also architectural. For content arriving as a stream, the verifier cannot finish the Pure signature operation merely from a separately accumulated CMS digest. The content itself remains the message for SLH-DSA. The RFC notes that this path does not provide single-pass verification in the same way the signed-attribute path can.

Path two: signed attributes

When signedAttrs is present, CMS changes the value that is signed. The content is hashed using the algorithm identified for the signer. That result becomes the value of the mandatory message-digest attribute. The mandatory content-type attribute identifies the type of the encapsulated content. The complete attribute set is encoded with Distinguished Encoding Rules, and Pure SLH-DSA signs that DER encoding.

The chain can be written as four separate assertions:

  1. These were the content bytes supplied to the digest function.
  2. This hash algorithm produced this message-digest value.
  3. This content-type, digest and the other attributes formed this exact canonical DER byte string.
  4. This SLH-DSA key signed that DER byte string under the Pure mode required by RFC 9814.

Only the fourth assertion is necessarily inside the HSM. The first three may be performed by an application process, a CMS library, a gateway, or several components in succession. If the audit system retains only a key identifier and a signature-operation success code, it preserves the last assertion while discarding the joins that give the signature its business meaning.

The message-digest comparison is indispensable but not sufficient. A verifier recomputes the digest over the received content and checks equality with the signed attribute. It must also check the signed content-type against the actual encapsulated content type. Otherwise the same bytes can be asserted under the wrong semantic envelope. In systems where content type controls workflow, parser selection, retention or authorization, this is a security boundary rather than metadata decoration.

The digest algorithm belongs to the evidence too. With signed attributes, the relevant hash identifier appears in SignerInfo.digestAlgorithm, and the SignedData.digestAlgorithms set must account for the algorithms used by the signers. RFC 9814 also requires enough digest output for the collision-resistance expectations of the selected SLH-DSA parameter set. “The digest matched” is incomplete if the verifier cannot say which algorithm was selected, whether it was permitted, and whether the selection met the parameter-set requirement.

DER is part of what was authorized

Signed attributes are an ASN.1 set, but signatures operate on bytes. DER supplies one canonical encoding so independent parties can derive the same byte string. That canonicalization is not an administrative afterthought. It is the direct input to Pure SLH-DSA in the attribute path.

A dangerous audit design stores a rendered list such as “content type: data; digest: …; signing time: …” and assumes it can reproduce the signature input later. It may not preserve attribute order normalization, tag treatment, exact value encodings, duplicate handling, or unrecognized attributes. A faithful record retains the received CMS object and, where signing responsibility must be demonstrated, the exact DER byte string submitted for signature together with a deterministic derivation record.

This is also where middleware can become a hidden policy owner. An HSM may protect the private key perfectly while an unsigned adapter constructs the attributes, omits a required one, inserts a vendor attribute, or encodes a different set from the one displayed for approval. The strongest key boundary cannot compensate for an unaccountable message-construction boundary.

Algorithm identifiers must agree

RFC 9814 defines twelve object identifiers for the Pure SLH-DSA parameter sets used as signature algorithms. The algorithm parameters are absent. A verifier checks that the signature algorithm is consistent with the public-key algorithm carried through the certificate context. This closes one class of mismatch, but it does not relieve the CMS implementation from validating every relevant identifier.

The specification says the CMSAlgorithmProtection signed attribute should be included. Defined in RFC 6211, it places the digest and signature algorithm identifiers inside the signed attribute set. Its purpose is to resist algorithm-substitution attacks in which unprotected outer identifiers are altered while a signature value is reused or interpreted under a different algorithm story.

“Should” creates an operational decision, not permission to forget the field. A receiver needs an explicit policy for absence: accept under a documented compatibility profile, quarantine, or reject. A producer needs evidence that the attribute was actually included. A procurement claim that a product “supports RFC 9814” says nothing about its default, downgrade behavior or telemetry for this protection.

RFC 9909 covers the related X.509 algorithm identifiers and certificate usage for SLH-DSA. That certificate layer matters to key interpretation and path validation, but it is not the subject of this evidence boundary. A valid certificate path cannot show that an external process hashed the intended archive, just as a correct message-digest cannot show that the certificate was trusted for the transaction. The controls meet at verification; they should not be collapsed into one green indicator.

Why this is not pre-hash mode

The signed-attribute design resembles a pre-hash interface: a large message is reduced before the hardware signing call. The resemblance is operational. Cryptographically, the operations differ.

HashSLH-DSA, standardized alongside the Pure variant in FIPS 205 and addressed for certificates in RFC 9909, has its own algorithm definition and identifiers. RFC 9814 selects Pure SLH-DSA for CMS. In the signed-attribute path, CMS hashes the content to populate an attribute; Pure SLH-DSA then signs the DER encoding of the entire attribute set. The signed message is therefore not simply the external content digest. It includes the content type and any other signed attributes as encoded.

Calling this “pre-hash SLH-DSA” creates three failures. It can cause an implementer to choose the wrong identifier. It can lead a verifier to reconstruct the wrong input. And it can induce auditors to treat the digest receipt as though it were the complete signature request. Precise naming keeps the CMS content-binding stage distinct from the SLH-DSA mode.

Streaming is a benefit with a new owner

For large content, signed attributes offer a practical data path. A receiver can stream the content through the specified digest function, retain the compact result, receive or parse the signed attributes, check the digest and content type, and verify the signature over their DER encoding. The whole content need not be retained merely to feed the SLH-DSA verification call. A signer can similarly keep bulk bytes away from a constrained module.

That benefit assigns power to the component that computes the digest and constructs the attributes. If the hasher is outside the certified module, its software supply chain, input selection, error handling and observability become part of the trust boundary. If two services exchange only a digest without a content identity, length, source locator and immutable version, a retry can join the signature to a different object. If a streaming failure is retried from a partial offset, the digest may represent a suffix while the workflow label still names the full archive.

The correct unit of evidence is a transaction, not a signature blob. For each signing event, retain or make reproducible: content identity and immutable version; byte length; the hash algorithm and computed digest; content type; the complete signed-attribute set; exact DER-to-be-signed bytes or a verified reconstruction method; SLH-DSA parameter-set identifier; public-key and certificate identifiers; signature; validation time; policy version; and independent outcome codes for content-digest match, attribute validation, algorithm protection, signature verification and certificate-path validation.

What the standard does not promise

RFC 9814 is an interoperability specification. It does not establish vendor adoption, migration speed, HSM throughput, network performance or the suitability of any commercial implementation. No such claims should be inferred from the publication of the RFC.

Nor does a post-quantum signature identifier make the surrounding system uniformly post-quantum secure. Certificate paths can contain other algorithms. Content confidentiality is outside the signature. Randomness quality, side-channel resistance, fault resistance, key generation and private-key storage remain implementation duties. The RFC also carries a limit of fewer than 2^64 signatures per SLH-DSA key; lifecycle counters and rotation evidence cannot be delegated to ASN.1 parsing.

The earlier hash-based signature RFCs for XMSS and LMS illustrate why state, lifecycle and interface conditions matter even when the primitive is well specified. SLH-DSA is stateless, but “stateless” does not mean “without operational state”: organisations still need inventories, certificate histories, policy versions, counters, revocation status and durable verification material.

A minimum acceptance test

Before approving an RFC 9814 implementation, require paired test vectors for both CMS paths. For the no-attribute case, demonstrate that altering one content byte fails verification and that an externally supplied content digest cannot be substituted for the message. For the attribute case, alter the content, message-digest, content-type, one noncritical signed attribute, the DER encoding, digest identifier, signature identifier and certificate key in separate tests. Each should fail at a named stage, not merely produce a generic error.

Then test detached and encapsulated content; multi-gigabyte streaming; interrupted and resumed streams; duplicate or unrecognized attributes; absent CMSAlgorithmProtection; algorithm-parameter presence where absence is required; and certificate-path failure after signature success. Capture the receipt set for each run. If the system cannot explain which stage rejected a mutation, its audit surface is not ready for delegated approval.

This is Heng Lu’s minimum-initial-specification principle applied to a cryptographic transition: publish the smallest precise interface that allows voluntary adopters to test reality. The “reality layer” is not the product’s compliance label. It is the reproducible mapping from content bytes to digest, from digest and type to DER attributes, and from those bytes to a verifiable Pure SLH-DSA signature. Running code has primacy only when the receipts let another party rerun the claim.

Sources