摘要

  • 9 月 28 日的 draft-reddy-wimse-aggregate-signatures-01 仍是个人提交的活动 Internet-Draft；并非 WIMSE 工作组通过的标准，更不是 RFC。
  • 各跳记录收到和发出的消息摘要，可以暴露删掉一个曾修改内容的节点；若该节点原样转发，邻居的摘要仍可能吻合。
  • 草案用聚合签名来约束这种“无改动节点”的抹除，但授权、连续无改动节点的精确先后顺序及最终执行结果必须另行判断。

设想请求经过甲、乙、丙三个服务。乙读取并签署了请求，却把相同内容交给丙。如果签名各自独立，事后删掉乙，甲的输出摘要仍与丙的输入摘要相符。检查者得到一条看似没有断点的内容轨迹，却少了一个实际经手者。新草案附录 A 用三跳例子说明了这一点：摘要相等不能代替参与者名单。

这份 9 月 28 日修订的文件题为《Authenticated Provenance for WIMSE Delegation Chains》。IETF Datatracker 将它列为活动的个人 Internet-Draft，标明无 RFC stream、IESG 状态为 I-D Exists，并明确个人提交不代表 IETF 背书。草案页上的 Standards Track 意向不能当作正式审议结果。9 月 8 日的 -00 版已经提出聚合签名；-01 的报道价值在于进一步拆开内容改动的溯源与未改动转发的参与证明，并细化路径、查询和响应处理。

WIMSE 原有 HTTP 消息签名工作，处理的是发送工作负载与直接接收方之间的身份绑定。多跳委托中的最终接收者，不能因此自动知道沿途全部工作负载。新提案让每个签名节点带上收到和发出的正文摘要，以及路径和查询相关值。若某节点改过正文，从链中抽掉它会使剩余节点的输入、输出对不上；核验者也能把变更定位到某一跳。但摘要只能说明被签名的内容如何衔接，不能判断内容是否真实、变更是否合理。

关键是没有改动内容的转发者。提案使各跳的签名贡献进入同一运行中的聚合值，不在链上单独传送原始签名；核验时必须用声称参与的签名者及其消息共同校验。按文件陈述的密码学假设，试图从这份名单中抹去一个已经签过名的转发者，会令聚合值验证失败。这是草案对机制的安全主张，并非有实测数据支撑的部署结论。

其代价同样具体。聚合后的签名值可以接近一枚签名大小，身份令牌、签名输入和逐跳摘要仍随链长度增长。所有节点需要兼容同一种可聚合算法；草案指出 ML-DSA 本身不能聚合，退回逐跳独立签名便丢失了对无改动转发者的防抹除性质。任何一枚贡献无效，整体检查都会失败，且不能直接指明出错节点。文件还承认，消息轨迹本身不能认证连续多个原样转发者的先后顺序。提议的 HTTP 字段和参数只是 IANA 注册请求，不是既有注册事实。

最需要守住的边界是权力。文件明确把授权排除在范围之外。一个工作负载确曾签名，不代表它有权接触任务、调用工具，或让接收方接受其行动。参与证明、访问决策与应用结果必须各自留下可核对的依据。

来源