摘要

  • 全球 RPKI 并非字面意义上建立在单一通用信任锚之上。依赖方软件通常使用 AFRINIC、APNIC、ARIN、LACNIC 和 RIPE NCC 的 TAL。但给定资源的有效认证路径通常终止于一个公认的权威机构，因此运行多个验证器并不会为该资源创建多个独立的签发者。
  • 验证器多样性是有价值的。独立的代码库可能包含不同的解析器缺陷、内存安全故障、传输行为、缓存策略和发布周期。单独的实例还降低了一次进程故障或维护事件导致网络可用验证源全部消失的概率。
  • 每个符合规范的验证器仍然在其配置的信任锚所赋予的权威范围内评估签名对象。如果已被接受的父 CA 撤销了子证书、从中移除资源或颁发了竞争性证书链，验证器应识别由此产生的加密状态，而不是对父 CA 的行为是否明智进行投票。
  • 存储库和传输多样性可以提高可用性，但镜像无法制造权威。完美复制的恶意证书或撤销仍然是恶意的，而来自独立镜像的未签名更正并非有效替代。
  • 验证器输出之间的多数投票并非制度性上诉。两个过期的缓存可能比一个当前缓存获得更多票数；两个实现可能共享一个库或解释；而一个真实的权威变更可能首先表现为分歧。运营商需要解释每个差异的证据，而不是简单的计数。
  • 信任锚的韧性属于权威层：保护密钥保管、分权批准、公开轮换计划、后续密钥分段、独立观察、范围限定的证书变更、有理由的决策、上诉和连续性安排。RFC 9691 使计划中的信任锚密钥更安全，但明确不保护当前信任锚私钥被泄露的情况。
  • 本地例外（如 SLURM）可以在不利行动期间保留运营商的自主权，但它们是本地的，可能使验证视图碎片化。它们是应急控制措施，而非替代全球权威或自动解决争议注册局决策的方法。
  • 号码资源协会可以倡导信任锚收据、密钥仪式证据、变更通知、质询程序和验证器比较报告。RIR 认证机构和授权技术运营商仍然对密钥、证书和存储库负责；NRS 不得将软件多样性或其自身倡导作为权威已分散的证据进行推销。

多样性在第一个决策做出之后开始

RPKI 验证器并非通过检查 BGP 并选择其认为有说服力的机构来发现权威。它从运营商配置的信任锚材料开始。信任锚定位器提供位置和一个公钥，用于检索和认证自签名证书授权证书。从这个被接受的起点开始，验证器遵循证书路径，检查资源扩展、清单、撤销列表和签名对象，并派生出经过验证的有效负载。

用不同语言编写的两个验证器可以独立地执行该工作。一个可能会拒绝格式错误的编码，而另一个可能错误地处理。一个可能会在存储库中断后恢复，而另一个可能会崩溃。一个可能会清晰地暴露过期的清单，而另一个可能会产生不太有用的错误。这些差异之所以重要，是因为存储库内容是不可信的输入，而验证面很复杂。

但验证器不会独立决定谁是最終的签发者。如果两者都配置了相同的 TAL 公钥，则两者都接受相同的信任锚作为其证书所描述资源的起始权威。对于后代对象在语法或密码学上是否有效，它们可能有不同意见。如果它们对输入和标准达成一致，它们不应仅仅因为一个偏好持有者而另一个偏好父 CA 而产生分歧。

因此，机构集中的问题在于实现的上游。验证器可以证明一个对象在规定的规则下源自已接受的根。它不能证明根的治理是公平的，不能证明强制撤销是相称的，也不能证明注册局的持有者记录反映了每一个私人法律利益。密码学验证回答的是一个更窄的问题。

这就是为什么一个购买三个验证器产品的采购计划可能夸大了去中心化。它为单一配置的权威创建了三个计算见证。这是一项有用的韧性，但不是三个独立的认证权力来源。

五个区域锚不会给每个前缀五个独立投票权

