摘要

  • HTTPbis 的 Call for Adoption 询问 draft-hardt-httpbis-signature-key-08 是否应成为工作组工作；Datatracker 对该状态的定义明确表明，征询仍在进行，并不表示已经形成采纳共识。
  • 草案提供获取签名验证密钥的多种方式，却保留预配置、带外交换和应用特定获取路径；因此它没有替任何资源所有者选择本地信任政策。

技术讨论常把“可验证”误写成“可授权”。两者都可能涉及同一把公钥，但它们问的问题不同。验证要问：这条消息能否由相应私钥产生，并在既定规则下得到检查？授权要问：这个签署者在这个时间、这个上下文中，是否可以对这个资源做这件事？前一个问题可以由通用协议机制部分回答；后一个问题必须由拥有资源、承担损失的人或组织保留并记录。

HTTPbis 的公开征询针对一份定义五个 HTTP 头字段的草案。它列举了八种初始密钥分发或发现方案，包括匿名内联密钥、与 JWK 指纹绑定的自签发委托、JWKS URI 发现、直接 JWKS、JWT 形式、自签发 JWT、X.509 证书链以及已缓存断言的引用。征询要求社区在 2026 年 9 月 7 日前就是否应由 httpbis 工作组采纳该文本发表意见并给出理由。

这份档案证明的是一个正在开放的程序问题。它不证明采纳结果。Datatracker 将 “Call For Adoption By WG Issued” 定义为：工作组主席已经发出针对个人草案的征询，但工作组尚未形成采纳共识。后续如果出现主席对共识的说明、工作组草案名称、评审阶段、IESG 行动或 RFC 发布，它们都应分别成为带有日期和责任主体的新记录。截止日期不是未来决定的替身。

八种方案的存在也不等于端点必须接受八种方案。不同方案处理的身份暴露、委托、网络访问和缓存条件并不相同。JWKS URI 可能要求验证者访问外部位置；X.509 链会引入一套证书验证路径；内联密钥可以支持假名操作；JWT 可能承载与委托相关的内容。草案的技术价值之一，正是让这些差别能够被明确讨论、测试和规范，而不是用“有签名”一句话抹平。

草案本身没有把这种多样性伪装成统一信任命令。它说明，预配置密钥和带外密钥交换不属于 Signature-Key 的范围；这类签名不必使用 Signature-Key 头，验证者也可以通过应用特定方式取得验证密钥。这里保留的是部署选择权。某个服务可以用该头字段，可以附加自身的账户映射和发布者规则，也可以使用完全不同的密钥获取方法。

这条边界在真实操作中尤其重要。假设一个已签名请求要求转账、修改医疗数据、启动云资源、代表员工调用工具，或提交一份具有法律后果的文件。即使签名数学上有效，且验证者成功按草案找到公钥，仍有一长串本地问题没有答案：签署者是账户、工作负载、个人代理还是外部合作方？谁允许这种委托？作用范围和金额上限是什么？哪些上下文必须再次确认？拒绝如何处理？日志保存多久？何时以及由谁撤销？这些问题不会因为 HTTP 头字段存在而被转移给 IETF。

HTTPbis 的 charter 也为这种克制提供了制度边界。该工作组维护核心 HTTP，并可研究通用扩展；它不是某一种应用的账户制度、同意流程、风险承受规则或商业审批机构。工作组可以判断一项通用接口是否值得集体推进，主席可以处理工作组程序，但资源所有者仍然掌握端点授权。把技术标准的参与记录膨胀成对所有应用的授权，会让真正做决定的人从记录中消失。

这并不是要贬低 Signature-Key。不同实现若能用一致方式传递或引用验证材料，可能减少双边协调成本，也可能让安全审查更清楚。恰恰因为其覆盖匿名、委托、URI、证书和缓存等多种路径，工作组有充分理由检查算法协商、密钥替换、网络获取、缓存行为和注册规则。但每一项技术审查的结论，仍须与“谁被允许做什么”的业务决定分开。

最容易造成误导的说法是“标准化信任”。它把两个本来独立的凭据压缩成一张。协议凭据应保留草案版本、征询、共识状态、字段约束和后续规范步骤。应用凭据应保留政策所有者、可接受签署者类别、密钥来源、身份绑定、委托、范围、限额、审计记录和撤销路径。应用可以把两者连接起来，但不能让前者填补后者空白。

邮件列表的参与同样只能构成技术讨论的证据。参与者可以提出风险、实现经验和异议；这些贡献有价值，却不能代表未在场的资源所有者、用户或交易对手授予权限。未来即使有工作组采纳，也是一项关于通用 HTTP 工作的程序决定，不是一张针对某笔操作的授权书。

当前可以确认的结论很窄：HTTPbis 正在考虑一个用于签名验证密钥发现或分发的通用机制。它尚未采纳草案，未为所有应用挑选可信身份或发行者，也没有批准实际操作。把技术路径和本地信任决定分别保存，既让标准讨论可审计，也让责任停留在真正拥有它的地方。

来源