]> NIO

lijun.liao@nio.io

This document defines eight new operations for the Enrollment over Secure Transport (EST) protocol specified in RFC 7030: ucacaps, ucacert, ucacerts, ucrlinfo, ucrl, usimpleenroll, usimplereenroll, and userverkeygen. These operations deliver PKI objects, including CA certificates, certificate chains, CRLs, and enrolled certificates, as Base64-encoded DER or PEM, without the CMS encapsulation used by the corresponding EST operations in RFC 7030. The ucacaps operation enables EST clients to discover which operations the EST server supports. Eliminating the CMS wrapper for these responses reduces code size and parsing complexity. This document updates RFC 7030.

Introduction Enrollment over Secure Transport (EST) defines a set of HTTPS-based operations for certificate enrollment and management. An EST server sits between a Certification Authority (CA) and an EST client and performs Registration Authority (RA) functions, as described in . updates RFC 7030 to clarify EST transfer-encoding behavior and ASN.1 details. further updates RFC 7030 and RFC 9148 to clarify and enhance the csrattrs definition. The responses to the standard EST operations (cacerts, simpleenroll, simplereenroll, and serverkeygen) are encapsulated in Cryptographic Message Syntax (CMS) structures , specifically using the application/pkcs7-mime; smime-type=certs-only content type. While CMS provides a well-established container format, parsing it requires code that may be unnecessary or unavailable in some EST deployments . EST-coaps addresses EST over CoAP and DTLS by defining shorter resource paths, using CoAP Block-Wise Transfer for fragmentation, and allowing binary ASN.1 payloads. It also defines Content-Format 287 (application/pkix-cert) as a non-CMS single-certificate response format that can be selected using CoAP content negotiation. However, RFC 9148 primarily specifies EST semantics for CoAP-based networks and does not define the HTTPS operations or the CRL metadata and retrieval operations defined in this document. The relationship with RFC 9148 is discussed in . This document also addresses two functional gaps. First, provides no capability-discovery operation for these new operations, so an EST client would otherwise need to rely on out-of-band configuration or probing. The ucacaps operation enables the client to discover server support explicitly. Second, does not define in-band CRL metadata or retrieval operations; revocation information is normally obtained from CRL Distribution Point (CDP) URIs carried in certificates. The ucrlinfo operation supports lightweight freshness checks, and the ucrl operation provides an EST-based retrieval path when the full CRL is needed. This document adds eight new operations to (Protocol Exchange Details), as summarized in : New Operations Defined in This Document

New Operation	Based on RFC 7030 Operation	Auth	Response Format
ucacaps	(new)	No	text/plain keyword list
ucacert	(new)	No	application/pkix-cert (single CA cert)
ucacerts	cacerts ()	No	application/pem-certificate-chain
ucrlinfo	(new)	No	text/plain (CRL metadata)
ucrl	(new)	No	application/pkix-crl
usimpleenroll	simpleenroll ()	Yes	application/pkix-cert
usimplereenroll	simplereenroll ()	Yes	application/pkix-cert
userverkeygen	serverkeygen ()	Yes	application/x-pem-file (key + cert)

These eight operations fall into four categories: capability discovery (ucacaps), CA certificate retrieval (ucacert, ucacerts), CRL metadata and retrieval (ucrlinfo, ucrl), and certificate enrollment and server-side key generation (usimpleenroll, usimplereenroll, userverkeygen). The "u" prefix is used consistently across all eight new operations. For the six operations whose responses carry DER or PEM payloads (ucacert, ucacerts, ucrl, usimpleenroll, usimplereenroll, userverkeygen), it denotes "unencapsulated": their responses carry DER or PEM payloads without a CMS wrapper. For ucacaps (capability discovery) and ucrlinfo (CRL metadata), there is no CMS equivalent; the "u" prefix is used solely to maintain a consistent naming convention with the other operations in this document. All security requirements imposed by on the corresponding RFC 7030 operations (cacerts, simpleenroll, simplereenroll, serverkeygen) apply equally to the corresponding operations defined in this document. Refer to for security considerations specific to these new operations.

Conventions and Definitions The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in BCP 14 when, and only when, they appear in all capitals, as shown here. The following terms from are used in this document:

EST client:

The entity that contacts the EST server to obtain certificates or CA information, as defined in .

EST server:

The entity that processes EST requests, typically acting as an RA between the EST client and the CA, as defined in .

CA:

Certification Authority. The entity that issues X.509 certificates .

CSR:

Certificate Signing Request. A PKCS#10 message used by an EST client to request certificate issuance.

PoP:

Proof of Possession. Verification that the requester holds the private key corresponding to the public key in the CSR, as described in .

EST URL Structure and Path Components The operations in this document follow the same URI path structure defined in . Retrieval operations (ucacaps, ucacert, ucacerts, ucrlinfo, ucrl) use HTTP GET: GET /.well-known/est// ]]> Enrollment operations (usimpleenroll, usimplereenroll, userverkeygen) use HTTP POST: POST /.well-known/est// ]]> An EST server MUST return HTTP 405 (Method Not Allowed) if a client uses POST for a retrieval operation or GET for an enrollment operation. In the URI templates above, <operation> is one of: ucacaps, ucacert, ucacerts, ucrlinfo, ucrl, usimpleenroll, usimplereenroll, or userverkeygen. The optional <label> path segment follows : an EST server MAY use an additional path segment before the operation name to distinguish services for multiple CAs or certificate profiles. The <label> MUST NOT be the same as any defined operation name. The internal structure and interpretation of <label> are outside the scope of this document; for example, it may be a single opaque token that identifies a CA and certificate profile, or a slash-separated pair of the form <ca-name>/<cert-profile>.

