Summary

  • In delegated RPKI, a resource holder operates a child certification authority and controls its private key. The parent RIR still certifies the holder's resource scope and can replace or revoke the child certificate under applicable rules. Key custody is separation of duties, not independence from the allocation hierarchy.
  • The standards divide the system into manageable relationships. RFC 6492 supports parent-child provisioning; RFC 8181 supports publication by a service distinct from the signing CA; certificate and key-rollover standards support continuity. Interoperability is essential because autonomy tied to one proprietary client is fragile.
  • A formal service option is not necessarily a usable right. Eligibility, contracts, account authority, software conformance, publication access, test facilities, support, cost and documentation all determine whether an operator can exercise delegation in practice.
  • Migration is the decisive test. Current regional arrangements differ: some documented transitions permit hosted and self-operated service to overlap, while another requires revoking the hosted CA before creating a delegated one. A choice that can be exercised only through avoidable interruption is a weak choice.
  • Holding the key brings duties. The delegated operator must secure signing material, issue current manifests and revocation lists, maintain publication, monitor external validation, preserve succession access and respond to compromise. Delegation should not transfer responsibility without providing usable tools and support.
  • Hybrid publication can separate key custody from repository availability. It often gives operators meaningful signing control without requiring each one to expose a global repository, but it preserves dependence on the parent or publication provider and therefore needs clear service and exit terms.
  • No-penalty choice means more than equal price. Delegated users should retain equivalent eligibility, information, incident access, review, migration assistance and membership standing. Providers may charge transparent cost-based fees or enforce neutral safety rules, but should not make self-custody an inferior institutional status.
  • Number Resource Society can help with a rights-and-duties matrix, conformance exercises, migration rehearsals and evidence-led member advocacy. It should not market private-key possession as ownership of the resource or immunity from legitimate parent action.

The ceremony proves who holds the key, not who holds all authority

A network security team installs certification-authority software on infrastructure it controls. The software generates a key pair locally. The private key does not leave the organisation. The team exports a child request, submits it to its Regional Internet Registry, receives a parent response and completes the relationship. The child CA requests a resource certificate, creates Route Origin Authorizations and publishes signed entities.

This is delegated RPKI in its most legible form. The operator, rather than the RIR's hosted service, decides when its child key signs. A parent cannot simply use that private key to create an entity bearing the child's signature. The operator can apply its own hardware controls, approval rules, audit records, automation and succession arrangements.

Yet the certificate derives its force from the parent. The RIR certifies which number resources fall within the child certificate. If a resource is transferred, returned or removed after a justified process, the parent can issue a narrower certificate or revoke the child certificate. Relying parties accept the operator's ROAs because a valid chain reaches them from an accepted regional trust anchor, not because private-key possession creates freestanding authority.

The difference is easy to lose in political language. Advocates may call delegated RPKI sovereignty. Hosted providers may imply that local key custody changes little because the parent still controls scope. Both positions flatten a real separation of duties.

Key custody matters because it prevents the hosted provider from being the only party able to express the holder's routing intent. It lets the operator integrate authorizations with its own network controls and preserve an independent record of what it signed. It can reduce dependence on a regional web interface during an urgent routing change. It can support child delegations and unified management under several parent relationships.

Parent authority matters because RPKI is a resource certificate hierarchy. A former holder cannot keep authorizing a transferred prefix merely by retaining an old private key. A compromised or persistently broken child cannot demand indefinite certification regardless of consequence. Delegation needs rules for issuance, scope change, revocation and recovery.

The institutional question is therefore not "Who has the key?" in isolation. It is whether the holder can choose and exercise its signing role on reliable, interoperable and fair terms while the parent exercises its narrower authority through declared procedure. A usable right exists in that relationship, not inside the key file alone.

Hosted convenience and delegated control answer different needs

Hosted RPKI made route authorization accessible. The member authenticates to an RIR service, enters a prefix and origin AS, and the provider handles key generation, entity signing, renewal, manifests, certificate revocation lists and repository publication. For many small networks, this is the difference between deploying RPKI and not deploying it.

Delegated operation shifts important duties to the holder. The operator runs a child CA, protects its key, communicates with the parent, creates signed entities and either runs or selects a publication service. It must keep manifests and revocation information current and recover from software or infrastructure failure.

Neither model is inherently virtuous. A small municipal network with two stable routes may reasonably prefer a well-run hosted service. A large multi-RIR carrier with automated routing changes, downstream customers and mature key management may reasonably require delegation. A university or public-service consortium may choose local keys but parent publication as a balance between institutional custody and repository resilience.

Choice becomes politically significant because the provider of hosted convenience is also the parent authority. This is not a competitive market in which a dissatisfied customer can move the certification of a regional resource to any unrelated vendor. Third parties can provide CA software or managed operation, but the certificate path still has to connect to the appropriate parent.

