EST Lightweight Operations

3.1. Base64 Transfer

[RFC8951] deprecates use of Content-Transfer-Encoding for EST. The new operations defined in this document follow that guidance.¶

Consistent with [RFC8951], Section 3, the operations defined in this document use base64 encoding for DER payloads in both requests and responses. For operations that return DER payloads (application/pkix-cert, application/pkix-crl), the response body MUST be the base64 encoding ([RFC4648], Section 4) of the DER object. This applies even though [RFC2585] defines these media types as carrying binary DER, so that all EST payloads share a single transfer format.¶

For POST operations that submit a PKCS#10 CSR, the request body MUST be the base64 encoding ([RFC4648], Section 4) of the DER-encoded PKCS#10 object.¶

Senders MUST NOT include a Content-Transfer-Encoding header. Receivers MUST ignore any Content-Transfer-Encoding header that is present. As specified in [RFC8951], Section 3.1, receivers SHOULD tolerate white space (CR, LF, space, and tab) in base64-encoded bodies; senders are not required to insert any white space.¶

The ucacaps, ucrlinfo, ucacerts, and userverkeygen operations already return textual payloads and therefore do not require any additional transfer-encoding mechanism.¶

3.2. Line-Oriented Text Responses

The ucacaps and ucrlinfo responses use the following line format:¶

• The body MUST consist of US-ASCII characters only. EST servers SHOULD send the Content-Type text/plain; charset=us-ascii.¶

• Each line MUST be terminated by <CR><LF> or <LF>. EST clients MUST accept a final line that is not terminated.¶

• EST servers MUST NOT send leading or trailing white space on a line. EST clients MUST ignore leading and trailing white space (space and tab) on each line, and MUST ignore empty lines.¶

3.3. HTTP Caching

The ucacert, ucacerts, and ucrl retrieval operations support HTTP caching [RFC9111]. EST servers SHOULD include caching metadata in successful (HTTP 200) responses to these operations so that clients and HTTP intermediaries can reuse them. EST clients SHOULD cache such responses locally and refresh them according to the advertised freshness information. Successful responses for these operations MUST NOT include Pragma: no-cache, Cache-Control: no-cache, or Cache-Control: no-store.¶

4.1. ucacaps

GET /.well-known/est/<label>/ucacaps

cacerts
simpleenroll
simplereenroll
serverkeygen
crls
ucacert
ucacerts
ucrlinfo
ucrl
usimpleenroll
usimplereenroll
userverkeygen

5.1. 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.¶

GET /.well-known/est/<label>/ucacert

5.2. ucacerts

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

GET /.well-known/est/<label>/ucacerts

6.1. Selecting the Current CRL

GET /.well-known/est/<label>/ucrlinfo?dp=<dpname>
GET /.well-known/est/<label>/ucrl?dp=<dpname>

6.2. 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.¶

GET /.well-known/est/<label>/ucrlinfo
GET /.well-known/est/<label>/ucrlinfo?dp=<dpname>

sha256sum=fcWyNz1VMfF2wj4/ozla0+Aqj5s0c4fHkkjY8d26oF0=
issuer=MIHxMQswCQYDVQQGEwJERTEP...
thisupdate=1735732800
nextupdate=1736337600
crlnumber=42

6.3. 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.¶

GET /.well-known/est/<label>/ucrl
GET /.well-known/est/<label>/ucrl?dp=<dpname>

7.1. Client Authentication

The enrollment operations defined in this section (usimpleenroll, usimplereenroll, and userverkeygen) require client authentication. The client authentication requirements are unchanged from [RFC7030]. EST clients and EST servers MUST follow [RFC7030], Section 3.2.3 for HTTP-based client authentication and [RFC7030], Section 3.3.2 for certificate-based client authentication at the TLS layer, as applicable to the authentication method in use.¶

7.2. Common Processing Rules

Unless stated otherwise, the enrollment operations defined in this section follow the processing rules of the corresponding operations in [RFC7030]. In particular:¶

• Linking identity and POP: [RFC7030], Section 3.5 applies to usimpleenroll and usimplereenroll. EST clients SHOULD include the tls-unique value in the challenge-password attribute of the CSR, and if it is present, the EST server MUST verify it. The EST server MAY reject requests without this information, as indicated by server policy. This mechanism does not apply to userverkeygen, whose CSR carries no PoP signature (Section 7.5.1).¶

