摘要

  • NRS 在此主题中的角色是倡导、研究、组织运动、召集和授权成员代表。操作行为属于 RIR 信任锚运营商、授权 RPKI 服务提供商、持有者和依赖方；引用 NRS 的立场既不能作为 NRS 执行这些操作的证据，也不构成 BTW 的认可。
  • 运营商的默认设置应为委托 CA，即资源持有者生成或授权生成其私钥，控制签名权限，并可选择合格的运营支持。托管签名仍是一个选项，而非实际参与的条件。
  • 密钥保管只是证书自由的一部分。持有者还需要及时的父证书服务、可用的发布接口、可导出的签名状态、独立监控以及记录在案的在服务提供商之间转移而不失去路由安全覆盖的权利。
  • 便携式发布应作为普通服务转移进行测试。重叠、存储库同步、清单、撤销材料、依赖方可见性和回滚需要可衡量的验收标准，以便迁移服务不会造成验证缺口。
  • 紧急恢复不应依赖于常规密钥托管。离线恢复凭证、多方授权、预先商定的替换密钥程序以及范围狭窄的连续性操作可以恢复控制，同时将常规签名留在持有者手中。
  • 用户控制的从属密钥不会消除父 CA。运营商的规则必须通过通知、证据、快速审查和补救措施来约束延迟签发、选择性撤销、存储库阻碍、无解释的资源削减以及其他不利行为。
  • 小型运营商需要支持的委托：托管硬件、仪式、健康检查、培训以及用户安全域内的合同操作。有意义的区分在于谁控制权力和退出，而不是谁实际输入每条命令。
  • 设计应通过可观察的实践来判断：独立密钥生成、常规轮换、发布提供商迁移、泄露恢复、父争议和依赖方收敛。无法通过这些测试的权利只是描述性的承诺，而非操作性的权利。

角色边界是证据的一部分

NRS 自身的定位为本分析提供了第一层边界。它是一个倡导去中心化、退出、可移植性、冗余和更少自由裁量瓶颈的会员和倡导组织。卢恒关于 NRS 存在原因的说明直接指出，NRS 不销售产品或实施商业解决方案；其作用是改变治理方向。因此，NRS 可以发布研究、组织运动、召集受影响的运营商、支持成员并代表已授予其授权的组织。但不能将该代表权转化为对任何其他人的注册机构权力。

实施层是分开的。RIR 信任锚运营商、授权 RPKI 服务提供商、持有者和依赖方仍然对任何权威注册记录、分配、转移认可、RPKI 或 RDAP 操作、技术故障转移、约束性审查、破产行为或与本文章相关的法律强制补救措施负责。NRO 协调五个 RIR；它不是 NRS 的另一个名称。IANA 编号服务执行其定义的协调角色；它们不是 NRS 的部门。法院和合法公共权力机构保留其法律体系实际赋予它们的权力。

BTW 的角色又是分开的。BTW 报告可观察的结构，检查一手来源，并将提案标注为提案。它不会将 NRS 的倡导转化为事实，也不会代表 NRS 进行运动，也不会从一致性中推断权威。这种现实而非倡导的纪律是本文章中机构名词重要的原因：NRS 的建议、RIR 的行为和法院的命令是三件不同的事情。

RPKI 的权威即使在一个服务使其看起来统一时也是分散的

资源公钥基础设施通常通过一个简单的产品选择向运营商呈现：使用托管服务或运行委托 CA。这种描述有用但不完整。其下有多种权力。父 CA 认证子项的资源持有。子项控制私钥并发布签名产品。存储库使证书、撤销信息、清单和路由源对象可用。依赖方检索并验证这些产品。运营门户验证请求，并可能代表客户执行签名。

当一个机构执行所有这些功能时，用户的体验可能很顺畅。但也可能掩盖权力所在。用户可能会点击授权一个源，而服务生成并保留相关的私钥。同一机构可能决定如何验证请求、何时发布对象、如何恢复账户以及是否允许导出。客户有服务关系，但不一定具有独立可用的认证能力。

这种区别很重要，因为路由安全权威可以影响实际连接。路由源授权本身不会指挥路由器；依赖网络决定是否以及如何使用验证状态。然而，广泛验证使签名状态具有实际后果。不正确的撤销、过时的发布、过宽的授权或泄露的密钥可能影响路由的分类。因此，集中常规签名和恢复造成了治理依赖，即使正式资源注册保持不变。

