密钥透明性证明无法审计谁获得了目录查询许可

Summary

KEYTRANS 的搜索证明能够验证一项已获准查询的结果及日志一致性，但查询在抵达透明日志之前是否被应用放行，并不在该证明的证明范围内。
当前架构草案允许应用使用认证、关系、所有权和限速等规则控制 Search、Update 与 Monitor；这种灵活性保护身份存在性和撤权后的数据，却也把重要权力留在证明之外。
Daniel Kade 提议增加保护隐私的“查询策略回执”：记录策略版本、操作、请求者类别、关系类别、决定代码、日志时期和例外授权，同时排除用户名、原始标签、公钥、联系人图谱和完整查询史。它是治理建议，不是 IETF 或 KEYTRANS 的现行要求。

证明从门后开始

设想 Alice 要寻找 Bob 的通信密钥。服务允许请求进入 KEYTRANS，返回映射值、前缀树路径和日志树承诺。Alice 验证成功，也通过持续监控确认自己的视图没有被悄悄分叉。就这个答案而言，透明机制做了它应做的事。

Fred 发出结构相同的请求，却因应用判断双方没有所需关系而在传输层被挡下。他没有得到错误的证明；他根本没有得到一个可由 KEYTRANS 验证的操作。若审计者只查看日志承诺与成功证明，Alice 的轨迹清晰，Fred 的轨迹近乎不存在。

这条接缝决定了制度分析的起点。透明数据结构回答的是“获准进入后的答案是否符合已认证状态”，不是“入口是否按一贯、公开且可申诉的规则管理”。密码学可以压缩一项事实，却不能把未编码的组织判断凭空变成可验证事实。

KEYTRANS 实际承诺了什么

KEYTRANS 工作组的目标来自一个具体风险：为端到端加密系统分发公钥的服务，可能向目标用户提供被替换的密钥，从而进入本应保密的通信。架构把可搜索的前缀树与只追加的日志树结合，使标签到值的映射、更新历史和不同客户端所见状态能够接受验证。

搜索证明因此很有力量。只要客户端正确执行验证并保存必要状态，它就能判断返回值是否位于承诺的树中，日志是否沿一致历史演进，以及服务是否向不同观察者展示难以调和的状态。RFC 6962 与 RFC 9162 所代表的证书透明度经验说明，只追加结构和一致性证明可以把某些隐蔽的替换行为转成可发现的偏差。

但这种力量有明确边界。正在讨论的 draft-ietf-keytrans-architecture-09 是拟作为 Informational 发布的工作组互联网草案；draft-ietf-keytrans-protocol-05 同样仍是草案。它们不是已经完成的 RFC，也不证明任何特定服务已经部署。架构反复把访问控制留给所嵌入的应用，标准不能脱离应用独立运行。

换言之，树根承诺数据库状态，不承诺组织决定。一个通过验证的 SearchResponse 表明服务对这次搜索给出了与认证结构相符的答案；它没有证明所有相似请求都获准进入，也没有证明拒绝发生在正确的规则、正确的版本或正确的例外权限之下。

隐私为什么需要一道门

把所有拒绝都视作可疑，会误解问题。查询一个身份是否存在，本身可能泄露联系人、组织成员、受保护群体或敏感服务的使用情况。RFC 6973 的隐私考虑以及 RFC 7258 对普遍监控的警示都提醒设计者：可观察性越强，并不自动意味着治理越好。公开一张完整的搜索图谱，可能比不透明更危险。

因此，KEYTRANS 的活动章程要求身份存在性和账户数据只向获授权的客户端披露。架构允许应用复用既有传输和访问控制，规则可以基于登录状态、资源所有权、“朋友”关系、速率限制或其他应用语义。协议没有能力为所有产品定义一套通用的社会关系。

问题不在于门存在，而在于门的动作没有与证明系统同等清晰的责任边界。一个合法的隐私规则、一次临时反滥用阻断、一次过期的紧急例外和一次商业差别待遇，都可能在日志前表现为同一种“没有查询”。当系统只保存成功证明时，这些完全不同的制度行为被压扁成沉默。

撤权揭示的不是开关，而是状态机

协议草案中的 Contact Monitoring 使这条边界更加明显。客户端在成功搜索某联系人后，可能需要继续监控与先前版本相关的状态，即使它后来失去新的 Search 或 Update 权限。草案为这种连续性保留了窄路径，并允许用承诺开口证明先前曾拥有相应权限。

这意味着访问控制不是简单的“允许/拒绝”位。一次允许可以产生后续验证义务；一次撤权可能禁止获取新内容，却不能立即终止保护旧会话所需的监控。MLS 的安全架构、共享安全目标与消息层安全要求同样强调，通信安全依赖随时间变化的成员、凭据和状态，而不是一次性的登录判断。

