Summary

  • A route origin authorization is not a self-standing declaration. It is accepted only through a valid certificate path rooted in an RIR trust anchor. The parent CA can issue, replace, narrow or revoke the certificate beneath which an operator's ROAs are signed.
  • Registration and certification are deliberately aligned. This makes the cryptographic statement reflect current resource records, but it also means a transfer decision, contractual-status error, court order or account action can alter the set of route authorizations seen by relying parties.
  • Revocation does not issue a command to the global routing table. A lost ROA may cause an announcement to become NotFound, while a changed or competing authorization can make it Invalid. Networks then apply their own routing policies. The effect is distributed, variable and potentially serious.
  • The RIPE NCC's December 2020 legacy-resource incident demonstrated the propagation mechanism: an error in contractual status narrowed certificates, deleted hosted ROAs and caused delegated ROAs to disappear or overclaim. It is evidence of a real control path, not evidence of a universal failure rate.
  • Delegated RPKI gives the operator its own signing key and operational control over its child CA. It does not remove the RIR parent. The parent still determines the certified resource set and can revoke the child certificate under stated conditions.
  • Stronger governance should include prospective revocation grounds, risk-based notice, machine-readable change previews, make-before-break transfer plans, emergency restoration, written reasons, independent review and public incident accounting. Liability exclusions should not substitute for prevention and remedy.
  • Number Resource Society can contribute constructively by comparing parent-CA rules, publishing continuity checklists and representing smaller holders in technical-policy debates. Its advocacy does not itself confer certificate authority or prove an alternative trust arrangement.

The decisive packet is evaluated far from the registry

Consider an ordinary announcement of a prefix from an operator's autonomous system. The operator has configured BGP correctly. Its transit providers receive the route. Somewhere else, however, a relying-party validator has fetched RPKI material, built a set of validated route origin authorizations and passed the resulting payloads to routers. Those routers compare the prefix and origin AS with the payload set. The announcement can be Valid, Invalid or NotFound. Each network then applies its own policy.

The registry does not sit in the packet path. It does not press a button that withdraws the route from every router. Yet it sits above the cryptographic evidence used in that distributed decision. If the certificate path to the operator's ROA ceases to validate, that ROA no longer contributes a valid payload. If another covering authorization remains, the route may become Invalid. If none remains, it will generally become NotFound. A network that rejects Invalid routes can then refuse the announcement; a network that accepts NotFound routes may continue carrying it.

That sequence is the mechanism that matters. The administrative event occurs at a parent CA. Repositories distribute the changed entities. Validators refresh their local views. Routers receive new validation data. Independent network policies convert that data into reachability consequences.

The gaps and caches in this chain matter. Different validators refresh at different moments. Operators can retain data during repository trouble. Router policy is not uniform. There is no honest basis for claiming that one certificate event instantly disconnects a prefix everywhere. There is equally little basis for treating revocation as a harmless clerical edit. The architecture was designed so cryptographic status could influence routing. Governance must take that influence seriously without exaggerating its uniformity.

The operator's signature is conditional

The attractive story of RPKI is holder control. An address holder authorizes an origin AS by creating a ROA. Cryptography lets others verify that the statement came from a key associated with the certified resources. This is a valuable correction to a routing system in which BGP announcements otherwise carry no built-in proof that the origin is authorized.

But the holder's key is not sovereign. RFC 6480 describes a hierarchy aligned with the allocation of Internet number resources. A resource certificate binds a public key to IP address blocks and AS numbers. The validity of a signed entity depends on a certification path to a selected trust anchor, on certificate validity, on revocation information and on the resources permitted at each level.

An operator using a delegated CA controls the private key of that child. A parent cannot use that key to forge the child's signature. This distinction is substantial. It protects the integrity of the operator's own signing act and permits local automation, sub-delegation and key-management choices.

The parent retains a different power. It can issue the child certificate, change the resources covered by a replacement certificate or place the certificate on a revocation list. A child signature over resources no longer supported by a valid parent path cannot make itself valid by mathematical insistence. The parent need not possess the child key to make the child's assertions cease to count.

Hosted RPKI compresses the distinction further. The RIR operates the holder's CA and stores the private key in its infrastructure. The holder chooses routing intentions through a portal or interface, while the service performs signing, renewal and publication. The resulting ROA may accurately express the holder's instruction, but cryptographic custody and parent authority are located within the same institution. Convenience therefore changes the allocation of control, not only the amount of technical work.

