Summary

  • Publication-as-a-service lets an operator retain control of its delegated RPKI certificate authority and private key while another organisation accepts and distributes its certificates, revocation lists, manifests and signed routing entities. It is neither fully hosted RPKI nor complete self-publication.
  • The service solves a real problem. Global repository availability, protocol maintenance, capacity planning and incident response are specialist duties that many otherwise capable certificate-authority operators should not have to duplicate.
  • Separation also creates a new handoff. A correctly signed entity can be rejected at the private publication interface, accepted but not integrated into the public repository, served through one transport but not another, or retrieved inconsistently by relying parties. One uptime percentage cannot describe these states.
  • Responsibility should be divided by control. The operator owns signing intent, key security, entity correctness and prompt reconciliation. The publication provider owns authenticated acceptance, atomic state changes, public availability, freshness, evidence preservation and recovery. The parent RIR owns accurate resource certification and practical cooperation when repository references or providers must change.
  • A useful service agreement needs stage-specific objectives, signed transaction evidence, external availability measurements, retention rules, security duties, incident classification, transition assistance and remedies tied to operational consequence rather than a token subscription credit.
  • Portability is the constitutional test of the arrangement. An operator should be able to move to another repository without surrendering its CA key, losing its history or enduring an avoidable gap, but migration still requires coordination with the parent certificate issuer and careful control of old and new publication states.
  • Number Resource Society can help compare terms, define a minimum evidence pack, organize portability exercises and represent operators in regional service discussions. It should not claim that a model clause or independent monitor can guarantee route outcomes.

The entity was signed, accepted and still absent

Consider a delegated certificate authority preparing a route change before a maintenance window. Its operator creates a new Route Origin Authorization, refreshes the manifest and sends the publication request to a repository service. The service returns success. Minutes later, engineers querying independent validators still see the previous authorization. The old origin remains Valid; the intended new origin remains Invalid. Which institution has failed?

There are several possible answers. The operator may have sent an internally inconsistent entity set. The publication server may have accepted the transaction but not incorporated it into the repository view. Its RPKI Repository Delta Protocol endpoint may be serving an old notification file. An rsync replica may be behind. A validator may have cached a prior state or failed to refresh. The parent certificate may contain a repository reference that no longer matches the intended service. Time may simply be shorter than any promised publication interval.

This is not semantic fussiness. Each explanation assigns a different duty and remedy. A protocol success response can settle one fact while leaving the operational result unresolved. A public entity can be cryptographically correct yet unavailable. A repository can be reachable while stale. A validator can retrieve a current snapshot and still apply local policy in a way the resource holder did not expect.

Publication-as-a-service makes these distinctions unavoidable. The delegated operator has kept the signing key, but it has outsourced the bridge from signature to public reliance. Resilience improves only if that bridge has named owners, measurable stages and evidence strong enough to resolve disagreement after the maintenance window has passed.

A new market emerged from sensible specialization

The case for separation is strong. Operating a delegated RPKI certificate authority already requires secure keys, certificate exchanges with the parent, timely manifests and revocation lists, correct signed entities, monitoring and staff who understand the consequences of an error. Running the public repository adds a different set of duties: globally reachable distribution, two retrieval protocols, capacity for many validators, resistance to denial of service, coherent snapshots and deltas, replication, observability and round-the-clock recovery.

There is no principle of Internet governance requiring every holder of a private signing key to become a global content-distribution operator. Concentrating repository expertise can reduce fragile single-server installations. A regional registry or specialist provider may sustain better network diversity, monitoring and support than a small network's secondary task could justify. The separation can also narrow a compromise's reach: the repository need not possess the CA's private signing key, while the CA host need not expose a high-volume public service.

The technical basis predates the recent service market. RFC 8181 specifies an authenticated publication protocol between a certificate authority and a publication server. RFC 8182 specifies RRDP for the public side consumed by relying parties. The operator that signs and the organisation that distributes can therefore be different.

Regional services turned this possibility into an accessible product. ARIN deployed an RFC 8181 repository service after community requests, APNIC supports publication for self-hosted clients, and the RIPE NCC moved from a 2022 beta to a production Publish in Parent service. The middleman did not appear because operators forgot sovereignty. It appeared because specialization can be safer than amateur duplication.

Hybrid RPKI is a distinct allocation of control

The familiar labels hosted and delegated conceal the new arrangement. In hosted RPKI, the regional registry commonly operates the holder's certificate authority, protects or generates its private key, translates portal choices into signed entities and publishes them. In fully self-operated delegated RPKI, the holder runs both the child CA and its repository. Publication-as-a-service sits between them.