The existence of hosted service should therefore strengthen, not eliminate, the delegated option. A low-friction default serves broad adoption. A practical delegated exit disciplines concentration and serves operators with different risk. The models complement each other when movement is possible and responsibilities are clear.

Problems arise when convenience becomes the only realistically supported path. Delegation may appear on a service page yet require obscure manual exchanges, unsupported software, an unannounced interruption, specialist contacts and contractual uncertainty. The formal choice survives, but only operators with exceptional relationships can use it safely.

The reverse problem also exists. Treating self-operation as the only respectable model can transfer complex security duties to organisations unable to perform them. A key held under weak access controls and an expiring repository is not autonomy in any useful sense. It can degrade routing evidence for the holder and increase validation work for others.

The legitimate objective is informed, no-penalty choice. Hosted users should know what the provider controls. Delegated users should know what they control and what remains with the parent. Each should have a safe route to change models as its capacity and risk evolve.

Open protocols turn a promise into an interoperable option

Delegation would be fragile if every RIR required a proprietary child. The IETF standards supply a common operating grammar.

RFC 6492 defines a provisioning protocol between a parent and child CA. The child can list its entitlement, request certificates and request revocation through authenticated exchanges. The parent responds within a defined protocol rather than forcing every implementation to reproduce a regional web session. The standard does not decide why the parent assigns a resource or when a contractual dispute justifies action. It makes the certificate relationship interoperable once authority has been established.

RFC 8181 separates publication from signing. A delegated CA can send signed material to a repository server through an authenticated publication protocol. This permits a hybrid arrangement: the operator holds the signing key while the RIR or another provider operates the globally available repository. Separating the roles reduces the false choice between surrendering the key and running every public service alone.

Other RPKI standards define certificate profiles, manifests, revocation lists and rollover procedures. They give independent software projects a stable target. An operator can evaluate maintained CA implementations rather than install a binary available only from its parent.

Standards do not guarantee usability. Two products can claim support while differing on profiles, timing, identity exchange, child handling or failure recovery. A regional parent can conform to the core exchange yet leave onboarding dependent on a manual ticket. A publication server can accept standard messages while offering no clear capacity or incident terms.

Usable autonomy therefore requires conformance evidence. RIRs should publish supported protocol versions, profiles, algorithms, endpoint behavior, size limits, update expectations and deprecation schedules. They should test against more than one maintained child implementation where the ecosystem permits and publish reproducible results. Software projects should test against more than one parent.

Change must be paced. A parent should announce protocol or profile deprecation with enough time for delegated operators to upgrade and rehearse. Emergency security changes may require faster action, but they should include a compatibility plan, direct notice and after-action review. The operator should not discover at certificate renewal that its previously conforming child is no longer accepted.

Open standards also protect institutional memory. Staff change, vendors disappear and community software can be retired. If requests, responses and entities use documented formats, a successor team can reconstruct the relationship and migrate tools. Autonomy is less dependent on one administrator's private notes.

The right to hold a key is therefore inseparable from the right to use a standards-conforming child. Without interoperability, private custody can become a proprietary enclosure with a different lock.

Availability on a webpage is not equal availability

Regional service descriptions show that delegated RPKI exists, but access conditions vary. ARIN describes hosted and delegated deployment and a repository publication option. The RIPE NCC permits delegated CAs for eligible members and certain end users and documents both self-publication and publication service. APNIC has long supported self-operated children and parent publication. LACNIC states that delegated service has been available to members since December 2019 and asks interested organisations to contact its hostmaster.

These are meaningful commitments. They establish that self-custody is not merely theoretical in several regions. They do not prove that every holder in every contractual category can obtain it on equivalent terms.

Eligibility is the first test. Direct members may have a clear path while sponsored, provider-independent, legacy or national-registry users depend on another institution. In the RIPE service region, documentation for provider-independent and legacy end users ties direct or sponsored access to particular contractual and account-maintainer relationships. In the APNIC region, national registries can form additional parent layers. The correct authority path follows the actual resource and agreement.

The second test is discoverability. A service requiring an email can still work well, but the user needs published eligibility, expected response, technical prerequisites, terms and escalation. An unexplained manual gate makes it difficult to know whether refusal reflects policy, capacity or misunderstanding.

The third test is parity. Can the delegated user obtain certificates for the same eligible resources as a hosted user? Does it receive the same notification of resource changes? Can it use parent publication? Is there a test service? Are incidents handled by the same operational team? Does the member portal show enough state to diagnose a failed exchange?