Registration truth becomes cryptographic scope

RPKI was not accidentally attached to RIR records. Its central promise is that a certificate reflects a current delegation of number resources. APNIC's certification practice statement explains the arrangement plainly: the organisations issuing certificates are also the organisations that perform the delegation, and are therefore authoritative about that binding. RIPE NCC documentation says its resource certificates are linked to registered organisations and automatically change when resources are added, returned, moved or transferred.

This alignment prevents a former holder from relying indefinitely on an old certificate after a legitimate transfer. It lets a recipient establish new authorizations and allows relying parties to reject stale claims. Without a parent capable of updating scope, RPKI would protect old routing intentions at the expense of current registration.

The same alignment gives administrative records a second life. A name, status or contractual relationship in registry systems is no longer used only to answer who receives service or what appears in RDAP. It can determine which prefixes enter a resource certificate. That certificate determines which signed entities can validate. The path from registration to routing evidence is intentional.

The governance question is not whether to sever that path. Doing so would defeat the purpose of resource certification. It is how to constrain errors and discretionary action where the path begins. If a resource is removed after a completed transfer, the old holder's authorization should cease. If a temporary account mismatch, contested invoice or mistaken legal classification produces the same result without adequate safeguards, the security mechanism has carried an administrative defect into a more consequential layer.

The distinction between accurate correction and premature enforcement must be made before revocation. Cryptography can show that a parent signed a new certificate or listed an old one on a CRL. It cannot show that staff interpreted a merger correctly, that notice reached the right officer, that a sanctions match was sound or that a disputed transfer deserved immediate effect. Those are institutional questions surrounding the signed act.

Revocation is not one outcome

The word revocation suggests a single switch. The routing result is more conditional. RFC 6811 defines three route-origin validation states. A route is NotFound when no validated payload covers it. It is Valid when at least one payload covers and matches the route. It is Invalid when at least one payload covers it but none matches.

Suppose a holder has one exact ROA for a prefix and the certificate path disappears. Once validators stop accepting that ROA, no covering payload may remain. The route then moves from Valid to NotFound. Many networks accept NotFound because RPKI deployment is incomplete and rejecting every uncertified route would still be destructive. The immediate effect may therefore be a loss of validation protection rather than loss of reachability.

Now suppose a broader valid ROA remains under another CA, or a replacement authorization covers the prefix with a different origin or maximum length. The route can become Invalid. Networks that reject Invalid routes may drop it. Others may lower preference, tag it for monitoring or accept it. RFC 7115 makes the final policy local; validation status informs routing rather than dictating one universal response.

This variability is no reason for complacency. A route does not need to disappear everywhere for harm to be material. Selective rejection by large transit providers, cloud networks, public-sector peers or content platforms can fragment access. A prefix that becomes NotFound loses the assurance on which customers may rely. An operator may also face an urgent need to recreate ROAs under a new certificate while caches converge at different speeds.

Governance language should therefore avoid two errors. It should not say the RIR directly controls every route. Nor should it claim that a certificate change affects only an optional security label. The parent controls an input to decisions made across many autonomous networks. The distributed nature of the final action reduces neither the parent's duty of care nor the operator's need for continuity planning.

The design choice emerged before mass operational use

The modern arrangement took shape over years. Work by RIRs and the IETF preceded the 2012 publication of the principal RPKI architecture documents. A RIPE policy proposal numbered 2008-08 debated how certificates should reflect registered resources and stated that certificates would at all times reflect registration status, although that proposal was later withdrawn. APNIC was already reporting resource-certification work in 2009. These were not merely discussions about better encryption. They concerned which institution would attest to resource control.

Production services arrived around 2011. The RIPE NCC launched a hosted resource-certification service at the start of that year, initially with a limited feature set. Its launch announcement presented the service as a way to make the registry more robust and routing more secure. Later in 2011 it offered a local certification proof of concept in which an operator could run its own CA with the RIPE NCC as parent. LACNIC records hosted service from January 2011 and delegated service from December 2019. Regional timing and capabilities differed.

