]> NIO Inc.

lijun.liao@nio.io

This document defines Enrollment over Secure Transport (EST) protocol operations over HTTPS and secure CoAP for use with C509 certificates. The operations specified in this document support CA certificate distribution, C509 certificate enrollment, C509 certificate re-enrollment, and server-side key generation using C509 certificates. This document also defines operations for server capability discovery, Certificate Revocation List (CRL) distribution, and a challenge-response proof of possession for KEM-only keys. About This Document Status information for this document may be found at . Discussion of this document takes place on the Authentication and Authorization for Constrained Environments Working Group mailing list (), which is archived at . Subscribe at . Source for this draft and an issue tracker can be found at .

Introduction Enrollment over Secure Transport (EST) defines HTTPS-based operations for X.509 certificate enrollment and CA certificate distribution. Payloads are DER-encoded and wrapped in CMS (Cryptographic Message Syntax, ) structures. C509 defines a compact, CBOR-encoded alternative to DER X.509 certificates. C509 certificates are substantially smaller. Although C509 was developed with constrained devices in mind, its benefits extend to unconstrained devices operating over low-bandwidth links and to large-scale deployments. Smaller, CBOR-encoded certificates reduce bandwidth and storage requirements, accelerate TLS handshakes, and lower parsing and serialization overhead even on powerful endpoints; because C509 does not use ASN.1/DER, implementations can avoid complex ASN.1 parsing code, which reduces code size and complexity and lowers the attack surface for certificate parsing libraries. In complex systems (for example, connected cars) that contain diverse device classes—microcontrollers, sensor chips, and SoCs—using a common certificate format wherever practical simplifies integration and provisioning. Using C509 consistently across device classes simplifies provisioning, interoperability, and over-the-air updates, and can reduce overall operational costs and latency. This document defines EST operations that carry C509 objects in place of DER X.509 objects, following the same secure transport and URI path structure as and . A key property of this design is that EST clients need only minimal CBOR processing:

• For non-KEM-only key types, the C509 CSR is typically pre-provisioned as an opaque binary blob by the device manufacturer or a provisioning tool; the EST client sends it verbatim as the POST body of simpleenroll / sen or simplereenroll / sren without interpreting its contents.
• For KEM-only key types, the EST client needs to communicate with the component that holds the private key (for example, a secure element or a hardware security module) to get the public key (C509SubjectPublicKeyInfo) and, after receiving the KEM challenge object (C509KemChall) from the EST server, the certification request (C509CertificationRequest); in this case, the EST client treats the C509SubjectPublicKeyInfo, C509KemChall, and C509CertificationRequest as opaque binary blobs.
• For all key types, the C509 certificate (and private key in the operation serverkeygen / skc) returned in the response is stored directly in persistent memory without modification. The EST client MUST validate received C509 certificates against a trust anchor (see ); apart from this validation, no parsing of the response is required. This property makes the EST client implementation lightweight.

This document uses C509CertificationRequest as defined in as the C509 Certificate Signing Request (C509 CSR) format. An EST client uses a C509 CSR to request issuance of a C509 certificate from an EST server. The operations for EST over HTTPS used in this document (those marked new are new operations defined in this document) are listed in , and those for EST over CoAP in .

Operations for EST over HTTPS Used in This Document (M/O: MANDATORY / OPTIONAL)

Operations for EST over CoAP/DTLS Used in This Document (M/O: MANDATORY / OPTIONAL)

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 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 C509 certificates.

C509 CSR:

C509 Certification Request. A CBOR-encoded certification request used by an EST client to request issuance of a C509 certificate.

PoP:

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

Protocol Design

Client Authentication While permits a number of the EST functions to be used without authentication, this document requires that the client MUST be authenticated for all functions, as in . This document requires EST to support certificate-based client authentication only; neither HTTP Basic nor Digest authentication (as described in ) is supported, as in .

TLS Certificate Type Negotiation When C509 certificates are used for TLS or DTLS authentication, the client and server negotiate the certificate type using the server_certificate_type and client_certificate_type TLS extensions as defined in .

Discovery and URIs In EST over HTTPS, the capabilities of the EST server are retrieved by using the operation caps. In EST over CoAP/DTLS, the capabilities are retrieved by sending a GET method to the EST server (as in ). As in , the ct attribute lists the Content-Formats of both the request and the response. Linefeeds are included only for readability. ;rt="ace.est.crts";ct="TBD TBD TBD", ;rt="ace.est.sen";ct="TBD TBD", ;rt="ace.est.sren";ct="TBD TBD", ;rt="ace.est.att";ct=TBD, ;rt="ace.est.skc";ct="TBD TBD", ;rt="ace.est.crli";ct=TBD, ;rt="ace.est.crl";ct=TBD, ;rt="ace.est.kemc";ct="TBD3 TBD7" ]]> (TODO: the TBD values will be replaced with the real values once the Content-Formats are assigned in and .)

EST URL Structure and Path Components The operations in this document follow the same URI path structure defined in for HTTPS and the corresponding secure CoAP mapping defined in . Retrieval operations caps, cacerts / crts, csrattrs / att, crli, and crl use the GET method. Request target: /.well-known/est// ]]> Enrollment operations kemc, simpleenroll / sen, simplereenroll / sren, and serverkeygen / skc use HTTP POST or CoAP POST: Request target: /.well-known/est// ]]> An EST server MUST return HTTP 405 / CoAP 4.05 (Method Not Allowed) if a client uses POST for a retrieval operation or GET for an enrollment operation. The optional <label> path segment follows for HTTPS and the equivalent path structure in for CoAP: an EST server MAY use an additional path segment before the operation name to distinguish services for multiple CAs and / or certificate profiles.

Channel Binding Channel binding is OPTIONAL. The channel binding mechanisms specified in and apply.

Message Binding The message binding mechanism specified in applies for CoAP in this document.

Message Fragmentation The message fragmentation mechanism specified in applies for CoAP in this document.

Delayed Responses The mechanism for delayed responses specified in applies for CoAP in this document. The retry-later mechanism for the operations simpleenroll and simplereenroll specified in applies for HTTPS in this document.

Response Cache Successful responses whose content is not expected to change in the near future may include caching metadata:

• For EST over HTTPS, EST servers SHOULD include ETag, Last-Modified, Cache-Control, and Expires headers.
• For EST over secure CoAP, EST servers SHOULD include the options ETag and Max-Age.

CBOR Transfer All POST request bodies and all response bodies in this document, except the caps response, are CBOR-encoded. The CBOR encoding MUST be deterministic as specified in Sections and of . For HTTPS, following , the POST request bodies and the CBOR-based response bodies are base64-encoded as specified in ; the CBOR encoding is the input to the base64 encoding routine. This format is used regardless of any Content-Transfer-Encoding header, and any value in such a header MUST be ignored. As specified in , white space including CR, LF, spaces (ASCII 32), and tabs (ASCII 9) SHOULD be tolerated by receivers; senders are not required to insert any kind of white space. For CoAP, CBOR payloads are carried directly in binary form, without base64 encoding, in the message body using the relevant CoAP Content-Format. An EST server that serves both X.509 and C509 certificates under the same path distinguishes the requests by the media type (HTTP Content-Type) or Content-Format (CoAP) of the request. If the media type or Content-Format of a POST request is not supported, the EST server MUST return HTTP 415 / CoAP 4.15 (Unsupported Media Type / Unsupported Content-Format). The media types used in this document are: Media Types Used in This Document

Media Type	CoAP Content Format	Structure	Defined in
application/cose-c509-cert+cbor	TBD	C509Certificate
application/cose-c509+cbor	TBD	COSE_C509
application/cose-c509+cbor;usage=chain	TBD	COSE_C509
application/cose-c509-pkcs10+cbor	TBD	C509CertificationRequest
application/cose-c509-pubkey+cbor	TBD3	C509SubjectPublicKeyInfo
application/c509-kemchall+cbor	TBD7	C509KemChall	This document
application/cose-c509-crtemplate+cbor	TBD	C509CertificationRequestTemplate
application/cose-c509-pem+cbor	TBD	C509PEM (key + certificate)
application/c509-crl+cbor	TBD	C509CRL
application/c509-crlinfo+cbor	TBD	C509CRLInfo

The caps operation returns text/plain; charset=utf-8 with a list of capability keywords.

C509 Certification Request (C509 CSR) A C509 CSR is a CBOR-encoded certification request used to request issuance of a C509 certificate. It is the C509 analogue of the PKCS#10 CSR used in standard EST operations. This document uses C509CertificationRequest as defined in . An EST client sends a C509 CSR to request certificate issuance or re-enrollment. The media type is application/cose-c509-pkcs10+cbor. For server-side key generation requests (), the EST client does not possess the private key and does not know the public key that the EST server will generate. In this case, the subjectPublicKeyAlgorithm in TBSCertificationRequest MUST be set to the integer code for empty-publickey (see ) and subjectPublicKey MUST be a zero-length byte string (h''). Because no private/public key is available, no PoP signature can be computed/verified: the signatureAlgorithm MUST be set to the id-alg-unsigned integer code (see ) and signatureValue MUST be a zero-length byte string. EST servers MUST accept C509 CSRs using empty-publickey and id-alg-unsigned for serverkeygen / skc requests and MUST NOT verify a PoP signature in this case.

empty-publickey Algorithm This document defines a new C509 public key algorithm, empty-publickey, to be used exclusively in C509 CSRs for serverkeygen / skc (server key generation) requests to indicate that no public key is available in the CSR. The empty-publickey algorithm code (TBD1) MUST NOT appear in C509 certificates. It is only valid in the subjectPublicKeyAlgorithm field of TBSCertificationRequest when the corresponding subjectPublicKey is a zero-length byte string (h''). EST servers MUST reject any C509 CSR using empty-publickey in a simpleenroll / sen or simplereenroll / sren request.

CRAttribute C509ChangeSubjectName The ChangeSubjectName attribute for X.509 PKI is defined in . The corresponding definition for C509 certification requests is a CBOR array consisting of a subject and a subjectAlt. At least one of subject and subjectAlt MUST NOT be null. This CRAttribute MAY be included in a simplereenroll / sren request to change the Subject field and/or the SubjectAltName extension in the newly generated certificate.

Proof of Possession simpleenroll / sen and simplereenroll / sren MUST verify the PoP signature in the C509 CSR before issuing a certificate. As an exception, if the subjectPublicKeyAlgorithm in the C509 CSR is a KEM algorithm, the EST server MUST instead verify the PoP MAC as specified in . The serverkeygen / skc operation does not require PoP verification because the EST server generates the key pair itself.

Proof of Possession for KEM Private Keys Some public-key algorithms are KEM-only (key-encapsulation mechanisms) and do not provide a signature operation suitable for the traditional PoP signature carried in a C509CertificationRequest. For CSRs whose subjectPublicKeyAlgorithm is a KEM algorithm, an EST server MUST obtain explicit proof that the requester holds the corresponding KEM private key. This document specifies an interactive KEM challenge-response PoP mechanism based on the unilateral key confirmation specified in Section 4.4 of , in which the EST client (the decapsulator) is the key-confirmation provider and the EST server (the encapsulator) is the key-confirmation recipient. Together with the client authentication required by this document (), this provides PoP as described in Section 4.5 of .

Challenge Issuance Upon receipt of a KEM public key (C509SubjectPublicKeyInfo) in the kemc operation (), the EST server runs the encapsulation algorithm of the KEM with this public key, which produces a shared secret key K and a ciphertext c, and returns a CBOR-encoded KEM challenge object (C509KemChall) with media type application/c509-kemchall+cbor. The media type of C509KemChall is application/c509-kemchall+cbor (see ); the corresponding CoAP Content-Format is defined in . The "magic number" is TBD6, using the reserved CBOR tag 55799 and Content-Format TBD7, as described in . The fields are:

• keyId is the SHA-256 hash of the deterministically encoded (see ) C509SubjectPublicKeyInfo received in the kemc request.
• serverId is a 32-byte identifier of the EST server, chosen by the EST server. It is RECOMMENDED to use the SHA-256 hash of the certificate that the EST server uses for TLS or DTLS server authentication.
• encapsulation is the ciphertext c.
• lifetime, if present, is the number of seconds, counted from the sending of the response, after which the EST server considers the challenge expired. A relative value is used so that the EST client does not need a synchronized clock. If lifetime is absent, the lifetime is determined by the EST server policy and is not communicated to the EST client. An EST client SHOULD submit the enrollment request before the lifetime has elapsed; if the challenge has expired, the EST client needs to request a new challenge.

The KEM algorithm is the one identified by the subjectPublicKeyAlgorithm of the C509SubjectPublicKeyInfo received in the kemc request. The EST server MUST retain the challenge state, consisting of at least keyId, serverId, c, K, the identity of the authenticated EST client, and the expiry time of the challenge, until the challenge is used or has expired. A new challenge replaces any outstanding challenge for the same keyId and EST client.

PoP Nonce Because the KEM key pair to be certified is a static key pair, the key-confirmation provider (the EST client) contributes a nonce as its ephemeral data, as required by Section 4.4.1 of . The nonce is carried in the C509 CSR in the CR attribute C509KemPopNonce: The EST client MUST generate a fresh random nonce for each C509 CSR. The 256-bit length satisfies the requirement of Appendix C.2 of for all security strengths up to 256 bits. The C509KemPopNonce attribute MUST be present in a C509 CSR whose subjectPublicKeyAlgorithm is a KEM algorithm, and MUST NOT be present otherwise.

MAC Computation by the EST Client The EST client decapsulates encapsulation with its KEM private key to obtain the shared secret key K. The key-confirmation key KC_Key is K in its entirety (Section 4.4.2 of ); no data key is derived. The EST client constructs the TBSCertificationRequest, which includes the C509KemPopNonce attribute, and then constructs MAC_Data as specified in Section 4.4.1 of : where:

• KC_Step_Label is the 6-byte ASCII string "KC_1_D", indicating that the decapsulator provides the first key-confirmation message;
• ID_P is keyId (32 bytes), identifying the KEM key pair of the EST client;
• ID_R is serverId (32 bytes) from the C509KemChall;
• Eph_P is the value of the C509KemPopNonce attribute (32 bytes);
• Eph_R is the ciphertext encapsulation, whose length is fixed by the KEM algorithm;
• Extra_P is the CBOR-encoded TBSCertificationRequest; and
• Extra_R is empty.

All fields except Extra_P have a fixed length, so MAC_Data can be parsed unambiguously. The EST client computes the MAC tag over MAC_Data with KC_Key and places it in the C509CertificationRequest: the signatureAlgorithm MUST be set to the integer code of the MAC algorithm (e.g., TBD4 for HMAC-SHA256, see ) and the signatureValue MUST contain the MAC tag. The EST client then destroys K and submits a simpleenroll / sen or simplereenroll / sren request as usual.

Verification by the EST Server The EST server:

1. constructs a C509SubjectPublicKeyInfo from the subjectPublicKeyAlgorithm and subjectPublicKey fields of the TBSCertificationRequest, encodes it deterministically, and computes keyId from this encoding as described in ;
2. retrieves the challenge state for this keyId and verifies that the challenge has not expired and that the request is sent by the same authenticated EST client to which the challenge was issued;
3. verifies that the C509KemPopNonce attribute is present and is 32 bytes long;
4. constructs MAC_Data as specified in , using serverId and c from the challenge state; and
5. verifies the MAC tag in signatureValue over MAC_Data, using the MAC algorithm indicated by signatureAlgorithm and K from the challenge state.

Each challenge MUST be used at most once: the EST server MUST delete the challenge state, including K, after the first enrollment request that refers to it, whether or not the verification succeeds. If any step fails, the EST server MUST reject the request. Otherwise, the EST server proceeds with certificate issuance as for signature-based PoP.

MAC Algorithms The MAC algorithm MUST be one of the approved MAC algorithms for key confirmation listed in Appendix C.1 of , and the length of KC_Key MUST be permitted for that algorithm. EST servers MUST support HMAC-SHA256 (with integer value TBD4). EST clients SHOULD use HMAC-SHA256 and MAY use another approved MAC algorithm, for example if required by the security strength of the KEM. If the EST server does not support the MAC algorithm indicated by signatureAlgorithm, it MUST reject the request with HTTP 400 / CoAP 4.00 (Bad Request). EST servers MUST enforce challenge expiry and limit the number of outstanding challenges per EST client to mitigate denial-of-service risks.

EST Operations for Server Capability Discovery

caps This operation applies only to EST over HTTPS, not to EST over CoAP/DTLS. The caps operation allows an EST client to discover which C509-specific operations the EST server supports before invoking them. EST clients and EST servers MUST support caps.

Request The EST client sends a GET request for the server's C509 capability list. No request body is sent. /caps ]]>

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

• Media type: text/plain; charset=utf-8
• Body: A plain-text list of capability keywords, one keyword per line. The EST server MUST terminate each line with <CR><LF>. The EST client MUST be able to parse lines terminated by <CR><LF>, <CR>, or <LF>. Keywords are unquoted and case-insensitive.

The following keywords are defined. An EST server MUST include a keyword in the caps response if and only if it supports the corresponding operation. caps Keywords Defined in This Document

Keyword	Description
cacerts	EST server supports cacerts ()
crli	EST server supports crli ()
crl	EST server supports crl ()
csrattrs	EST server supports csrattrs ()
kemc	EST server supports kemc ()
simpleenroll	EST server supports simpleenroll ()
simplereenroll	EST server supports simplereenroll ()
serverkeygen	EST server supports serverkeygen ()

If an EST client receives an error response to a caps request, it cannot determine which OPTIONAL operations the EST server supports. In this case, the EST client MAY still attempt the MANDATORY operations cacerts, simpleenroll, and simplereenroll, and SHOULD NOT attempt the OPTIONAL operations. An EST client MUST be prepared to receive an error response for any operation. Successful caps responses MAY include caching metadata as specified in . Example response:

csrattrs / att The csrattrs / att operation returns a C509CertificationRequestTemplate that an EST client MAY use to construct a C509 CSR.

Request The EST client sends a GET request for the CSR template. No request body is sent. /csrattrs CoAP Request target: /.well-known/est//att ]]>