• Deferred processing: As specified in [RFC7030], Section 4.2.3, an EST server MAY respond with HTTP 202 (Accepted) when the request has been accepted for processing but the certificate is not yet available, for example because manual approval is required. The response MUST include a Retry-After header field ([RFC9110], Section 10.2.3). The EST client MUST wait at least the specified time before repeating the same request, and the EST server is responsible for maintaining the state needed to recognize the repeated request. If the CSR includes tls-unique information and the client repeats the request in a new TLS session, the CSR has to be recreated as described in [RFC7030], Section 4.2.3.¶

• Error responses: As specified in [RFC7030], Section 4.2.3, the EST server MUST answer with a suitable 4xx or 5xx HTTP status code when a problem occurs. Because the operations in this document are intended for EST clients that do not implement CMS, the EST server SHOULD NOT convey errors as a CMC Simple PKI Response. Instead, the response body SHOULD be a human-readable error message with the Content-Type text/plain, describing why the request was rejected.¶

7.3. usimpleenroll

The usimpleenroll operation requests a new certificate from the EST server ([RFC7030], Section 4.2.1) and returns the issued certificate as a DER-encoded X.509 certificate.¶

POST /.well-known/est/<label>/usimpleenroll
Content-Type: application/pkcs10

<Base64-encoded DER CSR>

7.4. usimplereenroll

The usimplereenroll operation renews or rekeys an existing certificate ([RFC7030], Section 4.2.2) and returns the renewed certificate as a DER-encoded X.509 certificate.¶

POST /.well-known/est/<label>/usimplereenroll
Content-Type: application/pkcs10

<Base64-encoded DER CSR>

7.5. userverkeygen

The userverkeygen operation requests server-side key generation and returns the generated private key and certificate ([RFC7030], Section 4.4).¶

POST /.well-known/est/<label>/userverkeygen
Content-Type: application/pkcs10

<Base64-encoded DER CSR>

id-alg-empty-publickey OBJECT IDENTIFIER ::= {
    iso(1) identified-organization(3) dod(6) internet(1)
    security(5) mechanisms(5) pkix(7) algorithms(6) TBD1 }

-----BEGIN PRIVATE KEY-----
<Base64-encoded PKCS#8 private key>
-----END PRIVATE KEY-----
-----BEGIN CERTIFICATE-----
<Base64-encoded issued certificate>
-----END CERTIFICATE-----

8.1. Transport Security

All operations defined in this document MUST be carried out over HTTPS (HTTP over TLS) as required by [RFC7030], Section 3. 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 MUST reject server certificates that cannot be validated, except during trust anchor bootstrapping as described in Section 8.5.¶

Implementers SHOULD consult [RFC7925] for guidance on TLS version, cipher suite selection, and certificate profiles when those recommendations are applicable to the deployment.¶

8.2. Client Authentication

The ucacaps, ucacert, ucacerts, ucrlinfo, and ucrl retrieval operations follow the same authentication policy as the cacerts operation defined in [RFC7030], Section 4.1.2: 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 [RFC5280].¶

Enrollment operations (usimpleenroll, usimplereenroll, userverkeygen) MUST require client authentication as specified in Section 7.1.¶

When HTTP Basic authentication is used, the considerations in [RFC7030], Section 3.2.3 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 [RFC7030], Section 3.3.2 apply.¶

8.3. Proof of Possession

usimpleenroll and usimplereenroll MUST verify the PoP signature in the PKCS#10 CSR before issuing a certificate, as required by [RFC7030], Section 3.4. 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 [RFC7030], Section 4.4.1). The authenticity of the request is therefore established solely by client authentication (Section 8.2). EST servers MUST enforce client authentication at least as strongly for userverkeygen as for the other enrollment operations.¶

8.4. 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 [RFC7030], Section 4.4. 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 [RFC7030], Section 6 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.¶