生产级依赖方软件通常包含五个区域互联网注册机构的信任锚定位器：AFRINIC、APNIC、ARIN、LACNIC 和 RIPE NCC。RFC 8897 指出，每个依赖方选择其信任锚，并将 IANA 和五个 RIR 标识为与号码资源分配层次结构一致的明显默认候选。Routinator 和 FORT 文档显示了普通配置中的五个 RIR TAL。

该结构比由一个组织运营的一个全球根更加分散。局限在一个区域树中的故障不需要使仅在另一个区域下认证的资源失效。区域社区、合同和治理也有所不同。任何声称整个 RPKI 只有字面上的一个信任锚的分析都是错误的。

当分析单位变成资源时，集中化再次出现。一个前缀通常位于从其分配所覆盖的信任锚下降的认证路径中。其持有者不能因为运营商运行了三个验证器而要求三个无关的 RIR 根为其颁发三个同等权威的证书。在合法的跨区域过渡期间，路径可能会暂时改变或重叠，但这是一个受控的例外，而不是例行的多根投票。

因此，软件多重性在依赖方层面水平运行，而认证权威是垂直组织的。例如，多个验证器可以遍历 APNIC 树，但它们不会将 APNIC 的根决策转变为五个区域决策。如果一个资源移动到另一个区域，权威路径会通过转移安排发生变化；验证器数量不会导致移动。

这种区分允许更精确的风险陈述。全球系统具有区域分离。然而，在一个资源的有效路径内，父权威可能会影响依赖于它的每一个后代对象。CA 证书撤销可能导致依赖方使下属签名对象无效。独立的验证器可能以令人钦佩的一致性确认该结果。它们的一致赞同展示了集中权威按设计运行，而非分散权威。

软件多样性是真实控制，不应被削弱

反对夸张的论点并非支持单一文化。RPKI 依赖方处理从许多发布点检索的证书、撤销列表、清单、ROA 和其他签名对象。它们处理 ASN.1、密码签名、URI 发现、RRDP、rsync、缓存状态、对象过期和异常发布条件。一个缺陷可能损坏输出、消耗资源或使验证数据对路由器不可用。

独立实现可以减少常见的软件故障，前提是它们的独立性是真实的。rpki-client 在 OpenBSD 生态系统中开发，强调小代码库、权限分离和受限的进程访问。Routinator 是一个 Rust 实现，具有自己的检索、存储和验证设计。FORT 是另一个具有单独运营控制的开源依赖方。它们的代码、发布路径和安全假设并不相同。

生态系统已经表明软件管理权会发生变化。2021 年，RIPE NCC 结束对其验证器的支持，并建议运营商转向替代方案，而不是继续使用未经维护的代码。该决定并未削弱 RPKI 权威；它承认依赖方软件可以由独立生态系统提供。

网络通过使用多个维护实现获得几项保护。一个关键的解析器缺陷不需移除所有源。可以比较存储库边缘情况。可以在成为唯一生产源之前测试新的标准特性。维护可以在不盲操作的情况下进行。不同的遥测可能会揭示一个接口隐藏的错误。

这些收益证明了工程投入的合理性。错误在于将它们用作不同主张的证据：即证书和注册局权威已被去中心化。防火门不会多样化建筑物的所有者。它使建筑物在某一类故障下更安全。验证器多样性应以同样精确的术语进行辩护。

共同的信任输入定义了独立判断的边界

RFC 8630 使信任决策异常可见。TAL 包含一个或多个位置和公钥信息。依赖方检索自签名 CA 证书，检查其公钥是否匹配，并决定是否愿意接受该实体作为证书所描述资源的信任锚。一旦被接受，该锚不仅仅是另一个数据源。它是后代证明成为有效的基础。

RFC 还指出了泄露的严重性。拥有信任锚私钥的攻击者可以冒充权威。依赖不适当或不正确的信任锚可能导致同样严重的后果。签发者可以在不重新分发 TAL 密钥的情况下更改其证书中的资源集，这是必需的灵活性，因为区域资源持有量会发生变化。同样的设计意味着依赖方对签发者的克制寄予了相当大的信任。