Response On success, the EST server returns an HTTP 200 / CoAP 2.05 response with:

• Media type: application/cose-c509-crtemplate+cbor (HTTP) / Content-Format TBD (CoAP)
• Body: A C509CertificationRequestTemplate as defined in .

A response code of HTTP 404 / CoAP 4.04 indicates that CSR attributes are not available. Successful csrattrs / att responses MAY include caching metadata as specified in .

EST Operations for Distribution of CA Certificates

cacerts / crts Depending on the Accept option, the cacerts / crts operation returns different forms of the CA certificates (TODO: the TBD will be replaced with the real value once the Content-Formats are assigned in and ):

• Accept: application/cose-c509-cert+cbor (HTTP) / Accept=TBD (CoAP): C509Certificate (the issuing CA certificate)
• Accept: application/cose-c509+cbor; usage=chain (HTTP) / Accept=TBD (CoAP): COSE_C509 (certificate chain)
• No Accept or Accept: application/cose-c509+cbor (HTTP) / Accept=TBD (CoAP): COSE_C509 (certificate set)

Request The EST client sends a GET request for the CA certificate(s). No request body is sent. The Accept option specifies the expected media type / Content-Format of the response. If an Accept option is not included in the request, the client is not expressing any preference and the server SHOULD return the CA certificate set with media type application/cose-c509+cbor (HTTP) / Content-Format TBD (CoAP). /cacerts (Accept: ) CoAP request target: /.well-known/est//crts (Accept=) ]]>

Response On success, the EST server returns an HTTP 200 / CoAP 2.05 response with:

• For Request with Accept: application/cose-c509-cert+cbor (HTTP) / Accept=TBD (CoAP):
  • Media type: application/cose-c509-cert+cbor (HTTP) / Content-Format TBD (CoAP)
  • Body: A C509Certificate representing the issuing CA certificate, i.e., the CA certificate whose key is used to issue certificates to the EST client. This form cannot carry the "Root CA Key Update" certificates defined in ; an EST client that needs them uses one of the other forms.
• For Request with Accept: application/cose-c509+cbor; usage=chain (HTTP) / Accept=TBD (CoAP):
  • Media type: application/cose-c509+cbor; usage=chain (HTTP) / Content-Format TBD (CoAP)
  • Body: A COSE_C509 representing an ordered certificate chain. The first element is the issuing CA certificate; subsequent elements are intermediate and root CA certificates in chain order. If a Root CA key update applies, the EST server SHOULD include the four "Root CA Key Update" certificates defined in in the response chain. If present, these certificates SHALL take the place of the root CA certificate at the end of the chain, in the order NewWithNew, NewWithOld, OldWithOld, and OldWithNew; that is, the chain is: issuing CA certificate, intermediate CA certificates (if any), NewWithNew, NewWithOld, OldWithOld, OldWithNew. In this case, the last intermediate CA certificate (or the issuing CA certificate if there is no intermediate CA) is issued under the new root CA key.
• For Request without Accept option or with Accept: application/cose-c509+cbor (HTTP) / Accept=TBD (CoAP):
  • Media type: application/cose-c509+cbor (HTTP) / Content-Format TBD (CoAP)
  • Body: A COSE_C509 representing a certificate set. The first element is the issuing CA certificate; no order is defined for the subsequent elements. If a Root CA key update applies, the EST server SHOULD include the four "Root CA Key Update" certificates defined in in the certificate set. No order is defined for these certificates.

If the server cannot return the CA certificates in the form requested by the Accept option, it MUST return HTTP 406 / CoAP 4.06 (Not Acceptable). Successful cacerts / crts responses MAY include caching metadata as specified in .

EST Operations for Distribution of C509 CRLs The crli and crl operations provide C509 CRL access. The C509 CRL format is defined in .

crli The crli operation returns metadata about the current C509 CRL for the target CA as a C509CRLInfo object without the full revocation list. This enables an EST client to check whether its locally cached CRL is still current before requesting the full crl. C509CRLInfo is defined in .

Request The EST client sends a GET request for CRL metadata. No request body is sent. /crli [?crlnumber=][&crldp=] ]]> The optional crlnumber query parameter carries the decimal representation of the CRL number the client is interested in. When present, the EST server MUST return the C509CRLInfo for the CRL with that exact crlNumber. If no CRL with the requested crlnumber is available, the EST server MUST return HTTP 404 / CoAP 4.04 (Not Found). When crlnumber is absent, the server returns the C509CRLInfo for the most recent CRL. The optional crldp query parameter carries a distribution point name extracted from the CRL Distribution Points extension of the certificate whose revocation status is to be checked (see ). The value is the URI of the distribution point, percent-encoded as specified in . When present, the EST server MUST return the C509CRLInfo for the CRL associated with that distribution point. When both crlnumber and crldp are present, the server MUST return the C509CRLInfo matching both criteria. For CoAP, each query parameter is carried in its own Uri-Query option, for example crlnumber=5 and crldp=<percent-encoded URI>.

Response On success, the EST server returns an HTTP 200 / CoAP 2.05 response with:

• Media type: application/c509-crlinfo+cbor (HTTP) / Content-Format TBD (CoAP)
• Body: A C509CRLInfo as defined in .

C509CRLInfo carries all CRL fields from C509CRLInfoData — including crlType, signatureAlgorithm, authoritySubject, authorityKeyIdentifier, crlNumber, thisUpdate, nextUpdate, baseCrlNumber, and crlExtensions — without the revokedCertsList. An EST client can use these fields to compare crlNumber, nextUpdate, or perform a freshness check against its local cache before deciding whether to download the full C509CRL via crl. If no matching CRL is available, the EST server MUST return HTTP 404 / CoAP 4.04 (Not Found). Successful crli responses MAY include caching metadata as specified in .

crl The crl operation returns the C509 CRL for the target CA.

Request The EST client sends a GET request for the C509 CRL. No request body is sent. /crl [?crlnumber=][&crldp=] ]]> The optional crlnumber query parameter carries the decimal representation of the CRL number. When present, the EST server MUST return the full C509CRL with that exact crlNumber. When crlnumber is absent, the server returns the most recent CRL. The optional crldp query parameter is encoded as specified for crli (). When present, the EST server MUST return the full C509CRL for the CRL associated with that distribution point. When both crlnumber and crldp are present, the server MUST return the C509CRL matching both criteria. For CoAP, the query parameters are carried in Uri-Query options as specified for crli ().

