Summary

  • The global RPKI is not literally built on one universal trust anchor. Relying-party software commonly uses TALs for AFRINIC, APNIC, ARIN, LACNIC and the RIPE NCC. But the valid certification path for a given resource normally terminates in one accepted authority at a time, so running several validators does not create several independent issuers for that resource.
  • Validator diversity is valuable. Independent codebases can contain different parser defects, memory-safety failures, transport behaviour, cache strategies and release cycles. Separate instances also reduce the chance that one process failure or maintenance event removes every validated feed available to a network.
  • Every conforming validator still evaluates signed entities within authority supplied by its configured trust anchors. If an accepted parent CA revokes a child certificate, removes resources from it or issues a competing chain, validators are expected to recognise the resulting cryptographic state rather than vote on whether the parent acted wisely.
  • Repository and transport diversity can improve availability, but mirrors cannot manufacture authority. A perfectly replicated adverse certificate or revocation remains adverse, while an unsigned correction from an independent mirror is not a valid substitute.
  • Majority voting among validator outputs is not an institutional appeal. Two stale caches can outvote one current cache; two implementations can share a library or interpretation; and a real authority change can appear first as disagreement. Operators need evidence explaining each difference, not a simple count.
  • Trust-anchor resilience belongs at the authority layer: protected key custody, divided approval, public rollover plans, successor-key staging, independent observation, scoped certificate changes, reasoned decisions, appeal and continuity arrangements. RFC 9691 makes planned trust-anchor key transitions safer but expressly does not protect against compromise of the current trust-anchor private key.
  • Local exceptions such as SLURM can preserve an operator's autonomy during an adverse action, but they are local and can fragment validation views. They are an emergency control, not a replacement global authority or an automatic cure for disputed registry decisions.
  • A Number Resource Society can make authority concentration more accountable by standardising trust-anchor receipts, key-ceremony evidence, change notices, challenge procedures and validator-comparison reports. It should complement independent software rather than market software diversity as proof that registry power has been decentralised.

Diversity begins after the first decision has already been made

An RPKI validator does not discover authority by inspecting BGP and choosing the institution it finds persuasive. It starts with trust-anchor material configured by the operator. A Trust Anchor Locator supplies locations and a public key used to retrieve and authenticate a self-signed certification-authority certificate. From that accepted starting point, the validator follows certificate paths, checks resource extensions, manifests, revocation lists and signed entities, and derives validated payloads.

Two validators written in different languages can perform that work independently. One may reject malformed encoding that another handles incorrectly. One may recover from a repository interruption while another crashes. One may expose a stale manifest clearly while another produces a less useful error. Those differences matter because repository content is untrusted input and the validation surface is complex.

But the validators do not independently decide who is the ultimate issuer. If both are configured with the same TAL public key, both accept the same trust anchor as the starting authority for the resources described by its certificate. They may disagree about whether a descendant entity is syntactically or cryptographically valid. If they agree on the inputs and standards, they should not disagree merely because one prefers the holder and the other prefers the parent CA.

The institutional concentration is therefore upstream of implementation. A validator can prove that an entity follows from the accepted root under stated rules. It cannot prove that the root's governance is fair, that a compelled revocation is proportionate or that the registry's holder record reflects every private legal interest. Cryptographic validation answers a narrower question.

This is why a procurement plan that buys three validator products can overstate decentralisation. It creates three computational witnesses to one configured authority. That is useful resilience, but it is not three independent sources of certification power.

Five regional anchors do not give every prefix five independent votes

Production relying-party software commonly includes trust-anchor locators for the five Regional Internet Registries: AFRINIC, APNIC, ARIN, LACNIC and the RIPE NCC. RFC 8897 says that each relying party chooses its trust anchors and identifies IANA and the five RIRs as obvious default candidates consistent with the number-resource allocation hierarchy. Routinator and FORT documentation show the five RIR TALs in ordinary configuration.

That structure is more distributed than one global root operated by one organisation. A failure confined to one regional tree need not invalidate resources certified exclusively under another. Regional communities, contracts and governance also differ. Any analysis that says the whole RPKI has only one literal trust anchor would be wrong.

The concentration reappears when the unit of analysis becomes a resource. A prefix normally sits within a certification path descending from the trust anchor that covers its allocation. Its holder cannot ask three unrelated RIR roots to issue three equally authoritative certificates merely because the operator runs three validators. During a legitimate inter-regional transition, paths may briefly change or overlap, but that is a controlled exception rather than routine multi-root voting.

