摘要

  • RFC 9908 允许 EST 服务器为后续 PKCS #10 请求提供固定值、必填字段类型以及留给客户端补齐的空位；它证明的是构造指令，而不是身份获批。
  • 可靠的证书自动化应分别保存模板交付、客户端补值、CSR 签名与持钥证明、入站身份认证、CA 授权、已签证书、安装以及实际使用的证据。

一份 /csrattrs 响应抵达设备：组织单位已经写定，通用名要由设备填写，公钥必须采用 P-256，主题备用名称里还有一个地址空位。运维平台随即把这台设备标成“身份已批准”。但此时设备尚未提交签名请求，服务器也没有完成入站认证，CA 更没有适用本地策略或签出证书。

这是一个假设场景，却点出了自动化中的真实诱惑：机器可读的指令看上去很像机器作出的决定。RFC 9908 消除了请求属性编码中的含混，治理系统不能反过来把后续权力塞回这个前置对象。

该标准更新了 RFC 7030 的 EST，也更新了通过 CoAP 运行 EST 的 RFC 9148。EST 原本就允许客户端询问 CA 期望在证书请求中看到哪些属性。争议在于服务器怎样携带具体属性值，尤其是 X.509 扩展值。RFC 9908 保留原有 CsrAttrs 线上结构，同时把语义说清，并引入更直接的模板。

CertificationRequestInfoTemplate 类似 PKCS #10 中的请求信息部分，却没有签名外壳，而且若干字段可以按规则省略。它是一张部分填好的底稿，不是完整 CSR，更不是证书。

省略本身有含义。服务器对主体可分辨名称没有要求时，subject 应当缺席；如果要求某类 RDN，则必须把该类型放入模板。类型与值同时出现，表示客户端应使用给定值；只有类型而没有值，则表示客户端应填入合适内容。subjectPKInfo 缺席意味着服务器没有在这里提出密钥要求；存在时，算法字段规定预期密钥类型。若服务器要求特定 RSA 长度，还可用占位公钥表达模数长度。

新的 id-aa-extensionReqTemplate 把这套逻辑扩展到证书扩展。服务器可以给出扩展标识符，完整提供、部分提供或不提供其值。例如一个 SAN 可同时含有服务器确定的名称和客户端需要补齐的地址。RFC 8994 所述自治控制平面正需要 EST 服务器传递特定 subjectAltName，这也是澄清的现实动因之一。

模板版本必须是 v1；其中不能重复出现 id-aa-extensionReqTemplate，也不能让旧的 id-ExtensionReq 与新模板属性并存。这些规则确保编码和互操作边界，却没有赋予模板任何身份裁决权。

RFC 7030 对这一点给出了直接证据。获取 CSR 属性是可选动作，服务器通常不应仅为回答该查询就要求客户端认证或授权。不论属性响应是什么，EST 服务器和 CA 都可以基于任何理由拒绝后续入站请求。知道表格怎样填，并不等于取得证书。

完整 CSR 到来后才出现另一组见证。服务器要认证客户端，并验证它是否有权使用所请求的服务。CSR 的签名在适用时证明客户端持有与公钥对应的私钥。EST 还可以把签名请求与已认证的 TLS 会话绑定。RFC 5272 则提供 EST 所采用的 CMC 持钥证明与证书管理背景。

三项检查不能合并。持钥证明回答“是否控制这把私钥”；入站认证回答“服务器接受了哪个连接方身份”；授权回答“该身份能否获得带有这些名称、扩展和用途的证书”。控制一把密钥不会自动获得某个 DNS 名；登录成功也不会让 CSR 中的所有 SAN 合法。

CA 的决定仍是独立层。RFC 7030 明确说签发始终由 CA 本地策略控制，也允许进入人工授权并用 HTTP 202 表示尚未完成。PKCS #10 同样把过程写成：CA 认证请求方、验证签名，并在请求有效时结合自身选择和其他信息构造 X.509 证书。格式正确的请求仍可被拒绝、延迟或调整。

最终证书必须作为新的签名制品保存。序列号、有效期、签发者、扩展和约束要从证书本身读取，不能由模板推断。把模板、完成后的 CSR、策略决定和证书逐项比较，才能知道哪些值由服务器固定、由客户端补充、由 CA 接受、修改或新增。

签出证书也不等于投入运行。RFC 5280 规定 X.509 配置与依赖方的路径验证。证书可能留在队列、装错端点、与旧证书并存，或被对端信任策略拒绝。安装清单和握手观察属于更晚的现实层。

因此，最低可审计记录不是一个绿色状态，而是一条带版本的证据链。保存 /csrattrs 原始字节、服务器身份、获取时间、缓存期限与模板哈希；标出固定值、客户端空位及缺席字段；把最终 CSR 绑定到实际使用的模板版本；再记录签名验证、持钥证明、认证身份、授权输入、策略版本、CA 决定、证书指纹、安装目标和观察窗口。

负面语义尤其重要。模板中没有某字段，只能证明服务器没有通过该字段提出要求，不能证明后来的值被允许或禁止。服务器在模板里给出固定 SAN，只能证明它指示客户端请求该名称，不能证明组织为何有权授权该名称。授权来源必须在 ASN.1 之外留下记录。

兼容也不是一句“线上结构不变”就结束。旧客户端未必理解新模板属性，更未必正确处理部分填值。上线前需要客户端能力清单、灰度观察和明确的遗留路径。静默丢弃未知要求会造成危险；未经批准便把旧响应当作等价替代同样危险。

回退的含义随阶段改变。错误模板可撤回，缓存可失效，待处理 CSR 可拒绝。证书一旦签发并部署，恢复旧模板不会让它从设备或依赖方视野中消失；是否吊销、替换、容忍以及如何处理离线设备，都要另作决定。

Heng Lu 的运行代码优先提醒我们，发布模板不是执行结果。最小初始规范、未来决定本地化与自愿采纳则要求共同语义保持狭窄，不因便利而膨胀成隐含权力。

现实层在这里可以逐层落地：指令、请求、持钥、身份、授权、签名制品和实际运行各自回答不同问题。数据主权的技术与实践之别进一步说明，技术上能把名称放进请求，不等于法律或组织上有权取得该名称。

RFC 9908 的进步在于更精确地表达服务器期望客户端构造什么。尊重这份精确，就不应让模板冒充后续判断。模板指导，客户端补齐并签名，服务器认证，策略授权，CA 签发，运维部署，依赖方验证。可信度来自每一次转换都能被单独证明。

来源