相关标准并不要求每项功能由一个运营商控制。RFC 6480 中描述的 RPKI 架构建立了一个与互联网号码资源关联的层次结构。RFC 6487 中的证书概要限制了资源证书表达权威的方式。签名对象和存储库标准定义了产品如何可用和验证。证书注册和发布协议支持跨组织边界的交互。这种模块化不仅仅是工程便利。它为机构选择提供了空间。

注册机构运营商应有意利用这一空间。资源识别、父认证、子签名、存储库操作和依赖方验证应在政策、合约、审计和事件响应中保持分离。提供商可以提供多种功能，但合并它们不应消除用户以后将其分开的权利。机构应为其行使的每项权力提供正当理由，而不是因为客户喜欢便利的界面而继承广泛授权。

对自满的最大警告来自层次结构本身。控制其私钥的子项并非主权。其父项可以拒绝重新签发证书、在政策允许的情况下减少认证资源、撤销证书或未能支持及时轮换。存储库运营商可以延迟或错误处理发布。依赖方可以保留过时材料，直到刷新和过期规则解析。因此，目标不是一种浪漫的主张，即拥有密钥就消除了依赖。而是一种宪政式的依赖分配：每个参与者获得所需的最小权力，每项权力都有证据、时限和审查。

用户持有的密钥应成为普遍默认

默认安排应从资源持有者控制的安全边界中生成密钥开始。该边界可以是持有者场所的硬件安全模块、持有者账户中的专用云安全服务、离线设备或根据合同管理的设备。具体设备应反映风险和规模。重要的是持有者能够授权使用、更换提供商、获取密钥操作的证据，并防止注册机构运营商单方面行使常规签名权力。

生成密钥还不够。控制意味着持有者决定谁可以激活它、在什么批准规则下、用于哪些签名产品、附带什么审计记录以及在哪个时间段。大型地址持有者可能适合双人规则。较小的运营商可以使用一个负责的管理员加上一个独立的恢复联系人。高风险操作，如广泛的路由授权或疑似泄露后的更换，需要比常规续期更强的批准。

注册机构运营商应发布委托保管的基线，而不规定一种昂贵的设备。基线应涵盖熵、支持的算法、安全备份、访问日志、职责分离、撤销准备、时间同步、管理员变更、受保护的恢复材料和处置。应区分强制性安全结果与可选实施模式。运营商应能够证明所需的控制，而无需从偏爱的供应商购买。

当操作外包时，用户保管的默认也应适用。管理安全公司可以管理 HSM、安排签名和监控发布。如果用户控制账户、批准策略和替换权利，这仍然可以是委托操作。相反，标记为“客户管理”的设备如果只有提供商可以导出配置、批准新管理员或切换发布，则提供的独立性很小。治理应检查实际权威而非营销描述。

一些组织会选择托管签名。他们可能缺乏人员、只运营小规模资源集或看重简单服务。注册机构运营商应通过强认证、可见批准和衡量的服务质量来支持这一选择。但托管用户应获得明确的升级路径。他们应能建立自己的密钥、获得必要的从属证书关系、移动发布、验证依赖方可见性，并在没有惩罚性费用或自由裁量延迟的情况下关闭托管签名。

默认规则塑造市场。如果委托操作需要特殊批准、冗长谈判或专门个人联系，托管控制将成为事实规范，即使政策称其为可选。注册机构运营商应扭转这一负担。符合要求的委托请求应是例行公事。任何拒绝都应指明具体的安全或授权缺陷，说明如何修复，并允许快速独立审查。注册机构运营商可以执行技术要求；它不应使用这些要求来保护自己的服务份额。

同样的原则适用于密钥证据。用户应收到密钥创建、证书请求、证书签发、对象签名、撤销和轮换的可验证记录。这些记录应在审计或争议中有用，而不暴露私钥。如果提供商执行仪式，用户应收到足以显示发生什么的证明和日志。证据应在服务变更时随客户转移。

证书权利是一揽子权利，而非单一保管主张

称密钥为“用户控制”可能成为口号，除非相关权利得到明确。第一项权利是生成或独立授权生成。第二项是排他性常规使用：注册机构运营商和提供商都不能仅仅因为其操作基础设施就创建新的签名产品。第三项是通过可靠记录进行检查。第四项是通过正常轮换和紧急泄露程序进行更换。第五项是在提供商之间移动。第六项是终止并安全退役旧权威。