Under this hybrid model, the holder runs the delegated CA and controls the corresponding private key. It decides which authorized origin, prefix and maximum length to sign within the certified resource set. A repository provider receives authenticated publish and withdraw requests, maintains the repository namespace and exposes the resulting material to validators. The parent RIR continues to issue the resource certificate and to certify the scope within which the child can act.

That distribution matters because control is not binary. The operator has cryptographic control over the entities it creates. The repository has operational control over whether those entities become and remain retrievable at the designated location. The RIR has hierarchical control over the resource certificate and, depending on the deployment, over changes needed to support a new repository relationship. Relying parties retain control over their software and route policy.

Calling the model delegated can lead an executive to believe that the operator is independent. Calling it hosted can imply that the RIR holds the key. Neither is accurate. “Delegated CA with managed publication” is less elegant but more informative. Governance begins by naming what each party can actually do, because contractual responsibility rarely becomes clearer after a failure than it was before one.

RFC 8181 settles transactions, not every consequence

The publication protocol provides useful precision. Requests and responses are carried in signed Cryptographic Message Syntax entities, allowing client and server to authenticate the exchange. A CA can publish a new entity, replace an existing entity when the expected hash matches, withdraw an entity, or ask the server to list what it believes the client has published. A query containing several changes is processed atomically: all succeed or none do.

These properties reduce ambiguity. The hash prevents a client from casually overwriting a repository entity when client and server disagree about its current content. Atomicity prevents part of a coordinated entity set from being committed after another part failed. The list operation supports recovery when the two systems lose synchronization. Error responses identify a failed request instead of leaving the client to infer rejection from the public repository.

But the protocol's boundary must be respected. A success response says that the publication server processed the request according to the exchange. It does not certify that every public replica immediately contains the new bytes. It does not prove that an RRDP snapshot and all relevant deltas are coherent, that rsync serves the same view, that remote validators can connect, or that the entity validates under its parent chain.

Nor does technical authentication necessarily answer who inside the operator approved the change. The client identity may belong to an automated CA. Its request can be perfectly authentic and substantively mistaken. Publication evidence is therefore necessary but bounded. The service contract should build on the protocol's precise claims rather than turn a successful response into a vague promise that “RPKI was updated.”

The private handoff and public repository are different services

The repository provider faces two constituencies. Its customer-facing service accepts instructions from certificate authorities. Its public-facing service distributes material to relying parties. Reliability at one interface does not imply reliability at the other.

On the private side, the provider must authenticate the client, authorize its namespace, check expected hashes, apply a request atomically, return a determinate result and offer reconciliation. Capacity here is driven by certificate authorities and entity changes. Latency is measured from receipt to committed repository state. Security concerns include credential compromise, cross-tenant writes and a malicious request targeting another publisher's URI.

On the public side, many validators fetch snapshots, deltas or files. Capacity is driven by global retrieval patterns, retries and outages elsewhere. The provider must expose a coherent current state, keep manifests and revocation material reachable, manage RRDP sessions and serials correctly, sustain rsync where offered, and avoid serving different realities from replicas without detection. Availability is measured from diverse networks, not from the provider's internal load balancer.

Between them lies integration. A transaction can be durably committed in the publication engine but not yet represented in the RRDP notification and snapshot. This interval may be tiny in a sound system, but it is the interval that matters during an urgent route change. It deserves its own objective and evidence.

A mature agreement therefore describes three services: instruction acceptance, repository-state construction and public distribution. Marketing can call them one product. Incident review cannot.

The repository is part of the evidence, not neutral storage

It is tempting to describe the provider as a storage company. That understates its function. RPKI publication is how a signed assertion becomes available to relying parties. Selection, freshness and consistency can matter as much as signature validity.

RFC 9286 requires a manifest to list files and hashes at a CA publication point. The manifest helps a relying party detect certain missing, added or altered material and assess freshness. A certificate revocation list indicates which certificates should no longer be trusted. RRDP snapshots and deltas let validators reconstruct repository state. These are not decorative files around a ROA; they are part of the verification context.

A repository cannot forge a valid ROA without the CA key. That is a major protection. Yet it can still fail to serve the latest valid entity, replay an older repository state, omit a file, present inconsistent views or remain unavailable long enough to change relying-party treatment. RFC 8211 analyzes adverse actions by certificate authorities and repositories for this reason.

This does not mean every omission is malicious, or that validators respond identically. Cache state, entity validity, manifest processing, fetch order and local implementation affect outcomes. It means the repository performs an evidentiary function: it presents the signed record on which others act. A service performing that function should preserve an account of what it accepted, what it served, when each state changed and which public views were exposed.

The parent RIR remains in the room

