EST-coaps: Enrollment over Secure Transport with the Secure Constrained Application Protocol
updated by
- rfc-9908 — Clarification and Enhancement of the CSR Attributes Definition in RFC 7030
Extracted elements (31)
EST-coaps uses binary DER-encoded payloads instead of Base64 encoding (as used by HTTP-based EST) because binary is 30% smaller and well-supported by CoAP, reducing overhead for constrained devices where payload size is critical.
Shorter URI path names (/crts, /sen, etc.) are specified instead of the longer EST paths (/cacerts, /simpleenroll, etc.) because EST-coaps targets low-resource networks with small packets where header space savings are important.
An HTTPS-CoAPS Registrar bridges constrained CoAP networks to external HTTP/TLS EST servers. The Registrar must translate URI paths per Table 1, map CoAP/HTTP response codes, convert binary CBOR payloads to Base64, and reassemble blocks before forwarding upstream.
DTLS 1.2 implementations must use Supported Elliptic Curves and Point Formats Extensions (RFC 8422) including uncompressed point format. DTLS 1.3 does not support point format negotiation and renames the extension to 'Supported Groups'; point format extensions are not mandated.
Authentication of the EST-coaps client MUST be with a client certificate in the DTLS handshake. HTTP Basic and Digest authentication (as described in Section 3.2.3 of RFC 7030) are not supported.
Clients and servers MUST support the short resource EST-coaps URIs defined in Table 1 (e.g., /crts, /sen, /sren, /skg, /skc, /att). The server MUST support the default /.well-known/est root resource.
Content-Format 281 (application/pkcs7-mime; smime-type=certs-only) MUST be supported by EST-coaps servers. Servers MAY also support Content-Format 287 (application/pkix-cert).
DTLS connections SHOULD only be kept alive for EST messages that are relatively close to each other, such as a /sen immediately following a /crts during device bootstrapping.
EST-coaps servers MUST implement Block1 and Block2 options (RFC 7959). EST-coaps clients MUST implement Block2, and MUST implement Block1 only if they expect to send requests exceeding the path MTU.
In server-side key generation, clients and servers MUST support unprotected (PKCS #8) private keys (Content-Format 284). CMS EnvelopedData encryption (Content-Format 280) SHOULD be supported for deployments where end-to-end encryption is needed.
The /cacerts, /simpleenroll, and /simplereenroll functions MUST be implemented by EST-coaps servers. /serverkeygen and /csrattrs are OPTIONAL; /fullcmc is not specified.
The client MUST be authenticated for all EST-coaps functions. Unlike RFC 7030, which permits some EST functions without authentication, EST-coaps requires authentication for every operation.
The EST-coaps client MUST be configured with at least an Implicit Trust Anchor database to enable authentication of the server before updating its trust anchor. The updated Explicit TA MUST continue to be used in new DTLS connections after a /crts response.
The EST-coaps-to-HTTPS Registrar MUST terminate EST-coaps downstream and initiate EST connections over TLS upstream. The Registrar MUST authenticate and optionally authorize client requests, and MUST reassemble blocks before translating binary content to Base64.
The mandatory cipher suite for DTLS in EST-coaps is TLS_ECDHE_ECDSA_WITH_AES_128_CCM_8. Curve secp256r1 MUST be supported; this curve is equivalent to the NIST P-256 curve.
TLS cipher suites that include '_EXPORT_' and '_DES_' in their names MUST NOT be used, in accordance with RFC 7030.
When a slow server requires manual intervention (minutes), it SHOULD respond with response code 5.03 (Service Unavailable) and a Max-Age Option indicating the time the client SHOULD wait before resending the identical CSR.
An EST-coaps DTLS connection MAY remain open for sequential EST transactions, unlike RFC 7030's HTTPS model. This accommodates constrained devices that cannot afford a full DTLS handshake for every EST transaction.
CoAP response code mapping: GET requests (/crts, /att) return 2.05 on success; POST requests (/sen, /sren, /skg, /skc) return 2.04 on success. Delayed responses use 5.03 with Max-Age. HTTP 4xx/5xx map to equivalent CoAP 4.xx/5.xx codes.
EST-coaps maps EST URIs to shorter equivalents: /cacerts→/crts, /simpleenroll→/sen, /simplereenroll→/sren, /serverkeygen→/skg (PKCS #7) or /skc (pkix-cert), /csrattrs→/att. These shorter URIs save header space in constrained networks.
Proof-of-possession (POP) linking is OPTIONAL. For DTLS 1.2, the tls-unique value (first Finished message) is added as a challengePassword in the PKCS #10 CSR. For DTLS 1.3, a 32-byte tls-exporter binding derived using 'EXPORTER-Channel-Binding' is used instead.
Resource discovery is performed by sending GET /.well-known/core?rt=ace.est* over CoAPS. The server MUST return ace.est.crts, ace.est.sen, and ace.est.sren in the response if it supports resource discovery; optional resources are only listed if implemented.
IANA added RFC 9148 as an additional reference to the existing 'est' URI entry in the Well-Known URIs registry, alongside the original RFC 7030 reference.
IANA registered six new CoAP Content-Format values (256–9999 range) in the 'CoAP Content-Formats' subregistry: 280 (pkcs7-mime server-generated-key), 281 (pkcs7-mime certs-only), 284 (pkcs8), 285 (csrattrs), 286 (pkcs10), 287 (pkix-cert).
IANA registered six Resource Type (rt=) Link Target Attribute Values in the CoRE Parameters registry: ace.est.crts, ace.est.sen, ace.est.sren, ace.est.att, ace.est.skg, ace.est.skc, each identifying a specific EST-coaps function.
Constrained IoT devices lack traditional entropy sources (mouse movement, keystroke timing, disk turbulence) for random number generation. Selecting hardware capable of producing high-quality random numbers is critical, as weak randomness can lead to digital identity theft through predictable private keys.
The 3SHAKE attack allows an on-path attacker to leverage session resumption/renegotiation to invalidate POP linking. For DTLS 1.2, tls-unique (RFC 5929) is retained as the risk is limited; for DTLS 1.3, tls-exporter binding is mandated to mitigate the attack. The Extended Master Secret Extension (RFC 7627) SHOULD be used with DTLS 1.2.
When a Registrar is present and server-side key generation is used without end-to-end CMS encryption, the Registrar can observe the private key in transit, acting as a man-in-the-middle. Clients must trust the Registrar not to expose the key.
EST-coaps uses binary DER-encoded ASN.1 payloads rather than Base64. Binary format is approximately 30% smaller than Base64-encoded equivalents, making it suitable for constrained CoAP environments.
Server-side key generation responses (/skg, /skc) use Content-Format 62 (application/multipart-core, RFC 8710), encoded as a CBOR array of four items: [Content-Format-ID, key-bytes, Content-Format-ID, cert-bytes]. For /skg: [284, key, 281, cert]; for /skc: [280, enc-key, 287, cert].
The CoAP Accept Option is used in requests to express the preferred response Content-Format (281 or 287). If no Accept Option is included, the server SHOULD choose Content-Format 281 (PKCS #7 container).