The fourth test is practical cost. The operator appropriately bears local CA security and staffing. Additional provider fees may be defensible where they reflect a distinct service, especially managed publication or support. But costs should be published, predictable and connected to service. An opaque premium imposed merely because a member declines hosted key custody would weaken the claim of equal choice.

No current public denominator shows how many eligible holders requested delegation, were accepted, abandoned setup, failed migration or returned to hosted service across all regions. Availability should therefore be assessed from published rights and reproducible user journeys, not an invented global adoption rate.

A service option becomes equal when an ordinary eligible operator can discover it, understand it, complete it with conforming tools and receive a reasoned answer if blocked. Anything less may still be useful, but it is not yet a robust right.

Migration is where nominal choice meets operational consequence

An operator already using hosted RPKI cannot prove its freedom merely by pointing to a delegated signup page. It must be able to move its routing authorizations from the hosted key to a local child without an avoidable period in which intended routes lose valid authorization.

Migration has several states. The operator inventories current ROAs and intended routes. It establishes the local CA and secures its key. Parent and child exchange identities. A publication relationship is configured. The parent issues a certificate. The child publishes replacement entities. Independent validators observe them. The hosted entities are retired. Monitoring confirms the expected result.

The ordering is difficult because two CAs may claim overlapping resource scope during transition. RPKI certificate policy must prevent unauthorized duplication, and parent systems may be designed to support only one member CA mode at a time. Yet a strict break-before-make sequence can create a gap. Revoking the hosted CA before the delegated child can publish means relying parties may temporarily see no authorization or inconsistent states as caches refresh.

Current documentation demonstrates regional difference. The RIPE NCC delegated setup page tells an existing hosted user to revoke the hosted CA before adding a delegated one and recommends using the test environment first. APNIC has described helpdesk-assisted parallel hosted and self-operated service as a transitional process. ARIN tells users changing deployment options to work with Registration Services. These are not equivalent experiences.

Parallel operation is not automatically safe. The parent must ensure that overlap is intentional, short, monitored and unable to preserve authority after a transfer. Replacement ROAs should reflect the same verified routing intent. A make-before-break facility should be a controlled migration state, not a permanent duplicate entitlement.

Where parallel certification cannot be offered, the provider should minimize the gap through pre-validation. It can verify the child's identity, keys, software exchange and publication relationship before revoking the hosted CA. It can stage approved routing-intent data and schedule the cutover with operational staff present. It can define an emergency return to hosted service if the child fails.

The migration record should state expected validity transitions and actual observation. "The new CA was created" is not completion. Completion means current signed entities validate through the new path, intended routes have the expected status, old authority has been safely retired and the holder possesses a durable record.

Migration support is not a courtesy extra. It determines whether the right can be exercised without paying in avoidable reachability risk. An institution that supports self-custody only for greenfield users has created an option for the future while leaving current hosted users effectively locked in.

Test environments must reproduce the dangerous boundaries

Delegated operation should be rehearsed before it carries production routing intent. A test parent lets the operator learn identity exchange, provisioning, certificate issuance, publication, entity validation, rollover and recovery without affecting live authorizations.

The environment is valuable only if its differences are explicit. A test service may omit parent publication, use a different trust anchor, simplify account eligibility or lack the production incident path. The RIPE NCC test documentation, for example, warns that its delegated test parent does not currently support publication as a service. That is useful honesty; it also means the test cannot validate the entire production hybrid arrangement.

Providers should publish a capability matrix comparing test and production. The operator needs to know which protocol versions, resource structures, rate limits, publication modes, revocation actions and alerts are equivalent. A green test result should not imply assurance for a component that was absent.

Testing should cover failure, not only enrollment. Let the child key become unavailable and restore it from the approved mechanism. Rotate a key. Allow a manifest to approach expiry. Interrupt publication. Change certified scope. Reject a malformed request. Revoke and re-establish the child. Simulate staff succession. Each exercise should leave evidence that another administrator can understand.

Migration rehearsal is especially important. If production requires hosted revocation before delegated creation, the test should measure the operator's readiness for the gap and the provider's response. If production allows overlap, the test should show how duplicate scope is bounded and ended.

Conformance suites can make these exercises repeatable. They should publish expected messages and results without exposing production credentials. Independent CA projects, RIRs and operators can run the same cases. Failures become actionable interoperability reports rather than rumours that one side blames on the other.

Testing has a governance effect. It reduces the informational advantage of the parent and specialist vendors. A member can determine whether it possesses the staff, tools and procedures to accept delegated duties. It can also demonstrate that a refusal or failure occurs at the service boundary rather than inside its own software.

No test can reproduce every repository, validator or network policy. The result is readiness evidence, not a guarantee of route acceptance. But a right that cannot be rehearsed before production is unnecessarily hazardous, especially for small operators exercising it for the first time.

