摘要

  • draft-ietf-tls-trust-anchor-ids-06 提议信任锚短标识，帮助 TLS 对端选择证书路径；客户端清单可以不完整、甚至与真实信任策略不一致，因此它不是接受承诺。
  • 无条件发送便于第一次选路，却可被被动观察；条件发送降低这种暴露，却可能在选错路径后依赖服务器提供的可用锚清单，另开一次连接恢复。
  • 组织必须分别治理信号、路径库存、选择与回退、本地验证、恢复、隐私模式和最终服务结果，不能用一个“受信任”字段覆盖全部环节。

把信任策略全部告诉服务器，听起来像是提高握手成功率的直线方案。问题在于，信任锚组合往往比浏览器版本或密码套件更接近设备和机构的长期状态。某个企业内部根、过渡期根或罕见行业根一旦出现在每个 ClientHello 里，就可能把一群很小的客户端从人群中挑出来。

TLS 工作组的 revision 06 没有把“发送得更精确”设为唯一目标。它允许客户端发送个别 Trust Anchor ID、覆盖多个锚的群组 ID、一个子集，甚至空清单。客户端可以省略自己真实信任的锚，也可以列出自己并不信任的锚；群组中同样可能混有本地策略会拒绝的成员。清单服务于证书路径选择，不是信任库的远程导出。

该版本在 2026 年 9 月 30 日更新，草案页眉把预期状态写为 Standards Track；本次冻结的 Datatracker 记录中，intended_std_level 与 std_level 仍为空。它是一份 Internet-Draft，不是 RFC。本证据包也没有证明生产部署、互操作或行业采用。

服务器收到的是选路提示

服务端可能同时持有多条证书路径：一条通向普遍存在的旧根，一条通向正在引入的新根，另一条用于特定客户端。现有 certificate_authorities 扩展可以传递机构名称，但完整列表可能过大。短标识把选择信号压缩进更小空间。

草案让依赖方在 ClientHello 或 CertificateRequest 中放入无序的 RequestedTrustAnchorList。认证方为每条候选路径维护其签发锚的个别 ID，以及包含该锚的群组模式，然后寻找交集。若同时存在 certificate_authorities，满足任一扩展都可以参与选择。没有匹配时，对端可以返回 handshake_failure，也可以提供回退证书。

选择结束后，验证才真正决定成败。客户端仍需按自身策略检查锚、应用身份、有效期、算法、名称与路径约束，以及它选择实施的其他验证要求。服务端路径元数据写错，会让它稳定地选出错误证书；客户端为保护隐私而故意给出宽泛清单，也可能得到同样结果。两者造成的是连接失败，不是信任范围扩大。

因此，“服务器按客户端请求提供了某 CA”不能被解释成客户端为该 CA 背书。它只说明一个选择算法命中了一个信号。接受权限仍在依赖方。

严格路径减少搜索，不减少判断

若服务端证书确实匹配所请求的信任锚 ID，它可以在 Certificate 消息中加入一个空的 trust_anchors 扩展。这个空标记不是什么都没说；它要求证书列表完整、顺序正确，而且不夹带无关证书。

客户端据此可以把列表当作已经构造好的路径，不再自行搜索其他拼接方法。RFC 4158 展示了路径构造何以成为图搜索问题，RFC 5280 则规定路径验证的基本纪律。前者可以被简化，后者不能被跳过。排列无误的链仍可能落到未获授权的根、违反名称约束，或使用不符合本地规则的算法。

运营日志至少要保存两份独立结论：“路径因 ID X 被选中”与“策略版本 Y 以理由 Z 接受或拒绝该路径”。把两者合成一个绿色状态，会在真正需要诊断时抹掉故障边界。

隐私模式决定谁能看见

草案区分从不发送、条件发送和无条件发送三种行为。条件发送通常要求观察者主动探测并触发相应行为；无条件清单则可被被动采集。若每个用户的清单不同，短标识照样可以形成长期指纹。

草案因此不建议发送用户唯一的无条件清单，而倾向于让许多客户端共享同一匿名集清单。但“许多人共享”不是永久属性。软件升级、地区差异、企业策略或历史状态都可能把一个大群体切成很小的子群。若清单由以往连接结果生成，它还能把多次会话关联起来。

群组 ID 可以扩大表面匿名集，却把风险转移到群组治理。谁分配 ID，哪些锚属于群组，成员何时变更，客户端与服务器是否使用同一版本，都不在几个字节里自动解决。过时定义不会把不受信任的根变成可信根，却会让可用性承担错误。

服务端恢复清单也有隐私边界。它应按所请求服务及 SNI 上下文过滤，而不是把共享平台拥有的全部证书路径暴露出去。敏感信任锚不适合通过这一机制公开。

一次新连接换回精确选择

草案为首次误选提供了受限恢复。服务端可在 EncryptedExtensions 中发送一个非空、按服务端偏好排序的个别信任锚 ID 清单。客户端若随后拒绝证书，就把这份可用清单与自己真实信任的锚求交集，再结合双方偏好选出一个锚，开启新连接，并只请求该个别 ID。

恢复最多一次。服务端没有发送清单、双方没有可信交集，或第二次仍失败，都会把错误交给应用。新连接还会增加往返和尾部延迟。条件发送并没有消灭成本，只是把一部分隐私收益兑换成选择不确定性。

在根迁移中，这种交换可能有价值。服务器优先提供新路径，把旧路径留作兼容回退；已经更新的客户端直接成功，尚未更新的客户端通过一次重试回到旧路径。但运营者必须知道是哪一批客户端持续重试、增加多少延迟、何时应结束过渡。否则“兼容机制”会固化成无人负责的永久双栈。

七张表，而不是一个真值

符合最小初始原则的做法不是建立一个全球信任裁判，而是保留足够小、足够清晰的本地收据。

第一张表记录信号策略：发了哪些个别或群组 ID，是否条件发送，匿名集规则是什么。第二张记录路径库存：服务端实际有哪些链，各自的锚与群组元数据来自何处、版本为何。第三张记录选择与回退：哪个扩展命中、偏好如何排序、无匹配时采取什么动作。

第四张单独记录本地验证：信任库版本、应用身份、约束与具体拒绝理由。第五张记录恢复：服务端可用清单、偏好交集、唯一一次重试及延迟。第六张记录隐私模式：发送条件、历史状态和服务过滤。第七张记录结果：实际证书路径、握手状态和用户可见服务结果。

不同团队可以拥有不同表，任何一方都不必获得修改全部策略的权限。这样，运行代码提供事实，参与者仍保留未来决策空间，协议协调也不会被误写成集中授权。

来源