Software multiplicity therefore operates horizontally at the relying-party layer, while certification authority is organised vertically. Several validators can traverse the APNIC tree, for example, but they do not transform APNIC's root decision into five regional decisions. If a resource moves to another region, the authority path changes through the transfer arrangements; validator count does not cause the move.

The distinction allows a more exact risk statement. The global system has regional separation. Within the active path for a resource, however, a parent authority can affect every descendant entity that relies on it. A CA certificate revocation can cause relying parties to invalidate subordinate signed entities. Independent validators may confirm that result with admirable consistency. Their agreement then demonstrates concentrated authority functioning as designed, not dispersed authority.

Software diversity is a real control and should not be diminished

The argument against exaggeration is not an argument for monoculture. RPKI relying parties process certificates, revocation lists, manifests, ROAs and other signed entities retrieved from many publication points. They handle ASN.1, cryptographic signatures, URI discovery, RRDP, rsync, cache state, entity expiry and exceptional publication conditions. A defect can corrupt output, consume resources or make validated data unavailable to routers.

Independent implementations reduce common software failure when their independence is real. rpki-client is developed in the OpenBSD ecosystem and emphasises a small codebase, privilege separation and constrained process access. Routinator is a Rust implementation with its own retrieval, storage and validation design. FORT is another open-source relying party with separate operational controls. Their code, release paths and security assumptions are not identical.

The ecosystem has already shown that software stewardship changes. In 2021 the RIPE NCC ended support for its validator and advised operators to move to alternatives rather than continue using unmaintained code. The decision did not weaken RPKI authority; it acknowledged that relying-party software can and should be supplied by an independent ecosystem.

Networks gain several protections from using more than one maintained implementation. A critical parser flaw need not remove every feed. A repository edge case can be compared. A new standards feature can be tested before it becomes the sole production source. Maintenance can occur without operating blind. Different telemetry may reveal an error that one interface hides.

These benefits justify engineering effort. The mistake is to use them as evidence for a different proposition: that certificate and registry authority has been decentralised. A fire door does not diversify the owner of the building. It makes the building safer under a class of failure. Validator diversity should be defended on equally precise terms.

The common trust input defines the boundary of independent judgment

RFC 8630 makes the trust decision unusually visible. A TAL contains one or more locations and public-key information. The relying party retrieves a self-signed CA certificate, checks that its public key matches and decides whether it is willing to accept that entity as a trust anchor for the resources described in the certificate. Once accepted, the anchor is not merely another data source. It is the basis on which descendant attestations become valid.

The RFC also states the severity of compromise. An attacker with the trust-anchor private key can masquerade as the authority. Reliance on an inappropriate or incorrect trust anchor can have similarly severe consequences. The issuer can change the resource set in its certificate without redistributing the TAL key, a flexibility needed because regional resource holdings change. That same design means the relying party places substantial confidence in the issuer's restraint.

Multiple validators using the same TAL do not make separate trust choices unless their operators deliberately configure them differently. Bundled TALs can make the choice almost invisible: installation produces a useful default, and every implementation begins from the same regional keys. Convenience is desirable for adoption, but it should not be confused with an independently negotiated trust relation.

Nor does retrieving the trust-anchor certificate from multiple URLs create multiple authorities. RFC 8630 permits several locations to improve retrieval. Each location is checked against the same public key. A mirror can keep the certificate available; it cannot sign a different authoritative state without the trusted private key.

This boundary gives operators a practical inventory question. For every validator instance, which TAL keys are configured, how were they obtained, who can update them, and which software package can alter them during an upgrade? If three instances receive TAL changes through one unattended package channel, their apparent independence includes a shared bootstrap dependency. The codebases may differ while the root configuration remains operationally concentrated.

A validator cannot overrule a valid adverse act merely because it is adverse

RFC 8211 analyses actions by certification authorities and repository managers that can harm a resource holder. The cause may be attack, mistake, policy action or legal compulsion. A parent can revoke a CA certificate, with the result that relying parties treat subordinate signed entities as invalid. A competing ROA or altered resource set can also change routing outcomes.

