Summary

  • RFC 9955 classifies hybrid digital signatures by properties that do not automatically travel together. Backward compatibility, hybrid unforgeability, strong non-separability, simultaneous verification, proof composability, performance and ease of approval can conflict.
  • The same hybrid signature may deliver hybrid unforgeability to a modern verifier that checks both components, while a legacy verifier that accepts one component does not receive that property. Counting hybrid signatures at the sender therefore does not measure assurance at the receiver.
  • Operators need a secret-free hybrid-verification receipt that records the signed object, expected construction, component and final results, artifact location, key-use scope, verifier policy and build, approval boundary, receiver cohort and expiry of any legacy exception. This is local operating guidance proposed here, not an RFC 9955, IETF or NIST requirement.

One object, two security statements

The ordinary status line—“signature valid”—is too small for a hybrid transition.

In a single-algorithm system, that line can still conceal important facts: which key was trusted, how its certificate was validated, which policy applied and when the decision occurred. A hybrid system adds another ambiguity. A sender can generate a signature containing two component algorithms, yet the receiver may be permitted to verify only one. RFC 9955 calls backward compatibility a verification property. The sender did the hybrid work; the verifier’s implementation or policy determines how much of it counts.

That distinction matters because assurance is exercised at acceptance. A document, software package, routing object, certificate or administrative order becomes consequential when a verifier lets it cross a boundary. If one receiver verifies both components and another checks only the traditional one, it is misleading to treat their two green lights as the same green light. The first may obtain a security claim that survives the failure of either component. The second has chosen compatibility with a legacy estate and relies on the component it understands.

RFC 9955 does not condemn that choice. It describes why it is a choice. The document is Informational, published in the IETF Stream in July 2026. It does not standardize a combiner, prescribe migration for a sector or allocate a code point. Its value is the map: properties often grouped under the word “hybrid” occupy different points on several spectrums, and some cannot be maximized together.

The governance error would be to turn that map back into a binary badge.

The artifact is not the guarantee

RFC 9955 uses “artifact” for evidence of the sender’s intent to hybridize that remains after a component is removed. Where that evidence resides changes who must notice it and what else the security argument must trust.

An artifact can live inside the signature, at the algorithm layer. It can sit in a certificate or negotiation mechanism, at the protocol layer. It can be a label in the signed message, at the policy layer. Those placements are not decorative. They assign work to different actors.

If the artifact lives in the message, the verifier needs permission and logic to inspect the message for hybrid intent. This can create a circular dependence: the message’s authenticity depends on the signature, while the meaning of the signature depends on a message label telling the verifier that two components were intended. If the artifact lives in a combined certificate, the claim inherits certificate-chain provenance and policy. If it lives in system configuration, later analysis cannot describe the cryptographic property without recovering the exact implementation and configuration that governed the decision.

Weak Non-Separability means removal leaves such evidence, but a separated component signature may still verify. Detection can require a careful verifier or a later investigation. Strong Non-Separability moves the decisive property into the construction: separating the hybrid produces no valid component signature. Add Simultaneous Verification and a normally operating verifier cannot terminate successfully on one component before it has established the result of both.

These are materially different outcomes. A dashboard field reading hybrid=true proves none of them. Nor does the word “concatenated,” because RFC 9955 shows that concatenated, nested and fused approaches can place artifacts differently. The relevant question is not merely how signatures were assembled. It is where hybrid intent survives, who can observe it and what the verifier does when one component is missing or fails.

Compatibility spends assurance at the receiving edge

Backward compatibility is attractive for good reasons. Long-lived infrastructure cannot always replace every verifier at once. Procurement cycles may be counted in years. Root certificates, archives and regulated records may outlive the software that first checked them. A sender may need to begin post-quantum signing while old receivers continue operating.

The cost is not abstract. RFC 9955 says backward compatibility and Strong Non-Separability are inherently mutually exclusive. A strongly non-separable construction must fail when a component is removed; a legacy verifier needs a path that can still accept what it understands. The RFC also says that when backward compatibility is acted upon—when the verifier actually skips a component—it is mutually exclusive with hybrid unforgeability at that verification event.

The same signature can therefore cross two organizational boundaries under two assurance levels. This is a receiver-cohort problem, not just an algorithm rollout. A migration register that records only “hybrid signing enabled” measures the producer. It does not identify the population still consuming the object as a traditional signature.

That population needs an owner and an end date. Otherwise compatibility becomes a permanent, unpriced exception. The modern verifier’s success can create false confidence for the whole institution while the consequential legacy path remains open.

Key reuse makes the institution part of the proof

RFC 9955 also explains a less visible exposure. If a component extracted from a hybrid signature can be presented to a verifier for that component—possibly in another system or protocol—the attacker’s target need not be the intended hybrid recipient. A policy on the primary verifier does not protect every other place where the same key is accepted.

