摘要

  • 全球 RPKI 并非确实构建于一个通用信任锚点之上。依赖方软件通常使用 AFRINIC、APNIC、ARIN、LACNIC 和 RIPE NCC 的信任锚定位符（TAL）。但对于给定资源，其有效证书路径在特定时刻通常终止于一个被接受的权威机构，因此运行多个验证器并不会为该资源创建多个独立的签发者。
  • 验证器多样性具有价值。独立的代码库可能包含不同的解析器缺陷、内存安全故障、传输行为、缓存策略和发布周期。独立的实例也降低了因单一进程故障或维护事件而使得网络失去所有可用验证数据的风险。
  • 然而，每一个符合标准的验证器仍在其已配置的信任锚点所授予的权限内评估签名对象。如果一个被接受的父 CA 撤销了一个子证书、移除了其资源或者发布了一条竞争证书链，验证器应当能够识别由此产生的密码学状态，而不是投票决定父级的举动是否明智。
  • 存储库和传输层面的多样性可以提高可用性，但镜像节点无法制造权威。一份被完美复制的恶意证书或撤销信息仍然是恶意的；而来自独立镜像的一份未经签名的纠正则不是有效的替代品。
  • 以多数票方式在验证器输出之间进行选择，并不是一种机构上的上诉。两个陈旧的缓存可以胜过一份最新的缓存；两个实现可能共享同一个库或解释方式；而一次真实的权限变更最初可能表现为不一致。操作人员需要能够解释每一项差异的证据，而不是简单的计数。
  • 信任锚点的韧性属于权限层面：受保护的密钥保管、分开的审批、公开的轮转计划、后继密钥的预先布置、独立观察、有限范围的证书变更、有理由的决策、申诉和连续性安排。RFC 9691 使得计划内的信任锚点密钥转换更加安全，但明确不防止当前信任锚点私钥被泄露的情形。
  • 诸如 SLURM 之类的本地例外可以在不利操作期间保护操作者的自主权，但它们只在本地生效，并可能割裂验证视图。它们是一种应急控制，而非替代性的全球权威，也不是对争议性注册局决策的自动解药。
  • 资源号协会（Number Resource Society）可以通过对信任锚点收据、密钥仪式证据、变更通知、异议程序以及验证器对比报告进行标准化，使得权限集中更具可问责性。它应当作为独立软件的补充，而非将软件多样性标榜为注册局权力已被去中心化的证明。

多样性始于第一个决策已被做出之后

RPKI 验证器并非通过检查 BGP 然后选出其认为有说服力的机构来发现权威。它起始于由操作者配置的信任锚点材料。信任锚定位符（TAL）提供了一些位置和一个公钥，用于获取和认证一份自签名的认证机构（CA）证书。从那个被接受的起点出发，验证器沿着证书路径进行验证，检查资源扩展、清单、撤销列表和签名对象，并产生经过验证的载荷。

两个用不同语言编写的验证器可以独立完成这项工作。一个验证器可能会拒绝另一个验证器错误处理的畸形编码。一个验证器可能在存储库中断后恢复，而另一个则崩溃了。一个验证器可能清楚地显示一份过时的清单，而另一个则产生一段不那么有用的错误提示。这些差异很重要，因为存储库内容是不可信的输入，并且验证表面很复杂。

然而，这些验证器并不独立决定谁是最终的签发者。如果两者都配置了相同的 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 证书，结果使得依赖方将下属的签名对象视为无效。一份冲突的 ROA 或被更改的资源集合，也可以改变路由结果。

从持有者的角度来看，其后果可能是严重的。而从验证器的角度来看，其任务仍然是正确处理已被接受的证书状态。如果一份经过恰当签名、处于当前时刻的撤销，在已配证书链下出现并满足验证规则，验证器就无权因为某项公开声明指控不公便将其忽略。那么做，将把各家软件维护者变成上诉注册机构。

