Network Working Group L. Liao Internet-Draft NIO Intended status: Standards Track 6 July 2026 Expires: 7 January 2027 EST for C509 Certificates draft-liao-ace-est-c509-01 Abstract This document defines Enrollment over Secure Transport (EST) protocol operations over HTTPS 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 7 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 7 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. C509 Certification Request (C509 CSR) . . . . . . . . . . . . 7 3.1. empty-publickey Algorithm . . . . . . . . . . . . . . . . 8 3.2. CRAttribute ChangeSubjectName . . . . . . . . . . . . . . 8 3.3. Proof of Possession . . . . . . . . . . . . . . . . . . . 8 3.3.1. C509PublicKey . . . . . . . . . . . . . . . . . . . . 8 3.3.2. Proof of Possession for KEM Private Keys . . . . . . 9 4. EST URL Structure and Path Components . . . . . . . . . . . . 10 4.1. CBOR Transfer . . . . . . . . . . . . . . . . . . . . . . 11 5. EST Server Capability Discovery . . . . . . . . . . . . . . . 12 5.1. caps . . . . . . . . . . . . . . . . . . . . . . . . . . 12 5.1.1. Request . . . . . . . . . . . . . . . . . . . . . . . 12 5.1.2. Response . . . . . . . . . . . . . . . . . . . . . . 13 5.2. csrattrs . . . . . . . . . . . . . . . . . . . . . . . . 14 5.2.1. Request . . . . . . . . . . . . . . . . . . . . . . . 14 5.2.2. Response . . . . . . . . . . . . . . . . . . . . . . 14 6. Distribution of CA Certificates . . . . . . . . . . . . . . . 14 6.1. cacert . . . . . . . . . . . . . . . . . . . . . . . . . 14 6.1.1. Request . . . . . . . . . . . . . . . . . . . . . . . 15 6.1.2. Response . . . . . . . . . . . . . . . . . . . . . . 15 6.2. cacerts . . . . . . . . . . . . . . . . . . . . . . . . . 15 6.2.1. Request . . . . . . . . . . . . . . . . . . . . . . . 15 6.2.2. Response . . . . . . . . . . . . . . . . . . . . . . 15 7. Distribution of C509 CRLs . . . . . . . . . . . . . . . . . . 16 Liao Expires 7 January 2027 [Page 2] Internet-Draft EST-C509 July 2026 7.1. crlinfo . . . . . . . . . . . . . . . . . . . . . . . . . 16 7.1.1. Request . . . . . . . . . . . . . . . . . . . . . . . 16 7.1.2. Response . . . . . . . . . . . . . . . . . . . . . . 17 7.2. crl . . . . . . . . . . . . . . . . . . . . . . . . . . . 17 7.2.1. Request . . . . . . . . . . . . . . . . . . . . . . . 17 7.2.2. Response . . . . . . . . . . . . . . . . . . . . . . 18 8. Certificate Enrollment Operations . . . . . . . . . . . . . . 18 8.1. Client Authentication . . . . . . . . . . . . . . . . . . 18 8.2. kemchall . . . . . . . . . . . . . . . . . . . . . . . . 18 8.2.1. Request . . . . . . . . . . . . . . . . . . . . . . . 18 8.2.2. Response . . . . . . . . . . . . . . . . . . . . . . 19 8.3. simpleenroll . . . . . . . . . . . . . . . . . . . . . . 19 8.3.1. Request . . . . . . . . . . . . . . . . . . . . . . . 19 8.3.2. Response . . . . . . . . . . . . . . . . . . . . . . 19 8.4. simplereenroll . . . . . . . . . . . . . . . . . . . . . 20 8.4.1. Request . . . . . . . . . . . . . . . . . . . . . . . 20 8.4.2. Response . . . . . . . . . . . . . . . . . . . . . . 20 8.5. serverkeygen . . . . . . . . . . . . . . . . . . . . . . 20 8.5.1. Request . . . . . . . . . . . . . . . . . . . . . . . 21 8.5.2. Response . . . . . . . . . . . . . . . . . . . . . . 21 9. Security Considerations . . . . . . . . . . . . . . . . . . . 21 9.1. Transport Security . . . . . . . . . . . . . . . . . . . 21 9.1.1. TLS Certificate Type Negotiation . . . . . . . . . . 22 9.1.2. Client Authentication . . . . . . . . . . . . . . . . 22 9.2. Server Key Generation . . . . . . . . . . . . . . . . . . 22 9.3. C509 Certificate Validation . . . . . . . . . . . . . . . 22 10. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 23 10.1. Well-Known URI Registry . . . . . . . . . . . . . . . . 23 10.2. C509 Public Key Algorithms Registry . . . . . . . . . . 23 10.3. C509 Signature Algorithms Registry . . . . . . . . . . . 24 10.4. C509 CR Attributes Registry . . . . . . . . . . . . . . 25 10.4.1. Media Type application/c509-pubkey+cbor . . . . . . 25 10.5. CoAP Content-Formats Registry . . . . . . . . . . . . . 26 11. References . . . . . . . . . . . . . . . . . . . . . . . . . 27 11.1. Normative References . . . . . . . . . . . . . . . . . . 27 11.2. Informative References . . . . . . . . . . . . . . . . . 28 Appendix A. Message Flow Diagrams . . . . . . . . . . . . . . . 29 A.1. caps . . . . . . . . . . . . . . . . . . . . . . . . . . 29 A.2. cacert . . . . . . . . . . . . . . . . . . . . . . . . . 29 A.3. cacerts . . . . . . . . . . . . . . . . . . . . . . . . . 30 A.4. crlinfo . . . . . . . . . . . . . . . . . . . . . . . . . 30 A.5. crl . . . . . . . . . . . . . . . . . . . . . . . . . . . 30 A.6. simpleenroll . . . . . . . . . . . . . . . . . . . . . . 31 A.7. serverkeygen . . . . . . . . . . . . . . . . . . . . . . 31 Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . . 32 Author's Address . . . . . . . . . . . . . . . . . . . . . . . . 32 Liao Expires 7 January 2027 [Page 3] Internet-Draft EST-C509 July 2026 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. This document defines EST operations that carry C509 objects in place of DER X.509 objects, following the same HTTPS/TLS transport and URI path structure as [RFC7030]. For environments where HTTPS/TLS is impractical, EST for C509 certificates over CoAP with OSCORE is defined in [I-D.ietf-ace-coap-est-oscore]. 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 or simplereenroll 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 (KemChall) from the EST server; in this case, the EST client considers the C509PublicKey, KemChall, and C509CertificationRequest opaque binary blobs. Liao Expires 7 January 2027 [Page 4] Internet-Draft EST-C509 July 2026 * For all key types, the C509 certificate 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 defined in this document are: Liao Expires 7 January 2027 [Page 5] Internet-Draft EST-C509 July 2026 +==========+============+=========+==============+=================+ | Opera- | Category | Client | Request | Response | | tion | | Authen- | Media Type | Media Type | | | | tica- | | | | | | tion | | | +==========+============+=========+==============+=================+ | caps | Capability | No | (none) | text/plain | | | discovery | | | | +----------+------------+---------+--------------+-----------------+ | cacert | CA cert. | No | (none) | application/ | | | retrieval | | | cose-c509- | | | | | | cert+cbor | +----------+------------+---------+--------------+-----------------+ | cacerts | CA cert. | No | (none) | application/ | | | chain | | | cose-c509+cbor; | | | retrieval | | | usage=chain | +----------+------------+---------+--------------+-----------------+ | crlinfo | CRL | No | (none) | application/ | | | metadata | | | c509-crlinfo | | | retrieval | | | +cbor | +----------+------------+---------+--------------+-----------------+ | crl | CRL | No | (none) | application/ | | | retrieval | No | | c509-crl+cbor | +----------+------------+---------+--------------+-----------------+ | csrattrs | CSR | No | (none) | application/ | | | attributes | | | cose-c509- | | | retrieval | | | crtemplate+cbor | +----------+------------+---------+--------------+-----------------+ | kemchall | KEM | Yes | application/ | application/ | | | challenge | | c509-pubkey | cbor | | | issuance | | +cbor | | +----------+------------+---------+--------------+-----------------+ | simple | Cert. | Yes | application/ | application/ | | enroll | enrollment | | cose-c509- | cose-c509- | | | | | pkcs10+cbor | cert+cbor | +----------+------------+---------+--------------+-----------------+ | simple | Cert. re- | Yes | application/ | application/ | | reenroll | enrollment | | cose-c509- | cose-c509- | | | | | pkcs10+cbor | cert+cbor | +----------+------------+---------+--------------+-----------------+ | server | Server-side| Yes | application/ | application/ | | keygen | key | | cose-c509- | cose-c509- | | | generation | | pkcs10+cbor | pem+cbor | +----------+------------+---------+--------------+-----------------+ Figure 1: Operations Defined in This Document Liao Expires 7 January 2027 [Page 6] Internet-Draft EST-C509 July 2026 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 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. 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. 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.5), 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 3.1) and subjectPublicKey MUST be an empty 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. Liao Expires 7 January 2027 [Page 7] Internet-Draft EST-C509 July 2026 EST servers MUST accept C509 CSRs using empty-publickey and id-alg- unsigned for serverkeygen requests and MUST NOT verify a PoP signature in this case. 3.1. empty-publickey Algorithm This document defines a new C509 public key algorithm, empty- publickey, to be used exclusively in C509 CSRs for serverkeygen 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 an empty byte string (h''). EST servers MUST reject any C509 CSR using empty-publickey in a simpleenroll or simplereenroll request. 3.2. CRAttribute ChangeSubjectName The ChangeSubjectName 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. ChangeSubjectName = [ subject C509Name / null, subjectAlt SubjectAltName / null ] This CRAttribute MAY be included in a simplereenroll request to change the Subject field and/or the SubjectAltName extension in the newly generated certificate. 3.3. Proof of Possession simpleenroll and simplereenroll MUST verify the PoP signature in the C509 CSR before issuing a certificate. The serverkeygen operation does not require PoP verification because the EST server generates the key pair itself. 3.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: Liao Expires 7 January 2027 [Page 8] Internet-Draft EST-C509 July 2026 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.4.1); the corresponding CoAP Content-Format is defined in Section 10.5. The "magic number" is TBD2, using the reserved CBOR tag 55799 and Content-Format TBD3, as described in [RFC9277], Section 2.2. 3.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 kemchall operation, an EST server returns a CBOR-encoded KEM challenge object (KemChall) with media type application/cbor. KemChall = [ keyId : bstr, encapAlg : int, encapsulation : bstr ] In particular: * keyId is the SHA-256 fingerprint of the CBOR-encoded C509PublicKey, Liao Expires 7 January 2027 [Page 9] Internet-Draft EST-C509 July 2026 * 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 S to the client's KEM public key. The server MUST retain the challenge state (at least keyId, S, and the lifetime) for the duration of the challenge. * Client decapsulation and response: The client decapsulates encapsulation to recover the one-time secret key S. The client computes a MAC value over the CBOR-encoded TBSCertificationRequest with the key S. 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 derives K from S and verifies the received mac against the saved 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. IANA is requested to register MAC algorithms to be used in C509CertificationRequest (Section 10.3). 4. EST URL Structure and Path Components The operations in this document follow the same URI path structure defined in [RFC7030], Section 3.2.2. Retrieval operations (caps, cacert, cacerts, crlinfo, crl) use HTTP GET: Method: GET Request target: /.well-known/cest/ Request target: /.well-known/cest/