Summary

  • APNIC records prop-166 as endorsed and technically implemented, but still awaiting changes to its Certification Practice Statement and RPKI Terms and Conditions.
  • The policy would permit APNIC to revoke a self-hosted RPKI CA's resource certificate when a current Manifest and CRL cannot be discovered and validated for more than 60 days.
  • The remaining governance question is not whether APNIC can detect a stale CA, but whether the warning, decision, evidence and recovery path are clear enough for operators to rely on.

The most revealing line in APNIC's prop-166 history is not the consensus date. It is the entry for 11 February 2026: “Technical Implementation complete – Awaiting Updates CPS/RPKI ToC.” At the reporting freeze on 5 September, APNIC's proposal index still listed prop-166 under “In Implementation”. The software may be ready, but the public authority that explains when and how it will be used is not yet shown as complete.

That distinction is central to the policy. Prop-166 concerns self-hosted RPKI certification authorities, also called delegated CAs. In APNIC's hosted model, APNIC manages the certificate and publication infrastructure for a resource holder. In self-hosted mode, the holder operates its own CA and publication point, or combines its CA with APNIC's publication service. The holder gains operational control, but it also becomes responsible for keeping the publication chain usable.

The proposal addresses a specific failure mode. If APNIC cannot discover and validate a self-hosted CA's current Manifest and Certificate Revocation List for more than 60 days, APNIC would remove that CA as a child and revoke its resource certificate. The proposal calls for reasonable discovery efforts and notifications to the operator when validation fails and when revocation occurs. APNIC's impact assessment adds that warning emails would be sent to known contacts before removal.

The proposer frames this as waste reduction for relying parties. Validators repeatedly traverse publication points to retrieve and validate signed objects. A CA whose repository remains broken contributes no current validated payload, yet can continue to consume synchronization attempts, CPU, network traffic and operator attention. The proposal text says one misconfiguration can prompt hundreds of thousands of futile attempts. That figure is part of the proposer's rationale; APNIC's impact assessment does not publish an independent measurement for it.

The intended scope is deliberately narrow. National Internet Registry RPKI CAs are excluded. The target is the small population of persistently non-functional self-hosted CAs, not an operator experiencing a brief outage. APNIC translates the proposal's “two months” into a fixed 60-day threshold. It also expects that the affected CA's signed objects, including ROAs, will already have expired before that threshold is reached.

This means revocation is not presented as immediate invalidation of otherwise current routing authorisations. It is the registry closing an abandoned or broken branch after its signed publication state has already gone stale. A holder can recreate a self-hosted CA through the normal process. The action is consequential, but it is not supposed to be a permanent exclusion.

The public record establishes the policy's progression. Version 1 was posted on 31 July 2025. APNIC published its impact assessment on 15 August. The proposal reached consensus at APNIC 60 on 11 September, completed the final call for comments on 14 October and received Executive Council endorsement on 4 December. Technical implementation was recorded as complete on 11 February 2026. What the record does not yet establish is a production enforcement date, a final warning cadence, the number of affected CAs, any completed revocations or measured savings for validators.