摘要

  • draft-kuehlewind-audit-architecture第01版发布于2026年9月7日，新增“带内记录存储”：每个代理都可以运行自己的Audit Store，并通过交互所用的现有连接交换记录。
  • 草案把这种方式称为外部存储的替代方案，而不是替代品；两者也可以组合使用。文本同时承认，同一方运营代理与存储，会比独立外部存储要求更多信任。
  • 存储只是审计链的一项功能。草案还分别描述记录器、Auditing Service、证明、透明度登记、审计员和验证者。
  • 该文件仍是个人互联网草案。IETF Datatracker明确提示，它没有得到IETF认可，在IETF标准流程中也没有正式地位。
  • Daniel Kade提出一份“保管拓扑回执”，公开每项功能的实际运营者。这是本文的分析建议，并非草案要求。

新增的捷径，自带一条信任说明

第01版最值得注意的新内容只有一段。新增的3.2节说，记录不必全部导出到独立的外部Audit Store。每个代理可以运行自己的存储，再把记录发给正在交互的另一个代理所运行的存储。传输可以复用原有连接，无须另开带外通道。

这不是没有价值的便利。短时运行的代理往往已经与对端建立了经过认证的连接；复用连接可以减少额外集成，也让记录更容易沿着分布式任务链流动。草案并未把自托管写成唯一方案。它明确说，这只是外部存储的一个替代选择，两种方式可以并用。紧接着，文本把治理代价写了出来：当代理与其Audit Store由同一方运营时，系统必须比面对独立外部存储时更信任这家运营者。

第00版没有“带内记录存储”这一节。因此，本次新闻对象是可核验的版本变化，而不是对旧有表述重新包装。

“有审计”至少包含六个不同动作

问题不在于带内存储必然不合格，而在于部署方很容易用一句“这个代理接受审计”，抹平整条证据链。第01版自己的角色设计恰好说明为什么不能这样做。

首先，不同参与者从不同位置产生记录。面向用户的一端可以保留指令、批准和追加授权；代理可以产生动作、委托与授权状态变化的信号；工具或外部服务则可以记录效果发生边界所看到的请求。Audit Recorder负责捕获或转换这些信号。Audit Store负责保存和提供记录。Auditing Service对可观察记录进行规范化，以自身身份签名，并送交透明度日志登记。最后，审计员依据一套审计政策作出判断，验证者可以评估其中的具体声明。

这些功能回答的不是同一个问题。存储回答日后到哪里找记录；签名把声明与一把密钥联系起来；证明可以支持对记录生成环境的主张；透明度回执可以支持“某份声明在某时已经登记并且没有被不一致展示”；审计独立性则关乎谁有权评价证据。任何单项能力都不能独自证明所有参与者如实、完整地记录了一切。

角色能否合并，进一步增加了辨认难度。草案说，角色是功能，而不是部署单元，同一实体可以承担多个角色。代理的宿主进程也可以充当该代理的记录器。这样做更简单，但草案承认存在记录器与代理合谋的威胁，并把独立记录器或及时的透明度登记列为缓解方向。第01版的另一处又明确写道，架构的问责属性需要一个独立的Auditing Service。

只要不混淆名词，这两种安排并不冲突。同一方运营的Store可以只负责传输和保存，而由独立服务完成规范化、签名或外部承诺；第三方可以托管Store，却不负责审计判断；一个看似“外部”的产品也可能仍由同一集团、同一管理员或同一密钥持有人控制。“外部”描述位置，“独立”描述控制权与激励，两者不能互换。

存储放在哪里，不等于证据由谁保管

可以比较两种部署。第一种把Store放在代理进程内，但记录一产生，另一个独立服务就把签名承诺登记到代理运营者无法单独改写的透明度系统。第二种把日志导出到云端，却由运营代理的同一团队管理云日志账户；在首次外部承诺出现之前，这个团队仍能同时改动源记录与副本。

第二种在地理上更“外部”，第一种却可能更早形成不可单方撤销的历史约束。这个例子并不证明任一方案完整或合规，它只说明：网络拓扑图和供应商数量不能替代保管链证据。

RFC 9334对远程证明也作了类似拆分：Attester生成Evidence，Verifier评估它，Relying Party再用自己的政策决定是否接受。RFC 9943则区分签名声明、透明度服务、回执和依赖方的最终决定。组件名称本身不构成保证级别；角色、政策、密钥与证据路径共同决定可相信的范围。

还必须保留文件的制度状态。Datatracker没有显示RFC流、负责的区域主管或工作组采纳，而且明确提示该个人草案不代表IETF认可。第01版新增的是一项正在讨论的架构选择，不是IETF已经制定的代理审计规则。

来源