Separating the CA from publication does not separate the resource holder from its parent. The RIR issues the child resource certificate and defines its certified address and ASN scope from registration status. The certificate profile also connects the validation chain to repository locations and related material. A holder cannot use possession of its own key to certify resources the parent has removed.

This continuing role is legitimate. RPKI needs a hierarchy that tracks recognized number-resource registration. A former holder should not preserve routing authority indefinitely after a valid transfer merely because it controls a child key. The difficulty arises when an operator needs to change publication providers while remaining fully entitled to the same resource certificate.

Repository migration can require new setup material, changed references, fresh certificates or coordinated publication states. RFC 8183 helps exchange setup information, but it does not create a service deadline or compel the parent to approve a new relationship. Technical interoperability is not an enforceable exit right.

The RIR therefore has a continuity duty even when it is not the publication vendor. It should authenticate migration requests, make the required parent-side changes promptly, support a safe overlap or cutover design, and retain evidence of what it issued. If the RIR also supplies publication, it occupies two roles and should report them separately. Parent authority must not become a quiet mechanism that makes a nominally competitive repository market impossible to leave.

Specialization can diversify operational risk

A service provider may improve more than convenience. It can distribute public endpoints across networks and locations, maintain experienced on-call staff, test multiple validator implementations, fund denial-of-service protection and coordinate fixes with CA software developers. A pooled repository can justify engineering that each small publisher would postpone.

The model also permits risk separation. The CA private key remains under the operator's security regime. A compromise of the repository does not automatically grant signing authority. Conversely, a compromise of the CA host need not grant an attacker control over the public serving platform or other tenants. Provider-side namespace authorization can contain a faulty client that attempts to write outside its assigned branch.

Consolidation may improve observability. A provider serving many publication points can detect systemic RRDP faults, unusual entity churn or validator retry storms sooner than isolated operators. It can publish common incident reports and offer consistent evidence formats. Regional providers already have relationships with resource holders and may connect support across certification and repository issues.

These are plausible benefits, not universal facts. A large shared service also increases blast radius. Its telemetry may be broad but opaque. Its scale may make customers reluctant to leave. Resilience depends on the implementation, the number of independent providers, the ability to move and the honesty of service reporting. Outsourcing transfers duties; it does not make them disappear. A sound comparison asks whether the provider's controls are stronger than the operator's alternative and whether failure remains reversible.

Concentration creates a failure that signatures cannot cure

If many delegated CAs use one repository service, compromise or operational error at that service can affect a wide set of otherwise independent signers. Their private keys remain safe, but their entities may become stale, absent or inconsistently served together. Cryptographic decentralization at the CA layer can coexist with operational centralization at publication.

This is not an argument for counting repository hostnames and declaring monopoly. One provider may operate genuinely independent serving regions; many domains may rely on the same infrastructure. Conversely, one regional repository may be more robust than hundreds of nominally independent servers. Concentration analysis needs provider ownership, software, cloud, DNS, network, key management, control-plane and staff dependencies.

The middleman also gains informational power. It can observe when clients change routing authorizations, which changes fail, how urgently users retry and which validators fetch particular material. Much of this is operationally necessary. Retention and secondary use should nevertheless be stated. A publication contract should not quietly turn routing-security administration into an unrestricted behavioral dataset.

Most important, customers may lack a credible fallback. If the provider fails, the CA operator cannot simply place identical files at an arbitrary new URL and expect validators to discover them. Parent-issued references and repository structure matter. A concentrated provider with difficult exit can become more constitutionally important than its “storage” label suggests. Portability, not branding, determines whether specialization remains a service or becomes control.

Responsibility should follow the controlled act

Arguments after an incident often use the language of shared responsibility. The phrase is reasonable but can become an escape hatch when every party is responsible in general and none is responsible for the failed step. A better rule is to assign each controlled act and each required cooperation.

The operator controls signing intent, its CA key, local authorization, entity generation and the decision to submit. It should be accountable for a ROA that accurately reflects the request it approved but encodes the wrong origin. It should also monitor whether its submitted state became public rather than treating a success response as the end of the change.

The publication provider controls the customer namespace, transaction handling, committed repository state, public interfaces, replicas and evidence retained about them. It should be accountable for rejecting a conformant authorized request without stated grounds, acknowledging a transaction it did not commit, serving stale or split views beyond agreed bounds, or losing records required for recovery.

The parent RIR controls the resource certificate and parent-side cooperation. It should be accountable for an incorrect resource scope, an unjustified delay in changing repository arrangements or an exit design that unnecessarily destroys continuity. Where it is also the publication provider, internal departments should not blur these duties.

Relying parties control fetching and local validation. They cannot demand that a publisher compensate for a validator that ignored current material. Evidence must locate the fault. Shared responsibility should mean adjacent parties exchange enough proof to do so, not that responsibility dissolves at every boundary.