使用相同 TAL 的多个验证器不会做出单独的信任选择，除非其运营商有意进行不同配置。捆绑的 TAL 可能使选择几乎不可见：安装产生有用的默认值，并且每个实现都从相同的区域密钥开始。便利性有利于采用，但不应与独立协商的信任关系混淆。

从多个 URL 检索信任锚证书也不会创建多个权威。RFC 8630 允许多个位置以提高检索效率。每个位置都针对相同的公钥进行检查。镜像可以使证书保持可用；它无法在没有受信任私钥的情况下签署不同的权威状态。

这个边界给运营商提供了一个实际盘点问题。对于每个验证器实例，配置了哪些 TAL 密钥，它们是如何获得的，谁可以更新它们，以及哪个软件包可以在升级过程中更改它们？如果三个实例通过一个无人值守的软件包通道接收 TAL 更改，它们的表观独立性包括一个共享的引导依赖。代码库可能不同，但根配置在操作上仍然是集中的。

验证器不能仅仅因为一个有效的不利行为是不利的就否决它

RFC 8211 分析了认证机构和存储库管理者的行为，这些行为可能损害资源持有者。原因可能是攻击、错误、政策行动或法律强制。父 CA 可以撤销 CA 证书，结果导致依赖方将下属签名对象视为无效。竞争的 ROA 或变更的资源集也可能改变路由结果。

从持有者的角度来看，影响可能很严重。从验证器的角度来看，任务仍然是正确处理已接受的认证状态。如果配置的链下出现一个正确签名的当前撤销并满足验证规则，验证器无权因为公开声明声称不公平而忽略它。这样做会使每个软件维护者变成上诉注册局。

运行另一个实现并不会改变这种划分。正确的实现对有效父行为的影响应趋于一致。多样性可以揭示一个验证器未能获取新的撤销或错误处理了清单。它不能得出父 CA 缺乏合同或法律权威的结论。该判断需要证据和解析器逻辑之外的论坛。

这就是标题主张最尖锐的形式。单一信任锚不一定是整个互联网的单一组织；它是相关路径顶部的唯一被接受的权威。如果该权威或一个强大的父 CA 采取不利行动，验证器多元性可以使后果更可靠地可见。它不能治愈产生该后果的权威关系。

补救措施必须在权威层运作：对异常证书变更的分权批准、在可能的情况下通知、确切理由、独立审查、上诉、连续性措施以及纠正错误而不抹去历史的方法。技术检测支持这些控制。它不能替代它们。

验证器之间的一致是计算证据，而非制度同意

运营商经常比较多个验证器的输出。这种做法可以识别实现缺陷或过期的缓存，但比较需要一个关于一致意味着什么的理论。三个相同的验证有效负载列表表明这些实例从其当前视图产生了相同的结果。它们不表明三个注册局批准了底层的证书或受影响的持有者同意了。

这种区别类似于重复的算术。独立的计算器增加了对总和计算正确的信心。它们不提供发票系合法签发的独立证据。RPKI 验证器可以确认路径和对象有效性。认证机构和注册过程决定了哪些陈述进入该路径。

即使是计算一致也有局限性。实例可能共享一个密码库、操作系统组件、存储库缓存、TAL 包、网络路径或更新计划。两个品牌产品可能继承了相同的解析依赖。三个服务器可能查询同一个本地镜像。多样性应按照故障域而不是产品数量来评估。

歧义也是模糊的。一个实例可能过时，一个可能实现了更新的 RFC，一个可能拒绝格式错误的内容，而一个可能首先获取了当前的撤销。少数可能是正确的。一个新的有效权威变更通常会在缓存更新时产生暂时的不一致。一个选择最常见输出的多数规则可以在需要快速识别撤销时正好保留旧的权威。

由于这些原因，比较应保留解释。报告应显示软件和版本、TAL 密钥标识符、存储库序列号或获取时间、清单状态、验证错误和输出差异。运营商可以随后确定原因是代码、检索、配置还是上游权威。没有来源的共识是一个弱安全信号。

多数投票在合法变更的时刻特别危险

