摘要

  • TLS 工作组 2026 年 9 月 30 日的信任锚标识草案第 06 版，把二进制标识的长度上限从 255 字节降到 32 字节，协议中的 TrustAnchorID 结构也改为容纳 1 至 32 字节。文件仍是工作组 Internet-Draft，IESG 状态为 I-D Exists，不是已发布 RFC。
  • 新增的实现说明要求软件面对可能极大的 OID 分量时避免溢出与误判，区分协议上有效的标识和本地文字配置未必能表示的标识。标识帮助选择证书路径，并不替依赖方决定应信任哪个认证机构。

证书链换根时，握手成功不一定只是「多发一张证书」那么简单。客户端可能已经信任新根，旧设备却仍只接受旧根；服务端需要知道对端认可哪条路径，才有机会在可用性和信任库更新之间保持衔接。TLS 草案提出的 trust_anchors 扩展，就是用较短的标识传递这种选择线索。它并不要求所有对端拥有相同的信任库，更不会因为某个标识出现在握手里，就给相应认证机构授予信任。

第 06 版最醒目的变化是长度。9 月 14 日的第 05 版允许一个标识的二进制表示达到 255 字节；9 月 30 日新稿将上限设为 32 字节，并把 TLS 结构的范围从 <1..2^8-1> 改成 <1..32>。草案解释，这使二进制和点分十进制形式无论写成相对还是完整 OID，都可以舒适地放进 255 字节范围。这里被限制的是一个标识的长度，不是可被信任的根证书数量，也不是证书路径数。

更容易被忽略的是另一种「大」。即使整个标识只有 32 字节，OID 的单个分量仍可以是很大的整数；匹配组标识的模式也可能包含大数。新增实现章节明确要求不能把大分量读错，也不能在整数溢出时出现未定义行为。它推荐尽量保留字节表示，在字节层比较标识和执行匹配，以免先把每个分量塞进某种固定宽度整数。这是对软件边界的要求，不是要求 CA 一律使用很长的数字。

诊断日志与文字配置仍可能需要点分十进制写法。草案允许这些场景设置本地支持上限，却同时要求对协议上有效、只是本地不支持的标识作可互操作处理。TLS 实现必须能接收指定握手消息中含任意大 OID 分量的标识；在交给其他组件前，可以丢弃不支持的标识。若 EncryptedExtensions 中的标识全被丢弃，就等同于没有收到该扩展，不能悄悄将其解释成另一种信任许可。对设有分量上限的实现，草案建议至少覆盖至 2^32-1，以容纳私有企业编号的完整范围，并建议标识分配遵循该范围；这里用的是 SHOULD 而不是 MUST。

草案没有说这种设计已经部署，也没有证明任何实现存在溢出漏洞。第 06 版还把版本化组示例中原来的 2^64-1 改成无穷上限；那是示例边界，不是现实注册表发生变更的证据。Datatracker 所示状态依然是工作组草案、IESG I-D Exists。新闻事实是文本细化了标识长度与异常输入处置，而不是 IETF 已认证某个产品或改变全球信任根。

来源