]> NIO

lijun.liao@nio.io

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 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 HTTPS/TLS transport and URI path structure as . For environments where HTTPS/TLS is impractical, EST for C509 certificates over CoAP with OSCORE is defined in . 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.
• 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 defined in this document are:

Operations Defined in This Document

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.

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

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 simplereenroll request to change the Subject field and/or the SubjectAltName extension in the newly generated certificate.

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.

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 kemchall operation, an EST server returns a CBOR-encoded KEM challenge object (KemChall) with media type application/cbor.

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 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 ().

EST URL Structure and Path Components The operations in this document follow the same URI path structure defined in . Retrieval operations (caps, cacert, cacerts, crlinfo, crl) use HTTP GET: Request target: /.well-known/cest// ]]> Enrollment operations (kemchall, simpleenroll, simplereenroll, serverkeygen) use HTTP POST: Request target: /.well-known/cest// ]]> An EST server MUST return HTTP 405 (Method Not Allowed) if a client uses POST for a retrieval operation or GET for an enrollment operation. The optional <label> path segment follows : an EST server MAY use an additional path segment before the operation name to distinguish services for multiple CAs or certificate profiles.

CBOR Transfer All POST request bodies in this document are CBOR-encoded. CBOR-based response bodies are base64-encoded for transport. 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	Structure	Defined in
application/cose-c509-cert+cbor	C509Certificate (single certificate)
application/cose-c509+cbor;usage=chain	COSE_C509
application/cose-c509-pkcs10+cbor	C509CertificationRequest
application/c509-pubkey+cbor	C509PublicKey	this document
application/cbor	KemChall	this document
application/cose-c509-crtemplate+cbor	C509CertificationRequestTemplate
application/cose-c509-pem+cbor	C509PEM (key + cert)
application/c509-crl+cbor	C509CRL
application/c509-crlinfo+cbor	C509CRLInfo

The caps operation returns text/plain with a list of capability keywords.

EST Server Capability Discovery

caps 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. The EST server SHOULD NOT require client authentication for this operation. /caps ]]>

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

• Media type: text/plain
• 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
cacert	EST server supports cacert ()
cacerts	EST server supports cacerts ()
crlinfo	EST server supports crlinfo ()
crl	EST server supports crl ()
csrattrs	EST server supports csrattrs ()
kemchall	EST server supports kemchall ()
simpleenroll	EST server supports simpleenroll ()
simplereenroll	EST server supports simplereenroll ()
serverkeygen	EST server supports serverkeygen ()

An EST client that receives an HTTP error response to a caps request MUST NOT attempt the operations defined in this document. Example response:

csrattrs The csrattrs 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. The EST server SHOULD NOT require client authentication for this operation. /csrattrs ]]>

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

• Media type: application/cose-c509-crtemplate+cbor
• Body: A base64-encoded C509CertificationRequestTemplate as defined in .

An HTTP response code of 204 or 404 indicates that CSR attributes are not available.

Distribution of CA Certificates

cacert The cacert operation returns the issuing CA certificate for the requested EST service as a single base64-encoded CBOR C509Certificate.

Request The EST client sends a GET request for the CA certificate. No request body is sent. The EST server SHOULD NOT require client authentication for this operation. /cacert ]]>

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

• Media type: application/cose-c509-cert+cbor
• Body: A base64-encoded C509Certificate for the issuing CA, as defined in .

The response body contains exactly one C509 certificate. Successful cacert responses SHOULD include HTTP caching metadata. EST servers SHOULD include ETag, Last-Modified, Cache-Control, and Expires headers when the certificate lifetime provides a meaningful freshness bound.

cacerts The cacerts operation returns the CA certificate chain for the requested EST service as a CBOR sequence of C509 certificates.

Request The EST client sends a GET request for the CA certificate chain. No request body is sent. The EST server SHOULD NOT require client authentication for this operation. /cacerts ]]>

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

• Media type: application/cose-c509+cbor;usage=chain
• Body: A base64-encoded 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, and NewWithOld in the response chain. These are defined in .

Successful cacerts responses SHOULD include HTTP caching metadata.

Distribution of C509 CRLs The crlinfo and crl operations provide C509 CRL access. The C509 CRL format is defined in .

crlinfo The crlinfo 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. The EST server SHOULD NOT require client authentication for this operation. /crlinfo Request target: /.well-known/cest//crlinfo [?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 200 response with:

• Media type: application/c509-crlinfo+cbor
• Body: A base64-encoded 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 status 404 (Not Found).

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. The EST server SHOULD NOT require client authentication for this operation. /crl Request target: /.well-known/cest//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 status 404 (Not Found).

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

• Media type: application/c509-crl+cbor
• Body: A base64-encoded C509CRL as defined in .

