摘要

  • NRO 在 2025 年 12 月更新的 RPKI 路线图中，将短期 Trust Anchor 证书列为核心功能；当时提供者为 APNIC、ARIN 和 LACNIC，并以 2025 年底作为五个 RIR 全部提供该功能的目标。
  • 2026 年 8 月 29 日，AFRINIC 公布的 TAL 仍可取得一张自签名根证书，其有效期从 2020 年 3 月 30 日延续至 2030 年 3 月 28 日。
  • 这说明公开证据尚未闭环，而不是证明服务中断、路由失效或验证失败。现有路线图没有定义“短期”的最长时限，也没有公布 AFRINIC 的延期或例外决定。
  • 一份合格的交付凭证应连接功能定义、证书签发、指纹、TAL 公钥连续性、仓库可用性、依赖方刷新观察、例外、回退和更正记录。

目标日期已经过去，在线证书没有解释结果

NRO 路线图里最值得追问的内容只有一行。功能名称是“Short-lived TA certificates”；“当前提供”一栏列出 APNIC、ARIN 和 LACNIC；五个 RIR 全部提供的目标日期则写着“End of 2025”。

该页面最后修改于 2025 年 12 月 2 日。当时它仍是一份面向未来的计划，而不是年末完成验收表。路线图本来就可以记录意图。问题在于目标日期过去后，公开记录没有增加第二个对象，用来区分已经交付、批准例外、推迟实施、修改定义或尚未完成。

AFRINIC 的在线材料把问题落到了一个可重复检查的技术对象上。2026 年 8 月 29 日，其 Trust Anchor Locator 可以正常获取，首个地址指向 RPKI 仓库中的 AfriNIC.cer。这张自签名证书的名称为 AfriNIC-Root-Certificate，序列号为 E5CF72BA6C7E9E28，notBefore 是 2020 年 3 月 30 日，notAfter 是 2030 年 3 月 28 日。

文件可以下载，仓库地址有效，指纹也能记录。这些事实不构成事故证据。它们提出的是一个更窄的问题：共同目标过去八个月后，AFRINIC 仍在提供一张有效期约十年的证书，公开路线图却没有说明这项在线状态与“短期证书”目标之间是什么关系。

可能存在完全正常的解释。路线图或许没有及时更新；AFRINIC 或许采用了未在该页链接的定义；替换可能正在测试、等待受控签发，或者获得了例外；现有证书也可能需要保留到预定切换点。冻结的公开资料无法在这些解释之间作出选择。

因此，当前首先是证据缺口，而不是技术故障。机构不应让运营者靠猜测来补齐一个已经到期的承诺状态。

没有公开定义，“短期”就不能直接成为判决

十年有效期与“短期”并列，直觉上很容易得出未达标结论。但这一步超过了来源能够支持的范围。

NRO 路线图没有给出最长有效期、正常续签周期、重叠窗口或例外授权规则。配套的 RIR 功能基线也没有给出 AFRINIC 的带日期验收记录。公开材料既没有说两年，也没有说一年或九十天。任何具体阈值都只能是外加的假设。

在线证书仍然具有证据价值。它不是宣传用语，也不是未来预测，而是从 AFRINIC TAL 所列地址取得的运行对象。它能证明某个观察时点的证书状态，却不能替路线图补写定义，更不能代替负责机构作出验收决定。

基础设施问责必须把三个对象分开：承诺说明准备做什么；运行工件说明当时能取得什么；交付凭证说明该工件是否满足既定条件，或者为何仍处于例外、延期或未完成状态。把三者合并，最终只会奖励公告，而不能证明实施。

状态表不需要复杂。它只需明确标注：按已公布定义完成；在已识别例外下完成；延期至新日期；由另一控制措施替代；尚未完成。没有更新不是第六种技术状态。

TAL 固定的是信任公钥，不是永远不变的证书

RFC 7730 解释了一个重要边界：缩短证书有效期，并不必然要求每个运营者重新分发一项新的信任决定。

