Summary

  • RFC 9691 requires each supporting Relying Party to start its own 30-day acceptance timer only after it successfully verifies the same reciprocal successor relationship; publication for 30 days is not a global convergence receipt.
  • A defensible rollover keeps the signed TAK, the validator’s first-seen history, dual-repository equivalence, the production key actually selected, old-TAL lag and final key destruction as separate evidence.

The old trust-anchor key is A. The planned replacement is B. Under RFC 9691, A publishes a Trust Anchor Key object naming B as successor. B publishes its own TAK naming A as predecessor. A validator must retrieve and validate both sides: B’s current key must match A’s successor, and B’s predecessor must match A’s current key.

That reciprocal binding is stronger than a loose announcement. It says the currently trusted authority and the staged authority describe the same planned edge. But it still speaks only about valid signed objects and one validator’s observations. It does not report how many validators support TAK, when each first saw B, whether any missed a withdrawal, which key each uses for production, or whether old local TAL data still survives.

The timer belongs to the validator

The phrase “30-day acceptance timer” invites a misleading picture: one date is published, 30 days pass, and the Internet moves together. RFC 9691 specifies something more cautious.

When a Relying Party successfully verifies B and did not see that same successor on its previous successful validation run, it starts a 30-day timer for that TA. It continues normal top-down validation with A. B may be tested, but it must not yet become the production root through this process. On later successful runs, the RP checks that the successor relationship persists. Only after its own timer expires may that RP update its current key details and restart validation from B.

The start event is therefore local. A continuously running validator might begin on the first publication day. A validator behind an outage might begin a week later. A seasonal or newly installed instance might start months later. A validator that does not implement automatic TAK transition may only alert an operator. One that never processes TAK continues from the key in its TAL or equivalent configuration.

A useful receipt names the validator instance, implementation and version, current TAL fingerprint, current and successor key fingerprints, URI sets, first successful observation, previous successful run, timer start and expiry, every cancellation or restart, and the production root actually selected. “TAK published for 30 days” omits the subject whose acceptance matters.

Absence and change are evidence, not noise

If successor verification fails, or the current TAK no longer includes B, the RP cancels its timer. A changed successor key or certificate URI set creates a new transition fact. This protects the RP from silently accumulating time across incompatible offers.

RFC 9691 warns against withdrawing B and later re-adding the identical successor. A validator may have fetched the offer, missed the withdrawal, and kept its old timer. It could then switch earlier than peers that observed the gap. Changing the successor URI set forces a fresh timer without requiring a new SubjectPublicKeyInfo.

This detail turns collection history into part of the authority proof. The latest TAK alone cannot reconstruct whether a validator saw an uninterrupted offer. An operator needs per-run observations or a cryptographically bound local state record. A monitoring platform that stores only the current object can show a correct present state while erasing the reason two validators will switch on different days.

One key in use, two repositories to keep equivalent

During the overlap, a supporting RP uses one production key at a time. The TA, however, may need to maintain A and B together because older or non-supporting RPs still depend on A.

RFC 9691 requires separate repository directories for the maintained key pairs. Except for their TAK objects, the current CA certificates and delegated content must be equivalent. Internet Number Resources must match. Delegations to child CAs must be represented under both roots. A resource reduction or revocation is not fully effective until all relevant publication points reflect it; a resource extension must not be disclosed to the child before all roots can validate it.

With one publication server, the RFC 8181 publish and withdraw operations for both roots belong in one query to reduce inconsistent views. With multiple servers, short divergence remains possible and must be bounded. A valid A-side TAK and a valid B-side TAK do not prove that every delegated certificate, manifest and CRL generation is equivalent at the moment a particular RP fetches them.

The migration ledger should therefore hash the validated product set under A and B, retain publication generations and timestamps, and explain every temporary difference. The relevant outcome is not byte identity—URIs and issuers can differ—but validation equivalence for the same resources and delegations.

Four phases, four different decisions

The standard describes a planned roll in four phases. First, A publishes a current-only TAK so the operator can establish that it can maintain the object. Second, B is created, equivalent material is published, and the reciprocal successor/predecessor pair appears. Third, the TA distributes a new TAL for B while retaining A for validators that do not use TAK. Fourth, A’s repository is removed and its private key destroyed.

These are not one transaction. Phase two proves the new path can be validated. Phase three changes bootstrap material through in-band or external distribution channels. Phase four withdraws an old recovery path and an old authority. Each needs its own owner and rollback boundary.

RFC 9691 recommends using different certificate URI sets in the B TAL and B TAK during phase three. That separation can help estimate which clients arrived through the TAK path. It does not reveal every validator, and a missing request is ambiguous: retirement, outage, caching, package update, local removal, or unsupported software can all look quiet.

An RP seeded with an old TAL may need one 30-day period for every key generation it missed. If A has been removed, it cannot validate the current tree long enough to learn its way forward and must be repaired locally. Keeping A indefinitely avoids that cliff but preserves the old private key and repository as authority surfaces. Retirement is a governance decision, not a consequence of the timer.

The signed object cannot repair a compromised root

TAK improves planned transition. It does not protect against compromise of the current or successor private key. A current TA key that can sign the RPKI root already controls the signed transition evidence. Reciprocal objects make the intended path mechanically testable; they do not create an authority outside the compromised root.

Out-of-band conversion has its own boundary. A TAK can carry TAL-like data, and distributors may convert a validated TAK into a TAL. If the TAK is not rooted in a TA already trusted by the RP, it has security properties similar to an unauthenticated TAL file: trust moves to the distribution source. Package updates can help non-TAK validators, but they are a separate channel with separate respect for local operator choices.

RFC 8630 defines the TAL bootstrap. RFC 6487, RFC 6488 and RFC 9286 provide certificate, signed-object and manifest validation. None observes the whole validator population. RFC 9319 defines route-origin validation states downstream; a successful trust-anchor transition still does not prove a router loaded a payload or forwarded traffic accordingly.

Lu Heng’s minimum-specification discipline fits the design: standardize the smallest interoperable transition and leave deployment timing, telemetry and exceptions with accountable operators. Reality-layer discipline keeps TAK publication, local timer state, repository content, validated payloads, router policy and packet outcome from borrowing one another’s authority. Running-code primacy makes observed per-validator state stronger than a calendar declaration.

Sources