The core IETF documents published in 2012 separated the functions cleanly on paper. RFC 6480 described the architecture. RFC 6482 specified ROAs. RFC 6483 explained route-origin validation. RFC 6492 specified exchanges through which a child CA requests certificates and a parent issues or revokes them. Later work added publication protocols and analyzed adverse CA action.

The institutional settlement was pragmatic. RIRs already maintained resource records, authenticated holders and coordinated uniqueness. Placing them above resource certificates avoided creating an unrelated global title authority. Hosted service lowered the entry cost for operators that did not want to run a CA or repository. Delegation preserved a route for organisations requiring stronger key control.

That settlement deserves credit. It also deserves periodic constitutional review. A function that began as an optional security service now supplies evidence consumed by more networks and more automated systems. As reliance grows, service terms written for experimentation may become inadequate for infrastructure whose errors can alter reachability. The relevant test is not whether the original design was malicious. It is whether governance has matured with operational consequence.

The parent CA is more than a technical relay

RFC 6492 gives parent and child systems a standard language for listing resources, requesting issuance and requesting revocation. It does not decide why a parent believes a resource should be included, whether a transfer is complete or what process should precede an involuntary change. The protocol faithfully carries a decision made elsewhere.

This is common in infrastructure. Technical standards define how a command is authenticated and represented. They do not supply the entire public law of the institution permitted to send it. A validly signed revocation can still be premature, mistaken or procedurally unfair. Conversely, a parent can be obliged to revoke even when an operator would prefer delay, such as after a confirmed compromise or completed transfer.

The RIR therefore performs at least three related roles. It maintains registration information. It decides the resource scope that its certification service will attest. It operates, or parents, CAs that translate that scope into cryptographic entities. In hosted service it may also hold the user's private key and publish the user's signed entities.

Role concentration can improve consistency. When a transfer closes, one institution can update the record, replace certificates and help the parties construct new authorizations. It can also amplify an error. A mistaken status change need not wait for a separate organisation to act; automation may carry it directly into certificate issuance and repository state.

Governance should match the concentrated role. The parent should document the mapping between registration events and certificate events. It should distinguish changes that can occur automatically from those requiring human confirmation. It should identify who can authorize an emergency revocation, how dual control works, what evidence is retained and how an operator can challenge a mistake. A certification practice statement can describe technical practice; service terms and community policy must also define the legitimacy of the decision.

A 2020 incident revealed the propagation path

On 17 December 2020, the RIPE NCC reported an error involving legacy resources. A programming mistake in the implementation of an unrelated registry item set the contractual status of affected legacy resources to none. Those resources then became ineligible for certification.

The consequences followed the hierarchy. Resource certificates for 36 CAs were updated to contain fewer certifiable resources. Forty-one hosted ROAs, producing 202 validated payloads, were deleted from 24 CAs. Certificates issued to affected delegated CAs shrank; depending on their software, their ROAs disappeared or were rejected for overclaiming. The RIPE NCC restored the contractual status of 105 affected resources and recreated the hosted ROAs. Delegated operators were advised to check whether they needed to recreate theirs.

The numbers should be kept inside the event. They do not establish an annual error rate, a global denominator or a comparative failure measure for RIRs. The post-mortem also does not prove that every affected route became unreachable. Validation state and network policy determine that outcome.

What the incident proves is the mechanism. A contractual-status error in the registration environment propagated into certificate scope and route-authorisation material. Hosted and delegated users experienced different recovery obligations. The RIR could recreate hosted ROAs it operated, while delegated holders might need to act within their own CAs.

The RIPE NCC said it would improve quality assurance, acceptance testing and risk-based impact analysis. Those are sensible measures. The broader lesson is that changes near the registration-to-certificate boundary deserve the same care as changes to a router platform. Testing should include the expected certificate diff, ROA and validated-payload impact, transfer effects, delegated-client behavior and restoration path. A registry change that appears administrative may have a cryptographic blast radius.

Transfer is the hardest ordinary case

Emergency compromise is dramatic, but transfer is the recurring governance test. The registry must stop certifying the former holder and begin certifying the recipient. Routing may need to continue throughout. The origin AS may remain the same, change once or change in stages. The seller, buyer, broker, transit provider and RIR may each control a different part of the sequence.

RIPE NCC guidance says that when a resource is moved or transferred, the registered organisation and certificate change; underlying ROAs are removed and must be recreated. Its hosted documentation also says resources are automatically added or removed from certificates as registered holdings change. This behavior protects the recipient from stale claims by the former holder. It creates a cutover dependency that should be treated as part of settlement.