TAL 包含证书获取地址以及用于核验 Trust Anchor 证书的公钥材料。被引用对象必须是当前有效、自签名的 RPKI CA 证书，其公钥必须与 TAL 中的公钥一致。证书因续期或资源变化而重新签发时，信任锚密钥应保持稳定，新证书继续从稳定 URI 提供。

这套设计把公钥连续性与证书寿命分开。AFRINIC 可以保留依赖方已经固定的信任关系，同时用新证书表达当前资源和日期。普通续签不等于信任锚换钥。

它也把“交付”拆成多个环节：证书必须正确签发，仓库必须在预期地址提供，依赖方软件必须获取证书，检查其当前有效、自签名状态与 TAL 公钥匹配，并完成本地接受检查。RFC 7730 建议在仓库重新同步期间以及缓存证书到期前执行这些动作。

所以，“已经签发短期证书”仍不足以证明切换完成。真正有用的是一条证据链：寿命规则、签发结果、公钥匹配、仓库发布、有限范围的获取观察、例外处置和可用的纠正路径。

这条证据链也不能与路由结果混为一谈。现有资料没有证明任何路由变成 RPKI Invalid，没有证明路由器拒收前缀，也没有证明依赖方刷新失败或缓存了错误对象。那些都是需要独立观测的下游事件。

更短的时钟只是重新分配风险

短期证书的价值，不在于“短”天然等于安全。更短的有效期可以限制旧状态继续被接受的时间，也能把续签从罕见操作变成经常接受检验的流程。

但收益依赖自动化。更频繁的签发与发布可以更早暴露流程缺陷，同时也压缩临近到期时诊断和修复问题的时间。长期证书减少关键续签时刻，却允许旧的资源与日期表达持续更久。两种做法改变的是风险分布，而不是消灭风险。

因此，“已实施”不应只表示相关代码已经存在。验收记录还应说明哪张生产证书体现了规则、何时开始切换、新旧状态如何重叠、仓库可用性如何检查、观察了哪些验证器，以及下一张证书无法按时提供时如何回退。

这些信息不要求披露私钥、HSM 布局或可被攻击者利用的步骤。日期、散列值、汇总结果和观测边界足以建立问责。

缺少的是一张可验证的交付凭证

凭证第一部分应先定义“短期”：通常有效期、提前续签时间、重叠规则和例外批准者。如果它只是相对于旧做法更短，也应写明比较基线。

第二部分记录公开证书事实：负责 RIR、序列号、SHA-256 指纹、notBefore、notAfter、仓库 URI，以及证书公钥与 TAL 一致的确认。

第三部分要区分三个范围：权威发布点是否提供预期字节；声明过的依赖方样本是否成功获取和接受；测量范围之外的未知总体。样本成功不能被放大成“整个互联网”都已完成切换。

例外也可在不暴露敏感讨论的情况下公开：例外编号、原因类别、责任人、复核日期和关闭条件已经足够。最后，更正必须追加而不是覆盖。指纹、日期或功能分类发生修正时，旧状态仍应保留。

这是五个 RIR 共同承诺中的 AFRINIC 检查点

NRO RPKI Program 是协调机制。它可以统一定义、减少不必要差异，让跨多个区域持有资源的运营者更容易比较基本安全功能。

协调并不意味着 NRO 运营 AFRINIC 的证书颁发机构。AFRINIC 负责自己的 Trust Anchor 证书签发和发布；依赖方软件决定刷新与接受行为；网络运营者决定部署方式，以及如何把验证数据用于路由政策。

因此结论必须保持克制。AFRINIC 证书提供了共同承诺下的一次可重复观察。它不证明 AFRINIC 的 RPKI 服务已经损坏，也不证明 NRO 故意错误描述实施状态。它证明的是，公开证据目前还无法把 2025 年底目标连接到一个定义清楚、已经验收的 AFRINIC 生产状态。

修补并不困难。NRO 可以保留历史行，并补充功能定义、各 RIR 状态、证据日期和例外说明；AFRINIC 可以公布证书寿命政策及下一次签发的有限验收事实。信任锚在技术上应当平静无事，但它从承诺走到生产的路径必须能够被重建。

Sources