摘要

  • RFC 9691 允许信任锚通过 TAK 对象发布后继密钥，但依赖方在 30 天接受计时期间仍使用当前密钥进行生产验证。
  • 依赖方必须验证前任与后继 TAK 的双向关系，并持续观察密钥与证书地址没有变化。
  • 单个验证器完成切换，只能证明该观察者的状态，不能证明全网已经采用新密钥。

RFC 8630 定义的信任锚定位器（TAL）包含证书获取地址和用于验证该自签名证书的公钥。它是带外分发的初始信任材料。正因为如此，信任锚换钥不是一次普通的仓库对象更新。

RFC 9691 增加了带内的信任锚密钥对象（TAK）。当前 TAK 可以列出当前公钥、证书地址、后继公钥及其地址。依赖方看到后继密钥时不会立即采用，而是先用后继密钥执行自顶向下验证，确认后继 TAK 存在，并核对两边的连续性：当前 TAK 指向后继，后继 TAK 又把当前密钥列为前任。

首次验证成功后，依赖方为这把后继密钥启动 30 天接受计时器，同时继续使用当前密钥进行生产验证。在计时结束前的成功验证中，所列密钥和证书 URL 必须保持不变。如果后继密钥消失或验证失败，计时器会被取消。只有满足这些条件并完成等待期，依赖方才把后继密钥设为当前密钥。

这意味着运营方发布成功、某个依赖方完成验证、计时器连续运行、依赖方正式切换，是四种不同事实。任何一种都不能代替其余状态，更不能代表所有依赖方。

能力差异还会延长共存期。不能处理 TAK 的依赖方会继续使用 TAL 或人工配置中的密钥。RFC 9691 因而指出，运营方可能需要同时保留旧、新密钥对，并在不同目录中发布相应材料。旧 TAL 客户端与仍在接受期内的新客户端，虽然都使用旧密钥，却不是同一种状态。

RFC 6489 的 CA 换钥流程也采取分阶段方法：创建新的 CA 实例，发布证书、CRL 与清单，留出发现期，重新签发下级产品，最后退役旧实例。RFC 6916 对算法套件迁移进一步区分 CA 就绪、产品重签、依赖方就绪、过渡期和旧算法终止。

接受账本应绑定当前与后继密钥指纹、证书 URL 集合、两份 TAK 的哈希、首次成功验证时间、计时开始与连续观测、切换时间、验证器身份和版本。对于仍依赖 TAL 的群体，还应单列支持范围、退出条件和批准终止旧密钥的责任主体。

这是一项治理层推论，不是 RFC 强制规定的新审计格式。它的作用是把各项局部证据连起来，同时阻止运营方把一个样本误报为普遍采用。

来源