NRS RPKI With User-Controlled Keys

Summary

• The NRS default should be a delegated CA in which the resource holder generates or authorizes generation of its private key, controls signing authority and can choose qualified operational support. Hosted signing remains an option, not the condition for practical participation.
• Key custody is only one part of certificate freedom. The holder also needs timely parent-certificate service, a usable publication interface, exportable signed state, independent monitoring and a documented right to move providers without losing route-security coverage.
• Portable publication should be tested as an ordinary service transition. Overlap, repository synchronization, manifests, revocation material, relying-party visibility and rollback need measured acceptance criteria so that moving service does not create a validation gap.
• Emergency recovery should not depend on routine key escrow. Offline recovery credentials, multi-party authorization, pre-agreed replacement-key procedures and narrowly scoped continuity actions can restore control while leaving ordinary signing with the holder.
• A user-controlled subordinate key does not neutralize the parent CA. NRS rules must constrain delayed issuance, selective revocation, repository obstruction, unexplained resource reduction and other adverse actions through notice, evidence, rapid review and remedies.
• Small operators need supported delegation: managed hardware, ceremonies, health checks, training and contracted operation in the user's security domain. The meaningful distinction is who controls authority and exit, not who physically types each command.
• The design should be judged by observable exercises: independent key generation, routine rollover, publication-provider migration, compromise recovery, parent dispute and relying-party convergence. Rights that cannot survive those tests are descriptive promises rather than operational rights.

RPKI authority is divided even when one service makes it look unified

The Resource Public Key Infrastructure is often presented to operators through a simple product choice: use a hosted service or run a delegated CA. That description is useful but incomplete. Several powers sit beneath it. A parent CA certifies a child's resource holdings. The child controls a private key and issues signed products. A repository makes certificates, revocation information, manifests and route-origin entities available. Relying parties retrieve and validate those products. Operational portals authenticate requests and may perform signing on behalf of a customer.

When one institution performs all those functions, the user's experience can be smooth. It can also obscure where power resides. A user may click to authorize an origin while the service generates and retains the relevant private key. The same institution may decide how requests are authenticated, when entities are published, how an account is recovered and whether export is possible. The customer has a service relationship, but not necessarily an independently usable certification capability.

This distinction matters because route-security authority can shape real connectivity. A route origin authorization does not command routers by itself; relying networks decide whether and how to use validated state. Yet widespread validation gives signed state practical consequences. An incorrect withdrawal, stale publication, overbroad authorization or compromised key can affect how routes are classified. Concentrating ordinary signing and recovery therefore creates a governance dependency even where formal resource registration remains unchanged.

The relevant standards do not require every function to be controlled by one operator. The RPKI architecture described in RFC 6480 establishes a hierarchy tied to Internet number resources. The certificate profile in RFC 6487 constrains how resource certificates express authority. Signed-entity and repository standards define how products are made available and validated. Certificate enrollment and publication protocols support interaction across organizational boundaries. This modularity is not merely an engineering convenience. It provides room for institutional choice.

NRS should use that room deliberately. Resource recognition, parent certification, child signing, repository operation and relying-party validation should remain distinct in policy, contracts, audit and incident response. A provider may offer several functions, but combining them should not erase the user's right to separate them later. An institution should have to justify each power it exercises, not inherit a broad mandate because customers prefer a convenient interface.

The strongest warning against complacency comes from the hierarchy itself. A child that controls its private key is not sovereign. Its parent can decline to reissue a certificate, reduce certified resources where policy permits, revoke a certificate or fail to support a timely rollover. A repository operator can delay or mishandle publication. A relying party can retain stale material until refresh and expiry rules resolve it. The objective is therefore not a romantic claim that possession of a key eliminates dependence.

It is a constitutional allocation of dependence: each actor receives the minimum power required, and each power has evidence, time limits and review.

User-held keys should be the ordinary presumption

