摘要

  • Steven Mih 的首版“披露封套”个人互联网草案于 9 月 27 日公布。它没有获得 IETF 背书，也不是已经实施的代理审计标准。
  • 提案把可选择公开的代理输入或输出放在原签名记录之外。核验者须先独立验证原记录，再逐项重算披露内容的摘要；两种结论不能混成一个“通过”。
  • 摘要吻合只能说明交来的值对应先前承诺。它不证明输入正确、代理行为适当，亦不阻止收到封套的人继续传播其中的明文。

设想同一笔代理操作受到两方复核：甲只看到输入摘要，乙还拿到完整输入。这不是一个已披露的真实案例，而是新草案值得关注的治理场景。两方可以面对同一个历史签名对象，却拥有不同的可读证据。决定差异的，不是签名有没有改动，而是谁在事后选择给谁看原始内容。

9 月 27 日的公告介绍了 Steven Mih 的 draft-mih-agent-disclosure-envelope-00。IETF Datatracker 将其列为活跃的个人 Internet-Draft，并明确表示个人提交不等于 IETF 认可，也不具有正式标准程序地位。它依赖作者另行提出的 Agent Action Capsule 方案，不能把这套组合报道成已部署的 IETF 服务。基础方案中，agent_input_digest 与 agent_output_digest 是经过 RFC 8785 JSON 规范化后计算的 SHA-256 摘要；输入和输出原文从未作为这两个字段写进签名记录。

这份新提案的做法是给完整不变的 Capsule 套一个独立封套，旁边附上可选的 disclosures 对象。首版只允许两个可披露成员：agent_input 和 agent_output。没有附上某一项，按草案是 WITHHELD，即“未披露”，而非“没有这项输入”或“核验失败”。封套本身不是提交给 SCITT 透明度服务登记的签名声明；披露值是后来加入的，因此不参与原 Capsule 的签名，也不改变其 capsule_id。这为不同收件人提供不同披露视图，同时保持同一个基础记录的身份。

但一个不变的标识符，不会自动验证后来加上的内容。草案要求核验者分两路处理：一路核对原 Capsule，另一路对每个披露值做完整 JSON 规范化、重算摘要，再与原先留下的承诺比较。它分别报告吻合、不吻合、成员不在许可表内，以及承诺摘要缺失或格式不合要求等结果。即使披露值吻合，也不能因此把无效的基础记录升级为有效；基础记录有效，也不能让未做重算的披露自动可信。若界面只因为收到了明文就显示“已证实”，未经签名的附件就会借原记录的声望取得它没有的证明力。

“选择性披露”是另一份配套提案，问题不同：它处理的是本可能以明文进入载荷、但在签署时被隐藏的字段。此处的输入和输出字段从一开始就只有摘要；后来交出的原文是在封套中供比对的前像，不是把原载荷还原或重写。这个区别限制了可以诚实宣称的成果：核验成功说明一个值与旧承诺相符，不说明代理当时获取的信息准确、输出可用，或披露者对该值拥有无限传播权。

披露时的隐私代价同样不能省略。未披露时，收件人看不到原文；一旦原文进入封套，任何拿到该封套的人都能直接读取。草案没有提供逐收件人加密，也没有规定转发后的控制办法。制作方可以为不同复核者分别构造封套，但仍需另行决定谁有资格收取、用什么渠道传送及如何限制副本。Daniel Kade 的分析重点正在这里：密码学可以固定承诺并检验对应关系，不能替组织作出有权披露的决定。这不是指称任何机构已经泄密，也不是新的 IETF 义务。

来源