Summary

  • RFC 9908 is an IETF Proposed Standard from January 2026 that updates RFC 7030 and RFC 9148.
  • Its clarified CSR Attributes encoding distinguishes an attribute OID from the value expected with it, including values for X.509 extensions.
  • CertificationRequestInfoTemplate lets an EST server constrain selected request fields while leaving client-owned values explicitly open.

Theo March analysis: the important change is not that EST receives a new approval decision. It is that /csrattrs can describe a request shape instead of merely presenting an ambiguous list of acceptable attribute types. A server may send a partially filled CertificationRequestInfoTemplate. It can supply an RDN value that the client is expected to use, or include an RDN while omitting its value so the client supplies a suitable one. The subject field itself is optional: it is present when the server has RDN requirements.

The same presence logic applies to the public-key information. subjectPKInfo is absent when the server has no key requirements; when present, its algorithm identifies the expected key-pair type. subjectPublicKey is normally absent. The special exception is a placeholder used to express an RSA modulus-length requirement. That placeholder is not the client’s final public key and must not be read as one.

This matters for the ACP and BRSKI enrollment use case described by RFC 8994 and RFC 8995, where the server needs to convey a specific subjectAltName through /csrattrs. RFC 9908 clarifies the encoding of that requirement and the X.509 extension requirements that accompany it. The template is a constraint on the CSR request information; it is not a CSR signature, a certificate approval, authentication, or a replacement for CA policy. Existing EST enrollment authentication and CA decisions remain separate concerns.

For interoperation, inspect bytes rather than accepting a response merely because a decoder accepts it. Compare the encoded attribute OID and its associated value; verify the ASN.1 presence or absence of subject, subjectPKInfo, and subjectPublicKey; check whether an RDN value is actually encoded or intentionally omitted; and confirm that an RSA modulus-length placeholder is not copied as the generated key. Then create the CSR and compare its DER CertificationRequestInfo with the template’s required values, including the requested subjectAltName, before examining the certificate chain.

Operator acceptance path: first record the /csrattrs response bytes and the server’s authenticated context. Next, identify every fixed value, every blank intended for client completion, and every absent structure whose semantics matter. Reject a client implementation that changes a supplied RDN value, treats an omitted RDN value as a fixed value, or turns the RSA placeholder into a public key. Finally, verify the resulting CSR and issued certificate against the request requirements. A decodable template alone is not acceptance evidence.

Sources