The default arrangement should begin with key generation in a security boundary controlled by the resource holder. That boundary may be a hardware security module on the holder's premises, a dedicated cloud security service in the holder's account, an offline device, or a managed appliance operated under contract. The precise equipment should reflect risk and scale. What matters is that the holder can authorize use, replace the provider, obtain evidence of key operations and prevent the Society from exercising ordinary signing power unilaterally.

Generating a key is not enough. Control means the holder decides who may activate it, under what approval rule, for which signed products, with what audit record and during which period. A two-person rule may be appropriate for a large address holder. A smaller operator may use one accountable administrator plus an independent recovery contact. High-risk actions, such as broad route authorizations or replacement after suspected compromise, can require stronger approval than routine renewal.

NRS should publish a baseline for delegated custody without prescribing one expensive appliance. The baseline should address entropy, supported algorithms, secure backup, access logging, separation of duties, revocation readiness, time synchronization, administrator changes, protected recovery material and disposal. It should distinguish mandatory security outcomes from optional implementation patterns. An operator should be able to prove the required control without buying from a favored vendor.

The presumption of user custody should also apply when operations are outsourced. A managed-security company may administer an HSM, schedule signing and monitor publication. If the user controls the account, approval policy and replacement rights, this can remain delegated operation. Conversely, a device labelled "customer managed" offers little independence if only the provider can export configuration, approve a new administrator or switch publication. Governance should examine effective authority rather than marketing descriptions.

Some organizations will choose hosted signing. They may lack staff, operate only a small resource set or value a simple service. NRS should support that choice with strong authentication, visible approvals and measured service quality. But hosted users should receive an explicit upgrade path. They should be able to establish their own key, obtain the necessary subordinate certificate relationship, move publication, verify relying-party visibility and close hosted signing without a punitive fee or discretionary delay.

Default rules shape markets. If delegated operation requires exceptional approval, lengthy negotiation or specialized personal contacts, hosted control becomes the practical norm even if policy calls it optional. NRS should reverse that burden. A conforming delegated request should be routine. Any refusal should identify a specific security or authorization defect, state how to cure it and permit rapid independent review. The Society may enforce technical requirements; it should not use those requirements to protect its own service share.

The same principle applies to key evidence. The user should receive verifiable records of key creation, certificate requests, certificate issuance, entity signing, revocation and rollover. These records should be useful during an audit or dispute without exposing the private key. If a provider performs a ceremony, the user should receive attestations and logs sufficient to show what occurred. Evidence should travel with the customer when service changes.

Certificate rights are a bundle, not a single custody claim

Calling a key "user controlled" can become a slogan unless related rights are specified. The first right is generation or independently authorized generation. The second is exclusive ordinary use: neither NRS nor the provider should be able to create new signed products merely because it operates infrastructure. The third is inspection through reliable records. The fourth is replacement through normal rollover and urgent compromise procedures. The fifth is movement between providers. The sixth is termination with safe retirement of old authority.

The bundle must include timely parent service. A child cannot maintain valid certification indefinitely if the parent ignores certificate requests, delays changes or refuses a justified replacement key. NRS should set service objectives for routine issuance, planned rollover, resource changes and urgent compromise. Time should run from a complete authenticated request. If a request is defective, the response should identify the defect rather than restart an opaque queue.

It must also include access to publication. A child CA that signs correctly but cannot make products reliably available does not possess useful independence. The holder should be able to select among qualified repository providers, operate its own conforming repository where appropriate, and retrieve a complete current inventory. Repository terms should not make continued publication contingent on unrelated membership disputes or commercial services.

Data portability is another right. The holder should be able to export public certificates, signed entities, manifests, revocation products, repository paths, relevant timing information, configuration and audit history in documented formats. Private keys may be non-exportable by design, especially in hardware, but that should not trap the user. A replacement key and coordinated transition must remain possible. Non-exportability can protect a key; it cannot justify non-portability of the certification relationship.