想象一下服务于一个网络的三个验证器。两个在证书撤销之前没有成功完成一次获取。一个具有当前的存储库状态并移除了受影响的有效负载。一个简单的两票对一票政策将保留被撤销的权威，因为过期的视图拥有更多选票。为提升安全性而设计的冗余将延迟合法的安全行动。

反过来事实。两个验证器因为共享一个缺陷而接受了一个格式错误或重放的状态，而一个更严格的实现拒绝了它。多数投票再次选择了错误的结果。当实例并非统计独立且系统并非设计为拜占庭共识协议时，计数不能替代因果诊断。

更好的生产设计利用多样性进行警报、故障转移和有限比较。路由器可以根据供应商能力和本地架构从独立运营的缓存接收馈送。网络可以定义哪个实例是正常服务的权威，哪个在进程故障后接管，以及当不一致时冻结自动变更或触发审查。安全政策应区分缺乏新鲜数据与经过验证的移除。

响应也可能依赖于范围。一个影响单个前缀的不一致不应要求放弃所有验证的有效负载。完整的验证器故障与有争议的对象不同。信任锚获取失败与该锚下的认证变更不同。细粒度的遥测防止冗余层将每个异常压平为一次投票。

没有通用定数使这些决策对每个网络都正确。路由器集成、风险容忍度和更新间隔各不相同。运营商应公开其内部使用的逻辑，并针对当前状态变更、过期缓存多数、格式错误对象不一致和完全馈送丢失进行测试。只有当选择行为像实例一样精心设计时，验证器多样性才成为一种控制。

存储库多样性保护可用性，而非认证权力

RPKI 存储库系统是分布式的。子 CA 可以在不同的点发布，RRDP 或 rsync 可以使签名产品对依赖方可用。多个位置、内容分发和缓存的验证状态降低了一次服务器中断立即移除所有数据的可能性。它们是关键的可用性控制。

签名对象还允许验证器将存储库传输视为不可信。镜像不能在保持有效签名的情况下静默更改 ROA。清单和撤销信息帮助依赖方检测缺失、过时或替代的内容。这是架构的优势：分发不需要每个交付服务器都是权威。

相同的属性定义了限制。镜像不能发布持有者缺失的 ROA，恢复父 CA 有效撤销的证书，或纠正错误的资源集，而没有授权签名。十个存储库可以复制相同的当前不利状态。它们的独立性使该状态更难压制，而不是更不具备权威性。

存储库管理者本身也可能采取不利行动或失败。RFC 8211 考虑了这些情况，因为压制或替代可能影响依赖方验证的内容。验证器多样性可以帮助识别不同的检索结果，存储库多样性可以提供替代访问。然而，如果相关的 CA 控制着权威的清单和撤销状态，分发并不会对其签署的决策创建独立的制度检查。

治理的回应是将可用性与问责制配对。出版物服务应在有用时操作上分离，变更应产生可验证的收据，独立监控者应存档哈希和时间。缺失的对象、过时状态和经过认证的撤销应作为不同事件报告。存档可以显示什么在何时发生了变化；它不能单方面创建替代权威。

因此，韧性声明应命名所在的层。多站点发布提高了交付韧性。独立验证器提高了处理韧性。受保护和分权 CA 操作提高了签发韧性。审查和上诉提高了治理韧性。将全部四个称为去中心化会模糊每个实际控制哪种故障。

信任锚轮换仅在权威仍可信赖时解决连续性

长期存在的信任锚密钥最终必须更改。硬件老化、算法演进、运营实践改善，可能的泄露可能需要更换。轮换是危险的，因为依赖方从已经带外配置的密钥材料引导。改变得太突然，验证生态系统的部分可能会丢失该树。

RFC 9691 引入了一个信任锚密钥对象，可以信号当前和后继公钥及其证书位置。它使用一个接受期和重复观察，以便依赖方可以在切换前阶段性地准备后继者。该过程使计划中的轮换更有秩序，并给运营商提供证据表明后继材料保持稳定。

这是一个实质性的权威层改进。它承认根密钥转换不能在没有保护措施的情况下委托给普通对象检索。它也支持独立软件，因为不同的依赖方可以实现或监控相同的阶段性变更。