8.5. 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. Except during the bootstrapping case described below, 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 [RFC7030], Section 4.1.1. In particular, certificates obtained in this way MUST NOT be accepted as trust anchors until they have been verified out-of-band as described there. EST clients SHOULD follow the guidance in [RFC7030], Section 3.6 (Server Authorization) for trust anchor selection, and SHOULD use an Implicit Trust Anchor ([RFC7030], Section 3.6.2) only when an Explicit Trust Anchor is not available.¶

The ucacert operation returns only the issuing CA certificate. An EST client that relies only on ucacert can build a certification path to its trust anchor only if it already holds, or can otherwise obtain, any intermediate CA certificates between the issuing CA and that trust anchor. EST clients that need intermediate CA certificates SHOULD use ucacerts (Section 5.2) or cacerts ([RFC7030], Section 4.1).¶

8.6. 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 [RFC7030], Section 4.2.2. 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 ([RFC6402], Section 2.8) 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.¶

8.7. Capability Discovery Security

The ucacaps operation SHOULD NOT require client authentication (consistent with [RFC7030], Section 4.1.2) and returns its response without any application-layer signature. Its integrity therefore depends entirely on TLS server authentication. When the EST client has authenticated the EST server against an Explicit Trust Anchor, an on-path attacker cannot modify the response. However, when the client has not yet authenticated the server in this way, for example during bootstrapping with an Implicit Trust Anchor or with no trust anchor at all (Section 8.5), an on-path attacker 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.¶

8.8. 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. EST servers SHOULD limit the accepted length of the dp query parameter (Section 6.1.1) and SHOULD reject longer values with HTTP 414 (URI Too Long) or 400 (Bad Request).¶

9.1. Media Type Registration

IANA is requested to register the following media type in the "Media Types" registry, in the manner described in [RFC6838].¶

Type name:

application¶

Subtype name:

pem-key-certificate-chain¶

Required parameters:

None¶

Optional parameters:

None¶

Encoding considerations:

7bit. The body consists of US-ASCII characters only.¶

Security considerations:

The body contains an unencrypted private key. It MUST be transmitted only over a channel that provides confidentiality and integrity protection, such as TLS, and MUST NOT be stored by HTTP caches or intermediaries. Recipients MUST store the private key securely immediately upon receipt. The certificates carry no confidentiality requirements, but recipients MUST validate them before use. See Section 8.4 of RFC XXXX.¶

Interoperability considerations:

The body uses the strict PEM textual encoding defined in [RFC7468], Section 3. The certificate part follows the conventions of application/pem-certificate-chain ([RFC8555], Section 9.1).¶

Published specification:

Section 7.5.4 of RFC XXXX¶

Applications that use this media type:

EST clients and servers implementing the userverkeygen operation, and other applications that deliver a private key together with its certificate chain.¶

Fragment identifier considerations:

None¶

Additional information:

Deprecated alias names for this type: None¶

Magic number(s): None¶

File extension(s): .pem¶

Macintosh file type code(s): None¶

Person & email address to contact for further information:

Lijun Liao lijun.liao@nio.io¶

Intended usage:

COMMON¶

Restrictions on usage:

None¶

Author:

Lijun Liao lijun.liao@nio.io¶

Change controller:

IETF¶

• RFC Editor's Note: Please replace "RFC XXXX" with the RFC number assigned to this document.¶

9.2. SMI Security for PKIX Algorithms

IANA is requested to assign the following object identifier in the "SMI Security for PKIX Algorithms" registry (1.3.6.1.5.5.7.6):¶

9.3. Media Types Used (Informative)

The operations defined in this document use the media types listed in Table 7. All of them except application/pem-key-certificate-chain, which is registered by this document, are already registered in the IANA Media Types registry.¶

10.1. Normative References

[RFC2046]

Freed, N. and N. Borenstein, "Multipurpose Internet Mail Extensions (MIME) Part Two: Media Types", RFC 2046, DOI 10.17487/RFC2046, November 1996, <https://www.rfc-editor.org/rfc/rfc2046>.

[RFC2119]

Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, DOI 10.17487/RFC2119, March 1997, <https://www.rfc-editor.org/rfc/rfc2119>.

[RFC2585]

Housley, R. and P. Hoffman, "Internet X.509 Public Key Infrastructure Operational Protocols: FTP and HTTP", RFC 2585, DOI 10.17487/RFC2585, May 1999, <https://www.rfc-editor.org/rfc/rfc2585>.