The bundle includes independent observation. The user should not have to trust the same dashboard that performed the action. External monitors should retrieve repositories as relying parties do, validate the resource chain, compare expected and observed products, and alert on disappearance, inconsistency, unexpected origin changes or approaching expiry. NRS should support standardized feeds or notifications so that holders and third-party monitors can detect adverse changes quickly.

Finally, certificate rights need remedies. A user whose service is delayed or obstructed should have a fast channel that understands routing consequences. Review should be capable of ordering publication restoration, temporary continuity measures, corrected issuance or preserved state. Financial compensation may matter later, but it does not replace rapid technical correction. A right that can be vindicated only after the relevant certificate expires is not an effective right.

Publication must be portable in fact, not only in contract

Repository portability is the most likely place for nominal freedom to fail. Publication involves names, locations, synchronization, manifests, certificate and revocation state, fetch behavior and relying-party caches. A move that looks complete from the user's portal may still create inconsistent views among validators. NRS should therefore define migration as a measured technical event with preparation, overlap, observation and closure.

Before a move, the outgoing provider should supply a complete inventory and recent operational history. The incoming provider should verify that it can publish every required current product and maintain the necessary availability. The child should prepare fresh manifests and any other time-sensitive material under the applicable standards. Parent and child references should be checked. Monitoring should establish a baseline across several independent retrieval points.

The transition should avoid a moment in which neither repository serves a usable state. The exact sequence will depend on certificate and repository design, but the governing requirement is clear: old and new arrangements need a bounded overlap or another standards-conforming method that preserves validation while references change. Operators should model relying parties that refresh at different times. Success cannot be declared merely because the new endpoint answers one test request.

RFC 8181's publication protocol and RFC 8182's repository delta mechanism illustrate why service boundaries and retrieval behavior deserve separate attention. A publication interface can let a CA submit products to a repository it does not operate. Delta retrieval can improve efficient synchronization for relying parties. Neither protocol alone guarantees institutional portability. Credentials, repository references, service terms, historical state, monitoring and coordinated change still need governance.

NRS should require qualified providers to accept and release customers through common procedures. Qualification should test protocol conformance, availability, consistency, incident response, export completeness and migration cooperation. It should forbid contractual terms that claim ownership over customer certificates or signed products. Fees for exit should reflect reasonable work, not the strategic value of trapping a user.

Migration exercises should occur before an emergency. A holder might run an annual test that creates a non-production child environment, moves it between services and verifies independent validation. Larger holders could perform a controlled production transition at longer intervals. Providers should participate in Society-wide exercises that include an outgoing operator that is slow, unreachable or financially distressed. The point is to discover hidden dependencies while time remains.

Rollback deserves equal attention. If the incoming service publishes an inconsistent state, there must be a bounded way to restore the last known good arrangement without creating competing authority. Rollback criteria should be decided before the move: failed validation from multiple monitors, missing critical entities, divergence beyond a defined interval or inability to refresh. One accountable transition leader should coordinate action, while independent observers record what relying parties actually see.

Closure should retire credentials and references that are no longer needed, confirm that the outgoing service cannot accept new submissions, preserve required audit evidence and notify the holder of residual retention. The outgoing provider must not keep a shadow ability to publish after the transition. Nor should it delete evidence needed to explain the prior state. Security requires both removal of obsolete power and preservation of accountable history.

Portability metrics should be public in aggregate. NRS can report median and worst-case migration time, observed validation gaps, rollback frequency, incomplete exports, provider-caused delays and incidents by severity. Comparable evidence gives members a basis for choosing services. It also reveals whether a formally competitive repository market is genuinely open or dominated by one provider whose customers cannot safely leave.

Emergency recovery should restore authority without creating permanent escrow

Key loss and compromise are inevitable design cases, not remote exceptions. An operator can lose access to an HSM, dismiss an administrator, suffer a disaster, discover unauthorized signing or become locked out of a cloud account. A governance model that insists on user-held keys but offers no credible recovery will push users back toward concentrated hosting. A model that solves recovery through routine central escrow recreates the same concentration under another name.