Response On success, the EST server returns an HTTP 200 / CoAP 2.05 response with:

• Media type: application/c509-crl+cbor (HTTP) / Content-Format TBD (CoAP)
• Body: A C509CRL as defined in .

If no matching CRL is available, the EST server MUST return HTTP 404 / CoAP 4.04 (Not Found). Successful crl responses MAY include caching metadata as specified in .

EST Operations for Certificate Enrollment

kemc The kemc operation requests a KEM-based Proof-of-Possession challenge for a submitted C509 public key whose subjectPublicKeyAlgorithm is a KEM algorithm.

Request An authenticated EST client sends a POST request containing a C509SubjectPublicKeyInfo () to request a KEM challenge. /kemc Media type: application/cose-c509-pubkey+cbor (HTTP) / Content-Format TBD (CoAP) Body: C509SubjectPublicKeyInfo ]]> If the request does not contain a KEM public key, the EST server MUST return HTTP 400 / CoAP 4.00 (Bad Request). If the server supports KEM PoP for the submitted algorithm, it issues a challenge; otherwise, it MUST return HTTP 501 / CoAP 5.01 (Not Implemented).

Response On success, the EST server returns an HTTP 200 / CoAP 2.05 response with:

• Media type: application/c509-kemchall+cbor (HTTP) / Content-Format TBD7 (CoAP)
• Body: A C509KemChall ().

A client that receives a C509KemChall decapsulates the shared secret key, computes the PoP MAC as specified in , and then proceeds with a normal enrollment request (simpleenroll / sen or simplereenroll / sren) carrying the MAC in the C509 CSR. The EST server verifies the MAC as specified in and issues the certificate on success.

simpleenroll / sen The simpleenroll / sen operation requests issuance of a new C509 certificate from the EST server.

Request An authenticated EST client sends a POST request containing a C509 CSR (). /simpleenroll CoAP Request target: /.well-known/est//sen Media type: application/cose-c509-pkcs10+cbor (HTTP) / Content-Format TBD (CoAP) Body: C509CertificationRequest ]]> The C509CertificationRequest MUST include a valid PoP signature. The EST server MUST verify the PoP signature against the public key in the C509 CSR before issuing a certificate, as required by . As an exception, if the public key in the C509 CSR is a KEM public key, the C509CertificationRequest MUST instead include a valid PoP MAC, and the EST server MUST verify it as specified in .

Response On success, the EST server returns an HTTP 200 / CoAP 2.05 response with:

• Media type: application/cose-c509-cert+cbor (HTTP) / Content-Format TBD (CoAP)
• Body: A C509Certificate issued for the subject in the C509 CSR, as defined in .

simplereenroll / sren The simplereenroll / sren operation renews or rekeys an existing C509 certificate.

Request An authenticated EST client sends a POST request containing a C509 CSR for re-enrollment. The request Subject field and SubjectAltName extension MUST be identical to the corresponding fields in the certificate being renewed or rekeyed. The C509ChangeSubjectName attribute defined in MAY be included in the CSR to request that these fields be changed in the new certificate. /simplereenroll CoAP Request target: /.well-known/est//sren Media type: application/cose-c509-pkcs10+cbor (HTTP) / Content-Format TBD (CoAP) Body: C509CertificationRequest ]]> Re-enrollment processing follows . The EST server MUST verify the PoP signature in the C509 CSR or, if the public key in the C509 CSR is a KEM public key, the PoP MAC as specified in .

Response On success, the EST server returns an HTTP 200 / CoAP 2.05 response with:

• Media type: application/cose-c509-cert+cbor (HTTP) / Content-Format TBD (CoAP)
• Body: A renewed C509Certificate, as defined in .

serverkeygen / skc The serverkeygen / skc operation requests server-side key generation and returns the generated private key and the issued C509 certificate. As discussed in , transporting private keys generated by the EST server is inherently risky. The use of server-generated private keys increases the risk of digital identity theft. Therefore, implementations SHOULD NOT use EST functions that rely on server-generated private keys.

Request An authenticated EST client sends a POST request containing a C509 CSR. The subjectPublicKeyAlgorithm in the C509 CSR MUST be set to empty-publickey () and subjectPublicKey MUST be a zero-length byte string (h''), because the key pair is generated by the EST server. The signatureAlgorithm MUST be the id-alg-unsigned integer code (see ) and signatureValue MUST be a zero-length byte string. EST servers MUST accept C509 CSRs that use empty-publickey and id-alg-unsigned for serverkeygen / skc and MUST NOT verify a PoP signature in this case. /serverkeygen CoAP Request target: /.well-known/est//skc Media type: application/cose-c509-pkcs10+cbor (HTTP) / Content-Format TBD (CoAP) Body: C509CertificationRequest ]]>

Response On success, the EST server returns an HTTP 200 / CoAP 2.05 response with:

• Media type: application/cose-c509-pem+cbor (HTTP) / Content-Format TBD (CoAP)
• Body: A C509PEM.

The C509CertData field in the C509PEM MUST contain only the issued C509 certificate for the generated key pair. 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 or DTLS channel; no additional encryption is applied.

Security Considerations The security requirements of apply in full to all operations defined in this document.

Transport Security All operations defined in this document MUST be carried out over HTTPS (HTTP over TLS) or secure CoAP (CoAP over DTLS) as required by and . Implementations MUST NOT fall back to plain HTTP or unsecured CoAP. EST clients and servers SHOULD use C509 certificates for TLS or DTLS authentication when both peers support C509. This enables end-to-end C509 usage, including the handshake itself, and reduces size and parsing overhead consistently. EST servers SHOULD continue to accept X.509 certificates for TLS or DTLS client authentication for interoperability with clients that do not yet support C509. All operations MUST require client authentication (see ).