Restricting reuse of component keys can reduce that risk. Certificates can describe allowed key uses. Separate keys can be reserved for the hybrid construction. But the RFC is precise about the boundary: this is a policy requirement, not a cryptographic assurance. It works only if every relevant signer and verifier follows it consistently.

That changes the unit of audit. The owner cannot inspect one application, see that it requires two checks and declare the risk closed. It must know where the component public keys are trusted, which protocols accept them, whether certificate constraints are enforced and whether an unmanaged verifier can turn a hybrid component into an ordinary credential.

In Heng Lu’s terms, policy should mirror the operational boundary. The written prohibition on key reuse is not the running system. Its truth depends on the population that enforces it.

Approval belongs on another axis

Security properties and approval logistics are easy to conflate because both produce authoritative-looking labels.

RFC 9955 separates a need-for-approval spectrum from the non-separability spectrum. At one end, a new fused construction may need a new analysis or approval. At the other, a wrapper can call component implementations as black boxes, making it easier to retain their existing validation status. The logistical advantage is real. It does not manufacture simultaneous verification or strong non-separability.

NIST’s post-quantum FAQ accommodates dual signatures under current standards when at least one component is a properly implemented, approved algorithm, and describes verification as requiring all component signatures to succeed. FIPS 204 separately standardizes ML-DSA. These are useful, bounded facts. They do not justify a sentence such as “the hybrid assurance is approved” without saying which component, module, combiner, policy and runtime decision the approval covers.

A procurement team can therefore satisfy an approval requirement while buying a design whose security argument relies on message inspection, certificate-chain policy or consistent key-use restrictions. That may be the correct compromise. It should be visible as a compromise.

A receipt for the decision that actually happened

The missing record is not a copy of the signature. The signed object already exists. What is missing is evidence of the verifier’s decision context.

A hybrid-verification receipt should be generated at consequential acceptance boundaries and retained with the protected audit trail. It should bind:

  1. the digest and context of the signed object, plus the exact hybrid construction and version expected;
  2. the component algorithms, non-secret public-key identifiers and the certificate or provenance chains that were actually validated;
  3. the location of each hybrid-intent artifact and whether this verifier examined it;
  4. the required result vector, the observed result for every component and the final composite decision;
  5. whether the construction and execution provided weak or strong non-separability, and whether verification was simultaneous, without inferring those properties from a product label;
  6. the verifier software build, configuration hash and policy revision;
  7. component-key reuse restrictions and the defined enforcement population;
  8. approval or validation status attached to the exact component or module it covers;
  9. the receiver cohort and any compatibility exception, with its accountable owner and expiry;
  10. the failure and disclosure behavior that controls whether partial results can influence the decision;
  11. decision time, evidence-retention window and a trigger for re-verifying long-lived material;
  12. the person or role empowered to reject, roll back or quarantine acceptance when the required assurance cannot be reproduced.

The receipt must remain secret-free. It needs hashes, versions, bounded identifiers and protected references, not private keys or sensitive document content. Its function is not to strengthen weak mathematics. It prevents a local valid bit from being promoted into a stronger institutional claim than the verifier earned.

What evidence would change a decision

For an operator, the practical test is cohort-based rather than slogan-based.

Take one reviewed corpus of signed objects. Run it through every materially distinct verifier build and policy. Include missing components, invalid first and second components, altered artifact labels, certificate-chain changes and attempts to reuse a component key in another accepted context. Record not just pass or fail, but which checks occurred before the decision and what information was exposed.

Then compare the result to the institution’s claim. If the claim is “every consequential receiver obtains hybrid unforgeability,” any receiver that accepts one component is a failed claim, even if compatibility was intentional. If the claim is narrower—“senders emit dual signatures while named legacy cohorts temporarily rely on the traditional component”—the evidence may support it, provided the cohorts, owner and expiry are explicit.

The Minimum Initial Specification principle is useful here. Standardization should begin with the smallest claim the evidence can carry. A component is approved. A sender emitted two signatures. A particular verifier checked both. A construction is strongly non-separable. Those are four different statements. Combining them into “quantum-safe” without the intervening evidence would convert a migration label into advocacy.

Limits

This analysis does not report a deployed stripping attack, a broken product or a failed public procurement. The sources provide standards and design analysis, not prevalence data. Strong Non-Separability and Simultaneous Verification are not declared universally superior; they can conflict with compatibility, performance and approval constraints. A verifier receipt cannot repair an unsuitable construction or guarantee future cryptanalysis.

It can do something more modest and more operationally valuable: preserve which assurance was exercised, by whom, under which policy, before the single word valid erased the difference.

Sources