NRS should prefer replacement over recovery of the same private key. If a key is suspected compromised, restoring a copy can restore the attacker's power as well. The safe objective is to authenticate the holder, establish a new key, obtain appropriate parent certification, revoke or retire the old certificate, publish coherent current state and verify relying-party convergence. The old private key should not be treated as a treasure that must always be recoverable.

Planned recovery credentials can support this transition. At enrollment, the holder can identify multiple recovery authorities, such as two officers and an independent security contact, each with protected credentials. No single party should possess enough authority to replace the key. A threshold approval can authorize a replacement request after identity, role and resource evidence are checked. The threshold record should be updateable when personnel change and tested periodically.

Offline recovery material may be held in separated locations under tamper-evident control. For some organizations, this could include an encrypted backup split among custodians. For others, especially where keys are intentionally non-exportable, it may consist of credentials that authorize a new key ceremony rather than a copy of the signing key. NRS should define outcomes and evidence while allowing both patterns according to risk.

Emergency authority must be narrow. A continuity trustee or Society security function may be allowed to facilitate authentication, preserve repository availability and request a temporary parent action. It should not gain open-ended ability to issue route authorizations for the user's resources. Any temporary signed state should be pre-authorized, minimally permissive, short-lived and visible to the holder and independent reviewers. Where no safe temporary state exists, the decision should be explicit rather than disguised as routine administration.

The recovery sequence should classify the incident. Loss without evidence of compromise can permit a controlled rollover with ordinary authorizations maintained during overlap. Suspected compromise demands faster revocation analysis and closer inspection of every recently signed product. Organizational control disputes require caution: the technical team should not choose a corporate faction merely because one side possesses a device. Legal incapacity or dissolution may invoke separate continuity rules tied to recognized resource authority.

Time objectives should match routing risk. A suspected unauthorized authorization affecting active routes may require action within hours. A lost offline key with current products valid for a safe interval may allow a more deliberate ceremony. The Society should publish target times by incident class and measure performance. Urgency should not erase authentication, but authentication should be designed before the crisis rather than invented during it.

Every emergency action needs after-the-fact review. The record should show who initiated it, what evidence supported authority, which products changed, how long temporary measures lasted, when the user regained control and what relying parties observed. Review should examine both false negatives and false positives. Refusing a genuine holder can prolong risk; accepting an impostor can transfer effective routing authority. Recovery design must confront both errors.

The Society should also provide a safe rehearsal. Entities can simulate loss, administrator departure and compromised signing in an isolated environment, then carry out replacement and publication checks. A provider that passes normal operations but cannot support a recovery exercise should not be treated as fully qualified. Recovery is part of the service, not an exceptional favor.

The parent CA remains powerful and must be governed accordingly

Delegation changes the location of ordinary signing, but the parent still anchors the subordinate certificate. This fact should be stated plainly. A parent can harm a user by revoking without adequate basis, failing to renew, certifying an incorrect resource set, delaying a replacement key or publishing inconsistent revocation state. A policy that celebrates user custody while ignoring parent power would misdescribe the risk.

RFC 8211 examines adverse actions by a CA or repository manager and is especially relevant to institutional design. Technical architecture cannot make every hostile or mistaken act impossible. Governance must reduce opportunity, improve detection, constrain discretion and provide recovery. NRS should treat parent intervention as an accountable exercise of defined authority, not an unreviewable property of operating the root or intermediate service.

Routine parent actions should be automated against authoritative resource records and authenticated requests, with transparent status and independent monitoring. Manual discretion should be reserved for identified exceptions. If a certificate request is rejected, the user should receive a reason code, the evidence relied upon and a route to correction. If the Society believes an urgent security action is required, it should record the scope, expected duration and approval basis.

High-impact adverse actions should require separation of duties. The person investigating an alleged compromise should not alone authorize revocation and control the review record. A two-person or committee approval can reduce error, while an emergency rule can permit immediate temporary action followed by rapid independent confirmation. The standard should identify which events justify that exception and how quickly confirmation must occur.