一揽子权利必须包括及时的父服务。如果父项忽略证书请求、延迟更改或拒绝合理的替换密钥，子项无法无限维持有效的认证。注册机构运营商应为常规签发、计划轮换、资源变更和紧急泄露设定服务目标。时间应从完整的认证请求开始计算。如果请求有缺陷，响应应指明缺陷，而不是重新启动不透明的队列。

还必须包括对发布的访问。子 CA 正确签名但不能使产品可靠可用，并不拥有有用的独立性。持有者应能选择合格的存储库提供商、在适当情况下运营自己的合规存储库、并检索完整的当前清单。存储库条款不应使持续发布依赖于无关的会员争议或商业服务。

数据可移植性是另一项权利。持有者应能导出公共证书、签名对象、清单、撤销产品、存储库路径、相关时间信息、配置和审计历史，格式应有文档说明。私钥可能设计为不可导出，尤其是在硬件中，但这不应困住用户。替换密钥和协调过渡必须仍然可能。不可导出性可以保护密钥；但不能证明认证关系的不可移植性。

一揽子权利包括独立观察。用户不应信任执行操作的同一个仪表板。外部监控器应像依赖方一样检索存储库，验证资源链，比较预期和观察到的产品，并在消失、不一致、意外源更改或即将过期时发出警报。注册机构运营商应支持标准化提要或通知，以便持有者和第三方监控器快速检测不利变化。

最后，证书权利需要补救措施。服务被延迟或阻碍的用户应有一个了解路由后果的快速通道。审查应能命令发布恢复、临时连续性措施、纠正签发或保留状态。财务补偿可能以后重要，但不替代快速技术纠正。只有在相关证书过期后才能实现的权利不是有效的权利。

发布必须在事实上可移植，而不仅仅是合同中

存储库可移植性是名义自由最可能失败的地方。发布涉及名称、位置、同步、清单、证书和撤销状态、获取行为以及依赖方缓存。从用户门户看起来完全的移动仍可能在验证者中造成不一致视图。因此，注册机构运营商应将迁移定义为一个有准备、重叠、观察和关闭的可衡量技术事件。

在移动之前，退出提供者应提供完整的清单和近期操作历史。进入提供者应验证其能否发布所有必需的当前产品并维持必要的可用性。子项应根据适用标准准备新的清单和其他时间敏感材料。父项和子项引用应被检查。监控应在多个独立检索点建立基线。

过渡应避免两个存储库都不提供可用状态的时刻。确切顺序取决于证书和存储库设计，但管理要求很明确：旧和新安排需要有界重叠或其他符合标准的方法，在引用更改时保持验证。运营商应模拟在不同时间刷新的依赖方。成功不能仅仅因为新端点响应一个测试请求而宣布。

RFC 8181 的发布协议和 RFC 8182 的存储库增量机制说明了为什么服务边界和检索行为值得单独关注。发布接口可以让 CA 向它不运营的存储库提交产品。增量检索可以改善依赖方的高效同步。但这两个协议本身都不能保证机构可移植性。凭证、存储库引用、服务条款、历史状态、监控和协调变更仍需治理。

注册机构运营商应要求合格提供商通过共同程序接受和释放客户。资格应测试协议合规性、可用性、一致性、事件响应、导出完整性和迁移合作。应禁止声称拥有客户证书或签名产品所有权的合同条款。退出费用应反映合理工作，而非困住用户的战略价值。

迁移演练应在紧急情况前进行。持有者可以每年进行一次测试，创建非生产子环境，在服务之间移动，并验证独立验证。大型持有者可以隔更长时间进行一次受控生产过渡。提供商应参与注册机构运营商范围的演练，包括缓慢、不可达或财务困难的退出运营商。关键是发现隐藏的依赖关系，同时还有时间。

回滚同样值得关注。如果进入服务发布了不一致的状态，必须有一种有界的方式恢复最后已知的良好安排，而不产生冲突的权威。回滚标准应在移动前决定：来自多个监控器的验证失败、丢失关键对象、超过定义间隔的差异或无法刷新。一个负责任的迁移领导者应协调行动，而独立观察员记录依赖方实际看到的内容。