安全边界仍然明确。RFC 9691 指出该机制不保护当前或后继信任锚私钥的泄露。控制当前密钥的攻击者已经拥有指导恶意过渡所需的权威。多个验证器忠实处理签名的过渡将不会抵消这种控制。

因此，密钥轮换需要技术机制周围的制度控制。后继生成应使用受保护设施和分权批准。公众应通过独立渠道收到提前通知、当前和后继指纹、预期日期和恢复联系人。依赖方开发者应测试支持。在预期等价期间，监控者应比较两个密钥下的验证结果。过渡后应出示旧私钥销毁或退役的证据。

教训比轮换更广泛。密码程序可以使权威变更安全地防止意外中断，同时保持权威的集中不变。良好的治理既问过渡是否验证，也问控制它的人员、规则和证据是否受到充分约束。

密钥保管应分离持有、批准和观察

信任锚私钥的强大使得没有常规管理员应能单独且不可见地使用它。技术保管可以将密钥置于受保护硬件中，限制导出，并需要对敏感操作有多个授权参与者。组织保管可以将提议变更、批准、执行仪式和审查结果的人员分离。

这些控制不会创造另一个根，但它们降低了单个受损账户或内部人员行使根权力的风险。它们也为后续审查创造证据。证书签发、资源集变更或轮换应链接到一个已批准的事件、精确输入、参与者、生成输出和独立发布观察。

阈值批准必须是实质性的。来自一个报告线的三个批准使用同一个受损身份服务可能在看起来分散的同时共享一个故障域。参与者应代表不同的职责，紧急访问应比普通访问更窄且更可见。恢复材料不应静默绕过施加在活动密钥上的相同控制。

公众不能检查秘密密钥材料，也不应检查。它可以检查治理证据：当前认证实践声明、密钥标识符、仪式时间表、审计范围、异常操作计数、实质性发现和补救措施。资源持有者可以在其证书被更改时接收更详细的证据。法院和主管当局可以在适用程序下访问受保护的记录。

验证器多样性补充了这种结构。独立实现和监控者可以确认发布的效果与仪式输出匹配，并且没有出现意外的后代状态。它们仍然是权威的观察者，而非分权保管的替代品。最强的设计将两者联系起来：受限签发产生可审计的变更，多样化的依赖方验证这些变更按预期传播。

注册局权威必须可审查，因为认证跟随注册

RPKI 资源证书反映了号码资源分配层次结构和签发机构对权威的认可。如果底层注册发生变化，认证路径可以改变。一个完美安全的密钥仍然可能执行不正确、过度或争议性的注册局决策。密钥保护处理未经授权的使用；它不能保证合理的政策或裁决。

因此，制度控制应在签署之前开始。从证书中移除资源的权限应明确指出。例程归还、批准转移、合同终止、欺诈纠正、法院命令和紧急安全响应是不同的理由。每个应有证据、决策权、在法律允许情况下的通知规则、范围、生效时间和审查。

挑战决策的持有者需要一个能够审查注册基础而非仅仅确认 CA 签名有效的论坛。审查应独立于做出初始决策的员工或机构。紧急连续性措施可以在争议考虑期间保留路由，但它们不应静默重写最终持有者状态。

发布应带有理由代码或链接的公开通知，级别有助于问责而不披露受保护的证据。验证器不需要私人案件文件来处理撤销。运营商和受影响的持有者需要知道变更是否是计划的、纠正性的、安全相关的或法律限制的，以便寻求正确的补救措施。

这就是制度合法性进入路由安全的地方。网络越依赖来源验证，上游注册和认证决策就越有影响力。加强技术执行应匹配更强健的正当程序，而不是声称独立验证器代码已经分散了权力。

本地例外保留自主权但可能碎片化共享信号

RFC 8416 定义了简化本地互联网号码资源管理与 RPKI。它允许运营商在其本地视图中过滤或添加断言，包括在解决不利行动时提供保护。这是明确承认依赖方可能需要独立的有限自治权，不受全球发布状态的约束。

