摘要

  • draft-ietf-keytrans-architecture-09 中的墓碑条目说明某个标签的最新版本应去新日志查询，并防止客户端在新日志故障时误收旧值。
  • 同一草案另行要求迁移期间继续监测两份日志；旧日志停止修改后，仍须运行足够长时间，让包括长期离线用户在内的相关客户端完成监测。
  • 因此，真正的关停条件应是一份“日志退役回执”：绑定旧日志最终树头、可信分发渠道、各客户端群体的完成证据、例外处理、决策人和恢复触发器。这是本文提出的治理工具，不是 KEYTRANS 的规范要求。

设想一部半年没有开机的手机。用户重新登录加密通信应用时，服务已经迁往新的 Key Transparency 日志。旧日志里的标签都放了墓碑条目，运营看板显示新版覆盖率接近百分之百，旧端点也已关闭。但手机还保存着迁移前的树头。它需要从那个历史状态一路核验到旧日志的最终状态，才能确认自己没有被隔离在另一条历史里。

此时，“迁移完成”与“证据闭合”分开了。客户端可能知道现在应去哪里查询，却无法完成过去应当完成的监测。架构草案直白地指出：如果旧日志在用户完成监测前关停，该用户可能失去发现旧日志某些不当行为的能力。

墓碑条目由此显出准确但有限的含义。它是一块方向牌，不是一张关停许可证。

墓碑条目解决的是新旧值顺序

Key Transparency 试图约束一个长期存在的信任弱点：端到端加密服务往往仍由服务商告诉用户“这个账号对应哪把公钥”。如果服务商遭到入侵或主动作恶，它可能替换密钥，让不同用户看到不同绑定。可搜索、受密码学保护的追加式日志，使账号持有者和联系人能够持续检查身份与公钥的对应关系，并发现分叉视图。

KEYTRANS 工作组章程同时强调，这只是一块构件。它不负责让不同加密通信服务整体互通，具体认证、传输、账号恢复和产品政策仍要在别的层次完成。这个边界对迁移尤其重要：共同协议可以定义怎样验证历史，但不能替每家服务决定要支持离线客户端多久。

架构草案预设了多日志场景。更换签名密钥、密码套件、部署模式，扩容，或从日志故障中恢复，都可能要求新日志接棒。客户端因此应当能够与多个独立日志交互；所有用户还必须遵循一致的 Search、Update 与 Monitor 指向政策，才能保持全局一致视图和可检测性。

渐进迁移的示例非常具体。查询先访问旧日志；只有当旧日志中该标签的最新版本是应用定义的墓碑条目时，才转向新日志。普通更新只写新日志，旧日志仅补上尚未存在的墓碑。这一顺序堵住了一条危险退路：新日志一时不可达，不能成为接受迁移前旧密钥的理由。

但墓碑并不证明新日志里的值正确，也不证明账号持有者已经核验迁移，更不证明所有客户端都看见了标记。把这些判断塞进一个布尔状态，会把协议的查询规则扩张成机构的风险决定。

两份日志意味着两条尚未结清的证据链

草案要求新旧日志像独立运行时那样分别接受监测。这句话使“数据已搬迁”与“旧历史可以销毁”无法混为一谈。

旧日志需要在一个明确时点停止接收修改，并留下最终树头。客户端要把自己过去保存的状态连接到这个终点。新日志要展示迁移后的标签版本，标签持有者需要处理相应 Update 并确认内容正确。若采用第三方审计、第三方管理、联系人监测或匿名访问，每一种模式还有自己的非串谋、时延与持续检查假设。

因此，“活跃设备已经升级”只是运营事实之一。安装了新版本，不等于执行过旧日志最终 Monitor；访问过新日志，不等于核验过本人标签；主设备已完成，不等于多年后恢复的备份不会带回更早树头；账号长期不活跃，也不等于用户放弃了可验证历史。

草案没有规定统一保留七天、九十天或一年。它只要求旧日志保持可用足够长时间，并提醒有些用户会离线很久。这不是缺陷，而是合理的权限边界。高风险企业通信、普通消费者消息服务和状态易失的网页客户端，对备份恢复、账号期限和监测频率的承诺不同。统一数字会把应用层责任伪装成协议常数。