The CA operator retains demanding duties

Managed publication is not managed RPKI. The operator still runs the certificate authority. It must protect its private key, keep parent exchanges current, issue entities within certified scope, refresh manifests and revocation lists, maintain backups, control administrator access and understand how changes affect routes.

It should maintain a canonical intended-state record independent of the provider. For every publication transaction, that record should include the entities expected after the change, their hashes, the initiating service identity, the approving human or rule, the business reason, the relevant route change and the provider's response. The operator should be able to reconstruct its desired repository without asking the provider what it once intended.

Reconciliation is also an operator duty. RFC 8181's list operation exists because client and server can disagree. The CA should compare the provider's committed inventory with local state and compare public repository observations with both. Monitoring from the same host or network as the provider is limited public evidence. At least one view should approximate what remote relying parties can retrieve.

The operator needs a response plan for each failure class. A rejected request calls for correction or escalation. A success response followed by absent public state calls for provider evidence. A parent certificate problem calls for the RIR. A stale local manifest calls for CA intervention. The plan should name who can freeze changes, issue emergency entities, contact the parent and invoke migration.

Outsourcing is responsible when the customer remains capable of detecting failure and exercising exit. Otherwise convenience becomes dependency without supervision.

The provider's duty begins before availability

Repository providers often emphasize uptime because it is easy to place on a status page. Their first duty is narrower and earlier: accept only authenticated, authorized instructions and apply them exactly once to the correct namespace.

Tenant separation is fundamental. A client must not publish at another CA's URI. Replacement and withdrawal must check the expected old hash. Multi-entity changes must preserve atomicity. Duplicate requests, retries and ambiguous network failures need determinate handling. An operator should be able to ask whether a transaction committed without risking a second inconsistent application.

The next duty is faithful integration. The bytes accepted should be the bytes represented in the provider's authoritative repository state. The provider should not silently transform signed entities. It should generate public repository metadata consistently, expose new state within the promised interval and make the same current view available across supported retrieval methods subject to protocol semantics.

Then comes availability: diverse validators should be able to retrieve complete, fresh material. The provider needs capacity, replication, DNS resilience, network diversity, monitoring and tested restoration. Recovery must protect consistency; restoring an old snapshot without detecting subsequent accepted transactions can be worse than a visible outage.

Finally comes evidence. The provider should preserve signed requests and responses, commit identifiers, state hashes, integration times, RRDP sessions and serials, replica health, administrative actions and incident decisions. A provider that restores service but cannot explain the state it served has repaired availability while leaving accountability broken.

The RIR's duty is continuity of certification

The parent RIR may argue that the delegated operator selected its repository and therefore owns the consequences. Choice does matter. It does not eliminate the RIR's unique ability to issue a certificate that recognizes the child's resources and publication arrangement.

At enrollment, the RIR should make the available models intelligible. The resource holder needs to know which keys it controls, which party publishes, what parent references are used, how to change providers, what support is available and which termination events can affect the certificate. A checkbox labeled delegated is not informed choice if publication dependence remains hidden.

During operation, the RIR should expose parent-side events promptly. A certificate issuance, resource-set change, revocation or setup modification should have a stable identifier and time. The child must be able to distinguish provider trouble from a parent action. Support teams should have an escalation route for time-sensitive routing changes rather than treating repository migration as ordinary account administration.

At exit, the RIR should process a valid repository change under a published timetable. It should support a technically sound continuity method, verify that the new publication point is reachable and preserve the old and new certificate history. Emergency security action may require immediate revocation, but ordinary commercial or service disputes should not force the most destructive transition.

The RIR is not an insurer for every third party. It is the indispensable coordinator at the point where repository choice meets hierarchical authority. Its obligation is practical neutrality and timely cooperation.

One uptime percentage hides five clocks

A serious service commitment should measure at least five intervals. The first is request availability: can an authorized client reach the publication endpoint and receive a valid response? The second is decision latency: how long does the service take to accept or reject a conformant request? The third is integration latency: after success, when does the committed entity set enter the authoritative public repository state?

The fourth is distribution freshness: when do RRDP and rsync, where supported, expose coherent material from diverse locations? The fifth is recovery time: after a fault, how quickly does the provider restore a state that includes every valid accepted transaction or identifies those requiring replay?

These clocks have different denominators. A monthly endpoint-uptime figure may exclude failed authentication, maintenance, slow integration and stale replicas. A median publication time can conceal a long tail precisely when urgent changes occur. A repository can answer every probe with HTTP success while its notification file remains old. Availability without semantic freshness is a green light on an empty road.

