摘要

  • 第 03 版只把前序上下文的哈希写入后继签名；所有上下文可在任何人签字前生成，签名甚至可以倒序收集。
  • 第 04 版改为摘要前序完整 signoff，包括实际签名，并在强链模式拒绝旧式、混合式或未精确固定版本的链。
  • 新机制证明的是证明对象之间的因果依赖，不是可信时钟、真实阅读、组织授权、执行或效果。

这不是“签名失效”的故事。恰恰相反，旧链里的每一份签名都可能完全有效，却共同讲出一个并未发生的顺序。

9 月 6 日提交的 draft-schrock-ep-quorum-04 主动承认了这一点。第 03 版让后一个批准者签署含有 prev_context_hash 的上下文，也就是前一个批准上下文的摘要。文档据此声称，签名本身证明了后一个人是在前一个批准之后、并知晓前序批准的情况下签署。

问题在于，上下文不是签名。协调者可以先把整条上下文链生成出来，再从名单最后一人开始倒着收集签名，最后按正常顺序排列。每个哈希都对，每个签名也对，但“先后”只是展示层制造的叙事。

依赖点移到了已完成证明

第 04 版定义 EP-QUORUM-SIGNOFF-CHAIN-v1。输入不再只是前序上下文，而是前序完整 signoff JSON 对象，包括其签名原文。它先加入域分隔字符串和一个零字节，再对 UTF-8 JCS 规范形式计算 SHA-256。得到的 prev_signoff_hash 进入后继者自己的签名上下文。

第一份上下文必须省略该字段。第一项填 null、版本缺失或未知、继续使用 prev_context_hash、新旧链混用、链接错误，都会令强链失败。即使同一上下文出现另一份同样有效的签名，摘要也会改变，后继者必须重新签。

这次修正得到的性质很窄，也很重要：在文档给定的签名不可伪造与哈希抗碰撞、抗原像假设下，后继证明必须依赖一份已经存在的前序证明。它没有创造可信时间。issued_at 仍是声明值。它也不证明批准者看见了前序决定、读了相同画面、理解了行动、未受胁迫或没有机械点选。

证据包不能自选宪法

草案的 gate 检查政策格式、签名、精确行动绑定、角色、不同的人类标识、不同公钥、阈值、顺序、强链和时间窗。真实但不在该角色名册里的签名不算数；同一把钥匙登记成两个名字，也不能变出两名批准者；未凑齐的 trail 不产生部分权力。

然而，预期政策和 Approver Directory 必须从证据包之外的认证来源取得。让提交者附带的政策自己定义有效性，就是让证据挑选法官。基础收据草案同样承认：加密证明只说明某把登记密钥签了字；密钥标识与真实自然人的关系，取决于名录与身份核验。

逐项 admission 只能提前挡掉已知错误，不能替代最终判断。Verifying Executor 必须重算整个 gate，因为它不能假设协调者诚实执行了入场检查。即使 quorum 满足，组织仍要另行作出 AUTHORIZED 决定；系统仍要执行；目标状态仍要核验；一次性消费仍要证明权限没有被重复使用。

同一仓库的三种语言不是三次独立验证

第 04 版报告 JavaScript、Python 和 Go 验证器在共享测试集上得到一致结果，其中包括倒序签署的旧链和替换前序签名。它是有用的同团队一致性证据，却不是独立实现、形式化证明、互操作活动或生产部署。

这是一份 Intended status 为 Informational 的个人提交，没有 IANA 动作，也不能因进入 IETF Datatracker 就被说成 IETF 共识。它真正值得肯定的，是把共享规范收窄到可证明的不变量：后继证明必须依赖前序完整证明。组织权力、人的判断和运行结果仍应留在各自可审计的现实层。

来源

  1. IETF Datatracker 文档记录
  2. EP-QUORUM 第 04 版
  3. EP-QUORUM 第 03 版
  4. EP Authorization Receipts 第 12 版
  5. RFC 8785：JSON 规范化方案
  6. Web Authentication Level 2
  7. RFC 2119：规范性关键词
  8. RFC 8174：关键词大小写范围
  9. Minimum Initial Specification, Localized Future Decision, and Voluntary Adoption
  10. On Reality Layers, Symbolic Power, and Why Clarity Feels So Hostile
  11. Running-Code Primacy