摘要

  • 当受保护的 crit 列表点名一项验证器不理解或不支持的扩展时，即使密码学签名匹配，RFC 7515 仍要求判定该 JWS 无效。
  • 这不是普通的“重要性”标签，而是一道语义兼容门：旧实现不能在忽略新规则后沿用旧含义继续处理。
  • 密码学完整性、JOSE 扩展处理和具体应用是否接受，是三个权属不同、都应留下独立证据的判断。

一个绿色结果为何必须被推翻

设想网关收到一段紧凑序列化的 JWS。它能解析算法标识，取得正确密钥，也按规范重建了签名输入。密码学函数返回成功。若系统只有一个名为“valid”的布尔值，工作似乎已经结束。

但受保护标头中还有一项扩展，并且它的名字出现在 crit 数组里。网关从未实现这项扩展。此时成功的签名结果不能成为通行证。按照 RFC 7515，这段 JWS 对该网关是无效的，因为网关虽能确认哪些字节没有被篡改，却不知道这些字节要求它采用什么新语义。

crit 的值是一个标头参数名数组。每个名字都必须对应 JOSE 标头里实际存在的扩展参数，接收方必须理解且支持其处理规则。数组不得为空，不得重复名字，也不能点名根本不存在的参数。JWS 或 JWA 已经定义的普通参数不能被重新塞进列表冒充扩展。

它还只能出现在受保护标头里。这一点不是排版要求。如果“哪些规则必须理解”本身不受签名保护，中间人就能删除名单，再让不认识扩展的接收方按旧规则接受消息。crit 是关于含义的声明，因此必须与被声明的内容一起获得完整性保护。

未知但未列为关键的标头参数通常可以忽略。这给协议留下向前扩展的空间：可选提示不会让旧软件全部停摆；一旦扩展会改变必要的构造、解释或安全属性，发送方就用 crit 明示“不了解便不得继续”。

Sakimura 所参与设计的不是警告灯

RFC 7515 列出的作者是 Michael B. Jones、John Bradley 与 Nat Sakimura。Sakimura 长期参与数字身份标准并在 OpenID Foundation 担任领导角色，但这项工作应准确归于三位共同作者及其标准化过程，而不是包装成个人发明。

人物意义恰恰体现在他们面对的制度问题。身份协议需要跨越不同厂商、语言、运行时和更新周期。一项新扩展不可能等到全世界同时升级后才出现；它也不能容忍旧实现把含义已经变化的对象当成普通旧对象接受。

crit 没有预先登记未来所有答案，而是分配了推进的责任。生产者负责声明本消息依赖哪些扩展。接收者负责证明自己确实执行了这些扩展。密码学成功没有越级权限，不能覆盖能力缺失。

这里的“critical”也不等于“危险”或“高敏感”。判断标准是忽略它会不会改变消息的解释。一个业务上很醒目的字段可能只是可选元数据；一个看似细小的编码开关却可能改变签名输入。扩展设计者和应用配置者必须根据语义依赖决定是否列入，而不是根据名字听起来是否严重。

b64:false 把风险变成可见的字节差异

RFC 7797 给出了最清晰的实例。普通 JWS 在构造签名输入时，会使用负载的 base64url 编码。受保护标头把 b64 设为 false 后，签名输入改用未经编码的负载。这会改变参与计算的确切字节，也会改变某些序列化方式对负载内容的限制。

因此，使用 b64:false 时必须同时在 crit 中列出 b64。只实现了原始 RFC 7515 行为、却不知道 RFC 7797 的接收方会看到未知关键扩展并拒绝。它不会把未编码负载误当成采用默认编码规则的对象，也不会因为某个签名函数返回成功就掩盖双方对签名输入的不同理解。

知道扩展的算法仍不代表应用可以使用它。RFC 7797 建议应用配置保持一致，避免在同一使用场景中随意混用编码与未编码负载；紧凑序列化对某些负载字节另有约束；JWT 更被明确禁止采用 b64:false。所以，通用 JWS 库可以正确实现该扩展，而上层 JWT 应用仍必须拒绝这种组合。

这恰好形成三道问题：签名计算是否匹配？处理器是否理解并正确执行所有关键扩展？当前消息类型和应用配置是否允许这样使用？第一道门打开，不会自动打开后两道。

能计算某算法，不代表政策接受它

RFC 7518 规定了 JOSE 使用的算法与标识符。实现能识别并计算一种算法，只说明能力存在。RFC 7515 仍把“哪些算法可接受”留给应用决定。密码学上成立的签名可能使用了本组织已禁用的算法、错误的密钥类型或不合适的参数。

RFC 8725 针对 JWT 把这条边界讲得更具体。验证方需要明确限制允许的算法，不能让发送者可控的标头独自决定验证方法；还要检查发行者、主体、受众以及应用自己的约束。不同用途的 JWT 应采用互斥验证规则，防止一种令牌被混入另一种上下文。

crit 不替代这些检查。它不会证明发行者可信，不会确认受众就是当前服务，也不会批准业务操作。甚至双方都“认识”某扩展，也不表示当前配置允许它。理解只是作出判断的前提，而不是判断本身。

多重签名把一条路径变成多条路径

JWS 的 JSON 序列化可以容纳多个签名。RFC 7515 的一般验证过程要求至少一项签名有效，同时允许应用制定更严格的接受政策。这里必须保存“究竟是哪一项、沿哪条规则通过”，而不只是汇总为一个成功位。

每项签名都有自己的受保护标头，也可能有不同的关键扩展。系统迁移时，旧签名常被保留以兼容旧接收者，新签名则引入新算法或新语义。若政策长期只是“任一签名通过即可”，旧路径可能变成永久降级通道。若未经协调立即改成“全部通过”，不支持新扩展的正常接收者又会整体中断。

协议提供表达能力，部署方必须补上迁移政策：哪些签名满足条件，哪些算法和扩展被允许，兼容路径服务哪些受众，旧路径何时退出。没有这些限定，多签名不是韧性，而是把信任选择藏在一个模糊布尔值里。

审计记录必须说清是哪一层拒绝

良好的验证记录至少分三层。密码学层保存算法、密钥引用、签名输入构造和计算结果。JOSE 处理层保存受保护标头是否合法、遇到了哪些关键名字、哪个模块执行了每项扩展，以及是否因未知语义拒绝。应用层保存消息配置、发行者与受众核验、声明约束、授权决定和请求效果。

这不要求记录密钥、完整令牌或敏感声明；稳定的关联标识和明确原因码已经能避免严重误导。签名吻合却因未知扩展失败时，把原因写成“签名错误”，会让人员错误地轮换密钥。JOSE 全部通过但受众不符时，只记录“令牌有效”，会掩盖真正拦截请求的应用政策。

crit 最重要的价值不是让标头多一个字段，而是让接收方无法用“我验过签名”代替“我理解所签内容”。Sakimura 与共同作者把语义谦逊变成一条可执行规则：缺少必要知识时，正确答案就是拒绝。

资料来源