The agreement should define the starting and stopping event for each measure, the observation points, exclusions and reporting period. It should publish percentiles and maximum breaches, not only averages. Planned maintenance should still disclose publication consequences. Security suspensions may be valid, but they should be counted and classified rather than removed from history.

Operators need their own measurements too. A provider's result is one view. Independent probes should test retrieval from multiple networks and validator implementations. When the two disagree, the evidence procedure must decide what is authoritative for service review without assuming that the vendor's dashboard wins.

A receipt must say which promise it proves

Signed transaction evidence is the foundation of a fair allocation. For each request, the operator should retain the signed CMS message, entity hashes, server response, transaction identifier and local send and receive times. The provider should retain the same exchange plus its authenticated client identity, authorization decision and commit record.

A second receipt should establish repository integration. It can identify the committed state root or inventory digest, the RRDP session and serial first containing the change, the snapshot hash, the integration time and any relevant rsync state. This is not mandated by RFC 8181, but it converts an internal event into reviewable evidence.

A third layer should show external availability. Independent monitors can record notification, snapshot, delta and file retrieval from diverse networks, with cryptographic hashes and signed observation times. They should preserve failures as well as successes. A provider-selected monitor alone does not create independence; governance of monitor selection, keys and retention matters.

Each receipt proves a bounded proposition. A request receipt proves what was sent. A success response proves protocol processing at the server. An integration receipt proves what the provider committed. An external observation proves what one observer could retrieve at a time. None alone proves global route treatment.

This modesty strengthens evidence. Incident reports become a sequence of testable statements rather than a contest between screenshots. The party controlling each stage produces the record for that stage. Gaps are visible, and no receipt is promoted into proof of a consequence it cannot establish.

Incident classes should not be mixed for convenience

A publication service needs a public incident vocabulary. At minimum it should distinguish authentication failure, authorization error, malformed request, hash conflict, transaction-processing failure, integration delay, incomplete repository state, stale metadata, RRDP failure, rsync failure, replica inconsistency, parent-certificate mismatch, denial of service, administrative suspension and evidence loss.

The distinction protects both customer and provider. If an operator sends an invalid entity, the provider should not record a repository outage. If the service accepts a valid transaction but delays public integration, it should not blame client authentication. If one transport fails while another remains current, the report should state partial degradation rather than either total failure or full availability.

Severity should reflect time and consequence but avoid pretending that the provider knows every route outcome. A useful report can state how many customer namespaces experienced a stale public state, for how long, which repository views were affected and what entity categories were involved. It should separately state what route observations or customer reports are known. Unknown effects remain unknown.

Root-cause language should separate trigger, control weakness and consequence. A software defect may trigger a bad snapshot; limited public evidence release validation may permit it; monitoring blind spots may extend it. “Human error” is rarely a complete cause. “External network issue” is equally weak if architectural concentration made that network indispensable.

Consistent classification creates comparable evidence over time. Without it, each provider can rename the same failure until reliability cannot be evaluated.

Portability is more than downloading entities

RPKI objects are signed files, so it may appear that a customer can leave by copying them. The repository relationship is not that simple. Public locations are referenced through the certification structure. Repository namespaces, setup credentials, RRDP state and provider-specific evidence must be re-established. The parent may need to issue changed material. Validators must discover and retrieve the new location through a valid chain.

Portability therefore has five parts. Configuration portability lets the operator export entity intent, publication inventory, URIs and relevant setup data in documented formats. Evidence portability supplies requests, responses, hashes, integration history and incidents. Identity portability permits the CA to establish a new authenticated publication relationship without recreating the organization from nothing.

Operational portability coordinates old and new serving states so that validators do not face an avoidable gap or conflicting authoritative views. Contractual portability obliges the old provider and parent to cooperate within defined periods even when the customer is leaving after a dispute.

The private key should not need to leave the operator's control. Keeping the key is one advantage of the hybrid model. But key possession alone does not deliver a migration. The provider and parent hold other necessary controls.

Fees can cover reasonable transition work, but punitive exit charges undermine the market's legitimacy. A provider should not erase logs at termination or make evidence retrieval conditional on waiving claims. The departure period is when records matter most. A service is portable only when exit preserves both operational continuity and the ability to prove what happened before it.

Make-before-break must be designed, not assumed

An ideal migration allows the new repository to become valid and observable before the old one is withdrawn. In practice, certification references and validator behavior make overlap a technical question, not a slogan. Two publication points cannot simply assert competing current states without clear authority.

The parent RIR, old provider, new provider and CA operator should publish a tested migration procedure. It should define the freeze point for ordinary changes, the inventory and hashes to be transferred, new setup authentication, certificate issuance, the validation criteria for the new repository, the old repository's retention period and the final withdrawal event. Emergency changes during the cutover need an explicit path.

