Summary

  • Post-quantum RPKI migration is justified as risk preparation, but there is no credible date for a cryptographically relevant quantum computer. The correct response is a stepwise preparation with evidence, not a hasty transfer of authority to the CA or the provider that moves first.
  • IETF standards should define interoperable certificates, signed entities, validator behaviour, and transition milestones. CAs should implement these obligations. None of these roles confer to a CA ownership of the represented resources, the holder's private key, or the right to prevent switching to another qualified service.
  • RFC 6916 already treats algorithmic migration as a multi-year top-down transition with parallel product sets and defined preparation dates. Its structure is useful, but a quantum transition also requires explicit anti-lock-in, semantic equivalence, downgrade, emergency, and rollback rules.
  • NIST's ML-DSA and SLH-DSA standards provide mature cryptographic starting points, but not an automatic selection for RPKI. A June 2026 individual IETF proposal profiles ML-DSA-65 for experiments while honestly recording incomplete evidence of signed entities and multi-validator validation.
  • Parallel RSA and post-quantum publication must be judged on the resulting routing semantics, not on a byte-for-byte identity. Divergences in route authorisations, revocation status, or manifests must be visible and must never be silently merged into a makeshift response.
  • Key custody controlled or authorised by the holder must remain portable between hardware and service providers. Non-exportable keys can be replaced through coordinated renewal; they must not become an excuse for a CA to trap the certification relationship.
  • Reversibility requires isolated test hierarchies, measured production pilots, limited fallback, clean key withdrawal, and a defined return path in case of new suite failure. A permanent classic fallback would become a downgrade channel rather than a security function.
  • The NRS should publish a 2025–2035 migration charter covering decision rights, evidence thresholds, provider neutrality, support for small operators, incident response, public metrics, and independent review before any mandatory production date.

The quantum risk is real, but the timeline remains uncertain

The security concern is straightforward. Large-scale quantum computing could make vulnerable algorithms based on integer factorisation or discrete logarithms in a way that ordinary classical computing does not. The current production profile of the RPKI uses RSA PKCS #1 v1.5 signatures with SHA-256 and RSA keys of at least 2048 bits. A cryptographically relevant quantum computer would undermine the assumption that only the private key holder can create a valid RSA signature.

This statement does not provide a deployment date. Progress in quantum hardware, error correction, resource estimates, and technical feasibility remains uncertain. Registry governance should resist two symmetric errors: declaring the threat imaginary until a public break, or treating every forecast as a reason for immediate replacement. Critical infrastructures cannot start a global migration on the day an old suite fails, but they should not force an immature suite into production just to appear prepared.

Urgency differs from long-lived encrypted data. An adversary can collect encrypted data today and decrypt it later if the plaintext remains valuable. RPKI signatures mostly authorise a current or time-limited state, and stakeholders fetch changing repositories. This reduces some 'harvest now' exposure, but it does not eliminate the transition problem. A future ability to forge certificates or signed entities could create false routing authority, and a hurried emergency switchover would be especially dangerous in a hierarchical system.

Preparation should therefore start with a cryptographic inventory, implementation experiments, hardware support, repository measurements, validator interoperability, and governance rules. It should not start with a provider mandate. The key question for 2025 to 2035 is whether the system can evolve deliberately before RSA is no longer safe while retaining enough flexibility to fix a wrong algorithm, implementation, or timeline.

The NIST standards of August 2024 materially changed the starting point. FIPS 204 defines ML-DSA, a lattice-based digital signature standard. FIPS 205 defines SLH-DSA, a stateless hash-based alternative. FIPS 203 covers a key encapsulation mechanism rather than signatures, so it is less directly relevant for signing RPKI objects. NIST's transition planning indicates deprecation and withdrawal of quantum-vulnerable standards by 2035 in its own standards context, with higher-risk systems expected to migrate sooner.

These developments justify work now. They do not decide the RPKI suite. RPKI has specific certificate, CMS, repository, manifest, revocation, and stakeholder constraints. A standardised, theoretically secure algorithm may still impose unacceptable entity size, signing cost, hardware, interoperability, or operational behaviour in that environment. Technical selection requires RPKI evidence; institutional selection requires legitimate, verifiable authority.