Base64 Transfer deprecates use of Content-Transfer-Encoding for EST. The new operations defined in this document follow that guidance. For operations that return DER payloads (application/pkix-cert, application/pkix-crl), the response body MUST be the Base64 encoding defined in of the DER object. Servers MUST NOT include a Content-Transfer-Encoding header. For POST operations that submit a PKCS#10 CSR, the request body MUST be the Base64 encoding defined in of the DER-encoded PKCS#10 object. Clients and servers implementing this document MUST NOT require or generate a Content-Transfer-Encoding header for these operations. The ucacaps, ucrlinfo, ucacerts, and userverkeygen operations already return textual payloads and therefore do not require any additional transfer-encoding mechanism. The ucacert, ucacerts, and ucrl retrieval operations support HTTP caching. EST servers SHOULD provide caching metadata on successful authoritative responses so that clients and HTTP intermediaries can reuse them. EST clients SHOULD cache authoritative responses locally and refresh them according to the advertised freshness information. Authoritative responses for these operations MUST NOT include Pragma: no-cache, Cache-Control: no-cache, or Cache-Control: no-store.

EST Server Capability Discovery EST does not provide a mechanism for EST clients to discover which operations an EST server supports before invoking them. This section defines the ucacaps operation for that purpose. EST clients SHOULD issue a ucacaps request before using any of the other operations defined in this document, to confirm that the EST server supports the intended operation.

ucacaps

Request The EST client requests the server's capability list using the HTTP GET method. No request body is sent. The EST server SHOULD NOT require client authentication for this operation, consistent with . /ucacaps ]]>

Response On success, the EST server returns HTTP status 200 with:

• Content-Type: text/plain
• Body: A plain-text list of capability keywords, one keyword per line. Lines MUST be terminated by <CR><LF> or <LF>. Keywords are unquoted and case-insensitive; EST clients MUST match them in a case-insensitive manner.

The EST server SHOULD use the canonical lowercase form defined in . The EST server MAY advertise additional, implementation-specific keywords not defined in this document. EST clients MUST ignore any unknown keywords. If the EST server supports none of the capabilities listed in , it SHOULD return an empty body. An EST client that receives an empty body SHOULD interpret the response as if none of the capabilities are supported. An EST client that receives an HTTP error response to a ucacaps request SHOULD assume that only the operations defined in are supported and MUST NOT attempt the operations defined in this document.

Choice of Capability-List Format The ucacaps response uses text/plain rather than JSON or CBOR because the information being conveyed is intentionally limited to an unordered set of capability keywords. A line-oriented keyword list can be parsed with minimal code, can be inspected manually, and does not require a JSON, CBOR, or CMS parser. This is consistent with the purpose of this document: reducing parsing requirements in EST deployments that do not implement CMS. JSON and CBOR are both suitable formats when a protocol needs structured values, nested data, typed fields, or extensible objects. The ucacaps response does not require those properties. Each advertised capability is a single token, unknown tokens are ignored, and absence of a token has a simple meaning. Adding a structured encoding for this operation would therefore increase implementation requirements without adding protocol semantics. Future specifications that need to advertise parameters associated with a capability, such as algorithm lists, profile identifiers, size limits, or transport-specific options, can define additional capability keywords or a separate structured discovery operation. Such an extension would be preferable to overloading the simple ucacaps keyword list with structured data.

Capability Keywords The following keywords are defined. An EST server MUST include a keyword in the ucacaps response if and only if it supports the corresponding operation. RFC 7030 operations (see also ): ucacaps Keywords for RFC 7030 Operations

Keyword	Description
cacerts	EST server supports cacerts ()
simpleenroll	EST server supports simpleenroll ()
simplereenroll	EST server supports simplereenroll ()
fullcmc	EST server supports fullcmc ()
serverkeygen	EST server supports serverkeygen ()
csrattrs	EST server supports csrattrs (, as updated by )

RFC 8295 operations (see also ): ucacaps Keywords for RFC 8295 Operations

Keyword	Description
pal	EST server supports pal ()
eecerts	EST server supports eecerts ()
crls	EST server supports crls ()
symmetrickeys	EST server supports symmetrickeys ()
symmetrickeys/return	EST server supports symmetrickeys/return ()
firmware	EST server supports firmware ()
firmware/return	EST server supports firmware/return ()
tamp	EST server supports tamp ()
tamp/return	EST server supports tamp/return ()
serverkeygen/return	EST server supports serverkeygen/return ()

Operations defined in this document (see also ): ucacaps Keywords Defined in This Document

Keyword	Description
ucacert	EST server supports ucacert ()
ucacerts	EST server supports ucacerts ()
ucrlinfo	EST server supports ucrlinfo ()
ucrl	EST server supports ucrl ()
usimpleenroll	EST server supports usimpleenroll ()
usimplereenroll	EST server supports usimplereenroll ()
userverkeygen	EST server supports userverkeygen ()

Capability keywords are case-insensitive; the canonical (registered) form is lowercase as shown in the tables above. An EST server SHOULD use the canonical lowercase form. An EST client MUST accept keywords in any case and MUST ignore unknown keywords. Note: designates cacerts, simpleenroll, and simplereenroll as MUST-implement operations. An EST server implementing this document SHOULD include these three keywords in every ucacaps response so that a client can enumerate all capabilities from a single request. Example response: This response indicates that the EST server supports the three mandatory RFC 7030 operations, serverkeygen, the RFC 8295 crls operation, and all operations defined in this document.

Distribution of CA Certificates This section defines two operations that provide EST clients with CA certificate material. ucacert is a new operation with no RFC 7030 equivalent. ucacerts is an alternative encoding of the cacerts operation (), returning the chain as a PEM-encoded certificate chain (application/pem-certificate-chain ) without a CMS wrapper.

ucacert The ucacert operation returns the issuing CA certificate for the requested EST service as a single DER-encoded X.509 certificate. This differs from cacerts in two important ways: (1) only the issuing CA certificate is returned, not the full certificate chain; and (2) the certificate is returned without a CMS wrapper.