[RFC2986]

Nystrom, M. and B. Kaliski, "PKCS #10: Certification Request Syntax Specification Version 1.7", RFC 2986, DOI 10.17487/RFC2986, November 2000, <https://www.rfc-editor.org/rfc/rfc2986>.

[RFC4648]

Josefsson, S., "The Base16, Base32, and Base64 Data Encodings", RFC 4648, DOI 10.17487/RFC4648, October 2006, <https://www.rfc-editor.org/rfc/rfc4648>.

[RFC5280]

Cooper, D., Santesson, S., Farrell, S., Boeyen, S., Housley, R., and W. Polk, "Internet X.509 Public Key Infrastructure Certificate and Certificate Revocation List (CRL) Profile", RFC 5280, DOI 10.17487/RFC5280, May 2008, <https://www.rfc-editor.org/rfc/rfc5280>.

[RFC5652]

Housley, R., "Cryptographic Message Syntax (CMS)", STD 70, RFC 5652, DOI 10.17487/RFC5652, September 2009, <https://www.rfc-editor.org/rfc/rfc5652>.

[RFC5958]

Turner, S., "Asymmetric Key Packages", RFC 5958, DOI 10.17487/RFC5958, August 2010, <https://www.rfc-editor.org/rfc/rfc5958>.

[RFC5967]

Turner, S., "The application/pkcs10 Media Type", RFC 5967, DOI 10.17487/RFC5967, August 2010, <https://www.rfc-editor.org/rfc/rfc5967>.

[RFC6402]

Schaad, J., "Certificate Management over CMS (CMC) Updates", RFC 6402, DOI 10.17487/RFC6402, November 2011, <https://www.rfc-editor.org/rfc/rfc6402>.

[RFC7030]

Pritikin, M., Ed., Yee, P., Ed., and D. Harkins, Ed., "Enrollment over Secure Transport", RFC 7030, DOI 10.17487/RFC7030, October 2013, <https://www.rfc-editor.org/rfc/rfc7030>.

[RFC7468]

Josefsson, S. and S. Leonard, "Textual Encodings of PKIX, PKCS, and CMS Structures", RFC 7468, DOI 10.17487/RFC7468, April 2015, <https://www.rfc-editor.org/rfc/rfc7468>.

[RFC8174]

Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC 2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174, May 2017, <https://www.rfc-editor.org/rfc/rfc8174>.

[RFC8295]

Turner, S., "EST (Enrollment over Secure Transport) Extensions", RFC 8295, DOI 10.17487/RFC8295, January 2018, <https://www.rfc-editor.org/rfc/rfc8295>.

[RFC8551]

Schaad, J., Ramsdell, B., and S. Turner, "Secure/Multipurpose Internet Mail Extensions (S/MIME) Version 4.0 Message Specification", RFC 8551, DOI 10.17487/RFC8551, April 2019, <https://www.rfc-editor.org/rfc/rfc8551>.

[RFC8555]

Barnes, R., Hoffman-Andrews, J., McCarney, D., and J. Kasten, "Automatic Certificate Management Environment (ACME)", RFC 8555, DOI 10.17487/RFC8555, March 2019, <https://www.rfc-editor.org/rfc/rfc8555>.

[RFC8951]

Richardson, M., Werner, T., and W. Pan, "Clarification of Enrollment over Secure Transport (EST): Transfer Encodings and ASN.1", RFC 8951, DOI 10.17487/RFC8951, November 2020, <https://www.rfc-editor.org/rfc/rfc8951>.

[RFC9110]

Fielding, R., Ed., Nottingham, M., Ed., and J. Reschke, Ed., "HTTP Semantics", STD 97, RFC 9110, DOI 10.17487/RFC9110, June 2022, <https://www.rfc-editor.org/rfc/rfc9110>.

[RFC9111]

Fielding, R., Ed., Nottingham, M., Ed., and J. Reschke, Ed., "HTTP Caching", STD 98, RFC 9111, DOI 10.17487/RFC9111, June 2022, <https://www.rfc-editor.org/rfc/rfc9111>.

[RFC9810]

