Tail risk surfaced during the v0.1.0 review (PR #2). Filing for future tracking.
§10.2 says "Verifiers MUST verify both component signatures over the same canonical input; failure of either component is a signature failure." This is the correct AND semantics for a hybrid signature. You want both classical AND PQC to validate, defending against compromise of either family.
What's not stated: behavior in degraded or transition scenarios. If a verifier has the PQC public key but not the classical one (or vice versa), is the message rejected? If the hybrid algorithm is unknown to the verifier but one component is recognizable, do they extract and verify the recognized component? If an attacker breaks one component (e.g., classical ECDSA via key compromise), and a vendor's implementation accepts "either-of-two" as a fallback, the hybrid degrades to the weaker single algorithm.
The failure mode: a vendor implementing hybrid as "verify what you can, accept if any verifies" is a known anti-pattern. The spec language is correct on its face, but a single Implementer's Note codifying the AND semantics and explicitly forbidding either-of-two acceptance would prevent the pattern from showing up.
Proposed direction:
- Implementer's Note: "Verifiers MUST NOT accept a hybrid signature when only one component validates, even if the other component's public key is unavailable. A verifier missing keys for a component MUST reject the signature."
- Defined behavior when the verifier supports only a subset of the hybrid algorithms (reject with a specific error code rather than degrade silently)
Why deferred from v0.1.0: low confidence the misuse will appear in reference implementations within the v0.1.0 timeframe. Trigger that would raise priority: any v0.1 reference implementation ships hybrid as default, or any vendor's docs describe partial-verification as a fallback.
References: specification.md §10.2
Tail risk surfaced during the v0.1.0 review (PR #2). Filing for future tracking.
§10.2 says "Verifiers MUST verify both component signatures over the same canonical input; failure of either component is a signature failure." This is the correct AND semantics for a hybrid signature. You want both classical AND PQC to validate, defending against compromise of either family.
What's not stated: behavior in degraded or transition scenarios. If a verifier has the PQC public key but not the classical one (or vice versa), is the message rejected? If the hybrid algorithm is unknown to the verifier but one component is recognizable, do they extract and verify the recognized component? If an attacker breaks one component (e.g., classical ECDSA via key compromise), and a vendor's implementation accepts "either-of-two" as a fallback, the hybrid degrades to the weaker single algorithm.
The failure mode: a vendor implementing hybrid as "verify what you can, accept if any verifies" is a known anti-pattern. The spec language is correct on its face, but a single Implementer's Note codifying the AND semantics and explicitly forbidding either-of-two acceptance would prevent the pattern from showing up.
Proposed direction:
Why deferred from v0.1.0: low confidence the misuse will appear in reference implementations within the v0.1.0 timeframe. Trigger that would raise priority: any v0.1 reference implementation ships hybrid as default, or any vendor's docs describe partial-verification as a fallback.
References:
specification.md§10.2