摘要

  • draft-reddy-wimse-aggregate-signatures-01 用逐跳输入、输出摘要说明消息在哪里被改写，再用聚合签名防止一个已签名但未改正文的转发节点被悄悄删掉。
  • 接近常数大小的只有聚合签名；Signature-Input、每跳 WIT、路径、查询和摘要仍随链长增长。
  • 验证成功证明的是所呈现参与者及其改写归属，不证明所有应在场的节点都在场，也不证明改写获准、动作提交或结果发生。

先把“短”拆成两个问题

一个动态代理把任务交给编排器，编排器生成更具体的请求，网关原样转发正文，目的服务最终执行。若只看最后一条 HTTP 请求，前三个工作负载留下的语境已经消失。修订 01 想让目的端能验证：哪些工作负载参与过，谁改变过消息。

方案不是把历史塞进一枚会自我解释的签名，而是保存两类材料。第一类是逐跳沿袭：本跳把收到的正文摘要写入 wimse-req-digest，把发出的正文写入 Content-Digest；下一跳签下前一跳的输出。第二类才是聚合：每跳对自己的签名基签名，签名值不断折叠进 Signature-Aggregate。

目的端验证聚合值时，仍要拿到全部公钥和全部被签消息。公钥来自每跳 WIT 的 cnf.jwk；被签消息要从各自的 Signature-Input、旧路径、旧查询、相邻摘要和最终请求重建。因此，“一枚签名大小”描述的只是签名字节，不是完整证明包。

修订 01 的权衡章节明确说，Signature-Input、Workload-Identity-Tokens 与摘要会随链增长。运营上应当分别计算聚合签名字节和证据包总字节。把两者画成同一条“证明大小”指标，会让节省看起来比实际更大。

没有改正文的节点为什么最容易消失

设 H1 发出正文摘要 A。H2 收到 A，也发出 A；它只是转发。H3 收到 A，改写后发出 B。

若三跳各自携带独立签名和摘要，攻击者可以删掉 H2。删后，H1 的输出仍是 A，H3 的输入仍是 A，摘要连续；H1 和 H3 的独立签名也可继续成立。正因为 H2 什么都没改，摘要链没有留下断口。

聚合签名增加的保护恰好针对这个空白。H2 的独立签名没有单独上网，而是被折叠进持续更新的聚合值。攻击者若宣称链只有 H1 与 H3，就必须拿出只覆盖这两跳的新聚合值；但它没有 H2 的独立贡献可供减去。验证集合与聚合值不一致，整体验证失败。

这并不证明所有应该参加的节点都参加了。一个中间方若原样转发却从未签名，现有链仍可能验证成功。一个本该经过的审批服务若被绕开，密码学也不会凭空生成它的缺席记录。必须由外部策略说明哪些主体或角色必须出现，再把策略要求同已证明的参与者集合比对。

验证者重建的不是最终请求

较早节点签下的路径和查询可能已被后来节点覆盖。修订 01 因而要求每跳把自己的发送路径与查询保存在 wimse-req-path 和 wimse-req-query。目的端重建 H1 的签名基时，用的是 H1 保存的值，而不是最后一跳的 URI。

正文摘要也有相邻依赖。H1 的输出值从 H2 签下的输入摘要取得；最后一跳没有后继，才从最终 Content-Digest 取得。这个设计把“我说我发了什么”和“下一跳说它收到了什么”接在一起。丢掉一个邻接记录，聚合值本身仍可能完好，但验证所需的消息集合已经不可恢复。

每一跳还要在 Workload-Identity-Tokens 字典中用唯一标签加入自己的 WIT，并在自己的签名输入中覆盖该成员。后继不得覆盖或删除已有成员。目的端要逐一验证 WIT，而不是看到令牌就默认身份可信。令牌中的算法名称同样只是声明所用算法；本地允许清单才决定它能否被接受。

所以，最低可用回执至少要保留：有序的跳点与消息集合、聚合原始字节、逐跳 WIT 与验证结果、逐跳签名输入、输入输出摘要、重建路径和查询、算法策略、聚合验证结果。Daniel Kade 把这称为“重建回执”，不是修订 01 规定的数据库字段。

归因不是正当性

修订 01 明说，摘要给出的是归因，不是正确性。一个工作负载可以恶意改写，也可以因模型错误改写；只要它如实签下输入和输出，记录仍在密码学上自洽。审计员知道谁做了改写，却仍需角色与授权策略判断它能不能这样做。

类似地，中间方可以丢弃旧聚合值，以自己为发起者创建一条新链。签名会识别新的发起者，但不会决定它是否有权发起请求。目的端若没有“哪些主体可以发起何种动作”的策略，无法从一枚有效签名补回授权。

这条边界可以用五份回执表达：参与者回执、改写回执、聚合验证回执、策略决定回执、执行与结果回执。前三份建立可验证沿袭，不能替代后两份。HTTP 返回成功也不自动证明业务提交；业务提交也不自动证明外部效果。

整体验证也带来整体故障

聚合把所有贡献绑成一体。优点是内部签名不可随意剥离；代价是任何一份坏签名都会让整条链失败，而且聚合值本身不指出坏在哪一跳。错误凭证、过期状态、序列化差异、不合规算法或恶意参与者都可能让全链拒绝。

接入决策可以只需要“全链通过或拒绝”，事故处理却需要定位。系统应另存逐段验收结果、前缀验证回执或足够的受控重放材料。否则，团队拥有防篡改能力，却没有可操作的故障归因路径。

算法敏捷也不能被理解成“对方带什么就收什么”。修订 01 提到 BLS 消息增强方案可用于当前设计，但供 WIT 使用的算法标识仍留给另一份规范，而且 BLS 不具备后量子安全。一个聚合链的所有跳还必须使用同一聚合算法。若退回逐跳独立签名，摘要仍能发现删掉改写节点的行为，却失去对未改写签名节点的同等防删除性质。

证据链也是拓扑泄露链

逐跳 WIT 暴露参加者身份，wimse-aud 可能暴露下一接收方，摘要序列显示改写发生在哪一段。跨组织分享验证包时，分享的不只是签名，还可能是服务拓扑和处理史。保存多久、谁能读取、能否在不交出全部正文的情况下验证，都需要单独治理。

卢恒的“现实层”视角在此很实用：工作负载身份、公钥、被签 HTTP 表示、改写沿袭、聚合验证、授权决定、应用提交和外部结果是相互关联但不同的记录。任何一层变绿，都不能替其他层作证。

“运行代码优先”把注意力放回真正的控制面：结构化字段解析器能否保存旧值，验证器能否重建签名基，WIT 是否逐一校验，相邻摘要是否正确连接。协议图上短小漂亮的聚合值，不能补救只存最后一个请求的系统。

最小初始规范也不是要求收集所有内部日志，而是保存另一位获准验证者完成重建所需的最小完备集合。链越长，事实越多；签名可以压缩，事实不会因此消失。

来源与边界

证据冻结于 2026 年 9 月 30 日（Asia/Shanghai）。修订 01 是一份活跃的个人 Internet-Draft，不是 RFC、IETF 共识、采用报告或已部署标准，未来可能修改、替换或到期。来源没有提供实测开销、互操作结果、线上攻击、生产节省、合规结论或已观察损失。事实包中的证据大小公式是 Daniel Kade 的解释模型，不是性能基准。