关闭应退役不再需要的凭证和引用，确认退出服务不能接受新提交，保留所需的审计证据，并通知持有者剩余保留。退出提供者不得在过渡后保留发布的能力。也不应删除解释先前状态所需的证据。安全需要同时移除过时权力和保留可问责历史。

可移植性指标应在总体中公开。注册机构运营商可以报告迁移时间的中位数和最差情况、观察到的验证缺口、回滚频率、不完整导出、提供商造成的延迟和按严重性分类的事件。可比证据为成员选择服务提供了基础。它也能揭示一个形式上竞争的存储库市场是否真正开放，还是由一个客户无法安全离开的提供商主导。

紧急恢复应恢复权威而不创造永久托管

密钥丢失和泄露是不可避免的设计案例，而非罕见例外。运营商可能失去对 HSM 的访问、解雇管理员、遭受灾难、发现未经授权签名或被锁定在云账户外。坚持用户持有密钥但不提供可靠恢复的治理模型将推动用户回到集中托管。通过常规中央托管解决恢复的模型以另一个名称重新创造了同样的集中。

注册机构运营商应优先替换密钥而非恢复同一私钥。如果密钥疑似泄露，恢复副本也会恢复攻击者的权力。安全目标是认证持有者、建立新密钥、获得适当的父认证、撤销或退役旧证书、发布连贯的当前状态并验证依赖方收敛。旧私钥不应被视为必须始终可恢复的宝藏。

计划中的恢复凭证可以支持这一过渡。在注册时，持有者可以指定多个恢复权威，例如两名高管和一位独立安全联系人，每人持有受保护凭证。没有任何一方应拥有足够的权力来替换密钥。阈值批准可在身份、角色和资源证据检查后授权替换请求。阈值记录应在人员变动时更新并定期测试。

离线恢复材料可以保存在分离的位置，处于防篡改控制下。对于某些组织，这可能包括在保管人之间分割的加密备份。对于其他组织，特别是密钥故意不可导出的，可能包括授权新密钥仪式而非签名密钥副本的凭证。注册机构运营商应根据风险定义结果和证据，同时允许两种模式。

紧急权威必须狭隘。连续性受托人或注册机构运营商安全功能可能被允许促进认证、保持存储库可用性并请求临时父操作。但不应获得为用户资源发布路由授权的无限制能力。任何临时签名状态都应是预授权的、最小允许的、短暂的，并对持有者和独立审查员可见。在没有安全临时状态的情况下，决策应明确，而非伪装成常规管理。

恢复序列应对事件进行分类。没有泄露证据的丢失可以允许在重叠期间维持常规授权的受控轮换。疑似泄露需要更快的撤销分析和仔细检查每个最近签名的产品。组织控制争议需要谨慎：技术团队不应仅仅因为一方拥有设备就选择公司派系。法律无力或解散可能调用与认可资源权威相关的单独连续性规则。

时间目标应与路由风险匹配。影响活跃路由的疑似未授权授权可能需要数小时内采取行动。在安全间隔内当前产品有效的离线密钥丢失可能允许更从容的仪式。注册机构运营商应按事件类别发布目标时间并衡量绩效。紧迫不应消除认证，但认证应在危机前设计好，而非在危机中发明。

每项紧急行动都需要事后审查。记录应显示谁发起了行动、什么证据支持权威、哪些产品发生变化、临时措施持续多久、用户何时恢复控制以及依赖方观察到什么。审查应同时检查假阴性和假阳性。拒绝真正的持有者可能延长风险；接受冒充者可能转移有效的路由权威。恢复设计必须面对这两种错误。

注册机构运营商还应提供安全演练。参与者可以在隔离环境中模拟丢失、管理员离职和签名泄露，然后执行替换和发布检查。通过正常操作但无法支持恢复演练的提供商不应被视为完全合格。恢复是服务的一部分，而非特殊恩惠。

父 CA 仍然强大，必须相应得到治理

委托改变了常规签名的位置，但父项仍然锚定从属证书。这一事实应明确说明。父项可以通过在无充分依据时撤销、未能续期、认证不正确的资源集、延迟替换密钥或发布不一致的撤销状态来伤害用户。庆祝用户保管而忽视父项权力的政策会错误描述风险。

RFC 8211 检查了 CA 或存储库经理的不利行为，并与机构设计特别相关。技术架构无法使每个敌对或错误行为都不可能。治理必须减少机会、改进检测、约束自由裁量权并提供恢复。注册机构运营商应将父干预视为定义权威的可问责行使，而非运营根或中间服务的不可审查属性。