RPKI keys represent limited authority, not ownership

The architecture described in RFC 6480 follows the existing hierarchy of number resource allocation. Resource certificates bind a public key to IP addresses or AS numbers included in the certificate extensions. The certificate enables cryptographically verifiable assertions in the RPKI. It does not transform the private key into a title of ownership, nor does it make the issuing CA the owner of the represented resources.

This distinction is important during migration because each holder may need new keys, certificates, and signed products. A parent CA must be ready to issue under the new suite before its children can migrate in the established top-down model. This technical dependency gives the parent sequencing power. It does not justify a discretionary claim that a child must surrender custody, accept an affiliated service, or renegotiate its underlying resource rights.

The recognised authority of the holder should remain the invariant between cryptographic suites. Corresponding certificates may use different keys and encodings while representing the same resource set. Corresponding route authorisations may have the same routing meaning while the signatures differ. Migration is a change in how authority is verified, not a transfer of authority itself.

CA policy should state this clearly. Issuing a replacement certificate does not create a new allocation, erase an existing dispute, cure a defective underlying authority, or allow a provider to claim beneficial control. Conversely, possession of a post-quantum private key cannot override a legal resource transfer or revocation recognised by governance rules. Cryptographic control and resource recognition must remain connected without being conflated.

The same rule applies to hosted operation. A CA or contracted service may generate and hold keys for a client who chooses managed signing. It performs a limited technical function for the recognised holder. A migration that requires new hardware or larger keys should not be used to rewrite this relationship into permanent custody. The client should retain visibility, approval, records, a path to upgrade to delegated operation, and a documented exit.

The NRS can make the invariant enforceable through a certificate rights charter. The charter should protect holder-authorised key generation, provider choice, timely parent service, publication access, evidence export, routine and emergency renewal, independent monitoring, and review of adverse actions. These rights apply to the current suite and replacement suites. No migration exception should allow silent recentralisation.

Decision authority must be divided by function

No single institution should decide every aspect of quantum migration. The IETF is the appropriate venue for interoperable technical specifications for the Internet: algorithm identifiers, certificate and signed entity profiles, stakeholder behaviour, repository management, and transition procedures. Its open review can expose engineering conflicts and produce common requirements. It does not allocate number resources or operate every CA.

RPKI CAs implement technical standards as part of their certification responsibilities. They generate or accept certificate requests, issue certificates, manage revocation, publish signed products, and support child transitions. Trust anchor operators have a particularly important role because their readiness affects the hierarchy below. Their operational authority should be bounded by published milestones, compliance evidence, and independent observation.

Stakeholders decide which trust anchors and algorithmic policies they accept. This is not a theoretical footnote. A new suite only takes practical effect when validators can fetch and verify it, produce expected validated output, and deliver that output to network systems. Operators need clear configurations for old-only, parallel acceptance, new-preferred with limited fallback, and new-only. Hidden defaults would turn local policy into accidental global behaviour.

Resource holders decide how their keys are held in the accepted profile, who may operate them, which route authorisations they intend, and which qualified provider assists them. They do not individually choose an arbitrary global algorithm and expect universal acceptance. Their autonomy is exercised within interoperable rules, with meaningful choices about custody, support, and timing during allowed windows.

The NRS governance should connect these functions without absorbing them. It can represent member needs in standards discussions, qualify interoperable services, coordinate readiness exercises, publish evidence, protect portability, and provide independent review. It should not announce a proprietary suite, force members to use an NRS-held key, or claim that a technical migration extends the Society's title over resources.

Governments and security authorities may publish transition dates for systems under their jurisdiction. These dates can influence vendors and entities, especially public sector networks. They should not fragment the global RPKI into incompatible national roots. The NRS and RIRs should map applicable obligations, seek interoperable implementation, and disclose conflicts early. Global routing security depends on shared validation even when procurement laws differ.

RFC 6916 provides a structure, not a complete constitutional answer

RFC 6916 anticipated that the RPKI would eventually need a stronger algorithmic suite. It describes a planned transition spanning multiple years rather than an emergency switch. The model is top-down: parent authorities become capable before children. It defines milestones for CA readiness, CA production, stakeholder readiness, a twilight period, and eventual end-of-life for the old suite.

