摘要

  • ACME 个人互联网草案 01 版于十月二十八日更新，删掉00 版的“严格后量子配置”。旧配置要求 TLS 服务端与客户端 JWS 请求采用后量子或混合签名，并拒绝仅使用传统签名的回退。
  • 新版拟允许 ACME 服务器不再实现 ES256；现行 RFC 8555 第 6.2 节仍要求服务器实现它。保留 ES256 的服务器，可以在自行确定的过渡期内继续接受传统 JWS 签名。

加固隧道之后，谁还拿得到证书？

设想一家公司让 ACME 客户端自动续发证书。客户端和服务器之间的 TLS 连接换上后量子或混合密钥交换，流量即使今天被截获，也不容易在将来被解开。但证书申请本身还要由账户密钥签署 JWS。只要服务器继续接受旧算法，决定申请能否进入签发流程的那道门就没有随隧道一起换锁。

六月版本为此设了一个明确的“严格后量子配置”：TLS 服务端认证与 JWS 请求认证都必须使用后量子或混合签名，传统签名不能作为退路。十月版本把整节删掉，只留下一个“后量子就绪机制”。它仍要求参与该机制的 ACME 连接使用 TLS 1.3 或更新版本，并以具备后量子或混合密钥交换的通道传输；新式认证要得到支持。至于传统认证何时关停，文本交给部署方的策略。

变化不止于删标题。六月要求该配置下的服务器实现指定的 ML-DSA 变体和一种复合签名，还保留 ES256。十月第 4.2 节改称：服务器可以支持 JOSE 注册表中的任意 JWS 算法，不指定必须采用哪种算法或参数集；服务器甚至可以不实现 ES256。若为兼容旧客户端保留 ES256，传统签名可在其选择的过渡期内继续使用。两个服务商完全可能都说自己“后量子就绪”，却对同一张旧账户签名给出相反答复。

草案还有一处需要作者自己补齐。引言仍把后量子与混合签名称作“必须实现”，第 4.2 节却用“可以”，并明确表示不强制某一 JWS 算法。编写互操作测试时，这两段不能同时当成同一条验收规则。这里缺的不是口号，而是一份可执行的算法清单与拒绝条件。

IETF 跟踪页标明这是个人提交的互联网草案，并非已通过的标准；原文没有给出部署数量或全行业关闭旧签名的日期。只有服务端公布具体策略，并在测试中证明旧签名到期后确实被拒绝，“退场”才算发生。

来源：十月版本；六月版本；RFC 8555；IETF 状态。