Summary

  • RFC 9691 lets a trust anchor signal a successor key in band, but a relying party keeps using the current key while a 30-day acceptance timer runs.
  • A transition record should distinguish successor publication, reciprocal key verification, stable observation, RP cutover and deliberate retirement of legacy support.
  • Evidence from one validator or cohort never proves that every RP has adopted the new key.

A Trust Anchor Locator is deliberately small. Under RFC 8630 it tells an RPKI relying party where to retrieve a trust-anchor CA certificate and gives it the public key needed to verify that the retrieved self-signed certificate is the intended anchor. That out-of-band pin is powerful, but it also means a change of trust-anchor key cannot be treated like an ordinary repository update.

RFC 9691 adds an in-band Trust Anchor Key object. A TAK can name the current public key and certificate locations and also advertise a successor public key with its locations. The successor is not accepted merely because it appears. The relying party validates the successor hierarchy and checks continuity in both directions: the current TAK identifies the successor, and the successor TAK identifies the current key as its predecessor.

When those checks first succeed, the relying party starts a 30-day acceptance timer. It continues production validation with the current key. On later successful runs, the advertised keys and certificate URLs must remain unchanged. If the successor disappears or fails verification, the timer is cancelled. Only after the timer expires under the specified conditions does the relying party move its current trust-anchor details to the successor.

That sequence creates several different facts. The operator may have published a successor. A particular RP may have verified it. That RP may have observed the same transition continuously for the required interval. It may then have switched. None of those facts establishes that every validator has done the same.

The distinction matters because TAK support is not universal by definition. RFC 9691 says a relying party that cannot process TAK objects continues to use the key in its TAL or equivalent manual configuration. An operator may therefore need to maintain old and new key pairs, with separate repository directories, long enough to protect older clients. A stale TAL is not the same condition as a TAK-aware RP whose acceptance timer is still running.

RFC 6489 describes a related conservative rollover for CA keys. It stages a new CA instance, publishes its certificate, CRL and manifest, reissues subordinate products, and only then retires the old instance. RFC 6916 makes the same institutional point at algorithm-migration scale: CA readiness, product reissuance, RP readiness, twilight and end of life are distinct milestones.

An acceptance ledger should therefore bind the current-key fingerprint, successor fingerprint, certificate URL set, current and successor TAK hashes, first verified observation, timer start, continuity observations, transition time, validator identity and software version. It should separately record which TAL-only or manually configured cohorts remain supported and the decision that will end that support.

This is an editorial governance inference, not an extra protocol requirement. The RFC objects prove cryptographic relationships and local validation events. The ledger joins those bounded proofs without turning a sample into a global claim.

Sources