The design uses parallel corresponding product sets. During key phases, certificates, revocation lists, manifests, and signed entities may exist under both suites. Stakeholders can test the next suite while continuing to use the current suite, then prefer the new suite while retaining the old path for a limited interval. This is an important safety mechanism because a global PKI cannot rely on every implementation changing at the same time.

The structure also exposes governance power. Someone must publish the transition schedule, decide readiness thresholds, and determine when the old suite reaches twilight and end-of-life. A parent can delay a child by not supporting the new suite. A validator can continue to accept the old suite after the intended security limit. A provider can use transition complexity to discourage exit. The technical sequence needs institutional rules around these actions.

RFC 6916 does not explicitly define emergency transition. This omission is understandable for its planned model, but quantum preparation cannot ignore the possibility of accelerated evidence: a cryptanalytic breakthrough, an implementation disaster, or a credible indication that RSA security has deteriorated faster than expected. The NRS and RIRs need an emergency decision framework that does not improvise ownership, trust anchors, or fallback under pressure.

The existing procedure also predates current post-quantum entity sizes and implementation realities. Parallel publication can multiply repository transfer, cache, and validation costs. The system needs measurements across large and small CAs, various network conditions, and multiple validator implementations. A schedule that only the best-resourced operators can meet would turn cryptographic security into a new barrier to participation.

The constitutional supplement should define five things: who can propose and approve milestones; what interoperable evidence is required; how holders receive equal access to migration; how divergence and downgrade are handled; and how decisions can be reversed. Standards describe valid behaviour. Governance determines whether the power to require that behaviour is exercised fairly.

The 2026 RPKI proposal is a proof of progress and incompleteness

An individual Internet draft submitted to the IETF SIDROPS community in June 2026 provides a useful current marker. It proposes ML-DSA-65 as the leading candidate for the next RPKI signature suite and reuses post-quantum certificate and CMS conventions developed elsewhere in the IETF. It aims to keep the existing RPKI architecture, repository model, and router-oriented validated output model intact.

The proposal is not an adopted Internet standard and should not be described as such. Its status is important because migration decisions can become politically sensitive once institutions invest. Treating an early proposal as a given would favour first implementers and vendors before independent evidence exists. The appropriate response is to test the proposal rigorously and compare alternatives against published criteria.

Its candour is valuable. The initial revision reported generation of ML-DSA and SLH-DSA CA certificates, end-entity certificates, and revocation lists using a contemporary cryptographic library. It also reported that the tested command-line CMS path did not produce the needed ML-DSA signed data, so complete RPKI manifests and route authorisations were not generated in that environment. Multi-validator interoperability with full post-quantum RPKI objects remained future work.

This is not evidence that ML-DSA cannot work in RPKI. It is evidence that a standard reference, an algorithm implementation, and an end-to-end RPKI capability are different maturity levels. Governance should reward publication of such gaps. Suppressing them to maintain momentum would increase the risk of a brittle mandatory date.

The proposal also identifies larger keys and signatures as concerns for repositories and validation. ML-DSA-65 is selected as a candidate because it has a finalised NIST standard and stable IETF certificate and CMS identifiers, not because it is always the smallest or fastest choice. SLH-DSA offers cryptographic diversity but may impose significantly larger signatures or higher signing costs, depending on the variant. Other candidates may offer size advantages but lack equivalent profiling and implementation maturity.

The NRS should treat the draft as an invitation to shared measurement. It can fund independent implementations, repository tests, hardware trials, and validator comparison without declaring a winner. Results should include failures and environment details. A provider that brings useful evidence should not receive exclusive control over production migration as a reward.

Algorithm selection needs a public evidence standard

The selected suite must meet cryptographic, operational, and institutional criteria. Cryptographic criteria include security basis, parameter strength, implementation resistance, randomness requirements, side-channel behaviour, failure behaviour, and diversity relative to other accepted suites. The existence of a formal standard is necessary for confidence but does not eliminate implementation risk.

Operational criteria include public key and signature size, certificate and revocation list growth, manifest size, repository snapshots and deltas, signing latency, validator CPU and memory, cache size, failure handling, and hardware availability. Measurements should use representative global repositories as well as synthetic edge cases. A median result may hide a failure for a small validator or a large publication point.