A high-quality transfer plan begins before the registry update. The parties should inventory every ROA and actual announcement, including more specifics, multiple origins and temporary mitigation providers. They should agree which authorizations must exist after closing, who will create them, how access to the recipient's CA will be confirmed and how validators will be observed. The RIR should provide a machine-readable preview of what will be removed and what the recipient can create.

The principle is make before break wherever the architecture permits it. The outgoing authorization should remain valid until the incoming authorization is published and retrievable, unless security or law requires immediate removal. Where regional systems cannot support overlapping certification, the limitation should be explicit and the cutover should have a tested rollback or accelerated restoration route.

Not every overlap is safe. Certifying two parties for the same resources can create competing claims or extend former-holder power. A bounded transition can nevertheless be safer than an unannounced gap. The policy design must specify duration, permitted entities, approval, monitoring and automatic expiry. Transfer continuity is not a request to preserve obsolete rights indefinitely; it is a request to sequence valid rights without avoidable routing damage.

Notice must arrive before the cryptographic event when possible

Traditional notice is often an email saying that an account status changed. That is too weak when the event can alter certificate scope. The message may reach a billing contact rather than the routing-security team. It may describe a contractual issue without listing the prefixes, certificates or ROAs at risk. It may arrive after automated systems have already acted.

Notice should be risk-based. A confirmed private-key compromise may justify immediate revocation, followed by rapid notification and replacement. A completed voluntary transfer follows an agreed schedule. A disputed payment, sanctions match, suspected policy breach or uncertain corporate succession usually allows a warning period unless a concrete threat demands urgency.

For non-emergency action, the operator should receive a precise preview: affected resources, current certificate identifiers, signed entities expected to cease validating, effective time, reason, authority, available cure and review route. The preview should be available in the portal and in a signed machine-readable form so large operators can compare it with routing intent.

Delivery should use independently maintained operational and legal contacts, not only the account credential that may be disputed or compromised. Acknowledgement should be recorded, but lack of acknowledgement should not create an endless veto. Escalation can proceed through repeated channels and a published timetable.

The notice period should support a correction. If the registry has attached the wrong organisation, misread a merger document or matched the wrong sanctioned party, staff must be able to pause non-emergency action while evidence is reviewed. If the action is correct, the operator gains time to prepare new ROAs or customers for a validation-state change.

Good notice is not a promise that every route stays Valid. It is a disciplined handoff between administrative authority and network operations. It reduces surprise, creates an evidentiary record and makes later accountability possible.

Reasons and review are security controls

Institutions sometimes treat due process as delay imposed on technical security. Here it is part of security. A parent that can revoke quickly needs controls against account takeover, insider error, false legal claims and misunderstood registration changes. Written reasons and independent review force the decision to be tied to evidence and authority.

Revocation grounds should be prospective and finite. Examples include confirmed key compromise, holder request, certificate inconsistency with a completed registration change, expiration of the relevant service relationship, a binding legal order, demonstrated fraud, or persistent failure of a delegated CA under a published policy. Broad phrases such as operational reasons should be accompanied by thresholds, approval roles and restoration duties.

Review must fit the timescale. A routine appeal decided months later cannot protect a route cutover occurring this afternoon. The first layer should be a rapid technical and registration check by staff not responsible for the initial action. A second layer can consider contractual or policy disputes. Emergency action may remain in force during review when continued certification creates a serious risk, but the institution should explain why.

The reviewer needs more than the current record. It should see the event history: who changed the registration status, which rule was applied, what certificate diff resulted, what notifications were sent, which approvals were obtained and what restoration options exist. Operators should receive as much of that reasoning as security and privacy allow.

Publication of anonymised decision classes can improve consistency. Members can see how often emergency and non-emergency grounds are used, how quickly mistakes are restored and whether regional policy produces recurring transfer gaps. Aggregate reporting must not invent precision where events are rare, but silence leaves the community unable to assess concentrated power.

Delegation narrows one dependency, not the hierarchy

Delegated RPKI is sometimes presented as the answer to RIR control. It is a partial answer. The operator generates and protects its private key, runs its CA software and decides which entities to sign. It can integrate authorization changes with network operations, manage resources from several parents in one system and potentially issue child certificates.

