EST (Enrollment over Secure Transport) Extensions
Extracted elements (28)
Encryption of symmetric keys beyond what TLS already provides is OPTIONAL because TLS already provides confidentiality; however, when additional encryption is used, several CMS content type nesting options are supported (plain DER, enveloped-data over signed-data, signed-data over enveloped-data, or CCC encrypted key package) to accommodate different server capabilities and security policies.
The /eecerts and /crls path components are intentional push-only mechanisms rather than general-purpose repository queries: the server knows a priori (via out-of-band configuration) which peer certificates and CRLs the client will need, so pushing them during bootstrapping avoids requiring the client to parse CRL Distribution Point extensions and make additional round trips.
The PAL uses a special package type 0001 ('Additional PAL value present') rather than a fixed maximum size to accommodate clients with small memory constraints. Servers can split large PALs across multiple linked PAL objects without imposing a single universal size limit.
Clients that support CCC (CMS Content Constraints, RFC 6010) can signal support for the encrypted key package OID via a content type attribute in the CSR; if the client knows a priori that the server supports it, inclusion of the attribute in the CSR is not required.
The PKCS #12 server-side key generation response (HTTP 200, application/pkcs12 with private key and certificate in the same PFX) differs from RFC 7030 Section 4.4.2, which returns them separately. The DecryptKeyIdentifier (enveloping) specified in RFC 7030 is not supported for PKCS #12.
Clients MUST reject CRLs (distributed via /crls) that do not validate to an authorized Trust Anchor.
Clients MUST reject EE certificates (distributed via /eecerts) that do not validate to an authorized Trust Anchor.
For PKCS #12 server-side key generation, the server MUST ignore the public key values and signature in the CSR; they are included only to allow reuse of existing codebases for generating and parsing requests.
For symmetric key distribution, clients MUST authenticate the server and check server authorization; the server MUST authenticate the client and check client authorization. The cipher suite used to return the symmetric key MUST offer cryptographic strength commensurate with the key being delivered, and MUST NOT use the NULL encryption algorithm.
For TAMP packages returned via /tamp, clients MUST support validation with a certificate (in addition to direct TA validation as specified in RFC 5934) and MUST reject the package if the digital signature does not validate back to an authorized TA.
If a firmware package is digitally signed, the client MUST reject it if the digital signature does not validate back to an authorized TA. If a firmware receipt or error is digitally signed, the server MUST reject it if the digital signature does not validate back to an authorized TA.
If a symmetric key package (or encrypted key package) that is digitally signed is received by the client, the client MUST reject it if the digital signature does not validate back to an authorized TA. The server similarly MUST reject a digitally signed key package receipt or error that does not validate to an authorized TA.
If the server has a PAL for the client, the server response MUST contain an HTTP 200 response code with Content-Type 'application/xml' or 'application/json'.
In each PAL entry, the 'type', 'size', and 'info' fields MUST all be present. The 'info' field MUST include exactly one of dn, ski, iasn, or uri.
It is strongly RECOMMENDED that servers always return encrypted symmetric keys; additional encryption beyond TLS (e.g., AES Key Wrap) is OPTIONAL.
PAL package type 0001 (Additional PAL value present) MUST be the last entry in the PAL if it appears, and MUST NOT be the only entry in the PAL, in order to avoid needlessly dereferencing URIs.
RFC 8295 defines six new EST path components extending /.well-known/est: /pal (Package Availability List), /eecerts (end-entity certificates), /crls (certificate revocation lists), /symmetrickeys, /firmware, and /tamp, plus extensions to the existing /serverkeygen path component for PKCS #12 and asymmetric key receipts.
The /eecerts path component allows servers to push peer end-entity certificates (in a certs-only CMS degenerate signed-data, application/pkcs7-mime) to clients that will need them for communicating with known peers; it is a pure push mechanism, not a general-purpose repository query.
The /firmware path component (HTTP GET) distributes RFC 4108 firmware packages, which may be unprotected, compressed, encrypted, or signed CMS content using application/cms. The /firmware/return path (HTTP POST) allows clients to return firmware load receipts and errors; server acknowledges with HTTP 204.
The PAL (Package Availability List) is an XML or JSON document available at /pal that advertises packages a client may retrieve, notifications to begin certificate management, and pointers to additional PALs. Each PAL entry has four fields: type (4-digit code), date (last successful download time), size (bytes), and info (URI, DN, SKI, or IssuerAndSerialNumber).
The /serverkeygen path component is extended to support PKCS #12 (PFX, RFC 7292): the client POSTs a PKCS #10 CSR, and on success the server returns HTTP 200 with Content-Type 'application/pkcs12' containing a base64-encoded DER PFX that bundles both the private key and the certificate. Password-based encryption (PBE) shrouding is supported; the DecryptKeyIdentifier from RFC 7030 is not used with PKCS #12.
The /serverkeygen/return path component (HTTP POST) extends RFC 7030's /serverkeygen to support returning asymmetric key package receipts and errors (RFC 7191). Additionally, /serverkeygen responses may now return keys encapsulated in broader CMS content types including the encrypted key package (RFC 6032) with EncryptedData, EnvelopedData, or AuthEnvelopedData, with EnvelopedData being mandatory-to-implement.
The /symmetrickeys path component (HTTP GET) distributes CMS-encapsulated symmetric key packages (RFC 6031) to clients. The /symmetrickeys/return path component (HTTP POST) allows clients to return key package receipts or errors (RFC 7191). Success responses from the server on /return are HTTP 204 with no content.
The /tamp path component (HTTP GET) distributes TAMP (RFC 5934) packages—Status Query, Trust Anchor Update, Apex Trust Anchor Update, Community Update, Sequence Number Adjust—to manage trust anchor databases on clients. The /tamp/return path (HTTP POST) returns TAMP responses, confirms, and errors with RFC 5934 MIME types.
Section 11.1 registers the PAL XML namespace 'urn:ietf:params:xml:ns:pal', and Section 11.2 registers the PAL XML schema under the IETF XML registry.
Section 11.3 establishes the PAL Package Types registry with values 0000–0037, covering reserved, additional PAL pointer, X.509 CA/EE certificates, CRLs/ARLs, DS and KE certificate enrollment lifecycle codes (0006–0019), asymmetric key package variants (PKCS #8, CMS, PKCS #12) and their receipts/errors, symmetric key packages, firmware packages, and the full suite of TAMP operation types.
Absent a client-side policy requiring a signature on symmetric or asymmetric key packages, a malicious EST server can strip the signature, bypassing the validation check entirely. The signature-validation requirement is therefore only a sanity check against mis-signed packages or misconfiguration, not a strong security guarantee without a corresponding client policy.
A PAL entry's 'date' field MUST be encoded as Generalized Time in exactly 20 characters (YYYY-MM-DDTHH:MM:SSZ); implementations SHOULD NOT rely on sub-second resolution and MUST NOT generate leap-second instants. The 'type' field is a 4-digit string; 'size' is a nonNegativeInteger (zero means the client must initiate a transaction or return a receipt/error); 'info' is a choice of dn (string per RFC 4514), ski (hexBinary), iasn (issuer+serial), or uri.