摘要

  • RFC 6916 把 RPKI 算法迁移设计为证书颁发机构、发布仓库和依赖方共同完成的顺序流程，而不是某个软件组件单独升级。
  • 自上而下的安排要求新旧算法套件的签名产品在过渡期并行存在，再逐步要求验证方就绪，最终撤下旧套件。
  • 文件预期迁移可能持续数年，却没有定义紧急迁移机制。它服务于有计划的替换，无法单独应对突发的密码学失效。

密码学变更牵动整条链

在资源公钥基础设施（RPKI）中，已签名声明沿着层级链条传递。证书颁发机构（CA）为下一级 CA 签发证书；下级机构再为树中更深处的资源签发证书和其他签名对象。依赖方（RP）下载已发布材料并验证这条链。网络运营商随后可以把验证结果纳入自己的路由策略。

这些环节各有边界。证书签发了，不等于所有仓库都发布了对应对象；对象已发布，也不等于所有 RP 都能验证。验证结果本身更不会决定路由器接受哪条路由，最终策略仍由运营商设定。RFC 6916 要解决的因此不是“换一个哈希或签名算法”这么简单，而是如何在变更算法套件时，维持各环节之间可用的信任路径。

RFC 6916《资源公钥基础设施（RPKI）算法敏捷迁移程序》于 2013 年 4 月作为 BCP 182 发布。作者署名包括 Roque Gagliano、Stephen Kent 和 Sean Turner。这是 IETF 社群形成的共识文件，不能把它说成任何一位作者个人发出的指令。RFC 6916

先定时间表，再选替代算法

RFC 6916 没有指定下一套算法。它在 2013 年要求先更新当时由 RFC 6485 规定的 RPKI 算法配置，再另行制定迁移时间表。RFC 7935 后来取代 RFC 6485，并给出本次查阅到的配置。因此，未来迁移必须更新适用的配置，不能只在证书上增加一个新算法标签。RFC 7935

时间表要列明五个日期：CA 必须能够使用新套件签发证书的时间、重新签发全部产品的时间、RP 必须就绪的时间、旧套件变为可选的时间，以及旧套件的终止日期。RFC 6916 将每个节点设在协调日期当日 UTC 午夜过后一分钟，并要求 CA 和 RP 在各阶段提供准备度指标。时间由此成为信任系统的运行条件：仓库、验证软件和证书都要在指定日期支持正确版本。

算法迁移也不同于普通的密钥轮换。RFC 6489 说明在算法套件不变时如何更换 CA 密钥；RFC 6916 处理的是算法套件本身改变，影响证书、撤销列表、清单和签名对象。能更换一把密钥，并不足以证明整个套件迁移已经解决。RFC 6489

为什么父级先走

迁移按层级自上而下推进。父级 CA 尚不能签发新套件证书时，子级 CA 就无法申请该证书。文件也避免让 CA 证书的签名算法与其主体公钥分别属于不同套件；否则就会产生混合套件证书和更复杂的仓库结构。RFC 6916 警告，缺少层级顺序可能使发布数据量呈指数增长。

在这里，层级就是控制面的组成部分。父级准备情况构成子级的实际依赖，子级无法越过它单独切换。标准把“准备、签发、验证方支持、撤下旧套件”的顺序公开出来，但并未声称存在某个中央机构可以命令全网同时迁移。

并行发布换来验证时间

分阶段迁移让旧套件继续承担生产用途，同时引入并测试新套件。阶段 0 只有当前套件。阶段 1 从 CA 就绪日开始：非叶节点 CA 必须能处理新套件请求，但 RP 在生产环境仍使用旧套件。新套件产品可先用于测试，最好放在独立发布点。

阶段 2 从 CA 启动日开始。每一组签名产品都必须同时有旧、新套件的版本。RP 可以测试新产品，同时继续使用旧产品。两套产品的对应输出——例如 ROA 内的路由源授权数据——应当一致，但需要考虑发布时间差异。如果大量 CA 没有准备好，时间表就必须重新发布；RP 此时尚未被要求全面支持新套件，但验证问题会成为延后下一阶段的理由。

阶段 3 从 RP 就绪日开始，所有 RP 都应能验证新套件，并被鼓励优先采用新产品，而两套产品仍然并行存在。阶段 4 从“Twilight”日开始：RP 和 CA 必须使用新套件，旧套件产品可能仍然存在，却不再保证完整。到了终止日期，旧套件应被弃用，其信任锚定位符也要从发布点撤下。RFC 6916，第 4、10 节

这种回退空间有明确期限。尚不能验证新产品的 RP，在旧产品仍被要求保留且可用时，可以暂时继续使用它们。并行不是永久双轨承诺，而是一段有边界的时间，用来比较结果、测试实现并找出落后的环节。RFC 6481

失败会影响链条两端

RFC 6916 描述了签发者和验证者两种失效情形。若 CA 到旧套件终止时仍未完成迁移，其签名产品将不再有效；未迁移的 RP 则会失去验证新套件产品的能力，最终可能只能看到不完整的 RPKI 路由信息。

这并不意味着所有路由都会消失。RP 产生的是验证结果，路由器和运营商随后决定如何处理。缺失或无效的对象可能影响路由源验证，但真实路由后果取决于当地策略、软件和涉及的资源。标准说明了验证视图不完整的风险，却没有量化一次中断，也没有规定所有网络都必须拒绝相关路由。

谨慎的多年时限同时暴露出适用边界。RFC 摘要明确说迁移预计要花数年，而且没有规定紧急迁移。对于需要广泛实现和发布支持的计划变更，这种节奏或许合理；但若当前算法或密钥在计划完成前就不再安全，应该怎么办？RFC 6916 没有提供危机处置程序。

Gagliano 在公开记录中的位置

Cisco 的公开作者页面称 Gagliano 是 Principal Solutions Engineer，并列出他此前在 LACNIC、ANTEL 和 Sprint 从事工程与架构工作的经历。这些资料显示其履历横跨运营商、区域注册机构和供应商，但无法证明他为何支持 RFC 中的某项具体条款。可以直接由 RFC 支持的说法更有限也更可靠：Gagliano 共同撰写了一套共识程序，把迁移准备视为整条 RPKI 链的属性。Cisco 作者简介

本次查阅的 RFC 7935 算法配置规定 RSA 2048 位密钥与 SHA-256。2026 年的一份信息类 Internet-Draft 正在研究后量子候选方案和迁移架构，包括并行发布与混合树。作者明确说明，该草案不会更新 RFC 7935 或 RFC 6916，不会选定生产配置，也不会批准把评估中的选项用于实际 RPKI。研发议题出现，并不等于生产迁移已经获批或排期。RFC 7935；draft-yoshikawa-sidrops-pqc-rpki-02

RFC 6916 的长久贡献在于流程设计：它把“采用更强算法”拆成可观察的依赖——CA 签发新套件，发布点存放对应产品，RP 验证这些产品，并在准备情况得到检验之前保留旧路径。它也把未解问题摆在台面上：如何度量准备度、如何协助落后参与者，以及如何把紧急处置与计划迁移区分开。运营商和标准制定参与者仍需作出这些后续决定。