Interoperability criteria require that at least two independent CA implementations, multiple repository environments, and major stakeholder implementations agree on complete sets of valid and invalid entities. Testing should cover malformed algorithm identifiers, unsupported parameters, stale manifests, inconsistent revocation, unknown suites, and mixed old-new branches. Acceptance means consistent security behaviour, not just successful verification of a happy-path entity.

Institutional criteria include licensing, vendor concentration, hardware diversity, export and renewal support, availability across regions, cost to small operators, and ability to replace a provider. A theoretically excellent suite may create governance risk if a single vendor controls usable hardware or only one service can operate the required key format. Procurement evidence must accompany performance evidence.

Criteria should be set before comparing favoured algorithms. Otherwise, institutions may select metrics that justify an existing investment. The NRS should publish weights, testing methods, data sets, exceptions, and reviewer conflicts. Community comments should be answered with reasons. The final recommendation should explain why rejected alternatives were not chosen and what evidence could provoke reconsideration.

Algorithm diversity is valuable but not free. Supporting multiple suites increases code, configuration, and deprecation complexity. RFC 7696 warns that too many choices can damage interoperability and leave weak algorithms deployed too long. The goal is a small coherent set with a credible replacement path, not a permanent menu that every validator interprets differently.

Semantic equivalence is the litmus test of migration

Old-suite and new-suite entities will not be byte-identical. Keys, signatures, certificate serial numbers, validity details, and repository paths may differ. The meaningful question is whether they produce the same accepted resource and routing semantics. For route authorisations, validators should compare the resulting validated payload by prefix, max length, origin AS, and relevant trust context.

If branches diverge, a validator should not silently merge them. Suppose the RSA branch authorises one origin while the post-quantum branch authorises another, or one branch has revoked a child certificate while the other remains current. Combining the two could broaden authority beyond any intended state. Picking whichever validates first can hide a serious operational error or attack.

Divergence should produce explicit telemetry and a bounded policy response. During an early test phase, production may continue to rely on the established suite while the new branch is investigated. During a new-suite-preferred phase, fallback may be allowed for a defined class of technical failure, but not for a semantic conflict. The difference between unsupported, unavailable, malformed, expired, and contradictory must remain visible.

The CA has a duty to maintain matching state between branches during parallel publication. Revocations, resource changes, and holder instructions must be applied consistently. Automated generation can reduce drift, but shared automation can also repeat an error. Independent validators and holder monitors should compare outputs rather than trusting a common administrative display.

Semantic checks should extend beyond route authorisations. Certificate resource sets, revocation status, manifest coverage, and entity inventory need corresponding comparisons. Newer signed entities and future uses may require entity-specific equivalence rules. The guiding principle is stable: migration changes the cryptographic representation, not the intended resource authority.

The NRS should make divergence statistics publicly available in aggregate. Reports can show unpaired entities, inconsistent validated outputs, stale branches, fallback events, validator disagreements, and time to correction. Sensitive holder details may remain protected. A transition that claims success while hiding semantic divergence has measured cryptography but not routing security.

Parallel publication must not become permanent downgrade

Running two suites provides a recovery path while the new one matures. It also preserves the vulnerable path. If validators accept RSA indefinitely whenever the post-quantum branch is missing or invalid, an attacker can suppress the stronger branch and obtain the weaker result. Fallback becomes a downgrade channel when its conditions are broad, silent, or permanent.

Each phase needs an explicit acceptance policy. In the test phase, the current suite remains authoritative and the next suite provides evidence. In the parallel production phase, both must be present and semantically equivalent. In the preference phase, the new suite governs, with narrowly defined fallback for availability failures. At end-of-life, acceptance of the old suite ceases except in isolated forensic or test contexts.

Fallback must be time-limited, logged, and visible to the operator. A validator that repeatedly falls back should alert rather than normalise the condition. Trust anchor and CA operators should receive aggregated signals so they can distinguish a repository outage from a systemic incompatibility. Resource holders must be able to see whether their products are accepted under both suites.

The withdrawal date must be evidence-based but credible. A date that changes every time a vendor is late gives every vendor an incentive to delay. A date that ignores a hardware incompatibility can fragment validation. Governance should define readiness thresholds, exception categories, and consequences in advance. Late critical operators may receive limited assistance or isolated transition measures, not an indefinite veto.