These are important controls. A hosted-service portal outage need not prevent the delegated holder from creating a new ROA. RIR staff cannot use the child's private key to sign a different statement. The holder can retain its own signed event history and choose a separate publication service.

The parent still controls the certificate that makes the child authoritative for a resource set. RFC 6492 allows the parent to issue and revoke certificates. If registration changes, the parent can provide a certificate with fewer resources. If the child continues signing the old scope, validators will reject overclaiming. Delegation therefore separates signing custody from registration authority; it does not abolish registration authority.

RIPE-847 makes this explicit in another context. Since October 2025, if the RIPE NCC cannot discover and validate a delegated CA's current manifest and CRL for more than three months, the resource certificate is to be revoked after reasonable efforts to discover current material and notify the operator. The policy addresses persistently non-functional CAs and the burden they impose on relying parties, not brief imperfections.

That is a legitimate parent function with governance consequences. A delegated operator gains control and assumes duties. The parent gains a ground for revocation and must apply it predictably. Monitoring must avoid false positives caused by the parent's own reachability problems. Notice should identify failed checks and allow the holder to demonstrate valid publication. Restoration should be documented.

Delegation is best understood as constitutional separation within the hierarchy. It prevents the parent from doing everything, but not from doing anything.

Repositories form a second control surface

Certificates and ROAs have to reach relying parties. RPKI repositories publish certificates, revocation lists, manifests and signed entities. RFC 8181 defines a protocol through which a CA can ask a publication server to publish or withdraw entities. Hosted service normally combines CA and repository operation. Delegated holders may publish themselves or use an RIR's publication service.

This distinction matters because possession of the signing key and ability to distribute the signed entity are different powers. A delegated holder that uses publish-in-parent keeps its key but depends on the parent-operated repository accepting and serving its entities. A holder that self-publishes gains more distribution control and also takes responsibility for globally available service, fresh manifests, current revocation lists and resilience against operational failure.

Repository unavailability does not translate mechanically into immediate route rejection. Validators cache material and apply rules for stale or unavailable repositories. Different implementations and local settings can create different timing. But stale publication can prevent intended changes from reaching the world, and invalid manifests or revocation information can cause a branch to be rejected.

The institutional map should therefore state four controls separately: registration scope, parent certification, child signing and publication. An organisation may control one, two or three without controlling all four. Contracts and continuity plans that say only that the operator has its own key are incomplete.

The same separation improves incident analysis. If a new ROA does not appear, the cause may be a failed child signing operation, rejected provisioning request, failed publication request, repository synchronization problem or relying-party cache. Blaming the abstract RPKI obscures where authority and responsibility actually sat.

Court orders and sanctions require a narrow bridge

RIRs operate under law. A court may decide a corporate dispute, order preservation or transfer of assets, restrain an account or address alleged fraud. Sanctions rules may prohibit service to a listed person. A registry cannot promise to ignore binding legal duties because routing continuity is valuable.

The danger lies in translating broad legal pressure into certificate action without a defined bridge. An order concerning shares in a company may not instruct the RIR to revoke a resource certificate. A sanctions match may be ambiguous. A creditor's claim may concern payment rather than the validity of a current route authorization. The institution should identify the legal act, the resource relationship and the least disruptive compliant response.

Where immediate revocation is required, the record should identify who authorized it and why notice was limited. Where preservation is allowed, the RIR might freeze transfer while maintaining existing authorization until a court clarifies control. That choice must be grounded in law and policy, not improvised by technical staff.

Cross-border operations complicate the picture. A resource holder, parent company, network, RIR and court may sit in different jurisdictions. RPKI does not solve conflicts of law. Its cryptographic certainty can even disguise legal uncertainty: validators know which certificate path is accepted, not whether the dispute behind a parent action was correctly resolved.

This is another reason to avoid presenting route validation as proof of ownership. RIPE NCC terms expressly deny that its certificates support ownership claims. Resource certificates attest within a coordination system. Courts may use or examine that evidence, but the certificate is not a universal title deed.

Liability should follow preventable control

Current service terms often allocate much of the risk to the user. ARIN's published agreement describes broad termination rights, including immediate termination for several contractual, governmental, technical and security grounds, and a fourteen-day route for termination for any or no reason. It also contains extensive disclaimers, waiver and release language. RIPE NCC terms place use at the holder's risk and limit liability except in cases including wilful misconduct or gross negligence.