最终树头提供终点，却不会替机构作决定

立即迁移的示例要求把旧日志最终树大小与根哈希通过可信渠道发给用户。用户据此执行最后的 Monitor 查询。标签持有者还要在新日志中处理迁移版本的 Update，建立新的监测状态并核验迁移。

草案给出两种分发思路：将旧日志最终坐标放进新日志的知名标签，并要求用户像监测自己的标签那样监测它；或随应用代码分发。两种方法都能建立共同的密码学终点，却都不会回答是谁选择了这个终点、哪些受支持版本确实收到它、遇到更早树头的客户端由谁处理。

协议草案把若干时钟写进配置：max_ahead、max_behind、必需的 reasonable_monitoring_window，以及可选的 maximum_lifetime。合理监测窗口表达标签持有者通常应多久检查一次，也帮助协议安排共同的“显著日志条目”。它不是在线人口普查。最大存续期可以约束证明与存储，却不能自动变成面向用户的支持期限。

工程团队想减少双日志成本，产品团队想淘汰旧客户端，安全团队想移除旧密钥，隐私团队想缩短数据保留。这些理由都可能成立。单独任何一条都不能证明关停不会破坏仍受承诺保护的证据链。

一份可复核的日志退役回执

回执不必公开账号、密钥或个人监测状态。它应当让后来者能重现“为什么此时可以关停”的判断。

旧日志边界。 记录日志配置、签名身份、最后允许修改的时点、最终树大小、根哈希、时间戳、部署模式，以及最终树头与此前公共状态一致的证明。

迁移规则。 固化新旧日志身份、查询与更新顺序、墓碑语义、实现这些规则的客户端版本。必须明确区分“以后去新日志找此标签”和“旧历史可以不再验证”。

分发证据。 列出应用发布、知名标签、设备管理策略等可信渠道，并按受支持客户端群体记录到达率。总下载量不能代替版本、平台和账号状态的分层证据。

完成状态。 分别记录接触新日志、核验迁移标签、完成旧日志最终 Monitor、执行备份恢复测试。四者不能互相冒充。

离线与丢失状态政策。 说明最长支持回归期、重装与多设备规则、备份年龄、无法访问账号的处理，以及受保护的例外入口。推算值应当标成推算，不能伪装成已观测事实。

决策权限。 密码学闭合由安全负责人证明；服务可用性风险由业务负责人接受；保留边界由隐私或法务责任人说明；最终退役由有明确授权的角色批准。异议要保留，不能被一个平均分消除。

可逆窗口。 旧服务在一段时间内保持只读或可恢复。回归客户端无法桥接树头、出现冲突证明或异常墓碑时，应触发延期、恢复或独立调查。

必须保留草案状态

截至本文截止时间，架构文档是提交 IESG 出版审议的第 09 版 Internet-Draft，预期状态为 Informational，并不是 RFC。文档负责人审查记录称工作组已有共识、没有重大反对，同时说明参与反馈的是相对较小的专业群体。这些都是重要程序事实，不能被压缩成“标准已经批准”。

配套协议仍在演进。IETF 126 会议纪要记录了对 UpdateRequest 新线格式的讨论，原因是此前格式无法实现；客户端实现者也提出当前可任选传输编码可能造成不互通。会议发言不等于最终共识，却提醒部署者把架构目标、协议版本、运行实现和本地退役决定分开验证。

最小共同规则已经足够清晰：新日志不可达时，不得让旧密钥复活；用户尚未获得合理机会闭合旧历史时，不得轻率撤掉监测表面。至于“合理机会”如何按具体服务落地，必须由有名字的机构承担，而不是交给一块墓碑条目默默决定。

来源

  1. KEYTRANS 架构草案第 09 版
  2. 架构文档历史与负责人审查
  3. KEYTRANS 协议草案第 05 版
  4. KEYTRANS 工作组章程
  5. IETF 126 KEYTRANS 会议纪要
  6. Lu Heng：《Minimum Initial Specification, Localized Future Decision, and Voluntary Adoption》
  7. Lu Heng：《Running Code Primary》