摘要
- 在委托 RPKI 中,资源持有者运行子证书颁发机构并控制其私钥。父 RIR 仍然认证持有者的资源范围,并可在适用规则下替换或撤销子证书。密钥保管是职责分离,而非独立于分配层级。
- 标准将系统划分为可管理的关系。RFC 6492 支持父子配置;RFC 8181 支持由独立于签名 CA 的服务发布;证书和密钥轮换标准支持连续性。互操作性至关重要,因为依赖单一专有客户端是脆弱的。
- 正式的服务选项未必是可行使的权利。资格、合同、账户权限、软件合规性、发布访问、测试设施、支持、成本和文档都决定了运营商能否在实践中行使委托。
- 迁移是决定性的考验。当前的区域安排有所不同:有些记录的过渡允许托管和自营服务重叠,而另一些则要求先撤销托管 CA 再创建委托 CA。一个只能通过可避免的中断来行使的选择是薄弱的选择。
- 持有密钥带来责任。委托运营商必须保护签名材料、发布当前清单和撤销列表、维护发布、监控外部验证、保留继任访问并响应泄露。委托不应在未提供可用工具和支持的情况下转移责任。
- 混合发布可以将密钥保管与存储库可用性分开。它通常赋予运营商有意义的签名控制,而无需每个运营商都暴露全球存储库,但它保留了对父机构或发布提供者的依赖,因此需要明确的服务和退出条款。
- 无惩罚选择不仅仅意味着同等价格。委托用户应保留同等的资格、信息、事件访问、审查、迁移援助和会员地位。提供者可以收取透明的基于成本的费用或执行中性的安全规则,但不应将自我保管变成低人一等的制度地位。
- 资源号协会可以通过权利与责任矩阵、合规性练习、迁移演练和基于证据的成员倡导来提供帮助。它不应将私钥持有营销为资源所有权或免于合法父机构行动的特权。
仪式证明谁持有密钥,而非谁拥有所有权力
网络安全团队在其控制的基础设施上安装证书颁发机构软件。该软件在本地生成密钥对。私钥不离开组织。团队导出子请求,提交给其区域互联网注册机构,接收父响应,并完成关系。子 CA 请求资源证书,创建路由来源授权,并发布签名对象。
这是委托 RPKI 最清晰的形式。运营商而非 RIR 的托管服务决定其子密钥何时签名。父机构不能简单地使用该私钥创建带有子签名的对象。运营商可以应用自己的硬件控制、批准规则、审计记录、自动化和继任安排。
然而,证书的力量来自父机构。RIR 认证哪些号码资源属于子证书。如果资源经过正当程序被转让、归还或移除,父机构可以颁发更窄的证书或撤销子证书。依赖方接受运营商的 ROA,是因为通过来自公认区域信任锚的有效链到达它们,而非因为私钥持有创造了独立权力。
这种差异很容易在政治语言中丢失。倡导者可能称委托 RPKI 为主权。托管提供者可能暗示本地密钥保管改变不大,因为父机构仍控制范围。这两种立场都扁平化了真实的职责分离。
密钥保管很重要,因为它防止托管提供者成为唯一能表达持有者路由意图的一方。它让运营商将授权与自己的网络控制集成,并保留其所签署内容的独立记录。它可以在紧急路由变更期间减少对区域网络界面的依赖。它可以支持子委托和在多个父关系下的统一管理。
父权力很重要,因为 RPKI 是一个资源证书层级。前持有者不能仅通过保留旧私钥来继续授权已转让的前缀。被泄露或持续损坏的子 CA 不能无视后果地要求无限期认证。委托需要关于颁发、范围变更、撤销和恢复的规则。
因此,制度问题孤立地看并非“谁有钥匙?”,而是持有者能否在可靠、可互操作和公平的条款下选择并行使签名角色,同时父机构通过宣布的程序行使其更窄的权力。可用的权利存在于这种关系中,而非仅存在于密钥文件内。
托管便利与委托控制满足不同需求
托管 RPKI 使路由授权变得可访问。成员向 RIR 服务认证,输入前缀和来源 AS,提供者处理密钥生成、对象签名、续期、清单、证书撤销列表和存储库发布。对于许多小型网络,这是部署 RPKI 与否的区别。
委托操作将重要职责转移给持有者。运营商运行子 CA,保护其密钥,与父机构通信,创建签名对象,并运行或选择发布服务。它必须保持清单和撤销信息最新,并从软件或基础设施故障中恢复。
两种模式本身都无优劣之分。拥有两条稳定路由的小型市政网络可能合理偏好运行良好的托管服务。拥有自动化路由变更、下游客户和成熟密钥管理的大型多 RIR 运营商可能合理要求委托。大学或公共服务联盟可能选择本地密钥但父机构发布,作为制度保管和存储库韧性之间的平衡。
选择变得具有政治意义,因为托管便利的提供者也是父机构。这不是一个竞争性市场,不满意的客户可以将区域资源的认证转移到任何无关的供应商。第三方可以提供 CA 软件或托管运营,但证书路径仍必须连接到适当的父机构。
因此,托管服务的存在应加强而非消除委托选项。低摩擦的默认选项支持广泛采用。实用的委托退出方式制约集中化并为具有不同风险的运营商服务。当移动可行且职责清晰时,两种模式相辅相成。
当便利成为唯一真正受支持的路径时,问题就会产生。委托可能出现在服务页面上,但需要模糊的手动交换、不支持的软件、未宣布的中断、专家联系和合同不确定性。正式选择幸存,但只有具有特殊关系的运营商才能安全地使用它。
反向问题也存在。将自我运营视为唯一受尊敬的模式可能会将复杂的安全职责转移给无力执行的组织。在弱访问控制和过期存储库下持有的密钥在任何有用意义上都不是自主权。它可能降低持有者的路由证据并增加他人的验证工作。
合法的目标是知情且无惩罚的选择。托管用户应知道提供者控制什么。委托用户应知道他们控制什么以及什么继续留在父机构。每方都应有安全途径在其能力和风险演变时改变模式。
开放协议将承诺变为可互操作的选项
如果每个 RIR 都要求专有子 CA,委托将是脆弱的。IETF 标准提供了通用操作语法。
RFC 6492 定义了父 CA 和子 CA 之间的配置协议。子 CA 可以通过经过身份验证的交换列出其权利、请求证书和请求撤销。父机构在定义好的协议内响应,而非强制每个实现重现区域网络会话。该标准不决定父机构为何分配资源或合同争端何时证明行动合理。它使证书关系在权力确立后即可互操作。
RFC 8181 将发布与签名分离。委托 CA 可以通过经过身份验证的发布协议将签名材料发送到存储库服务器。这允许混合安排:运营商持有签名密钥,而 RIR 或其他提供者运营全球可用的存储库。分离角色减少了在交出密钥和独自运行每项公共服务的错误选择。
其他 RPKI 标准定义了证书概况、清单、撤销列表和轮换程序。它们为独立软件项目提供了稳定的目标。运营商可以评估维护中的 CA 实现,而非仅安装来自其父机构的二进制文件。
标准不保证可用性。两个产品可能声称支持,但在概况、时间、身份交换、子处理或故障恢复上存在差异。区域父机构可能符合核心交换,但入职仍依赖手动工单。发布服务器可能接受标准消息,但没有明确的能力或事件条款。
因此,可用自主权需要合规性证据。RIR 应发布支持的协议版本、概况、算法、端点行为、大小限制、更新预期和弃用时间表。在生态系统允许的情况下,他们应针对多个维护中的子实现进行测试,并发布可重现的结果。软件项目应针对多个父机构进行测试。
变更必须有节奏。父机构应在弃用协议或概况时给予足够时间,以便委托运营商升级和演练。紧急安全变更可能需要更快行动,但应包括兼容性计划、直接通知和事后审查。运营商不应在证书续期时发现其先前合规的子 CA 不再被接受。
开放标准也保护制度记忆。人员变动、供应商消失、社区软件可能被淘汰。如果请求、响应和对象使用文档化的格式,继任团队可以重构关系并迁移工具。自主权更少依赖单管理员的私人笔记。
因此,持有密钥的权利与使用合规子 CA 的权利不可分割。没有互操作性,私人保管可能成为具有不同锁的专有围栏。
网页上的可用性并非同等可用性
区域服务描述显示委托 RPKI 存在,但访问条件各异。ARIN 描述了托管和委托部署以及存储库发布选项。RIPE NCC 允许符合条件的成员和某些最终用户使用委托 CA,并记录了自我发布和发布服务。APNIC 长期支持自我运营的子 CA 和父发布。LACNIC 声明委托服务自 2019 年 12 月起对成员可用,并请有意组织联系其主机管理员。
这些是有意义的承诺。它们确立了自我保管在多个区域并非纯理论。它们不证明每个合同类别中的每个持有者都能在同等条件下获得它。
资格是第一重考验。直接成员可能有清晰路径,而代理、独立、遗留或国家注册用户依赖其他机构。在 RIPE 服务区域,针对独立和遗留最终用户的文档将直接或代理访问与特定合同和账户维护者关系挂钩。在 APNIC 区域,国家注册机构可以形成额外的父子层。正确的权力路径遵循实际资源和协议。
第二重考验是可发现性。需要电子邮件的服务仍然可以运作良好,但用户需要已发布的资格、预期响应时间、技术要求、条款和升级渠道。未解释的手动关口使人难以知道拒绝是源于政策、能力还是误解。
第三重考验是平等性。委托用户能否获得与托管用户相同的合格资源证书?是否接收相同的资源变更通知?能否使用父发布?是否有测试服务?事件是否由同一运营团队处理?成员门户是否显示足够的状态以诊断失败的交换?
第四重考验是实际成本。运营商合理承担本地 CA 安全和人员成本。额外的提供者费用如果反映不同的服务(尤其是托管发布或支持)可能是可辩护的。但成本应公开、可预测且与服务挂钩。仅因成员拒绝托管密钥保管而施加的不透明溢价将削弱平等选择的主张。
目前没有公共分母显示所有区域中有多少符合条件的持有者请求了委托、被接受、放弃设置、迁移失败或返回托管服务。因此,可用性应根据已发布的权利和可重现的用户旅程来评估,而非虚构的全球采用率。
当一个普通符合条件的运营商能够发现它、理解它、用合规工具完成它,并在被阻止时收到合理解释时,服务选项才变得平等。不足的选项可能仍然有用,但还不是强有力的权利。
迁移是名义选择与实际运营后果的交汇点
已使用托管 RPKI 的运营商不能仅通过指向委托注册页面来证明其自由。它必须能够将其路由授权从托管密钥移动到本地子 CA,而不会在预期路由失去有效授权的可避免时间段内发生。
迁移有若干状态。运营商盘点当前 ROA 和预期路由。建立本地 CA 并保护其密钥。父与子交换身份。配置发布关系。父机构颁发证书。子 CA 发布替换对象。独立验证者观察它们。托管对象被退役。监控确认预期结果。
排序很困难,因为两个 CA 可能在过渡期间主张重叠的资源范围。RPKI 证书政策必须防止未授权复制,父系统可能设计为一次仅支持一个成员 CA 模式。然而,严格的先断后建序列可能造成缺口。在委托子 CA 可以发布之前撤销托管 CA 意味着依赖方可能暂时看不到授权或不一致的状态,因为缓存刷新。
当前文档展示了区域差异。RIPE NCC 委托设置页面告知现有托管用户在添加委托 CA 之前撤销托管 CA,并建议首先使用测试环境。APNIC 描述了帮助台协助的并行托管和自营服务作为过渡过程。ARIN 告知用户更改部署选项时需与注册服务合作。这些不是等效的体验。
并行操作不自动安全。父机构必须确保重叠是故意的、短暂的、受监控的,并且不能在转让后保留权力。替换的 ROA 应反映相同的验证路由意图。先建后断设施应是受控的迁移状态,而非永久重复权利。
如果无法提供并行认证,提供者应通过预验证最小化缺口。它可以在撤销托管 CA 之前验证子的身份、密钥、软件交换和发布关系。它可以分阶段批准路由意图数据并安排与运营人员共同进行切换。它可以定义如果子 CA 失败时紧急返回托管服务的途径。
迁移记录应说明预期的有效性转换和实际观察结果。“新 CA 已创建”不是完成。完成意味着当前签名对象通过新路径验证,预期路由具有预期状态,旧权力已被安全退役,并且持有者拥有持久记录。
迁移支持不是礼貌的附加项。它决定了权利能否在不支付可避免的可达性风险代价的情况下行使。仅为新用户支持自我保管的机构已经为未来创建了选项,同时有效地锁定了现有托管用户。
测试环境必须复制危险边界
委托操作在承载生产路由意图之前应进行排练。测试父机构让运营商学习身份交换、配置、证书颁发、发布、对象验证、轮换和恢复,而不影响实时授权。
环境只有在差异明确时才有价值。测试服务可能省略父发布,使用不同的信任锚,简化账户资格,或缺乏生产事件路径。例如,RIPE NCC 测试文档警告其委托测试父机构目前不支持发布服务。这是有用的诚实;它也意味着测试无法验证整个生产混合安排。
提供者应发布比较测试和生产的兼容矩阵。运营商需要知道哪些协议版本、资源结构、速率限制、发布模式、撤销操作和告警是等效的。绿色的测试结果不应保证缺席组件的保证。
测试应涵盖失败,而不仅是注册。让子密钥不可用并从已批准的机制恢复。轮换密钥。让清单接近过期。中断发布。更改认证范围。拒绝格式错误的请求。撤销并重新建立子 CA。模拟人员继任。每项练习应留下其他管理员可以理解的证据。
迁移演练尤其重要。如果生产要求先撤销托管再创建委托,测试应衡量运营商对缺口的准备以及提供者的响应。如果生产允许重叠,测试应显示重复范围如何被限制和结束。
合规套件可以使这些练习可重复。它们应发布预期消息和结果,而不暴露生产凭据。独立 CA 项目、RIR 和运营商可以运行相同案例。失败成为可操作的互操作性报告,而非一方指责另一方的谣言。
测试有治理效果。它减少了父机构和专业供应商的信息优势。成员可以确定自己是否拥有承担委托职责的人员、工具和程序。它还可以证明拒绝或失败发生在服务边界而非其自身软件内部。
没有测试能复制每个存储库、验证者或网络策略。结果是就绪证据,而非路由接受保证。但在生产前无法演练的权利对于首次行使的小型运营商尤其危险。
发布是可分离的,这改变了自主权计算
运行 CA 和运行存储库是不同的功能。CA 保护私钥并签署证书、清单、撤销列表和路由授权。发布服务使当前签名材料可通过全球可达的机制供依赖方使用。
运营商可能有能力进行密钥保管,但不愿意运营高可用公共存储库。存储库面临网络中断、DDoS 攻击、存储不一致、陈旧对象和协议兼容性要求。小型本地 CA 可以安全,而其公共分发点可能脆弱。
RFC 8181 使分离成为可能。子 CA 在本地签名并通过认证协议将对象提交到发布服务器。ARIN 为委托用户提供存储库发布服务。APNIC 支持自我运营 CA 的父发布。RIPE NCC 为委托 CA 提供发布服务。这种混合可以是许多有能力的持有者的强大默认选项。
这种安排保留了有意义的自主权。RIR 不因其发布对象而持有子签名密钥。它应根据声明的协议和授权检查接受或拒绝发布消息,而非重写签名内容。运营商可以保留自己的对象和请求历史。
依赖仍然存在。如果父发布服务不可用或移除子的材料,依赖方可能最终失去对当前有效对象的访问。发布提供者可以在不伪造子签名的情况下造成伤害。因此,服务条款、可用性设计、事件通知、证据和退出条款都很重要。
自我发布仍然是具有能力和理由选择它的运营商的合法选项。父机构不应仅为了保持委托管理便利而要求其存储库。自主权修辞也不应迫使每个子 CA 向全球检索表面添加另一个脆弱发布点。
发布服务之间的迁移需要与 CA 之间的迁移同样小心。存储库 URI 嵌入在证书中,依赖方观察缓存状态。运营商和父机构应分阶段新发布,验证检索,并根据标准和软件行为退役旧位置。发布退出不应要求交出签名密钥。
有用的政策是模块化选择:托管签名和托管发布;委托签名与父发布;或委托签名与独立操作的发布,需遵守技术上合理的规则。每个模块应标识其运营商、职责、条款、证据和恢复。
密钥自主权在不受无关操作负担强加给密钥持有者时更强。分离让机构将责任分配给最有能力承担的一方。
持有密钥创造积极义务
没有义务的权利将危害其旨在改善的同一生态系统。委托运营商控制认证功能,其过时或格式错误的输出可能浪费依赖方资源、使其自身对象无效并使诊断复杂化。
第一义务是密钥安全。访问应受限、认证并记录。高影响签名可能需要多个批准角色。备份应加密、测试并防止单管理员离开组织。运营商必须知道如何撤销和替换受损密钥,而不依赖受损环境。
第二义务是对象新鲜度和内部一致性。清单和证书撤销列表有过期时间。证书需要续期。已发布对象必须与当前证书范围对应。自动化有帮助,但应在 CA 外部监控。显示“已发布”的仪表板弱于对存储库结果的独立验证。
第三义务是发布可用性。如果运营商自我发布,它承担全球可检索当前材料和弹性协议服务的负担。如果使用父发布,它必须维护经过认证的发布关系并监控确认。外包分发不消除验证它的需要。
第四义务是与路由意图对齐。本地密钥保管使自动化成为可能,但自动化可能更快地签名错误。CA 应将预期 BGP 路径与预期授权进行比较,在可行时使用精确匹配,要求对重大变更进行审查,并保存历史记录。
第五义务是联系和继任。父通知必须到达活跃团队。紧急联系人应在人员变动后仍然有效。合并、破产或外包网络过渡需要受控交接。无人能合法或技术上操作的密钥不是受保护的自主权。
区域政策可以强制执行最低卫生要求,前提是规则是前瞻性和成比例的。RIPE-847(2025 年发布)提供了一个有限的例子:当 RIPE NCC 无法发现和验证委托 CA 的当前清单和撤销列表超过三个月时,它应在合理的发现和通知努力后撤销资源证书。该政策针对持续无功能的 CA,而非短暂的不完美。
该规则说明了相互义务。运营商必须保持功能正常。父机构必须使用已发布的阈值、寻找当前材料并提供通知。撤销不视为选择委托的惩罚;而是对负担验证的持续失败的回应。
当义务同样明确时,委托权利更合法。持有者然后可以在知情同意下选择,父机构可以在不将自我保管视为可疑的情况下处理真正的生态系统损害。
无惩罚选择不限于价格
RIR 可以对托管和委托服务收取相同的会员费,但仍使委托变得惩罚性。平等对待有多个维度。
不应仅仅因为持有者选择自己的密钥而缩小资格,除非技术或合同关系确实不同。父机构应在应用相同注册规则后认证相同的当前资源范围。不应使不相关的服务取决于交出签名保管。
支持应是公平而非相同的。托管用户需要门户操作帮助;委托用户需要父交换、证书状态和发布方面的帮助。RIR 不需要调试每个第三方安装,但应识别错误是否发生在自身端点,发布诊断,并维护升级渠道。“因自托管而不支持”在被争议组件是父自身服务时是不充分的。
信息应同时到达。委托运营商需要关于影响证书的注册变更、协议弃用、信任锚工作、服务事件和政策提案的通知。他们不应从依赖方告警中得知父操作改变了其范围。
事件访问也应平等。委托用户可能需要紧急重新颁发或帮助确认父响应。提供者可以要求强身份证明,但不应仅因托管团队有更熟悉的工具就将自我保管置于较低优先级的队列。
审查和补救应遵循控制。持有者对自己的密钥和子输出负责。父机构对准确的授权、协议操作及其对子证书采取的行动负责。合同不应利用委托来否认每项由父控制的失败。相反,委托运营商不应期望 RIR 赔偿其未维护存储库造成的损失。
定价可以反映成本。专门的发布或辅助迁移服务可能消耗资源。费用应公开、通过相关治理流程批准,并合理与服务相关,而非旨在引导用户选择托管保管。费用减免或共享援助可能适用于公共利益网络缺乏能力的情况,但补贴决定应透明。
会员地位必须不受影响。选择委托 CA 不应减少投票权、政策参与、注册服务访问或作为负责任的成员的推定。安全事件应基于证据评判,而非基于只有集中操作才安全的文化信念。
无惩罚选择不意味着失败无后果。中性安全规则、基于成本的费用和成比例的撤销可以适用。测试在于相同的合法目标能否在不必要地加重密钥自主权的情况下实现。
撤销权力需要理由和回归路径
委托不消除父机构撤销子证书的能力。当密钥受损、资源离开持有者、证书与权威注册不一致或持续失败的子 CA 造成操作损害时,这种权力是必要的。
该权力也定义了私钥自主权的边界。持有者可能拥有子密钥和每个备份,但一旦父路径被撤销,其签名就不再有效。因此,在此边界的程序性保障至关重要。
父机构应发布有限的撤销类别。安全泄露、经认证的持有者请求、完成的资源转让、合格服务关系到期、具有约束力的法律要求以及持续的技术失败是可理解的类别。广泛的“操作原因”应有阈值、批准者和审查支持。
通知应与紧迫性匹配。确认的密钥泄露可能需要立即行动,随后在权利仍然存在时通过新密钥快速重新注册。计划中的转让可以使用预定的切换。技术失败规则可以提供观察、联系尝试、治疗期和最终通知。与路由安全无关的行政争议在证书行动前应谨慎行事。
理由应足够详细,以便运营商回应。协议错误应标识失败的交换。资源范围变更应标识注册事件。敏感法律材料可能需要有限披露,但保密不应成为默认。
审查必须能够产生补救。在航线失去有效授权数月后受理的上诉是不够的。系统需要紧急技术审查以纠正错误的父行动,随后如果事实或权力仍有争议则进行更全面的制度审查。
还必须有一条回归路径。如果子密钥安全且父机构错误,恢复可以重新颁发正确的证书并验证现有对象。如果子密钥受损,应建立新的子 CA。如果运营商失败,补救可能要求当前清单、更正发布或迁移到托管服务。补救应与原因匹配。
审计记录应保存请求、理由、证据类别、批准、通知、证书行动、发布效果和恢复。公共报告可以汇总常规事件并描述严重的提供者失败,而不披露私人拓扑。
父权力的合法性不来自否认其效果。来自通过可预测、可审查和可修复的规则使用该效果。当父机构不能使用子密钥签名且不能任意撤销子证书时,委托仍然有意义。
自动化应是可移植的而非专有的
大型运营商通常选择委托,因为他们希望路由授权遵循通过本地自动化的网络意图。流量工程系统可以准备路由、获得批准并创建相应的 ROA,而无需等待人工操作多个区域门户。
这种好处仅在自动化可移植时才真实。运营商应能够以文档化的形式导出其预期路由集、CA 关系、证书历史和发布状态。在在不同 CA 实现之间移动之前,不应必须重现专有提供者模型。
开放配置和发布协议界定了父和存储库的边界,但本地 CA 数据也很重要。密钥可以适当地保持不可从硬件导出。配置、授权意图、子关系、联系、审计证据和恢复指令仍应是可转移或可重建的。
软件多样性减少了对单一项目的依赖,但实现之间的迁移并不简单。新 CA 可能使用新密钥并需要父协调。子证书和发布 URI 可能改变。运营商应测试过渡并维护连续性,而非复制不透明的内部状态。
RIR 可以通过记录中性协议要求来支持可移植性,而不是认可一个强制客户端。他们可以为广泛使用的软件提供示例,同时接受任何合规实现。合规性测试应报告失败的标准行为,而不是不支持的品牌。
托管委托服务需要额外的清晰度。第三方可以代表持有者运营子 CA,而持有者保留合同权力或硬件密钥。RIR 应认证合格持有者并识别授权代理人,而不将供应商与资源持有者混淆。退出条款应让持有者替换代理人而不失去父关系。
自动化也增加了错误的爆炸半径。格式错误的意图馈送可以替换许多授权。委托软件应提供空运行、交易限制、批准策略和紧急冻结。本地控制不是削弱保障的论据;它是将其更紧密地集成到实际路由中的机会。
可移植的自动化增强了自主权和问责性。持有者可以更换工具、保存证据并识别哪个系统发出了错误对象。父机构可以维护稳定的标准边界,而非支持每个内部设计。
绑定到一个应用版本或顾问的权利是脆弱的。通过可互操作的协议、可恢复的配置和可替换的代理人表达的权利可以在制度变化中幸存。
小型运营商需要辅助路径,而非主权讲座
委托 RPKI 通常通过全球运营商和国家注册机构的需求来讨论。小型运营商也可能有本地保管的合法理由:公共部门要求、内部安全政策、多提供者路由、源于过去账户争端的不信任或与本地控制集成的需求。
他们面临更陡峭的相对负担。相同的 CA 概念、密钥管理、发布和监控适用于拥有三名工程师的组织和拥有三百名的组织。假设深度公钥基础设施专业知识的文档可能使正式选项不可访问。
辅助不应意味着拿回密钥。RIR 和社区机构可以提供逐步的标准解释、测试父、验证的配置示例、合规性检查、办公时间和迁移调度。混合发布服务可以移除最大的公共可用性负担,同时保留本地签名。
合作运营是另一种可能性。几个组织可以使用合格的托管提供者,同时维护不同的子密钥和权力。合同应定义谁可以签名、谁持有恢复材料、如何报告事件以及每个成员如何退出。共享基础设施不得将单独授权折叠为单一未记录的管理员。
财务支持可能适用于社区网络、大学和关键本地服务,其中安全采用具有公共价值。它应通过透明标准分配,不应购买政治支持。援助和注册机构选举是分开的领域。
培训应包括不委托的理由。如果组织无法维护联系、保护凭证、监控发布或执行恢复,今天托管服务可能更安全。决定可以重新考虑。知情选择包括决定本地密钥尚不负责的自由。
提供者应避免两种语气。一种是轻蔑的:“只有专家需要这个”。另一种是浪漫的:“真正的控制意味着自己做所有事”。两者都模糊了模块化选择和援助的光谱。
实用的权利是围绕最不富裕但有合法用例的合格成员设计的,而非仅第一个成功完成 XML 交换的大型运营商。如果该成员可以测试、获得帮助、使用父发布并安全迁移,则机构选项是成熟的。
证据应区分拒绝、困难和负责任的拒绝
声称 RIR 不允许密钥自主权可能意味不同的事情。服务可能正式不可用于持有者类别。它可能可用但未记录。请求可能被延迟。特定客户端可能失败合规性。持有者可能缺乏认证所需的合同关系。运营商可能提供了无效请求。父机构可能因声明的安全原因拒绝。
这些情况需要不同的补救措施。权利审查应保存请求日期、持有者类别、资源关系、已发布资格、软件和版本、协议交换、错误响应、支持联系人、理由、延迟和最终结果。在存在机器消息的情况下,仅截图是弱的。
困难也需要分母。十个投诉不能证明大多数迁移失败,如果尝试迁移的数量未知。区域声明不应成为全球声明。提供者可以通过发布带有类别和隐私保护的请求和结果计数来改进证据。
负责任的拒绝是可能的。证书资源之外的请求不得批准。使用禁止算法或无效证书请求的子 CA 可能需要更正。持续无功能的 CA 可以根据已发布的规则采取行动。未授权的供应商不能简单主张成员的权利。
提供者应发布映射到规则和补救措施的理由。“不支持”应标识问题是协议、概况、资格、安全还是容量。持有者应能够在其认为标准或政策被误用时请求审查。
研究人员还应验证事件发生时的公共文件。服务功能会变化。LACNIC 的当前页面记录了自 2019 年以来的委托可用性,而早期的缺失不能从今天的表格推断。APNIC 和 RIPE 发布服务已演变。公平的历史分析对声明进行日期标记,而不是将当前能力向后投影。
操作证据优于修辞。章程可能承诺持有者控制;成功的标准交换显示了其中一个方面。服务页面可能承诺委托;可重现的迁移差距显示了限制。单个项目不能解决整个机构。
这种纪律保护了成员和 RIR。它使真正的排斥可见,同时过滤掉由不合格范围或损坏的子软件引起的失败。密钥自主权需要足够强的证据来支持修复,而非足够宽泛的口号来适应每个挫折。
资源号协会可以定义互惠契约
NRS 声明的关注持有者参与、准确注册和对任意注册权力的限制使委托 RPKI 成为自然的测试案例。该组织可以通过定义具体的权利和互惠义务来做出最大贡献。
其第一个产品可以是区域委托访问矩阵。对于每个 RIR 和相关持有者类别,它将记录资格、管辖条款、父协议、支持的证书概况、发布选项、测试能力、迁移序列、支持路线、费用、撤销规则和审查。每个条目将链接到当前的第一方材料并带有验证日期。
第二个可以是合规性和迁移诊所。成员将使用维护中的 CA 软件运行授权的测试用例,保留结果,并在发布前寻求提供者更正。诊所可以区分子缺陷和父缺陷,并共享修复而不暴露密钥或资源细节。
第三个可以是选择委托的成员的连续性契约。参与者将维护命名联系人、密钥恢复证据、当前对象监控、发布测试和继任计划。NRS 可以提供模板和练习,而非认证其无法独立保证的安全。
第四个可以是区域治理中的代表。当迁移要求可避免的先断后建、支持条款不明确或委托用户获得较弱的事件访问时,NRS 可以提交基于证据的提案。它可以要求董事会解释成本、安全约束和实施计划。
NRS 应对自己的倡导施加限制。私钥不是财产权、永久注册权或免受法院命令保护的证明。区域父机构仍然是证书链的一部分。成员运营的 CA 可能失败并可能面临成比例的行动。NRS 第一方材料不证明每个 RIR 接受其分析或其拟议契约已强制实施。
互惠框架很重要。成员并非要求无责任地持有密钥。他们要求承担责任所需的工具、标准、迁移和公平待遇。RIR 不交出权威资源范围。他们接受当成员选择委托时,子签名行为的控制属于子 CA。
该契约加强了路由安全。它创造了更有能力的运营商,保留了低负担的托管路径,并使集中的功能在不必动摇层级的情况下具有可竞争性。
反对意见在揭示隐藏成本时最强
第一个反对意见是委托 CA 增加了可能失败的系统数量。是的。托管集中化可以提供专业的密钥保管和存储库韧性。委托牺牲了一些集中运营效率以换取签名权力分离和本地集成。答案是知情选择、混合发布和可执行的最低卫生要求,而非强制委托。
第二个反对意见是父机构不能允许迁移期间重叠而不双重认证。重叠确实带来风险。但提供者可以预验证子 CA、分阶段发布并约束任何过渡性重复范围。当协议或政策阻止重叠时,他们可以公布限制并提供协调切换与快速回滚。“无重叠”不应意味着“无迁移工程”。
第三个反对意见是开放标准已经解决了平等问题。标准解决了关键的技术部分。它们不解决资格、费用、支持、通知、测试平等、迁移顺序或补救。合规端点仍可能实际不可访问。
第四个反对意见是无惩罚规则会迫使 RIR 补贴昂贵用户。他们不必。透明的成本定价和合理的支持边界与平等地位兼容。惩罚意味着与合法成本和风险无关或不相称的负担,而非每项服务差异。
第五个反对意见是本地密钥持有鼓励错误的所有权主张。这种修辞风险存在。文档应明确指出边界:密钥认证子签名对象在已认证的范围内。它不创造法律头衔或覆盖有效的父行动。
第六个反对意见是委托用户如果失败可以简单地返回托管服务。返回是有用的,但也是一次需要当前权限、安全对象替换和密钥退役的迁移。它应被设计、测试且无污名。失败应产生学习而非在持有者仍合资格的情况下永久排斥。
最后一个反对意见是可能只有少数人想要委托。没有可靠的全球分母支持精确份额,少数派权利仍可以约束集中服务。成本应与需求成比例,但名义支持不足当该选项是信任模型的一部分时。
这些反对意见将主张缩小到可辩护的范围。权利不是普遍自我认证、免费定制支持或安全豁免。它是合格的持有者准备接受职责时可用、基于标准且公平管理的选择。
委托权利章程可以简短且可执行
每个提供认证的 RIR 应与技术文档和服务条款一起发布委托权利章程。它不必是宏大的宪法语言。它应回答运营商必须做出的决定。
资格:识别哪些直接成员、代理用户、遗留持有者、国家注册机构和授权代理人可以请求子证书,以及根据哪个协议。说明所需证据和预期响应时间。
互操作性:列出支持的标准、概况、算法和协议版本。提供端点、测试用例、弃用通知和合理的合规性响应。接受任何满足发布要求的实现,而非单一首选品牌。
选择:提供托管、委托和可用的混合发布模型,不附带无关的会员服务损失。发布费用和支持边界。允许授权的托管代理人,同时保留持有者的权力。
迁移:描述从清点到旧 CA 退役的每个状态,包括是否可能重叠、预验证如何工作、哪些人员在场、什么监控证明完成以及紧急恢复如何发生。
操作:说明持有者对密钥安全、清单、撤销信息、发布、联系、路由意图和继任的职责。说明父机构对授权准确性、协议可用性、通知、事件证据和其边界的支持的职责。
不利行动:定义撤销类别、紧迫性、通知、治疗期、批准者、证据、审查和恢复。将持续技术失败与短暂中断区分开,安全紧急与行政争议分开。
可移植性:解释持有者如何更改 CA 软件、发布提供者、托管代理人或部署模型。提供可导入的状态,同时兼容密钥安全,并保留历史记录。
问责:发布带有诚实分母的服务度量,报告严重的提供者导致的事件,并提供独立审查途径。通过 RIR 既定治理邀请社区修订。
章程应是可测试的。成员可以指出未响应的、不支持的合规交换或未记录的迁移步骤。机构可以指出失败的持有者义务。分歧变得更狭窄和更可解决。
这样的章程不会让 RIR 成为每个委托存储库的担保人,也不会让持有者独立于资源注册。它将把有吸引力的服务描述转换为互惠承诺。这正是将密钥持有从技术特征转变为可执行的制度选择的关键。
衡量行使的选择,而非理论可用性
RIR 经常报告 RPKI 覆盖范围或对象计数。这些度量不揭示委托选择是否可用。
区域服务可以报告符合条件的请求、完成的入职、中位数和父关系时间范围、按原因划分的合规性失败、按模型划分的迁移、紧急恢复、自愿返回托管服务和强制撤销。计数需要清晰的报告期和持有者类别,在隐私允许的情况下。
迁移度量应将准备与生产切换分开。运营商选择的长时间准备期不同于父延迟。报告预期和实际的授权缺口、外部验证成功和未解决事件。如果预期对象仍然不可用,不要称证书颁发完成。
支持度量应标识哪一方控制了故障。父端点、发布服务、子软件、本地密钥、账户资格和注册状态是不同的类别。这使投资可以跟随重复出现的问题。
运营商可以维护自己的就绪分数:当前密钥恢复、有效清单和撤销信息、外部存储库验证、活跃联系、经过测试的父交换、记录意图、软件支持状态和继任计划。分数应促进行动,而非成为夸大安全的公共徽章。
NRS 和研究人员可以比较各区域的已发布权利和授权测试。他们应避免简单的排名。一个委托用户少的区域可能有高度可用的服务;另一个用户更多的区域可能反映市场结构。采用不是公平的证据,低采用不是阻挠的证据。
最有揭示性的度量是成功更改模型而不意外丢失有效授权。它一起测试了文档、身份、标准、父操作、子就绪、发布、监控和补救。
目前没有完整的公共数据支持全球委托请求接受率、迁移失败率、成本比较或路由影响概率。这个局限性属于每个严肃的分析。这也是机构发布有边界的服务证据的理由。
目标不是最大化委托。是显示符合条件的成员在合理时可行使其选择权,而留在托管的成员是出于知情偏好而非实际束缚。
自主权是选择责任的能力
委托 RPKI 在操作性 RPKI 历史的大部分时间以区域形式存在。开放标准使父子配置和单独发布成为可能。现在多个区域描述了自我运营的认证,软件存在于 RIR 控制之外。这些是实质性的成就。
剩下的治理问题是该选项是否作为一种权利而非例外运作。合格持有者能否发现条款、使用合规子 CA、测试失败、选择发布、安全迁移、获得支持、挑战父错误以及更改工具而不受无关惩罚?
私钥持有只回答了一部分。它防止托管提供者作为子签名,并允许本地安全和自动化。它不消除父证书、不保证存储库可用性、不证明资源头衔、也不免除子的操作职责。
标准、迁移支持和免罚选择必须共存。没有迁移的标准使已安装的托管用户成为俘虏。没有互操作性的迁移可能将他们绑定到一个工具。没有平等信息、支持和审查的技术选择可以创造二等会员身份。没有持有者义务的平等待遇可能负担每个依赖方。
RIR 应保留强大的托管服务。这是许多成员负责任的选择,也是实际采用的主要贡献者。他们还应使委托和混合模式明显可用,因为当密钥保管可以根据运营商需求与父权力分离时,信任更强。
选择委托的成员应接受完整的肯定契约:安全密钥、当前对象、有韧性的发布、受监控的意图、活跃联系和经过测试的继任。他们不应将本地保管描述为逃避合法注册或证书范围。
NRS 可以通过证据、合规练习、迁移援助和区域提案使这种平衡可见。其倡导在同样清晰地主张义务和权利时具有可信度,并避免超出技术和合同记录的声明。
持有自己密钥的权利最终是选择责任的权利。它意味着父机构不能仅因行政便利要求交出子签名行为,子 CA 不能在没有胜任运营的情况下要求信任。在这些立场之间有一个成熟的制度安排:开放、可移植、可审查、安全进入和退出。
当这种安排存在时,委托 RPKI 不是关于主权的口号。它是加强路由安全及其上方机构合法性的实际职责分离。
来源
- IETF, RFC 6480,An Infrastructure to Support Secure Internet Routing:https://www.rfc-editor.org/rfc/rfc6480.html
- IETF, RFC 6484,Certificate Policy for the Resource Public Key Infrastructure:https://www.rfc-editor.org/rfc/rfc6484.html
- IETF, RFC 6486,Manifests for the Resource Public Key Infrastructure:https://www.rfc-editor.org/rfc/rfc6486.html
- IETF, RFC 6489,Certification Authority Key Rollover in the Resource Public Key Infrastructure:https://www.rfc-editor.org/rfc/rfc6489.html
- IETF, RFC 6492,A Protocol for Provisioning Resource Certificates:https://www.rfc-editor.org/rfc/rfc6492.html
- IETF, RFC 8181,A Publication Protocol for the Resource Public Key Infrastructure:https://www.rfc-editor.org/rfc/rfc8181.html
- IETF, RFC 8211,Adverse Actions by a Certification Authority or Repository Manager in the RPKI:https://www.rfc-editor.org/rfc/rfc8211.html
- ARIN,RPKI Deployment Options:https://www.arin.net/resources/manage/rpki/options/
- ARIN,RPKI Frequently Asked Questions:https://www.arin.net/resources/manage/rpki/help/faq/
- ARIN,Delegated RPKI:https://www.arin.net/resources/manage/rpki/options/delegated/
- ARIN,Repository Publication Service:https://www.arin.net/resources/manage/rpki/options/rps/
- RIPE NCC,Using the RPKI System:https://www.ripe.net/manage-ips-and-asns/resource-management/rpki/using-the-rpki-system/
- RIPE NCC,Using a Delegated Certification Authority:https://www.ripe.net/manage-ips-and-asns/resource-management/rpki/using-a-delegated-certification-authority/
- RIPE NCC,RPKI for PI and Legacy End Users:https://www.ripe.net/manage-ips-and-asns/resource-management/rpki/resource-certification-rpki-for-provider-independent-end-users/
- RIPE NCC,RPKI Test Environment:https://www.ripe.net/manage-ips-and-asns/resource-management/rpki/rpki-test-environment/
- RIPE NCC, RIPE-847,Revocation of Persistently Non-functional Delegated RPKI CAs:https://www.ripe.net/publications/docs/ripe-847/
- APNIC,APNIC Now Supports RFC-Aligned Publish in Parent Self-Hosted RPKI:https://blog.apnic.net/2020/11/20/apnic-now-supports-rfc-aligned-publish-in-parent-self-hosted-rpki/
- APNIC,How to Run Delegated RPKI in Krill:https://blog.apnic.net/2020/12/23/how-to-run-delegated-rpki-in-krill/
- APNIC,Resource Public Key Infrastructure:https://www.apnic.net/community/security/resource-certification/
- LACNIC,Resource Certification:https://www.lacnic.net/640/1/lacnic/resource-certification-rpki
- Number Resource Society,Our Charter:https://nrs.help/our-charter/
- Number Resource Society,Frequently Asked Questions:https://nrs.help/faq/