运行另一个实现并不会改变这一分工。正确的实现应当在有效的父级动作的效果上收敛。多样性可以揭示，某个验证器未能获取到新的撤销或错误处理了清单。它无法证明父级缺乏契约或法律上的权限。这种判断需要的是证据和独立于解析器逻辑之外的平台。

这是本文标题主张的最尖锐形式。单一的信任锚点，并不必然是整个互联网上的同一组织；它是在相关路径顶端那个独一无二、被接受的权威。如果该权威或某个强有力的父级做出恶意举动，验证器的多重性可以使后果更加可靠地显现。它无法治愈那个产生这种后果的权威关系。

补救措施必须作用于权威层面：针对特殊证书变更的分开审批、尽可能的通知、确切的原因、独立审查、申诉、连续性措施，以及一种在不抹去历史的前提下纠正错误的方法。技术检测支持着这些控制。它并不能取代它们。

验证器之间的一致，是计算层面的证据，而非机构同意

操作者们常常会比较来自多个验证器的输出。这一实践可以发现某个实现缺陷或过时的缓存，但这种比较需要一套关于一致意味着什么的理论。三份相同的已验证载荷列表表明，这些实例基于其当前视图得出了相同的结果。它们并不表明三家注册机构批准了底层的证书，或者受影响的持有者已表示同意。

这种区别类似于重复的算术。独立的计算器提升了人们对求和处理正确的信心。它们并没有提供独立证据以证明该发票是合法开具的。RPKI 验证器可以确认路径和对象的有效性。而认证机构和注册过程决定了哪些陈述会进入那条路径。

即使是计算上的一致也存在局限。实例们可能共享某个密码学库、操作系统组件、存储库缓存、TAL 软件包、网络路径或更新时刻表。两种不同品牌的产品可能继承相同的解析器依赖。三台服务器可以查询同一台本地镜像。多样性的评估应基于故障域，而非产品数量。

不一致同样是模糊的。某个实例可能过时了，某个可能实现了更新的 RFC，某个可能拒绝了畸形的内容，而某个可能已经首先获取到了最新的撤销。少数派可以是正确的。一次新近产生的、有效的权限变更，往往会随着缓存的更新而产生临时的不一致。一条选择最常见输出的多数决规则，恰恰可能在需要快速识别撤销的时刻，保留了旧的权威。

出于这些原因，比较工作应当保留解释。报告应展示软件及其版本、TAL 密钥标识符、存储库序列号或获取时间、清单状态、验证错误和输出差异。随后，操作者们可以判断原因是代码、获取、配置还是上游权威。没有来源出处的一致性，是一个薄弱的安全信号。

在合法变更发生的时刻，多数决尤其危险

设想有三台验证器为一套网络提供服务。其中两台自某次证书撤销之前起，便未成功完成过获取。另一台拥有最新的存储库状态，并移除了受影响的载荷。一条简单的“三取二”策略将因为陈旧视图拥有更多票数而保留住被撤销的权威。这项旨在提升安全性的冗余设计，却会延迟一次合法的安全行动。

将事实反转。两台验证器因为共享同一个缺陷而接受了一种畸形或被重放的状态，而一台更严格实现则将其拒绝。多数决再次选出了错误的结果。当各个实例并不是统计独立的，且系统并非被设计为一套拜占庭共识协议时，计数无法替代因果诊断。

一种更好的生产设计，是将多样性用于告警、故障切换和受限的比较。路由器可以根据厂商能力和本地架构，从独立运行的缓存中获取数据流。网络可以定义哪一个实例在日常服务中具有权威性，哪一个实例在进程故障后接管，以及何时出现不一致将冻结自动化变更或触发审查。安全策略应当区分“缺失新数据”与“经过验证的移除”。

响应也可以根据范围而定。一个影响单个前缀的差异，不应导致放弃所有已验证的载荷。一次完整的验证器故障，不同于一个存在争议的对象。一次信任锚点获取的失败，不同于发生在此锚点之下的经过认证的变更。细粒度的遥测可以防止冗余层将每一种异常都压平为一次投票。

