EST for C509 Certificates
draft-liao-ace-est-c509-03
This document is an Internet-Draft (I-D).
Anyone may submit an I-D to the IETF.
This I-D is not endorsed by the IETF and has no formal standing in the
IETF standards process.
| Document | Type | Active Internet-Draft (individual) | |
|---|---|---|---|
| Author | Lijun Liao | ||
| Last updated | 2026-07-19 | ||
| RFC stream | (None) | ||
| Intended RFC status | (None) | ||
| Formats | |||
| Stream | Stream state | (No stream defined) | |
| Consensus boilerplate | Unknown | ||
| RFC Editor Note | (None) | ||
| IESG | IESG state | I-D Exists | |
| Telechat date | (None) | ||
| Responsible AD | (None) | ||
| Send notices to | (None) |
draft-liao-ace-est-c509-03
Network Working Group L. Liao
Internet-Draft NIO
Intended status: Standards Track 19 July 2026
Expires: 20 January 2027
EST for C509 Certificates
draft-liao-ace-est-c509-03
Abstract
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 Certificate Revocation List
(CRL) distribution.
About This Document
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.
Status of This Memo
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/.
Liao Expires 20 January 2027 [Page 1]
Internet-Draft EST-C509 July 2026
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 20 January 2027.
Copyright Notice
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.
Table of Contents
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 4
2. Conventions and Definitions . . . . . . . . . . . . . . . . . 7
3. Protocol Design . . . . . . . . . . . . . . . . . . . . . . . 8
3.1. Client Authentication . . . . . . . . . . . . . . . . . . 8
3.2. Discovery and URIs . . . . . . . . . . . . . . . . . . . 8
3.3. EST URL Structure and Path Components . . . . . . . . . . 9
3.4. Channel Binding . . . . . . . . . . . . . . . . . . . . . 9
3.5. Message Binding . . . . . . . . . . . . . . . . . . . . . 9
3.6. Message Fragmentation . . . . . . . . . . . . . . . . . . 9
3.7. Delayed Responses . . . . . . . . . . . . . . . . . . . . 10
3.8. Response Cache . . . . . . . . . . . . . . . . . . . . . 10
3.9. CBOR Transfer . . . . . . . . . . . . . . . . . . . . . . 10
4. C509 Certification Request (C509 CSR) . . . . . . . . . . . . 11
4.1. empty-publickey Algorithm . . . . . . . . . . . . . . . . 12
4.2. CRAttribute C509ChangeSubjectName . . . . . . . . . . . . 12
4.3. Proof of Possession . . . . . . . . . . . . . . . . . . . 13
4.3.1. C509PublicKey . . . . . . . . . . . . . . . . . . . . 13
4.3.2. Proof of Possession for KEM Private Keys . . . . . . 13
5. EST Operations for Server Capability Discovery . . . . . . . 15
5.1. caps . . . . . . . . . . . . . . . . . . . . . . . . . . 15
5.1.1. Request . . . . . . . . . . . . . . . . . . . . . . . 15
5.1.2. Response . . . . . . . . . . . . . . . . . . . . . . 15
5.2. csrattrs / att . . . . . . . . . . . . . . . . . . . . . 16
5.2.1. Request . . . . . . . . . . . . . . . . . . . . . . . 17
5.2.2. Response . . . . . . . . . . . . . . . . . . . . . . 17
Liao Expires 20 January 2027 [Page 2]
Internet-Draft EST-C509 July 2026
6. EST Operations for Distribution of CA Certificates . . . . . 17
6.1. cacerts / crts . . . . . . . . . . . . . . . . . . . . . 17
6.1.1. Request . . . . . . . . . . . . . . . . . . . . . . . 18
6.1.2. Response . . . . . . . . . . . . . . . . . . . . . . 18
7. EST Operations for Distribution of C509 CRLs . . . . . . . . 19
7.1. crli . . . . . . . . . . . . . . . . . . . . . . . . . . 19
7.1.1. Request . . . . . . . . . . . . . . . . . . . . . . . 19
7.1.2. Response . . . . . . . . . . . . . . . . . . . . . . 20
7.2. crl . . . . . . . . . . . . . . . . . . . . . . . . . . . 20
7.2.1. Request . . . . . . . . . . . . . . . . . . . . . . . 20
7.2.2. Response . . . . . . . . . . . . . . . . . . . . . . 21
8. EST Operations for Certificate Enrollment . . . . . . . . . . 21
8.1. kemc . . . . . . . . . . . . . . . . . . . . . . . . . . 21
8.1.1. Request . . . . . . . . . . . . . . . . . . . . . . . 21
8.1.2. Response . . . . . . . . . . . . . . . . . . . . . . 21
8.2. simpleenroll / sen . . . . . . . . . . . . . . . . . . . 22
8.2.1. Request . . . . . . . . . . . . . . . . . . . . . . . 22
8.2.2. Response . . . . . . . . . . . . . . . . . . . . . . 22
8.3. simplereenroll / sren . . . . . . . . . . . . . . . . . . 22
8.3.1. Request . . . . . . . . . . . . . . . . . . . . . . . 23
8.3.2. Response . . . . . . . . . . . . . . . . . . . . . . 23
8.4. serverkeygen / skc . . . . . . . . . . . . . . . . . . . 23
8.4.1. Request . . . . . . . . . . . . . . . . . . . . . . . 24
8.4.2. Response . . . . . . . . . . . . . . . . . . . . . . 24
9. Security Considerations . . . . . . . . . . . . . . . . . . . 24
9.1. Transport Security . . . . . . . . . . . . . . . . . . . 24
9.1.1. TLS Certificate Type Negotiation . . . . . . . . . . 25
9.1.2. Client Authentication . . . . . . . . . . . . . . . . 25
9.2. Server Key Generation . . . . . . . . . . . . . . . . . . 25
9.3. C509 Certificate Validation . . . . . . . . . . . . . . . 25
10. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 25
10.1. C509 Public Key Algorithms Registry . . . . . . . . . . 26
10.2. C509 Signature Algorithms Registry . . . . . . . . . . . 26
10.3. C509 CR Attributes Registry . . . . . . . . . . . . . . 27
10.3.1. Media Type application/c509-pubkey+cbor . . . . . . 27
10.3.2. Media Type application/c509-kemchall+cbor . . . . . 28
10.4. CoAP Content-Formats Registry . . . . . . . . . . . . . 29
11. References . . . . . . . . . . . . . . . . . . . . . . . . . 30
11.1. Normative References . . . . . . . . . . . . . . . . . . 30
11.2. Informative References . . . . . . . . . . . . . . . . . 32
Appendix A. Message Flow Diagrams of EST over HTTPS
Operations . . . . . . . . . . . . . . . . . . . . . . . 32
A.1. caps . . . . . . . . . . . . . . . . . . . . . . . . . . 32
A.2. cacerts for single CA certificate . . . . . . . . . . . . 32
A.3. cacerts for CA certificate set . . . . . . . . . . . . . 33
A.4. cacerts for CA certificate chain . . . . . . . . . . . . 33
A.5. crli . . . . . . . . . . . . . . . . . . . . . . . . . . 33
A.6. crl . . . . . . . . . . . . . . . . . . . . . . . . . . . 34
Liao Expires 20 January 2027 [Page 3]
Internet-Draft EST-C509 July 2026
A.7. kemc . . . . . . . . . . . . . . . . . . . . . . . . . . 34
A.8. simpleenroll . . . . . . . . . . . . . . . . . . . . . . 35
A.9. simplereenroll . . . . . . . . . . . . . . . . . . . . . 35
A.10. serverkeygen . . . . . . . . . . . . . . . . . . . . . . 36
Appendix B. Message Flow Diagrams of EST over CoAP/DTLS
Operations . . . . . . . . . . . . . . . . . . . . . . . 37
B.1. cacerts for single CA certificate . . . . . . . . . . . . 37
B.2. cacerts for CA certificate set . . . . . . . . . . . . . 37
B.3. cacerts for CA certificate chain . . . . . . . . . . . . 37
B.4. crli . . . . . . . . . . . . . . . . . . . . . . . . . . 38
B.5. crl . . . . . . . . . . . . . . . . . . . . . . . . . . . 38
B.6. kemc . . . . . . . . . . . . . . . . . . . . . . . . . . 38
B.7. sen . . . . . . . . . . . . . . . . . . . . . . . . . . . 39
B.8. sren . . . . . . . . . . . . . . . . . . . . . . . . . . 39
B.9. skc . . . . . . . . . . . . . . . . . . . . . . . . . . . 40
Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . . 40
Change log . . . . . . . . . . . . . . . . . . . . . . . . . . . 40
Since draft-liao-ace-est-c509-02 . . . . . . . . . . . . . . . 40
Since draft-liao-ace-est-c509-01 . . . . . . . . . . . . . . . 41
Author's Address . . . . . . . . . . . . . . . . . . . . . . . . 41
1. Introduction
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.
Liao Expires 20 January 2027 [Page 4]
Internet-Draft EST-C509 July 2026
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 do not require a
CBOR parser or generator:
* 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 key device to get the public key (C509PublicKey) and the
certification request (C509CertificationRequest) after receiving
the KEM challenge object (C509KemChall) from the EST server; in
this case, the EST client considers the C509PublicKey,
C509KemChall, and C509CertificationRequest 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 to persistent memory without parsing. This property
makes the EST client implementation extremely 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 are (those
wit new marked are new operations defined in this document) in
Figure 1, and for EST over CoAP in Figure 2.
Liao Expires 20 January 2027 [Page 5]
Internet-Draft EST-C509 July 2026
+==========+===+=============+==============+===================+
| 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 |
| | | | | - 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 | c509-pubkey | c509-kemchall |
| | | issuance | +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 |
+----------+---+-------------+--------------+-------------------+
Figure 1: Operations for EST over CoAP/DTLS Used in This Document
(M/O: MANDDATORY / OPTIONAL)
Liao Expires 20 January 2027 [Page 6]
Internet-Draft EST-C509 July 2026
+===============+================+=====+==========+==========+
| EST over | Corresponding | M/O | Request | Response |
| CoAP/DTLS | EST over HTTPS | | Content- | Content- |
| Operation | Operation | | Format | Format |
+===============+================+=====+==========+==========+
| (Not Related) | | | | |
+---------------+----------------+-----+----------+----------+
| 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 |
+---------------+----------------+-----+----------+----------+
Figure 2: Operations for EST over CoAP/DTLS Used in This Document
(M/O: MANDDATORY / OPTIONAL)
2. 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 [RFC2119] [RFC8174] 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 [RFC7030],
Section 1.
EST server: The entity that processes EST requests, typically acting
as an RA between the EST client and the CA, as defined in
[RFC7030], Section 1.
CA: Certification Authority. The entity that issues C509
Liao Expires 20 January 2027 [Page 7]
Internet-Draft EST-C509 July 2026
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.
3. Protocol Design
3.1. Client Authentication
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
require the use of 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].
3.2. Discovery and URIs
In EST over HTTPS, the capabilities of EST server is retrieved by
using the operation caps.
In EST over CoAP/DTLS, the capabilities is retrieved by sending a GET
method to the EST server (as in Section 4.1 of [RFC9148]) (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]). Linefeeds are included only for
readability.
REQ: GET /.well-known/core?rt=ace.est*
RES: 2.05 Content
</est/crts>;rt="ace.est.crts";ct="TBD TBD TBD",
</est/sen>;rt="ace.est.sen";ct=TBD,
</est/sren>;rt="ace.est.sren";ct=TBD,
</est/att>;rt="ace.est.att";ct=TBD,
</est/skc>;rt="ace.est.skc";ct=TBD,
</est/crli>;rt="ace.est.crli";ct=TBD,
</est/crl>;rt="ace.est.crl";ct=TBD,
</est/kemc>;rt="ace.est.kemc";ct=TBD7
Liao Expires 20 January 2027 [Page 8]
Internet-Draft EST-C509 July 2026
3.3. EST URL Structure and Path Components
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 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.
3.4. Channel Binding
Channel binding is OPTIONAL. The challel binding mechanisms
specified in {RFC7030} and [RFC9148] apply.
3.5. Message Binding
The message binding mechanism specified in [RFC9148], Section 4.4
applies for CoAP in this document.
3.6. Message Fragmentation
The message fragmentation mechanism specified in [RFC9148],
Section 4.6 applies for CoAP in this document.
Liao Expires 20 January 2027 [Page 9]
Internet-Draft EST-C509 July 2026
3.7. Delayed Responses
The mechanism for delayed responses specified in [RFC9148],
Section 4.7 applies for CoAP in this document. And the mechanism
with retry-later for the operarions simpleenroll and simplereenroll
specified in [RFC7030], Section 4.2.3 applies for HTTP in this
document.
3.8. Response Cache
Successful responses, if will not be changed in the next short
period, 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
E-Tag and Max-Age.
3.9. CBOR Transfer
All POST request bodies in this document are CBOR-encoded. For
HTTPS, CBOR-based response bodies are base64-encoded for transport.
For CoAP, CBOR payloads are carried directly in the message body
using the relevant CoAP Content-Format. The CBOR encoding MUST be
deterministic as specified in Sections 4.2.1 and 4.2.2 of [RFC8949].
Servers MUST NOT include a Content-Transfer-Encoding header for CBOR
payloads.
The media types used in this document are:
Liao Expires 20 January 2027 [Page 10]
Internet-Draft EST-C509 July 2026
+=====================+=======+================================+=================================+
|Media Type |CoAP |Structure |Defined in |
| |Content| | |
| |Format | | |
+=====================+=======+================================+=================================+
|application/cose- |TBD |C509Certificate |[I-D.ietf-cose-cbor-encoded-cert]|
|c509-cert+cbor | | | |
+---------------------+-------+--------------------------------+---------------------------------+
|application/cose- |TBD |COSE_C509 |[I-D.ietf-cose-cbor-encoded-cert]|
|c509+cbor | | | |
+---------------------+-------+--------------------------------+---------------------------------+
|application/cose- |TBD |COSE_C509 |[I-D.ietf-cose-cbor-encoded-cert]|
|c509+cbor;usage=chain| | | |
+---------------------+-------+--------------------------------+---------------------------------+
|application/cose- |TBD |C509CertificationRequest |[I-D.ietf-cose-cbor-encoded-cert]|
|c509-pkcs10+cbor | | | |
+---------------------+-------+--------------------------------+---------------------------------+
|application/ |TBD3 |C509PublicKey |this document |
|c509-pubkey+cbor | | | |
+---------------------+-------+--------------------------------+---------------------------------+
|application/ |TBD7 |C509KemChall |this document |
|c509-kemchall+cbor | | | |
+---------------------+-------+--------------------------------+---------------------------------+
|application/cose- |TBD |C509CertificationRequestTemplate|[I-D.ietf-cose-cbor-encoded-cert]|
|c509-crtemplate+cbor | | | |
+---------------------+-------+--------------------------------+---------------------------------+
|application/cose- |TBD |C509PEM (key + certificate) |[I-D.ietf-cose-cbor-encoded-cert]|
|c509-pem+cbor | | | |
+---------------------+-------+--------------------------------+---------------------------------+
|application/ |TBD |C509CRL |[I-D.liao-cose-c509-revocation] |
|c509-crl+cbor | | | |
+---------------------+-------+--------------------------------+---------------------------------+
|application/ |TBD |C509CRLInfo |[I-D.liao-cose-c509-revocation] |
|c509-crlinfo+cbor | | | |
+---------------------+-------+--------------------------------+---------------------------------+
Table 1: Media Types Used in This Document
The caps operation returns text/plain; charset=utf-8 with a list of
capability keywords.
4. 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 [RFC2986] used in standard EST operations.
Liao Expires 20 January 2027 [Page 11]
Internet-Draft EST-C509 July 2026
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-leght 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 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.
4.1. 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.
4.2. CRAttribute C509ChangeSubjectName
The C509ChangeSubjectName for X.509 PKI is defined in [RFC6402]. The
corresponding definition for C509 certification request 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.
Liao Expires 20 January 2027 [Page 12]
Internet-Draft EST-C509 July 2026
4.3. Proof of Possession
simpleenroll / sen and simplereenroll / sren MUST verify the PoP
signature in the C509 CSR before issuing a certificate. The
serverkeygen / skc operation does not require PoP verification
because the EST server generates the key pair itself.
4.3.1. C509PublicKey
A C509PublicKey contains a subject public key in the C509 encoding.
It uses the same field types as TbsCertificate in
[I-D.ietf-cose-cbor-encoded-cert] and is defined as:
C509PublicKey = [
subjectPublicKeyAlgorithm : AlgorithmIdentifier,
subjectPublicKey : Defined
]
The subjectPublicKeyAlgorithm field uses the full AlgorithmIdentifier
encoding as defined in [I-D.ietf-cose-cbor-encoded-cert], without
limitation. The subjectPublicKey field uses the same encoding as in
C509 certificates: for most algorithms it is a CBOR byte string, but
for RSA public keys it is encoded as an array of two unwrapped CBOR
unsigned bignums [~biguint, ~biguint] when the exponent is not 65537,
as specified in [I-D.ietf-cose-cbor-encoded-cert].
The media type of C509PublicKey is application/c509-pubkey+cbor (see
Section 10.3.1); the corresponding CoAP Content-Format is defined in
Section 10.4. The "magic number" is TBD2, using the reserved CBOR
tag 55799 and Content-Format TBD3, as described in [RFC9277],
Section 2.2.
4.3.2. 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.
The recommended KEM PoP flow is:
* Challenge issuance: Upon receipt of a KEM public key
(C509PublicKey) in the kemc operation, an EST server returns a
CBOR-encoded KEM challenge object (C509KemChall) with media type
application/c509-kemchall+cbor.
Liao Expires 20 January 2027 [Page 13]
Internet-Draft EST-C509 July 2026
C509KemChall = [
keyId : bstr,
encapAlg : int,
encapsulation : bstr
]
The media type of C509KemChall is application/c509-kemchall+cbor (see
Section 10.3.2); the corresponding CoAP Content-Format is defined in
Section 10.4. The "magic number" is TBD6, using the reserved CBOR
tag 55799 and Content-Format TBD7, as described in [RFC9277],
Section 2.2.
In particular (TBD: check consistency with [NIST.SP.800-227]):
* keyId is the SHA-256 fingerprint of the CBOR-encoded
C509PublicKey,
* encapAlg is the encapsulation algorithm (TBD: define a new
registry or reuse a COSE algorithm), and
* encapsulation is the KEM ciphertext produced by encapsulating a
freshly generated one-time secret key K to the client's KEM public
key.
The server MUST retain the challenge state (at least keyId, K, and
the lifetime) for the duration of the challenge.
* Client decapsulation and response: The client decapsulates
encapsulation to recover the one-time secret key K. The client
computes a MAC value over the TBSCertificationRequest with the key
K. The client then submits a follow-up operation as usual.
* Server verification: The server computes the keyId, retrieves the
challenge state for that keyId, and verifies that the state is
still within its validity period. The server then verifies the
received MAC value against the TBSCertificationRequest. The
server proceeds with certificate issuance as for signature-based
PoP. If verification fails or the challenge has expired, the
server MUST reject the request.
Implementations SHOULD use HMAC-SHA256 (with integer value TBD4) by
default, unless constrained by the KEM's security requirements.
Servers MUST enforce challenge timeouts and retry limits to mitigate
replay and denial-of-service risks.
Liao Expires 20 January 2027 [Page 14]
Internet-Draft EST-C509 July 2026
5. EST Operations for Server Capability Discovery
5.1. caps
This operation is only related to EST over HTTPS, but 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.
5.1.1. Request
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
5.1.2. Response
On success, the EST server returns a 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.
Liao Expires 20 January 2027 [Page 15]
Internet-Draft EST-C509 July 2026
+================+==================================================+
| 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) |
+----------------+--------------------------------------------------+
Table 2: caps Keywords Defined in This Document
An EST client that receives an error response to a caps request MUST
NOT attempt the operations defined in this document.
Successful caps responses MAY include caching metadata as specified
in Section 3.8.
Example response:
cacerts
crli
crl
csrattrs
kemc
simpleenroll
simplereenroll
serverkeygen
5.2. csrattrs / att
The csrattrs / att operation returns a
C509CertificationRequestTemplate that an EST client MAY use to
construct a C509 CSR.
Liao Expires 20 January 2027 [Page 16]
Internet-Draft EST-C509 July 2026
5.2.1. Request
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>/attr
5.2.2. Response
On success, the EST server returns a 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].
An 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.8.
6. EST Operations for Distribution of CA Certificates
6.1. cacerts / crts
Successful cacerts / crts responses MAY include caching metadata as
specified in Section 3.8.
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 (HTTP) / Accept=TBD (CoAP):
C509Certificate (a single certificate)
* Accept: application/cose-c509; usage=chain (HTTP) / Accept=TBD
(CoAP): COSE_C509 (certificate chain)
* No Accept or Accept: application/cose-c509 (HTTP) / Accept=TBD
(CoAP): COSE_C509 (certificate set (unsorted certificates))
Liao Expires 20 January 2027 [Page 17]
Internet-Draft EST-C509 July 2026
6.1.1. 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-Formats of the response. If an Accept Option is
not included in the request, the client is not expressing any
preference and the server SHOULD choose format TBD for certificate
set.
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>)
6.1.2. Response
On success, the EST server returns a 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 a single certificate.
* 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.
* 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 an unordered certificate set.
The first element is the issuing CA certificate; subsequent
elements are not sorted. If a Root CA key update applies, the
Liao Expires 20 January 2027 [Page 18]
Internet-Draft EST-C509 July 2026
EST server SHOULD include the four "Root CA Key Update"
certificates OldWithOld, OldWithNew, NewWithOld, and NewWithNew
in the response chain. These are defined in [RFC9810],
Section 4.4.
Successful cacerts / crts responses MAY include caching metadata as
specified in Section 3.8.
7. EST Operations for Distribution of C509 CRLs
The crli and crl operations provide C509 CRL access. The C509 CRL
format is defined in [I-D.liao-cose-c509-revocation].
7.1. 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 [I-D.liao-cose-c509-revocation].
7.1.1. Request
The EST client sends a GET request for CRL metadata. No request body
is sent.
Method: GET
Request target: /.well-known/est/<label>/crli
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 status 404 (Not Found).
When crlnumber is absent, the server returns the C509CRLInfo for the
most recent CRL.
The optional crldp query parameter carries the CRL Distribution Point
identifier. 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.
Liao Expires 20 January 2027 [Page 19]
Internet-Draft EST-C509 July 2026
7.1.2. Response
On success, the EST server returns a 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
compute 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.8.
7.2. crl
The crl operation returns the C509 CRL for the target CA.
7.2.1. Request
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
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 carries the CRL Distribution Point
identifier. 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.
Liao Expires 20 January 2027 [Page 20]
Internet-Draft EST-C509 July 2026
If no matching CRL is available, the EST server MUST return HTTP 404
/ CoAP 4.04 (Not Found).
7.2.2. Response
On success, the EST server returns a 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.8.
8. EST Operations for Certificate Enrollment
8.1. kemc
The kemc operation requests a KEM-based Proof-of-Possession challenge
for a submitted C509 public key whose subjectPublicKeyAlgorithm is a
KEM algorithm.
8.1.1. Request
An authenticated EST client sends a POST request containing a
C509PublicKey (Section 4.3.1) to request a KEM challenge.
Method: POST
Request target: /.well-known/est/<label>/kemc
Media type: application/c509-pubkey+cbor (HTTP)/ Content-Format TBD (CoAP)
Body: C509PublicKey
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).
8.1.2. Response
On success, the EST server returns a HTTP 200 / CoAP 2.05 response
with:
Liao Expires 20 January 2027 [Page 21]
Internet-Draft EST-C509 July 2026
* Media type: application/c509-kemchall+cbor (HTTP) / Content-Format
TBD7 (CoAP)
* Body: A C509KemChall (Section 4.3.2).
A client that receives a C509KemChall uses the recovered one-time
secret key to produce the PoP MAC and then proceeds with a normal
enrollment request (simpleenroll / sen or simplereenroll / sren)
including the computed MAC in the request (see Section 4.3.2 for the
PoP flow). The EST server verifies the MAC using the stored
challenge state and issues the certificate on success.
8.2. simpleenroll / sen
The simpleenroll / sen operation requests issuance of a new C509
certificate from the EST server.
8.2.1. Request
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.
8.2.2. Response
On success, the EST server returns a 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 [I-D.ietf-cose-cbor-encoded-cert].
8.3. simplereenroll / sren
The simplereenroll / sren operation renews or rekeys an existing C509
certificate.
Liao Expires 20 January 2027 [Page 22]
Internet-Draft EST-C509 July 2026
8.3.1. 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 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.
8.3.2. Response
On success, the EST server returns a 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
[I-D.ietf-cose-cbor-encoded-cert].
8.4. 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 [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.
Liao Expires 20 January 2027 [Page 23]
Internet-Draft EST-C509 July 2026
8.4.1. Request
An authenticated EST client sends a POST request containing a C509
CSR. The subjectPublicKeyAlgorithm in the C509 CSR SHOULD be set to
empty-publickey (Section 4.1) and subjectPublicKey SHOULD be a zero-
length byte string (h''), because the key pair is generated by the
EST server. The signatureAlgorithm SHOULD be the id-alg-unsigned
integer code and signatureValue SHOULD 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
8.4.2. Response
On success, the EST server returns a 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 Section 9). The private key is protected only by the
TLS channel; no additional encryption is applied.
9. Security Considerations
The security requirements of [RFC7030] apply in full to all
operations defined in this document.
9.1. 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
[RFC7030], Section 3 and [RFC9148]. Implementations MUST NOT fall
back to plain HTTP or unsecured CoAP.
Liao Expires 20 January 2027 [Page 24]
Internet-Draft EST-C509 July 2026
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.
9.1.1. TLS Certificate Type Negotiation
When C509 certificates are used for TLS authentication, the client
and server negotiate the certificate type using the
server_certificate_type and client_certificate_type TLS extensions as
defined in [RFC7250].
9.1.2. Client Authentication
All operations MUST require client authentication.
9.2. Server Key Generation
The skc operation delivers a generated private key to the EST client
over TLS. EST servers SHOULD delete the private key after successful
transmission. EST clients MUST store the key material securely
immediately upon receipt.
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.
9.3. C509 Certificate Validation
EST clients MUST validate received C509 certificates against an
independently configured trust anchor according to
[I-D.ietf-cose-cbor-encoded-cert]. The trust model for C509
certificates differs from classical X.509 certificate chain
validation when C509 is used in the HyPKI trust architecture; in that
case, validation uses the cosigner-signed Merkle tree or signed
allowlist rather than a certificate chain.
10. IANA Considerations
Liao Expires 20 January 2027 [Page 25]
Internet-Draft EST-C509 July 2026
10.1. 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 [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 |
+-------------+--------------------------------------------------+
Table 3: empty-publickey Registration
10.2. 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 [I-D.ietf-cose-cbor-encoded-cert]:
Liao Expires 20 January 2027 [Page 26]
Internet-Draft EST-C509 July 2026
+=============+===============================+
| Field | Value |
+=============+===============================+
| Value | TBD4 |
+-------------+-------------------------------+
| Name | hmacWithSHA256 |
+-------------+-------------------------------+
| Identifiers | id-hmacWithSHA256 |
+-------------+-------------------------------+
| OID | 1.2.840.113549.2.9 |
+-------------+-------------------------------+
| Parameters | N/A |
+-------------+-------------------------------+
| OID | 06 08 2A 86 48 86 F7 0D 02 09 |
+-------------+-------------------------------+
| Comments | HMAC over SHA256 |
+-------------+-------------------------------+
| Reference | This document |
+-------------+-------------------------------+
Table 4: HMAC-SHA256 Registration
10.3. C509 CR Attributes Registry
IANA is requested to register the following entry 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 |
+-------+-----------------------------------------------------------+
10.3.1. Media Type application/c509-pubkey+cbor
When the application/c509-pubkey+cbor media type is used, the payload
is a C509PublicKey structure.
Type name: application
Subtype name: c509-pubkey+cbor
Liao Expires 20 January 2027 [Page 27]
Internet-Draft EST-C509 July 2026
Required parameters: N/A
Optional parameters: N/A
Encoding considerations: binary
Security considerations: See the Security Considerations section of
[[this document]].
Interoperability considerations: N/A
Published specification: [[this document]]
Applications that use this media type: Applications that employ C509
public keys.
Fragment identifier considerations: N/A
Additional information:
* Deprecated alias names for this type: N/A
* Magic number(s): TBD2
* 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
10.3.2. 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
Liao Expires 20 January 2027 [Page 28]
Internet-Draft EST-C509 July 2026
Required parameters: N/A
Optional parameters: N/A
Encoding considerations: binary
Security considerations: See the Security Considerations section of
[[this document]].
Interoperability considerations: N/A
Published specification: [[this document]]
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
* 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
10.4. CoAP Content-Formats Registry
IANA is requested to add entries for application/c509-pubkey+cbor and
application/c509-kemchall+cbor to the "CoAP Content-Formats" registry
in the registry group "Constrained RESTful Environments (CoRE)
Parameters".
Liao Expires 20 January 2027 [Page 29]
Internet-Draft EST-C509 July 2026
+----------------------+---------+-----------+-------+------------+
| Content | Content | Media | ID | Reference |
| Format | Coding | Type | | |
+======================+=========+===========+=======+============+
| application/ | - | [[link | TBD3 | [[this |
| c509-pubkey+cbor | | to x.y]] | | document]] |
+----------------------+---------+-----------+-------+------------+
| application/ | - | [[link | TBD7 | [[this |
| c509-kemchall+cbor | | to x.y]] | | document]] |
+----------------------+---------+-----------+-------+------------+
Figure 3: CoAP Content-Format IDs
11. References
11.1. Normative References
[I-D.ietf-cose-cbor-encoded-cert]
Mattsson, J. P., Selander, G., Raza, S., Höglund, J.,
Furuhed, M., and L. Liao, "CBOR Encoded X.509 Certificates
(C509 Certificates)", Work in Progress, Internet-Draft,
draft-ietf-cose-cbor-encoded-cert-20, 30 June 2026,
<https://datatracker.ietf.org/doc/html/draft-ietf-cose-
cbor-encoded-cert-20>.
[I-D.liao-cose-c509-revocation]
Liao, L., Tiloca, M., Höglund, J., Höglund, R., and S.
Raza, "CBOR Encoded Certificate Revocation Management",
Work in Progress, Internet-Draft, draft-liao-cose-c509-
revocation-00, 6 July 2026,
<https://datatracker.ietf.org/doc/html/draft-liao-cose-
c509-revocation-00>.
[NIST.SP.800-227]
Alagic, G., Barker, E., Chen, L., Moody, D., Roginsky, A.,
Silberg, H., and N. Waller, "Recommendation for Key-
Encapsulation Mechanisms", NIST Special Publication
800-227, September 2025,
<https://doi.org/10.6028/NIST.SP.800-227>.
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
Requirement Levels", BCP 14, RFC 2119,
DOI 10.17487/RFC2119, March 1997,
<https://www.rfc-editor.org/rfc/rfc2119>.
Liao Expires 20 January 2027 [Page 30]
Internet-Draft EST-C509 July 2026
[RFC5280] Cooper, D., Santesson, S., Farrell, S., Boeyen, S.,
Housley, R., and W. Polk, "Internet X.509 Public Key
Infrastructure Certificate and Certificate Revocation List
(CRL) Profile", RFC 5280, DOI 10.17487/RFC5280, May 2008,
<https://www.rfc-editor.org/rfc/rfc5280>.
[RFC5652] Housley, R., "Cryptographic Message Syntax (CMS)", STD 70,
RFC 5652, DOI 10.17487/RFC5652, September 2009,
<https://www.rfc-editor.org/rfc/rfc5652>.
[RFC6402] Schaad, J., "Certificate Management over CMS (CMC)
Updates", RFC 6402, DOI 10.17487/RFC6402, November 2011,
<https://www.rfc-editor.org/rfc/rfc6402>.
[RFC7030] Pritikin, M., Ed., Yee, P., Ed., and D. Harkins, Ed.,
"Enrollment over Secure Transport", RFC 7030,
DOI 10.17487/RFC7030, October 2013,
<https://www.rfc-editor.org/rfc/rfc7030>.
[RFC7250] Wouters, P., Ed., Tschofenig, H., Ed., Gilmore, J.,
Weiler, S., and T. Kivinen, "Using Raw Public Keys in
Transport Layer Security (TLS) and Datagram Transport
Layer Security (DTLS)", RFC 7250, DOI 10.17487/RFC7250,
June 2014, <https://www.rfc-editor.org/rfc/rfc7250>.
[RFC8174] Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC
2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174,
May 2017, <https://www.rfc-editor.org/rfc/rfc8174>.
[RFC8949] Bormann, C. and P. Hoffman, "Concise Binary Object
Representation (CBOR)", STD 94, RFC 8949,
DOI 10.17487/RFC8949, December 2020,
<https://www.rfc-editor.org/rfc/rfc8949>.
[RFC9148] van der Stok, P., Kampanakis, P., Richardson, M., and S.
Raza, "EST-coaps: Enrollment over Secure Transport with
the Secure Constrained Application Protocol", RFC 9148,
DOI 10.17487/RFC9148, April 2022,
<https://www.rfc-editor.org/rfc/rfc9148>.
[RFC9277] Richardson, M. and C. Bormann, "On Stable Storage for
Items in Concise Binary Object Representation (CBOR)",
RFC 9277, DOI 10.17487/RFC9277, August 2022,
<https://www.rfc-editor.org/rfc/rfc9277>.
Liao Expires 20 January 2027 [Page 31]
Internet-Draft EST-C509 July 2026
[RFC9810] Brockhaus, H., von Oheimb, D., Ounsworth, M., and J. Gray,
"Internet X.509 Public Key Infrastructure -- Certificate
Management Protocol (CMP)", RFC 9810,
DOI 10.17487/RFC9810, July 2025,
<https://www.rfc-editor.org/rfc/rfc9810>.
11.2. Informative References
[RFC2986] Nystrom, M. and B. Kaliski, "PKCS #10: Certification
Request Syntax Specification Version 1.7", RFC 2986,
DOI 10.17487/RFC2986, November 2000,
<https://www.rfc-editor.org/rfc/rfc2986>.
Appendix A. Message Flow Diagrams of EST over HTTPS Operations
A.1. caps
EST Client EST Server
| |
| Method: GET |
| Request target: /.well-known/est/<p>/caps |
|--------------------------------------------->|
| |
| Status: 200 OK |
| Media type: text/plain;charset=utf-8 |
| |
| <CR-LF seperated list of supported |
| operations> |
|<---------------------------------------------|
| |
Figure 4: HTTP cacerts message flow
A.2. cacerts for single CA certificate
EST Client EST Server
| |
| Method: GET |
| Request target: /.well-known/est/<p>/cacerts |
| Accept: application/cose-c509-cert |
|--------------------------------------------->|
| |
| Status: 200 OK |
| Media type: application/cose-c509+cbor |
| |
| <Base64-encoded COSE_C509> |
|<---------------------------------------------|
| |
Liao Expires 20 January 2027 [Page 32]
Internet-Draft EST-C509 July 2026
Figure 5: Message flow of EST over HTTPS operation cacerts for
single CA certificate
A.3. cacerts for CA certificate set
EST Client EST Server
| |
| Method: GET |
| Request target: /.well-known/est/<p>/cacerts |
|--------------------------------------------->|
| |
| Status: 200 OK |
| Media type: application/cose-c509+cbor |
| |
| <Base64-encoded COSE_C509> |
|<---------------------------------------------|
| |
Figure 6: Message flow of EST over HTTPS operation cacerts for CA
certificate set
A.4. cacerts for CA certificate chain
EST Client EST Server
| |
| Method: GET |
| Request target: /.well-known/est/<p>/cacerts |
| Accept: application/cose-c509; usage=chain |
|--------------------------------------------->|
| |
| Status: 200 OK |
| Media type: application/cose-c509+cbor |
| |
| <Base64-encoded COSE_C509> |
|<---------------------------------------------|
| |
Figure 7: Message flow of EST over HTTPS cacerts for CA
certificate chain
A.5. crli
Liao Expires 20 January 2027 [Page 33]
Internet-Draft EST-C509 July 2026
EST Client EST Server
| |
| Method: GET |
| Request target: /.well-known/est/<p>/crli |
| [?crlnumber=<n>][&crldp=<dp>] |
|---------------------------------------------->|
| |
| Status: 200 OK |
| Media type: application/c509-crlinfo+cbor |
| |
| <Base64-encoded C509CRLInfo> |
|<----------------------------------------------|
| |
Figure 8: Message flow of EST over HTTPS operation crli
A.6. crl
EST Client EST Server
| |
| Method: GET |
| Request target: /.well-known/est/<p>/crl |
| [?crlnumber=<n>][&crldp=<dp>] |
|---------------------------------------------->|
| |
| Status: 200 OK |
| Media type: application/c509-crl+cbor |
| |
| <Base64-encoded C509CRL> |
|<----------------------------------------------|
| |
Figure 9: Message flow of EST over HTTPS operation crl
A.7. kemc
Liao Expires 20 January 2027 [Page 34]
Internet-Draft EST-C509 July 2026
EST Client EST Server
| |
| [TLS client certificate] |
| |
| Method: POST |
| Request target: /.well-known/est/<p>/kemc |
| Media type: application/c509-pubkey+cbor |
| |
| <Base64-encoded C509PublicKey> |
|---------------------------------------------->|
| |
| |
| Status: 200 OK |
| Media type: application/c509-kemchall+cbor |
| |
| <Base64-encoded C509KemChall> |
|<----------------------------------------------|
| |
Figure 10: Message flow of EST over HTTPS operation kemc
A.8. simpleenroll
EST Client EST Server
| |
| [TLS client certificate] |
| |
| Method: POST |
| Request target: /.well-known/est/<p> |
| /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> |
|<----------------------------------------------|
| |
Figure 11: Message flow of EST over HTTPS operation simpleenroll
A.9. simplereenroll
Liao Expires 20 January 2027 [Page 35]
Internet-Draft EST-C509 July 2026
EST Client EST Server
| |
| [TLS client certificate] |
| |
| Method: POST |
| Request target: /.well-known/est/<p> |
| /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> |
|<----------------------------------------------|
| |
Figure 12: Message flow of EST over HTTPS operation simplereenroll
A.10. serverkeygen
EST Client EST Server
| |
| [TLS client certificate] |
| |
| Method: POST |
| Request target: /.well-known/est/<p> |
| /serverkeygen |
| Media type: application/cose-c509-pkcs10+cbor |
| |
| <CBOR C509 CSR (no pubkey)> |
|---------------------------------------------->|
| | 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) |
| |
Figure 13: Message flow of EST over HTTPS operation serverkeygen
Liao Expires 20 January 2027 [Page 36]
Internet-Draft EST-C509 July 2026
Appendix B. Message Flow Diagrams of EST over CoAP/DTLS Operations
B.1. cacerts for single CA certificate
EST Client EST Server
| |
| GET example.com/est/<p>/cacerts |
| (Accept: TBD) |
|--------------------------------------------->|
| |
| 2.05 Content (Content-Format: TBD) |
| { payload with CBOR-encoded C509Certificate |
| in binary format } |
|<---------------------------------------------|
| |
Figure 14: Message flow of EST over CoAP/DTLS operation cacerts
for single CA certificate
B.2. cacerts for CA certificate set
EST Client EST Server
| |
| Method: GET |
| GET example.com/est/<p>/cacerts |
|--------------------------------------------->|
| |
| 2.05 Content (Content-Format: TBD) |
| { payload with CBOR-encoded COSE_C509 |
| (certificate set) in binary format } |
|<---------------------------------------------|
| |
Figure 15: Message flow of EST over CoAP/DTLS operation cacerts
for CA certificate set
B.3. cacerts for CA certificate chain
Liao Expires 20 January 2027 [Page 37]
Internet-Draft EST-C509 July 2026
EST Client EST Server
| |
| GET example.com/est/<p>/cacerts |
| (Accept: TBD) |
|--------------------------------------------->|
| |
| 2.05 Content (Content-Format: TBD) |
| { payload with CBOR-encoded COSE_C509 |
| (certificate chain) in binary format } |
|<---------------------------------------------|
| |
Figure 16: Message flow of EST over CoAP/DTLS operation cacerts
for CA certificate chain
B.4. crli
EST Client EST Server
| |
| GET example.com/est/<p>/crli |
|--------------------------------------------->|
| |
| 2.05 Content (Content-Format: TBD) |
| { payload with CBOR-encoded C509CRLInfo |
| in binary format } |
|<---------------------------------------------|
| |
Figure 17: Message flow of EST over CoAP/DTLS operation crli
B.5. crl
EST Client EST Server
| |
| GET example.com/est/<p>/crl |
|--------------------------------------------->|
| |
| 2.05 Content (Content-Format: TBD) |
| { payload with CBOR-encoded C509CRL |
| in binary format } |
|<---------------------------------------------|
| |
Figure 18: Message flow of EST over CoAP/DTLS operation crl
B.6. kemc
Liao Expires 20 January 2027 [Page 38]
Internet-Draft EST-C509 July 2026
EST Client EST Server
| |
| POST example.com/est/<p>/kemc |
| (Content-Format: TBD) |
| { payload with CBOR-encoded C509PublicKey |
| in binary format } |
|--------------------------------------------->|
| |
| 2.05 Content (Content-Format: TBD) |
| { payload with CBOR-encoded C509KemChall |
| in binary format } |
|<---------------------------------------------|
| |
Figure 19: Message flow of EST over CoAP/DTLS operation kemc
B.7. sen
EST Client EST Server
| |
| POST example.com/est/<p>/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 } |
|<---------------------------------------------|
| |
Figure 20: Message flow of EST over CoAP/DTLS operation sen
B.8. sren
Liao Expires 20 January 2027 [Page 39]
Internet-Draft EST-C509 July 2026
EST Client EST Server
| |
| POST example.com/est/<p>/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 } |
|<---------------------------------------------|
| |
Figure 21: Message flow of EST over CoAP/DTLS operation sren
B.9. skc
EST Client EST Server
| |
| POST example.com/est/<p>/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 } |
|<----------------------------------------------|
| |
Figure 22: Message flow of EST over CoAP/DTLS operation skc
Acknowledgements
The authors thank xxx for reviewing and commenting on intermediate
versions of the 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-02
* Use both long name and short name of operations.
Liao Expires 20 January 2027 [Page 40]
Internet-Draft EST-C509 July 2026
* 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 (updates [RFC9148]).
* Use short operation names defined in [RFC9148] to replace the long
names defined in [RFC7030].
Author's Address
Lijun Liao
NIO
Email: lijun.liao@nio.io
Liao Expires 20 January 2027 [Page 41]