摘要

  • 当前 Key Transparency 架构草案明确指出：单个用户的所有请求都可成功、所有证明都可通过，而该用户看到的日志仍可能与其他人不一致。一致性会把客户留在原分支上，却不会自动揭示另一条分支。
  • 发现分叉需要额外的比较通道：不与日志合谋的审计者或管理者、匿名访问，或者点对点交换。三种办法分别改变信任、隐私、本地状态和运行责任的分配。

最安静的故障恰恰没有本地错误

开篇是为分析机制而构造的运行场景，不是真实事件报道。它区分了两个常被合并的问题：“这份回答是否延续了我过去看到的状态”，以及“所有人是否看到了同一状态”。前者可以在一台设备上验证，后者至少需要一个独立观察点。

draft-ietf-keytrans-architecture-09 正面处理了这一区别。IETF Datatracker 显示它仍是活跃的 Internet-Draft；第 09 版发布于 2026 年 6 月 29 日，档案在 7 月 9 日更新。工作组状态是 Submitted to IESG for Publication，IESG 状态是 Publication Requested，预期类别为 Informational，尚无 telechat 日期。它不是已经批准的 RFC，也不能被写成最终文本。

端到端加密并未自动解决身份目录的权力问题。消息内容可能受到保护，服务运营者却仍控制“用户身份对应哪把公钥”。若运营者把受害者的键值替换成自己掌握的公钥，传输仍可表现为加密，通信对象却已被改变。

Key Transparency 把身份与公钥的绑定写入受密码学保护的追加式日志。Search 返回标签值和证明；Update 写入新版本并给出证明；Monitor 在后台检查过去看到的值仍在树中，并检查用户拥有的标签是否出现未知变更。这个公共机制的范围很窄：让记录和变更可验证，而不是让一个中央机构替应用作出所有决定。

日志仍可能向不同人呈现不同历史。每一台客户端都会要求下一次响应与自己保存的树头一致，因此它会停留在一条线性分支上，并拒绝日后与该分支冲突的回答。这样一来，分叉无法被悄悄合并，证据也更难消失。但只要两组用户没有比较，双方都可能持续得到“验证成功”。

比较是一项独立的安全功能

草案列出三类跨越隔离的方法：可信第三方、匿名访问日志、点对点通信。它们的共同作用不是重新计算原证明，而是带来一个不受当前认证通道限制的视图。

第三方审计者跟踪日志是否只追加增长，并为近期树头签名。用户随查询响应收到这份签名。其安全假设是审计者不会和日志合谋共同签署一条恶意分支。异步审计还会产生时间差：审计签名可能落后于日志最新状态，而“最多可落后多久”是配置和治理决定，不是算法自然给出的常数。

第三方管理模式转移了更多工作。管理者保存并运行日志的大部分功能，服务运营者继续执行访问控制并认证新标签版本。双方不合谋是关键前提，运营者还必须检测管理者提供的分叉。多个独立第三方使用门限签名能够降低单点风险，但成员资格、门限、密钥轮换和替换仍要有人负责。

Contact Monitoring 不设常驻第三方。标签所有者定期核对自己的最新值；看到近期新值的联系人稍后回来确认，该值没有在所有者发现前被移除。为了发现分叉，应用仍须经匿名通道或点对点通道比较树头。责任从机构移到了设备、用户上线频率以及见证网络是否真正连通。

匿名比较从无法识别请求者的通道取得树头，再与认证通道中的树头对照。维护多条分支的日志无法可靠判断该返回哪一条，反复检查会逐步提高暴露概率。不过，这一结论取决于匿名通道是否真的隐藏身份、是否会被地区性或选择性阻断。

点对点交换所需数据很少，甚至可以通过二维码等低带宽带外方式完成。真正困难的是拓扑。如果两个社群从不交换见证值，日志就能长期把它们留在不同分支。定义一种消息格式不等于建立了连通的见证网络。

设备恢复不能把历史悄悄清零

客户端凭本地状态要求未来回答延续过去。如果最后树头、待完成的监控义务和外部见证记录在错误时刻丢失，日志可能为恢复后的设备提供另一段历史，而设备已没有冲突点可用。