Old keys and products require controlled withdrawal. Removing them too early can create validation gaps; keeping signing capability too long preserves the attack surface. CAs should destroy or archive old private keys according to a defined risk, remove old trust material at the declared step, and retain sufficient public evidence to explain historical state. Withdrawal evidence should be independently reviewed for top-tier CAs.

The ability to undo the new suite is different from continuing to trust the old one forever. A replacement plan can activate another resistant suite, restore an earlier known-good implementation, or suspend new issuance while current valid products persist. Reversibility should be designed as a governed transition, not as a hidden exception that defeats the security purpose.

Key custody must remain portable across hardware changes

Post-quantum private keys may require new cryptographic libraries, hardware security modules, memory profiles, signing ceremonies, and backup arrangements. These changes create a natural opportunity for providers to bundle custody, publication, and support. Bundling can reduce operational cost. It can also trap holders if the new key can only be used through a single provider's account or an undocumented interface.

The NRS should preserve the presumption that a holder can operate a delegated CA or appoint a provider under holder-controlled authority. Key generation should occur within a security boundary that the holder controls or has contractually decisive rights over. The holder should know who can activate signing, how approvals work, what evidence is retained, and how replacement occurs.

Private key export is not always desirable. A hardware device may deliberately prevent it. Portability cannot therefore mean that every private key must be extractable. It means that the certification relationship, public products, configuration, audit evidence, and publication service can move, while a new key is generated and certified through coordinated renewal. Non-exportability protects key material; it does not confer ownership on the device operator.

Providers should support common certificate request, publication, and monitoring interfaces. Custom key wrappers, undisclosed parameter choices, and proprietary approval systems should not become conditions for RPKI participation. Where hardware support is scarce during early deployment, the NRS may qualify shared services, but contracts must include transition assistance and no claim over holder resources.

Backup and recovery require algorithm-specific testing. Some post-quantum signing methods depend critically on secure randomness. Hardware and software may represent keys in different forms. Recovery ceremonies should verify that restored or replacement keys work with compliant encodings and do not repeat insecure randomness. The safest response to a suspected compromise is typically replacement rather than recovery of the same signing key.

Small operators need funded access to secure migration. If only large networks can afford compatible hardware and testing, central hosted custody will become the practical default. The NRS can provide grants, reference configurations, managed ceremonies, and shared test environments usable with multiple providers. Support should follow the member, not subsidise a dominant host.

Repository capacity is a governance concern

Post-quantum signatures can be much larger than current RSA signatures. Parallel publication can multiply certificates, revocation lists, manifests, and signed entities. Stakeholders repeatedly synchronise global repository contents, validate them, and produce local outputs. A suite that dramatically increases transfer or processing can affect operators unevenly and create new concentration among high-capacity validators.

Measurements should cover full snapshots, incremental updates, cold start, ordinary refresh, mass renewal, revocation events, and recovery after local state loss. RRDP snapshot and delta behaviour is important, as is fallback to other retrieval methods. Testing should include constrained networks, remote regions, and commodity hardware rather than only a well-connected laboratory.

Entity size limits and resource checks must avoid two failures. Limits that are too loose can allow memory, storage, or processing exhaustion. Limits that are too strict can reject legitimate post-quantum products. Validators should report whether rejection was due to algorithmic policy, syntax, size, time, memory, or semantic validation. A generic 'invalid' result prevents diagnosis and can fragment operator response.

Repository providers should not gain political authority simply because they absorb extra costs. Their role is to reliably publish compliant products and signal capacity. Fees may reflect measurable service cost, subject to transparency and competition. A repository should not decide that only its affiliated CA can use the new suite or delay a client migration to protect a business bundle.

Capacity evidence should inform algorithm choice and timeline. If ML-DSA produces significant but manageable growth, engineering and investment may be preferable to selecting a less mature alternative solely for size. If measurements show that a proposed suite makes global validation impractical, standardisation work must adapt. The decision belongs to open technical assessment, not private contract negotiation.