Testing should include validators that begin before, during and after migration; clients using RRDP and rsync where applicable; loss of one provider; replay of an old request; rollback after the new service fails validation; and recovery when the parent-side action is delayed. The test should record elapsed times and observed states, not merely declare success.

There may be designs where a brief break cannot safely be avoided. If so, the service should disclose that limitation before enrollment and estimate the relevant entity-validity headroom. Operators with critical routing changes can schedule accordingly or choose another model. Hidden break-before-make is a governance defect because it converts a technical constraint into an uninformed dependency.

Portability exercises should occur before a provider is in crisis. An exit plan first read during an outage is documentation, not preparedness.

Contract terms should follow control and consequence

Publication agreements often contain broad exclusions because routing decisions occur outside the provider's network. That boundary is real. A repository does not control every validator, router or operator policy. It should not guarantee worldwide reachability. Yet this does not justify disclaiming the steps it does control.

The contract should warrant authenticated processing, namespace isolation, faithful publication, defined freshness, evidence retention, security practice, incident notice and transition assistance. It should state customer duties with equal precision: correct CA operation, current contacts, secure credentials, timely renewal, monitoring and cooperation in recovery.

Liability should distinguish direct service failure from remote routing consequence. A provider can accept responsibility for re-performance, forensic support, emergency migration costs or independently verified losses within negotiated limits without promising to compensate every downstream packet loss. Gross negligence, intentional suppression, confidentiality breach and destruction of required evidence deserve different treatment from an ordinary short degradation.

The customer also needs procedural rights. A suspension should have grounds, notice where safe, a rapid review path and a route to export evidence. A disputed invoice should not silently become a routing-security intervention. The provider may need emergency authority to contain compromise, but the authority should expire or receive independent review.

Standard terms will vary by region and jurisdiction. The important institutional rule is symmetry: control should bring a corresponding duty, and a duty should have a remedy more meaningful than a status-page apology.

Service credits are not enough

A credit calculated from a small monthly fee may be commercially conventional and operationally irrelevant. The operator's main loss after publication failure may be staff time, delayed network migration, emergency transit changes, customer explanation or the cost of moving repositories. A discount on the next month does not restore the missed authorization or establish what validators saw.

Remedies should be layered. The first is performance: immediate correction, confirmed repository integration and external validation. The second is evidence: a complete incident pack under a fixed timetable, including transaction and state records. The third is continuity: temporary expert support, parent coordination and accelerated migration if confidence is lost.

Financial remedies can follow severity and repeated breach, with caps appropriate to the service. They need not turn the provider into a route insurer. Termination rights should activate after defined failures, evidence destruction or chronic objective breaches. A customer leaving for cause should receive cooperation and its records without an exit penalty.

Collective remedies matter where many small CAs cannot negotiate alone. A member association can aggregate incident patterns, request service changes and compare providers. An independent reviewer can examine protected logs and publish bounded findings when public disclosure would expose security details.

The strongest remedy is prevention through credible exit. A provider that knows customers can migrate under tested rules has an incentive to preserve trust. A customer that knows it can exit is less likely to demand impossible guarantees. Portability turns accountability from rhetoric into bargaining structure.

Emergency suspension needs a narrow constitution

A repository provider must be able to stop harmful activity. A compromised publication credential could attempt mass withdrawals or replacements. A tenant bug could flood the service. A court order or sanctions obligation may constrain service. Refusing every emergency power would make the repository fragile in a different way.

The power should be defined by threat and scope. The provider may block a credential, freeze a namespace or reject a transaction necessary to contain a credible risk. It should avoid removing already published valid material unless the risk requires it and the relevant authority permits it. Freezing new changes and withdrawing existing evidence are not equivalent actions.

Where advance notice would worsen the threat, notice can follow promptly. The customer should receive the reason category, affected namespace, start time, decision authority, evidence-preservation status and review route. Sensitive detection details can remain protected. The action should expire unless renewed by an authorized reviewer.

If the provider is also the RIR, certification and publication powers should not be casually combined. A repository suspension need not imply resource-certificate revocation. If both occur, each decision needs its own authority and record. Otherwise one commercial or security dispute can cascade through every layer of RPKI control.

An emergency constitution is a sign of seriousness, not distrust. It tells operators which risks can interrupt service and tells provider staff which actions require higher approval. The worst time to discover the boundary is after an administrator has already crossed it.

Independence requires more than a different company name

A market of several publication providers can still share the same cloud region, DNS operator, software release, monitoring vendor or trust arrangement. Procurement should examine common dependencies. Provider diversity is useful when failures are genuinely less correlated.