From the holder's perspective, the effect may be severe. From the validator's perspective, the task is still to process the accepted certification state correctly. If a properly signed current revocation appears under the configured chain and satisfies the validation rules, a validator is not authorised to ignore it because a public statement alleges unfairness. Doing so would turn each software maintainer into an appellate registry.

Running another implementation does not change this division. Correct implementations should converge on the effect of a valid parent action. Diversity can reveal that one validator failed to fetch the new revocation or mishandled the manifest. It cannot establish that the parent lacked contractual or legal authority. That judgment needs evidence and a forum outside parser logic.

This is the sharpest form of the title's claim. The single trust anchor is not necessarily a single organisation for the whole Internet; it is the singular accepted authority at the top of the relevant path. If that authority or a powerful parent acts adversely, validator plurality can make the consequence more reliably visible. It cannot cure the authority relation that produced it.

The remedy must operate at the authority layer: divided approval for exceptional certificate changes, notice where possible, exact reasons, independent review, appeal, continuity measures and a way to correct mistakes without erasing history. Technical detection supports those controls. It does not replace them.

Agreement among validators is evidence of computation, not institutional consent

Operators often compare outputs from several validators. The practice can identify an implementation defect or stale cache, but the comparison needs a theory of what agreement means. Three identical validated-payload lists show that the instances produced the same result from their current views. They do not show that three registries approved the underlying certificates or that affected holders consented.

The distinction resembles replicated arithmetic. Independent calculators increase confidence that a sum was computed correctly. They do not provide independent evidence that the invoice was lawfully issued. RPKI validators can confirm path and entity validity. The certification authority and registration process determine which statements enter that path.

Even computational agreement has limits. Instances may share a cryptographic library, operating-system component, repository cache, TAL package, network path or update schedule. Two branded products can inherit the same parsing dependency. Three servers can query one local mirror. Diversity should be assessed by failure domain rather than product count.

Disagreement is also ambiguous. One instance may be stale, one may implement a newer RFC, one may reject malformed content and one may have fetched a current revocation first. The minority can be correct. A newly valid authority change will often produce temporary disagreement as caches update. A majority rule that chooses the most common output can preserve old authority precisely when rapid recognition of revocation is required.

For these reasons, comparison should retain explanation. The report should show software and version, TAL key identifier, repository serials or fetch times, manifest state, validation errors and output differences. Operators can then determine whether the cause is code, retrieval, configuration or upstream authority. Consensus without provenance is a weak safety signal.

Majority voting is especially dangerous at the moment of legitimate change

Imagine three validators serving one network. Two have not completed a successful fetch since before a certificate revocation. One has current repository state and removes the affected payload. A simple two-out-of-three policy would keep the revoked authority because the stale view has more votes. The redundancy designed to improve safety would delay a legitimate security action.

Reverse the facts. Two validators accept a malformed or replayed state because they share a defect, while a stricter implementation rejects it. Majority voting again selects the wrong result. Count cannot substitute for causal diagnosis when instances are not statistically independent and the system is not designed as a Byzantine consensus protocol.

A better production design uses diversity for alerting, failover and bounded comparison. Routers can receive feeds from independently operated caches according to vendor capabilities and local architecture. A network can define which instance is authoritative for normal service, when another takes over after a process failure, and when disagreement freezes an automated change or triggers review. Safety policy should distinguish absence of fresh data from a validated removal.

The response can also depend on scope. A discrepancy affecting one prefix should not require abandoning all validated payloads. A complete validator outage differs from a disputed entity. A trust-anchor fetch failure differs from an authenticated change beneath that anchor. Fine-grained telemetry prevents the redundancy layer from flattening every exception into a vote.

There is no universal quorum that makes these decisions correct for every network. Router integrations, risk tolerances and update intervals differ. Operators should publish the logic they use internally and test it against current-state change, stale-cache majority, malformed-entity disagreement and total feed loss. Validator diversity becomes a control only when the selection behaviour is as carefully designed as the instances.

Repository diversity protects availability, not the power to certify

The RPKI repository system is distributed. Child CAs can publish at different points, and RRDP or rsync can make signed products available to relying parties. Multiple locations, content distribution and cached valid state reduce the chance that one server interruption removes all data immediately. They are essential availability controls.

Signed entities also let validators treat repository transport as untrusted. A mirror cannot silently change a ROA and retain a valid signature. Manifests and revocation information help relying parties detect missing, stale or substituted content. This is a strength of the architecture: distribution does not require every delivery server to be an authority.

