摘要

  • RFC 9589 要求 RPKI Signed Object 带有 CMS signing-time，并排除 binary-signing-time。
  • 仓库方和 relying party 可分别把该值写成 rsync 文件及 RRDP 落盘文件的 mod-time，从而在 RRDP 失败后减少无谓重传。
  • 该字段不是可靠时钟，不证明对象仍有效、清单仍当前、ROA 已被采用或网络正在转发。

两种交付之间的一枚小标记

RRDP 提供 snapshot 和 delta；rsync 提供文件树。它们负责交付，不负责裁决对象是否可信。RRDP 可能因 XML 损坏、TLS 证书过期或超时而不可用。此时 relying party 常已从 RRDP 拿到 DER 对象，却需要面对 rsync 的文件比较。

rsync 的快速判断会使用文件大小和修改时间。若 RRDP 落盘采用下载时刻，而服务器 rsync 文件采用另一时刻，第一次回退会再次搬运相同对象。RFC 9589 提供窄桥：签发者在 CMS 对象内提供 signing-time；仓库运营者应以它设置发布文件的 mod-time；relying party 也应以它设置从 RRDP 序列化的副本。两条路径获得同一比较坐标，rsync 便可省去不增加信息的传输。

这不是“时间拥有权”。它只是传输和存储层的协调值。节省带宽、磁盘 I/O 与 CPU 很有价值，尤其在故障时；但该价值不应被改写为“仓库是新的”或“对象应当被接纳”。

被签名，不等于时间可信

签名保护对象中携带的属性不被中途篡改，却不保证签发者时钟正确，不证明私钥正是在该时刻使用，也不证明对象那时已发布。RFC 9589 的安全考虑明确说：对 signing-time 的正确性没有要求，它不提供签名产生时间的可靠信息。

这种限制不是缺陷。RRDP 与 rsync 的转换只需要同一对象在两种序列化中采用一致值；它不需要一个能裁决真实世界的钟。即使值不准确，只要双方一致，传输优化仍可能成立。若要证明事故时间线，运营者需要受控日志、观测记录和保留对象；若要证明对象可用，则仍需 RPKI 验证。

同样，rsync 的相同大小与 mod-time 是“不传”的条件，不是字节相等的密码学证明。CMS、资源证书和对象专属规则没有被这个快速比较取代。

仍然必须逐层通过的证据

对象必须通过 RFC 6488 的通用规则及自身类型的额外验证。EE 证书要在资源证书链中有效，撤销状态仍重要。RFC 9286 的当前 manifest 提供签名文件清单；RFC 9829 进一步限定相关 CRL：它既要由证书的 CRLDP 指向，也要出现在签发 CA 当前 manifest 中且哈希匹配。

ROA 的范围尤其说明边界。它可授权某 AS 发起特定前缀，却不证明路由当前可见、被邻居选择、装入路由器或抵达目的地。RRDP 成功、rsync 回退成功、或一个时间字段被签名，都不会扩张这项声明。

因此应记录完整链条：URI 与字节哈希、传输决定、证书、CRL、manifest、对象验证、验证后输出指纹，以及最终供给的策略输入。HTTP 成功证明交付；少传字节证明节约；二者都不自动证明授权。

要演练的是实际回退

测试应覆盖正常 RRDP 后的 rsync 回退、坏 XML、过期 TLS、超时、文件缺失、尺寸或 mod-time 变化、EE 证书撤销以及对象不在当前 manifest 中。针对每个产品版本保存 URI、路径、哈希、signing-time、两端 mod-time、大小、是否传输、证书/CRL/manifest 结果和验证输出指纹。

多种验证器输出不一致，本身就是证据。省下传输却改变接纳对象集，不应算成功；传输多一些但输出相同，可能只是成本问题。声称支持某协议不是对已部署故障路径的证明。

来源