在明显错误的情况下，SLURM 可能是有价值的。具有可靠直接证据的网络可以在 CA 纠正意外撤销时为其自身及其客户保留可达性。本地断言可以被审查、过期和移除，而无需假装全球 RPKI 已经包含纠正措施。

该控制并非全球疗法。本地例外不会改变其他运营商验证的内容。如果许多网络创建不同的覆盖，RPKI 结果的共享意义碎片化。恶意或粗心的运营商也可以使用本地添加来授权全球层次结构不允许的路由。例外机制将责任转移到本地网络。

验证器多样性不能解决该政策问题。不同的实现可能都正确应用相同的本地文件，同时产生与全球存储库不同的输出。比较报告必须识别本地断言；否则运营商可能将有意的覆盖误认为实现缺陷或独立权威。

合理的例外政策要求证据、窄前缀和 ASN 范围、指定批准、开始和过期、受影响客户、审查和移除标准。紧急使用应促使追求权威修正，而非成为永久影子认证。运营商应能够在不必要泄露敏感细节的情况下向同行和审计员解释差异。

因此，本地自治是一个安全阀。它减少了对一个网络立即上游补救的依赖，但无法提供只有纠正后的权威链才能恢复的一致全球授权。

受约束的信任选择是可能的，但带来协调成本

RFC 8630 指出，不愿对信任锚签发者广泛信任的依赖方可以签发自己的自签名证书作为信任锚，并对下属证书施加约束。原则上，本地信任配置可以缩小外部锚被接受覆盖的范围。

该选项表明依赖方并非形而上地绑定到供应商默认值。它们选择从中验证的锚。大型运营商或联盟可以维护额外的约束、独立分发和审查。这些措施可能限制锚声明超出预期集合的资源的效果。

代价是协调。本地约束的锚必须跟踪区域资源持有和转移的合法变更。过时的约束可能在资源转移后拒绝有效的认证。不同的约束集可能导致网络派生出不同的有效负载。维护它们的机构获得了自己的权威和操作负担。

为相同资源创建几个竞争性的信任根将引发更困难的问题。当它们分歧时，哪个根获胜？任何有效路径都足够，允许过时或受损的根保留权威吗？必须达到法定人数，但有过期多数失效的风险吗？谁添加和移除根？密码学本身无法回答这些宪法选择。

近期目标不应是为多元化本身。应是在保持连贯验证信号的同时，最小化当前层次结构内不可审查的权力。强大信任锚操作、限定资源声明、透明变更、独立监控者、本地紧急控制和可信上诉可以减少集中风险，而无需发明未解决的多根竞赛。

对替代权威模型的研究仍然有价值。任何提案都应指定冲突解决、转移、紧急行动、密钥泄露、法律强制和退出。在回答这些情况之前就称设计为去中心化，将重复把验证器数量当成权威数量时的相同错误。

运营商在购买冗余前需要层次地图

韧性部署可以在六个层次上评估。第一是引导：TAL 密钥、获取方式、软件包源和更新权威。第二是签发：信任锚和下级 CA 密钥、批准和注册决策。第三是发布：清单、撤销列表、签名对象、RRDP、rsync 和存储库可用性。第四是验证：代码库、库、缓存、版本和异常情况行为。第五是向路由器分发：RPKI 到路由器会话、故障转移和过期规则。第六是路由策略：Valid、Invalid 和 NotFound 状态如何影响路由选择。

购买两个验证器主要改变了第四层，可能还有第五层。将它们运行在不同位置增加了可用性分离。在层次结构允许的情况下使用独立的存储库改善了第三层。没有一个自动改变引导或签发。一个共同的 TAL 更新通道、一个 RIR CA 和一个注册决策可以保持共享。

盘点应明确识别共同依赖。两个验证器是一个主机上的虚拟机吗？它们共享 DNS、电源和网络传输吗？它们读取同一个缓存吗？路由器会话自动故障转移吗？两个软件包收到相同的捆绑 TAL 更新吗？它们使用相同的密码库吗？哪个团队可以更改本地例外？