The same property defines the limit. A mirror cannot issue the holder's missing ROA, restore a certificate that a parent validly revoked or correct an erroneous resource set without authorised signatures. Ten repositories can replicate the same adverse current state. Their independence makes the state harder to suppress, not less authoritative.

Repository managers can themselves act adversely or fail. RFC 8211 considers those cases because suppression or substitution can affect what relying parties validate. Validator diversity can help identify different retrieval outcomes, and repository diversity can provide alternative access. Yet if the relevant CA controls the authoritative manifest and revocation state, distribution does not create a separate institutional check on its signed decisions.

The governance response is to pair availability with accountability. Publication services should be operationally separate where useful, changes should produce verifiable receipts, and independent monitors should archive hashes and times. A missing entity, stale state and authenticated revocation should be reported as different events. The archive can show what changed and when; it cannot unilaterally create replacement authority.

Resilience claims should therefore name the layer. Multi-site publication improves delivery resilience. Independent validators improve processing resilience. Protected and divided CA operation improves issuing resilience. Review and appeal improve governance resilience. Calling all four decentralisation obscures which failure each actually controls.

Trust-anchor rollover solves continuity only if the authority remains trustworthy

Long-lived trust-anchor keys must eventually change. Hardware ages, algorithms evolve, operational practices improve and suspected compromise can require replacement. A rollover is hazardous because relying parties bootstrap from key material already configured out of band. Change too abruptly and parts of the validation ecosystem can lose the tree.

RFC 9691 introduces a Trust Anchor Key entity that can signal current and successor public keys and their certificate locations. It uses an acceptance period and repeated observation so relying parties can stage a successor before switching. The procedure makes planned rollover more orderly and gives operators evidence that successor material remained stable.

This is a material authority-layer improvement. It recognises that root-key transition cannot be delegated to ordinary entity retrieval without safeguards. It also supports independent software because different relying parties can implement or monitor the same staged change.

The security boundary remains explicit. RFC 9691 says the mechanism does not protect against compromise of the current or successor trust-anchor private key. An attacker controlling the current key already possesses the authority needed to direct a malicious transition. Multiple validators faithfully processing the signed transition will not neutralise that control.

Key rollover therefore needs institutional controls around the technical mechanism. Successor generation should use protected facilities and divided approval. The public should receive advance notice, current and successor fingerprints through independent channels, expected dates and recovery contacts. Relying-party developers should test support. Monitors should compare validation outcomes under both keys while equivalence is expected. Destruction or retirement of the old private key should be evidenced after transition.

The lesson is broader than rollover. A cryptographic procedure can make an authority change safe against accidental discontinuity while leaving the authority's concentration intact. Good governance asks both whether the transition validates and whether the people, rules and evidence controlling it are sufficiently constrained.

Key custody should separate possession, approval and observation

A trust-anchor private key is powerful enough that no routine administrator should be able to use it alone and invisibly. Technical custody can place keys in protected hardware, restrict export and require multiple authorised entities for sensitive operations. Organisational custody can separate the people proposing a change, approving it, conducting the ceremony and reviewing the result.

These controls do not create another root, but they reduce the risk that one compromised account or insider can exercise root power. They also create evidence for later review. A certificate issuance, resource-set change or rollover should be linked to an approved event, exact inputs, entities, generated outputs and independent publication observations.

Threshold approval must be substantive. Three approvals from one reporting line using one compromised identity service may look distributed while sharing a failure domain. Entities should represent distinct responsibilities, and emergency access should be narrower and more visible than ordinary access. Recovery materials should not silently bypass the same controls imposed on the active key.

The public cannot inspect secret key material, nor should it. It can inspect governance evidence: current certification-practice statements, key identifiers, ceremony schedules, audit scope, exceptional-action counts, material findings and remediation. Resource holders can receive more detailed evidence when their certificates are changed. Courts and competent authorities can access protected records under applicable procedures.

Validator diversity complements this structure. Independent implementations and monitors can confirm that the published effects match the ceremony outputs and that no unexpected descendant state appeared. They remain observers of authority, not substitutes for divided custody. The strongest design connects both: constrained issuance produces auditable changes, and diverse relying parties verify that those changes propagate as intended.

Registry authority must be reviewable because certification follows registration

