Summary

  • RFC 9908 lets an EST server supply fixed values, required field types and client-filled slots for a later PKCS #10 request; the template proves an instruction, not approval of the requested identity.
  • Reliable certificate automation keeps separate evidence for template delivery, client completion, CSR signature and proof of possession, enrollment authentication, CA authorization, the issued certificate, deployment and observed use.

The enrollment dashboard showed a green identity check before any certificate request had been sent. Its evidence was a successful /csrattrs response. The response specified an organizational unit, asked the client to fill a common name, required a P-256 key and left one address slot open inside a subject alternative name. The system had learned a great deal about the request it wanted. It had not yet authenticated the requester for enrollment, seen the request signature, applied CA policy or issued anything.

That imagined dashboard is a common automation error, not an allegation about a product. A machine-readable instruction looks authoritative, so later decisions are projected backwards into it. RFC 9908 makes the instruction more expressive. Good governance must make the evidence chain at least as precise.

The RFC updates EST, Enrollment over Secure Transport, and its constrained-transport form in RFC 9148. EST already allowed a client to ask an enrollment server which attributes a certification request should contain. RFC 9908 resolves ambiguity about how the response carries both attribute identifiers and actual values, especially X.509 extension values.

Its new approach is deliberately close to a familiar object. CertificationRequestInfoTemplate resembles the information portion of a PKCS #10 certification request, but without the request's signature wrapper and with strategically optional fields. It is a mould for a future request, not a request and certainly not a certificate.

The optionality carries meaning. If the server has no requirement for the subject distinguished name, subject is absent. If it requires a particular kind of relative distinguished name, that RDN appears. A supplied value tells the client to use it; an RDN type without a value tells the client to fill a suitable value. The same discipline applies to subjectPKInfo: absence means the server expresses no key requirement there, while presence specifies the expected algorithm. An RSA-size requirement can use a placeholder public key of the desired modulus length.

RFC 9908 also defines id-aa-extensionReqTemplate. An extension template contains an extension identifier and can omit or partially fill the value. A server can require a subject alternative name, fix one name and leave another slot for the client. The client is expected to preserve supplied requirements and complete the open parts.

Those semantics solve a real interoperability problem. RFC 9908 describes the Autonomic Control Plane use case in which an EST server needs to convey a specific subject alternative name, as developed in RFC 8994. It also preserves the existing CsrAttrs wire structure and constrains the new encoding: the template version is v1, duplicate extension-template attributes are forbidden, and the old and new extension-request forms cannot appear together in the same template attributes.

None of this turns the response into an authorization token. RFC 7030 says requesting CSR attributes is optional and that the server ordinarily should not require client authentication or authorization simply to answer that request. It then states that, regardless of the response, the EST server and CA may reject a later enrollment request for any reason. A party that can receive construction advice has not thereby acquired a right to a certificate.

Enrollment introduces different witnesses. The server authenticates the client and checks that it is authorized for the requested service. The signed CSR provides proof of possession when the relevant private key can sign. EST can additionally bind that signed request to the authenticated TLS session. CMC, on which EST draws, supplies the wider proof-of-possession and certificate-management vocabulary.

These checks should not be compressed. Proof of possession answers whether the requester controls a private key corresponding to the public key. Channel authentication answers which client identity the server accepted. Authorization asks whether that identity may obtain this certificate, with these names and uses, under current policy. A device can possess a key without being entitled to router.example; an authenticated enrollment account can still request an unauthorized SAN.

The CA decision remains another layer. RFC 7030 says issuance is always controlled by local CA policy and even permits manual authorization with an asynchronous HTTP 202 response. PKCS #10 is equally clear: the CA authenticates the requester, verifies the request signature and, if the request is valid, constructs a certificate using both request material and CA choices. A syntactically perfect CSR can therefore be rejected, delayed or transformed by policy.

The issued certificate is the authoritative signed result. It should be retained and compared with the completed CSR and the decision record. The request may contain proposed attributes; the CA may use them along with other information to build extensions. The final certificate's serial number, validity, issuer, extensions and constraints belong to the issuance act, not to the earlier template.

Even issuance is not deployment. RFC 5280 defines certificate and path-validation machinery used later by relying parties. An issued certificate may remain in a queue, be installed on the wrong endpoint, coexist with its predecessor, never be presented, or be rejected by a peer's trust and policy. Inventory and observed handshakes are later evidence layers.

The minimum useful audit record is therefore a linked chain rather than one success flag. Retain the exact CSR-attributes response, the authenticated server context, retrieval time, cache lifetime and a template hash. Record which fields were fixed, open or absent. Bind the completed CSR to that template epoch. Store request bytes, signature validation, proof-of-possession result, authenticated client identity, authorization input, policy version, decision, issued certificate fingerprint, installation target and observation window.

Absence must remain meaningful. If a field is absent from the template, the server expressed no requirement through that field. Absence does not prove that a later value is permitted, prohibited or irrelevant. If the template supplies a fixed SAN, that proves the server instructed the client to request it. It does not explain why the server was entitled to make that instruction. Provenance and authorization must exist outside the ASN.1 value.

Compatibility deserves the same care. RFC 9908 maintains bits-on-the-wire compatibility, but not every installed client will understand every new template attribute correctly. Before publishing a richer template, operators need a client-capability inventory and an explicit fallback policy. Silently stripping unknown requirements is dangerous; silently treating a legacy response as equivalent may be equally wrong.

Rollback changes at each layer. A faulty template can be withdrawn and caches invalidated. A not-yet-processed CSR can be rejected. A bad policy decision can be stopped before signing. Once certificates have been issued and deployed, reverting the template does not remove them from endpoints or relying-party observations. Revocation, replacement, trust-store behavior and offline devices become separate decisions.

Heng Lu's Running-Code Primacy is useful here because publication is not execution. A template becomes operational through client parsing, completion and submission. Minimum Initial Specification argues for narrow shared semantics and locally verifiable decisions instead of expanding an initial specification into implied authority.

Reality Layers supplies the decisive discipline: instruction, request, possession, identity, authorization, signed artefact and observed operation are real in different ways. Data Sovereignty adds the institutional boundary. Technical capability to place a name in a request is not legal or organizational authority to claim that name.

RFC 9908 improves certificate automation by saying more clearly what the server expects the client to construct. Its value should not be inflated by collapsing everything that follows. The template describes the request. The signature proves a key relationship. Authentication identifies a channel participant. Policy authorizes or refuses. The CA signs an artefact. Operators deploy it. Relying parties observe and judge it. A trustworthy system can show every transition.

Sources