Publication is separable, and that changes the autonomy calculation

Running a CA and running a repository are different functions. The CA protects a private key and signs certificates, manifests, revocation lists and routing authorizations. The publication service makes current signed material available to relying parties over globally reachable mechanisms.

An operator may be capable of key custody but unwilling to operate a highly available public repository. Repositories face network outages, DDoS attacks, storage inconsistency, stale entities and protocol compatibility demands. A small local CA can be secure while its public distribution point is fragile.

RFC 8181 makes separation possible. The child signs locally and submits entities to a publication server through an authenticated protocol. ARIN offers Repository Publication Service for delegated users. APNIC supports parent publication for self-operated CAs. The RIPE NCC offers publication as a service for delegated CAs. This hybrid can be a strong default for many capable holders.

The arrangement preserves meaningful autonomy. The RIR does not possess the child signing key merely because it publishes the entities. It should accept or reject publication messages according to declared protocol and authorization checks, not rewrite the signed content. The operator can retain its own entity and request history.

Dependence remains. If the parent publication service is unavailable or removes the child's material, relying parties may eventually lose access to current valid entities. A publication provider can cause harm without forging the child's signature. Service terms, availability design, incident notice, evidence and exit therefore matter.

Self-publication remains a legitimate option for operators with the capacity and reason to choose it. The parent should not require its repository merely to keep delegated management convenient. Nor should autonomy rhetoric pressure every child to add another fragile publication point to the global retrieval surface.

Migration between publication services needs the same care as migration between CAs. Repository URIs are embedded in certificates and relying parties observe cached state. The operator and parent should stage new publication, verify retrieval and retire old locations according to standards and software behavior. A publication exit should not require surrender of the signing key.

The useful policy is modular choice: hosted signing and hosted publication; delegated signing with parent publication; or delegated signing with independently operated publication, subject to technically justified rules. Each module should identify its operator, duty, terms, evidence and recovery.

Key autonomy is stronger when it does not force unrelated operational burdens onto the key holder. Separation lets institutions allocate responsibility to the party best able to carry it.

Holding the key creates affirmative duties

A right without duties would endanger the same ecosystem it is meant to improve. The delegated operator controls a certification function whose stale or malformed output can waste relying-party resources, invalidate its own entities and complicate diagnosis.

The first duty is key security. Access should be limited, authenticated and logged. High-impact signing may require multiple approval roles. Backups should be encrypted, tested and protected against one administrator leaving the organisation. The operator must know how to revoke and replace a compromised key without relying on the compromised environment.

The second duty is entity freshness and internal consistency. Manifests and certificate revocation lists expire. Certificates need renewal. Published entities must correspond to the current certificate scope. Automation helps, but it should be monitored from outside the CA. A dashboard saying "published" is weaker than independent validation of the repository result.

The third duty is publication availability. If the operator self-publishes, it accepts the burden of globally retrievable current material and resilient protocol service. If it uses parent publication, it must maintain the authenticated publication relationship and monitor acknowledgements. Outsourcing distribution does not remove the need to verify it.

The fourth duty is alignment with routing intent. Local key custody makes automation possible, but automation can sign mistakes faster. The CA should compare intended BGP routes with prospective authorizations, use exact matches where practical, require review for broad changes and preserve history.

The fifth duty is contact and succession. Parent notices must reach an active team. Emergency contacts should survive personnel changes. A merger, insolvency or outsourced network transition needs a controlled handover. A key that no one can lawfully or technically operate is not protected autonomy.

Regional policy can enforce minimum hygiene if the rules are prospective and proportionate. RIPE-847, published in 2025, provides one bounded example: where the RIPE NCC cannot discover and validate a delegated CA's current manifest and revocation list for more than three months, it is to revoke the resource certificate after reasonable discovery and notice efforts. The policy targets persistently non-functional CAs, not brief imperfection.

That rule illustrates reciprocal duty. The operator must keep a functional child. The parent must use a published threshold, seek current material and provide notice. Revocation is not framed as punishment for choosing delegation; it is a response to sustained failure that burdens validation.

Delegated rights are more legitimate when their duties are equally clear. The holder can then choose with informed consent, and the parent can address genuine ecosystem harm without treating self-custody as presumptively suspect.

No-penalty choice is broader than price

An RIR could charge the same membership fee for hosted and delegated service yet still make delegation punitive. Equal treatment has several dimensions.

Eligibility should not shrink merely because the holder chooses its own key, except where a technical or contractual relationship truly differs. The parent should certify the same current resource scope after applying the same registration rules. It should not make unrelated services contingent on surrendering signing custody.