The NRS can coordinate shared test repositories and publish anonymised performance distributions. It should separate testing from trust anchors and production keys. Early experiments must not leak into production because an operator reuses a convenient repository path. Clear visual and technical separation protects both security and credibility of results.

Emergency migration requires a more restricted power model

A planned migration allows years of preparation. An emergency may offer only weeks or days. The trigger could be credible cryptanalytic evidence, a compromise of a widely used implementation, a catastrophic randomness failure, or a flaw in the selected post-quantum suite after deployment. Different triggers require different responses; 'quantum emergency' should not be a blank cheque.

The authority to declare an emergency should be distributed. Technical evidence may come from cryptographers, implementation maintainers, national security bodies, or independent researchers. Trust anchor operators and standards bodies must assess the global effect. The NRS and other governance bodies must protect member continuity and prevent self-interested service changes. No CA provider should be able to declare an emergency that forces clients to its product.

Emergency powers should be pre-specified: accelerating an already tested milestone, shortening certificate validity, suspending certain issuance, requiring enhanced monitoring, activating a resistant alternative suite, or limiting fallback. Each action should indicate scope, evidence, duration, and review. The response should avoid modifying underlying resource recognition unless the incident directly challenges that recognition.

An emergency key rollover can be technically valid while institutionally abusive. A parent could refuse a child's new request, insist on hosted custody, or use the emergency to withdraw a contested resource. Independent review must be able to distinguish security necessity from unrelated leverage. Temporary continuity may preserve an earlier uncontested state while the dispute proceeds.

Communication should avoid false certainty. If evidence is preliminary, operators must know what is known, what remains unknown, and which protective actions are reversible. Hiding uncertainty can produce uncoordinated overreaction. Publishing sensitive operational details too early can increase risk. A multi-tier disclosure plan should serve implementers, network operators, holders, and the public at appropriate levels.

Every emergency action must end. End dates, after-action review, key withdrawal, and compensation for undue action must be defined before use. An emergency authority that becomes ordinary control would turn cryptographic risk into institutional capture.

Rollback is a capability, not an admission of failure

Institutions sometimes avoid discussing rollback because it seems to weaken confidence in the selected suite. The reverse is true. A migration without a safe response to implementation flaws, semantic divergence, or operational overload relies on optimism. Reversibility enables earlier testing while limiting the consequences of a mistake.

Rollback does not necessarily mean reverting to RSA as a production response. Before the old suite's end-of-life, limited rollback may be acceptable if the new implementation fails but RSA remains within the declared security window. Later, rollback may mean switching to a second resistant suite, restoring a corrected version, or preserving the current signed state while new issuance is suspended.

Acceptance criteria should be stated before each production phase. Examples include validator disagreement above a threshold, semantic divergence, repository growth beyond tested limits, unsupported hardware behaviour, insecure randomness, key leakage, or inability to revoke consistently. The criteria should identify who orders rollback and how evidence is preserved.

Exercises should simulate partial rollback. One CA may need to roll back while others remain on the new suite. A validator version may be defective. A repository may reject a valid entity. The top-down hierarchy and parallel product model can create dependencies that make local correction difficult. Testing these boundaries reveals whether claimed reversibility exists in practice.

The return path should avoid uncontrolled dual authority. CAs need ordered manifests, revocation state, and clear current keys. Validators need explicit policy and telemetry. Holders need confirmation that their intended route authorisations remain unchanged. Old keys or failed new keys must be withdrawn when no longer needed, with sufficient evidence for later review.

Public reporting should distinguish rollback cause from algorithmic failure. A poor library integration does not prove the cryptographic primitive is broken. A resource capacity problem may require architecture work rather than abandonment. Accurate classification protects technical learning and prevents providers from using a failure to discredit competitors without evidence.

Three migration cases reveal the governance stakes

Consider a large delegated CA that controls its own hardware and publication. It joins a production pilot after two independent validators support the next suite. The parent issues corresponding certificates and the holder publishes semantically equivalent products under both suites. External monitors compare validated outputs. After a measured interval, the new suite becomes preferred. The holder changes hardware vendor during the pilot through normal renewal without changing its resource status.

This is a strong outcome because technical migration and vendor movement coexist. The parent fulfils its certification duty, the holder retains custody, repositories publish both branches, and validators expose divergence. No party obtains a permanent claim for having been first. Evidence, not institutional prestige, supports the next milestone.