常规父操作应针对权威资源记录和认证请求自动化，具有透明状态和独立监控。手动自由裁量权应保留用于已识别的例外。如果证书请求被拒绝，用户应收到原因代码、所依赖的证据以及纠正路径。如果注册机构运营商认为需要紧急安全行动，应记录范围、预期期限和批准依据。

高影响不利行动应要求职责分离。调查疑似泄露的人不应单独授权撤销和控制审查记录。双人或委员会批准可以减少错误，而紧急规则可以允许立即临时行动，随后快速独立确认。标准应识别哪些事件证明该例外是合理的，以及确认必须多快发生。

通知很重要但不是绝对的。提前通知适用于计划过期、资源变更和非紧急合规问题。在回应确认的密钥泄露之前，提前通知可能不安全。即使如此，同步通知应通过独立渠道进行，除非这样做会明显加剧损害。沉默不应成为默认，仅仅因为技术工作人员将证书管理视为内部事务。

审查需要技术能力和快速行动能力。数周后才会面的普通会员上诉对于实时路由安全问题是不够的。注册机构运营商应维持一个独立小组，能够检查资源权威、证书状态、存储库证据和运营影响。应能命令恢复、替换、纠正或临时连续性，同时更广泛的争议继续进行。

补救措施应保持认证和资源权利之间的区别。纠正不正确的证书撤销并不决定每个合同主张。反之，持有者不能使用从属密钥来击败在治理规则下认可的合法转移或资源变更。证书服务应反映权威资源状态，关于该状态的争议应通过适当的权利程序解决，并带有连续性保护。

透明度可以阻止滥用而不暴露可利用的细节。注册机构运营商应报告紧急撤销、延迟签发、有争议的资源削减、存储库中断和审查结果的数量和类别。重大事件应在即时风险过去后接受公开解释。敏感认证证据可以保持受保护。成员需要足够的信息来判断特殊权力是否罕见、有正当理由，并在错误时得到纠正。

密钥生命周期职责应具体且可测试

控制是在生命周期中维持的，而非在注册时一次建立。密钥生成应使用批准的算法和安全随机性。认证请求应将密钥绑定到认证持有者。激活应确认发布和独立验证。常规操作应续期时间敏感产品、监控存储库并限制管理员权限。轮换应在密钥弱点或设备故障造成紧迫性之前替换密钥。退役应撤销或过期权威，并安全处置过时秘密。

算法敏捷性是此职责的一部分。RFC 6916 描述了 RPKI 的算法敏捷性程序，反映了随时间改变密码算法的需求。注册机构运营商应避免使此类变更依赖于一个供应商硬件日程的保管模式。资格应测试服务能否引入支持的算法、运行必要的重叠、更新依赖方预期并退役旧材料，而不强迫用户放弃控制。

常规轮换是恢复将起作用的最佳证据。能够生成新密钥、获得认证、发布连贯状态并观察依赖方收敛的持有者已经同时展示了几个关键权利。注册机构运营商应设定轮换间隔或基于风险的预期，同时避免不必要的更替。演练应有足够记录，以区分完成的过渡和门户状态消息。

授权内容也需要治理。用户保管不应意味着无约束或粗心的签发。接口应验证资源范围、前缀长度、源身份和过期。风险变更可以在持有者自身的批准政策内接受额外审查。工具应显示移除或缩小授权的可能效果，并应警告冲突的当前对象。持有者控制决策，但良好的设计减少可避免的错误。

短有效期可以限制暴露，但增加对可靠续期和发布的依赖。长有效期减少续期压力，但可能使过期权威仍然有效。注册机构运营商应设定平衡的概览，并使权衡可见。紧急程序不应依赖每个依赖方立即刷新。测试应包括具有现实轮询、缓存和故障行为的验证器。

管理员生命周期应与密码生命周期一样严格。离职员工应立即失去访问权限。恢复联系人应重新确认。特权操作应使用强认证和独立通知。高风险操作应禁止共享账户。技术上安全的 HSM 如果前员工仍能通过被忽视的门户批准其使用，就不能保护权威。

支持的委托可以服务小型运营商而不剥夺其权利