Notice is important but not absolute. Advance notice is appropriate for planned expiry, resource changes and non-urgent compliance issues. It may be unsafe before responding to a confirmed key compromise. Even then, simultaneous notice should go through independent channels unless doing so would clearly worsen harm. Silence must not become the default simply because technical staff view certificate administration as internal.

Review needs technical competence and the ability to act quickly. A general membership appeal that meets weeks later is inadequate for a live routing-security problem. NRS should maintain an independent panel capable of examining resource authority, certificate state, repository evidence and operational impact. It should be able to order restoration, replacement, correction or temporary continuity while a broader dispute continues.

Remedies should preserve the distinction between certification and resource entitlement. Correcting an improper certificate revocation does not decide every contractual claim. Conversely, a holder cannot use a subordinate key to defeat a valid transfer or resource change recognized under governing rules. The certificate service should reflect authoritative resource state, and disputes about that state should be decided through the appropriate rights procedure with continuity protections.

Transparency can deter misuse without exposing exploitable detail. NRS should report counts and classes of emergency revocation, delayed issuance, disputed resource reduction, repository interruption and review outcomes. Significant incidents should receive public explanations once immediate risk passes. Sensitive authentication evidence can remain protected. Members need enough information to judge whether exceptional powers are rare, justified and corrected when wrong.

Key lifecycle duties should be specific and testable

Control is maintained across a lifecycle, not established once at enrollment. Key generation should use approved algorithms and secure randomness. Certification requests should bind the key to an authenticated holder. Activation should confirm publication and independent validation. Routine operation should renew time-sensitive products, monitor repositories and limit administrator privileges. Rollover should replace keys before weakness or device failure creates urgency. Retirement should revoke or expire authority and securely dispose of obsolete secrets.

Algorithm agility is part of this duty. RFC 6916 describes an algorithm-agility procedure for the RPKI, reflecting the need to change cryptographic algorithms over time. NRS should avoid a custody model that makes such change dependent on one vendor's hardware schedule. Qualification should test whether services can introduce supported algorithms, run necessary overlap, update relying-party expectations and retire old material without forcing users to surrender control.

Routine rollover is the best evidence that recovery will work. A holder that can generate a new key, obtain certification, publish a coherent state and observe relying-party convergence has demonstrated several critical rights at once. NRS should set rollover intervals or risk-based expectations, while avoiding needless churn. The exercise should be documented sufficiently to distinguish a completed transition from a portal status message.

Authorization content also needs governance. User custody should not mean unconstrained or careless issuance. Interfaces should validate resource scope, prefix length, origin identity and expiry. Risky changes can receive additional review inside the holder's own approval policy. Tools should show the likely effect of removing or narrowing an authorization and should warn about conflicting current entities. The holder controls the decision, but good design reduces avoidable mistakes.

Short validity can limit exposure but increase dependency on reliable renewal and publication. Long validity reduces renewal pressure but can leave stale authority effective. NRS should set balanced profiles and make the trade-off visible. Emergency procedures should not rely on every relying party refreshing instantly. Tests should include validators with realistic polling, cache and failure behavior.

Administrator lifecycle deserves the same rigor as cryptographic lifecycle. Departing staff should lose access promptly. Recovery contacts should be reconfirmed. Privileged actions should use strong authentication and independent notice. Shared accounts should be prohibited for high-impact actions. A technically secure HSM does not protect authority if an old employee can still approve its use through a neglected portal.

Supported delegation can serve small operators without taking their rights

The strongest practical objection to user-held keys is unequal capacity. A large network can employ security engineers and operate redundant hardware. A small holder may have one network administrator and little appetite for certificate maintenance. If delegation is designed only for the largest members, hosted control will remain dominant and the right will be formal rather than widely usable.

NRS should establish a supported-delegation service category. Providers could supply configured hardware, managed ceremonies, monitored publication, renewal alerts, incident support and periodic exercises. The user would retain ownership or decisive control of the security account, set approval policy and possess the ability to appoint a new provider. The provider would operate under a documented mandate that can be terminated without losing the certification relationship.