Server Key Generation The serverkeygen / skc operation delivers a generated private key to the EST client over TLS or DTLS (see ). EST servers SHOULD delete the private key after successful transmission. EST clients MUST store the key material securely immediately upon receipt. Because the C509 CSR in a serverkeygen / skc request carries no proof of possession, the EST server MUST verify that the authenticated EST client is authorized to request a certificate for the subject and subject alternative names in the C509 CSR.

C509 Certificate Validation EST clients MUST validate received C509 certificates against an independently configured trust anchor according to .

C509 CRL Validation A C509 CRL received via the crl operation is protected by the secure transport only while in transit. Before using a C509 CRL, an EST client MUST verify its signature and validate the CRL issuer as specified in . An EST client uses a C509CRLInfo received via the crli operation only to decide whether to retrieve the full C509CRL; it MUST NOT use a C509CRLInfo in place of a validated C509CRL for revocation decisions.

KEM Proof of Possession The KEM PoP mechanism () follows the key confirmation specified in Section 4.4 of . The MAC tag can only be computed by a party that can decapsulate the ciphertext, i.e., that holds the KEM private key. MAC_Data binds the tag to the KEM public key (keyId), the EST server (serverId), the ciphertext, a fresh client nonce, and the complete TBSCertificationRequest, so that a tag cannot be reused for a different CSR, a different challenge, or a different EST server. Binding the challenge state to the authenticated EST client prevents another client from using the challenge, and the single-use requirement prevents replay. The shared secret key K is used only as the key-confirmation key. Both the EST client and the EST server MUST destroy K after use, as required by Section 4.4.2 of .

Capability Discovery An attacker that could modify a caps response could make an EST client believe that an operation is not supported, or that an operation is supported when it is not. This is prevented by the requirement that all operations are carried out over TLS or DTLS with an authenticated EST server (see ).

IANA Considerations

C509 Public Key Algorithms Registry IANA is requested to register the following entry in the "C509 Public Key Algorithms" registry under the registry group "CBOR Encoded X.509 (C509)" defined in : empty-publickey Registration

Field	Value
Value	TBD1
Name	empty-publickey
Identifiers	N/A
OID	N/A
Parameters	N/A
DER	N/A
Comments	Exclusively for use in subjectPublicKeyAlgorithm of a TBSCertificationRequest for server-side key generation (serverkeygen / skc). MUST NOT appear in C509 certificates.
Reference	This document

C509 Signature Algorithms Registry IANA is requested to register the following entry in the "C509 Signature Algorithms" registry under the registry group "CBOR Encoded X.509 (C509)" defined in : HMAC-SHA256 Registration

Field	Value
Value	TBD4
Name	hmacWithSHA256
Identifiers	id-hmacWithSHA256
OID	1.2.840.113549.2.9
Parameters	N/A
DER	06 08 2A 86 48 86 F7 0D 02 09
Comments	HMAC over SHA256. Exclusively for use in the signatureAlgorithm of a C509CertificationRequest for the KEM proof of possession. MUST NOT appear in C509 certificates.
Reference	This document

C509 CR Attributes Registry IANA is requested to register the following entries in the "C509 CR Attributes" registry under the registry group "CBOR Encoded X.509 (C509)" defined in :

C509 CR Attribute Registrations

Media Types Registry IANA is requested to register the following media type in the "Media Types" registry.

Media Type application/c509-kemchall+cbor When the application/c509-kemchall+cbor media type is used, the payload is a C509KemChall structure. Type name: application Subtype name: c509-kemchall+cbor Required parameters: N/A Optional parameters: N/A Encoding considerations: binary Security considerations: See of RFC XXXX. Interoperability considerations: N/A Published specification: RFC XXXX Applications that use this media type: Applications that employ C509 KEM challenges. Fragment identifier considerations: N/A Additional information:

• Deprecated alias names for this type: N/A
• Magic number(s): TBD6 (derived from the CoAP Content-Format TBD7 as described in )
• File extension(s): .c509
• Macintosh file type code(s): N/A

Person & email address to contact for further information: iesg@ietf.org Intended usage: COMMON Restrictions on usage: N/A Author: ACE WG Change controller: IETF

CoAP Content-Formats Registry IANA is requested to add the entry for application/c509-kemchall+cbor to the "CoAP Content-Formats" registry in the registry group "Constrained RESTful Environments (CoRE) Parameters".

CoAP Content-Format IDs

Resource Type (rt=) Link Target Attribute Values Registry IANA is requested to add the following entries to the "Resource Type (rt=) Link Target Attribute Values" registry in the registry group "Constrained RESTful Environments (CoRE) Parameters": Resource Type Registrations

Value	Description	Reference
ace.est.crli	C509 CRL metadata retrieval	RFC XXXX
ace.est.crl	C509 CRL retrieval	RFC XXXX
ace.est.kemc	KEM challenge issuance	RFC XXXX

RFC Editor: Please replace "RFC XXXX" with the RFC number of this document and remove this note.