对用户持有密钥的最强烈实际反对是能力不平等。大型网络可以雇佣安全工程师并运营冗余硬件。小型持有者可能只有一名网络管理员，对证书维护兴趣不大。如果委托仅为最大的成员设计，托管控制将保持主导，权利将是形式上的而非广泛可用的。

注册机构运营商应建立支持的委托服务类别。提供商可以提供配置好的硬件、管理仪式、监控发布、续期提醒、事件支持和定期演练。用户保留安全账户的所有权或决定性控制权，设定批准政策，并拥有指定新提供商的能力。提供商在可终止而不失去认证关系的文档任务下运营。

成本应透明且可比较。基本委托操作不应需要定制法律谈判。标准服务描述可以说明哪方控制 HSM 账户、谁可以发起签名、谁批准高风险操作、如何导出记录、发布如何移动以及恢复如何工作。客户应能在权威和退出方面比较两个提供商，而不仅仅是价格和正常运行时间。

共享基础设施仍可保持分离。提供商可以在认证硬件上托管许多逻辑安全域，前提是每个客户的密钥和批准是隔离的，特权访问受到控制，且一个客户不能影响另一个。独立评估应测试技术隔离和运营实践。注册机构运营商不应假装共享硬件本身不可接受或不安全。

培训应侧重于决策而非将每个持有者变成密码学家。管理员需要理解路由授权的作用、密钥泄露与账户丢失的区别、何时请求轮换、如何验证发布以及联系谁。演练可以揭示组织权威是否最新。简洁、排练充分的程序比没人用过的长手册更有价值。

补贴可能对小型或公共利益网络合理，如果成本否则会迫使集中保管。资金应跟随用户，并可在多个合格提供商处使用。给予注册机构运营商运营的一个主机价格优势会破坏运营商试图创造的市场。支持应扩大选择，而非将财务援助转化为技术依赖。

托管服务本身应满足反锁定标准。用户应看到每个活跃授权、接收独立通知、导出历史、指定恢复联系人并演练向委托的过渡。服务不应将注册机构运营商描述为密钥权威的所有者，仅仅因为它执行签名。托管操作是在明确限制内为认可持有者行使的受托类技术角色。

审计应检查有效控制和依赖方结果

仅检查密钥是否存在和存储库是否响应请求的审计将错过治理问题。审查员应追踪谁可能导致新签名对象出现、谁可以阻止它、谁可以替换密钥、谁可以移动发布、谁可以在锁定后恢复以及谁可以撤销证书。他们应将文档化的权威与实际凭证、批准和观察到的行为进行比较。

测试应使用受控操作。审计员可以请求常规对象变更、检查批准证据、独立检索结果发布并测量收敛。可以启动轮换，在激活前暂停并验证回滚有效。可以请求完整导出并在测试环境中尝试提供商迁移。可以模拟不可用的管理员并确认阈值恢复拒绝单一索赔人。

存储库评估应包括不一致视图、过时增量状态、完整快照回退、过期压力和拒绝服务。依赖方多样，因此测试应在可能的情况下观察多个验证器实现和网络位置。目标不是保证相同的刷新时间。而是检测操作是否产生有界、可解释的收敛而非隐藏分歧。

父行为也应可审计。审查员应抽样证书请求、拒绝原因、紧急行动、资源变更和恢复时间。应寻找注册机构运营商托管服务用户与外部提供商用户之间的差别对待。更快处理自身客户的父项可以将必要的层级角色转化为反竞争优势。

事件记录应将原因与结果联系起来。如果授权消失，记录应区分用户指令、密钥泄露、父行动、存储库故障、到期和验证器延迟。每个原因需要不同的补救措施。汇总报告可以在不暴露私密安全细节的情况下显示系统的脆弱点。

指标应抵制虚荣。仅正常运行时间说明不了什么，如果导出不完整或迁移需要数月。注册机构运营商应发布诸如成功委托注册、父响应时间中位数、完成轮换、失败恢复、迁移持续时间、验证缺口分钟数、未授权签名事件、审查后撤销的不利行动和提供商集中度等指标。趋势和分布比一个有利的平均值更重要。

三个失败案例揭示权利是否真实

首先考虑一个使用注册机构运营商托管 CA 的中型接入提供商。在雇佣安全人员后，它决定转向委托模式。在基于权利的设计下，它在自己的 HSM 中生成密钥，认证证书请求，与独立存储库建立发布，并演练过渡。旧状态和新状态安全重叠，监控器观察到收敛，托管凭证关闭，提供商保留完整历史。无需官员决定客户是否有足够有说服力的理由离开。