Support should be equitable rather than identical. Hosted users need help with portal actions; delegated users need help with parent exchange, certificate state and publication. The RIR need not debug every third-party installation, but it should identify whether an error arose at its endpoint, publish diagnostics and maintain an escalation route. "Unsupported because self-hosted" is inadequate when the disputed component is the parent's own service.

Information should arrive at the same time. Delegated operators need notice of certificate-impacting registration changes, protocol deprecation, trust-anchor work, service incidents and policy proposals. They should not learn from relying-party alarms that a parent action changed their scope.

Incident access should also be equal. A delegated user may need emergency reissuance or help confirming a parent response. The provider can require strong identity proof, but it should not place self-custody behind a lower-priority queue simply because the hosted team has more familiar tools.

Review and remedy should follow control. The holder is responsible for its key and child output. The parent is responsible for accurate entitlement, protocol operation and actions it takes on the child certificate. Contracts should not use delegation to disclaim every parent-controlled failure. Conversely, a delegated operator should not expect the RIR to insure loss caused by its unmaintained repository.

Pricing can reflect cost. A specialized publication or assisted migration service may consume resources. Fees should be published, approved through the relevant governance process and reasonably related to service rather than designed to steer users toward hosted custody. Fee waivers or shared assistance may be appropriate where public-interest networks lack capacity, but subsidy decisions should be transparent.

Membership standing must remain untouched. Choosing a delegated CA should not reduce voting, policy participation, access to registration services or the presumption that the holder is a responsible member. Security incidents should be judged on evidence, not on a cultural belief that only central operation is safe.

No-penalty choice does not mean no consequences for failure. Neutral safety rules, cost-based fees and proportionate revocation can apply. The test is whether the same legitimate objective could be achieved without burdening key autonomy more than necessary.

Revocation authority needs reasons and a route back

Delegation does not remove the parent's ability to revoke a child certificate. That power is necessary when a key is compromised, resources leave the holder, a certificate becomes inconsistent with authoritative registration, or a persistently failed child imposes operational harm.

The power also defines the limit of private-key autonomy. A holder may possess the child key and every backup, yet its signatures cease to validate when the parent path is revoked. Procedural safeguards at this boundary are therefore essential.

The parent should publish finite classes of revocation. Security compromise, authenticated holder request, completed resource transfer, expiration of an eligible service relationship, binding legal requirement and sustained technical failure are intelligible classes. Broad "operational reasons" should be supported by thresholds, approvers and review.

Notice should match urgency. A confirmed key compromise may require immediate action, followed by rapid re-enrollment under a clean key if entitlement remains. A planned transfer can use a scheduled cutover. A technical-failure rule can provide observation, attempts to contact, a cure period and final notice. Administrative disputes unrelated to routing security deserve caution before certificate action.

Reasons should be given in enough detail for the operator to respond. A protocol error should identify the failed exchange. A resource-scope change should identify the registration event. Sensitive legal material may require limited disclosure, but secrecy should not become the default.

Review must be capable of producing a remedy. An appeal heard months after routes lose valid authorization is not sufficient. The system needs an emergency technical review able to correct mistaken parent action, followed by a fuller institutional review if the facts or authority remain disputed.

There must also be a route back. If the child key is safe and the parent acted in error, restoration can reissue the correct certificate and verify the existing entities. If the child key is compromised, the process should establish a clean child. If the operator failed, the cure may require current manifests, corrected publication or migration to hosted service. The remedy should fit the cause.

An audit record should preserve request, reason, evidence class, approvals, notices, certificate actions, publication effect and restoration. Public reporting can aggregate routine events and describe serious provider failures without disclosing private topology.

The legitimacy of parent authority does not come from denying its effect. It comes from using the effect through predictable, reviewable and repairable rules. Delegation remains meaningful when the parent cannot sign with the child key and cannot revoke the child arbitrarily.

Automation should be portable rather than captive

Large operators often choose delegation because they want routing authorizations to follow network intent through local automation. A traffic-engineering system can prepare a route, obtain approval and create the corresponding ROA without waiting for a human to navigate several regional portals.

This benefit is real only if automation is portable. The operator should be able to export its intended route set, CA relationships, certificate history and publication state in documented forms. It should not have to reproduce a proprietary provider model before moving between CA implementations.

Open provisioning and publication protocols establish the parent and repository boundaries, but local CA data also matters. Keys may appropriately remain non-exportable from hardware. Configuration, authorization intent, child relationships, contacts, audit evidence and recovery instructions should still be transferable or reconstructable.

Software diversity reduces dependence on one project, but migration between implementations is not trivial. A new CA may use a new key and require parent coordination. Child certificates and publication URIs may change. The operator should test the transition and preserve continuity rather than copying opaque internal state.