Request The EST client requests the CA certificate using the HTTP GET method. No request body is sent. The EST server SHOULD NOT require client authentication for this operation, consistent with . /ucacert ]]>

Response On success, the EST server returns HTTP status 200 with:

• Content-Type: application/pkix-cert
• Body: The Base64 encoding of the DER-encoded X.509 certificate of the issuing CA.

The returned certificate is the issuing CA certificate for the requested EST service context, as selected by the EST server for the target <label> (if any). The response contains exactly one certificate. Successful ucacert responses SHOULD include HTTP caching metadata. In particular, EST servers SHOULD include ETag and Last-Modified headers. EST servers SHOULD include Cache-Control and Expires headers when the certificate lifetime or the local CA-certificate replacement policy provides a meaningful freshness bound.

Relationship to cacerts The cacerts operation () returns the full certificate chain (issuing CA plus any intermediate and root CAs) wrapped in a CMS certs-only structure (application/pkcs7-mime; smime-type=certs-only). ucacert differs in two respects:

1. Scope: ucacert returns only the issuing CA certificate; the full chain is not included. EST clients that need the full chain for path validation should use ucacerts () or cacerts ().
2. Format: The certificate is returned as the Base64 encoding of a single DER-encoded X.509 certificate , with no CMS wrapper.

ucacerts The ucacerts operation returns the CA certificate chain for the requested EST service () as a PEM-encoded certificate chain (application/pem-certificate-chain), without a CMS wrapper.

Request The EST client requests the CA certificate chain using the HTTP GET method. No request body is sent. The EST server SHOULD NOT require client authentication for this operation, consistent with . /ucacerts ]]>

Response On success, the EST server returns HTTP status 200 with:

• Content-Type: application/pem-certificate-chain
• Body: A PEM-encoded certificate chain containing one or more certificates. The first certificate is the issuing CA certificate; subsequent certificates are the trust chain up to and including the root CA, each encoded as a CERTIFICATE PEM block.

Successful ucacerts responses SHOULD include HTTP caching metadata. In particular, EST servers SHOULD include ETag and Last-Modified headers. EST servers SHOULD include Cache-Control and Expires headers when the chain lifetime or the local CA-certificate replacement policy provides a meaningful freshness bound.

Comparison to cacerts The cacerts operation () wraps the certificate chain in a CMS certs-only structure. ucacerts delivers the same chain as concatenated PEM blocks that many TLS and PKI libraries can parse directly without a CMS library.

Distribution of Certificate Revocation Lists This section defines the ucrlinfo and ucrl operations. Neither operation has an equivalent in . defines the crls EST extension for distribution of one or more CRLs (and ARLs), but it does not define a lightweight CRL-metadata operation corresponding to ucrlinfo. Revocation status is also commonly obtained via the CRL Distribution Points (CDP) extension in issued certificates. The ucrlinfo operation returns lightweight metadata for the current CRL, including CRL number, validity window, issuer, and SHA-256 fingerprint, without downloading the full CRL body. The ucrl operation provides an in-band retrieval path for that same current CRL when the full object is needed.

ucrlinfo The ucrlinfo operation returns metadata about the current CRL for the target CA without downloading the full CRL body. This enables an EST client to check whether its locally cached CRL is still current (by comparing nextupdate, crlnumber, or sha256sum) before deciding to issue a ucrl request. Unlike the RFC 8295 crls operation, ucrlinfo does not describe a set of CRLs; it describes only the current CRL selected by the EST server for the target CA.

Request The EST client requests the CRL metadata using the HTTP GET method. No request body is sent. The EST server SHOULD NOT require client authentication for this operation, consistent with . /ucrlinfo ]]>

Response On success, the EST server returns HTTP status 200 with:

• Content-Type: text/plain
• Body: A plain-text list of CRL metadata fields, one field per line. Lines MUST be terminated by <CR><LF> or <LF>. Each line has the form <name>=<value>. Field order is not significant; EST clients MUST accept fields in any order and MUST ignore unknown field names.

Field names are case-insensitive; the canonical (registered) form is lowercase as shown in . EST servers SHOULD use the canonical lowercase form. EST clients MUST match field names in a case-insensitive manner. The defined fields are listed in . Date/time values are expressed as Unix time (seconds since 1970-01-01T00:00:00Z). ucrlinfo Response Fields

Field name	Value	Presence
sha256sum	Base64-encoded SHA-256 digest of the DER-encoded CRL	MUST
issuer	Single-line Base64-encoded DER encoding of the CRL issuer field ()	MUST
thisupdate	thisUpdate time of the CRL as Unix time (seconds since 1970-01-01T00:00:00Z) ()	MUST
nextupdate	nextUpdate time of the CRL as Unix time (seconds since 1970-01-01T00:00:00Z) ()	MUST if present in CRL
crlnumber	Decimal representation of the CRL Number extension value ()	MUST if present in CRL

Choice of CRL-Metadata Format The ucrlinfo response uses text/plain rather than JSON or CBOR because the response is a small set of independent name=value fields. The values are already encoded as simple strings: Unix time values for freshness checks, decimal text for the CRL number, and Base64 text for binary DER or digest values. A line-oriented format lets an EST client compare freshness indicators and decide whether to download the CRL without adding a JSON, CBOR, CMS, or ASN.1 parser for the metadata response itself. JSON or CBOR would be useful if ucrlinfo needed nested objects, arrays, typed alternatives, or complex policy information. This operation deliberately avoids those semantics. Field order is insignificant, unknown fields are ignored, and each defined field has a single textual representation, so a structured container would add implementation cost without changing the protocol semantics. Future specifications that need richer revocation metadata can define additional fields with simple textual encodings or a separate structured operation. Such an extension would be preferable to changing the base ucrlinfo response format. Example response: If no current CRL is available, the EST server MUST return HTTP status 503 (Service Unavailable). The server MAY include a Retry-After header to indicate when the CRL is expected to become available.