RPKI resource certificates reflect the number-resource allocation hierarchy and the issuing institution's recognition of authority. If the underlying registration changes, the certification path can change. A perfectly secured key can still execute an incorrect, overbroad or contested registry decision. Key protection addresses unauthorised use; it does not guarantee sound policy or adjudication.

Institutional controls should therefore begin before signing. The authority for removing resources from a certificate should be explicit. Routine return, approved transfer, contract termination, fraud correction, court order and emergency security response are different grounds. Each should have evidence, decision rights, notice rules where lawful, scope, effective time and review.

A holder challenging a decision needs a forum capable of examining the registration basis, not merely confirming that the CA signature is valid. Review should be independent of the employee or body that made the initial decision. Urgent continuity measures may preserve routing while the dispute is considered, but they should not silently rewrite the final holder state.

Publication should carry reason codes or linked public notices at a level that aids accountability without disclosing protected evidence. A validator does not need private case files to process a revocation. An operator and affected holder do need to know whether the change was scheduled, corrective, security-related or legally restrained so they can seek the right remedy.

This is where institutional legitimacy enters route security. The more networks rely on origin validation, the more consequential upstream registration and certification decisions become. Increased technical enforcement should be matched by stronger due process, not by the claim that independent validator code has already dispersed the power.

Local exceptions preserve autonomy but can fragment the shared signal

RFC 8416 defines Simplified Local Internet Number Resource Management with the RPKI. It allows an operator to filter or add assertions in its local view, including as protection from adverse actions while they are addressed. This is an explicit recognition that relying parties may need bounded autonomy from the global published state.

SLURM can be valuable during an evident error. A network with reliable direct evidence may preserve reachability for itself and its customers while a CA corrects an accidental revocation. The local assertion can be reviewed, expired and removed without pretending that the global RPKI already contains the correction.

The control is not a global cure. A local exception does not change what other operators validate. If many networks create different overrides, the shared meaning of RPKI results fragments. A malicious or careless operator can also use local additions to authorise routes that the global hierarchy does not. The exception mechanism moves responsibility to the local network.

Validator diversity does not resolve that policy question. Different implementations may all apply the same local file correctly while producing an output that differs from the global repository. Comparison reports must identify local assertions; otherwise an operator may mistake an intentional override for an implementation defect or independent authority.

A sound exception policy requires evidence, narrow prefix and ASN scope, named approval, start and expiry, affected customers, review and removal criteria. Emergency use should trigger pursuit of the authoritative correction rather than becoming permanent shadow certification. The operator should be able to explain the difference to peers and auditors without exposing sensitive details unnecessarily.

Local autonomy is thus a safety valve. It reduces dependence on immediate upstream remedy for one network, but it cannot provide the consistent global authorisation that only a corrected authoritative chain can restore.

Constrained trust choices are possible but carry coordination costs

RFC 8630 notes that a relying party unwilling to place broad confidence in a trust-anchor issuer can issue its own self-signed certificate as a trust anchor and impose constraints on subordinate certificates. In principle, local trust configuration can narrow what an external anchor is accepted to cover.

That option demonstrates that relying parties are not metaphysically bound to vendor defaults. They choose the anchors from which they validate. A large operator or consortium could maintain additional constraints, independent distribution and review. Such measures may limit the effect of an anchor claiming resources beyond an expected set.

The cost is coordination. Locally constrained anchors must track legitimate changes in regional resource holdings and transfers. A stale constraint can reject valid certification after resources move. Different constraint sets can cause networks to derive different payloads. The institution maintaining them acquires its own authority and operational burden.

Creating several competing trust roots for the same resources would raise even harder questions. Which root prevails when they disagree? Does any one valid path suffice, allowing an obsolete or captured root to preserve authority? Must a quorum agree, risking stale-majority failure? Who admits and removes roots? Cryptography cannot answer those constitutional choices by itself.

The near-term objective should not be multiplication for its own sake. It should be minimising unreviewable power within the present hierarchy while preserving a coherent validation signal. Strong trust-anchor operations, scoped resource claims, transparent changes, independent monitors, local emergency controls and credible appeal can reduce concentration risk without inventing an unresolved multi-root contest.

Research into alternate authority models remains valuable. Any proposal should specify conflict resolution, transfer, emergency action, key compromise, legal compulsion and exit. Calling a design decentralised before answering those cases would repeat the same mistake made when validator count is treated as authority count.

Operators need a layer map before they buy redundancy