The legal effect of these provisions depends on governing law and facts; a comparative article cannot decide enforceability. Their institutional message is nevertheless clear. RIRs want flexibility to operate an evolving security service without becoming insurers of every routing decision made elsewhere.

That concern is legitimate. The parent does not control whether a remote network rejects Invalid routes. It cannot guarantee the availability of every delegated repository or the correctness of the holder's ROA. Unlimited consequential liability could discourage the provision of a public-interest service.

But a complete waiver is a poor substitute for calibrated responsibility. Risk should follow preventable control. The holder should answer for incorrect routing intentions it submits, insecure credentials and failures in a CA it operates. A publication provider should answer for duties it expressly undertakes, subject to reasonable service limits. The parent should answer for grossly deficient authorization, unexplained deviation from published revocation rules, failure to follow a promised transition or avoidable delay in restoring its own error.

Remedies need not begin with large damages. They can include emergency restoration, fee credits, funded technical assistance, preservation of evidence, independent investigation and publication of findings. For serious proven loss, a capped compensation arrangement or insurance mechanism could be considered by each regional community. The central point is that the institution holding the decisive control should not be accountable only in theory.

A parent-action charter would make power legible

Each RIR should publish a compact charter for actions at the registration-certification boundary. It would not replace the technical certificate policy or the general service agreement. It would tell an operator what can happen to its certification state and under whose authority.

The charter should classify events. Voluntary events include holder-requested revocation, key rollover and transfer. Security events include compromise and authenticated emergency requests. Registration events include return, transfer and corrected delegation. Compliance events include sanctions, court orders and contractual termination. Operational events include persistently invalid delegated publication.

For each class, the charter should state the evidence threshold, notice period, approvers, whether make-before-break is available, expected routing-security effect, review path, restoration target and retained records. It should explain differences between hosted and delegated users. It should list interfaces through which operators can obtain a current entity inventory and preview a proposed certificate change.

The charter should also define negative authority: what the RIR will not decide through RPKI. A parent CA should not use revocation to punish lawful policy criticism, settle a private debt unrelated to service, choose between competing network architectures or confer property title. If regional policy authorizes a broader action, the authority should be explicit and reviewable.

Independent audit can test whether actual events follow the charter. Sampling should focus not only on cryptographic key protection but on the correctness of triggers from registration systems. Auditors should examine authorization, timing, notice and recovery. Public summaries can disclose classes and control findings without exposing holder secrets.

This is not bureaucracy added to security. It is the operating constitution of a security service with external effects.

What Number Resource Society can do without claiming the key

Number Resource Society argues publicly for accurate registration, holder control, participation and reduced arbitrary interference. Those principles are relevant to a parent CA because the strongest protection against overreach is not denial of hierarchy; it is transparent, bounded use of hierarchy.

NRS can make a concrete contribution by maintaining a comparative parent-action index. For each RIR, it could record published grounds for certificate replacement and revocation, notice rules, transition facilities, appeal channels, liability language and delegated-publication options. It could test whether pages are understandable to a small operator and identify terms that leave routing consequences unexplained.

It could also publish a transfer-continuity checklist built around entity inventory, recipient readiness, multiple origins, customer delegations, validator observation and rollback contacts. Smaller members often lack a dedicated public-key team. A neutral checklist and table-top exercise would translate institutional risk into practical preparation without asking NRS to operate a CA.

Finally, NRS could collect documented member experiences under strict evidence rules: date, regional service, event type, notice, validation-state effect, recovery and unresolved uncertainty. Aggregation should avoid claiming a rate without a known denominator. The value would be to reveal recurring failure modes and policy gaps.

These roles are positive but bounded. NRS's charter and explanatory pages are first-party advocacy. They do not prove that NRS is a recognised trust anchor, authorised registrar, neutral adjudicator or technically superior certificate operator. Its strongest position is as a civic institution around the hierarchy: making rules comparable, helping holders prepare and pressing regional communities to connect cryptographic power with procedural duty.

The objections are serious but manageable

