摘要

  • Raza Sharif 的 Agent Audit Trail 个人草案第06版新增验证步骤：呈交的最后一条若不是 session_end，即使哈希链的其他检查全部通过，也不得报告“会话完整”。
  • 同版还要求已签名链中的删除标记由删除授权方对标记本身重新签名，不能沿用被删除记录的旧签名。

审计人员拿到一串记录，逐条核对哈希，全部正确。这份材料仍可能少了末尾几条。删除链尾不会改变前面的链接，因此“每一条交来的记录都能验过”和“没有遗漏最后发生的动作”不是同一个结论。代理行动一旦涉及审批、工具调用或数据修改，这个差别决定了审计报告到底能证明什么。

9月29日更新的 draft-sharif-agent-audit-trail-06 正面处理这个盲区。新加的第6.3节第10步写明：若呈交会话的最后一条不是事件为 session_end 的结束记录，验证者必须将完整性判为不确定，说明链尾不可核实；前九步通过也不能覆盖这一结论。草案列出结束记录、事先声明的心跳频率或外部锚定，作为限定链尾范围的办法。普通哈希链能够证明交来部分的内部连续，却不能凭自身证明后面没有记录被删。

这里的版本变化要说准。第05版已经描述会话结束记录和心跳；第06版并不是首次提出这两种机制。真正新增的是验证者应当怎样报告结果。代理异常终止可能产生没有正常结束记录的“孤儿会话”，原因也许只是故障，不必直接推定恶意。但报告不能把一个通过的完整性检查，自动升级为会话已完整呈交。

同一修订还改动了第9.3节的删除标记。第05版说，若原记录带签名，替代它的标记保留该签名；问题在于旧签名认证的是旧内容，不是新的删除声明。第06版改为：在有签名的链里，执行删除的授权方必须用自己的 signer_kid，对删除标记本身的规范化内容生成新签名；不得复制原签名。标记无签名或签名验证失败，有签名链的验证就应失败。无签名标记只在本来就无签名的链里可接受，仍应披露。草案还建议，不要允许代理自己的密钥删除关于自己行为的记录。

这形成两道不同的责任界线：谁能证明一段会话的结尾在哪里，谁又有权替换其中一条记录。Daniel Kade 建议在审计交接时另附一张“链尾与删除权限收据”：写明最后序号、结束信号或心跳与外部锚定依据、验证者的完整性结论，以及任何删除操作的授权密钥。这是本文的操作建议，不是草案规定的表单。

Datatracker 将该文件列为仍在更新的个人 Internet-Draft，IESG 状态为 I-D Exists，没有 RFC 发布渠道；它明确说明个人草案不代表 IETF 背书。现有资料也没有证明发生过生产事故。可得出的新闻事实更窄：第06版把“链正确但会话可能缺尾”写进验证结论，并把删除行为从旧记录的签名中独立出来。

资料来源