RIRs can support portability by documenting neutral protocol requirements rather than endorsing one mandatory client. They may provide examples for widely used software while accepting any conforming implementation. A conformance test should report the failed standard behavior rather than the unsupported brand.

Managed delegated service requires additional clarity. A third party may operate the child CA on behalf of the holder while the holder retains contractual authority or a hardware key. The RIR should authenticate the eligible holder and recognize authorized agents without confusing the vendor with the resource holder. Exit terms should let the holder replace the agent without losing the parent relationship.

Automation also increases the blast radius of error. A malformed intent feed can replace many authorizations. Delegated software should offer dry runs, transaction limits, approval policy and an emergency freeze. Local control is not an argument for weaker safeguards; it is an opportunity to integrate them more closely with actual routing.

Portable automation strengthens both autonomy and accountability. The holder can change tools, preserve evidence and identify which system issued a mistaken entity. The parent can maintain a stable standards boundary instead of supporting every internal design.

A right tied to one application version or consultant is brittle. A right expressed through interoperable protocols, recoverable configuration and replaceable agents can survive institutional change.

Small operators need an assisted path, not a lecture on sovereignty

Delegated RPKI is often discussed through the needs of global carriers and national registries. Smaller operators may also have legitimate reasons for local custody: public-sector requirements, internal security policy, multi-provider routing, distrust arising from a past account dispute, or a need to integrate with local controls.

They face a steeper relative burden. The same CA concepts, key management, publication and monitoring apply to an organisation with three engineers as to one with three hundred. Documentation that assumes deep public-key expertise can make the formal option inaccessible.

Assistance should not mean taking the key back. RIRs and community institutions can provide step-by-step standards explanations, test parents, validated configuration examples, conformance checks, office hours and migration scheduling. A hybrid publication service can remove the largest public availability burden while preserving local signing.

Cooperative operation is another possibility. Several organisations may use a qualified managed provider while maintaining distinct child keys and authority. Contracts should define who can sign, who holds recovery material, how incidents are reported and how each member exits. Shared infrastructure must not collapse separate authorization into one undocumented administrator.

Financial support may be justified for community networks, universities and critical local services where secure adoption has public value. It should be distributed through transparent criteria and should not purchase political support. Assistance and registry elections are separate domains.

Training should include reasons not to delegate. If the organisation cannot maintain contact, protect credentials, monitor publication or perform recovery, hosted service may be safer today. The decision can be revisited. Informed choice includes the freedom to decide that local keys are not yet responsible.

The provider should avoid two tones. One is dismissive: "Only experts need this." The other is romantic: "Real control means doing everything yourself." Both obscure a spectrum of modular choices and assistance.

A practical right is designed around the least-resourced eligible member who has a legitimate use case, not merely the first large operator that successfully completed the XML exchange. If that member can test, obtain help, use parent publication and migrate safely, the institutional option is mature.

Evidence should distinguish denial, difficulty and responsible refusal

Claims that an RIR does not permit key autonomy can mean different things. The service may be formally unavailable to a holder category. It may be available but undocumented. A request may be delayed. A particular client may fail conformance. The holder may lack the contractual relationship required for certification. The operator may have supplied an invalid request. The parent may have refused for a stated safety reason.

These cases require different remedies. A rights review should preserve the request date, holder category, resource relationship, published eligibility, software and version, protocol exchange, error response, support contact, reason, delay and final outcome. Screenshots alone are weak where machine messages exist.

Difficulty also needs a denominator. Ten complaints do not establish that most migrations fail if the number of attempted migrations is unknown. A regional claim should not become a global one. Providers can improve evidence by publishing request and outcome counts with categories and privacy safeguards.

Responsible refusal is possible. A request outside certified resources must not be granted. A child using a prohibited algorithm or invalid certificate request may need correction. A persistently non-functional CA can justify action under a published rule. An unauthorized vendor cannot simply claim the member's entitlement.

The provider should issue a reason that maps to a rule and a cure. "Unsupported" should identify whether the issue is protocol, profile, eligibility, security or capacity. The holder should be able to ask for review where it believes the standard or policy has been misapplied.

Researchers should also verify public documents at the time of the event. Service features change. LACNIC's current page records delegated availability from 2019, while earlier absence cannot be inferred from today's form. APNIC and RIPE publication services evolved. A fair historical analysis dates claims rather than projecting current capability backward.

Operational evidence outranks rhetoric. A charter may promise holder control; a successful standards exchange shows one aspect of it. A service page may promise delegation; a reproducible migration gap shows a limitation. Neither single item settles the whole institution.

This discipline protects both members and RIRs. It makes genuine exclusion visible while filtering out failures caused by ineligible scope or broken child software. Key autonomy deserves evidence strong enough to support repair, not slogans broad enough to fit every frustration.

Number Resource Society can define a reciprocal compact