One objection is that advance notice helps an attacker with a compromised key. That is why the proposed discipline distinguishes emergency security action from ordinary administrative change. Immediate revocation can remain available when delay would extend a concrete threat. Dual authorization, rapid replacement and after-action review make emergency power safer without making it slow.

A second objection is that make-before-break can certify two claimants. Sometimes it can, and a careless overlap would weaken the system. The answer is not a universal overlap. It is a narrow transition tool used only where registration authority, party consent and technical constraints support it, with short expiry and visible monitoring. Where overlap is unacceptable, pre-validation and an agreed cutover can still reduce the gap.

A third objection is that operators already accept service terms. Consent to terms does not eliminate institutional dependence. Many operators have only one regional parent for resources they legitimately hold. The ability to decline RPKI is not a full answer once customers and peers increasingly value validation. Membership governance should improve the terms rather than pretend the relationship is an ordinary competitive purchase.

A fourth objection is that the distributed routing system protects users because networks choose their own policies. It does reduce direct control by the CA. It also means harm can be uneven and hard to measure. Fragmented consequence strengthens the case for precise incident telemetry; it does not excuse an avoidable parent error.

The final objection is cost. Preview tools, rapid review and audit require staff. Yet the RIR already operates authentication, registration, transfer and certification systems. Adding safeguards at the interface between them is cheaper than treating each error as an unforeseeable accident. Fees for certification services should support the controls that make them trustworthy.

Measure the boundary, not a mythical global switch

Accountability needs measures, but not invented global percentages. RIRs can publish counts of parent certificate replacements by cause, emergency revocations, non-emergency revocations, transfer cutovers, restoration events and delegated-CA actions. They can report median and range for notice and recovery where sample size permits, while suppressing details that would identify a holder.

Technical measures should track whether an action matched its preview, whether affected entities were recreated, whether delegated clients required manual recovery and whether repository distribution met declared targets. Registration measures should record how many certificate-impacting events arose from corrected data rather than planned holder action.

Independent observers can measure visible RPKI changes, but they cannot reliably infer every cause from public entities. An absent ROA may be intentional. A certificate shrink may follow a valid transfer. Public telemetry should therefore be combined with audited institutional records rather than replaced by outside guesses.

Operators also need their own measures. They should maintain a current inventory of parent relationships, certified resources, ROAs, delegated children, publication points and routing dependencies. They should alert on unexpected certificate scope changes and compare validated payloads from more than one implementation or vantage point. They should know which customers or services require Valid status rather than assuming every network treats NotFound alike.

The most useful measure is time from a mistaken parent action to restored valid authorization. It tests detection, contact, authority, signing and publication together. A low incident count with a chaotic restoration path is not mature governance.

No public dataset currently supports a reliable cross-RIR probability of wrongful revocation or route loss. That uncertainty should remain visible. It is a reason to publish better evidence, not a license to manufacture reassurance.

Security authority needs a procedural spine

RPKI solves a real problem. It lets an operator's routing intention become cryptographically verifiable and gives networks a stronger basis for rejecting accidental or malicious origins. The hierarchy is not an embarrassing flaw hidden inside that achievement. It is how the system binds authorization to current resource delegation.

But a hierarchy carries power downward. The RIR parent decides which resources a child certificate can cover. A hosted service may also possess the holder's signing key and publish every entity. Registration updates can therefore become changes in route-validation evidence. The 2020 RIPE NCC incident showed that this path is operational, while current regional terms and policies show that revocation grounds and remedies still vary.

The right response is neither to abandon RPKI nor to pretend cryptography removes institutional judgment. Parent CAs need prospective rules, narrowly tailored emergency power, meaningful notice, transfer engineering, quick review, transparent incident accounting and responsibility proportionate to control. Delegated CAs should be encouraged where their benefits justify their duties, but they should not be sold as escape from the parent relationship.

The phrase "certificate authority above the operator" should become a design reminder. The operator may originate the route and sign the authorization. Another institution determines whether the signature sits inside a valid resource chain. When that institution acts accurately, predictably and accountably, RPKI is stronger. When its administrative errors or open-ended discretion propagate unseen, routing security can become a channel for registry risk.

The next phase of RPKI governance is therefore procedural rather than cryptographic. The standards already explain how certificates, revocation lists, manifests and ROAs work. Regional communities must now make equally clear when the parent may act, how continuity is protected and what happens when the authority above the operator is wrong.

Sources