]> NIO

lijun.liao@nio.io

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

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

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

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

Conventions and Definitions The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in BCP 14 when, and only when, they appear in all capitals, as shown here. The following terms are used in this document:

EST client:

The entity that contacts the EST server to obtain certificates or CA information, as defined in .

EST server:

The entity that processes EST requests, typically acting as an RA between the EST client and the CA, as defined in .

CA:

Certification Authority. The entity that issues C509 certificates.

C509 CSR:

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

PoP:

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

Protocol Design

Client Authentication While permits a number of the EST functions to be used without authentication, this document requires that the client MUST be authenticated for all functions, as in . This document 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 ) is supported, as in .

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 ) (TODO: the TBD will be replaced with the real value once the Content-Formats are assigned in and ): ;rt="ace.est.crts";ct="TBD TBD", ;rt="ace.est.sen";ct="TBD TBD", ;rt="ace.est.sren";ct="TBD TBD", ;rt="ace.est.att";ct=TBD, ;rt="ace.est.skc";ct=TBD, ;rt="ace.est.crli";ct=TBD, ;rt="ace.est.crl";ct=TBD, ;rt="ace.est.kemc";ct=TBD7 ]]>

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

Channel Binding Channel binding is OPTIONAL. The challel binding mechanisms specified in {RFC7030} and apply.

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

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

Delayed Responses The mechanism for delayed responses specified in applies for CoAP in this document. And the mechanism with retry-later for the operarions simpleenroll / sen and simplereenroll / sren specified in applies for HTTP in this document.

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.

CBOR Transfer All POST request bodies in this document are CBOR-encoded. For the HTTPS binding, CBOR-based response bodies are base64-encoded for transport. For the CoAP binding, 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 and of . Servers MUST NOT include a Content-Transfer-Encoding header for CBOR payloads. The media types used in this document are: Media Types Used in This Document

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

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

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

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

CRAttribute ChangeSubjectName The ChangeSubjectName for X.509 PKI is defined in . 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. This CRAttribute MAY be included in a sren request to change the Subject field and/or the SubjectAltName extension in the newly generated certificate.