A resilient deployment can be evaluated across six layers. The first is bootstrap: TAL keys, their acquisition, package source and update authority. The second is issuance: trust-anchor and subordinate CA keys, approval and registration decisions. The third is publication: manifests, revocation lists, signed entities, RRDP, rsync and repository availability. The fourth is validation: codebases, libraries, caches, versions and exceptional-condition behaviour. The fifth is distribution to routers: RPKI-to-Router sessions, failover and staleness rules. The sixth is routing policy: how Valid, Invalid and NotFound states affect route selection.

Buying two validators changes mainly the fourth layer and perhaps the fifth. Running them in separate locations adds availability separation. Using independent repositories where the hierarchy permits improves the third. None automatically changes bootstrap or issuance. A common TAL update channel, one RIR CA and one registration decision can remain shared.

The inventory should identify common dependencies explicitly. Are both validators virtual machines on one host? Do they share DNS, power and network transit? Do they read one cache? Do router sessions fail over automatically? Do both packages receive the same bundled TAL update? Do they use the same cryptographic library? Which team can change local exceptions?

Testing should follow the map. Crash one implementation. Feed a malformed entity in a laboratory setting. Delay one repository view. Rotate a TAL in a controlled environment. Remove a payload legitimately and verify that stale-majority logic does not restore it. Exercise complete feed loss and recovery. Record which layer detected and contained each failure.

The result is a defensible resilience claim. The operator can say that no single validator process, host or maintenance event removes its validated feed, while acknowledging that regional certification authority remains common. Precise claims invite precise improvement; broad claims of decentralisation tend to end inquiry too early.

Independent comparison should explain divergence rather than score brands

A public comparison service can strengthen the ecosystem if it avoids turning validator outputs into a league table. Its task is to run maintained implementations against identified repository snapshots and live retrieval, preserve configuration, and report differences with enough evidence for developers and operators to reproduce them.

The useful unit is a validation event. Which trust anchors were active? Which entity or publication point produced disagreement? Did implementations fetch the same bytes? Did one use a cached prior state? Which RFC rule or local policy applied? What payload difference reached routers? Was the issue fixed, and in which version?

Aggregate counts can support maintenance, but they need denominators and severity. A parser rejection affecting one malformed test entity differs from a missing regional tree. A transport timeout differs from acceptance of a revoked certificate. The service should not infer global deployment share from its entities or describe one month's selected tests as every production condition.

Developers should have a right to respond with evidence. Operators should be warned when an implementation is no longer maintained, as the RIPE NCC did for its retired validator. Security-sensitive details may need coordinated disclosure before full publication. Independence means the comparison service cannot be funded or governed solely by one validator vendor or one issuing authority.

Such a service makes software diversity better. It can identify shared libraries, correlated failures and standards ambiguities. It also makes the authority boundary visible: when every implementation produces the same adverse result from one authenticated parent action, the report should direct attention to the issuer and review process rather than celebrate unanimity.

Number Resource Society can audit the boundary between code and authority

A future Number Resource Society can contribute by defining an assurance standard that names each layer and refuses to let one stand in for another. A provider claiming validator diversity would disclose codebases, versions, hosting separation, TAL acquisition, shared dependencies, comparison method, router-feed logic and exception policy. It would not be allowed to imply that these controls create independent certification roots.

For trust anchors and RIR CAs, NRS can define a different evidence set: current key identifiers, resource-claim scope, custody model, approval separation, rollover plan, exceptional change procedure, repository continuity, public notices, independent observations, appeal route and correction history. The entity is not to give NRS every private key. It is to make the exercise of upstream authority assessable.

NRS can also standardise change receipts. A receipt would bind the reason class, affected resource set, prior and new certificate identifiers, authorising body, effective time, publication evidence and review status. Validators or monitors can attach observations showing when the change became visible. Affected holders can challenge the registration basis through the designated forum while everyone agrees on what was signed.

This role is positive because it expands accountability without creating an untested super-root. NRS can accredit independent comparison providers, publish conformance cases and require corrective action after material findings. Membership representation can bring holders and operators into standards review. Funding and conflicts must be disclosed so that a major registry, vendor or network cannot convert assurance into endorsement.

The model remains prospective. Public NRS materials support distributed participation and bounded institutional power as aims; they do not establish that this trust-anchor assurance system is deployed or recognised by all regions. Credibility would depend on pilots, external audit, published exceptions and the willingness to criticise both software providers and issuing authorities.