ucrl The ucrl operation returns the current CRL for the target CA as a DER-encoded CRL. Unlike the RFC 8295 crls operation, which distributes one or more CRLs in a CRL package, ucrl returns only the single current CRL selected by the EST server for the target CA.

Request The EST client requests the current CRL using the HTTP GET method. No request body is sent. The EST server SHOULD NOT require client authentication for this operation, consistent with . /ucrl ]]>

Response On success, the EST server returns HTTP status 200 with:

• Content-Type: application/pkix-crl
• Body: The Base64 encoding of the DER-encoded X.509 CRL of the target CA.

Successful ucrl responses SHOULD include HTTP caching metadata. In particular, EST servers SHOULD include Last-Modified, ETag, Expires, and Cache-Control headers. When present, Last-Modified SHOULD reflect the CRL thisUpdate value, and Expires SHOULD reflect the CRL nextUpdate value. The Cache-Control header SHOULD include a max-age value no later than the advertised nextUpdate, together with the public, no-transform, and must-revalidate directives. If no current CRL is available, the EST server MUST return HTTP status 503 (Service Unavailable). The server MAY include a Retry-After header to indicate when the CRL is expected to become available.

Client Certificate Request Functions This section defines three enrollment operations that extend the Client Certificate Request Functions of and the Server-Side Key Generation operation of .

Client Authentication The enrollment operations defined in this section (usimpleenroll, usimplereenroll, and userverkeygen) require client authentication. The client authentication requirements are unchanged from . EST clients and EST servers MUST follow and for client authentication, respectively.

usimpleenroll The usimpleenroll operation requests a new certificate from the EST server () and returns the issued certificate as a DER-encoded X.509 certificate.

Request An authenticated EST client submits a PKCS#10 CSR using the HTTP POST method. The request body is the Base64 encoding of the DER-encoded PKCS#10 CSR. /usimpleenroll Content-Type: application/pkcs10 ]]> The CSR MUST include a valid PoP signature. The EST server MUST verify the PoP signature against the public key in the CSR before issuing a certificate, as required by .

Response On success, the EST server returns HTTP status 200 with:

• Content-Type: application/pkix-cert
• Body: The Base64 encoding of the DER-encoded X.509 certificate issued for the subject in the CSR.

Comparison to simpleenroll The simpleenroll response () wraps the issued certificate in a CMS certs-only structure (application/pkcs7-mime; smime-type=certs-only). usimpleenroll returns that certificate as the Base64 encoding of a single DER-encoded certificate.

usimplereenroll The usimplereenroll operation renews or rekeys an existing certificate () and returns the renewed certificate as a DER-encoded X.509 certificate.

Request An authenticated EST client submits a PKCS#10 CSR for re-enrollment using the HTTP POST method. The request body is the Base64 encoding of the DER-encoded PKCS#10 CSR. /usimplereenroll Content-Type: application/pkcs10 ]]> Re-enrollment processing follows .

Response On success, the EST server returns HTTP status 200 with:

• Content-Type: application/pkix-cert
• Body: The Base64 encoding of the DER-encoded renewed X.509 certificate.

Comparison to simplereenroll The simplereenroll response () wraps the renewed certificate in a CMS certs-only structure. usimplereenroll returns that certificate as the Base64 encoding of a DER-encoded certificate.

userverkeygen The userverkeygen operation requests server-side key generation and returns the generated private key and certificate ().

Request An authenticated EST client requests server-side key generation by submitting a PKCS#10 CSR using the HTTP POST method. Because the key pair is generated by the EST server, the SubjectPublicKeyInfo in the CSR SHOULD be absent or contain a placeholder. EST servers MUST NOT require a specific public key to be present. Likewise, the CSR signature is only a placeholder because the client possesses no corresponding private key. The EST client MAY use the id-alg-unsigned algorithm (OID 1.3.6.1.5.5.7.6.36) defined in to signal explicitly that the signature field is intentionally unsigned. EST servers MUST accept CSRs that use id-alg-unsigned. The request body is the Base64 encoding of the DER-encoded PKCS#10 CSR. /userverkeygen Content-Type: application/pkcs10 ]]> Unlike usimpleenroll, the EST server MUST NOT verify a PoP signature for userverkeygen because no client-generated public key is being certified (consistent with ). If the CSR uses id-alg-unsigned (), there is no signature value to check.

Response On success, the EST server returns HTTP status 200 with:

• Content-Type: application/x-pem-file
• Body: A sequence of PEM textual encodings containing exactly two label-value pairs in the following order:
  1. PRIVATE KEY: the PKCS#8 DER-encoded private key, Base64-encoded within the PEM encapsulation boundary.
  2. CERTIFICATE: the DER-encoded X.509 certificate issued for the generated key pair, Base64-encoded within the PEM encapsulation boundary.

• Note: The media type application/x-pem-file is a widely deployed convention for PEM-encoded () cryptographic objects. It predates the IETF media type registration process and is not registered in the IANA Media Types registry. No IANA-registered media type currently exists for a single message body carrying both a private key and a certificate in PEM textual encoding. This document uses application/x-pem-file to remain consistent with existing deployments. A future revision MAY register an appropriate media type with IANA and update this specification accordingly.

Example response body: -----END PRIVATE KEY----- -----BEGIN CERTIFICATE----- -----END CERTIFICATE----- ]]> The EST server SHOULD delete the private key from its storage as soon as the response has been transmitted successfully, unless the deployment policy requires retention for key escrow or disaster recovery (see ). The private key is protected only by the TLS channel; no additional encryption is applied.

Comparison to serverkeygen The serverkeygen response () uses a multipart/mixed MIME response containing a PKCS#8 part and a CMS certs-only part. userverkeygen delivers the same material in a single PEM file, eliminating the need for a MIME multipart parser and a CMS library.

