摘要

  • draft-ietf-emu-pqc-eap-tls-02 允许管理员在入网配置阶段通过可信 EST 预取证书链后，让 TLS 类 EAP 客户端或服务器在握手中省略中间证书。
  • 优化不会移除终端证书与 CertificateVerify；它只是把线上字节变成一组必须在下次连接时继续成立的既有状态。
  • 02 版仍是工作组 Internet-Draft，没有定义让两端在现场握手中协商“可以省略”的 TLS 信号，也不是部署效果证明。

第一次成功连接从此有了前史

后量子证书恰好在网络最不宽容的位置变大。EAP-TLS 及相近方法要在普通网络服务建立之前完成 TLS。长证书链可能带来分片、重传和更多往返。

草案的办法很具体：在设备 onboarding 时先取中间证书，以后再少发。客户端通过 /.well-known/est/eapservercertchain 获取服务器链；同一管理域内，服务器可通过 /.well-known/est/eapclientcertchain 获取客户端链。

这不是压缩，而是迁移。一次精简握手依赖一段更早的历史：信任锚已经安装，EST 服务器身份已验证，链已取回且精确字节仍在缓存，当前终端证书仍能经这些中间证书走到锚点，管理员也确实只对完成这套过程的群体启用了省略。

02 版日期为 2026 年 9 月 23 日，2027 年 3 月 27 日到期。Datatracker 仅确认它是活跃工作组文档且 I-D 存在。文档页眉写 Standards Track，tracker 却没有给出拟议 RFC 状态。应保留这种差异，而不是替标准流程补结论。

无需客户端认证，不等于无需信任

两个 EST 资源都用于信息获取，并要求服务器允许未认证客户端访问。这方便尚在配置阶段的设备拿到中间证书，但没有赋予匿名来源权威。

请求方必须用经 BRSKI、EST 或其他带外机制建立的信任锚认证 EST 服务器。来自未认证或不可信服务器的链不得用于 TLS 路径验证。资源不要求客户端身份与服务器必须可认证，是两项不同属性。

HTTP 200 也不是完整验证结论。一个 EAP 服务器可能由多个 CA 签发，资源可以返回全部相关中间证书；客户端仍要依据现场握手里的终端证书选出所需部分并构建路径。路径建不成，认证就应失败。

因此，成功下载只证明传输发生过。它不证明当前签发者一定在集合里，不证明缓存仍新鲜，不证明吊销检查通过，不证明现场对端持有终端私钥，更不证明最终获得了网络访问。

缓存进入认证可用性边界

草案建议缓存，否则只是把延迟从握手搬到每次取链。它同时要求考虑变化与过期：定期重新获取、遵守 Cache-Control 与 ETag，并检查中间证书有效期。

这些机制回答不同问题。ETag 能表示某个源端认为表示内容发生变化；证书有效期限定时间窗口。二者都不能证明新终端证书仍能借旧缓存成链，也不能证明 EST 源覆盖所有签发 CA，或每台离线设备都在服务器停止携带中间证书前完成更新。

系统由此出现两个时钟：配置平面上的证书和缓存不断变化，EAP 平面上的接入尝试随时发生。休眠终端错过刷新、接入服务器切换签发 CA、设备管理快照滞后，都可能把节省字节变成大面积认证失败。

省略靠配置，不靠协商

草案最重要的安全边界是默认行为：没有管理员明确配置，客户端必须发送完整证书链。服务器只有在管理员确认客户端已经取到中间证书之后，才可以省略。建议也把适用范围限定在双方支持规范且在配置阶段完成预取的部署。

02 版并未定义能在 TLS 握手中证明共同状态的扩展。文档只把这种信号列作未来方案并排除在当前范围之外。现场没有新增回执能说：“你将省略的那组中间证书，我确实有。”

所以这不能是根据软件版本打开的全局开关。能力必须绑定签发者集合、对端群体、配置代次与新鲜度策略。回退也必须具体：恢复完整链传输，而不是只把告警清零。

后量子不只在叶证书

草案把保密与认证分开。长期保密需要 TLS 1.3 以及后量子或混合密钥协商组。抗未来量子攻击的认证则要求从终端证书到带外信任锚的每个签名都采用合适方案。

一张后量子终端证书不会让经典中间证书自动获得同样性质。预取也没有移除所有大对象：终端证书和 CertificateVerify 签名仍在每次握手里，SLH-DSA 等较大签名仍可能造成压力。它缩小的是一个来源，不是对低延迟或成功接入的保证。

运营证据应逐级保存：锚点安装、EST 身份验证、响应完成、中间证书哈希落库、新鲜度检查、签发路径匹配、省略配置、现场路径验证、EAP 完成、网络访问交付。任何一个“已启用”都不能替代这十个状态。

来源与限制

来源没有提供部署数量、实测失败率、固定节省字节数、刷新周期或回退 SLA。本文不宣称任何产品实现、事故或已完成标准。