| Internet-Draft | EST-C509 | November 2026 |
| Liao | Expires 5 May 2027 | [Page] |
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.¶
This note is to be removed before publishing as an RFC.¶
Status information for this document may be found at https://datatracker.ietf.org/doc/draft-liao-ace-est-c509/.¶
Discussion of this document takes place on the Authentication and Authorization for Constrained Environments Working Group mailing list (mailto:ace@ietf.org), which is archived at https://mailarchive.ietf.org/arch/browse/ace/. Subscribe at https://www.ietf.org/mailman/listinfo/ace/.¶
Source for this draft and an issue tracker can be found at https://github.com/ace-wg/xxx.¶
This Internet-Draft is submitted in full conformance with the provisions of BCP 78 and BCP 79.¶
Internet-Drafts are working documents of the Internet Engineering Task Force (IETF). Note that other groups may also distribute working documents as Internet-Drafts. The list of current Internet-Drafts is at https://datatracker.ietf.org/drafts/current/.¶
Internet-Drafts are draft documents valid for a maximum of six months and may be updated, replaced, or obsoleted by other documents at any time. It is inappropriate to use Internet-Drafts as reference material or to cite them other than as "work in progress."¶
This Internet-Draft will expire on 5 May 2027.¶
Copyright (c) 2026 IETF Trust and the persons identified as the document authors. All rights reserved.¶
This document is subject to BCP 78 and the IETF Trust's Legal Provisions Relating to IETF Documents (https://trustee.ietf.org/license-info) in effect on the date of publication of this document. Please review these documents carefully, as they describe your rights and restrictions with respect to this document. Code Components extracted from this document must include Revised BSD License text as described in Section 4.e of the Trust Legal Provisions and are provided without warranty as described in the Revised BSD License.¶
Enrollment over Secure Transport (EST) [RFC7030] defines HTTPS-based operations for X.509 [RFC5280] certificate enrollment and CA certificate distribution. Payloads are DER-encoded and wrapped in CMS (Cryptographic Message Syntax, [RFC5652]) structures. C509 [I-D.ietf-cose-cbor-encoded-cert] 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 [RFC7030] and [RFC9148].¶
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 Section 9.3); 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 [I-D.ietf-cose-cbor-encoded-cert] 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 Figure 1, and those for EST over CoAP in Figure 2.¶
+==========+===+=============+==============+===================+ | Opera- | M | Description | Request | Response | | tion | / | | Media Type | Media Type | | | O | | | | +==========+===+=============+==============+===================+ | caps | M | Capability | (none) | text/plain; | | (new) | | discovery | | charset=utf-8 | +----------+---+-------------+--------------+-------------------+ | cacerts | M | CA | (none) | - application/ | | | | certificate | | cose-c509+cbor | | | | retrieval | | - application/ | | | | | | cose-c509+cbor, | | | | | | usage=chain | | | | | | - application/ | | | | | | cose-c509-cert | | | | | | +cbor | +----------+---+-------------+--------------+-------------------+ | crli | O | CRL | (none) | application/ | | (new) | | metadata | | c509-crlinfo+cbor | | | | retrieval | | | +----------+---+-------------+--------------+-------------------+ | crl | O | CRL | (none) | application/ | | (new) | | retrieval | | c509-crl+cbor | +----------+---+-------------+--------------+-------------------+ | csr | O | CSR | (none) | application/ | | attrs | | attributes | | cose-c509- | | | | retrieval | | crtemplate+cbor | +----------+---+-------------+--------------+-------------------+ | kemc | O | KEM | application/ | application/ | | (new) | | challenge | cose-c509- | c509-kemchall | | | | issuance | pubkey+cbor | +cbor | +----------+---+-------------+--------------+-------------------+ | simple | M | Certificate | application/ | application/ | | enroll | | enrollment | cose-c509- | cose-c509- | | | | | pkcs10+cbor | cert+cbor | +----------+---+-------------+--------------+-------------------+ | simple | M | Certificate | application/ | application/ | | reenroll | | reenroll- | cose-c509- | cose-c509- | | | | ment | pkcs10+cbor | cert+cbor | +----------+---+-------------+--------------+-------------------+ | server | O | Server-side | application/ | application/ | | keygen | | key | cose-c509- | cose-c509- | | | | generation | pkcs10+cbor | pem+cbor | +----------+---+-------------+--------------+-------------------+
+===============+================+=====+==========+==========+ | EST over | Corresponding | M/O | Request | Response | | CoAP/DTLS | EST over HTTPS | | Content- | Content- | | Operation | Operation | | Format | Format | +===============+================+=====+==========+==========+ | (Not Related) | caps | N/A | N/A | N/A | +---------------+----------------+-----+----------+----------+ | crts | cacerts | M | (none) | - TBD | | | | | | - TBD | | | | | | - TBD | +---------------+----------------+-----+----------+----------+ | crli (new) | crli | O | (none) | TBD | +---------------+----------------+-----+----------+----------+ | crl (new) | crl | O | (none) | TBD | +---------------+----------------+-----+----------+----------+ | attr | csrattrs | O | (none) | TBD | +---------------+----------------+-----+----------+----------+ | kemc (new) | kemc | O | TBD | TBD | +---------------+----------------+-----+----------+----------+ | sen | simpleenroll | M | TBD | TBD | +---------------+----------------+-----+----------+----------+ | sren | simplereenroll | M | TBD | TBD | +---------------+----------------+-----+----------+----------+ | skc | serverkeygen | O | TBD | TBD | +---------------+----------------+-----+----------+----------+
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 [RFC2119] [RFC8174] when, and only when, they appear in all capitals, as shown here.¶
The following terms are used in this document:¶
The entity that contacts the EST server to obtain certificates or CA information, as defined in [RFC7030], Section 1.¶
The entity that processes EST requests, typically acting as an RA between the EST client and the CA, as defined in [RFC7030], Section 1.¶
Certification Authority. The entity that issues C509 certificates.¶
C509 Certification Request. A CBOR-encoded certification request used by an EST client to request issuance of a C509 certificate.¶
Proof of Possession. Verification that the requester holds the private key corresponding to the public key in the C509 CSR.¶
While [RFC7030] 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 [RFC9148]. This document requires EST to support certificate-based client authentication only; neither HTTP Basic nor Digest authentication (as described in Section 3.2.3 of [RFC7030]) is supported, as in [RFC9148].¶
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 [RFC7250].¶
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 Section 4.1 of [RFC9148]). As in [RFC9148], the ct attribute lists the Content-Formats of both the request and the response. Linefeeds are included only for readability.¶
REQ: GET /.well-known/core?rt=ace.est* RES: 2.05 Content </.well-known/est/crts>;rt="ace.est.crts";ct="TBD TBD TBD", </.well-known/est/sen>;rt="ace.est.sen";ct="TBD TBD", </.well-known/est/sren>;rt="ace.est.sren";ct="TBD TBD", </.well-known/est/att>;rt="ace.est.att";ct=TBD, </.well-known/est/skc>;rt="ace.est.skc";ct="TBD TBD", </.well-known/est/crli>;rt="ace.est.crli";ct=TBD, </.well-known/est/crl>;rt="ace.est.crl";ct=TBD, </.well-known/est/kemc>;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 [I-D.ietf-cose-cbor-encoded-cert] and [I-D.liao-cose-c509-revocation].)¶
The operations in this document follow the same URI path structure defined in [RFC7030], Section 3.2.2 for HTTPS and the corresponding secure CoAP mapping defined in [RFC9148]. Retrieval operations caps, cacerts / crts, csrattrs / att, crli, and crl use the GET method.¶
Method: GET Request target: /.well-known/est/<operation> Request target: /.well-known/est/<label>/<operation>¶
Enrollment operations kemc, simpleenroll / sen, simplereenroll / sren, and serverkeygen / skc use HTTP POST or CoAP POST:¶
Method: POST Request target: /.well-known/est/<operation> Request target: /.well-known/est/<label>/<operation>¶
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 [RFC7030], Section 3.2.2 for HTTPS and the equivalent path structure in [RFC9148] 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 is OPTIONAL. The channel binding mechanisms specified in [RFC7030] and [RFC9148] apply.¶
The message binding mechanism specified in [RFC9148], Section 4.4 applies for CoAP in this document.¶
The message fragmentation mechanism specified in [RFC9148], Section 4.6 applies for CoAP in this document.¶
The mechanism for delayed responses specified in [RFC9148], Section 4.7 applies for CoAP in this document. The retry-later mechanism for the operations simpleenroll and simplereenroll specified in [RFC7030], Section 4.2.3 applies for HTTPS in this document.¶
Successful responses whose content is not expected to change in the near future may include caching metadata:¶
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 4.2.1 and 4.2.2 of [RFC8949].¶
For HTTPS, following [RFC8951], the POST request bodies and the CBOR-based response bodies are base64-encoded as specified in Section 4 of [RFC4648]; 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 [RFC8951], Section 3.1, 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 Type | CoAP Content Format | Structure | Defined in |
|---|---|---|---|
| application/cose-c509-cert+cbor | TBD | C509Certificate | [I-D.ietf-cose-cbor-encoded-cert] |
| application/cose-c509+cbor | TBD | COSE_C509 | [I-D.ietf-cose-cbor-encoded-cert] |
| application/cose-c509+cbor;usage=chain | TBD | COSE_C509 | [I-D.ietf-cose-cbor-encoded-cert] |
| application/cose-c509-pkcs10+cbor | TBD | C509CertificationRequest | [I-D.ietf-cose-cbor-encoded-cert] |
| application/cose-c509-pubkey+cbor | TBD3 | C509SubjectPublicKeyInfo | [I-D.liao-cose-c509-additions] |
| application/c509-kemchall+cbor | TBD7 | C509KemChall | This document |
| application/cose-c509-crtemplate+cbor | TBD | C509CertificationRequestTemplate | [I-D.ietf-cose-cbor-encoded-cert] |
| application/cose-c509-pem+cbor | TBD | C509PEM (key + certificate) | [I-D.ietf-cose-cbor-encoded-cert] |
| application/c509-crl+cbor | TBD | C509CRL | [I-D.liao-cose-c509-revocation] |
| application/c509-crlinfo+cbor | TBD | C509CRLInfo | [I-D.liao-cose-c509-revocation] |
The caps operation returns text/plain; charset=utf-8 with a list of capability keywords.¶
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 [RFC2986] used in standard EST operations.¶
This document uses C509CertificationRequest as defined in [I-D.ietf-cose-cbor-encoded-cert], Section 4. 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 (Section 8.4), 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 Section 4.1) 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 [I-D.ietf-cose-cbor-encoded-cert]) 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.¶
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.¶
The ChangeSubjectName attribute for X.509 PKI is defined in [RFC6402]. 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.¶
C509ChangeSubjectName = [ subject C509Name / null, subjectAlt SubjectAltName / 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.¶
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 Section 4.3.1. The serverkeygen / skc operation does not require PoP verification because the EST server generates the key pair itself.¶
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 [NIST.SP.800-227], 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 (Section 3.1), this provides PoP as described in Section 4.5 of [NIST.SP.800-227].¶
Upon receipt of a KEM public key (C509SubjectPublicKeyInfo) in the kemc operation (Section 8.1), 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.¶
C509KemChall = [ keyId : bstr .size 32, serverId : bstr .size 32, encapsulation : bstr, ? lifetime : uint ]¶
The media type of C509KemChall is application/c509-kemchall+cbor (see Section 10.4.1); the corresponding CoAP Content-Format is defined in Section 10.5. The "magic number" is TBD6, using the reserved CBOR tag 55799 and Content-Format TBD7, as described in [RFC9277], Section 2.2.¶
The fields are:¶
keyId is the SHA-256 hash of the deterministically encoded (see Section 3.10) 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.¶
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 [NIST.SP.800-227]. The nonce is carried in the C509 CSR in the CR attribute C509KemPopNonce:¶
C509KemPopNonce = bstr .size 32¶
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 [NIST.SP.800-227] 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.¶
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 [NIST.SP.800-227]); 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 [NIST.SP.800-227]:¶
MAC_Data = KC_Step_Label || ID_P || ID_R || Eph_P || Eph_R
|| Extra_P || Extra_R
¶
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 Section 10.2) 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.¶
The EST server:¶
constructs a C509SubjectPublicKeyInfo from the subjectPublicKeyAlgorithm and subjectPublicKey fields of the TBSCertificationRequest, encodes it deterministically, and computes keyId from this encoding as described in Section 4.3.1.1;¶
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;¶
verifies that the C509KemPopNonce attribute is present and is 32 bytes long;¶
constructs MAC_Data as specified in Section 4.3.1.3, using serverId and c from the challenge state; and¶
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.¶
The MAC algorithm MUST be one of the approved MAC algorithms for key confirmation listed in Appendix C.1 of [NIST.SP.800-227], 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.¶
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.¶
The EST client sends a GET request for the server's C509 capability list. No request body is sent.¶
Method: GET HTTP request target: /.well-known/est/<label>/caps¶
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.¶
| Keyword | Description |
|---|---|
cacerts
|
EST server supports cacerts (Section 6.1) |
crli
|
EST server supports crli (Section 7.1) |
crl
|
EST server supports crl (Section 7.2) |
csrattrs
|
EST server supports csrattrs (Section 5.2) |
kemc
|
EST server supports kemc (Section 8.1) |
simpleenroll
|
EST server supports simpleenroll (Section 8.2) |
simplereenroll
|
EST server supports simplereenroll (Section 8.3) |
serverkeygen
|
EST server supports serverkeygen (Section 8.4) |
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 Section 3.9.¶
Example response:¶
cacerts crli crl csrattrs kemc simpleenroll simplereenroll serverkeygen¶
The csrattrs / att operation returns a C509CertificationRequestTemplate that an EST client MAY use to construct a C509 CSR.¶
The EST client sends a GET request for the CSR template. No request body is sent.¶
Method: GET HTTP Request target: /.well-known/est/<label>/csrattrs CoAP Request target: /.well-known/est/<label>/att¶
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 [I-D.ietf-cose-cbor-encoded-cert].¶
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 Section 3.9.¶
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 [I-D.ietf-cose-cbor-encoded-cert] and [I-D.liao-cose-c509-revocation]):¶
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)¶
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).¶
Method: GET
HTTP request target: /.well-known/est/<label>/cacerts
(Accept: <accepted media type>)
CoAP request target: /.well-known/est/<label>/crts
(Accept=<accepted Content-Format>)
¶
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 [RFC9810], Section 4.4; 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 [RFC9810], Section 4.4 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 [RFC9810], Section 4.4 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 Section 3.9.¶
The crli and crl operations provide C509 CRL access. The C509 CRL format is defined in [I-D.liao-cose-c509-revocation].¶
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 [I-D.liao-cose-c509-revocation].¶
The EST client sends a GET request for CRL metadata. No request body is sent.¶
Method: GET
Request target: /.well-known/est/<label>/crli
[?crlnumber=<n>][&crldp=<dp>]
¶
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 [I-D.ietf-cose-cbor-encoded-cert]). The value is the URI of the distribution point, percent-encoded as specified in Section 2.1 of [RFC3986]. 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>.¶
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 [I-D.liao-cose-c509-revocation].¶
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 Section 3.9.¶
The crl operation returns the C509 CRL for the target CA.¶
The EST client sends a GET request for the C509 CRL. No request body is sent.¶
Method: GET
Request target: /.well-known/est/<label>/crl
[?crlnumber=<n>][&crldp=<dp>]
¶
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 (Section 7.1.1). 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 (Section 7.1.1).¶
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 [I-D.liao-cose-c509-revocation].¶
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 Section 3.9.¶
The kemc operation requests a KEM-based Proof-of-Possession challenge for a submitted C509 public key whose subjectPublicKeyAlgorithm is a KEM algorithm.¶
An authenticated EST client sends a POST request containing a C509SubjectPublicKeyInfo ([I-D.liao-cose-c509-additions]) to request a KEM challenge.¶
Method: POST
Request target: /.well-known/est/<label>/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).¶
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 (Section 4.3.1).¶
A client that receives a C509KemChall decapsulates the shared secret key, computes the PoP MAC as specified in Section 4.3.1.3, 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 Section 4.3.1.4 and issues the certificate on success.¶
The simpleenroll / sen operation requests issuance of a new C509 certificate from the EST server.¶
An authenticated EST client sends a POST request containing a C509 CSR (Section 4).¶
Method: POST
HTTP Request target: /.well-known/est/<label>/simpleenroll
CoAP Request target: /.well-known/est/<label>/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 [RFC7030], Section 3.4. 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 Section 4.3.1.¶
The simplereenroll / sren operation renews or rekeys an existing C509 certificate.¶
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 Section 4.2 MAY be included in the CSR to request that these fields be changed in the new certificate.¶
Method: POST
HTTP Request target: /.well-known/est/<label>/simplereenroll
CoAP Request target: /.well-known/est/<label>/sren
Media type: application/cose-c509-pkcs10+cbor (HTTP) /
Content-Format TBD (CoAP)
Body: C509CertificationRequest
¶
Re-enrollment processing follows [RFC7030], Section 4.2.2. 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 Section 4.3.1.¶
The serverkeygen / skc operation requests server-side key generation and returns the generated private key and the issued C509 certificate.¶
As discussed in [RFC9148], Section 9, 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.¶
An authenticated EST client sends a POST request containing a C509 CSR. The subjectPublicKeyAlgorithm in the C509 CSR MUST be set to empty-publickey (Section 4.1) 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 [I-D.ietf-cose-cbor-encoded-cert]) 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.¶
Method: POST
HTTP Request target: /.well-known/est/<label>/serverkeygen
CoAP Request target: /.well-known/est/<label>/skc
Media type: application/cose-c509-pkcs10+cbor (HTTP) /
Content-Format TBD (CoAP)
Body: C509CertificationRequest
¶
On success, the EST server returns an HTTP 200 / CoAP 2.05 response with:¶
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 Section 9). The private key is protected only by the TLS or DTLS channel; no additional encryption is applied.¶
The security requirements of [RFC7030] apply in full to all operations defined in this document.¶
All operations defined in this document MUST be carried out over HTTPS (HTTP over TLS) or secure CoAP (CoAP over DTLS) as required by [RFC7030], Section 3 and [RFC9148]. Implementations MUST NOT fall back to plain HTTP or unsecured CoAP.¶
EST clients and servers SHOULD use C509 certificates [I-D.ietf-cose-cbor-encoded-cert] 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 [RFC5280] for TLS or DTLS client authentication for interoperability with clients that do not yet support C509.¶
All operations MUST require client authentication (see Section 3.1).¶
The serverkeygen / skc operation delivers a generated private key to the EST client over TLS or DTLS (see Section 8.4). 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.¶
EST clients MUST validate received C509 certificates against an independently configured trust anchor according to [I-D.ietf-cose-cbor-encoded-cert].¶
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 [I-D.liao-cose-c509-revocation]. 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.¶
The KEM PoP mechanism (Section 4.3.1) follows the key confirmation specified in Section 4.4 of [NIST.SP.800-227]. 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 [NIST.SP.800-227].¶
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 Section 9.1).¶
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 [I-D.ietf-cose-cbor-encoded-cert]:¶
| 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 |
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 [I-D.ietf-cose-cbor-encoded-cert]:¶
| 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 |
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 [I-D.ietf-cose-cbor-encoded-cert]:¶
+-------+-----------------------------------------------------------+ | Value | CR Attribute | +=======+===========================================================+ | TBD5 | Name: CMC Change Subject Name | | | Identifiers: id-cmc-changeSubjectName | | | OID: 1.3.6.1.5.5.7.7.36 | | | DER: 06 08 2B 06 01 05 05 07 07 24 | | | Comments: RFC 6402 | | | attributeValue: C509ChangeSubjectName | +-------+-----------------------------------------------------------+ | TBD8 | Name: KEM PoP Nonce | | | Identifiers: N/A | | | OID: N/A | | | DER: N/A | | | Comments: Nonce for the KEM proof of possession | | | in C509 CSRs (RFC XXXX) | | | attributeValue: C509KemPopNonce | +-------+-----------------------------------------------------------+
IANA is requested to register the following media type in the "Media Types" registry.¶
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 Section 9 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 [RFC9277], Section 2.2)¶
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¶
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".¶
+----------------------+---------+-----------+-------+------------+ | Content | Content | Media | ID | Reference | | Format | Coding | Type | | | +======================+=========+===========+=======+============+ | application/ | - | RFC XXXX | TBD7 | RFC XXXX | | c509-kemchall+cbor | | | | | +----------------------+---------+-----------+-------+------------+
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":¶
| 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.¶
EST Client EST Server | | | Method: GET | | Request target: /.well-known/est/<label>/caps | |---------------------------------------------->| | | | Status: 200 OK | | Media type: text/plain;charset=utf-8 | | | | <CR-LF separated list of supported | | operations> | |<----------------------------------------------| | |
EST Client EST Server | | | Method: GET | | Request target: /.well-known/est/<label>/cacerts | | Accept: application/cose-c509-cert+cbor | |------------------------------------------------->| | | | Status: 200 OK | | Media type: application/cose-c509-cert+cbor | | | | <Base64-encoded C509Certificate> | |<-------------------------------------------------| | |
EST Client EST Server | | | Method: GET | | Request target: /.well-known/est/<label>/cacerts | |------------------------------------------------->| | | | Status: 200 OK | | Media type: application/cose-c509+cbor | | | | <Base64-encoded COSE_C509> | |<-------------------------------------------------| | |
EST Client EST Server | | | Method: GET | | Request target: /.well-known/est/<label>/cacerts | | Accept: application/cose-c509+cbor; | | usage=chain | |------------------------------------------------->| | | | Status: 200 OK | | Media type: application/cose-c509+cbor; | | usage=chain | | | | <Base64-encoded COSE_C509> | |<-------------------------------------------------| | |
EST Client EST Server | | | Method: GET | | Request target: /.well-known/est/<label>/crli | | [?crlnumber=<n>][&crldp=<dp>] | |----------------------------------------------->| | | | Status: 200 OK | | Media type: application/c509-crlinfo+cbor | | | | <Base64-encoded C509CRLInfo> | |<-----------------------------------------------| | |
EST Client EST Server | | | Method: GET | | Request target: /.well-known/est/<label>/crl | | [?crlnumber=<n>][&crldp=<dp>] | |----------------------------------------------->| | | | Status: 200 OK | | Media type: application/c509-crl+cbor | | | | <Base64-encoded C509CRL> | |<-----------------------------------------------| | |
EST Client EST Server | | | [TLS client certificate] | | | | Method: POST | | Request target: /.well-known/est/<label>/kemc | | Media type: application/cose-c509-pubkey+cbor | | | | <Base64-encoded C509SubjectPublicKeyInfo> | |----------------------------------------------->| | | | | | Status: 200 OK | | Media type: application/c509-kemchall+cbor | | | | <Base64-encoded C509KemChall> | |<-----------------------------------------------| | |
EST Client EST Server | | | [TLS client certificate] | | | | Method: POST | | Request target: /.well-known/est/<label> | | /simpleenroll | | Media type: application/cose-c509-pkcs10+cbor | | | | <Base64-encoded C509CertificationRequest> | |----------------------------------------------->| Verify PoP, | | Issue C509 | | cert | Status: 200 OK | | Media type: application/cose-c509-cert+cbor | | | | <Base64-encoded C509Certificate> | |<-----------------------------------------------| | |
EST Client EST Server | | | [TLS client certificate] | | | | Method: POST | | Request target: /.well-known/est/<label> | | /simplereenroll | | Media type: application/cose-c509-pkcs10+cbor | | | | <Base64-encoded C509CertificationRequest> | |----------------------------------------------->| Verify PoP, | | Issue C509 | | cert | Status: 200 OK | | Media type: application/cose-c509-cert+cbor | | | | <Base64-encoded C509Certificate> | |<-----------------------------------------------| | |
EST Client EST Server | | | [TLS client certificate] | | | | Method: POST | | Request target: /.well-known/est/<label> | | /serverkeygen | | Media type: application/cose-c509-pkcs10+cbor | | | | <Base64-encoded C509 CSR (no public key)> | |----------------------------------------------->| | | Generate | | keypair, | | Issue C509 | Status: 200 OK | cert, Delete | Media type: application/cose-c509-pem+cbor | key from server | | | <Base64-encoded C509PEM> | |<-----------------------------------------------| | (key no longer on EST server) | | |
EST Client EST Server
| |
| GET example.com/.well-known/est/<label>/crts |
| (Accept: TBD) |
|---------------------------------------------->|
| |
| 2.05 Content (Content-Format: TBD) |
| { payload with CBOR-encoded C509Certificate |
| in binary format } |
|<----------------------------------------------|
| |
EST Client EST Server
| |
| GET example.com/.well-known/est/<label>/crts |
|---------------------------------------------->|
| |
| 2.05 Content (Content-Format: TBD) |
| { payload with CBOR-encoded COSE_C509 |
| (certificate set) in binary format } |
|<----------------------------------------------|
| |
EST Client EST Server
| |
| GET example.com/.well-known/est/<label>/crts |
| (Accept: TBD) |
|---------------------------------------------->|
| |
| 2.05 Content (Content-Format: TBD) |
| { payload with CBOR-encoded COSE_C509 |
| (certificate chain) in binary format } |
|<----------------------------------------------|
| |
EST Client EST Server
| |
| GET example.com/.well-known/est/<label>/crli |
| [?crlnumber=<n>][&crldp=<dp>] |
|---------------------------------------------->|
| |
| 2.05 Content (Content-Format: TBD) |
| { payload with CBOR-encoded C509CRLInfo |
| in binary format } |
|<----------------------------------------------|
| |
EST Client EST Server
| |
| GET example.com/.well-known/est/<label>/crl |
| [?crlnumber=<n>][&crldp=<dp>] |
|---------------------------------------------->|
| |
| 2.05 Content (Content-Format: TBD) |
| { payload with CBOR-encoded C509CRL |
| in binary format } |
|<----------------------------------------------|
| |
EST Client EST Server
| |
| POST example.com/.well-known/est/<label>/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 } |
|<-----------------------------------------------|
| |
EST Client EST Server
| |
| POST example.com/.well-known/est/<label>/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 } |
|<----------------------------------------------|
| |
EST Client EST Server
| |
| POST example.com/.well-known/est/<label>/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 } |
|<----------------------------------------------|
| |
EST Client EST Server
| |
| POST example.com/.well-known/est/<label>/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 } |
|<-----------------------------------------------|
| |
The author thanks the members of the ACE and COSE working groups for reviewing and commenting on intermediate versions of this draft.¶
RFC Editor's Note: Please remove this section prior to publication of a final version of this document.¶
Use C509SubjectPublicKeyInfo defined in [I-D.liao-cose-c509-additions] 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 [NIST.SP.800-227]: 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 [RFC8951] 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.¶