Security Considerations The security requirements of apply in full to all operations defined in this document. The following subsections address security considerations specific to the new operations.

Transport Security All operations defined in this document MUST be carried out over HTTPS (HTTP over TLS) as required by . Implementations MUST NOT fall back to plain HTTP. EST servers MUST present a TLS certificate that EST clients can validate against a configured trust anchor, and EST clients SHOULD reject server certificates that cannot be validated. Implementers SHOULD consult for guidance on TLS version, cipher suite selection, and certificate profiles when those recommendations are applicable to the deployment.

Client Authentication The ucacaps, ucacert, ucacerts, ucrlinfo, and ucrl retrieval operations follow the same authentication policy as the cacerts operation defined in : the EST server SHOULD NOT require client authentication for these operations. CRLs and related CRL metadata are public information that relying parties must be able to retrieve without impediment; requiring authentication for ucrlinfo or ucrl would hinder revocation checking, consistent with the design intent of CRL distribution points in . Enrollment operations (usimpleenroll, usimplereenroll, userverkeygen) MUST require client authentication as specified in . When HTTP Basic authentication is used, the considerations in apply. In particular, the user:password credential is Base64-encoded and visible to any observer that can read the TLS plaintext. Basic authentication MUST therefore only be used inside a TLS session. EST servers SHOULD rate-limit failed authentication attempts to mitigate brute-force attacks against user credentials. When TLS client certificate authentication is used, the requirements and considerations in apply.

Proof of Possession usimpleenroll and usimplereenroll MUST verify the PoP signature in the PKCS#10 CSR before issuing a certificate, as required by . An EST server that skips PoP verification may issue certificates for public keys that the requester does not control, undermining the binding between the certified key pair and the subscriber. The userverkeygen operation does not require PoP verification because the EST server generates the key pair itself (see ). The authenticity of the request is therefore established solely by client authentication (). EST servers MUST enforce client authentication at least as strongly for userverkeygen as for the other enrollment operations.

Private Key Delivery The userverkeygen operation delivers a generated private key to the EST client over TLS in a PEM file. This follows the same model as the serverkeygen operation in . The following additional considerations apply:

• The EST server SHOULD delete the generated private key immediately after the response has been transmitted successfully. If the deployment requires the server to retain a copy (e.g., for key escrow or disaster recovery), the private key MUST be stored in encrypted form with access controls that restrict retrieval to authorized personnel only.
• EST clients MUST verify the EST server's TLS certificate before transmitting the enrollment request, as the TLS channel is the only confidentiality protection for the delivered private key.
• Server-side key generation is generally discouraged when the EST client is capable of generating its own key pair; see for further guidance.
• The PEM response contains the private key in a PRIVATE KEY block with no encryption. EST clients MUST store the key material securely immediately upon receipt (e.g., import it into a hardware security module or an encrypted key store) and MUST NOT write it to unprotected storage.

Response Integrity and Trust Anchor Bootstrapping The ucacert, ucacerts, and ucrl operations return PKI objects over a TLS-protected channel without an additional application-layer signature. EST clients MUST validate received certificates and CRLs against an independently configured trust anchor. When bootstrapping a device that does not yet possess a trust anchor, the initial ucacert or ucacerts exchange is subject to the same considerations as the cacerts bootstrap operation described in . EST clients SHOULD follow the guidance in (Server Authorization) for trust anchor selection, and SHOULD use an Implicit Trust Anchor () only when an Explicit Trust Anchor is not available.

Subject Name and SAN Validation for Re-enrollment The usimplereenroll operation identifies the certificate to be renewed by the subject DN (and optionally SAN) carried in the CSR, consistent with . EST servers MUST ensure that the authenticated requester is authorized to renew the certificate identified by that subject identity. When the id-cmc-changeSubjectName attribute is present in the CSR, the EST server MUST validate that the requested new subject DN and SAN values are within the policy permitted for the authenticated requester and the selected certificate profile.

Capability Discovery Security The ucacaps operation SHOULD NOT require client authentication (consistent with ) and returns its response without any application-layer signature. Therefore, an on-path attacker that can intercept the TLS session could return a manipulated capability list. For example, the attacker could omit userverkeygen to prevent key generation or omit ucrlinfo and ucrl to interfere with CRL checking. EST clients SHOULD treat the ucacaps response as advisory information only. EST clients SHOULD NOT rely on it as a security enforcement mechanism. In particular, a negative ucacaps response (e.g., an absent keyword) MUST NOT cause an EST client to fall back to less secure behavior. EST clients that obtain the ucacaps response via a TLS session in which the server certificate has been validated against an Explicit Trust Anchor MAY treat the response as reliable.

Denial-of-Service Considerations The ucrl operation returns the full CRL, which may be large. EST servers SHOULD implement rate limiting and response size limits to prevent resource exhaustion from concurrent CRL download requests. EST clients SHOULD call ucrlinfo before ucrl to determine whether the locally cached CRL is still current. If the crlnumber, nextupdate, or sha256sum fields indicate no change since the last download, the client SHOULD refrain from issuing a ucrl request. EST clients that cache the CRL locally SHOULD use the nextupdate field from ucrlinfo (or from the cached CRL itself) to determine when to refresh, and SHOULD NOT poll more frequently than necessary.

IANA Considerations This document makes no requests to IANA.

Media Types (Informative) The operations defined in this document use the media types listed in . All types except application/x-pem-file are already registered in the IANA Media Types registry; no new registrations are requested by this document. Media Types Used by Lightweight EST Operations

Media Type	Used by	Registered in
application/pkcs10	Request body for enrollment operations
application/pkix-cert	Response body for ucacert, usimpleenroll, usimplereenroll
application/pkix-crl	Response body for ucrl
application/pkcs7-mime	(existing cacerts/simpleenroll format, for reference)
application/pem-certificate-chain	Response body for ucacerts
application/x-pem-file	Response body for userverkeygen (key + cert)	Unregistered; see note below
text/plain	Response body for ucacaps and ucrlinfo

