EST for C509 Certificates

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

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

• 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).¶

5.1.1. 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.¶

Method: GET
Request target: /.well-known/cest/<label>/caps

5.1.2. 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.¶

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

Example response:¶

cacert
cacerts
crlinfo
crl
csrattrs
kemchall
simpleenroll
simplereenroll
serverkeygen

5.2.1. 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.¶

Method: GET
Request target: /.well-known/cest/<label>/csrattrs

5.2.2. 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 [I-D.ietf-cose-cbor-encoded-cert].¶

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

6.1.1. 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.¶

Method: GET
Request target: /.well-known/cest/<label>/cacert

6.1.2. 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 [I-D.ietf-cose-cbor-encoded-cert].¶

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

6.2.1. 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.¶

Method: GET
Request target: /.well-known/cest/<label>/cacerts

6.2.2. 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 [RFC9810], Section 4.4.¶

Successful cacerts responses SHOULD include HTTP caching metadata.¶

7.1.1. 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.¶

Method: GET
Request target: /.well-known/cest/<label>/crlinfo
Request target: /.well-known/cest/<label>/crlinfo[?crlnumber=<n>][&crldp=<dp>]

The optional crlnumber query parameter carries the decimal representation of the CRL number the client is interested in. When present, the EST server MUST return the C509CRLInfo for the CRL with that exact crlNumber. If no CRL with the requested crlnumber is available, the EST server MUST return HTTP status 404 (Not Found). When crlnumber is absent, the server returns the C509CRLInfo for the most recent CRL.¶

The optional crldp query parameter carries the CRL Distribution Point identifier. When present, the EST server MUST return the C509CRLInfo for the CRL associated with that distribution point. When both crlnumber and crldp are present, the server MUST return the C509CRLInfo matching both criteria.¶

7.1.2. 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 [I-D.liao-cose-c509-revocation].¶

C509CRLInfo carries all CRL fields from C509CRLInfoData — including crlType, signatureAlgorithm, authoritySubject, authorityKeyIdentifier, crlNumber, thisUpdate, nextUpdate, baseCrlNumber, and crlExtensions — without the revokedCertsList. An EST client can use these fields to compare crlNumber, nextUpdate, or compute a freshness check against its local cache before deciding whether to download the full C509CRL via crl.¶

If no matching CRL is available, the EST server MUST return HTTP status 404 (Not Found).¶

7.2.1. 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.¶

Method: GET
Request target: /.well-known/cest/<label>/crl
Request target: /.well-known/cest/<label>/crl[?crlnumber=<n>][&crldp=<dp>]

The optional crlnumber query parameter carries the decimal representation of the CRL number. When present, the EST server MUST return the full C509CRL with that exact crlNumber. When crlnumber is absent, the server returns the most recent CRL.¶

The optional crldp query parameter carries the CRL Distribution Point identifier. When present, the EST server MUST return the full C509CRL for the CRL associated with that distribution point. When both crlnumber and crldp are present, the server MUST return the C509CRL matching both criteria.¶

If no matching CRL is available, the EST server MUST return HTTP status 404 (Not Found).¶

7.2.2. 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 [I-D.liao-cose-c509-revocation].¶

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

8.2.1. Request

An authenticated EST client sends a POST request containing a C509PublicKey (Section 3.3.1) to request a KEM challenge.¶

Method: POST
Request target: /.well-known/cest/<label>/kemchall
Media type: application/c509-pubkey+cbor

<Base64-encoded C509PublicKey>

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

8.2.2. Response

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

• Media type: application/cbor¶

• Body: A base64-encoded KemChall (Section 3.3.2).¶

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 Section 3.3.2 for the PoP flow). The EST server verifies the MAC using the stored challenge state and issues the certificate on success.¶

8.3.1. Request

An authenticated EST client sends a POST request containing a C509 CSR (Section 3).¶

Method: POST
Request target: /.well-known/cest/<label>/simpleenroll
Media type: application/cose-c509-pkcs10+cbor

<Base64-encoded C509CertificationRequest>

The C509CertificationRequest MUST include a valid PoP signature. The EST server MUST verify the PoP signature against the public key in the C509 CSR before issuing a certificate, as required by [RFC7030], Section 3.4.¶

8.3.2. 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 [I-D.ietf-cose-cbor-encoded-cert].¶

8.4.1. Request

An authenticated EST client sends a POST request containing a C509 CSR for re-enrollment. The request Subject field and SubjectAltName extension MUST be identical to the corresponding fields in the certificate being renewed or rekeyed.¶

The ChangeSubjectName attribute defined in Section 3.2 MAY be included in the CSR to request that these fields be changed in the new certificate.¶

Method: POST
Request target: /.well-known/cest/<label>/simplereenroll
Media type: application/cose-c509-pkcs10+cbor

<Base64-encoded C509CertificationRequest>

Re-enrollment processing follows [RFC7030], Section 4.2.2. The EST server MUST verify the PoP signature in the C509 CSR.¶

8.4.2. 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 [I-D.ietf-cose-cbor-encoded-cert].¶

8.5.1. Request

An authenticated EST client sends a POST request containing a C509 CSR. The subjectPublicKeyAlgorithm in the C509 CSR SHOULD be set to empty-publickey (Section 3.1) 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.¶

Method: POST
Request target: /.well-known/cest/<label>/serverkeygen
Media type: application/cose-c509-pkcs10+cbor

<Base64-encoded C509CertificationRequest>

8.5.2. 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 Section 9). The private key is protected only by the TLS channel; no additional encryption is applied.¶

9.1.1. TLS Certificate Type Negotiation

When C509 certificates are used for TLS authentication, the client and server negotiate the certificate type using the server_certificate_type and client_certificate_type TLS extensions as defined in [RFC7250].¶

9.1.2. Client Authentication

The caps, cacert, cacerts, crlinfo, and crl operations SHOULD NOT require client authentication, consistent with [RFC7030], Section 4.1.2. The kemchall, simpleenroll, simplereenroll, and serverkeygen operations MUST require client authentication.¶

10.4.1. Media Type application/c509-pubkey+cbor

When the application/c509-pubkey+cbor media type is used, the payload is a C509PublicKey structure.¶

Type name: application¶

Subtype name: c509-pubkey+cbor¶

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¶