现在改变一个事实：托管服务拒绝导出有用状态，并说迁移只能在年度维护期间进行。客户可能仍持有资源注册，但实际证书自由缺失。独立注册机构审查应能要求导出、设定协调日期并监督连续性。如果注册机构运营商本身运营主机，决策必须移交给独立机构。机构合法性取决于接受对自己基础设施的审查。

第二个案例是一个委托 CA，其 HSM 在洪水后出现故障。当前授权保持发布并在有限期限内有效。持有者激活其阈值恢复组，在辅助站点创建新密钥，并请求父项进行替换认证。独立监控器将预期状态与发布进行比较。由于没有泄露证据，旧权威和新权威可以通过受控轮换重叠。恢复成功，无需任何人检索故障密钥的托管副本。

如果证据相反显示洪水前存在未授权签名，响应会改变。旧证书和每个近期对象都需要审查。父项可能需要紧急撤销行动，临时连续性可能比先前状态更窄。用户仍通过预先建立的恢复权威参与，但速度和遏制优先于保留每个现有授权。事件随后接受独立审查。

第三个案例是资源持有者与存储库提供商之间的争议。提供商声称未付发票并威胁立即停止发布。正常商业债权人可以追讨付款，但不应使用对路由安全发布的控制作为对不相关网络的杠杆。资格条款应要求连续期、导出、迁移合作和争议分离。注册机构运营商可以允许用户在金融索赔在适当论坛继续的同时移动发布。

假设持有者还与注册机构运营商就会费发生争议。同样的分离应适用。基本认证和发布连续性不应作为非正式催收工具被撤销。如果治理规则因不同原因授权资源行动，该行动必须遵循其自身的证据、通知和审查。将计费杠杆与父权力相结合将重新创造出用户控制密钥旨在限制的机构主导地位。

这些案例表明保管、可移植性、恢复和审查应在一起。用户建筑物中的私钥不能解决存储库胁迫。可移植发布不能解决父项撤销。没有真实组织权威的紧急恢复可能将控制交给冒充者。每项保护针对不同的失败，一揽子权利只有在端到端演练过渡时才有效。

提供商多样性必须减少相关控制，而非增加标签

注册机构运营商不应从服务目录中列出的公司数量推断弹性。几个品牌可能依赖相同的 HSM 运营商、云账户、存储库平台、证书软件团队或事件承包商。共享层的故障随后会影响看似独立的用户。提供商资格应向注册机构运营商披露重大依赖，并使集中度在总体上对成员可见。

依赖映射应涵盖控制和基础设施。两个存储库服务可能运行在不同的数据中心，但依赖一个管理员组进行特权更改。委托 CA 供应商可能将所有客户的恢复权威放在一个支持台。监控公司可能仅从它应该观察的服务中获取预期状态。这些安排创造了相关的判断，即使设备是分开的。

注册机构运营商应为每个目的定义独立性。第二个发布端点只有在第一个提供商不可用时才能运行，才提供基础设施多样性。恢复保管人只有在不能被普通运营商指示时，才提供组织多样性。外部监控器只有在独立检索和验证状态时，才提供证据多样性。一个组织仍可能提供优秀服务，但不应仅因为使用两个产品名称就被重复计数。

成员需要足够的披露以有意识地选择。提供商描述应识别重要的分包功能、与服务连续性相关的司法管辖区、变更控制权威、恢复依赖、可移植性条款和近期演练结果。敏感安全细节可以保持受保护。公共目的是揭示集中度和退出风险，而非发布攻击指南。

注册机构运营商本身应避免成为隐藏的公共依赖。它必然会运营或授权父功能，并且可能在早期阶段运行参考服务。但这并不证明其门户是唯一认证渠道、其存储库是唯一支持的发布位置或其支持团队是唯一恢复权威。参考服务应建立互操作性并降低进入成本，同时为独立操作留出空间。

采购可以加强这种分离。注册机构运营商合约应使用开放接口、要求配置和证据导出、保护客户对操作记录的所有权，并允许另一提供商提供过渡协助。其他无法复制的自定义功能应受到审查。最便宜的短期报价可能成本高昂，如果它使机构无法更换关键运营商。

