摘要

  • 第 06 版草案拟把 JWS none 和 JWE RSA1_5 标为“已弃用”而非“禁止”；应用必须默认关闭，但可为特定对象或操作作窄范围启用。
  • 截至 2026 年 9 月 29 日，IANA 的现行 JOSE 注册表尚未完成这项变更；即使将来状态更新，也不能证明某个库已移除能力或某次请求已被拒绝。
  • 可审计的退场凭证必须把对象、算法、解析后的允许清单、编译后的库能力、例外责任人及期限、接受或拒绝结果，以及由此授予的权限连成一条链。

一次风险评审会上，最容易得到掌声的截图往往来自注册表。旧算法旁边出现“已弃用”，表格从红色变成琥珀色，升级项目似乎就完成了。可是在生产入口，合作方仍可能提交一个旧令牌，租户级兼容配置仍可能覆盖默认值，运行时也仍可能返回成功。真正的安全边界从来不在截图里。

《JOSE：弃用 ‘none’ 和 ‘RSA1_5’》第 06 版于 2026 年 9 月 25 日发布。Datatracker 条目显示它仍是处于 IETF 最后征求意见阶段的互联网草案，截止日期为 10 月 9 日，并且还需要 IANA 审查。修订历史只能证明文本如何推进，不能证明任何服务已经改变行为。

草案处理的是两种不同的机制。JWS none 表示不带签名、也不带消息认证码的 Unsecured JWS。RFC 7515定义了 JWS 框架，而 RFC 7518早已要求实现不得默认接受无保护的 JWS。危险之处在于，软件若让输入中的 alg 自己选择验证路径，攻击者就可能把真实性检查变成一个可关闭的选项。

JWE RSA1_5 则是加密对象的密钥管理算法，采用 RSAES-PKCS1-v1_5；它属于 RFC 7516描述的 JWE 流程。它不是 JWS 的 RS256、RS384 或 RS512。后者是签名算法，前者是密钥加密标识。把所有含“RSA”的名称一起封锁，既会破坏无关操作，也没有证明脆弱路径真的关闭。RFC 8017给出底层 RSA 方案，CFRG 的 RSA 指南则说明统一失败处理和抗预言机能力取决于实现细节。

草案使用了四组不应混淆的义务：库开发者应当弃用支持；应用开发者必须默认关闭；确有需要时，应用可以只为特定对象或操作启用，但不能全局打开；未来新的 JOSE 规范不得允许这两种算法。它要求的是受约束的迁移，不是宣称代码已经消失。

这正是“已弃用”与“禁止”的差别。现有规范和应用仍可能继续使用，但应迁移。截至本文取证时，IANA JOSE 注册表仍把 none 标为 Optional，把 RSA1_5 标为 Recommended-。未来的注册表更新会改变公共元数据，却不会自动改写网关、SDK、硬件安全模块、租户配置或例外文件。

所以证据链应从实际决策点向两端延伸。先记录 JOSE 对象类型和业务操作，再记录受保护头中的 alg，以及 JWE 的 enc；随后是签发者、受众、租户和路由选择出的策略；解析完成后的允许清单；库版本与实际编译进去的能力；任何例外的来源、批准者、范围和到期日；密钥类型；最终的接受或拒绝；以及该结果让哪个主体获得了什么动作权限。

对 JWE，还必须保存失败形态。不同的错误码、响应长度或耗时可能把解密端点变成预言机，即使控制台把 RSA1_5 标成“仅例外”。NIST SP 800-131A 第 2 版提供迁移背景，却不是某个本地端点已经统一错误路径的证明。

RFC 8725要求 JWT 实现验证算法，并避免依赖攻击者控制的选择。落实到运行时，这意味着应用必须拥有自己的有效允许清单。令牌头只能表达请求采用的处理方式，不能成为选择验证器的授权。

草案还为未来算法注册提出安全门槛：新的 JWS 签名或 MAC 算法应满足 EUF-CMA；完整的 JWE 加密过程应满足 IND-CCA2；内容加密应采用 RFC 5116所描述的 AEAD。这些是评审基线，不是某个构建版本的测试报告，也不能覆盖密钥、解析和策略组合中的错误。

Heng Lu 的“运行代码优先”把接受事件置于库存标签之上；现实层次帮助我们区分象征性的弃用与消息实际取得权限的事实；最低限度初始规范则说明，共同规则可以确立安全默认值，但本地系统仍必须对每个窄范围例外负责。

只有当所有相关入口都默认拒绝，而每一个仍然存在的“是”都具体、可归属、可度量并且会到期，退场才算完成。在那之前，“已弃用”只是入口处的警告牌，不是决策点签发的拒绝凭证。

来源