摘要

  • RPKI 清单序号是某个 CA 对自身发布点文件清单所维护的本地顺序证据，不是全局时钟，也不描述网络此刻正在怎样转发。它的编码存在上限，错误发行能让后续清单再也无法大于验证端已经接受的值。
  • RFC 9981 允许不同的清单文件名建立新的序号比较纪元。验证端必须告警，发行方也不应把换名当作日常计数管理。
  • 新纪元只重置已记忆的序号基线。签名与证书验证、更晚的 thisUpdate、文件名与哈希清单，以及签名对象 URI 同 RRDP 或 rsync 位置的精确对应，仍须逐项通过。

一份更新、却永远不可能更大的清单

设想某个认证机构的发布软件出现一次致命算术错误。本应发行序号 7914 的清单，却写出了字段能够容纳的最大值 2^159 - 1。签名来自正确密钥，时间有效，文件名和哈希也准确描述发布点。若干 relying party 接受它，并保存了这个序号。

运营者发现错误，恢复计数状态，再发行一份修正清单。新清单在真实时间里更晚，密码学上无误，内容也合理，却无法通过旧的序号比较：合法编码中已经没有比已保存最大值更大的数。

问题并非普通的整数溢出趣闻，而是两类证据发生冲突。签名说明发行方确实作出了新陈述；序列说明新陈述不可能继承已接受的旧陈述。验证端若忽略序列，就为旧清单重放打开通道；若永远拒绝较小序号，又会把发布点冻结。两种反应各自保护着真实安全属性。

RFC 9981 选择能够被双方独立观察的最小断点：新的清单文件名。它并未授予发行方随意抹去历史的权力。文件名只是宣告“从这里开始，用一套新的序号历史比较”，其余证据全部延续。

清单究竟证明什么

RPKI 清单由 CA 针对一个发布点签发，列出发行方准备公开的文件名，并将每个文件名绑定到哈希。验证端借此发现文件缺失、内容被替换，或当前仓库视图不完整。

清单本身是 RPKI 签名对象，采用一次性 EE 证书。内容包括 manifestNumber、thisUpdate、nextUpdate、文件哈希算法以及文件名/哈希列表。CA 证书通过 id-ad-rpkiManifest SIA 指向清单。

证据范围非常有限。清单列出了某个 ROA 文件，不等于对应路由正在 BGP 中出现；列出了 CRL，不等于每个验证端都已取得它；验证端生成了 VRP，也不等于路由器已经消费。清单属于“发行方在某发布点声称应有哪些文件”这一现实层，验证结果与转发后果位于后续层。

恢复时必须守住这个边界。若把事故概括为“RPKI 信任坏了”，组织容易诉诸整体重置。更准确的判断是：一个发行方、一个文件名之下的序号状态变得不可继续。修复范围因此也可以保持局部。

为连续性而设的有限计数器

RFC 9286 要求每次发行新清单时把序号增加一。验证端将观察到的值与之前接受的值比较，要求新值更大。序号缺口能够提示中间状态被跳过，倒退能够提示陈旧清单或重放。

它不是全球时间戳。两个 CA 不共享序列；一个发行方的巨大序号也不会天然晚于另一方的小序号。即使在同一 CA 内，序号也不能代替时间。thisUpdate、nextUpdate、证书有效期、撤销状态和签名对象规则仍各自成立。

RFC 9981 指出，正整数编码上限为 20 个八位组，最大值是 2^159 - 1。正常运行根本不会自然耗尽：即使每秒发行一份，也需要大约 23,171,956,451,847,141,650,870 千兆年。问题不是容量规划，而是软件可以在一个错误赋值中跨越天文尺度。

异常加法、无延迟发行循环、损坏的恢复状态或直接写入最大值，都可能让验证端接受一个无法超越的序号。不同产品随后可能表现不同：有的在旧状态过期后恢复，有的会无限期拒绝。于是同一个发布点对一组验证端是健康的，对另一组却永久陈旧。

真正需要恢复的不仅是文件发行，还包括各验证端保留的比较状态。若只观察 CA 控制台或仓库 HTTP 状态，就看不到这一分裂。

文件名作为显式纪元边界

RFC 9981 规定：当清单文件名不同于此前与该 CA 关联的文件名时，验证端不得仅因新序号不大于旧序号而拒绝。若其余检查通过，验证端把新序号记录在新文件名之下，并从这里开始新的比较纪元。

这里的“文件名”不是仓库界面显示的随意标签。它是 CA 证书 id-ad-rpkiManifest SIA URI 的最后一个路径片段。CA 必须发行指向新位置的证书状态，把清单放在相应位置，并确保签名对象自己的 URI 绑定同实际获取路径一致。

一次可审计的转移因此包含三件事：CA 命名新的清单路径，仓库在该路径提供对象，验证端识别比较键发生变化。无需中央机构宣布全网重置，也不需要验证软件猜测一个更小的数字“大概比较新”。

验证端看见换名时必须通知运营者。告警不是装饰。它可能表示合法恢复、计划内 CA 过渡、配置错误，甚至更严重的密钥或发布面问题。签名能认证发行方，却无法自行说明为什么发行方要抛弃旧序列。

