摘要

  • JWTClaimConstraints Authority Token 配置文件修订 05 规定，DER 编码的约束对 ACME 客户端和服务器是不透明字节串；两者只传送并逐字节比较，不解释其业务含义。
  • Token Authority 按所属领域规则做语义核验；部署生态另行决定 ACME 服务器把哪些签发者证书配置为可信。
  • 可选的 token-authority 只是客户端取令牌的位置提示。服务器验证时不使用它，而是要求令牌通过 x5u 或 x5c 指向已经进入信任配置的证书。
  • 修订 05 仍是工作组 Internet-Draft。验证成功不能被扩大解释成法律身份、来电真实性或跨生态普遍授权的证明。

新修订终于说清三层分工

作者在 2026 年 9 月 5 日发布了修订 05 公告。此前，ACME 主席的可实现性审阅追问规范性要求到底面向哪些实现者，以及若干字段应怎样处理。Chris Wendt 的回复与修改记录列出了对适用对象、签发者信任和 token-authority 用法的澄清。

这份配置文件服务于 Secure Telephone Identity 证书颁发机构。它用 ACME 自动证明申请者对 JWTClaimConstraints 证书扩展具有某种授权；该扩展会限制凭证能够提出的声明。RFC 9448定义扩展本身，RFC 8226与 RFC 9118提供证书和增强约束的规则背景。

修订 05 正文把工作分给三个角色。ACME 客户端提交标识符并取得令牌；ACME 服务器核验挑战响应；Token Authority 先按领域规则判断申请的约束是否适当，再签发授权令牌。

界线直接体现在约束值的处理上。对客户端和服务器而言，标识符中的 DER 值只是经过 base64url 表示的不透明八位字节串。它们保留原样传送，并要求令牌里的值与订单里的值逐字节完全相同。它们不会打开 mustInclude、permittedValues 或 mustExclude 来判断组合是否合理；语义责任留给 Token Authority。

这是一次克制，而非功能缺口。RFC 8555让 ACME 自动管理证书，并没有因此赋予通用挑战服务器治理电话号码声明约束的制度权限。格式正确与权利成立，本来就是两个命题。

客户端发现地址不等于服务器信任入口

token-authority 参数很容易被读成“指定可信权威”。修订 05 明确否定这种读法：它只是给客户端的可选建议，告诉客户端可以去哪里尝试取得令牌。服务器验证挑战响应时忽略这个值。

签发者证书由令牌中的 x5u 或 x5c 提供，两者不能同时缺失。服务器读取或获取证书、核验令牌签名，还必须确认该证书已经被自身配置为本生态的 Authority Token 可信签发者。证书引用只解决“从哪里取密钥”，不会自动产生“为什么信任它”。

信任根及 Token Authority 证书的生态特定要求由部署生态建立，草案仅把 STIR 治理作为例子。谁能进入名单、权限范围多大、何时暂停或撤销、错误决定如何申诉，都不在这份配置文件的规范范围内。

这一前提并非突然出现。已经是 Standards Track 的 RFC 9447假定 CA 与 Token Authority、客户端与 Token Authority 之间预先存在关系，并说明无法假定这些关系时，该挑战并不适用。新草案改变的是约束内容的表达方式，没有发明一套全球统一的授权机构。

服务器能证明一组边界清晰的技术事实

在可信签发者已经配置的前提下，服务器仍要完成多项核验。它检查令牌结构和类型、验证签名，要求 exp 存在且当前有效，要求 jti 存在，并确认令牌绑定到发起订单的 ACME 账户密钥。它还核对 ca 标志与申请的证书类型是否一致。

随后，服务器逐字节比较令牌约束和标识符约束。任一步骤失败，挑战进入 invalid 状态，并应返回 ACME 问题文档，通常使用 unauthorized。这些规则阻止一枚令牌轻易跨账户、跨申请形式或跨约束内容复用。

但结论必须止步于此。exp 证明令牌在配置文件定义的时间窗口内，签名证明相应密钥签过消息，字节相等证明两个位置引用同一编码约束。这三者都没有显示是谁将签发者加入信任、适用哪个政策版本、它被委托了哪一类范围，以及语义判断出错后由谁纠正。

Datatracker 当前页面仍把文稿标为活跃且 In WG Last Call，IESG 状态只是 I-D Exists；没有 document shepherd、负责 Area Director 或 telechat 日期。早先征询已写明 7 月 25 日结束，因而不能从页面标签推断现在仍开放评论。修订 05 不是已批准 RFC，也不是实现、互操作或部署报告。

草案还约束每个订单至多放一个 JWTClaimConstraints 标识符和一个 TNAuthList 标识符。对已经签发的证书，x5u 地址应在依赖方仍可能需要时保持可取，通常至少到证书过期。这能保留日后核验所需材料，却仍无法还原签发者何以获得信任。

最薄的补件是一张约束权威回执

部署生态可以为每项决定生成“约束权威回执”。回执不公开电话号码或原始私密约束，只绑定生态政策标识与版本、Token Authority 身份与可信证书指纹、获准处理的约束族和委托范围类别，以及 ACME 订单与编码约束的哈希。

它还应记录令牌签发、决定和过期时间，结果与有限错误类别，信任条目的生效和撤销状态，以及纠正、事件或申诉联系人。最后明确：协议验证成功不是对法律身份、来电真实性或生态之外普遍权利的裁决。

这张回执是 Daniel Kade 的编辑建议，不是 IETF 现有要求。它应由实际执行信任政策的系统直接生成，而不是人工抄进第二本礼仪性台账。目标仅是让审计者把有效交换连接到真正赋予权威的政策，同时继续隐藏敏感订单内容。