Brockhaus, H., von Oheimb, D., Ounsworth, M., and J. Gray, "Internet X.509 Public Key Infrastructure -- Certificate Management Protocol (CMP)", RFC 9810, DOI 10.17487/RFC9810, July 2025, <https://www.rfc-editor.org/rfc/rfc9810>.

[RFC9908]

Richardson, M., Ed., Friel, O., von Oheimb, D., and D. Harkins, "Clarification and Enhancement of the CSR Attributes Definition in RFC 7030", RFC 9908, DOI 10.17487/RFC9908, January 2026, <https://www.rfc-editor.org/rfc/rfc9908>.

[RFC9925]

Benjamin, D., "Unsigned X.509 Certificates", RFC 9925, DOI 10.17487/RFC9925, February 2026, <https://www.rfc-editor.org/rfc/rfc9925>.

10.2. Informative References

[RFC6838]

Freed, N., Klensin, J., and T. Hansen, "Media Type Specifications and Registration Procedures", BCP 13, RFC 6838, DOI 10.17487/RFC6838, January 2013, <https://www.rfc-editor.org/rfc/rfc6838>.

[RFC7228]

Bormann, C., Ersue, M., and A. Keranen, "Terminology for Constrained-Node Networks", RFC 7228, DOI 10.17487/RFC7228, May 2014, <https://www.rfc-editor.org/rfc/rfc7228>.

[RFC7925]

Tschofenig, H., Ed. and T. Fossati, "Transport Layer Security (TLS) / Datagram Transport Layer Security (DTLS) Profiles for the Internet of Things", RFC 7925, DOI 10.17487/RFC7925, July 2016, <https://www.rfc-editor.org/rfc/rfc7925>.

[RFC7942]

Sheffer, Y. and A. Farrel, "Improving Awareness of Running Code: The Implementation Status Section", BCP 205, RFC 7942, DOI 10.17487/RFC7942, July 2016, <https://www.rfc-editor.org/rfc/rfc7942>.

[RFC9148]

van der Stok, P., Kampanakis, P., Richardson, M., and S. Raza, "EST-coaps: Enrollment over Secure Transport with the Secure Constrained Application Protocol", RFC 9148, DOI 10.17487/RFC9148, April 2022, <https://www.rfc-editor.org/rfc/rfc9148>.

A.1. ucacaps

EST Client                             EST Server
   |                                        |
   |  GET /.well-known/est/<label>/ucacaps  |
   |--------------------------------------->|
   |                                        |
   |  HTTP/1.1 200 OK                       |
   |  Content-Type: text/plain              |
   |                                        |
   |  cacerts                               |
   |  simpleenroll                          |
   |  simplereenroll                        |
   |  serverkeygen                          |
   |  ucacert                               |
   |  ucacerts                              |
   |  ucrl                                  |
   |  ucrlinfo                              |
   |  usimpleenroll                         |
   |  usimplereenroll                       |
   |  userverkeygen                         |
   |<---------------------------------------|
   |                                        |

A.2. ucacert

EST Client                             EST Server
   |                                        |
   |  GET /.well-known/est/<label>/ucacert  |
   |--------------------------------------->|
   |                                        |
   |  HTTP/1.1 200 OK                       |
   |  Content-Type: application/pkix-cert   |
   |                                        |
   |  <Base64 DER CA certificate>           |
   |<---------------------------------------|
   |                                        |

A.3. ucacerts

EST Client                             EST Server
   |                                        |
   |  GET /.well-known/est/<label>/ucacerts |
   |--------------------------------------->|
   |                                        |
   |  HTTP/1.1 200 OK                       |
   |  Content-Type:                         |
   |    application/pem-certificate-chain   |
   |                                        |
   |  <PEM-encoded issuing CA certificate>  |
   |  [ <PEM-encoded intermediate           |
   |      CA certificates> ]                |
   |  <PEM-encoded root CA certificate>     |
   |  [ <Root CA Key Update certificates> ] |
   |<---------------------------------------|
   |                                        |

A.4. ucrlinfo

