Summary

  • RFC 6916 makes RPKI algorithm migration a coordinated sequence for certificate authorities, publication repositories and relying parties, rather than a local software switch.
  • Its parent-first plan preserves corresponding products under old and new algorithm suites during a staged overlap, then sets milestones for validators and a final end-of-life date.
  • The document says the process may take several years and specifies no emergency transition. It is a plan for orderly change, not a ready-made answer to a sudden cryptographic failure.

A cryptographic change is not a software update

Changing a signature algorithm inside one application can sound like a contained engineering task. In the Resource Public Key Infrastructure, however, each signed statement sits inside a hierarchy. A certificate authority (CA) certifies the next CA below it; that child can issue certificates and signed objects for resources farther down the tree. A relying party (RP) retrieves the published material and decides whether the chain and its signed products validate. Network operators can then use RPKI validation results in their own routing policies.

Those are separate actions. A certificate being issued does not show that every repository has published the matching material. Publication does not show that every RP can validate it. A validation result does not, by itself, dictate what a router will accept: operators set policy at that later point. The design question in RFC 6916 was how to change the cryptographic suite while preserving a usable path through each of these stages.

The paper trail matters for attribution. RFC 6916, “Algorithm Agility Procedure for the Resource Public Key Infrastructure (RPKI),” was published in April 2013 as Best Current Practice 182. Its listed authors are Roque Gagliano, Stephen Kent and Sean Turner. The document is an IETF consensus standard, not a personal instruction issued by any one author. RFC 6916

The schedule came before the replacement algorithm

RFC 6916 does not nominate a new algorithm. In 2013 it said a future transition must begin by updating the RPKI algorithm profile then defined by RFC 6485, followed by a separate transition timeline. RFC 7935 later obsoleted RFC 6485 and sets out the retrieved current profile; a future transition would need the applicable profile to be updated, not merely a new label in a certificate. The timeline is expected to name five dates: when CAs must be ready to issue with the next suite, when they must have reissued their products, when RPs must be ready, when the old suite becomes optional, and when it reaches end of life. RFC 7935

The precision is deliberately coarse but coordinated: RFC 6916 assumes each milestone takes effect one minute after midnight UTC. It also calls for readiness metrics for CAs and RPs in each phase. The date is therefore more than a project-management convenience. It tells repositories, relying-party software, resource certificates and operators which version of the trust chain they must be able to use at a given point.

The distinction between a new algorithm and a new key is equally important. RFC 6489 already describes CA key rollover when the algorithm suite stays the same. RFC 6916 addresses the more disruptive case in which the cryptographic suite itself changes. A process that can replace one key cannot simply be assumed to solve a change in the algorithms used for certificates, revocation lists, manifests and signed objects. RFC 6489

Why the parent moves first

RFC 6916 requires a top-down migration. A child CA cannot ask its parent for a certificate under the new suite until the parent can issue one. The specification also avoids CA certificates whose signing algorithm and subject-key algorithm belong to different suites. Without that order, a migration would have to manage mixed-suite certificates and a more complex repository structure; the RFC warns that a non-top-down approach could cause exponential growth in repository data.

This is the trust hierarchy acting as a control surface. A parent CA’s readiness is a dependency for its children, not a vote that each child can bypass. The standard responds by making the sequence visible: readiness first, then issuance, then relying-party support, then retirement of the older suite. It does not claim that one central actor can force every downstream system to move on command.

Parallel products buy time

The RFC divides the transition into phases so the old suite can continue to serve production while the new one is introduced and tested.

In Phase 0, only the current suite is supported. Phase 1 begins at the CA Ready date: non-leaf authorities must be able to process requests using the new suite, but RPs still use the old suite for production. New-suite products may be issued for testing, preferably at separate publication points.

Phase 2 begins at the CA Go date. Each signed product set must now have a corresponding version under both suites. The old set remains available, while capable RPs can begin checking the new one. During this overlap, the RFC expects corresponding outputs—such as the route-origination data in ROAs—to agree, allowing for timing differences. If many CAs are not ready, the timeline must be reissued; RP support is not yet mandatory, but a problem there is a reason to delay the next milestone.

Phase 3 begins at the RP Ready date. All RPs must be able to validate the new suite, and they are encouraged to prefer its products while both sets remain available. If a substantial number cannot do so, the transition calendar must move. Phase 4 starts at the Twilight date: the new suite is required for RPs and CAs, while old-suite products may still exist but may no longer be complete. At end of life, the old suite must be deprecated and its trust-anchor locators removed from publication points. RFC 6916, Sections 4 and 10

The fallback is designed into the schedule. A relying party that cannot validate the new products can continue with the old ones while they are still required and available. This is not a promise that two versions will coexist forever. It is a bounded overlap in which both sides can test, compare and reveal readiness problems before the old path is retired. RFC 6481

The failure boundary is shared

The procedure gives both issuers and validators a way to fail. RFC 6916 warns that a CA which has not completed migration after the old suite’s end-of-life will have signed products that are no longer valid. An RP that does not complete its own transition will lose the ability to validate products under the new suite. The result can be a smaller or incomplete RPKI view of routing information.

That is a reliability concern, not a claim that every route disappears. RPs produce validation data; routers and operators decide what to do with it. A missing or invalid product can influence route-origin validation, but the final routing effect depends on local policy, software and which resources are covered. The standard identifies the risk of incomplete validation; it does not quantify an outage or assign a universal route-rejection outcome.

The design’s conservative timing also has a clear limit. The abstract says a transition is expected to take several years and that no emergency transition is specified. That omission may be sensible for a planned replacement, where a new suite needs broad implementation and publication support. It leaves a different question unanswered: what happens if the existing suite or a key becomes unsafe before a multi-year migration can finish? RFC 6916 does not supply that crisis procedure.

Gagliano’s place in the record

Cisco’s public profile describes Gagliano as a Principal Solutions Engineer and says he previously held engineering and architecture roles at LACNIC, ANTEL and Sprint. That background places operator, registry and vendor experience alongside his standards work, but the profile does not establish why he supported any particular RFC provision. The RFC itself records the safer claim: he co-authored a consensus procedure that treats migration readiness as a property of the whole RPKI chain, not just of the next signature algorithm. Cisco author profile

The current algorithm profile in RFC 7935 specifies RSA with a 2048-bit key and SHA-256. In 2026, an informational Internet-Draft is examining post-quantum candidates and migration structures, including parallel publication and a mixed-tree approach. Its authors state that it does not update RFC 7935 or RFC 6916, choose a production profile, or authorize the evaluated options for live RPKI use. That boundary matters: new experiments are evidence that engineering questions are being explored, not proof that a production transition has been approved or scheduled. RFC 7935; draft-yoshikawa-sidrops-pqc-rpki-02

RFC 6916’s durable contribution is procedural. It turns “support a stronger algorithm” into a set of observable dependencies: a CA must issue the new suite, each publication point must carry corresponding signed products, RPs must validate them, and the old trust path must remain until readiness has been demonstrated. The rulebook also exposes what it does not settle: how readiness is measured, how late actors are supported, and how an emergency differs from a planned migration. That is where operators and standards participants must make the next set of decisions.