NRS's stated focus on holder participation, accurate registration and limits on arbitrary registry power makes delegated RPKI a natural test case. The organisation can contribute most by defining concrete rights and reciprocal duties.

Its first product could be a regional delegated-access matrix. For each RIR and relevant holder category, it would record eligibility, governing terms, parent protocol, supported certificate profiles, publication options, test capabilities, migration sequence, support route, fees, revocation rules and review. Each entry would link to current first-party material and carry a verification date.

The second could be a conformance and migration clinic. Members would run authorized test cases with maintained CA software, preserve results and seek provider correction before publication. The clinic could distinguish child defects from parent defects and share fixes without exposing keys or resource details.

The third could be a continuity compact for members choosing delegation. Entities would maintain named contacts, key-recovery evidence, current entity monitoring, publication tests and a succession plan. NRS could provide templates and exercises rather than certify security it cannot independently guarantee.

The fourth could be representation in regional governance. Where a migration requires avoidable break-before-make, support terms are unclear or delegated users receive weaker incident access, NRS can submit evidence-led proposals. It can ask boards to explain cost, security constraints and implementation plans.

NRS should apply limits to its own advocacy. A private key is not proof of property title, perpetual registration entitlement or immunity from court orders. A regional parent remains part of the certificate chain. A member-operated CA can fail and may properly face proportionate action. NRS first-party materials do not prove that every RIR accepts its analysis or that its proposed compact is already enforced.

The reciprocal framing is important. Members do not ask to hold keys without responsibility. They ask for the tools, standards, migration and fair treatment needed to carry responsibility competently. RIRs do not surrender authoritative resource scope. They accept that control of the child's signing act belongs with the child when the member chooses delegation.

That compact strengthens routing security. It creates more capable operators, preserves a low-burden hosted path and makes concentrated functions contestable without destabilizing the hierarchy.

Objections are strongest when they expose hidden costs

The first objection is that delegated CAs increase the number of systems that can fail. True. Hosted centralization can provide professional key custody and repository resilience. Delegation trades some central operational efficiency for separation of signing authority and local integration. The answer is informed choice, hybrid publication and enforceable minimum hygiene, not compulsory delegation.

The second objection is that a parent cannot permit overlap during migration without double certification. Overlap does create risk. But providers can pre-validate a child, stage publication and constrain any transitional duplicate scope. Where protocol or policy prevents overlap, they can publish the limitation and provide a coordinated cutover with rapid reversal. "No overlap" should not mean "no migration engineering."

The third objection is that open standards already solve equality. Standards solve a crucial technical part. They do not establish eligibility, fees, support, notice, test parity, migration order or remedy. A conforming endpoint can still be practically inaccessible.

The fourth objection is that no-penalty rules would force RIRs to subsidize expensive users. They need not. Transparent cost-based pricing and reasonable support boundaries are compatible with equal standing. Penalty means burden unrelated or disproportionate to legitimate cost and risk, not every difference in service.

The fifth objection is that local key possession encourages mistaken claims of ownership. That rhetorical risk exists. Documentation should state the boundary plainly: the key authenticates the child's signed entities within current certified scope. It does not create legal title or override valid parent action.

The sixth objection is that delegated users can simply return to hosted service if they fail. Return is useful but also a migration requiring current authority, safe entity replacement and key retirement. It should be designed, tested and free of stigma. Failure should produce learning rather than permanent exclusion where the holder remains eligible.

The final objection is that only a small minority may want delegation. No reliable global denominator supports a precise share, and minority rights can still discipline a concentrated service. The cost should remain proportionate to demand, but nominal support is not enough where the option is presented as part of the trust model.

These objections narrow the claim to a defensible one. The right is not universal self-certification, free bespoke support or exemption from safety. It is a usable, standards-based and fairly administered choice for eligible holders prepared to accept the duties.

A delegated-rights charter can be short and enforceable

Each RIR offering certification should publish a delegated-rights charter alongside technical documentation and service terms. It need not be grand constitutional language. It should answer the decisions an operator must make.

Eligibility: identify which direct members, sponsored users, legacy holders, national registries and authorized agents can request a child certificate, and under which agreement. State the evidence required and the expected response time.

Interoperability: list supported standards, profiles, algorithms and protocol versions. Provide endpoints, test cases, deprecation notice and a reasoned conformance response. Accept any implementation that meets the published requirements rather than a single preferred brand.

Choice: offer hosted, delegated and available hybrid publication models without unrelated loss of membership service. Publish fees and support boundaries. Permit authorized managed agents while preserving the holder's authority.

Migration: describe every state from inventory through old-CA retirement, including whether overlap is possible, how pre-validation works, which staff are present, what monitoring proves completion and how emergency restoration occurs.