Costs should be transparent and comparable. Basic delegated operation should not require bespoke legal negotiations. Standard service descriptions can state which party controls the HSM account, who can initiate signing, who approves high-risk actions, how records are exported, how publication moves and how recovery works. A customer should be able to compare two providers on authority and exit, not merely price and uptime.

Shared infrastructure can still preserve separation. A provider may host many logical security domains on certified hardware, provided each customer's keys and approvals are isolated, privileged access is controlled, and one customer cannot affect another. Independent assessment should test technical isolation and operational practices. NRS should not pretend that shared hardware is inherently unacceptable or inherently safe.

Training should focus on decisions rather than turning every holder into a cryptographer. Administrators need to understand what a route authorization does, how key compromise differs from account loss, when to request rollover, how to verify publication and whom to contact. Exercises can reveal whether organizational authority is current. A concise, well-rehearsed procedure is more valuable than a long manual no one has used.

Subsidy may be justified for smaller or public-interest networks if cost would otherwise force centralized custody. Funding should follow the user and be usable with multiple qualified providers. Giving one Society-operated host a price advantage would undermine the market NRS is trying to create. Support should expand choice, not convert financial assistance into technical dependence.

Hosted service itself should meet an anti-lock-in standard. Users should see every active authorization, receive independent notices, export history, designate recovery contacts and practice transition to delegation. The service should not describe the Society as the owner of the key authority merely because it performs signing. Hosted operation is a fiduciary-like technical role exercised for the recognized holder within explicit limits.

Audit should examine effective control and relying-party outcomes

An audit that checks only whether keys exist and repositories answer requests will miss the governance question. Reviewers should trace who can cause a new signed entity to appear, who can prevent it, who can replace the key, who can move publication, who can recover after lockout and who can revoke the certificate. They should compare documented authority with actual credentials, approvals and observed behavior.

Testing should use controlled actions. An auditor can request a routine entity change, inspect approval evidence, retrieve the resulting publication independently and measure convergence. It can begin a rollover, pause before activation and verify that rollback works. It can request a complete export and attempt a provider migration in a test environment. It can simulate an unavailable administrator and confirm that threshold recovery rejects a single claimant.

Repository assessment should include inconsistent views, stale delta state, full-snapshot fallback, expiry pressure and denial of service. Relying parties are diverse, so tests should observe several validator implementations and network locations where possible. The aim is not to guarantee identical refresh times. It is to detect whether an action produces a bounded, explainable convergence rather than hidden divergence.

Parent conduct should be auditable too. Reviewers should sample certificate requests, rejection reasons, urgent actions, resource changes and restoration times. They should look for differential treatment between users of the Society's hosted service and users of outside providers. A parent that processes its own customers faster can turn a necessary hierarchical role into an anticompetitive advantage.

Incident records should connect cause to effect. If an authorization disappeared, the record should distinguish user instruction, key compromise, parent action, repository failure, expiration and validator delay. Each cause calls for a different remedy. Aggregated reporting can then show where the system is fragile without exposing private security details.

Metrics should resist vanity. Uptime alone says little if exports are incomplete or migration takes months. NRS should publish measures such as successful delegated enrollments, median parent-response time, completed rollovers, failed recoveries, migration duration, validation-gap minutes, unauthorized signing incidents, adverse actions reversed on review and provider concentration. Trend and distribution matter more than one favorable average.

Three failure cases expose whether the rights are real

Consider first a medium-sized access provider using a Society-hosted CA. It decides to move to a delegated model after hiring security staff. Under a rights-based design, it generates a key in its own HSM, authenticates a certificate request, establishes publication with an independent repository and rehearses the transition. The old and new state overlap safely, monitors observe convergence, hosted credentials close and the provider retains a complete history. No official needs to decide whether the customer has a sufficiently persuasive reason to leave.

