摘要

  • RPKI CRL 仍必须携带 CRL Number，但依赖方只能检查它是否为非关键扩展、是否包含不超过 2^159-1 的非负整数，不能按其大小排序。
  • 适用的当前 CRL 必须同时被证书 CRLDP 指向，并在发行 CA 的当前清单中以相同文件名和内容哈希出现。
  • 选对 CRL 仍不等于证书未撤销、签名对象有效、路由来源获准、路由器执行策略或用户流量正常；每一步都要单独留据。

一个看似更新的对象为何不能胜出

先设定一个构造场景，而非真实事故。某 RP 获得两份同一 CA 的可解析 CRL。未被当前清单列出的那份 CRL Number 是 902；清单所列、且与 CRLDP 相符的那份是 901。902 更大，却没有被当前发布状态授权。若 RP 让数字获胜，就建立了第二套“当前”判定。

RFC 9829 正是要拆掉这套并行权威。RFC Editor 信息页和 IETF Datatracker显示，它是 2025 年 7 月发布、更新 RFC 6487 的标准轨 RFC。历史记录、引用清单、被引用记录与勘误检索提供文档沿革。冻结资料时没有匹配勘误；这并不证明任何实现合规。

“选更大编号”并非凭空产生。RFC 5280把 CRL Number 定义为单调递增序列。在可能遇到多份可用 CRL 的一般 PKI 中，它能帮助判断替代关系。

RPKI 先改变了问题的形状。RFC 6481约束 CA 的仓库发布结构；RFC 9286规定签名清单，逐项列出当前对象的文件名与内容哈希，其中包括该 CA 最新的 CRL。良构发布点只有一份当前 CRL，RP 不再需要让 CRL Number 从候选池中选举胜者。

字段合规不等于字段有权

RFC 9829 没有删除 CRL Number。每份 RPKI CRL 仍必须恰好有 AKI 与 CRL Number 两个扩展，不允许其他 CRL 扩展。RP 必须处理 AKI；对于 CRL Number，只检查非关键标记与数值边界，然后忽略其排序意义。

因此要分别记录三件事：字段存在、编码有效、字段是否有权决定当前对象。把它们压成一个“通过”，就会让有效语法冒充决策授权。

规范建议 CRL Number 与将要收录它的清单 manifestNumber 相同。这个建议利于排障和核对发布序列，却没有恢复“数值更大者优先”。两者不一致时，应产生诊断记录，而不是绕过清单。

当前 CRL 由两条指针相交而成

RFC 6487定义资源证书及 CRL Distribution Points。RFC 9829 更新了证书路径验证：当前 CRL 必须由发行者当前清单与证书 CRLDP 共同识别。

CRLDP 表明某张证书应查哪一对象，却不能证明仓库中的字节属于当前发布。清单表明 CA 当前承诺哪一文件及其哈希，却不能单独证明某张证书指向它。文件名一致而哈希不同，仍可能是替换；哈希放在无效或过期清单里，也没有可信发布权威。只有 CRLDP、当前清单条目与实际字节哈希汇合，候选对象才成立。

排序权没有消失，只是迁到清单。RFC 9286要求 manifestNumber 单调增加，并以 thisUpdate、nextUpdate、签名和清单 EE 证书共同界定当前状态。RP 还要处理回退与缓存规则。此前 RFC 9981 文章讨论清单编号触顶后通过新文件名开启比较纪元；本稿不重复那个恢复机制，只回答一个纪元内部为何不能再让 CRL Number 投票。

哈希证明 CA 承诺了哪些字节

清单能帮助发现旧对象替换、删除或传输途中修改。RFC 9829 将 fileList 哈希称为 CA 对“哪份 CRL 最新”的加密意图证明，并以此消除可能的重放路径。

但“意图”有边界。匹配哈希证明取得的字节与已验证清单的承诺相同，不证明清单尚在时限内，不验证 CRL 签名或密钥关系，也不回答目标证书序列号是否列在其中。CRL 本身仍须有效；验证 CRL 的公钥必须与验证证书的公钥相同；只有在适用 CRL 中找到序列号，才构成撤销判断。

RFC 3779规定 IP 与 AS 资源扩展。它描述证书层的资源约束，不把撤销结果变成正在运行的 BGP 路由。

仓库送达只是复制了一份材料

RFC 8182定义 RRDP 传输，rsync 也是常见获取路径。下载成功不决定当前清单。不同 RP 可能因时间、缓存与失败策略而使用不同已验证纪元。调查时真正有用的是“哪个清单、哪个哈希、哪条缓存规则”，而不是“看到了多大的 CRL 编号”。

RFC 9589 的既有文章拥有 CMS signing-time、文件 mod-time 与 RRDP/rsync 切换快速检查主题。它曾用 RFC 9829 支撑“文件时间不能选择当前 CRL”这一边界。本稿则展开被它留作旁证的完整机制：为何连 CRL 自己的编号也被撤销选择权。

撤销判断之后才进入路由链。RFC 6811把有效来源资料与 BGP 路由组合成本地验证状态；RFC 8210把验证缓存结果送往路由器。是否收到、如何应用策略、RIB/FIB 如何变化、数据包是否可达，仍是不同事实。

完整收据至少包含：CA 发布、仓库传输、当前清单选择、CRLDP/文件名/哈希汇合、CRL 验证、序列号查询、签名对象验证、来源状态计算、路由器接收、策略动作与流量观察。

这次标准化的动作是做减法

RFC 9829 保留 X.509 轮廓所需字段，却删去它在 RPKI 中多余的决策权。这与 Heng Lu 的最小初始规范相呼应：只协调必须共享的不变量，不让每个可见符号都膨胀成控制面。现实层要求把编号、清单、字节、验证与结果分开；运行代码优先则要求验证 RP 与路由器实际执行了什么。

最有力的测试不是正常样本，而是让未列入清单的 CRL 携带更大编号，再分别改变哈希、清单新鲜度、CRL 签名、发行密钥与序列号成员关系。每个失败都应有独立原因码。一个“RPKI 正常”的绿灯无法证明选择器没有偷走权威。

来源