摘要

  • RFC 9908 是 IETF Proposed Standard，发布于 2026 年 1 月，更新 RFC 7030 与 RFC 9148。
  • 它澄清 CSR Attributes 中属性 OID 与属性值的编码，尤其处理 X.509 扩展值，并加入 CertificationRequestInfoTemplate 方法。
  • 服务器可以发送部分填写的模板：固定自身要求的值，把需要客户端决定的值保留为空；这不是 CSR 获批、签发或 CA 策略的表示。

EST 的关键变化不是多列出几种可接受的属性，而是让 /csrattrs 描述一次后续 CSR 的形状。客户端读取 OID 和对应值后，必须区分“字段不存在”“字段存在但值留空”以及“服务器已经给出值”。这些 ASN.1 结构差异不能被实现随意折叠成一个布尔要求。

CertificationRequestInfoTemplate 可包含 subject。subject 是可选的：只有服务器有 RDN 要求时才出现。服务器提供的 RDN 值，客户端应照用；如果某个 RDN 出现但没有值，则由客户端提供合适值。因此，空值不是“没有约束”的同义词，而是明确交给客户端完成的槽位。subjectPKInfo 在服务器没有密钥要求时缺失；出现时，其算法标识预期的密钥对类型。subjectPublicKey 通常也缺失，但在必须表达 RSA 模数长度要求时，可以携带占位值。这个占位值不是客户端最终生成的公钥。

这一点直接对应 ACP 与 BRSKI 的入网场景：服务器需要通过 /csrattrs 传达特定的 subjectAltName，而不只是告诉客户端“可以带某个扩展”。RFC 8994 的 autonomic control plane 与 RFC 8995 的 bootstrap 流程构成了需求背景。RFC 9908 的目标是澄清和增强既有 EST 语义，并保持面向既有使用方式的兼容方向；它没有替换 EST 身份认证，也没有替换 CA 的审批和证书策略。

**Theo March 分析：**模板是约束表达，不是批准信号。服务器发送模板并不意味着它签署或批准 CSR；认证仍需按 EST 流程进行，CA 仍可能依据自身政策拒绝请求。解码成功也不等于要求被正确继承到 CSR 和最终证书。

来源