摘要

  • draft-ietf-acme-pop-00 在 newOrder 中声明 popKey，以订单专属的 pop 授权和 pop-01 挑战取代最终阶段的 CSR。
  • 持有证书私钥与控制 DNS 等证书标识符是两项独立证明；订单只有在两类授权都有效时才能进入 ready。
  • 签名密钥对新 nonce 与订单哈希签名；ML-KEM 密钥解封装服务器产生的 ciphertext，再对订单哈希返回 HMAC。
  • KEM 的 MAC 能向服务器证明持钥，却不能成为第三方可验证的不可抵赖证据；服务器本身也能算出同一结果。
  • KEM 证书私钥不能签署 ACME 撤销请求；与 STAR 组合后，账户密钥成为停止后续签发的唯一协议内控制点。

从撤销端倒推这条链

RFC 8555 为证书撤销提供两种认证方式：用 ACME 账户密钥，或用证书自己的私钥。对普通签名证书，两条路径可以形成一定冗余。KEM 私钥没有签名能力，第二条路天然不存在。

这意味着，KEM 证书签发成功并不是控制故事的终点。若账户密钥丢失，运营者可能无法通过 ACME 撤销证书。服务商提供的账户恢复、短有效期证书、CA 另行运营的 CRL 或 OCSP 可以降低风险，但它们是新的控制面，需要事先确认责任人、恢复时间与可用性。

STAR 又把依赖放大了一步。初次订单中的 popKey 可以在该订单的自动续发周期内持续使用，不会为每张新证书重新执行 pop-01。STAR 证书不能按通常方式单独撤销；账户密钥负责取消订单、停止以后继续签发。账户密钥一旦不可恢复，续发可能一直运行到人工干预或订单的 end-date。

后量子算法改善的是某类密码风险。它不会自动解决谁能叫停流程、谁能恢复控制、多久之后自动化才会自行停止。

popKey 与账户密钥必须不同

草案要求服务器把两把公钥转换为规范的 DER SubjectPublicKeyInfo，再逐字节比较；相同就拒绝订单。

账户密钥负责认证 ACME 消息。popKey 则是拟写入证书的公钥。前者有权创建订单、提交挑战响应，并在有关路径中撤销或取消；后者服务于证书所保护的实际应用。若两者共用一把密钥，管理权限与业务用途就会落在同一故障域中。

因此，密钥清单不能只记录算法和指纹。它还要说明哪把密钥控制账户，哪把密钥进入证书，谁能调用，如何恢复，何时轮换，以及丢失后会留下什么仍在运行的自动化。

持钥证明被放进原始订单

客户端在 newOrder 的 JWS payload 中放入一个 popKey、一个值为空的 pop 标识符，以及至少一个真正的证书标识符。服务器原子地保存 popKey 与 newOrder_hash，创建一个 pop 授权，并在其中只放一个 pop-01 挑战。

newOrder_hash 不是对解析后再生成的 JSON 计算，而是对 JWS payload 解码所得的原始字节计算。重复 JSON 键或无法形成唯一语义的输入必须被拒绝。证明绑定的是客户端真正提交的订单字节，而不是服务器后来重建的一份“看起来等价”的对象。

签名模式把固定域分离前缀、新生成的 32 字节 popNonce 与订单哈希拼接后签名。KEM 模式则由服务器对 popKey 执行 ML-KEM.Encaps，发出新的 challenge_ciphertext；客户端解封装、用 HKDF-SHA-256 导出 mac_key，再对订单哈希计算 HMAC。

任何订单字节变化都会改变证明上下文。每个订单也必须重新建立 pop 授权，不能拿已通过的旧授权复用。

pop 只回答一个问题

空值 pop 不是证书里的身份，也不携带公钥或哈希。它只是要求建立一项狭义授权：参与者是否在挑战完成时持有该订单中 popKey 对应的私钥？

DNS、电子邮件或其他标识符仍由原有 ACME 挑战验证。持有私钥不等于控制域名；控制域名也不等于持有拟签发证书的私钥。设备证明、RATS 证据与证书 Profile 可以和订单组合，但各自仍只为自己的命题负责。

这种拆分看似增加记录数量，实际上减少了权力误读。订单用 AND 关系组合多项独立授权，而不是让一项“成功”吞掉其他问题。

KEM 证明不能拿给第三方当签名

KEM 客户端只有解封装成功，才能导出正确的 MAC 密钥并返回 HMAC。对 ACME 服务器而言，这足以证明客户端持有相应私钥。

但 ciphertext 由服务器产生，服务器自己也拥有预期的 mac_key，所以同一个 HMAC 也可能由服务器生成。事后把 transcript 交给外部审计者，不能证明只有客户端能创建响应。草案明确把它与不可抵赖性区分开。

这不削弱服务器当下的签发判断，却限制了审计语言。保存 ciphertext、响应、订单哈希、时间与状态可形成内部记录；它不是一份可独立验证的客户签名。

服务器还必须限制秘密寿命：不记录原始 shared secret，只暂存派生的 mac_key，挑战进入终态就销毁；不同挑战不得复用 ciphertext。订单创建会触发 ML-KEM.Encaps，因此还需要限速，避免订单洪泛把密码运算变成资源消耗入口。

空的 finalization 并不代表空白授权

全部授权有效后，客户端用账户密钥认证一个内容为 {} 的 finalization 请求。CA 必须把与已接受 popKey 密码学等价的公钥写入证书，并使用订单中已获授权的证书标识符。

主题、有效期、Key Usage、Extended Key Usage 等其他字段仍由 CA 策略或所选 Profile 决定。草案也没有因为移除 CSR 就给客户端任意注入扩展的新通道。

证书生成后还要安装、与正确私钥配对、覆盖全部副本，并被依赖方接受。pop-01 只证明挑战完成那一刻的持钥状态，不证明之后仍然持有，更不证明业务已经成功。

第 00 版于 2026 年 9 月 1 日发布，是 ACME 工作组的 Standards Track Internet-Draft，不是 RFC，可能修改、替换或到期。本文不声称任何 CA 或客户端已经支持它，也不声称存在已验证的互操作、签发、事故或部署结果。