EST Client                             EST Server
   |                                        |
   |  GET /.well-known/est/<label>/ucrlinfo |
   |--------------------------------------->|
   |                                        |
   |  HTTP/1.1 200 OK                       |
   |  Content-Type: text/plain              |
   |                                        |
   |  sha256sum=fcWyNz...26oF0=             |
   |  issuer=MIHxMQswCQYDVQQGEw...          |
   |  thisupdate=1735732800                 |
   |  nextupdate=1736337600                 |
   |  crlnumber=42                          |
   |<---------------------------------------|
   |                                        |

A.5. ucrl

EST Client                             EST Server
   |                                        |
   |  GET /.well-known/est/<label>/ucrl     |
   |--------------------------------------->|
   |                                        |
   |  HTTP/1.1 200 OK                       |
   |  Content-Type: application/pkix-crl    |
   |                                        |
   |  <Base64 DER CRL>                      |
   |<---------------------------------------|
   |                                        |

A.6. usimpleenroll

EST Client                             EST Server
   |                                        |
   |  [HTTP Basic auth header,              |
   |   or TLS client certificate]           |
   |                                        |
   |  POST /.well-known/est/<label>/        |
   |       usimpleenroll                    |
   |  Content-Type: application/pkcs10      |
   |                                        |
   |  <Base64 PKCS#10 CSR>                  |
   |--------------------------------------->|
   |                                        |  Verify PoP,
   |                                        |  Issue certificate
   |                                        |
   |  HTTP/1.1 200 OK                       |
   |  Content-Type: application/pkix-cert   |
   |                                        |
   |  <Base64 DER certificate>              |
   |<---------------------------------------|
   |                                        |

A.7. usimplereenroll

EST Client                             EST Server
   |                                        |
   |  [HTTP Basic auth header,              |
   |   or TLS client certificate]           |
   |                                        |
   |  POST /.well-known/est/<label>/        |
   |       usimplereenroll                  |
   |  Content-Type: application/pkcs10      |
   |                                        |
   |  <Base64 PKCS#10 CSR>                  |
   |  (subject = cert to renew;             |
   |   optionally includes                  |
   |   id-cmc-changeSubjectName)            |
   |--------------------------------------->|
   |                                        |  Verify PoP,
   |                                        |  Renew certificate
   |                                        |
   |  HTTP/1.1 200 OK                       |
   |  Content-Type: application/pkix-cert   |
   |                                        |
   |  <Base64 DER certificate>              |
   |<---------------------------------------|
   |                                        |

A.8. userverkeygen

EST Client                             EST Server
   |                                        |
   |  [HTTP Basic auth header,              |
   |   or TLS client certificate]           |
   |                                        |
   |  POST /.well-known/est/<label>/        |
   |       userverkeygen                    |
   |  Content-Type: application/pkcs10      |
   |                                        |
   |  <Base64 PKCS#10 CSR>                  |
   |  (empty-publickey, id-alg-unsigned)    |
   |--------------------------------------->|
   |                                        |  Generate key pair,
   |                                        |  Issue certificate,
   |                                        |
   |  HTTP/1.1 200 OK                       |
   |  Content-Type:                          |
   |  application/pem-key-certificate-chain |
   |                                        |
   |  <PEM-encoded PKCS#8 private key>      |
   |  <PEM-encoded issued certificate>      |
   |<---------------------------------------|
   |                                        |  Delete key, unless
   |                                        |  retained by policy
   |                                        |

Changes since -01

• Removed "Updates: 7030"; <label> is a single path segment as in RFC 7030.¶

• userverkeygen: registered the media type application/pem-key-certificate-chain to replace application/x-pem-file; defined id-alg-empty-publickey for the CSR; rejected requests for additional private key encryption.¶

• ucacert / ucacerts: specified behavior during CA key rollover; the ucacerts chain includes the root CA certificate, followed by the root CA key update certificates.¶

• ucrlinfo / ucrl: excluded delta CRLs; added the dp parameter for partitioned CRLs; specified handling of indirect CRLs; explained the relationship to HTTP conditional requests.¶

• ucacaps: clients fall back to RFC 7030 operations on error.¶

• Aligned base64 transfer with RFC 8951, and adopted RFC 7030 rules for error responses, HTTP 202, and linking identity and POP.¶

• Clarified HTTP caching, text response format, and security considerations.¶

• Reference updates and editorial fixes.¶