草案把状态丢失作为正式风险。Contact Monitoring 中，刚出现且仍处于合理监控窗口的值最脆弱，尚未充分交换的日志区域也一样。第三方审计模式中的敏感区间则与允许的审计滞后相关。短命网页会话、换机、残缺备份或攻击者诱导的重置，都可能在不改变验证算法的情况下削弱保证。

账户恢复流程应明确保存或声明缺失哪些内容：最后接受的树头、未完成 Monitor 任务、见证者签名、最后比较时间以及日志配置身份。恢复后的客户端不应被静默当作从未见过日志的新客户端。无法证明连续性本身就是需要记录的证据，并应触发本地制定的恢复策略。

时间界限也必须落到运行数据上。检测速度受响应最大陈旧度、Reasonable Monitoring Window、后台监控真实频率、匿名或点对点比较间隔、审计者滞后和运营者检测管理者分叉的效果影响。用户还可能需要保持上线一段时间，后台机制才能运行。“可在有限时间内发现”只有在每个界限都有负责人、测量值和报警时才有意义。

因此，监控不能只看证明通过率。还要记录每台设备的树头年龄、外部签名年龄、比较成功与失败、Monitor 积压、状态恢复事件、陈旧响应拒绝，以及从发现冲突到采取本地行动的时间。一个完全绿色的验证面板可以与长期分叉同时存在。

透明机制不会取消访问控制

Key Transparency 特意保留应用现有的传输与授权规则。服务可以要求登录、限制可查询的身份、做速率限制，并阻止用户修改不属于自己的标签。日志证明的是一次获准操作如何执行，而不是替服务决定谁应获准。

Contact Monitoring 带来一个重要边界。用户昨天有权查询某标签，今天权限被撤销，但他仍可能必须稍后执行 Monitor，以完成昨天观察所产生的安全义务。草案要求这类监控继续可用。若授权系统把所有路径一并关闭，可能同时切断发现日志掩盖旧值的证据渠道。

不同见证方式也泄露不同信息。审计者能看到变更数量、顺序和大致时间，但看不到明文标签和值；第三方管理者通常能看到运营者可见的明文、历史和查询流量。匿名比较必须保护元数据，点对点交换则可能显露社交关系或相遇模式。不存在没有信息代价的见证者，只有可被明确审查的取舍。

因此，“引入独立第三方”不是完整方案。还要规定其可观察内容、保留期、关联能力、签名对象、客户端如何取得其公钥、签名迟到时怎么办，以及怎样替换失效的见证者。

迁移和删除不能顺手抹掉旧证据

草案希望客户端能处理多个日志，因为日志失效后，迁移到新日志是一条主要恢复路径。渐进迁移期间，旧日志必须保持运行，直到长期离线的用户也有机会完成监控。过早关闭会让这些用户无法发现旧日志中的部分不当行为。

立即迁移需要通过可信通道分发旧日志最终大小和根哈希，使所有人以同一检查点结束旧历史。联邦环境还要有一致政策，决定一个身份应由哪个日志负责；否则，权威日志的选择本身就会制造不同视图。

数据裁剪也分两层。过期或永久不可访问的用户数据可能可以删除，但用于证明其余状态的密码学节点仍可能需要保留。隐私删除与证明连续性必须协调，却不能用同一个“已经删除”标签来概括。

发现分叉提供证据，不发出最终命令

两个可验证视图一旦被比较并确认冲突，用户能够保存不可抵赖的日志不当行为证据。应用仍要决定下一步：提示风险、冻结密钥变更、暂停投递、要求带外核验、隔离一台设备，或在调查期间保留有限服务。

这些决定的误报成本、身份冒用成本和可用性成本各不相同。公共协议应让冲突可观察、可携带；具体处置权应留给了解情境且承担后果的运营者和用户，并让决定可记录、可复核、可逆转。

所以，部署验收不应止于“证明是否能通过”。还要验证独立比较是否真实运行，状态是否能穿过普通恢复流程，旧日志是否在迁移中保持可查，以及组织是否知道谁有权中断通信。见证者能够相遇，日志才真正透明。

来源