An operator choosing a service should ask where the publication engine and public replicas run, how control-plane access is separated, which networks and DNS dependencies are used, how software changes are staged, whether RRDP and rsync fail independently, and where evidence is retained. It should ask whether another provider can consume the export and whether the parent RIR has completed a migration exercise with that provider.

Multi-provider publication sounds attractive but requires protocol and authority clarity. Serving the same authoritative state through redundant infrastructure can improve availability if consistency is guaranteed. Allowing two independent providers to accept changes concurrently can create split-brain risk. Redundancy should not multiply writers without a conflict rule.

Open-source software helps inspection and interoperability but does not reveal operating quality. A provider can run sound code with weak access control or poor recovery. A proprietary layer can be well controlled but difficult to leave. Assurance should cover deployed systems, people and dependencies rather than treating software license as a proxy.

Independence is the ability to withstand or leave a failure, not merely the absence of a shared logo. A resilience claim should identify the correlated event it is designed to survive.

Security review should test the control plane

Public repository scanning is useful but incomplete. The most consequential service defects may occur before an entity appears publicly: weak client authentication, cross-tenant authorization, unsafe administrator access, ambiguous retries, unreviewed emergency actions or a release that commits transactions incorrectly.

An independent assessment should trace a representative change from authenticated request through authorization, atomic commit, repository construction, RRDP and rsync serving, monitoring, backup and restoration. It should test whether staff can alter a customer's state outside the ordinary interface and whether such action is separately approved and recorded. It should examine evidence keys and log protection as carefully as repository keys.

Restoration deserves destructive testing in a controlled environment. The provider should recover from a backup, replay accepted transactions after the backup point, reconstruct RRDP state or begin a valid new session, and show that no tenant receives another's entities. A backup that restores availability while losing acknowledged changes fails the core promise.

The assessment result can be public without exposing exploit details. It should identify scope, period, assessor independence, material exceptions and remediation. A generic security badge is less useful than a statement that publication transaction integrity, repository consistency and evidence preservation were tested.

Customers also need the right to report defects and receive tracking identifiers. Responsible disclosure should not be treated as contract breach. A middleman entrusted with public routing evidence earns legitimacy by making its own control surface open to disciplined challenge.

Privacy belongs in the service design

The public RPKI repository is intentionally public, but the service produces non-public metadata. Client IP addresses, administrator identities, failed authentication, draft changes, retry patterns, support messages and incident evidence can reveal network plans or internal roles. Retaining everything forever would increase breach and surveillance risk.

The provider should separate content needed for public validation from operational and security records. Public signed entities follow RPKI publication rules. Customer transaction evidence should be available to the customer and retained for a defined period. Security telemetry should have narrower access and purpose. Staff notes should not become an ungoverned parallel record.

Evidence design can minimize exposure. Hashes and signed state commitments can support later integrity checks without publishing the underlying customer event. Independent monitors need repository observations, not client identities. An auditor can inspect protected transaction records and report whether the public commitment matches without releasing every action.

Deletion rules should account for disputes and legal holds. Routine telemetry can expire; evidence tied to a known incident should be preserved. Termination should not trigger immediate deletion of records needed to resolve the termination itself. Customers should know the schedule and how to request preservation.

Privacy and accountability are not opposing absolutes. The answer is to retain the right evidence, bind it cryptographically, restrict access, record disclosure and publish aggregate performance. Indiscriminate transparency can be as irresponsible as unverifiable secrecy.

Regional services show a model, not one global bargain

ARIN's deployment options distinguish hosted, delegated and Repository Publication Service arrangements. The repository service lets a delegated entity retain its CA while ARIN maintains the public repository. The service emerged after documented community requests and deployment work. This shows that an RIR can unbundle signing from publication while using its existing infrastructure.

The RIPE NCC's 2022 beta notice described users running their own CAs and keeping sole control of private keys while the registry ran the repository. Its current Publish in Parent terms formalize a regional service based on RFC 8181. APNIC's certification practice statement likewise describes publication for self-hosted clients.

The similarities are enough to establish the hybrid model. They are not enough to claim identical eligibility, service levels, remedies, migration support or liability. A page that says high availability is not a comparable service report. A certification practice statement is not a complete incident record. Terms can change.

Operators should therefore resist both regional exceptionalism and careless global scoring. Comparison needs a common set of questions and current documents. Each provider should answer in its own legal and technical context. The objective is not to declare one RIR universally superior; it is to make the bargain visible enough that customers and boards can improve it.

Procurement should buy evidence and exit

A procurement form that asks only about uptime, price and compliance will miss the constitutional features of publication. The buyer should first map the service stages and confirm which party controls each. It should request sample transaction, integration and incident evidence before signing.