测试应跟随地图。使一个实现崩溃。在实验室环境中输入格式错误的对象。延迟一个存储库视图。在受控环境中轮换 TAL。合法移除有效负载并验证过期多数逻辑不会恢复它。练习完全馈送丢失和恢复。记录哪个层检测和包含了每次故障。

结果是一个可辩护的韧性声明。运营商可以说没有单个验证器进程、主机或维护事件会移除其验证馈送，同时承认区域认证权威仍然是共同的。精确声明邀请精确改进；关于去中心化的广泛声明往往会过早结束调查。

独立比较应解释差异而非给品牌打分

一个公开的比较服务可以加强生态系统，如果它避免将验证器输出变成排行榜。它的任务是运行维护的实现，针对识别出的存储库快照和实时检索，保存配置，并报告差异，附带足够的证据供开发者和运营商复现。

有用的单元是验证事件。哪些信任锚处于活动状态？哪个对象或发布点产生了分歧？实现获取了相同的字节吗？一个使用了先前的缓存状态吗？哪个 RFC 规则或本地策略适用？什么有效负载差异到达了路由器？问题是否已修复，在哪个版本中？

聚合计数可以支持维护，但它们需要分母和严重性。影响一个格式错误的测试对象的解析器拒绝与缺失区域树不同。传输超时与接受已撤销证书不同。该服务不应从其参与者推断全球部署份额，也不应将一个月的选择性测试描述为每种生产条件。

开发者应有权利用证据回应。运营商应在实现不再维护时收到警告，就像 RIPE NCC 对其退役验证器所做的那样。安全敏感细节在完整公开前可能需要协调披露。独立性意味着比较服务不能仅由一个验证器供应商或一个签发机构资助或管理。

这样的服务使软件多样性变得更好。它可以识别共享库、相关故障和标准歧义。它也使得权威边界可见：当每个实现从同一个认证的父行为产生相同的不利结果时，报告应将注意力引向签发者和审查过程，而不是庆祝一致意见。

号码资源协会可以审查代码与权威之间的边界

号码资源协会可以通过发布一份拟议的保证标准来做出贡献，该标准命名每个层并拒绝让一个层代表另一个层。声称验证器多样性的提供者将披露代码库、版本、托管分离、TAL 获取、共享依赖、比较方法、路由器馈送逻辑和例外政策。它不会被允许暗示这些控制创建了独立的认证根。

对于信任锚和 RIR CA，NRS 可以提出一套不同的证据：当前密钥标识符、资源声明范围、保管模型、批准分离、轮换计划、异常变更程序、存储库连续性、公开通知、独立观察、上诉路径和更正历史。目标不是给 NRS 每个私钥。而是使上游权威的行使可评估。

NRS 还可以提出标准变更收据，供签发机构和独立监控者采用。收据将绑定原因类别、受影响的资源集、前后证书标识符、授权机构、生效时间、发布证据和审查状态。监控者可以附加观察结果，显示变更何时变得可见。受影响的持有者可以通过指定论坛挑战注册基础，同时所有人都同意签了什么。

这个角色是积极的，因为它扩大了问责制，而无需创建未经测试的超级根。NRS 可以倡导独立合格的比较提供者，并发布基于源代码的比较。认证和纠正命令需要主管当局；NRS 不能发布任何一种。成员代表可以将持有者和运营商纳入标准评审。资金和冲突必须披露，以便主要注册局、供应商或网络不能将保证转化为认可。

该模型仍然是前瞻性的。公共 NRS 材料支持分布式参与和有限制度权力作为目标；它们并未确立这个信任锚保证系统已部署或得到所有区域认可。可信度将依赖于试点、外部审计、已发布例外以及批评软件提供商和签发机构的意愿。

测量必须保持软件使用率与权威暴露分开

对于生产验证器部署，没有完整的公共分母。运营商可以运行私有实例、使用供应商集成服务、外包验证或从上游接收验证路由。下载计数不等于活跃网络。公共路由器观察不会可靠地揭示哪个依赖方实现产生了政策决定。