Note: application/pkix-cert and application/pkix-crl are registered in the IANA Media Types registry (see ). Implementers should consult the IANA registry for authoritative definitions. The media type application/x-pem-file is not registered with IANA, but it is a widely deployed convention for PEM-encoded () cryptographic objects. It predates the IETF media type registration process. No IANA-registered type currently exists for a response body containing both a private key and a certificate in PEM textual encoding. A future revision of this document MAY register an appropriate media type and update the userverkeygen specification accordingly.

References Normative References This second document defines the general structure of the MIME media typing system and defines an initial set of media types. [STANDARDS-TRACK] The protocol conventions described in this document satisfy some of the operational requirements of the Internet Public Key Infrastructure (PKI). This document specifies the conventions for using the File Transfer Protocol (FTP) and the Hypertext Transfer Protocol (HTTP) to obtain certificates and certificate revocation lists (CRLs) from PKI repositories. [STANDARDS-TRACK] This memo represents a republication of PKCS #10 v1.7 from RSA Laboratories' Public-Key Cryptography Standards (PKCS) series, and change control is retained within the PKCS process. The body of this document, except for the security considerations section, is taken directly from the PKCS #9 v2.0 or the PKCS #10 v1.7 document. This memo provides information for the Internet community. This document describes the commonly used base 64, base 32, and base 16 encoding schemes. It also discusses the use of line-feeds in encoded data, use of padding in encoded data, use of non-alphabet characters in encoded data, use of different encoding alphabets, and canonical encodings. [STANDARDS-TRACK] This memo profiles the X.509 v3 certificate and X.509 v2 certificate revocation list (CRL) for use in the Internet. An overview of this approach and model is provided as an introduction. The X.509 v3 certificate format is described in detail, with additional information regarding the format and semantics of Internet name forms. Standard certificate extensions are described and two Internet-specific extensions are defined. A set of required certificate extensions is specified. The X.509 v2 CRL format is described in detail along with standard and Internet-specific extensions. An algorithm for X.509 certification path validation is described. An ASN.1 module and examples are provided in the appendices. [STANDARDS-TRACK] This document describes the Cryptographic Message Syntax (CMS). This syntax is used to digitally sign, digest, authenticate, or encrypt arbitrary message content. [STANDARDS-TRACK] This document defines Secure/Multipurpose Internet Mail Extensions (S/MIME) version 4.0. S/MIME provides a consistent way to send and receive secure MIME data. Digital signatures provide authentication, message integrity, and non-repudiation with proof of origin. Encryption provides data confidentiality. Compression can be used to reduce data size. This document obsoletes RFC 5751. This document updates RFC 7030: Enrollment over Secure Transport to resolve some errata that were reported and that have proven to cause interoperability issues when RFC 7030 was extended. This document deprecates the specification of "Content-Transfer-Encoding" headers for Enrollment over Secure Transport (EST) endpoints. This document fixes some syntactical errors in ASN.1 that were present. This document defines the syntax for private-key information and a content type for it. Private-key information includes a private key for a specified public-key algorithm and a set of attributes. The Cryptographic Message Syntax (CMS), as defined in RFC 5652, can be used to digitally sign, digest, authenticate, or encrypt the asymmetric key format content type. This document obsoletes RFC 5208. [STANDARDS-TRACK] This document profiles certificate enrollment for clients using Certificate Management over CMS (CMC) messages over a secure transport. This profile, called Enrollment over Secure Transport (EST), describes a simple, yet functional, certificate management protocol targeting Public Key Infrastructure (PKI) clients that need to acquire client certificates and associated Certification Authority (CA) certificates. It also supports client-generated public/private key pairs as well as key pairs generated by the CA. This document describes and discusses the textual encodings of the Public-Key Infrastructure X.509 (PKIX), Public-Key Cryptography Standards (PKCS), and Cryptographic Message Syntax (CMS). The textual encodings are well-known, are implemented by several applications and libraries, and are widely deployed. This document articulates the de facto rules by which existing implementations operate and defines them so that future implementations can interoperate. Public Key Infrastructure using X.509 (PKIX) certificates are used for a number of purposes, the most significant of which is the authentication of domain names. Thus, certification authorities (CAs) in the Web PKI are trusted to verify that an applicant for a certificate legitimately represents the domain name(s) in the certificate. As of this writing, this verification is done through a collection of ad hoc mechanisms. This document describes a protocol that a CA and an applicant can use to automate the process of verification and certificate issuance. The protocol also provides facilities for other certificate management functions, such as certificate revocation. This document defines a placeholder X.509 signature algorithm that may be used in contexts where the consumer of the certificate is not expected to verify the signature. As part of this, it updates RFC 5280. In many standards track documents several words are used to signify the requirements in the specification. These words are often capitalized. This document defines these words as they should be interpreted in IETF documents. This document specifies an Internet Best Current Practices for the Internet Community, and requests discussion and suggestions for improvements. RFC 2119 specifies common key words that may be used in protocol specifications. This document aims to reduce the ambiguity by clarifying that only UPPERCASE usage of the key words have the defined special meanings. Informative References The Internet Protocol Suite is increasingly used on small devices with severe constraints on power, memory, and processing resources, creating constrained-node networks. This document provides a number of basic terms that have been useful in the standardization work for constrained-node networks. A common design pattern in Internet of Things (IoT) deployments is the use of a constrained device that collects data via sensors or controls actuators for use in home automation, industrial control systems, smart cities, and other IoT deployments. This document defines a Transport Layer Security (TLS) and Datagram Transport Layer Security (DTLS) 1.2 profile that offers communications security for this data exchange thereby preventing eavesdropping, tampering, and message forgery. The lack of communication security is a common vulnerability in IoT products that can easily be solved by using these well-researched and widely deployed Internet security protocols. The EST (Enrollment over Secure Transport) protocol defines the Well-Known URI (Uniform Resource Identifier) -- /.well-known/est -- along with a number of other path components that clients use for PKI (Public Key Infrastructure) services, namely certificate enrollment (e.g., /simpleenroll). This document defines a number of other PKI services as additional path components -- specifically, firmware and trust anchors as well as symmetric, asymmetric, and encrypted keys. This document also specifies the PAL (Package Availability List), which is an XML (Extensible Markup Language) file or JSON (JavaScript Object Notation) object that clients use to retrieve packages available and authorized for them. This document extends the EST server path components to provide these additional services. Enrollment over Secure Transport (EST) is used as a certificate provisioning protocol over HTTPS. Low-resource devices often use the lightweight Constrained Application Protocol (CoAP) for message exchanges. This document defines how to transport EST payloads over secure CoAP (EST-coaps), which allows constrained devices to use existing EST functionality for provisioning certificates. This document updates RFC 7030, "Enrollment over Secure Transport" (EST), clarifying how the Certificate Signing Request (CSR) Attributes Response can be used by an EST server to specify both CSR attribute Object Identifiers (OIDs) and CSR attribute values, particularly X.509 extension values, that the server expects the client to include in a subsequent CSR request. RFC 9148 is derived from RFC 7030 and is also updated. RFC 7030 is ambiguous in its specification of the CSR Attributes Response. This has resulted in implementation challenges and implementor confusion because there was no universal understanding of what was specified. This document clarifies the encoding rules. This document also provides a new straightforward approach: using a template for CSR contents that may be partially filled in by the server. This also allows an EST server to specify a subject Distinguished Name (DN).