Successful crl responses SHOULD include HTTP caching metadata. When present, Last-Modified SHOULD reflect the CRL thisUpdate value, and when nextUpdate is present, Expires SHOULD reflect thisUpdate + nextUpdate. If no matching CRL is available, the EST server MUST return HTTP status 404 (Not Found).

Certificate Enrollment Operations

Client Authentication The enrollment operations defined in this section (kemchall, simpleenroll, simplereenroll, and serverkeygen`) require client authentication. The client authentication requirements are unchanged from . EST clients and EST servers MUST follow and for client authentication, respectively.

kemchall The kemchall 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. /kemchall Media type: application/c509-pubkey+cbor ]]> If the request does not contain a KEM public key, the EST server MUST return HTTP 400 (Bad Request). If the server supports KEM PoP for the submitted algorithm, it issues a challenge; otherwise, it MUST return HTTP 501 (Not Implemented).

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

• Media type: application/cbor
• Body: A base64-encoded KemChall ().

A client that receives a KemChall uses the recovered one-time secret key to produce the PoP MAC and then proceeds with a normal enrollment request (simpleenroll or simplereenroll) 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 The simpleenroll operation requests issuance of a new C509 certificate from the EST server.

Request An authenticated EST client sends a POST request containing a C509 CSR (). /simpleenroll Media type: application/cose-c509-pkcs10+cbor ]]> 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 200 response with:

• Media type: application/cose-c509-cert+cbor
• Body: A base64-encoded C509Certificate issued for the subject in the C509 CSR, as defined in .

simplereenroll The simplereenroll 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. /simplereenroll Media type: application/cose-c509-pkcs10+cbor ]]> Re-enrollment processing follows . The EST server MUST verify the PoP signature in the C509 CSR.

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

• Media type: application/cose-c509-cert+cbor
• Body: A base64-encoded renewed C509Certificate, as defined in .

serverkeygen The serverkeygen 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 serverkeygen and MUST NOT verify a PoP signature in this case. /serverkeygen Media type: application/cose-c509-pkcs10+cbor ]]>

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

• Media type: application/cose-c509-pem+cbor
• Body: A base64-encoded 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) as required by . Implementations MUST NOT fall back to plain HTTP. EST clients and servers SHOULD use C509 certificates for TLS authentication when both peers support C509. This enables end-to-end C509 usage, including the TLS handshake itself, and reduces size and parsing overhead consistently. EST servers MUST continue to accept X.509 certificates for TLS 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 The caps, cacert, cacerts, crlinfo, and crl operations SHOULD NOT require client authentication, consistent with . The kemchall, simpleenroll, simplereenroll, and serverkeygen operations MUST require client authentication.

Server Key Generation The serverkeygen 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

Well-Known URI Registry IANA is requested to register the following entry in the "Well-Known URI" registry established by : Well-Known URI Registration for cest

URI Suffix	Change Controller	Reference	Status	Related Information
cest	IETF	This document	permanent	C509 EST operations as defined in this document

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

Field	Value
Value	TBD1
Name	empty-publickey
Identifiers	N/A
OID	N/A
Parameters	N/A
DER	N/A
Comments	Exclusively for use in subjectPublicKeyAlgorithm of a TBSCertificationRequest for server-side key generation (serverkeygen). 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: COSE 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. 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. This memo defines a path prefix for "well-known locations", "/.well-known/", in selected Uniform Resource Identifier (URI) schemes. In doing so, it obsoletes RFC 5785 and updates the URI schemes defined in RFC 7230 to reserve that space. It also updates RFC 7595 to track URI schemes that support well-known URIs in their registry. 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. 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. Ericsson AB RISE Nexus Inria Enrollment over Secure Transport (EST) is a certificate provisioning protocol over HTTPS [RFC7030] or CoAPs [RFC9148]. This document specifies how to carry EST over the Constrained Application Protocol (CoAP) protected with Object Security for Constrained RESTful Environments (OSCORE). The specification builds on the EST-coaps [RFC9148] specification, but uses OSCORE and Ephemeral Diffie-Hellman over COSE (EDHOC) instead of DTLS. The specification also leverages the certificate structures defined in [I-D.ietf-cose-cbor-encoded-cert], which can be optionally used alongside X.509 certificates.

Message Flow Diagrams

caps

caps message flow /caps | |------------------------------------------->| | | | Status: 200 OK | | Media type: text/plain | | | | cacert | | cacerts | | crlinfo | | crl | | kemchall | | simpleenroll | | simplereenroll | | | |<-------------------------------------------| | | ]]>

cacert

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

cacerts

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

crlinfo

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

crl

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

simpleenroll

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

serverkeygen

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

Acknowledgements The authors thank xxx for reviewing and commenting on intermediate versions of the draft.