不存在一个普适的法定人数，能使这些决策对每一个网络都是正确的。路由器集成、风险容忍度和更新间隔各不相同。操作者们应当发布其内部使用的逻辑，并针对当前状态变更、陈旧缓存多数决、畸形对象不一致以及完整的馈送丢失等情形进行测试。只有当选择行为与各个实例一样被精心设计时，验证器多样性才能成为一种控制。

存储库多样性保护的是可用性，而非签发权

RPKI 存储库系统是分布式的。下级 CA 可以在不同位置进行发布，而 RRDP 或 rsync 可以将已签名的产品提供给依赖方。多个位置、内容分发以及仍在有效期内的缓存状态可以减少某台服务器中断就立刻移除所有数据的概率。它们是至关重要的可用性控制。

签名对象也使得验证器可以将存储库传输视为不可信的。一台镜像节点无法悄无声息地更改一份 ROA 并保留其有效签名。清单和撤销信息则帮助依赖方检测缺失、过时或被替换的内容。这正是该架构的一个优势：分布并不要求每一台投递服务器都是一家权威机构。

相同的特性也定义了其局限。一台镜像节点无法签发持有者缺失的 ROA，无法恢复已被父级有效撤销的一份证书，也无法在没有授权签名的情况下纠正一个错误的资源集。十家存储库可以复制同一份恶意的现行状态。它们的独立性使该状态更难被压制，而非减弱其权威性。

存储库管理者自身也可能做出恶意举动或发生故障。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，资源号协会可以定义一套不同的证据集合：当前的密钥标识符、资源声明范围、保管模型、审批分离、轮转计划、特殊变更流程、存储库连续性、公开通知、独立观察、申诉路径以及纠错历史。目标并不是让资源号协会拥有每一把私钥，而是让上游权限的行使变得可被评估。

资源号协会也可以将变更收据标准化。一份收据要绑定原因类别、受影响的资源集合、变更前及变更后的证书标识符、授权主体、生效时间、发布证据以及审查状态。验证器或监控者可以附上显示该变更是何时变得可见的观察记录。受影响的持有者可以通过指定的平台挑战注册的基础，而同时所有人都对什么被签署了达成一致。

这一角色是建设性的，因为它扩展了可问责性，却没有创建一个未经考验的超级根。资源号协会可以认证独立的对比服务提供商，发布一致性案例，并在出现实质性发现之后要求纠正性的行动。成员代表性可以将持有者和运营者带入标准的审查。资金和利益冲突必须得到披露，这样一家主要的注册机构、厂商或网络才无法将保障转变为背书。

这种模式仍然是前瞻性的。资源号协会的公开材料拥护分布式的参与和受约束的制度权力作为宗旨；它们并不确立这套信任锚点保障系统已得到部署或得到所有区域的承认。其可信性将取决于试点项目、外部审计、公开的例外，以及同时批评软件供应商和签发权威的意愿。

测量必须将软件流行度与权限暴露分开

针对生产环境验证器部署情况，并不存在一份完整的公开分母。运营者可以运行私有实例、使用厂商集成的服务、将验证外包，或从上游接收已验证的路由。下载次数并不等于活跃网络的数量。公开的路由器观测结果并不能可靠地揭示是哪一依赖方实现产生了某项策略决定。

因此，报告应当抵制诸如某一实现服务于互联网中某个固定份额之类的说法，除非测量方法能够支撑该分母。一项调查可以陈述哪些做出回应的网络正在使用 Routinator、rpki-client、FORT 或其它服务。它不能默默地将结论推广至所有的自治系统。一个测试平台可以陈述它比较了哪些版本。它不能推断每一个已部署的版本都行为相同。

权限暴露则需要一种不同的衡量标准。一台验证器可以列出哪个信任锚点产生了每一份载荷，而一位运营者可以按其配置的锚点报告其本地已验证集合的份额。这依然没有衡量治理的质量或恶意行动的概率。资源计数、路由计数和流量依赖是各不相同的分母。

