Summary

  • The NRO’s December 2025 roadmap listed short-lived Trust Anchor certificates as a core RPKI feature, then offered by APNIC, ARIN and LACNIC, with an end-of-2025 target for all five RIRs.
  • On 29 August 2026, AFRINIC’s published TAL still retrieved a self-signed root certificate valid from 30 March 2020 to 28 March 2030.
  • Those facts expose a public evidence gap, not a proven outage or failed validation: the roadmap does not define “short-lived”, record an AFRINIC exception, or show whether later implementation work occurred.
  • A delivery receipt should join the feature definition, issued certificate, stable TAL key, repository availability, relying-party refresh evidence, exceptions, rollback and correction history.

One row promised a state the live certificate does not explain

The most revealing line in the NRO’s RPKI roadmap is only three cells wide. The feature is “Short-lived TA certificates”. APNIC, ARIN and LACNIC appear in the column for registries already offering it. The date by which every Regional Internet Registry would offer it is “End of 2025”.

That table was last modified on 2 December 2025. It was therefore still a forward-looking commitment when published, not a year-end completion report. Nothing is inherently wrong with that. A roadmap is supposed to describe intended movement. The problem begins when the target date passes and the public record does not acquire a second entity: evidence of delivery, deferral, exception or revised meaning.

AFRINIC’s live trust-anchor material provides a precise test. On 29 August 2026, its published Trust Anchor Locator was retrievable. The TAL pointed to AfriNIC.cer at the registry’s RPKI repository. The fetched self-signed certificate identified itself as AfriNIC-Root-Certificate, carried serial E5CF72BA6C7E9E28, and had a validity interval beginning on 30 March 2020 and ending on 28 March 2030.

The certificate was there. Its repository address worked. Its fingerprint could be recorded. None of those observations establishes a service failure. They instead create a simpler discrepancy: a public programme promised a short-lived-certificate capability across all RIRs by the end of 2025, while the certificate AFRINIC served eight months later still exposed an approximately ten-year interval.

There may be a benign explanation. The roadmap page may be stale. AFRINIC may define the feature through a mechanism not visible in the checked pages. An internal rollout may be planned or tested. An exception may have been approved. The 2020–2030 certificate may be intended to remain until a controlled reissuance event. The NRO may use “short-lived” in a precise way that was documented elsewhere but not linked from the roadmap.

The evidence package does not decide among those possibilities. That is the point. A target date should not require an operator to invent the state that followed it.

“Short-lived” needs a definition before it becomes an audit result

It is tempting to take ten years, compare it with the adjective “short-lived”, and declare the target missed. That would move faster than the sources permit.

The checked NRO roadmap names the feature but does not publish a maximum lifetime, renewal cadence, permitted overlap or exception rule. Its companion baseline catalogues many differences among RIR services, but it does not close this particular row with a dated AFRINIC implementation record. Without a defined threshold, this article cannot honestly say whether two years, one year, ninety days or some other period is the programme’s acceptance condition.

The visible certificate interval still matters. It is not a rumour, projection or marketing phrase. It is an operational artifact retrieved from the URI published in AFRINIC’s TAL. It supplies a lower-level fact against which the higher-level commitment can be tested. What it cannot supply is the programme’s missing definition or the institution’s decision.

This distinction is central to infrastructure accountability. A commitment is what an institution says it intends to deliver. An artifact is what an observer can retrieve. An acceptance record is the evidence by which the responsible actor declares that the artifact satisfies the commitment. Collapsing the three states rewards good announcements and makes implementation dependent on inference.

A competent register should be able to say one of five things without drama: delivered under the published definition; delivered with an identified exception; deferred to a new date for a stated reason; replaced by a different control; or not yet complete. Silence is not a sixth technical state. It is the absence of a public state.

The TAL pins a key, not an eternal certificate

RFC 7730 explains why shorter certificate life does not necessarily mean repeatedly redistributing a new trust decision to every operator.

A Trust Anchor Locator contains retrieval locations and the public-key material used to verify the trust-anchor certificate. The referenced object must be a current, self-signed RPKI CA certificate. Its public key must match the key in the TAL. The trust-anchor key is expected to remain stable when the certificate is reissued because resources change or the certificate is renewed before expiry. A replacement certificate remains available through the same stable URI.

That architecture separates key continuity from certificate lifetime. An RIR can retain the trust relationship pinned by the TAL while renewing the certificate that expresses current resources and dates. Reissuance need not mean a new key ceremony for relying parties. Key rollover is a different and more consequential operation.

The separation also creates multiple delivery steps. The RIR must issue the replacement correctly. The repository must serve it at the expected location. Relying-party software must retrieve it, check that it is current and self-signed, confirm the TAL key match, and perform its local acceptance checks. RFC 7730 says those functions should occur during repository resynchronisation and before the cached certificate expires.