Message Flow Diagrams This appendix illustrates the HTTP message flows for each operation defined in this document. All exchanges occur within a TLS session; the TLS handshake is not shown. For DER-carrying operations, the examples show the base64-encoded form required by this specification.

ucacaps

ucacaps message flow /ucacaps | |--------------------------------------->| | | | HTTP/1.1 200 OK | | Content-Type: text/plain | | | | cacerts | | simpleenroll | | simplereenroll | | serverkeygen | | ucacert | | ucacerts | | ucrl | | ucrlinfo | | usimpleenroll | | usimplereenroll | | userverkeygen | |<---------------------------------------| | | ]]>

ucacert

ucacert message flow /ucacert | |--------------------------------------->| | | | HTTP/1.1 200 OK | | Content-Type: application/pkix-cert | | | | | |<---------------------------------------| | | ]]>

ucacerts

ucacerts message flow /ucacerts | |--------------------------------------->| | | | HTTP/1.1 200 OK | | Content-Type: | | application/pem-certificate-chain | | | | | | [ PEM-encoded intermediate | | CA certificates ] | | [ ] | |<---------------------------------------| | | ]]>

ucrlinfo

ucrlinfo message flow /ucrlinfo | |--------------------------------------->| | | | HTTP/1.1 200 OK | | Content-Type: text/plain | | | | sha256sum=fcWyNz...26oF0= | | issuer=MIHxMQswCQYDVQQGEw... | | thisupdate=1735732800 | | nextupdate=1736337600 | | crlnumber=42 | |<---------------------------------------| | | ]]>

ucrl

ucrl message flow /ucrl | |--------------------------------------->| | | | HTTP/1.1 200 OK | | Content-Type: application/pkix-crl | | | | | |<---------------------------------------| | | ]]>

usimpleenroll

usimpleenroll message flow /usimpleenroll | | Content-Type: application/pkcs10 | | | | | |--------------------------------------->| | | Verify PoP, | | Issue certificate | | | HTTP/1.1 200 OK | | Content-Type: application/pkix-cert | | | | | |<---------------------------------------| | | ]]>

usimplereenroll

usimplereenroll message flow /usimplereenroll | | Content-Type: application/pkcs10 | | | | | | (subject = cert to renew; | | optionally includes | | id-cmc-changeSubjectName) | |--------------------------------------->| | | Verify PoP, | | Renew certificate | | | HTTP/1.1 200 OK | | Content-Type: application/pkix-cert | | | | | |<---------------------------------------| | | ]]>

userverkeygen

userverkeygen message flow / | | userverkeygen | | Content-Type: application/pkcs10 | | | | | | (no SubjectPublicKeyInfo needed) | |--------------------------------------->| | | Generate key pair, | | Issue certificate, | | Delete key from | | server | HTTP/1.1 200 OK | | Content-Type: application/x-pem-file | | | | | | | |<---------------------------------------| | (key no longer on EST server) | | | ]]>

Comparison with RFC 7030 Operations The following table summarizes how each new operation relates to its RFC 7030 counterpart, the changes in response format, and the corresponding RFC 7030 section (see ). Comparison of New Operations with RFC 7030 Counterparts

New Operation	RFC 7030 Operation	Auth	New Content-Type	New Format
ucacaps	(none)	No	text/plain	Keyword list
ucacert	(none)	No	application/pkix-cert	Single DER cert
ucacerts	cacerts ()	No	application/pem-certificate-chain	PEM cert chain
ucrlinfo	(none)	No	text/plain	CRL metadata
ucrl	(none)	No	application/pkix-crl	DER CRL
usimpleenroll	simpleenroll ()	Yes	application/pkix-cert	DER cert
usimplereenroll	simplereenroll ()	Yes	application/pkix-cert	DER cert
userverkeygen	serverkeygen ()	Yes	application/x-pem-file	PEM: PKCS#8 + certificate

Key differences from RFC 7030 equivalents:

• New single-certificate retrieval operation: ucacert returns the issuing CA certificate as the Base64 encoding of a single DER-encoded X.509 certificate, with no certificate chain and no CMS wrapper. has no equivalent. cacerts always returns the full chain in CMS format.
• No CMS wrapper: The certificate- and CRL-returning operations deliver their payloads without CMS encapsulation. EST clients therefore do not need a CMS library to parse those responses.
• PEM instead of multipart: userverkeygen returns the private key and certificate in a single PEM file (application/x-pem-file) rather than a multipart/mixed MIME response (). EST clients do not need a MIME multipart parser or a CMS library.
• New capability discovery operation: ucacaps enables EST clients to discover which operations the EST server supports. has no equivalent operation.
• New CRL operations: ucrlinfo provides lightweight CRL metadata (number, validity window, issuer, and SHA-256 fingerprint) without downloading the full CRL body, and ucrl extends EST with in-band CRL retrieval when the full CRL is needed. does not define CRL distribution or CRL status operations; CRL retrieval is normally handled via the CDP extension in issued certificates.

Comparison with RFC 8295 defines EST extensions for package distribution, including the crls operation for distributing one or more CRLs (and ARLs). This document addresses a narrower use case for the latest CRL of the selected CA. The main differences are summarized in . Comparison with RFC 8295

Topic	RFC 8295 crls	This Document
Object scope	Returns one or more CRLs in a CRL package and may also distribute ARLs.	ucrl returns a single current CRL; ucrlinfo returns metadata for that current CRL.
Metadata-only check	Not defined.	ucrlinfo allows freshness checks without downloading the CRL body.
Response format	Follows the RFC 7030 CMS-based response model for CRL packages.	Uses Base64-encoded DER for ucrl and plain text for ucrlinfo, without CMS.
Intended use	General EST extension for CRL/ARL distribution.	Lightweight retrieval of the current CRL and its metadata.

Comparison with RFC 9148 (EST-coaps) RFC 9148 defines EST-coaps: a profile and transport mapping that carries EST messages over secure CoAP instead of HTTPS. It changes the transfer substrate by using CoAP, DTLS, short CoAP resource paths, CoAP resource discovery, CoAP Block-Wise Transfer, and CoAP Content-Format identifiers. RFC 9148 is important prior art for reducing EST payload overhead. In particular, it defines Content-Format 287 for application/pkix-cert, allowing a client to request a single DER-encoded certificate rather than a CMS certs-only object for certificate-returning EST-coaps functions. RFC 9148 performs this selection with CoAP content negotiation, using the Accept Option, rather than by defining separate resources for each response format. This document addresses a related but different problem. It keeps the HTTPS-based EST model of and defines additional EST operations with simpler response payloads. The goal is to reduce application-layer parsing requirements for EST clients that still use HTTP/TLS and to add operations that are not present in RFC 7030 or RFC 9148. The main differences are summarized in . Comparison with RFC 9148

Topic	RFC 9148	This Document
Transport	Defines EST over CoAP secured with DTLS.	Uses the existing EST HTTPS/TLS transport from RFC 7030.
URI design	Maps EST operations to short CoAP paths such as /crts, /sen, /sren, /skg, /skc, and /att.	Adds HTTP EST operations under the RFC 7030 /.well-known/est/ path structure.
Discovery	Uses CoRE Link Format resource discovery for EST-coaps resources.	Defines ucacaps as an EST operation that returns supported operation keywords.
Response selection	Uses CoAP content negotiation; a client uses the Accept Option to request an available Content-Format.	Uses distinct HTTP EST resources for the unencapsulated operations, with ucacaps for capability discovery.
Certificate response format	Supports PKCS#7 certs-only Content-Format 281 and defines Content-Format 287 (application/pkix-cert) for a single non-CMS certificate response.	Defines unencapsulated HTTP operations whose successful responses use base64-encoded DER certificates or PEM certificate chains without CMS.
CA certificate retrieval	Maps the EST cacerts function to /crts; Content-Format 287 can carry a single certificate when negotiated.	Adds ucacert for a single issuing CA certificate and ucacerts for a PEM certificate chain.
Enrollment responses	Maps simpleenroll and simplereenroll to CoAP and permits single-certificate responses when Content-Format 287 is negotiated.	Defines usimpleenroll and usimplereenroll as HTTP/TLS operations that directly return a DER certificate.
Server-side key generation	Defines CoAP resources for server-side key generation and uses application/multipart-core for key-and-certificate responses.	Defines userverkeygen, returning a PEM-encoded private key and certificate in a single response body.
CRL support	Does not define EST-coaps CRL metadata or CRL retrieval operations.	Defines ucrlinfo and ucrl for CRL freshness checks and CRL retrieval.

RFC 9148 is therefore complementary to this document rather than a substitute for it. It already solves part of the same problem for EST-coaps by defining a non-CMS single-certificate format and negotiating it with Accept. That mechanism may also inform implementations that expose the same semantics over transports other than CoAP. However, RFC 9148 does not update the HTTPS resource model of RFC 7030, does not define the ucacaps, ucacert, ucacerts, ucrlinfo, ucrl, usimpleenroll, usimplereenroll, or userverkeygen HTTP operations, and does not define EST-based CRL metadata or CRL retrieval. An implementation can support both specifications. For example, a server could offer EST-coaps resources for CoAP clients while also offering the operations defined in this document for HTTPS EST clients. Another implementation might choose to apply RFC 9148-style content-negotiation semantics across multiple transports. The interfaces can share the same CA, RA policy, authentication checks, and certificate issuance logic, but their standardized protocol bindings and payload formats are distinct.

Acknowledgements The authors want to thank Michael Richardson for reviewing and commenting on intermediate versions of the draft.

Implementation Notes

• Editor's Note: This section is for author reference only. It MUST be removed before RFC publication.

A reference implementation of the operations described in this document is available in the gateway module of the XiPKI open-source PKI project (https://github.com/xipki/xipki). The reference implementation supports HTTP Basic authentication and TLS client certificate authentication, consistent with and . Its path routing also supports both the two-segment <alias>/<operation> form and the three-segment <ca-name>/<cert-profile>/<operation> form described in .