Measurement must keep software prevalence separate from authority exposure

There is no complete public denominator for production validator deployments. Operators can run private instances, use vendor-integrated services, outsource validation or receive validated routes from upstreams. Download counts do not equal active networks. Public router observations do not reliably reveal which relying-party implementation produced a policy decision.

Reports should therefore resist claims such as one implementation serving a fixed share of the Internet unless the measurement supports that denominator. A survey can state how many responding networks use Routinator, rpki-client, FORT or another service. It cannot silently generalise to all autonomous systems. A test platform can state which versions it compared. It cannot infer that every deployed version behaves the same.

Authority exposure requires a different measure. A validator can list which trust anchor produced each payload, and an operator can report the share of its local validated set by configured anchor. That still does not measure governance quality or the probability of adverse action. Resource counts, route counts and traffic dependence are different denominators.

Operational metrics should be tied to failures: validation-cycle success by instance, repository freshness, output divergence, TAL changes, router-feed availability, stale duration, local exceptions and time to correction. Authority metrics should include exceptional certificate changes, rollover performance, audit findings, appeals and remediation. Joining the two into one diversity score would erase causality.

The most useful report may conclude that software resilience is strong while authority review remains weak. Another may find sound CA governance but dangerous validator monoculture. Layered measures let institutions fix the actual deficit. A single decentralisation badge rewards presentation rather than engineering.

The next architecture should diversify checks before it multiplies sovereign roots

There is a genuine constitutional question about whether the RPKI authority hierarchy should evolve. Regional trust anchors reflect the allocation structure and provide a coherent basis for validation, but their power becomes more consequential as Invalid routes are rejected more widely. Software diversity alone is not an answer. Neither is casually adding roots without a rule for disagreement.

Near-term reform can diversify checks around the current authority. Independent monitors can archive changes. Holders can receive signed notices. Exceptional actions can require divided approval. Appeals can be institutionally separate. Key ceremonies and rollover evidence can be published. Local emergency exceptions can be governed and time-limited. Cross-regional transfers can use common receipts. Validator implementations can remain independent and continuously compared.

Longer-term proposals might use constrained roots, cross-signing, threshold authority or other models. Each must explain how a legitimate resource transfer changes authority, how a compromised entity is removed, how conflicting certifications are resolved, how legal orders are scoped and how relying parties converge. Redundancy that cannot terminate obsolete authority can be more dangerous than hierarchy.

The design objective is not maximal root count. It is minimised unaccountable control with sufficient coherence for route-origin validation to remain useful. A system can have several roots and still concentrate power over each resource. It can have one path for a resource and still surround that path with strong procedural checks. Labels should follow the actual failure analysis.

NRS can host this debate constructively if it publishes assumptions, competing designs and test results rather than declaring institutional victory. RIRs, operators, holders, validator developers and routing vendors each possess part of the necessary evidence. No one group's software or certificate should define the constitutional answer alone.

The correct claim is narrower and stronger

An operator running multiple maintained validators is safer from a class of failures than an operator depending on one neglected instance. Independent code and operations can detect defects, preserve service during maintenance and expose ambiguous repository conditions. Those are material gains and should be measured.

The operator remains dependent on configured trust anchors and their certification hierarchies. For a given resource, several validators ordinarily verify authority derived from the same active root path. If the parent chain validly changes, correct validators follow it. If the root key is compromised, software variety does not restore trustworthy issuance. If the registry decision is contested, parser agreement does not supply due process.

The response is not cynicism about RPKI. Origin validation provides a useful cryptographic statement that BGP alone lacks. Its growing operational weight is exactly why the authority layer deserves explicit governance. Technical success should increase scrutiny of upstream power rather than conceal it.

The strongest deployment combines both kinds of control. Diverse relying-party software checks untrusted content independently. Trust-anchor and CA operations use protected keys, divided authority and safe rollover. Registration changes are reasoned and reviewable. Publication is resilient and observable. Router-feed policy handles stale and divergent states deliberately. Local exceptions remain bounded. External assurance reports each layer without substituting one for another.

Validator diversity can confirm that one trust hierarchy is being interpreted correctly. It cannot make that hierarchy plural. Institutional legitimacy begins when the system says so plainly and then builds the missing checks where authority actually resides.

Sources