Now change one fact: the hosted service refuses to export useful state and says migration can occur only during an annual maintenance period. The customer may still possess the resource registration, but practical certificate freedom is missing. NRS review should be able to require export, set a coordinated date and supervise continuity. If the Society itself operates the host, the decision must move to an independent body. Institutional legitimacy depends on accepting review of one's own infrastructure.

The second case is a delegated CA whose HSM fails after a flood. Current authorizations remain published and valid for a limited period. The holder activates its threshold recovery group, creates a new key at a secondary site and asks the parent for replacement certification. Independent monitors compare the intended state with publication. Because there is no evidence of compromise, the old and new authority can overlap through a controlled rollover. Recovery succeeds without anyone retrieving an escrowed copy of the failed key.

If evidence instead shows unauthorized signing before the flood, the response changes. The old certificate and every recent entity require review. The parent may need an urgent revocation action, and temporary continuity may be narrower than the prior state. The user still participates through pre-established recovery authorities, but speed and containment take priority over preserving every existing authorization. The event later receives independent review.

The third case is a dispute between a resource holder and a repository provider. The provider alleges unpaid invoices and threatens to stop publication immediately. A normal commercial creditor can pursue payment, but it should not use control of route-security publication as leverage over unrelated networks. Qualification terms should require a continuity period, export, migration cooperation and dispute separation. NRS can permit the user to move publication while the financial claim continues in the proper forum.

Suppose the holder is also in dispute with NRS over membership fees. The same separation should apply. Essential certification and publication continuity should not be withdrawn as an informal collection device. If governing rules authorize resource action for a distinct reason, that action must follow its own evidence, notice and review. Combining billing leverage with parent power would recreate precisely the institutional dominance that user-controlled keys are intended to limit.

These cases demonstrate why custody, portability, recovery and review belong together. A private key in the user's building does not solve repository coercion. Portable publication does not solve parent revocation. Emergency recovery without authentic organizational authority can hand control to an impostor. Each protection addresses a different failure, and the bundle works only when transitions are practiced end to end.

Provider diversity must reduce correlated control, not multiply labels

NRS should not infer resilience from the number of companies listed in a service directory. Several brands can depend on the same HSM operator, cloud account, repository platform, certificate software team or incident contractor. A failure at the shared layer can then affect apparently independent users. Provider qualification should disclose material dependencies to the Society and make concentration visible in aggregate to members.

Dependency mapping should cover control as well as infrastructure. Two repository services may run in different data centers yet rely on one administrator group for privileged changes. A delegated-CA vendor may place every customer's recovery authority in one support desk. A monitoring company may obtain expected state only from the service it is supposed to observe. These arrangements create correlated judgment even when equipment is separate.

The Society should define independence for each purpose. A second publication endpoint provides infrastructure diversity only if it can operate when the first provider is unavailable. A recovery custodian provides organizational diversity only if it cannot be directed by the ordinary operator. An external monitor provides evidentiary diversity only if it retrieves and validates state independently. One organization may still offer excellent service, but it should not be counted twice merely because it uses two product names.

Members need enough disclosure to choose deliberately. Provider descriptions should identify significant subcontracted functions, jurisdictions relevant to service continuity, change-control authority, recovery dependencies, portability terms and recent exercise results. Sensitive security details can remain protected. The public purpose is to reveal concentration and exit risk, not publish an attack guide.

NRS itself should avoid becoming the hidden common dependency. It will necessarily operate or authorize parent functions, and it may run reference services during an early stage. That does not justify making its portal the only authentication channel, its repository the only supported publication location or its support team the sole recovery authority. Reference services should establish interoperability and lower entry costs while leaving space for independent operation.

Procurement can reinforce this separation. Society contracts should use open interfaces, require configuration and evidence export, protect customer ownership of operational records and permit transition assistance by another provider. Custom features that cannot be reproduced elsewhere should receive scrutiny. The cheapest short-term offer may be costly if it makes the institution unable to replace a critical operator.

