摘要

  • RFC 8181 规定多项发布操作必须整体成功或整体失败，但成功响应只证明客户端与服务器之间的事务。
  • RFC 9286 用签名清单绑定发布点当前对象的文件名和哈希；RRDP 再以会话、序列号、快照和增量向依赖方提供仓库视图。
  • 可核验的账本应区分“已请求、已提交、与清单一致、已公开提供、已被依赖方观测”，并为每个状态保存时间与证据范围。

RPKI 发布常被描述为一个动作：生成或撤回对象、上传仓库、等待验证器使用。相关标准却给出了更细的链条。认证机构或其发布客户端发起操作，发布服务器提交事务，清单描述当前对象集合，分发服务提供仓库视图，依赖方则按照自己的抓取周期取得并验证这些视图。

RFC 8181 保护第一道边界。客户端和服务器通过签名消息相互认证；一次请求可以包含多个发布与撤回操作，服务器必须原子处理。替换或撤回对象时，请求携带目标 URI 上既有对象的哈希。若哈希不符，服务器可以拒绝对意外状态的覆盖。这既是并发控制，也是事后证据。

成功响应因此重要但有限：它证明指定服务器接受了整项经认证的请求，却不证明公开 RRDP 通知已经更新、rsync 已提供新文件，或某个依赖方已经抓取。RFC 8181 明确把客户端—服务器发布协议与依赖方可见的分发接口分开。

下一层是 RFC 9286 定义的清单。清单是签名对象，列出与某一 CA 发布点关联的对象文件名和内容哈希。单个对象的签名不能识别所有旧版本替换或传输途中删除；依赖方把实际取得的集合与清单比较，才能发现特定的遗漏、修改或重放。

清单的范围不能模糊。它覆盖相关 CA 当前的证书、最新 CRL 和其他签名对象；多个 CA 实例共享发布点时，各自清单只覆盖各自产品。因此，目录列表本身不能替代“哪个 CA、哪份清单、哪个对象集合”的证据。

RFC 9286 还把清单签发与变更完成连接起来：对象集合发生最终变更时必须生成新清单，被替换对象的哈希要同步更新，新清单须在 nextUpdate 前发布。这形成了明确的集合证据，但仍不回答某个缓存或依赖方此刻看到哪一代。

RFC 8182 定义的 RRDP 补上分发序列。通知文件带有会话标识和当前序列号；快照提供完整视图，每个增量对应一次序列推进，包含该事件中新建、替换和撤回的对象。依赖方可以获得一致的时点视图，或逐步追上仓库状态。

序列号不是全球时钟，只属于特定会话与仓库服务器。依赖方可能在通知更新前抓取，可能命中缓存，也可能拒绝有问题的增量并回退到快照。因此，“序列号已增加”不足以构成完整回执；还需记录会话、通知哈希、传输方式、观测者和观测时间。

从提交到可见的账本应保存四组证据。第一组是请求：客户端和服务器身份、签名消息哈希、操作标签、URI、前序哈希、新对象哈希及请求响应时间。原子批次失败时，账本不得虚构部分成功；成功时应保存原始签名响应，而不是只留一个绿色标记。

第二组是服务器提交与清单：发布点、清单文件和哈希、thisUpdate、nextUpdate、CRL 哈希以及被枚举的完整对象集合。内部数据库提交可用于排障，但它不等于公开仓库观测。

第三组是分发：RRDP 通知 URI、会话、序列、通知/增量/快照哈希；若检查 rsync，则保存仓库 URI、观测时间和集合哈希。两种机制应分别记账，不能以一个通道的状态替代另一个。

第四组是有边界的依赖方观测：观测者身份、软件版本、抓取时间、传输方式、会话和序列、清单检查、对象集合检查及验证结果。一个观测只能证明一个依赖方在一个时间取得了某个视图；多个观测可以提高信心，但仍不是全球绝对状态。

账本可采用 REQUEST_AUTHENTICATED、SERVER_COMMITTED、MANIFEST_COHERENT、PUBLIC_VIEW_OBSERVED、RP_OBSERVED 和 EXCEPTION_OPEN。成功响应后出现旧视图可能只是时间顺序；序列已推进却出现清单不一致，则不能因“分发有变化”而判为健康。

公开 RFC 没有规定所有依赖方必须在同一个全球期限内取得变更，也不暴露私人缓存，更没有规定唯一的运营审计格式。某一依赖方未观测到，不证明全球缺失；某一依赖方已观测到，也不证明普遍收敛。

这份账本的价值不是许诺无法证明的同步，而是让每个跃迁可归因：客户端请求了什么、服务器提交了什么、清单枚举了什么、公共分发提供了什么、具名依赖方观测到什么。CA、仓库和依赖方各自在自己的权限范围内提供证据，账本只负责连接，不扩大任何一方的结论。

来源