Technical due diligence should cover RFC 8181 conformance, namespace isolation, reconciliation, RRDP behavior, rsync behavior where offered, repository consistency, capacity, dependency diversity, monitoring, recovery and security testing. Operational due diligence should cover support hours, urgent escalation, staff access, change management, incident reporting and previous material failures with appropriate confidentiality.

Contract review should test suspension, termination, evidence retention, subcontractors, data use, external assessment, parent coordination and remedies. The buyer should obtain the migration procedure and run at least a tabletop exercise. A promise that staff will “help” is not a transition objective.

The operator should also assess itself. Does it have personnel to run the CA, maintain fresh entities, reconcile state and interpret evidence? A managed repository does not make a neglected delegated CA safe. For some organisations, hosted RPKI remains the more responsible choice because it places both signing and publication with a capable provider. Hybrid is valuable when the holder can discharge the control it retains.

The purchasing decision should be revisited after incidents and material service changes. Publication is an operating relationship, not a one-time software acquisition. The right product is the one whose responsibility map matches the operator's capability and whose exit remains credible.

Number Resource Society can make the market legible

Number Resource Society can contribute without operating a repository or claiming supervisory power. Its first useful product would be a publication-service comparison built around controlled facts: eligibility, CA key custody, provider ownership, public transports, service objectives, evidence fields, retention, suspension, parent coordination, migration steps, charges and remedies. Providers should be able to correct factual errors, while missing answers remain visible.

Second, NRS can publish a minimum evidence specification. It can define the request receipt, integration receipt, external observation and incident chronology an operator should receive. The specification should state each proof's limit so members do not mistake repository evidence for a guarantee of route acceptance.

Third, it can convene portability exercises with willing RIRs, software operators and members. Results can report steps, elapsed time, validator observations and unresolved dependencies without exposing private keys or customer data. Repetition would show whether portability improves.

Fourth, NRS can aggregate member experience. One small operator may not persuade a provider to change terms after a failure. A documented pattern of ambiguous success responses, missing evidence or slow parent coordination deserves board-level attention. Aggregate reporting should use known local denominators and avoid converting anecdotes into global failure rates.

These activities fit a member-accountability role. NRS should disclose that its charter and FAQ are first-party statements, identify conflicts and avoid certifying reliability it cannot independently verify. Legibility is a meaningful contribution precisely because it is narrower than control.

Boards should govern the handoff, not only the repository

An RIR board reviewing publication service may focus on infrastructure uptime and adoption. It should also ask whether the institution has governed the handoff between customers, repository staff and certification staff. The most damaging ambiguity often sits between successful systems.

The board should receive separate indicators for accepted transactions, integration delay, public freshness, incidents, evidence requests, disputed actions and migrations. It should know how many customers could leave under the current procedure, how long a tested move took and which parent-side approvals were required. Reports should distinguish regional service performance from customer-operated CA failures.

Risk oversight should include concentration and subcontractors. A highly available service can remain dependent on one cloud control plane, DNS provider, software maintainer or small staff group. The board should see the provider's failure exercises and the status of material exceptions from independent assessment.

Policy oversight should examine emergency suspension and termination. Staff need authority to contain threats, but high-impact actions should have recorded approval and rapid review. Where publication and parent certification sit inside one RIR, governance should prevent an issue in one role from automatically triggering the other.

Member consultation belongs before terms harden. Publication-as-a-service changes the practical allocation of routing-security control. It is not merely a technical feature release. A board that governs the operating chain can keep specialization useful without letting convenience hide institutional power.

The resilience bargain is reversible specialization

Publication-as-a-service should not be judged by whether it inserts a middleman. Internet operations depend on intermediaries. The relevant question is whether the intermediary makes expertise available without becoming an unreviewable point of control.

The model passes that test when the operator retains meaningful signing custody and monitors its intended state; the provider makes authenticated changes faithfully and distributes them under measurable objectives; the parent RIR supports accurate certification and prompt transition; and relying parties can retrieve coherent evidence. It fails when a success response cannot be connected to public state, an outage cannot be reconstructed, or a customer with valid resources cannot leave without avoidable loss of continuity.

No contract can guarantee that every router will accept every route. No repository design can eliminate operator mistakes, parent disputes or validator faults. The achievable standard is more disciplined: each party proves the step it controls, incidents preserve a shared chronology, remedies correspond to bounded duties and portability is tested before trust collapses.

That standard does not weaken the case for managed publication. It makes the case durable. Specialist repositories can be an important resilience layer, especially for delegated CAs that should not duplicate global distribution. But specialization is legitimate only while it remains reversible. The new middleman earns its place not by promising that nothing will fail, but by making failure visible, recoverable and possible to leave.

Sources