治理记录若只写“当前已拒绝”，便无法解释为什么某个 Monitor 仍应继续。反过来，若为了保留连续性而永久保留全部身份与查询历史，又会侵蚀撤权和数据最小化。正确的审计对象是规则转移：谁依据哪个策略版本，把哪个操作从哪种权限状态移到哪种状态，以及哪些既有义务仍存续。

引入第三方并不会自动补上缺口

KEYTRANS 架构讨论了第三方管理与第三方审计。在第三方管理模式中，服务运营者仍控制访问门；管理者可能看到获准请求的明文标签、值、历史和查询流量，而被服务拒绝的请求可能从未抵达管理者。管理者能够验证自己所见的处理，却无法仅凭缺席识别上游拒绝。

第三方审计则可以获得变化数量、次序和时间等信息，同时让标签和值保持遮蔽。这减少了审计者对敏感目录内容的暴露，却同样不会自然产生“哪些请求在日志之外被挡下”的总体数据。观察日志并不等于观察入口。

当同一个控制实体运营多个服务时，架构还允许通过代理减弱可关联性，并警告不应以合并或镜像日志的方式干扰各自策略。这说明身份保护与跨域关联风险被认真对待。它也说明，不能靠建立一座收集所有拒绝细节的中央审计库来解决治理缺口。

查询策略回执应证明边界，而非暴露身份

可行的补充物不是公开搜索档案，而是一份经过严格最小化的查询策略回执。回执应在应用决定允许或拒绝时生成，与适用策略版本绑定，并能由受控审计方验证。它不需要让公众知道 Alice 搜索了 Bob。

一个可操作的回执可以包含：操作类别（Search、Update 或 Monitor）、粗粒度请求者类别、关系类别、轮换密钥生成的目标摘要、决定代码、相关日志时期、触发规则类别、例外授权者及到期时间、纠正状态、保存期限和聚合测试标识。目标摘要应定期轮换，避免成为跨时期稳定身份；类别应足够粗，避免重建联系人图谱。

它不应包含用户名、原始标签、公开密钥材料、认证凭据、消息内容、完整 IP 地址、永久设备标识、明文关系边或一个人的完整搜索历史。具体实现还需威胁建模、权限隔离和删除机制。回执的目标不是使每次拒绝公开，而是让获授权的审计者回答有限问题：同一策略版本下，同类请求是否得到一致处理？例外是否过期？撤权后的 Monitor 连续性是否符合规则？纠正是否真正执行？

这类机制也不能被树根取代。把回执哈希塞进日志，只会证明某个回执被承诺，不能证明回执涵盖了所有决定。完整性仍需要独立的计数、抽样、双写检查或受约束的执行环境。治理不应把“存在可验证记录”误称为“所有相关行为都已记录”。

删除义务反而强化了两层分工

架构指出，当应用政策使某些值永久不可访问时，可以删除这些值；协议运行所需的密码学材料则是另一类对象。应用负责把访问政策传达给自己的数据处理流程，透明日志本身并不理解为何某项内容应消失。

这进一步表明，数据层和政策层不能混为一谈。日志可以证明承诺的演进，应用必须证明删除判定、保留例外与后续监控义务如何协调。若策略回执具有明确到期与聚合规则，机构可以在不永久保存敏感身份明细的情况下，保留有限的决策可问责性。

仍然未知的部分

冻结来源没有说明任何具名产品采用了这些草案，也没有给出拒绝率、错误率、歧视性处理、事故频率、性能开销或司法合规结论。本文不声称现有运营者实施了不当封锁，也不把工作组文本描述为部署事实。

当前文本还可能变化。架构第 09 版于 2026 年 6 月 30 日发布，拟为 Informational，计划在 2027 年 1 月 1 日到期；协议第 05 版也仍处工作组阶段。章程确定工作范围，不保证最终设计或市场采纳。

这里能确定的结论更窄，也更重要：一个正确验证的 KEYTRANS 证明可以支持对获准查询结果的信任，却不能证明查询许可本身公平、一致或可纠正。隐私要求入口有所选择；制度合法性要求这项选择能够在不泄露身份网络的前提下接受检验。

密钥透明性证明无法审计谁被允许查询

为何重要

Summary

证明从门后开始

KEYTRANS 实际承诺了什么

隐私为什么需要一道门

撤权揭示的不是开关，而是状态机

引入第三方并不会自动补上缺口

查询策略回执应证明边界，而非暴露身份

删除义务反而强化了两层分工

仍然未知的部分

Sources

档案背景详情

Strategic Circle

Leadership Alliance

Strategic Circle 专属简报

Leadership Alliance 简报