From ffff22c845fcabcb3d02df09f11ae71cf596bb29 Mon Sep 17 00:00:00 2001 From: nmcitra Date: Mon, 3 Aug 2026 12:21:01 -0600 Subject: [PATCH] Proposal: Trust Re-establishment Failure (identity and authorization continuity across cryptographic transition) Candidate migration-surface entry for Sprint 1 consideration. Placed in proposals/ per the sprint plan; carries no QS number pending selection. References verified 2026-07-29 against RFC Editor and IETF Datatracker text. --- ...PROPOSAL_Trust-Re-establishment-Failure.md | 104 ++++++++++++++++++ 1 file changed, 104 insertions(+) create mode 100644 proposals/PROPOSAL_Trust-Re-establishment-Failure.md diff --git a/proposals/PROPOSAL_Trust-Re-establishment-Failure.md b/proposals/PROPOSAL_Trust-Re-establishment-Failure.md new file mode 100644 index 0000000..c933e8e --- /dev/null +++ b/proposals/PROPOSAL_Trust-Re-establishment-Failure.md @@ -0,0 +1,104 @@ +## Trust Re-establishment Failure — Identity and Authorization Continuity Across Cryptographic Transition + +**Surface:** Migration. **Evidence:** Theoretical attack classes; demonstrated for the authority-compromise component. + +**Description:** + +Trust re-establishment failure occurs when an organization replaces a quantum-vulnerable key, certificate, signature algorithm, or trust anchor and accepts the successor's identity and inherited authority on the strength of the predecessor's, without independently evaluating either at the assurance their consequence requires. Re-issuing a credential does not by itself re-establish the trust that credential represented. + +The invariant the failure violates: + +> Continuity cannot confer more assurance than the evidence that survives the transition. + +Successor-side claims include *this is the same subject*, *this issuer remains authoritative*, *this role still applies*, *this delegation remains valid*, *this session may continue*, and *this trust binding may be re-pointed*. The general failure class is **assurance inheritance**: a successor claim is accepted at an assurance level or authority scope the surviving transition evidence does not support, because the predecessor claim existed. Its attack form is **transition laundering** — an inadequately proven or compromised identity is converted into a durable successor credential whose stronger cryptography obscures the weakness in the transition evidence. The resulting credential can be cryptographically valid and institutionally false. + +Assurance inheritance is not unique to post-quantum migration. Cryptographic transition creates a deadline-driven instance of it in which predecessor evidence and successor authority may be rebound across large credential populations under a common migration procedure. + +**Standards basis — predecessor trust may carry a successor, but only while the predecessor's assurance holds.** Current CMP, RFC 9810 §4.4 (which obsoletes RFC 4210), specifies root CA key update by having the CA protect its new public key with its previous private key, and permits an end entity to acquire the new CA public key either "out-of-band" or "by using online messages also containing the link certificates 'new with old'." Predecessor trust can therefore establish successor trust directly. RFC 9810 also states the condition attached to that mechanism: a graceful, scheduled changeover is specified "from one non-compromised CA key pair to the next," and "if the CA key is compromised, re-initialization must be performed for all entities in the domain of that CA" (§3.1.2, requirement 10). The standard already separates ordinary continuity from assurance failure and assigns a different procedure to each. RFC 5011 mitigates an analogous successor trust-anchor acceptance problem for DNSSEC using a hold-down timer and revocation signalling, while noting that hold-down mitigates rather than resolves the compromise case. Post-quantum root rekeying remains open in current work: `draft-wang-lamps-root-ca-cert-rekeying-04`, an active individual Internet-Draft, proposes a one-way `newWithOld` link certificate for deployed devices that cannot install a new root, and its Security Considerations section is not yet written — a draft in progress rather than evidence of a defect. The unresolved question for the CNSA certificate-management transition is whether an equivalent assurance-loss boundary governs end-entity successor issuance, and the identity and authority rebound onto that successor. + +**Certificate-policy practice already implements part of this boundary.** Published federal certificate policies constrain routine rekey — by the assurance level of the successor, by whether subscriber information remains valid, by periodic identity re-establishment, and by different handling after compromise. The gap described here is therefore not that PKI has never distinguished continuity from reproofing. It is that post-quantum migration produces an algorithmic assurance-loss event and a population-scale rebinding event together, while the CNSA certificate-management profiles state no general rule for when degraded predecessor evidence, degraded issuer assurance, or migration-derived records must trigger the stronger re-establishment path. The same migration also reaches authority and session state outside the certificate profile entirely. + +**Standards basis — the predecessor credential is the specified continuity proof.** RFC 8756 §4 requires that "the private signing key used to generate the encapsulating SignedData MUST correspond to the public key of an existing signature certificate unless an appropriate signature certificate does not yet exist, such as during initial enrollment," and Appendix A.1.1 describes the result: "The CA will verify the authorization of the previously installed certificate and issue an appropriate new certificate to the end-entity." Rekey follows the same pattern (Appendix A.2.1). The profile leaves additional identity and authorization requirements to certificate policy and deployment procedure. + +**Standards basis — the profiles state a validity boundary but no general assurance-degradation rule.** RFC 8756 §9: "the certificate policy for a particular environment will specify whether expired certificates can be used to sign certification requests." The proposed CNSA 2.0 successor repeats the framing — "some organizational policies might allow a grace period during which an expired certificate could be used to rekey" (`draft-jenkins-cnsa2-cmc-profile-03`, Appendix A.2). Expiry is recognized as a reason a credential may no longer bootstrap its successor. Neither document states a general rule tying successor-bootstrap authority to the continuing assurance of the credential, its issuer, its proofing process, or its algorithm. + +**Standards basis — the post-quantum profile closes the cryptographic path and relocates the decision.** `draft-jenkins-cnsa2-cmc-profile-03` mandates ML-DSA-87 for signatures throughout (§4), including the certification request itself (§5.1, §5.2). A classical RSA or ECC key therefore cannot authenticate a request for its post-quantum successor: the profile does address the current algorithm's loss of assurance, by refusing it at the protocol acceptance layer. Where no appropriate ML-DSA signature certificate has already been provisioned — which includes initial organizational enrollments where no ML-DSA credential has been pre-provisioned — §5 requires instead that "procedural means that ensure the identity of the requestor MUST be used." The requirement has content: it names the outcome the procedure must achieve, and inherits CMC's request-authentication and proof-of-possession controls. The profile separately assumes (§4) that required trust anchors have been securely provisioned. What it does not carry is a standardized evidence set or identity-proofing assurance level, in either the profile or the RFC 5272 machinery beneath it. + +Appendix A.1 illustrates three enrollment paths, and Appendix A states that it does not intend to limit the use of CMC. Across the illustrated paths and any a community defines by policy, the same property holds: + +- **Previously certified signature key-pair** requires an already-provisioned ML-DSA certificate — available where a manufacturer or provisioning system supplied one, unavailable where the migration is itself the first post-quantum issuance. +- **Shared secret distributed securely out of band** specifies how the secret is used and verified, and RFC 5272 leaves the distribution method outside the protocol. Neither document assigns an identity-proofing assurance level to the distribution, or states how the recipient's identity is established before the secret is handed over. +- **RA authentication** carries substantial normative process in the profile and in RFC 5272 — request wrapping, RA authorization, algorithm enforcement, CA verification of RA authority. What is not standardized is the evidence an RA must examine to decide a requester is authentic, the assurance level that determination must satisfy, or how the determination is revalidated when its source records may derive from the credentials being replaced. + +This is a security boundary intentionally delegated to certificate policy and deployment, which is appropriate for a certificate-management protocol. It becomes unusually consequential during mass cryptographic transition, when the delegated determination is repeated at scale under shared migration assumptions, on a deadline, and sometimes from records built out of the credentials being retired. A migration can be cryptographically conformant while resting on materially different and potentially inadequate identity re-establishment. + +**[theoretical] Procedural-assurance failure at successor enrollment.** Where the evidence behind the mandated procedural means is weak or derived from the credentials being replaced, the successor credential is issued to the wrong entity. This failure requires no CRQC: a corrupted migration inventory, a shared secret delivered to the wrong party, or an RA operating at migration volume against unreconciled records is sufficient. What makes it a transition risk rather than ordinary enrollment risk is scale and timing — the determination is repeated at scale under shared migration assumptions and source records, and the result may thereafter be treated as high-assurance for the successor credential's remaining lifetime. + +**[theoretical] CRQC-forged predecessor claim.** If a predecessor credential or issuing chain becomes forgeable, a signature from it no longer establishes control, and any determination that consumed such a signature — directly, or indirectly through records built from those credentials — inherits the failure. The forgery step is not demonstrated; the acceptance of predecessor evidence as successor proof is specified, above. + +**[demonstrated] Authority-level trust contamination.** Rogue certificates issued under a compromised authority remained valid under widely trusted chains until relying parties changed their trust decisions concerning the issuer. Replacing end-entity certificates could not cure compromise of the issuing authority. The DigiNotar compromise demonstrates this component of the class; it is not a demonstration of transition laundering across a cryptographic migration. + +The failure can be particularly difficult to detect in long-lived machine identities and autonomous workloads that enroll without interactive proofing, retain persistent entitlements, and survive multiple credential rotations. Where such an identity also holds delegated authority to act on behalf of others, each rotation may carry the delegation forward on the same evidence that carried the identity. + +**Common Examples of Vulnerability:** + +1. A migration workflow authenticates a same-subject rekey with the credential being replaced, as the certificate-management profile specifies (RFC 8756, Appendix A.2.1), without a policy statement on whether that credential's assurance still supports the inheritance. +2. Separately from certificate issuance, the surrounding IAM and orchestration layer rebinds OAuth grants, mTLS role mappings, JWT or SAML issuer trust, delegated permissions, active sessions, and cached authorization decisions onto the successor identity without review. This inheritance is deployment-dependent and outside the certificate-management profile. +3. An organization satisfies a requirement for "procedural means that ensure the identity of the requestor" with a procedure never assessed for assurance — a helpdesk ticket, an email confirmation, a spreadsheet of expected serial numbers, or an RA operator approving at migration volume. +4. The authoritative record used to approve bulk re-enrollment is built by discovering and trusting the certificates being replaced, or is drawn from an issuance database whose integrity depends on the credentials under migration. +5. An organization migrates leaf credentials but retains a quantum-vulnerable or otherwise compromised root CA, intermediate CA, registration authority, recovery key, or administrative approval path as the basis for establishing replacement identities. +6. A long-lived workload is re-enrolled after an outage using only possession of a pre-transition secret, with no independent attestation, accountable human confirmation, inventory reconciliation, or constrained re-entry period. +7. Emergency migration procedures restore broad authorization before the organization can determine which identities, credentials, delegations, or approval records were exposed. +8. A certificate policy states whether *expired* credentials may sign certification requests but is silent on whether *cryptographically weakened* credentials may, leaving the decision to the enrollment implementation by default. + +**How to Prevent:** + +1. Treat cryptographic transition as trust re-establishment, not only key or certificate rollover. Define which identity, authority, and authorization claims must be proven again when a credential or trust anchor loses assurance. +2. Bound bootstrap authority by assurance as well as by validity in certificate policy. State whether a credential whose algorithm has lost assurance may authenticate the issuance of its replacement, and under what additional evidence. +3. Specify the assurance of the procedural means the profile requires. Record what evidence the procedure consumes, what identity-proofing assurance level it targets, who is accountable for the determination, how it behaves at migration volume, and what happens when it fails. An outcome requirement without a measurable assurance target permits materially different procedures unless the governing certificate policy supplies stronger criteria. The profile expects specific communities to supply that layer through certificate policy; implementers should not assume that adopting the cryptographic profile also imports a complete identity-proofing or rekey-assurance policy. For human subjects, NIST SP 800-63-4 provides defined assurance models for proofing, binding, and authentication; its scope is natural persons and it does not directly address machine-to-machine authentication, interconnected devices, or API access on behalf of subjects, so machine and workload enrollment require a separately stated assurance model. +4. Reconcile the records used to authorize bulk re-enrollment against a source that does not derive from the credentials being replaced — procurement, asset management, hardware attestation, or an owner confirmation independent of the certificate population. +5. Do not rely on a credential whose assurance has degraded as the sole continuity proof for its replacement. Use independent evidence appropriate to the identity type: fresh organizational or human proofing, a still-trusted root, hardware or workload attestation, dual control, or an attested approval by a still-trusted party. Where a human approval carries the determination, it must cost the approver something: name them in the continuity decision record, place their own standing at stake in the determination, and make the approval revocable when the determination is later found wrong. An approval that carries no consequence for the approver is not independent evidence — it relocates the attack from the records to the approver, which is the failure in Common Example 3. Anchor the approval chain in a source with external accountability, per the reconciliation in the preceding item. Where the out-of-band shared-secret path is used, state the assurance of the distribution rather than inheriting it from the phrase "securely out of band." +6. Separate credential issuance from authorization restoration, and require a distinct authorization-continuity decision. Subject continuity is not evidence that a role, delegation, entitlement, or session should survive the transition. Re-enter migrated identities at a reduced authority ceiling and raise it on evidence rather than on elapsed time: state what observation, attestation, or reconciliation moves an identity to the next stage, since stages with no stated gate are a schedule rather than a control. During the constrained period, require co-signature or human confirmation for actions whose consequence is high or irreversible, so that automation is restored by degrees alongside authority rather than returning in full the moment the credential does. +7. Build a trust-inheritance graph tracing each identity from proofing, issuer, registration authority, recovery mechanism, and sponsor through certificates, tokens, roles, delegations, sessions, policy bindings, and enforcement points. Decide which must be recomputed rather than copied. +8. Revoke or invalidate derived authorization state that cannot be traced to the re-established identity, including old certificates, tokens, sessions, cached policy decisions, delegated grants, recovery credentials, issuer mappings, and trust-store entries. +9. Produce a continuity decision record for each high-impact identity or identity class: evidence used, the named parties whose standing backs the determination, scope restored, confidence, expiry, unresolved exceptions, and rollback path. +10. Exercise compromise-transition scenarios before migration, including a compromised migration inventory, a compromised issuer, an RA under migration-volume load, loss of all trusted authenticators, and a long-lived machine identity attempting to inherit prior privileges. + +**Example Attack Scenarios:** + +Scenario #1: **[theoretical]** An organization migrating to post-quantum credentials cannot authenticate requests with classical keys, so it satisfies the procedural-means requirement with a bulk re-enrollment process: an RA approves requests matched against an asset inventory. The inventory was built by scanning certificate stores and treating each discovered certificate as authoritative for the identity it names, with ownership inferred from subject names rather than reconciled against procurement or asset records. An attacker who has placed a certificate into a scanned store, or who has altered an ownership record in the issuance database the inventory drew from, is approved along with everything else and receives a cryptographically strong post-quantum credential bearing a legitimate identity. No quantum computer is required; the failure is in the assurance of the evidence behind a determination the profile mandated without specifying. + +Scenario #2: **[theoretical]** A workload's post-quantum certificate is issued correctly to the right entity. The migration system then treats subject continuity as sufficient authority to rebind that identity's entitlements — service-mesh identity mappings, delegated permissions, and active sessions are re-pointed from the classical credential identifier to the successor without a separate authorization decision, because the migration was scoped as a cryptographic project. A delegation that should have lapsed, or a privilege whose justification expired, survives on the strength of the credential's continuity rather than its own. + +Scenario #3: **[demonstrated]** A certificate authority is compromised and attackers obtain rogue certificates for trusted services. Those certificates remain valid under widely trusted chains until relying parties change their trust decisions concerning the issuer. The DigiNotar compromise demonstrated this: false certificates were created for hundreds of sites and used in interception attacks, and the response required browser vendors and the Dutch government to withdraw trust in the authority rather than replace individual certificates. Leaf replacement alone could not cure compromise of the issuing path. + +**Relationship to adjacent work:** + +The boundary test is whether the failure survives when no predecessor signature is forged and the successor's cryptography operates correctly. For this entry it does: an RA 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 without any forgery and with every algorithm behaving as specified. + +QS03 as reshaped concerns predecessor signatures, certificates, and trust chains losing trustworthiness — what an adversary can forge once a signature algorithm falls. QS05 and QS06 concern whether an organization can replace cryptography safely and responsively, and whether hybrid or migration constructions permit downgrade or insecure composition. This entry concerns the successor-side decision: the evidence by which a replacement identity is established, and the authority by which predecessor claims are rebound onto it. + +Different trigger, different decision point, different controls. **The primary position is a standalone transition-risk entry adjacent to QS03 and QS05/QS06.** If the group defines QS03 broadly enough to cover not only forgery but every successor-bootstrap consequence, this material should be preserved as a named subsection and mitigation class within it rather than dropped. + +It is worth distinguishing this from the transition engineering that does exist, because that work is real and it is not in the same place. The CNSA 2.0 IPsec profile draft profiles RFC 9370 multiple key exchange so that a CNSA 1.0 classical group and ML-KEM-1024 both contribute to one security association, stating that the classical options facilitate backward compatibility during transition. The CNSA 2.0 TLS profile draft specifies negotiation and interoperability behavior between compliant and non-compliant endpoints. Both address *session establishment* across a suite change, and both specify transition behavior in detail. The certificate-management profile mandates the new algorithm precisely — a deliberate policy choice consistent with NSA's stated position that hybrid constructions are not required for security and that quantum-resistant-only deployment is the intended endpoint, while allowing protocol-specific hybrid constructions where interoperability or engineering constraints require them — and delegates the identity determination to procedural means whose assurance it does not specify. The contrast worth drawing is not that one document is careless. It is that transition behavior was specified where it concerned session establishment, and left to deployment where it concerned re-establishing the credential's subject and authority. + +**Reference Links:** + + + +1. [RFC 8756 — CNSA Suite Profile of Certificate Management over CMS](https://datatracker.ietf.org/doc/rfc8756/): Specifies that CNSA certificate enrollment and rekey may be authenticated by the credential being replaced (§4, Appendix A.1.1, Appendix A.2.1), and delegates to certificate policy the question of whether *expired* certificates may sign certification requests (§9), without stating a general rule for loss of cryptographic assurance. NSA-authored, published via the IETF Independent Submission stream and not representative of IETF consensus. +2. [draft-jenkins-cnsa2-cmc-profile-03 — CNSA Suite 2.0 Profile for Certificate Management over CMS](https://datatracker.ietf.org/doc/draft-jenkins-cnsa2-cmc-profile/): Active Internet-Draft, July 2026, Independent Submission stream, intended Informational, undergoing IETF conflict review; obsoletes RFC 8756 only if approved and published. Mandates ML-DSA-87 for signatures (§4, §5.1, §5.2), closing the classical-key authentication path, and requires that where no appropriate signature certificate exists "procedural means that ensure the identity of the requestor MUST be used" (§5) without specifying an evidence set or identity-proofing assurance level for those means (Appendix A.1). +3. [RFC 5272 — Certificate Management over CMS (CMC)](https://datatracker.ietf.org/doc/rfc5272/): The CMC generation both CNSA profiles normatively reference. Defines the identity-proof control, shared-secret verification and linking, RA processing, and proof-of-possession behavior, and places the method of distributing a shared secret outside the protocol. Obsoleted by RFC 10002. +4. [RFC 10002 — Certificate Management over CMS (CMC)](https://datatracker.ietf.org/doc/rfc10002/): Current IETF Proposed Standard for CMC, obsoleting RFCs 5272 and 6402. For renewal and rekey it specifies that separate identification and identity-proof controls are absent because an existing certificate supplies the same information, while permitting CAs and RAs to constrain which existing signing certificate may be used. RFC 8756 and draft-jenkins-cnsa2-cmc-profile-03 continue to reference RFC 5272, so both generations bear on this analysis. +5. [RFC 4210 — Internet X.509 PKI Certificate Management Protocol (CMP)](https://datatracker.ietf.org/doc/rfc4210/): The CMP generation in which root CA key update via `NewWithOld` / `OldWithNew` link certificates was originally specified (§4.4). Obsoleted by RFC 9810. +6. [RFC 9810 — Internet X.509 PKI Certificate Management Protocol (CMP)](https://datatracker.ietf.org/doc/rfc9810/): Current CMP Proposed Standard, obsoleting RFC 4210. Root CA key update (§4.4) permits an end entity to acquire the new CA public key either out-of-band or via online messages carrying the `new with old` link certificate, so predecessor trust can establish successor trust directly. §3.1.2 requirement 10 attaches the condition: the mechanism is specified for changeover "from one non-compromised CA key pair to the next," and "if the CA key is compromised, re-initialization must be performed for all entities in the domain of that CA." Establishes that the standards already separate ordinary continuity from assurance failure. +7. [draft-wang-lamps-root-ca-cert-rekeying-04 — Root CA Certificate Rekeying in the Scenario of Post Quantum Migration](https://datatracker.ietf.org/doc/draft-wang-lamps-root-ca-cert-rekeying/): Active LAMPS Internet-Draft addressing the population for which RFC 4210's out-of-band acquisition is unavailable, proposing a one-way `newWithOld` link certificate so that a post-quantum root is certified by the predecessor key. Its Security Considerations section states, in full, "Security analysis will be given later." +8. [RFC 5011 — Automated Updates of DNS Security (DNSSEC) Trust Anchors](https://datatracker.ietf.org/doc/rfc5011/): Solves the equivalent successor-trust problem in another substrate using a hold-down timer and revocation signalling, demonstrating that the failure mode is tractable when named and specified. +9. [RFC 8603 — CNSA Suite Certificate and Certificate Revocation List (CRL) Profile](https://datatracker.ietf.org/doc/rfc8603/): The CNSA 1.0 certificate and CRL profile referenced by RFC 8756. It applies RFC 5280's requirements and adds CNSA-specific algorithm and certificate constraints; it adds no CNSA-specific requirements for validity periods, key rollover, identity continuity, or trust re-establishment. CNSA 2.0 certificate constraints are specified separately in `draft-jenkins-cnsa2-pkix-profile`. +10. [draft-guthrie-cnsa2-ipsec-profile-04 — CNSA Suite 2.0 Profile for IPsec](https://datatracker.ietf.org/doc/draft-guthrie-cnsa2-ipsec-profile/): Active Internet-Draft. Profiles RFC 9370 multiple key exchange with ML-KEM-1024 as an additional key exchange, stating that CNSA 1.0 key establishment is permitted to enable backward compatibility and interoperability during the transition — transition engineering applied to session establishment. +11. [draft-becker-cnsa2-tls-profile-05 — CNSA Suite 2.0 Profile for TLS 1.3](https://datatracker.ietf.org/doc/draft-becker-cnsa2-tls-profile/): Active Internet-Draft. Specifies negotiation and interoperability behavior between CNSA-compliant and non-compliant endpoints, with compliance requiring that all CNSA requirements be met. +12. [NIST SP 800-63-4 — Digital Identity Guidelines](https://csrc.nist.gov/pubs/sp/800/63/4/final): Final, July 2025. Separates identity proofing, authenticator binding and management, authentication, and federation, with defined assurance levels — the available reference for specifying the assurance a procedural enrollment path must achieve. +13. [NIST IR 8547 (Initial Public Draft) — Transition to Post-Quantum Cryptography Standards](https://csrc.nist.gov/pubs/ir/8547/ipd): Initial Public Draft, November 2024. Identifies quantum-vulnerable digital-signature and key-establishment standards and the expected transition to post-quantum standards. +14. [NIST IR 8320C (Initial Public Draft) — Hardware-Enabled Security: Machine Identity Management and Protection](https://csrc.nist.gov/pubs/ir/8320/c/ipd): Initial Public Draft, April 2022. Describes the scale, lifecycle management, policy use, and protection challenges of machine identities and their cryptographic keys. +15. [ENISA — Operation Black Tulip: Certificate Authorities Lose Authority](https://www.enisa.europa.eu/sites/default/files/all_files/Operation_Black_Tulip_v2.pdf): Documents the DigiNotar compromise, the creation of false certificates for hundreds of sites, their use in interception, and the withdrawal of trust in the authority as the necessary response. +16. [NSA — Commercial National Security Algorithm Suite 2.0](https://media.defense.gov/2025/May/30/2003728741/-1/-1/0/CSA_CNSA_2.0_ALGORITHMS.PDF): Specifies the CNSA 2.0 algorithm selection and transition timelines. Browser-accessible; see the verification note above.