Thus “we issued a shorter certificate” would still not prove that the whole transition worked. “The roadmap date passed” proves even less. The useful operational claim is a chain: defined lifetime, successful issuance, stable-key match, publication, observed retrieval, bounded exceptions and a tested correction path.

This chain should not be confused with route validity. A trust-anchor certificate sits above a certification tree from which relying parties derive validated RPKI payloads. The frozen record contains no evidence that a route became RPKI Invalid, that a router rejected a prefix, that a repository refresh failed, or that an operator cached the wrong object. Those are downstream events requiring their own observations.

A shorter clock moves work; it does not abolish risk

The strongest case for short-lived trust-anchor certificates is not that short automatically means safe. It is that a shorter validity horizon can limit how long an obsolete certificate remains usable as current state and force renewal discipline to become routine rather than exceptional.

That benefit depends on the rest of the system. Frequent reissuance creates more opportunities to observe whether automation, repository publication and relying-party refresh behave as designed. It can make a broken renewal process visible earlier. It can also make operational dependence on those processes more immediate. If issuance or publication fails near expiry, the shorter interval provides less time to diagnose and repair the fault.

Long-lived certificates make renewal less frequent but can allow an old expression of resources and dates to remain acceptable for longer. Short-lived certificates reduce that duration only if replacement and retrieval are dependable. The trade is therefore not security against convenience. It is one failure distribution against another.

That is why the feature deserves a public acceptance record. A status of “implemented” should not mean merely that code capable of issuing a certificate exists. It should say which production certificate demonstrates the policy, when the change began, whether old and new states overlapped, how repository availability was checked, how relying-party behaviour was sampled, and what happens if the next certificate is not available in time.

No private key, HSM layout or attack-useful procedure needs to be published. The record can disclose dates, hashes, result classes and aggregate observations while keeping sensitive operational detail protected.

The missing entity is a delivery receipt

For this feature, a compact receipt would begin with the exact definition the roadmap omitted. It would state the normal trust-anchor certificate lifetime, renewal lead time, overlap rule and exception authority. If “short-lived” is relative rather than an absolute number, the comparison and baseline should be explicit.

The next fields would describe the production artifact: issuing RIR, certificate serial and SHA-256 fingerprint, notBefore, notAfter, repository URI, and a confirmation that the public key matches the TAL. These are public certificate facts, not security secrets.

The receipt would then distinguish three operational populations. First is the authoritative publication point: did the expected bytes become available at the stable URI? Second is the monitored relying-party sample: did validators retrieve and accept the new certificate during the intended interval? Third is the unknown population outside the measurement boundary. A test result should never be inflated into a claim about every validator on the Internet.

Exceptions belong in the same record. An older certificate may remain served because a dependency has not completed, because a safety review required a longer overlap, or because the feature definition changed. The public does not need privileged deliberation. It needs an exception identifier, responsible owner, bounded reason class, review date and closure condition.

Finally, the receipt needs an additive correction history. If a fingerprint was recorded incorrectly, a certificate was replaced, a date changed or the programme reclassified the feature, the earlier state should remain visible with the correction. Infrastructure memory is lost when pages are silently rewritten to make an old target look as though it always described the present.

This is an AFRINIC test inside a five-RIR promise

The NRO RPKI Program is a coordination mechanism. Its page assigns executive sponsorship to the NRO Executive Council, operational direction to a programme manager, technical direction and advice to a steering group containing experts from all five RIRs, and execution to RIR specialists and consultative groups.

That structure can reduce needless difference. An operator holding resources through more than one registry should not have to relearn every security workflow or accept avoidable variation in basic service. Joint baselines and roadmaps make comparison possible.

Coordination does not make the NRO the operator of AFRINIC’s certification authority. The individual RIR still issues and publishes its trust-anchor material. Relying parties still choose and maintain their trust anchors. Network operators still decide how validated data influences routing policy. A programme target can align work, but it does not perform the work.

The current case should therefore be read narrowly. AFRINIC’s certificate offers a clear, reproducible observation inside a shared commitment. It does not prove that AFRINIC’s RPKI service is broken. It does not prove that the NRO misrepresented implementation. It shows that the public chain stops before a reader can connect the end-2025 target to an accepted AFRINIC production state.

That gap is repairable. The NRO can update the roadmap with a definition, per-RIR state, evidence date and exception note. AFRINIC can publish the certificate-lifetime policy and the observable acceptance facts for its next issuance. Both can preserve the old row as history rather than replacing it silently.

The trust anchor itself should remain boring. The accountability around it should become precise.

Sources