References Normative References 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 contains a set of updates to the base syntax for CMC, a Certificate Management protocol using the Cryptographic Message Syntax (CMS). This document updates RFC 5272, RFC 5273, and RFC 5274. The new items in this document are: new controls for future work in doing server side key generation, definition of a Subject Information Access value to identify CMC servers, and the registration of a port number for TCP/IP for the CMC service to run on. [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. 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 specifies a new certificate type and two TLS extensions for exchanging raw public keys in Transport Layer Security (TLS) and Datagram Transport Layer Security (DTLS). The new certificate type allows raw public keys to be used for authentication. The Concise Binary Object Representation (CBOR) is a data format whose design goals include the possibility of extremely small code size, fairly small message size, and extensibility without the need for version negotiation. These design goals make it different from earlier binary serializations such as ASN.1 and MessagePack. This document obsoletes RFC 7049, providing editorial improvements, new details, and errata fixes while keeping full compatibility with the interchange format of RFC 7049. It does not create a new version of the format. 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 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] A Uniform Resource Identifier (URI) is a compact sequence of characters that identifies an abstract or physical resource. This specification defines the generic URI syntax and a process for resolving URI references that might be in relative form, along with guidelines and security considerations for the use of URIs on the Internet. The URI syntax defines a grammar that is a superset of all valid URIs, allowing an implementation to parse the common components of a URI reference without knowing the scheme-specific requirements of every possible identifier. This specification does not define a generative grammar for URIs; that task is performed by the individual specifications of each URI scheme. [STANDARDS-TRACK] This document defines a stored ("file") format for Concise Binary Object Representation (CBOR) data items that is friendly to common systems that recognize file types, such as the Unix file(1) command. This document describes the Internet X.509 Public Key Infrastructure (PKI) Certificate Management Protocol (CMP). Protocol messages are defined for X.509v3 certificate creation and management. CMP provides interactions between client systems and PKI components such as a Registration Authority (RA) and a Certification Authority (CA). This document adds support for management of certificates containing a Key Encapsulation Mechanism (KEM) public key and uses EnvelopedData instead of EncryptedValue. This document also includes the updates specified in Section 2 and Appendix A.2 of RFC 9480. This document obsoletes RFC 4210, and together with RFC 9811, it also obsoletes RFC 9480. Appendix F of this document updates Section 9 of RFC 5912. Ericsson AB Ericsson AB University of Glasgow RISE AB IN Groupe NIO Inc. This document specifies a CBOR encoding of X.509 certificates. The resulting certificates are called C509 certificates. The CBOR encoding supports a large subset of RFC 5280 and common certificate profiles, and it is extensible. Two types of C509 certificates are defined. One type is an invertible CBOR re-encoding of DER-encoded X.509 certificates with the signature field copied from the DER encoding. The other type is identical except that the signature is computed over the CBOR encoding instead of the DER encoding, thereby avoiding the use of ASN.1. Both types of certificates have the same semantics as X.509 while providing comparable size reduction. This document also specifies CBOR-encoded data structures for certification requests and certification request templates, new COSE headers, as well as a TLS certificate type and a file format for C509. This document updates RFC 6698 by extending the TLSA selectors registry to include C509 certificates. NIO RISE AB RISE AB RISE AB University of Glasgow This document specifies CBOR-encoded PKI structures for use with C509 certificates (draft-ietf-cose-cbor-encoded-cert), X.509 certificates (RFC 5280), and future certificate types. It defines C509 CRL and C509 OCSP, compact CBOR encodings of X.509 Certificate Revocation Lists (RFC 5280) and OCSP messages (RFC 6960), respectively. The structures defined in this document are certificate-type agnostic and can be used with C509 certificates, X.509 certificates, or future certificate types without modification. C509 OCSP improves on RFC 6960 by signing a wider set of fields to prevent algorithm- substitution and certificate-chain substitution attacks, replacing plaintext serial numbers with hashes to preserve requestor privacy, replacing the two-hash issuer identity with a single certificate hash, and identifying all participants (requestor, responder, issuer) by a uniform certificate hash rather than type-specific fields. C509 CRL and C509 OCSP are not wire-format-compatible with their DER- encoded X.509 counterparts and cannot be converted to or from them without semantic interpretation. NIO This document defines additions to CBOR Encoded X.509 Certificates (C509). This document defines a new C509SubjectPublicKeyInfo type, a CBOR representation of the X.509 SubjectDirectoryAttributes extension, and a mechanism that allows organizations assigned a Private Enterprise Number (PEN) to define organization-specific integer identifiers without registering each identifier in the C509 RDN attribute type, CR attribute type, extension ID, certificate policy, or extended key usage registries. This document also defines textual encoding labels for C509 objects using the textual encoding conventions specified in RFC 7468. 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 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 Cryptographic Message Syntax (CMS). This syntax is used to digitally sign, digest, authenticate, or encrypt arbitrary message content. [STANDARDS-TRACK]

Message Flow Diagrams of EST over HTTPS Operations

caps

Message flow of EST over HTTPS operation caps /caps | |---------------------------------------------->| | | | Status: 200 OK | | Media type: text/plain;charset=utf-8 | | | | | |<----------------------------------------------| | | ]]>

cacerts for single CA certificate

Message flow of EST over HTTPS operation cacerts for single CA certificate /cacerts | | Accept: application/cose-c509-cert+cbor | |------------------------------------------------->| | | | Status: 200 OK | | Media type: application/cose-c509-cert+cbor | | | | | |<-------------------------------------------------| | | ]]>

cacerts for CA certificate set

Message flow of EST over HTTPS operation cacerts for CA certificate set /cacerts | |------------------------------------------------->| | | | Status: 200 OK | | Media type: application/cose-c509+cbor | | | | | |<-------------------------------------------------| | | ]]>

cacerts for CA certificate chain

Message flow of EST over HTTPS cacerts for CA certificate chain /cacerts | | Accept: application/cose-c509+cbor; | | usage=chain | |------------------------------------------------->| | | | Status: 200 OK | | Media type: application/cose-c509+cbor; | | usage=chain | | | | | |<-------------------------------------------------| | | ]]>

crli

Message flow of EST over HTTPS operation crli /crli | | [?crlnumber=][&crldp=] | |----------------------------------------------->| | | | Status: 200 OK | | Media type: application/c509-crlinfo+cbor | | | | | |<-----------------------------------------------| | | ]]>

crl

Message flow of EST over HTTPS operation crl /crl | | [?crlnumber=][&crldp=] | |----------------------------------------------->| | | | Status: 200 OK | | Media type: application/c509-crl+cbor | | | | | |<-----------------------------------------------| | | ]]>

kemc

Message flow of EST over HTTPS operation kemc /kemc | | Media type: application/cose-c509-pubkey+cbor | | | | | |----------------------------------------------->| | | | | | Status: 200 OK | | Media type: application/c509-kemchall+cbor | | | | | |<-----------------------------------------------| | | ]]>

simpleenroll

Message flow of EST over HTTPS operation simpleenroll | | /simpleenroll | | Media type: application/cose-c509-pkcs10+cbor | | | | | |----------------------------------------------->| Verify PoP, | | Issue C509 | | cert | Status: 200 OK | | Media type: application/cose-c509-cert+cbor | | | | | |<-----------------------------------------------| | | ]]>

simplereenroll

Message flow of EST over HTTPS operation simplereenroll | | /simplereenroll | | Media type: application/cose-c509-pkcs10+cbor | | | | | |----------------------------------------------->| Verify PoP, | | Issue C509 | | cert | Status: 200 OK | | Media type: application/cose-c509-cert+cbor | | | | | |<-----------------------------------------------| | | ]]>

