摘要

  • 可选的 token-authority 是给客户端使用的发现提示，不是服务器的信任锚；服务器要依据本地配置的生态信任关系和 x5u 或 x5c 所指证书判断发行者。
  • ACME 服务器把 JWTClaimConstraints 当作不透明字符串，将原始订单里的值与令牌的 tkvalue 逐字节直接比较，不解码、不重编码，也不做规范化。
  • 一次有效挑战需要分别证明发行者、签名、类型、精确字节、exp、jti、ACME 账户密钥与 CSR 的 CA 角色；证书签发成功仍不等于之后的 JWS 验证或电话结果已经成立。

地址能带路，不能投信任票

tkauth-01 挑战可以带有 token-authority 参数。它存在时，ACME 客户端可以用这个网址找到提供 JWTClaimConstraints Authority Token 的机构；它不存在时，客户端应通过带外配置知道去哪里申请。

第 05 版明确限制了这个参数的权力：ACME 服务器验证挑战响应时不使用它。给客户端的一张路线图，不能自动把路线终点的签发者加入服务器信任集合。

真正的信任决定从另一条链路到达。Authority Token 必须由服务器已配置为相应生态令牌发行者的证书签名。证书材料可以由 HTTPS x5u 引用，也可以放在 x5c 中。两者都没有、证书取回失败，或证书不具备本地配置的发行者角色，验证就必须失败。可选的 iss 能声明发行者是谁，却不能让令牌用自己的声明授予自己信任。

这项分离让两个控制面可以独立变化。为了可用性而迁移发现网址，不应顺带扩大信任边界；治理方撤销一个发行者，也不必假装客户端的网络位置发生变化。若把二者塞进同一个设置，一次普通的服务迁移就可能变成未被审计的授权变更。

语义由 Token Authority 判断，ACME 守住身份

新订单的 JWTClaimConstraints 标识符，携带经 DER 编码的 JWTClaimConstraints 或 EnhancedJWTClaimConstraints ASN.1 对象，再以无填充 base64url 表示。Authority Token 在 atc.tkvalue 中带回同一值，并以 JWTClaimConstraints 标明类型。

对象内部表达 STIR 生态的声明约束。Token Authority 根据 RFC 8226 与 RFC 9118，判断申请方有权代表哪些资源、允许提出哪些声明。第 05 版要求 ACME 客户端和服务器把内部结构视作不透明字节，不再解析并重做这项语义判断。

服务器的职责仍然严格：证明 Token Authority 签下的值，正是客户端原始订单里提出的值。共享规范因此可以保持很薄——一个规范线格式、一次精确相等判断，再加上发行者、时间、账户和证书角色的连接——而不是把 STIR 的治理语义复制进每台 ACME 服务器。

“意思一样”不是授权规则

DER 与无填充 base64url 共同给出单一的规范字节序列。服务器必须直接比较两段收到的 base64url 字符串。它不得先解码、重编码、再次规范化，或自行判断两种表达语义等价。

出现 = 填充、base64url 字母表之外的字符、空白、替代字母表、非 DER 的 BER，或任何一个字节不同，结果都应失败。草案还建议采用常数时间比较；即便这些值本身不保密，这仍是一项保守的实现纪律。

问题不在于编码是否整洁，而在于谁有权解释差异。每增加一个宽容转换器，就增加一套“哪些差别可以忽略”的授权规则，而且不同语言库和版本可能给出不同答案。精确比较把这层隐形权力移出验证器，也让运营方能用两段原始字符串的安全哈希、长度和比较结果复现实况。

一盏绿灯里其实有八张收据

第一，atc 必须是结构正确的对象，包含 tktype、tkvalue 与 fingerprint。第二，签名证书必须被配置为可信 Authority Token 发行者。第三，签名必须通过。第四，类型必须是 JWTClaimConstraints。第五，tkvalue 必须与保存的原始订单值逐字节相同。

第六，exp 必须存在，并按服务器时钟与本地小幅时钟偏差政策仍然有效；jti 也必须存在。第七，令牌里的指纹必须匹配提交响应的 ACME 账户密钥。第八，令牌的 ca 布尔值必须与证书签名请求中 Basic Constraints 的 CA 位相符。

账户指纹的路径揭示了职责分工。Token Authority 不用它来验证申请方是否控制 ACME 账户；它把指纹签进令牌，留给 ACME 服务器与实际账户密钥连接。一个参与者证明语义授权，另一个证明账户控制，两者不是同一事实。

任何一步失败，挑战都应变为无效，服务器可以返回 ACME 授权错误。若监控只留下“令牌无效”，便无法区分不可信发行者、证书取回失败、签名错误、字节漂移、时钟问题、交易标识缺失、账户替换或证书角色冲突。

签发之后才开始的可用性义务

授权通过后，证书签发仍是另一个 ACME 步骤。草案还允许 CA 在成功订单响应里给出一个可选 x5u，供证书持有人以后在 JWS 对象中引用已签发证书。CA 应让该网址在依赖方仍需验证签名期间保持可取，通常至少到证书过期。

这个签发后的 x5u 与验证 Authority Token 发行者证书时使用的 x5u 不是同一张收据。它们服务于不同阶段、不同密钥与不同保存期限。签发记录不能证明后来有人成功取得证书、接受证书，或接受任何电话声明。

证据边界

第 05 版于 2026 年 9 月 5 日发布，是预计 2027 年 3 月 9 日到期的 IETF 工作组 Internet-Draft。它仍可能改变，也不是 RFC。本文没有测试任何客户端、服务器、CA、Token Authority、运行时、证书仓库、运营商或通话路径。

现有来源不能证明部署、采用、互操作、成功签发、电话号码权利、通话认证或欺诈下降。文本给出了拟议合同；运行代码是否守住它，只能由真实执行凭证回答。

来源