因此，报告应抵制诸如一个实现服务固定比例的互联网之类的声明，除非测量支持该分母。一项调查可以说明有多少回应网络使用 Routinator、rpki-client、FORT 或其他服务。它不能静默概括到所有自治系统。一个测试平台可以说明它比较了哪些版本。它不能推断每个部署的版本行为相同。

权威暴露需要不同的度量。验证器可以列出哪个信任锚产生了每个有效负载，运营商可以报告其本地验证集中按配置锚的份额。这仍然没有测量治理质量或不利行动的概率。资源计数、路由计数和流量依赖是不同的分母。

运营指标应绑定到故障：按实例的验证周期成功、存储库新鲜度、输出差异、TAL 变更、路由器馈送可用性、过期持续时间、本地例外和纠正时间。权威指标应包括异常证书变更、轮换性能、审计发现、上诉和补救。将两者合并为一个多样性分数会抹去因果关系。

最有用的报告可能得出结论，软件韧性很强而权威审查仍然薄弱。另一个可能发现 CA 治理健全但验证器单一文化危险。分层措施使机构能够修复实际缺陷。单个去中心化徽章奖励的是表象而非工程。

下一个架构应在倍增主权根之前多样化检查

关于 RPKI 权威层次结构是否应演进，存在一个真正的宪法问题。区域信任锚反映了分配结构，并为验证提供了连贯基础，但随着 Invalid 路由被更广泛地拒绝，其权力变得更加重要。软件多样性本身不是答案。随意添加根而没有分歧规则也不是。

近期改革可以多样化围绕当前权威的检查。独立监控者可以存档变更。持有者可以接收签名通知。异常行动可以要求分权批准。上诉可以在制度上分离。密钥仪式和轮换证据可以发布。本地紧急例外可以管理和限时。跨区域转移可以使用通用收据。验证器实现可以保持独立并持续比较。

更长期的提案可能使用约束根、交叉签名、阈值权威或其他模型。每个必须解释合法资源转移如何改变权威，受损参与者如何被移除，冲突认证如何解决，法律命令如何限定，以及依赖方如何收敛。无法终止过时权威的冗余可能比层次结构更危险。

设计目标不是最大根数。是尽可能小的不负责任的控制，同时保持足够的连贯性，使路径来源验证仍然有用。一个系统可以有多个根，但仍然在每个资源上集中权力。一个资源可以只有一条路径，但仍然在该路径周围有强大的程序检查。标签应跟随实际的故障分析。

NRS 可以建设性地召集这个辩论，如果它发布假设、竞争性设计和测试结果，而不是宣布制度胜利。RIR、运营商、持有者、验证器开发者和路由供应商各自拥有必要证据的一部分。没有一个群体的软件或证书应单独定义宪法答案。

正确的主张更窄但更强

运行多个维护良好的验证器的运营商比依赖一个被忽视的实例的运营商更安全地应对一类故障。独立代码和操作可以检测缺陷，在维护期间保持服务，并暴露歧义的存储库条件。这些是实质性的收益，应被测量。

运营商仍然依赖于配置的信任锚及其认证层次结构。对于给定资源，多个验证器通常验证从相同活动根路径派生的权威。如果父链合法更改，正确的验证器跟随它。如果根密钥泄露，软件多样性不会恢复可信的签发。如果注册局决策有争议，解析器一致不提供正当程序。

回应不是对 RPKI 的犬儒主义。来源验证提供了一个有用的密码陈述，而 BGP 本身缺乏。其不断增长的运营权重正是为何权威层需要明确的治理。技术成功应增加对上游权力的审查，而非掩盖它。

最强的部署结合了两种控制。多样化的依赖方软件独立检查不可信内容。信任锚和 CA 操作使用受保护密钥、分权权威和安全轮换。注册变更有理由且可审查。发布具有韧性和可观察性。路由器馈送政策有意处理过时和差异状态。本地例外保持有限。外部保证报告每个层，而不替代一个为另一个。

验证器多样性可以确认一个信任层次结构被正确解释。它不能使该层次结构多元。制度合法性始于系统明确说明这一点，然后在权威实际存在的地方建立缺失的检查。

来源