serverkeygen

Message flow of EST over HTTPS operation serverkeygen | | /serverkeygen | | Media type: application/cose-c509-pkcs10+cbor | | | | | |----------------------------------------------->| | | Generate | | keypair, | | Issue C509 | Status: 200 OK | cert, Delete | Media type: application/cose-c509-pem+cbor | key from server | | | | |<-----------------------------------------------| | (key no longer on EST server) | | | ]]>

Message Flow Diagrams of EST over CoAP/DTLS Operations

crts for single CA certificate

Message flow of EST over CoAP/DTLS operation crts for single CA certificate /crts | | (Accept: TBD) | |---------------------------------------------->| | | | 2.05 Content (Content-Format: TBD) | | { payload with CBOR-encoded C509Certificate | | in binary format } | |<----------------------------------------------| | | ]]>

crts for CA certificate set

Message flow of EST over CoAP/DTLS operation crts for CA certificate set /crts | |---------------------------------------------->| | | | 2.05 Content (Content-Format: TBD) | | { payload with CBOR-encoded COSE_C509 | | (certificate set) in binary format } | |<----------------------------------------------| | | ]]>

crts for CA certificate chain

Message flow of EST over CoAP/DTLS operation crts for CA certificate chain /crts | | (Accept: TBD) | |---------------------------------------------->| | | | 2.05 Content (Content-Format: TBD) | | { payload with CBOR-encoded COSE_C509 | | (certificate chain) in binary format } | |<----------------------------------------------| | | ]]>

crli

Message flow of EST over CoAP/DTLS operation crli /crli | | [?crlnumber=][&crldp=] | |---------------------------------------------->| | | | 2.05 Content (Content-Format: TBD) | | { payload with CBOR-encoded C509CRLInfo | | in binary format } | |<----------------------------------------------| | | ]]>

crl

Message flow of EST over CoAP/DTLS operation crl /crl | | [?crlnumber=][&crldp=] | |---------------------------------------------->| | | | 2.05 Content (Content-Format: TBD) | | { payload with CBOR-encoded C509CRL | | in binary format } | |<----------------------------------------------| | | ]]>

kemc

Message flow of EST over CoAP/DTLS operation kemc /kemc | | (Content-Format: TBD) | | { payload with CBOR-encoded | | C509SubjectPublicKeyInfo in binary format } | |----------------------------------------------->| | | | 2.05 Content (Content-Format: TBD) | | { payload with CBOR-encoded C509KemChall | | in binary format } | |<-----------------------------------------------| | | ]]>

sen

Message flow of EST over CoAP/DTLS operation sen /sen | | (Content-Format: TBD) | | { payload with CBOR-encoded | | C509CertificationRequest in binary format } | |---------------------------------------------->| | | | 2.05 Content (Content-Format: TBD) | | { payload with CBOR-encoded C509Certificate | | in binary format } | |<----------------------------------------------| | | ]]>

sren

Message flow of EST over CoAP/DTLS operation sren /sren | | (Content-Format: TBD) | | { payload with CBOR-encoded | | C509CertificationRequest in binary format } | |---------------------------------------------->| | | | 2.05 Content (Content-Format: TBD) | | { payload with CBOR-encoded C509Certificate | | in binary format } | |<----------------------------------------------| | | ]]>

skc

Message flow of EST over CoAP/DTLS operation skc /skc | | (Content-Format: TBD) | | { payload with CBOR-encoded | | C509CertificationRequest in binary format } | |----------------------------------------------->| | | | 2.05 Content (Content-Format: TBD) | | { payload with CBOR-encoded C509PEM | | in binary format } | |<-----------------------------------------------| | | ]]>

Acknowledgements The author thanks the members of the ACE and COSE working groups for reviewing and commenting on intermediate versions of this draft.

Change log

• RFC Editor's Note: Please remove this section prior to publication of a final version of this document.

Since draft-liao-ace-est-c509-03

• Use C509SubjectPublicKeyInfo defined in instead of C509PublicKey and the media type application/c509-pubkey+cbor previously defined in this document.
• Specify the order of the "Root CA Key Update" certificates in the CA certificate chain, and state that no order is defined for them in the CA certificate set.
• Allow a PoP MAC instead of a PoP signature for KEM public keys, and specify how the MAC is carried in the C509 CSR and how the server locates the challenge state.
• Align the KEM PoP with the key confirmation of : define MAC_Data, add the serverId field to C509KemChall, add the CR attribute C509KemPopNonce for the client nonce, and require single-use challenges bound to the authenticated EST client, remove the encapAlg field from C509KemChall, add the optional lifetime field to C509KemChall, and make HMAC-SHA256 mandatory to implement for EST servers.
• Require (MUST instead of SHOULD) empty-publickey and id-alg-unsigned in serverkeygen / skc requests.
• Follow for the base64 encoding of HTTPS payloads; CoAP payloads are binary.
• Require EST clients to validate received C509 certificates against a trust anchor.
• Specify HTTP 406 / CoAP 4.06 and HTTP 415 / CoAP 4.15 error responses.
• Add security considerations for server key generation, C509 CRL validation, and capability discovery.
• Add IANA registrations for the resource types ace.est.crli, ace.est.crl, and ace.est.kemc.
• Move RFC 5652 to the informative references.
• Use /.well-known/est/ as the path prefix for EST over CoAP, and <label> in the message flow diagrams.
• Specify the crldp query parameter as a percent-encoded distribution point URI taken from the certificate, and its encoding as CoAP Uri-Query options.
• Relax the client behavior after an error response to caps.
• Specify that the single-certificate form of cacerts / crts returns the issuing CA certificate.
• Editorial changes.

Since draft-liao-ace-est-c509-02

• Use both long name and short name of operations.
• Add message flows for the cacerts / crts operation to retrieve single CA certificate, and CA certificate chain.
• Add message flows for EST over CoAP/DTLS.
• Editorial changes.

Since draft-liao-ace-est-c509-01

• Add EST of C509 certificate over secure CoAP.
• Use short operation names defined in to replace the long names defined in .