Operation: state holder duties for key security, manifests, revocation information, publication, contacts, routing intent and succession. State parent duties for entitlement accuracy, protocol availability, notice, incident evidence and support at its boundary.

Adverse action: define revocation classes, urgency, notice, cure, approvers, evidence, review and restoration. Separate persistent technical failure from brief outage and security emergency from administrative dispute.

Portability: explain how a holder changes CA software, publication provider, managed agent or deployment model. Provide exportable state where compatible with key security and preserve a historical record.

Accountability: publish service measures with honest denominators, report serious provider-caused incidents and provide an independent review route. Invite community amendment through the RIR's established governance.

The charter should be testable. A member can point to a missed response, unsupported conforming exchange or undocumented migration step. The institution can point to a failed holder duty. Disagreement becomes narrower and more resolvable.

Such a charter would not make the RIR a guarantor of every delegated repository, nor make the holder independent of resource registration. It would convert an attractive service description into reciprocal commitments. That is what turns key possession from a technical feature into an enforceable institutional choice.

Measure exercised choice, not theoretical availability

RIRs often report RPKI coverage or entity counts. Those measures do not reveal whether delegated choice is usable.

A regional service can report eligible requests, completed onboarding, median and range of time to parent relationship, conformance failures by reason, migrations by model, emergency restorations, voluntary returns to hosted service and involuntary revocations. Counts need clear reporting periods and holder categories where privacy permits.

Migration measures should separate preparation from production cutover. A long preparation period chosen by the operator is not the same as a parent delay. Report expected and actual authorization gaps, external validation success and unresolved incidents. Do not call a certificate issuance complete if intended entities remain unavailable.

Support measures should identify which side controlled the fault. Parent endpoint, publication service, child software, local key, account eligibility and registration state are different categories. This lets investment follow recurring problems.

Operators can maintain their own readiness score: current key recovery, valid manifest and revocation information, external repository validation, active contacts, tested parent exchange, documented intent, software support status and succession. The score should prompt action rather than become a public badge that overstates security.

NRS and researchers can compare published rights and authorized tests across regions. They should avoid a simplistic rank. A region with few delegated users may have a highly usable service; another with more users may reflect market structure. Adoption is not proof of fairness, and low adoption is not proof of obstruction.

The most revealing metric is successful model change without unintended loss of valid authorization. It tests documentation, identity, standards, parent operation, child readiness, publication, monitoring and remedy together.

No complete public data currently supports a global delegated-request acceptance rate, migration-failure rate, cost comparison or route-impact probability. That limitation belongs in every serious analysis. It is also a reason for institutions to publish bounded service evidence.

The objective is not to maximize delegation. It is to show that eligible members can exercise it when justified, and that those who stay hosted do so by informed preference rather than practical captivity.

Autonomy is the ability to choose responsibility

Delegated RPKI has existed in regional forms for much of operational RPKI's history. Open standards make parent-child provisioning and separate publication possible. Multiple regions now describe self-operated certification, and software exists outside RIR control. These are substantive achievements.

The remaining governance question is whether the option works as a right rather than an exception. Can an eligible holder discover the terms, use a conforming child, test failure, choose publication, migrate safely, obtain support, challenge a parent error and change tools without unrelated penalty?

Private-key possession answers only one part. It prevents the hosted provider from signing as the child and allows local security and automation. It does not remove the parent certificate, guarantee repository availability, prove resource title or excuse the child from operational duties.

Standards, migration support and no-penalty choice must coexist. Standards without migration leave installed hosted users captive. Migration without interoperability can bind them to one tool. Technical choice without equal information, support and review can create second-class membership. Equal treatment without holder duties can burden every relying party.

RIRs should retain a strong hosted service. It is the responsible choice for many members and a major contributor to practical adoption. They should also make delegated and hybrid models demonstrably usable, because trust is stronger when key custody can be separated from parent authority according to operator need.

Members choosing delegation should accept the full affirmative compact: secure keys, current entities, resilient publication, monitored intent, active contacts and tested succession. They should not describe local custody as escape from legitimate registration or certificate scope.

NRS can make this balance visible through evidence, conformance exercises, migration assistance and regional proposals. Its advocacy is credible when it insists on duties as clearly as rights and avoids claims wider than the technical and contractual record.

The right to hold one's own keys is ultimately the right to choose responsibility. It means the parent cannot require surrender of the child's signing act merely for administrative convenience, and the child cannot demand trust without competent operation. Between those positions lies a mature institutional settlement: open, portable, reviewable and safe to enter or leave.

When that settlement exists, delegated RPKI is not a slogan about sovereignty. It is a practical separation of duties that strengthens both routing security and the legitimacy of the institutions above it.

Sources