摘要

  • 9 月 28 日，IETF 将 Key Transparency Architecture 调整为 AD Evaluation::Revised I-D Needed；安全领域主管要求草案把标签所有者与依赖该标签作判断的一方明确分开。
  • 搜索证明、树头签名和一致性校验即使全部有效，也不会自动说明谁有权改变绑定、哪条策略允许查询、由谁签署当前视图，以及谁还欠一次后续监测。
  • 运营记录不能只保存“验证成功”，而应保存角色限定回执：所有者、请求方角色、授权决策、部署模式、签名方、时间界限、先前状态与尚未履行的监测义务。

屏幕先亮起绿色。搜索证明有效，树头签名正确，新视图也能接上客户端上一次保存的状态。密码库已经完成了它能完成的工作。

但组织真正需要回答的问题才刚开始。发起查询的人，是这个标签所指账户的所有者，还是准备依赖别人的公钥建立加密关系的一方？谁批准了披露？谁能提交新值？如果这是一条刚出现的版本，谁必须稍后回来确认它没有在所有者看见之前被悄悄移走？一个 valid=true 无法携带这些职责。

这正是 IETF 本轮审查暴露的缝隙。2026 年 9 月 28 日，安全领域主管 Deb Cooley 向第 09 版 Key Transparency Architecture 发出审查意见。Datatracker 历史记录了状态从 AD Evaluation 变为 AD Evaluation::Revised I-D Needed，并把作者 Brendan McMillion 列为行动负责人。它仍是拟作为信息类 RFC 的 Internet-Draft；这不是 RFC 发布，也不是任何产品已经部署的证明。

最重要的审查意见看似只是改名。草案定义了 User / Account，但随后又让“标签所有者”和查询别人标签的“用户”承担不同任务。Cooley 要求把后者明确为依赖方。两者并不对称：所有者是目录绑定所描述的主体；依赖方则使用这项绑定作出是否信任另一人的决定。把两者都写成“用户”，会把权利、风险和事后义务压扁在同一个词里。

密钥透明解决的是端到端加密中的一个基础风险。通信服务往往负责分发用户公钥；如果服务悄悄把攻击者控制的公钥挂到某个账户上，加密仍会成功，只是保护了错误的关系。第 09 版因此把身份与公钥的绑定放入受密码学保护、只能追加的日志。Search、Update 与 Monitor 返回证明，后续答复必须与客户端此前看见的视图保持一致。对不同用户展示不同历史，会留下永久分叉。

“永久”不等于“自动发现”。架构还要求三条路径之一：可信第三方、匿名访问日志，或端到端比较。第三方路径让外部机构签署最新树头，用户同时接受一个额外假设——第三方不会与日志串通签署分叉。匿名或点对点路径则由客户端自行寻找矛盾。证明从来不是一次性诚实证书，而是持续观察过程中的一段证据。

草案定义的三种部署模式，实质上是三套不同的问责分工。

在 Contact Monitoring 中，没有第三方接过发现责任。标签所有者定期确认最新值没有异常变化；刚查询过新版本的依赖方则要稍后复查，确保该版本没有在所有者能够发现之前消失。草案尤其规定：即使访问策略后来不再允许该用户执行原 Search 或 Update，由旧操作产生的必要 Monitor 仍必须允许。撤销今天的访问权，不能抹掉昨天已经形成的证据义务。

在 Third-Party Auditing 中，日志承担大部分存储和运行工作，审计方周期性签署它观察到的树视图，日志再把签名随响应交给用户。保证的强弱取决于审计从哪个位置开始、允许落后多久。一份签名完全真实，却仍可能因过旧而不适合当前决策。

在 Third-Party Management 中，第三方管理者承担多数存储和操作；服务运营者仍是策略闸门，负责访问控制并认证新标签版本，再把合格请求转发给管理者。安全依赖双方不串通。审查意见要求图 6 加入一次有效查询，因为只画 Alice 对自己条目的查询和更新，会让读者看不见依赖方如何取得别人的公钥。

配套的第 05 版 Key Transparency Protocol说明了为何“部署模式”必须进入审计记录。配置中包含模式、签名与 VRF 公钥、合理监测窗口，并在适用时包含审计方公钥、起始位置和最大延迟。服务运营者签的树头、第三方管理模式下的签名和带延迟界限的审计签名，即使都能验证，也代表不同的信任结构。

客户端状态也是安全机制的一部分。旧视图约束新视图，丢失旧状态就会削弱发现分叉或事后隐藏数据的能力。对于状态天然短暂的网页，或状态可能被对手强制清除的应用，第 09 版建议采用第三方管理模式。审查要求补充状态丢失的实例，并解释所谓“永久无效状态”：草案称有些错误不会当场显现，用户仍需在一个有界期限内在线才能发现。

访问控制形成另一条边界。应用可以只允许联系人互查、要求登录或执行限流。日志证明的是数据结构如何处理请求，不会证明应用有权把该标签透露给这个请求方。审查因此要求统一使用 ACL 语言，而不是在“朋友”和“访问控制”之间切换。

隐私与删除又有自己的时钟。过期或永久不可访问的序列化用户数据可以清除，但验证所需的部分密码材料可能要保留到最大生存期结束；可验证随机函数用于隐藏标签。审查建议把隐私讨论合并，并在理解设计必须依赖 VRF 时把 RFC 9381列为规范性参考。密码层保护了标签，不代表应用层已经作出正确的受众决定。

出版依赖也被纳入审查。文档 shepherd 把架构称为协议草案的基础；若架构要先发表，协议引用就必须明确只是示例。审查还要求解释为何对比使用已经实施的 Certificate Transparency RFC 6962，而不是只写后继的 RFC 9162。MLS为匿名群组中的凭据提供背景，却不能证明 KT 已被部署。

运营上的补口不是再加一个哈希，而是建立角色限定验证回执。每次接受操作时，除证明和标签版本外，还要记录请求方是所有者还是依赖方、访问策略及版本、部署模式、日志/管理者/审计者的签名身份、树大小与时间、允许延迟、用于一致性判断的先前状态，以及未来仍需执行的 Monitor。

这份回执不会夸大协议，反而会缩小每项结论。事故复盘因此能区分五种完全不同的结果：密码证明无效；证明有效但查询未经授权；审计签名正确但过旧；监测责任没有履行；客户端已经丢失用于发现分叉的状态。

第 10 版可能用不同方式解决意见。现在已经可以确认的边界是：只能追加的历史能让欺骗变得可发现；只有明确角色，才能让某个人或机构真正负责发现它。

来源