Summary

  • RFC 9955 treats hybrid signatures as a spectrum of design goals. A multi-component artifact does not independently establish that every receiver checked every component.
  • Backwards compatibility may permit one-component verification; Strong Non-Separability and Simultaneous Verification demand more specific construction and honest-verifier behavior.

A message arrives with a traditional signature and a post-quantum signature. The audit log calls it “hybrid-signed.” That is a useful description of what was presented. It is not yet a description of what the receiving system did. Did the receiver require both components? Did it verify one because a legacy pathway permits that? Did a verifier stop after a first success? Was a hybridization artifact preserved for later review? Those are separate questions with separate owners.

RFC 9955, an IETF Informational RFC published in July 2026, does not prescribe a universal combiner or deployment. It maps the competing properties a hybrid digital-signature scheme may seek: hybrid authentication, proof composability, different degrees of non-separability, backwards and forwards compatibility, Simultaneous Verification, performance and space efficiency. Its value is precisely that it makes the trade-offs visible rather than allowing the word “hybrid” to hide them.

The document defines a hybrid signature scheme as multi-algorithm. It discusses a security premise in which authenticity can remain if at least one component scheme remains secure, subject to the property the scheme actually claims. That is not a licence to infer a universal receiver outcome from the number of components sent. The sender produces an artifact; the system that accepts it still has a rule, an implementation and a record of which checks it performed.

The distinction sharpens around stripping. RFC 9955 calls an artifact evidence of an intent to hybridize that can remain after a component is removed. Under Weak Non-Separability, a separated component can still verify while the artifact makes the separation detectable through further receiver-side or audit investigation. An artifact in a message, protocol, certificate or policy can therefore be valuable evidence without becoming an automatic verification failure. Strong Non-Separability goes further: separating the hybrid signature causes the component verification to fail.

The relevant claim must name which property is in scope; “we saw two signatures” does not name it.

Backwards compatibility makes the operational consequence unavoidable. The RFC describes a property under which a legacy receiver may verify only one component, generally the traditional component, and ignore the post-quantum one. That can be a deliberate transition choice. It is also why a hybrid-signed input cannot, on its own, prove that every receiver executed an all-component rule. Simultaneous Verification is stronger still: it requires the information for all components and prevents an honest verifier from successfully ending after one component succeeds.

The RFC explicitly does not prevent a malicious verifier from skipping checks by design.

Do not collapse this signature discussion into TLS hybrid key exchange: RFC 9954 concerns hybrid key exchange in TLS 1.3, while RFC 9955 concerns a digital-signature design spectrum. Nor does terminology substitute for an operating rule; RFC 9794 supplies vocabulary, not a finding about a particular deployment.

Daniel Kade applies the reality-layer discipline in docs/heng-lu-note.md as an editorial lens, not an IETF requirement. Keep the signed input, claimed scheme and component identifiers, verifier policy version, component-level result or failure evidence, acceptance/exception record and a separately scoped audit observation distinct. That record makes a transition explainable without granting the easiest field in a log the authority to declare a security outcome.

Sources