Proposal: Trust Re-establishment Failure — identity and authorization continuity across cryptographic transition

[nmcitra]

A candidate migration-surface entry for Sprint 1 consideration.

The gap

QS03 covers signatures and trust chains losing trustworthiness — what an adversary can forge once an algorithm falls. QS05 and QS06 cover whether an organization can replace cryptography safely. This addresses a third condition: what a migration accepts as proof that the same legitimate entity still controls an identity, and what authority that identity inherits on the other side. The failure occurs where the algorithm swap executes correctly and the resulting credential is cryptographically strong.

Why it is not a QS03 consequence

The boundary test is whether the failure survives when no predecessor signature is forged and the successor's cryptography works. It does: a registration authority can authenticate the wrong entity through weak external evidence, an authoritative migration record can be corrupted, a shared secret can reach the wrong party, and authority can be rebound without revalidation — all with no forgery and every algorithm behaving as specified. One of the two attack classes requires no CRQC at all.

Standards basis

The CNSA 2.0 CMC profile draft mandates ML-DSA-87 throughout, which closes the classical-key authentication path. Where no post-quantum certificate has been provisioned yet, §5 requires that "procedural means that ensure the identity of the requestor MUST be used" — without specifying an evidence set or identity-proofing assurance level for those means. RFC 9810 §3.1.2 already draws the boundary this entry generalizes: graceful changeover is specified for a non-compromised key pair, and compromise requires re-initialization of the entire CA domain.

References verified 2026-07-29 against RFC Editor and IETF Datatracker canonical text. RFC 4210 and RFC 5272 are cited as the generations the CNSA profiles normatively reference, with RFC 9810 and RFC 10002 cited alongside as the current standards.

Placement

Standalone-first, absorption-ready. If the group defines QS03 broadly enough to cover successor-bootstrap consequences, this material should be preserved as a named subsection and mitigation class rather than dropped. Boundary discussion is in #11.

Routing

Placed in proposals/ per the sprint plan, with no QS number pending Sprint 1 selection — following the convention in #23. The README and the open contribution-infrastructure work (#18) use different routing conventions; happy to make any mechanical adjustment to path, naming, or evidence format without changing substance.

I come at this from systems architecture rather than cryptography, so I would welcome correction on the PKI specifics from anyone closer to the certificate-management work.