Summary

  • RFC 9802 standardises how HSS, XMSS and XMSSMT public keys and signatures appear in X.509 certificates and CRLs; it does not place the signer's one-time-key consumption history in the certificate.
  • A signature can validate while the operational system has already forked or rolled back its private-key state. For stateful hash signatures, backup and recovery therefore need an independently auditable, monotonic receipt.

One certificate, two histories

Imagine a certification authority with an offline primary signer and a recovery appliance. Monday's backup contains private-key material and the next available one-time-signature index, 41,200. During the week, the primary signs certificates and CRLs up to index 41,259. On Friday, an incident team restores Monday's image without first proving which indices were consumed. The recovery device signs a different object at 41,200.

Nothing in the restored bytes announces that the world has moved on. The public key is unchanged. The X.509 algorithm identifier is correct. Both signatures may verify when examined separately. The damaging fact exists in the relationship between them: two different messages have reused one OTS key.

RFC 9802 states the consequence without euphemism. If an attacker obtains signatures on two different messages created with the same OTS key, producing forgeries becomes computationally feasible. This is not an ordinary housekeeping defect. It attacks the premise under which a relying party accepts the signature.

The standard's achievement is still substantial. Published on the IETF Standards Track in June 2025, it specifies object identifiers and ASN.1 encodings for HSS, XMSS and the multi-tree XMSSMT scheme in the Internet X.509 PKI. It defines how their public keys and signatures fit certificates and certificate revocation lists, how parameters are represented, and which Key Usage bits are permitted. The official record and IETF history establish that scope.

But an OID answers “which algorithm should parse and verify these bytes?” It does not answer “which signing states have ever existed?” That second question belongs to operations.

A private key is not only secret material

Conventional recovery language often treats a private key as a secret object: protect it, copy it under controls, and restore it when hardware fails. Stateful hash-based signatures add a second asset—the history of which one-time components have already been consumed.

RFC 8554 makes the base rule explicit for LM-OTS: a private key is used to sign at most one message. HSS arranges many such keys in a hierarchy so that the signer can produce a bounded collection of signatures. RFC 8391 similarly defines XMSS and XMSSMT using WOTS+ one-time components, Merkle trees and addressable state. The algorithms can offer very large budgets, but “very large” is still finite and sequential use remains part of the security design.

The corresponding operational object is therefore not merely:

private key bytes

It is closer to:

private key bytes + committed next index + reservations + released signatures + abandoned states + recovery epoch

Losing the first component stops signing. Losing the other components can make apparently successful signing unsafe.

NIST SP 800-208 recommends LMS/HSS and XMSS/XMSSMT parameter sets and places key generation and signing inside hardware cryptographic modules. RFC 9802 imports that discipline into its security requirements and proposes additional operational measures: maintain a record of generated signatures or OTS indices, check it before releasing a new signature, keep the population moderate enough to audit, or reserve future state in advance. If reuse is detected, it calls for freezing new signatures, re-auditing prior output and considering revocation.

Those verbs—record, check, reserve, freeze, re-audit—describe a control system. None is performed by certificate parsing.

Why ordinary redundancy can be dangerous

For a stateless algorithm, two secured appliances holding the same key may be an availability design. An offline backup can be restored when the primary fails. RFC 9802 warns that applying those straightforward strategies to a stateful HBS key will lead to OTS reuse with high probability unless correct state management is guaranteed.

Three failure classes follow.

First is rollback. A valid backup contains an old counter and reopens indices already used after the snapshot. Second is split brain. Two devices begin from one state and sign independently. Third is acknowledgement ambiguity. A device persists state and generates a signature, but the orchestrator loses the response and retries elsewhere. Whether the first signature reached a relying party does not determine whether its index was consumed; the conservative record must treat attempted release as consequential.

Availability engineering therefore changes shape. Redundancy cannot mean freely cloning a stateful signer. It may require a single state authority, fenced leases over disjoint index ranges, one-way state reservation, hardware-enforced monotonic counters, or a recovery ceremony that proves the restored signer begins beyond every state ever reserved. The precise design is local. The required invariant is not.

What validation proves—and what it does not

RFC 5280 gives relying parties the certificate-path and CRL framework: verify signatures, validity periods, constraints, intended key use and revocation information under local policy. RFC 9802 makes the new algorithms legible inside that framework.

A successful check can support a bounded claim: the presented signature mathematically validates under the presented public key and declared algorithm. With a valid chain and suitable revocation data, it can support additional claims about certification path and current acceptance policy.

It does not reveal every signature the key generated. It does not show abandoned outputs, parallel appliances, unreconciled reservations, snapshots, restore attempts or a counter rollback. It does not prove that the remaining signature budget is sufficient for the certificate's lifetime. It cannot distinguish a pristine index history from a fork whose conflicting signature has not yet reached this verifier.

The evidence ladder is therefore:

  1. the bytes parse under the declared algorithm;
  2. the signature validates under the public key;
  3. the certificate path and current revocation view satisfy local policy;
  4. the signing index was uniquely reserved and durably consumed;
  5. no other device, snapshot or recovery epoch could consume it;
  6. released outputs are completely reconciled with the state ledger;
  7. the relying application accepts the signed object and produces its own result.

RFC 9802 standardises critical parts of the first three layers. The signer operator owns layers four through six. The application owns the seventh.

The narrow doctrine

Lu Heng's Running-Code Primacy is useful here because the RFC's OIDs are coordination artifacts, while unique state consumption is a fact that must survive in running systems. The minimum-specification principle also clarifies the allocation of authority: common encodings allow independent verifiers to interoperate; each operator still decides and proves how its signer persists state, allocates capacity and recovers from failure. The reality-layer argument warns against replacing that hidden machinery with the reassuring appearance of a valid certificate.

This does not diminish the standard. It keeps the standard honest. RFC 9802 tells systems how to recognize the cryptographic object. Trust in a stateful signer additionally depends on evidence that no earlier version of the object was allowed to sign again.

Sources