运行指标应当与故障绑定：各实例的验证周期成功率、存储库新鲜度、输出差异、TAL 变更、路由器馈送可用性、过时持续时长、本地例外以及纠正时间。权限指标则应当包含特殊的证书变更、轮转表现、审计发现、申诉和修复措施。将两者合并到一个多样性评分中，会抹去因果关系。

最有用的报告或许会得出结论，认为软件韧性很强而权限审查依然薄弱。另一份报告则可能发现健全的 CA 治理却伴随着危险的验证器单一生态。分层级的衡量指标能让各个机构去解决真正的缺陷。一枚单一的“去中心化”徽章，奖励的是展示，而非工程。

接下来的架构，应在乘以主权根之前，先让校验变得多样

关于 RPKI 的权限层级是否应当演进，存在着一个真实的构造性问题。区域性的信任锚点反映了分配结构，并为验证提供了一个一致的基础，但随着 Invalid 路由被更广泛地拒绝，它们的权力也变得越发具有后果性。单凭软件多样性并不是答案。轻率地在没有确立关于不一致的规则的情况下就添加根节点，同样不是答案。

近期的改革可以让围绕当前权限的校验变得多样。独立的监控者可以将变更存档。持有者可以收到经过签名的通知。特殊行动可以要求分开的审批。申诉可以在机构上独立。密钥仪式和轮转证据可以公开。本地的应急例外可以被治理并限时。跨区域的转移可以使用共用的收据。验证器的实现可以保持独立并持续进行对比。

更长远的方案或许会用到受约束的根、交叉签名、门限权威或其它模型。每一种都必须解释，一次合法的资源转移如何改变权威，一个受控的参与者如何被移除，冲突的证书如何被解决，法律指令如何被限定范围，以及依赖方如何收敛。无法终止陈旧权威的冗余，可能比层级制更加危险。

设计的目标并不是根的数量最大化。它是在最小化无法被问责的控制的同时，保有足够的连贯性以使路由起源验证保持有用。一个系统可以有多个根，却在每一个资源上仍然集中权力。它可以为了某个资源而仅有一条路径，却仍以强有力的程序性校验将那条路径包围起来。标签应当追随事实上的故障分析。

若资源号协会能发布假设、竞争性的设计和测试结果，而不是宣布制度性的胜利，它便可以建设性地主持这场辩论。RIR、运营者、持有者、验证器开发者和路由厂商各自都拥有一部分必需的证据。没有任何单一群体的软件或证书，可以独自定义这个构造性的答案。

正确的表述更窄，但也更强

一位运行着多个受维护验证器的运营者，比一位仰赖于某个被忽略的单一实例的运营者，对某一类故障更加安全。独立的代码和运维可以检测到缺陷，在维护期间保持服务，并暴露模糊的存储库状况。这些都是实实在在的收益，而且应当加以衡量。

该运营者仍然依赖于已配置的信任锚点及其证书层级。对于给定资源，多个验证器通常验证的是源自同一条活跃根路径的权限。如果父级链条合法地发生了变更，正确的验证器会随之跟进。如果根密钥被泄露，软件的多样性并不能恢复可信的签发。如果注册局的决策受到争议，解析器的一致性并不能提供正当程序。

对此的回应，不应当是对 RPKI 怀抱犬儒。起源验证提供了一种有用的密码学陈述，而这正是 BGP 单独所欠缺的。其不断增长的操作分量，恰好是权限层面值得明确治理的原因。技术上的成功，应当增加对上游权力的审视，而不是将它掩藏起来。

最强有力的部署将两类控制结合起来。多样的依赖方软件独立地检查不受信的内容。信任锚点和 CA 操作使用受保护的密钥、分权的权威和安全的轮转。注册变更是有理由的且可被审查的。发布是富有韧性并可被观察的。路由器馈送策略审慎地处理过时和分歧的状态。本地例外保持有边界。外部的保障报告则分层级进行报告，而不用一层替代另一层。

验证器的多样性能够确认，一条信任层级正在得到正确的解释。它不能使那条层级变得多元。制度的合法性，始于系统把这句话讲清楚，然后才在权威真正所在的层面，铺设起那些缺失的校验。

来源