Concentration limits should focus on consequences rather than arbitrary market shares. If one provider serves most users but every customer can migrate within a tested interval, risk is lower than a smaller provider whose users cannot leave. NRS should combine share data with portability time, common dependencies, recovery performance and the scope of privileged access. A rising concentration indicator can trigger additional exercises, reserve capacity with alternate providers and closer review rather than an automatic ban.

Exit capacity must exist before a dominant service fails. Alternate providers should maintain tested ability to accept customers in waves. NRS can coordinate capacity exercises in which multiple fictional accounts move simultaneously, measuring authentication queues, repository load, support staffing and relying-party effects. A migration procedure proven for one quiet customer may fail when hundreds need it after a common outage.

The Society should also plan for provider acquisition. A merger can combine keys, staff, repositories and customer records under one controller even when contracts remain unchanged. Qualified providers should notify NRS of material control changes, explain their effect on isolation and offer a no-penalty migration period where concentration or jurisdiction changes significantly. Customers should not learn after completion that their independent service has become part of the institution they deliberately avoided.

Competition is not an end in itself. The objective is credible choice under stress. Multiple providers matter because they allow users to escape poor service, reduce correlated failure and challenge institutional assumptions. If users cannot move, if all providers depend on one control center or if the parent favors its affiliated host, market appearance adds little security. Diversity becomes valuable only when authority, infrastructure and evidence can actually separate.

NRS should adopt a certificate-rights charter with measurable acceptance tests

The Society should state certificate rights in a short governing charter and implement them through technical requirements, provider terms and review. The charter should recognize the holder's right to choose hosted or delegated operation, control ordinary signing, appoint qualified providers, obtain timely parent service, move publication, inspect evidence, replace keys, recover authority and challenge adverse action. It should also state the holder's duties to secure credentials, maintain contacts, issue within certified scope, monitor state and cooperate in incident response.

Each right needs an acceptance test. Delegation is proven by independent key generation and successful certification. Control is proven by an approval action the Society cannot perform alone. Portability is proven by migration with bounded validation effects. Recovery is proven by replacement after simulated loss. Parent accountability is proven by reasoned decisions, measured response and effective review. Provider competition is proven by actual customer movement, not a list of vendors.

NRS should phase the model without making delay permanent. It can begin with a reference delegated service, two independent publication providers, published interfaces and supervised migrations. Early users should include small and large holders in different regions. Findings should change requirements before scale increases. Hosted users should receive a clear date by which transition rights and exports are fully available.

The Society should remain skeptical of its own convenience. Central hosting may be efficient, especially at launch. Efficiency is a benefit, not a constitutional argument. If the institution writes the rules, controls the parent, holds most private keys, runs the dominant repository and judges disputes, operational ease has accumulated into governance power. Good intentions do not remove the conflict.

Nor should decentralization be romanticized. Poorly secured keys, abandoned repositories and untrained administrators can weaken routing security. NRS is entitled to require competence, monitoring and recovery. The constraint is that security rules must be proportionate, provider-neutral and curable. They should raise the quality of delegated operation rather than turn every deviation into a reason for central custody.

The final test is practical. A resource holder should be able to answer five questions with evidence: Who can sign now? Who can prevent or revoke that authority? Where is current state published? How can service move? How is safe control restored after loss or compromise? If the answer to all five is one institution, the system has reproduced hosted CA power regardless of the language used to describe it.

User-controlled keys are therefore not an ornamental decentralization feature. They are one part of a wider allocation of rights. Portable publication prevents repository dependence. Emergency recovery makes self-custody survivable. Parent constraints acknowledge the remaining hierarchy. Independent monitoring and review make institutional behavior visible. Supported delegation brings those protections within reach of smaller operators.

The Number Resource Society can make route security stronger without asking members to exchange resource dependence for certificate dependence. Its task is to provide a coherent trust hierarchy while refusing to monopolize every function beneath it. The disciplined position is neither central control nor unsupported self-service. It is user authority backed by interoperable services, tested continuity and narrow, reviewable institutional powers.