Now consider a small operator using hosted signing. Its provider announces that post-quantum service requires a ten-year contract because hardware is expensive and says the new key cannot move. The NRS should reject the lock-in claim. The provider may charge transparent fees for the service, but the operator must be able to replace the key, move publication, and appoint another qualified host. A non-exportable key is retired via renewal; the resource right continues.

The third case is a semantic conflict. The RSA branch contains an established route authorisation, while the post-quantum branch omits it after a publication error. Validators preferring the new suite would classify the route differently. The system must alert, prevent silent merging, and allow limited fallback while the CA corrects the new branch. Holder receipts and prior state help establish intent. The incident is reviewed and included in readiness metrics.

Change the facts once more: the new branch contains an additional authorisation not present under RSA. Fallback cannot resolve this by selecting the outcome that keeps traffic stable. The additional authority may be malicious or erroneous. The affected entity must be isolated, the CA's signing and administrative evidence examined, and the holder contacted through protected channels. Cryptographic validity does not make divergent semantics legitimate.

These cases show why migration cannot be reduced to algorithm identifiers. The decisive outcomes are portable authority, consistent routing meaning, observable failure, and verifiable institutional action. A system can be quantum-resistant and poorly governed. It can also be institutionally fair but technically unready. The transition must satisfy both tests.

The NRS should adopt a 2025–2035 migration charter

The charter should start with invariants. Number resource recognition does not change simply because the signature suite changes. The holder retains the right to authorised custody and provider choice. CAs receive no new ownership claims. Stakeholders retain an explicit trust policy choice. Emergency powers are temporary, limited, and reviewable.

The second part should define technical evidence gates. No mandatory production suite should be set before full certificate, revocation, manifest, and route authorisation interoperability is achieved on independent implementations. Repository and validator measurements must cover representative scale. Semantic equivalence checks, malformed entity tests, downgrade behaviour, and renewal must pass published acceptance criteria.

The third part should define steps and dates as ranges before they become commitments. From 2025 to 2027, inventory, standards review, and isolated experiments dominate. From 2027 to 2030, interoperable test hierarchies and selected parallel pilots may expand if evidence supports them. From 2030 onward, production preference and classic withdrawal can be scheduled based on security evidence, vendor readiness, and global interoperability. The 2035 horizon should motivate completion without claiming that one schedule fits every trust context.

The fourth part should protect participation. Small operators receive reference support and portable managed service. Providers disclose dependencies and exit conditions. Public sector obligations are mapped without creating incompatible roots. Member representatives, security experts, implementers, and independent reviewers participate in milestone decisions. Conflicts of interest are recorded.

The fifth part should define incident and rollback authority. Trigger classes, decision bodies, temporary measures, fallback limits, communication, review, and termination are approved before crisis. No emergency allows a CA to settle unrelated resource disputes. Compensation and correction apply when exceptional powers are abused.

Finally, the charter should require annual evidence. The NRS reports on implementation coverage, hardware diversity, repository growth, validation time, branch divergence, fallback, renewal success, vendor concentration, small operator readiness, and unresolved risks. Metrics should show distributions and failed tests, not just a percentage marked ready.

Migration succeeds only if users can leave

Cryptographic transitions naturally concentrate expertise. Early hardware is scarce, libraries are unfamiliar, standards change, and operational errors can be costly. A few providers can become indispensable. It is precisely at this time that exit rights must be strongest, because dependency formed during transition can persist long after technology matures.

Each qualified post-quantum service should offer documented onboarding, evidence export, publication portability, replacement key renewal, termination, and incident cooperation. The contract should state that certificates and signed products are executed for the recognised holder, not owned by the service. Significant price changes or provider acquisition should trigger a reasonable movement window.

The NRS should test exit anonymously. A synthetic client can move from one hosted service to another, from hosted to delegated operation, and from one hardware vendor to another. The test observes parent response, repository continuity, semantic equivalence, credential withdrawal, and validator convergence. A provider that can sign but cannot release a client is not fully qualified.