发行方不应例行换名。若每次重启、升级或仓库迁移都开启新纪元，单调序列就失去揭示倒退的价值，攻击者也获得更多机会把仍在有效期内的旧历史包装成新开端。例外权力之所以可控，正因为它罕见、留痕且需要解释。

新纪元没有重置什么

最危险的误读是把规则简化成“文件名新就接受”。RFC 9981 只回答一个问题：验证端应该用哪一份已保存的 manifestNumber 基线来比较。

新清单仍须通过签名验证，并由有效 EE 证书链到适用 CA。证书有效期、撤销和资源证书配置要求没有消失。清单结构、哈希算法、文件列表、缺失文件与哈希不匹配的处置仍受 RFC 9286 约束。

时间证据也保留。新文件名下的清单，其 thisUpdate 仍须晚于此前接受清单的 thisUpdate。攻击者不能把旧的已签名清单复制到看似新路径，借“新纪元”绕过时间比较。nextUpdate 继续限定发行方声明的有效窗口。

位置证据同样保留。清单 EE 证书包含签名对象 SIA URI。通过 RRDP 获取时，该 URI 必须同 RRDP publish URI 精确对应；通过 rsync 获取时，则须同 rsync URI 与路径一致。仓库管理员仅仅复制字节并改名，若签名引用仍指向别处，就没有形成规范定义的纪元切换。

清单也不会改写其所列对象。新纪元可以让新文件清单进入验证，却不能改变证书资源、ROA 前缀、CRL 状态或路由器输入。每份对象仍须在自己的证据链上成立。

多个 SIA 带来的分叉陷阱

“一个 CA、一个旧名、一个新名”的模型，在 CA 证书包含多个清单 SIA 时会失效。不同验证端可能支持或优先选择不同位置。若替换证书只移除一个旧文件名，却保留另一个旧名，一部分验证端看见新纪元，另一部分仍认为旧纪元延续。

于是双方都可能按自己选到的 URI 正确执行，却得出相反结果。一方在新名下接受较小序号；另一方把它同旧名下的最大值比较并拒绝。运营者很容易把分歧错判为缓存延迟、RRDP 同步问题或产品缺陷。

RFC 9981 的要求因此很严格：若依赖换名完成重置，新 CA 证书中不能再出现任何原有清单文件名。恢复方案必须盘点每一条 SIA、每一种传输路径和各验证端的选择规则，仅更新所谓“主仓库”地址并不够。

RRDP 与 rsync 是传输方法，不是两套事实。snapshot、delta 和 rsync 视图最终应指向签名 URI 与字节均一致的对象。HTTP 200 只证明数据到达，不能证明取得的是证书授权的对象。

为什么信任锚更难恢复

从属 CA 若污染清单历史，通常可以在上级认证关系之下按 CA 换钥规则建立新身份和新清单历史。过程仍需重叠发行、证书更新和对子节点保持连续，但上级 CA 能认证过渡。

信任锚没有更高层 CA。它的公钥与证书位置通过 TAL 等引导材料进入验证端。更换信任锚密钥或分发新 TAL，会面对更新节奏不一、旧安装长期存在和切换过急导致整棵树不可达的问题。

RFC 9691 的 TAK 对象改善了计划内换钥。当前信任锚可以声明后继公钥及其证书位置，验证端检查现任、前任和后继陈述的相互对应，并在接受计时器结束后迁移。它用当前已信任密钥建立可测试的带内桥梁。

但 TAK 不是绕过受损发布点的万能后门。验证端仍从当前信任材料开始，取得 CA 证书，验证清单与 CRL，之后才处理 TAK。没有预先部署连续性措施的信任锚，在紧急时仍可能遇到引导难题。因此，信任锚换钥能力要在事故前准备，且不能同文件名纪元恢复混为一个按钮。

只有不同验证端收敛，恢复才算成立

发行方签出新文件并不代表恢复完成。完成的定义应是：不同实现的验证端都取得准确对象，按 RFC 9981 接受纪元变化，验证文件清单，并对预期输出收敛。

演练必须使用抓取或合成的仓库材料，绝不能在生产把序号推近最大值。测试集合应包含正常递增、异常跳跃、最大值、同名下的小序号、新名下的小序号、新名但更旧的 thisUpdate、不匹配的签名对象 URI，以及仍保留某个旧 SIA 文件名的证书。

对每种验证产品和版本，记录取得 URI、旧名与新名、保存序号、时间比较、告警、验证结果、接受对象集合与 VRP 差异。产品之间的不同不是噪音，而是正式证据：它能在真实发行方依赖逃生机制前，揭示规范支持和状态保存方式的差异。

生产恢复也要保留同样账本。保存旧证书、旧清单、全部 URI、序号、时间和输出指纹；记录换名理由、批准人、新 SIA 以及预期影响；分别观察 RRDP snapshot、delta 和 rsync；在清除旧仓库材料前比较验证端与路由器输入。

回退边界必须预先定义。若新清单在签名、时间、URI 或文件清单上失败，答案不是再换一个文件名。应停止发行、保存证据，并在协议允许的范围内恢复最后一份可证明有效的发布状态。连续重置会把受控例外变成无法解释的历史。

来源