Summary

  • RFC 9858 registers additional SHA-256 and SHAKE256 parameter sets for HSS/LMS; those identifiers tell a verifier how to interpret a signature, not whether the signing appliance preserved unique leaf state.
  • A valid signature can coexist with a failed custody system if another process, restored backup or cloned module later signs from the same leaf index.
  • The decisive controls are non-exportable private material, durable advancement before signature release, explicit recovery rules, capacity telemetry and a tested successor-key transition.

A signature can pass and still leave the dangerous question unanswered

RFC 9858 is an important interoperability extension. Published by the IRTF Crypto Forum Research Group in October 2025, it adds HSS/LMS parameter sets using SHA-256 with 192-bit outputs and SHAKE256 with 192- or 256-bit outputs. The corresponding LM-OTS and LMS identifiers now sit in IANA registries, so implementations can announce a precise combination and verifiers can apply the matching algorithm.

That is a statement about cryptographic grammar. It is not a statement about custody history.

LMS signs with a leaf numbered q. The private key advances through a finite Merkle tree, and the one-time key behind a leaf must not be used twice. RFC 8554 is blunt about the consequence: reusing a private-key state can destroy the scheme's security guarantees. A verifier receives the message, signature, public key and enough authentication material to recompute the root. It can decide that this signature is internally valid. It cannot infer from that one transcript that no second signer, failed transaction or restored snapshot has emitted another signature for the same q.

This creates two separate evidence planes. The parameter plane answers: which hash family, output length, tree height and Winternitz setting govern verification? The custody plane answers: who owned the mutable state, when did it advance, what became durable, which signature escaped, and whether any other copy could resume from an earlier point? RFC 9858 strengthens the first plane by adding choices. It does not collapse the second into the first.

The 192-bit sets also make a real engineering trade. They reduce key and signature material relative to 256-bit-output counterparts, while accepting a smaller security margin. Choosing SHAKE256 rather than SHA-256 can align performance with a platform's primitives, but equal output sizes do not create an operational guarantee. A procurement record that says “RFC 9858 supported” therefore leaves unanswered which registered set was selected, why it fits the cryptoperiod, and how the state machine is protected.

NIST SP 800-208 turns that missing operational layer into concrete discipline for approved stateful hash-based signatures. For key generation in hardware modules, private keying material is non-exportable. Before a signature is released—or another signing request is accepted—the leaf index must be incremented and committed to nonvolatile storage. The order matters. A filesystem write acknowledged only in a cache is not proof that the new state survived a power loss. A cloned backup is not ordinary resilience if both copies can ever sign.

Recovery is consequently an architecture, not a restore checkbox. A design may keep independent trees under a higher-level HSS hierarchy, pre-assign disjoint ranges to controlled signers, or move to a separately generated successor key. What it must not do is restore an old private-state image and assume the verifier will detect reuse. The verifier is not the custody auditor.

Exhaustion deserves the same seriousness. Tree height sets a finite leaf budget. Consumption can accelerate through retries, failed releases, conservative reservation and parallel demand. Systems need a trustworthy high-water mark and enough lead time to distribute and authorize a successor public key. Once a conflicting signature has escaped from a reused one-time leaf, later reconciliation cannot make that exposure un-happen.

The practical reading of RFC 9858 is therefore layered. Registration makes a parameter set intelligible. Verification establishes that one presented signature matches its public key and message. Only operational evidence can establish that the signer advanced exactly once. Treating these as one claim turns a clean VALID result into false comfort.

Sources