集中度限制应关注后果而非任意市场份额。如果一个提供商服务大多数用户，但每个客户可以在测试间隔内迁移，风险比用户无法离开的较小提供商低。注册机构运营商应将份额数据与可移植时间、公共依赖、恢复性能和特权访问范围相结合。上升的集中度指标可以触发附加演练、与替代提供商的储备能力以及更密切的审查，而非自动禁令。

退出能力必须在主导服务失败前存在。替代提供商应保持经过测试的接纳客户浪潮的能力。注册机构运营商可以协调容量演练，其中多个虚构账户同时移动，测量认证队列、存储库负载、支持人员和依赖方效应。为一个安静客户验证的迁移程序在数百人需要时可能在公共故障后失败。

注册机构运营商还应为提供商收购做计划。合并可以将密钥、员工、存储库和客户记录置于一个控制者之下，即使合约保持不变。合格提供商应通知注册机构运营商重要的控制变更，解释其对隔离的影响，并在集中度或司法管辖区发生重大变化时提供无惩罚迁移期。客户不应在完成后才发现他们的独立服务已成为他们刻意避免的机构的一部分。

竞争本身不是目的。目标是在压力下的可信选择。多个提供商之所以重要，是因为它们允许用户逃避差劲服务、减少相关故障并挑战机构假设。如果用户不能移动，如果所有提供商依赖一个控制中心，或者如果父项偏向其附属主机，市场外观增加不了什么安全。只有当权威、基础设施和证据确实可以分离时，多样性才变得有价值。

注册机构运营商应采纳证书权利章程，附带可衡量的验收测试

注册机构运营商应在一个简短的管理章程中陈述证书权利，并通过技术要求、提供商条款和审查来实现。章程应承认持有者选择托管或委托操作、控制常规签名、指定合格提供商、获得及时父服务、移动发布、检查证据、替换密钥、恢复权威和挑战不利行动的权利。还应说明持有者保护凭证、维护联系人、在认证范围内签发、监控状态和配合事件响应的义务。

每项权利都需要验收测试。委托通过独立密钥生成和成功认证来证明。控制通过注册机构运营商无法单独执行的批准行动来证明。可移植性通过具有有界验证效应的迁移来证明。恢复通过模拟丢失后的替换来证明。父问责通过有理有据的决策、衡量的响应和有效审查来证明。提供商竞争通过实际客户移动而非供应商列表来证明。

注册机构运营商应分阶段实施模型，而不使延迟永久化。可以从参考委托服务、两个独立发布提供商、发布的接口和受监督的迁移开始。早期用户应包括不同区域的小型和大型持有者。发现应在规模扩大前改变要求。托管用户应收到过渡权利和导出完全可用的明确日期。

注册机构运营商应对自己便利保持怀疑。中央托管可能高效，尤其是在启动时。效率是好处，不是宪法论据。如果机构制定规则、控制父项、持有大多数私钥、运营主导存储库并判断争议，运营便利已累积成治理权力。良好意图并不能消除冲突。

也不应浪漫化去中心化。安全措施差的密钥、废弃存储库和未经培训的管理员可能削弱路由安全。注册机构运营商有权要求能力、监控和恢复。约束是安全规则必须是相称的、提供商中立和可纠正的。它们应提高委托操作的质量，而非将每个偏差转变为中央保管的理由。

最终测试是实际的。资源持有者应能用证据回答五个问题：现在谁能签名？谁能阻止或撤销该权威？当前状态在哪里发布？服务如何移动？丢失或泄露后如何安全恢复控制？如果所有五个问题的答案都是一个机构，那么系统已经复制了托管 CA 的权力，无论用什么语言描述。

因此，用户控制密钥不是装饰性的去中心化功能。它们是更广泛权利分配的一部分。可移植发布防止存储库依赖。紧急恢复使自我保管可存活。父约束承认剩余的层级。独立监控和审查使机构行为可见。支持的委托将这些保护置于小型运营商可及范围内。

注册机构运营商可以使路由安全更强，而不要求成员用证书依赖替换资源依赖。其任务是提供连贯的信任层级，同时拒绝垄断其下的每个功能。纪律立场既不是中央控制，也不是无支持的自主服务。而是用户权威，由可互操作服务、经过测试的连续性和狭隘、可审查的机构权力支持。

NRS 和 BTW 角色来源