Proof of Possession simpleenroll / sen and simplereenroll / sren MUST verify the PoP signature in the C509 CSR before issuing a certificate. The simplereenroll / skc` operation does not require PoP verification because the EST server generates the key pair itself.

C509PublicKey A C509PublicKey contains a subject public key in the C509 encoding. It uses the same field types as TbsCertificate in and is defined as: The subjectPublicKeyAlgorithm field uses the full AlgorithmIdentifier encoding as defined in , 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 . The media type of C509PublicKey is application/c509-pubkey+cbor (see ); the corresponding CoAP Content-Format is defined in . The "magic number" is TBD2, using the reserved CBOR tag 55799 and Content-Format TBD3, as described in .

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/cbor.

The media type of C509KemChall is application/c509-kemchall+cbor (see ); the corresponding CoAP Content-Format is defined in . The "magic number" is TBD6, using the reserved CBOR tag 55799 and Content-Format TBD7, as described in . In particular:

• 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 CBOR-encoded 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 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 ().

EST Operations for Server Capability Discovery

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

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

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

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

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

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

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 . Example response:

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

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

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 .

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

EST Operations for Distribution of CA Certificates

cacerts / crts Successful cacerts / crts responses MAY include caching metadata as specified in . Depending on the Accept option, the cacerts / crts operation returns different forms of the CA certificates (TODO: the TBD will be replaced with the real value once the Content-Formats are assigned in and ):

• Accept: application/cose-c509-cert (HTTP) / Accept=TBD (CoAP): a single certificate
• Accept: application/cose-c509; usage=chain (HTTP) / Accept=TBD (CoAP): certificate chain
• No Accept or Accept: application/cose-c509 (HTTP) / Accept=TBD (CoAP): certificate set (unsorted certificates)

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. /cacerts (Accept: ) CoAP request target: /.well-known/est//crts (Accept=) ]]>

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. If a Root CA key update applies, the EST server SHOULD include the three "Root CA Key Update" certificates OldWithOld, OldWithNew, NewWithOld, and NewWIthNew in the response chain. These are defined in .
• 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 EST server SHOULD include the three "Root CA Key Update" certificates OldWithOld, OldWithNew, NewWithOld, and NewWithNew in the response chain. These are defined in .

Successful cacerts / crts responses MAY include caching metadata as specified in .

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

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

Request The EST client sends a GET request for CRL metadata. No request body is sent. /crli Request target: /.well-known/est//crli [?crlnumber=][&crldp=] ]]> The optional crlnumber query parameter carries the decimal representation of the CRL number the client is interested in. When present, the EST server MUST return the C509CRLInfo for the CRL with that exact crlNumber. If no CRL with the requested crlnumber is available, the EST server MUST return HTTP 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.

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 .

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 .

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

Request The EST client sends a GET request for the C509 CRL. No request body is sent. /crl Request target: /.well-known/est//crl [?crlnumber=][&crldp=] ]]> The optional crlnumber query parameter carries the decimal representation of the CRL number. When present, the EST server MUST return the full C509CRL with that exact crlNumber. When crlnumber is absent, the server returns the most recent CRL. The optional crldp query parameter 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. If no matching CRL is available, the EST server MUST return HTTP 404 / CoAP 4.04 (Not Found).

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 .

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

EST Operations for Certificate Enrollment

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

Request An authenticated EST client sends a POST request containing a C509PublicKey () to request a KEM challenge. /kemc Media type: application/c509-pubkey+cbor (HTTP)/ Content-Type 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).

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

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

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 (sen or sren) including the computed MAC in the request (see for the PoP flow). The EST server verifies the MAC using the stored challenge state and issues the certificate on success.

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

Request An authenticated EST client sends a POST request containing a C509 CSR (). /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 .

Response On success, the EST server returns a HTTP 200 / CoAP 2.04 response with:

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

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

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

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 .

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

Request An authenticated EST client sends a POST request containing a C509 CSR. The subjectPublicKeyAlgorithm in the C509 CSR SHOULD be set to empty-publickey () and subjectPublicKey SHOULD be an empty 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 skc and MUST NOT verify a PoP signature in this case. /serverkeygen CoAP Request target: /.well-known/est//skc Media type: application/cose-c509-pkcs10+cbor (HTTP) / Content-Format TBD (CoAP) Body: C509CertificationRequest ]]>

Response On success, the EST server returns 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 ). The private key is protected only by the TLS channel; no additional encryption is applied.

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

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

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 .

Client Authentication All operations MUST require client authentication.

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 , 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.

C509 Certificate Validation EST clients MUST validate received C509 certificates against an independently configured trust anchor according to . 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.

IANA Considerations

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

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

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

Field	Value
Value	TBD4
Name	hmacWithSHA256
Identifiers	id-hmacWithSHA256
OID	1.2.840.113549.2.9
Parameters	N/A
OID	06 08 2A 86 48 86 F7 0D 02 09
Comments	HMAC over SHA256
Reference	This document

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 :

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 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

Media Type application/c509-kemchall+cbor When the application/c509-kemchall+cbor media type is used, the payload is a C509KemChall structure. Type name: application Subtype name: c509-kemchall+cbor Required parameters: N/A Optional parameters: N/A Encoding considerations: binary Security considerations: See 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

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

CoAP Content-Format IDs

References Normative References This memo profiles the X.509 v3 certificate and X.509 v2 certificate revocation list (CRL) for use in the Internet. An overview of this approach and model is provided as an introduction. The X.509 v3 certificate format is described in detail, with additional information regarding the format and semantics of Internet name forms. Standard certificate extensions are described and two Internet-specific extensions are defined. A set of required certificate extensions is specified. The X.509 v2 CRL format is described in detail along with standard and Internet-specific extensions. An algorithm for X.509 certification path validation is described. An ASN.1 module and examples are provided in the appendices. [STANDARDS-TRACK] This document describes the Cryptographic Message Syntax (CMS). This syntax is used to digitally sign, digest, authenticate, or encrypt arbitrary message content. [STANDARDS-TRACK] This document contains a set of updates to the base syntax for CMC, a Certificate Management protocol using the Cryptographic Message Syntax (CMS). This document updates RFC 5272, RFC 5273, and RFC 5274. The new items in this document are: new controls for future work in doing server side key generation, definition of a Subject Information Access value to identify CMC servers, and the registration of a port number for TCP/IP for the CMC service to run on. [STANDARDS-TRACK] This document profiles certificate enrollment for clients using Certificate Management over CMS (CMC) messages over a secure transport. This profile, called Enrollment over Secure Transport (EST), describes a simple, yet functional, certificate management protocol targeting Public Key Infrastructure (PKI) clients that need to acquire client certificates and associated Certification Authority (CA) certificates. It also supports client-generated public/private key pairs as well as key pairs generated by the CA. Enrollment over Secure Transport (EST) is used as a certificate provisioning protocol over HTTPS. Low-resource devices often use the lightweight Constrained Application Protocol (CoAP) for message exchanges. This document defines how to transport EST payloads over secure CoAP (EST-coaps), which allows constrained devices to use existing EST functionality for provisioning certificates. This document specifies a new certificate type and two TLS extensions for exchanging raw public keys in Transport Layer Security (TLS) and Datagram Transport Layer Security (DTLS). The new certificate type allows raw public keys to be used for authentication. The Concise Binary Object Representation (CBOR) is a data format whose design goals include the possibility of extremely small code size, fairly small message size, and extensibility without the need for version negotiation. These design goals make it different from earlier binary serializations such as ASN.1 and MessagePack. This document obsoletes RFC 7049, providing editorial improvements, new details, and errata fixes while keeping full compatibility with the interchange format of RFC 7049. It does not create a new version of the format. This document defines a stored ("file") format for Concise Binary Object Representation (CBOR) data items that is friendly to common systems that recognize file types, such as the Unix file(1) command. This document describes the Internet X.509 Public Key Infrastructure (PKI) Certificate Management Protocol (CMP). Protocol messages are defined for X.509v3 certificate creation and management. CMP provides interactions between client systems and PKI components such as a Registration Authority (RA) and a Certification Authority (CA). This document adds support for management of certificates containing a Key Encapsulation Mechanism (KEM) public key and uses EnvelopedData instead of EncryptedValue. This document also includes the updates specified in Section 2 and Appendix A.2 of RFC 9480. This document obsoletes RFC 4210, and together with RFC 9811, it also obsoletes RFC 9480. Appendix F of this document updates Section 9 of RFC 5912. Ericsson AB Ericsson AB University of Glasgow RISE AB IN Groupe NIO This document specifies a CBOR encoding of X.509 certificates. The resulting certificates are called C509 certificates. The CBOR encoding supports a large subset of RFC 5280 and common certificate profiles, and it is extensible. Two types of C509 certificates are defined. One type is an invertible CBOR re-encoding of DER-encoded X.509 certificates with the signature field copied from the DER encoding. The other type is identical except that the signature is computed over the CBOR encoding instead of the DER encoding, thereby avoiding the use of ASN.1. Both types of certificates have the same semantics as X.509 while providing comparable size reduction. This document also specifies CBOR-encoded data structures for certification requests and certification request templates, new COSE headers, as well as a TLS certificate type and a file format for C509. This document updates RFC 6698 by extending the TLSA selectors registry to include C509 certificates. NIO RISE AB RISE AB RISE AB University of Glasgow This document specifies CBOR-encoded PKI structures for use with C509 certificates (draft-ietf-cose-cbor-encoded-cert), X.509 certificates (RFC 5280), and future certificate types. It defines C509 CRL and C509 OCSP, compact CBOR encodings of X.509 Certificate Revocation Lists (RFC 5280) and OCSP messages (RFC 6960), respectively. The structures defined in this document are certificate-type agnostic and can be used with C509 certificates, X.509 certificates, or future certificate types without modification. C509 OCSP improves on RFC 6960 by signing a wider set of fields to prevent algorithm- substitution and certificate-chain substitution attacks, replacing plaintext serial numbers with hashes to preserve requestor privacy, replacing the two-hash issuer identity with a single certificate hash, and identifying all participants (requestor, responder, issuer) by a uniform certificate hash rather than type-specific fields. C509 CRL and C509 OCSP are not wire-format-compatible with their DER- encoded X.509 counterparts and cannot be converted to or from them without semantic interpretation. In many standards track documents several words are used to signify the requirements in the specification. These words are often capitalized. This document defines these words as they should be interpreted in IETF documents. This document specifies an Internet Best Current Practices for the Internet Community, and requests discussion and suggestions for improvements. RFC 2119 specifies common key words that may be used in protocol specifications. This document aims to reduce the ambiguity by clarifying that only UPPERCASE usage of the key words have the defined special meanings. Informative References This memo represents a republication of PKCS #10 v1.7 from RSA Laboratories' Public-Key Cryptography Standards (PKCS) series, and change control is retained within the PKCS process. The body of this document, except for the security considerations section, is taken directly from the PKCS #9 v2.0 or the PKCS #10 v1.7 document. This memo provides information for the Internet community.

Message Flow Diagrams over HTTPS

cacerts

HTTP cacerts message flow /cacerts | |--------------------------------------------->| | | | Status: 200 OK | | Media type: application/cose-c509+cbor | | | | | |<---------------------------------------------| | | ]]>

crli

HTTP crli message flow /crli | | [?crlnumber=][&crldp=] | |---------------------------------------------->| | | | Status: 200 OK | | Media type: application/c509-crlinfo+cbor | | | | | |<----------------------------------------------| | | ]]>

crl

HTTP crl message flow /crl | | [?crlnumber=][&crldp=] | | | |---------------------------------------------->| | | | Status: 200 OK | | Media type: application/c509-crl+cbor | | | | | |<----------------------------------------------| | | ]]>

kemc

HTTP kemc message flow /kemc | | Media type: application/c509-pubkey+cbor | | | | | |---------------------------------------------->| | | | | | Status: 200 OK | | Media type: application/c509-kemchall+cbor | | | | | |<----------------------------------------------| | | ]]>

simpleenroll

HTTP simpleenroll message flow | | /simpleenroll | | Media type: application/cose-c509-pkcs10+cbor | | | | | |---------------------------------------------->| Verify PoP, | | Issue C509 | | cert | Status: 200 OK | | Media type: application/cose-c509-cert+cbor | | | | | |<----------------------------------------------| | | ]]>

simplereenroll

HTTP simplereenroll message flow | | /simplereenroll | | Media type: application/cose-c509-pkcs10+cbor | | | | | |---------------------------------------------->| Verify PoP, | | Issue C509 | | cert | Status: 200 OK | | Media type: application/cose-c509-cert+cbor | | | | | |<----------------------------------------------| | | ]]>

serverkeygen

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

Message Flow Diagrams over CoAP/DTLS

crts

CoAP crts message flow

crli

CoAP crli message flow

crl

CoAP crl message flow

kemc

CoAP kemc message flow

sen

CoAP sen message flow

sren

CoAP sren message flow

skc

CoAP skc message flow

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-01

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