Competition should include continuity capacity. If a dominant service fails, alternative providers must have enough hardware, personnel, and repository capacity to accept wave migrations. Spare capacity can be tested without assigning live resources. Dependency maps should reveal whether apparent alternatives use the same cryptographic module, cloud control, or support team.

User choice is not absolute. A holder cannot demand a non-standardised algorithm, insecure key management, or indefinite acceptance of the old suite. The Society may impose common security outcomes. The test of legitimacy is whether the requirements are vendor-neutral, evidence-based, remediable, and no broader than necessary for interoperability and security.

Leaving is the strongest evidence that a CA's technical role has not become an asset claim. If the holder can generate a replacement key, obtain corresponding certification, move publication, and preserve routing semantics under a new qualified service, the hierarchy has coordinated security without confiscating choice.

Governance must remain adaptable after the quantum transition

Post-quantum migration will not be the last cryptographic change. Algorithms may weaken, implementations may fail, hardware may concentrate, and operational assumptions may age. The enduring goal is not a single successful pass from RSA to a favourite suite. It is a system capable of changing again without crisis or capture.

This capability depends on clean abstraction boundaries, interoperable formats, explicit algorithm policy, portable keys or renewal, repository capacity, semantic monitoring, and practised decision rights. It also depends on institutional memory. Evidence from early pilots, failed tests, emergency actions, and vendor changes must be preserved so that future leaders do not repeat avoidable mistakes.

The NRS should separate algorithm policy from commercial service policy. A technical update can revise accepted suites without rewriting membership rights. A vendor qualification can change without modifying the standard. A holder dispute can be adjudicated without choosing a cryptographic architecture. Separation reduces the likelihood that an urgent question carries unrelated power with it.

Independent review should continue after the old suite's end-of-life. Reviewers should verify that old keys have been withdrawn, unsupported validators remain absent, fallback exceptions are not persistent, the new market is not concentrated, and holders can still move. A declaration of completion should not end observation.

The Society should also retain humility about the word 'safe'. Post-quantum algorithms are designed to resist known classical and quantum attacks under current analysis. They are not guarantees against any future discovery, side channel, implementation error, or administrative abuse. Precise claims preserve trust better than absolute language.

Governance success will be visible when the next algorithm change is routine: standards mature openly, independent implementations interoperate, holders retain authority, providers compete, validators expose differences, and old keys are withdrawn on evidence. The quantum migration is the test case for this enduring capability.

A stronger key must not create a stronger institution than the members authorised

The period until 2035 will invite dramatic statements. Some will predict immediate quantum collapse; others will dismiss preparation as speculative. The responsible position lies in between. The RPKI should build and test a post-quantum path now because global migrations take years and a cryptographic failure could affect confidence in routing. It should keep mandatory dates conditional on complete evidence because premature deployment can create its own systemic risk.

The technical hierarchy is inevitable. Parent CAs must be ready, repositories must carry new entities, and stakeholders must validate them. The institutional hierarchy is a choice. The system can coordinate these functions without granting a CA permanent custody, proprietary control, or a veto over client movement. Clear rights and interoperable renewal turn hierarchy into service rather than ownership.

The standards record already provides useful foundations. RFC 6916 provides a multi-year phased template. RFC 7696 explains why algorithmic agility requires more than identifiers and why too many choices can weaken interoperability. The NIST has standardised credible post-quantum signatures. IETF certificate and CMS specifications now support ML-DSA. Current RPKI work identifies both a plausible candidate and unresolved implementation questions.

The remaining task is governance under uncertainty. The NRS should define who decides, what evidence counts, how dissent is handled, when fallback ends, how rollback works, and what rights survive each step. It should measure consequences on repositories and validators, support small members, and prevent vendor concentration from becoming policy.

A longer or more complex private key does not confer a greater right. A new certificate does not create a new allocation. A CA that coordinates migration does not acquire the resource. A provider that stores the key does not own the certification relationship. These propositions should be written before expensive infrastructure and emergency rhetoric make them harder to defend.

The quantum migration will succeed when the cryptography changes and the legitimate distribution of power does not. The holder remains recognised, the CA remains accountable, the validator remains explicit, the provider remains replaceable, and the standard remains open to evidence. This is not an obstacle to routing security. It is the governance condition that makes stronger routing security trustworthy.

Evidence and further reading