EST uses a three-layer stack—EST messages over HTTP over TLS over TCP—so that the TLS and HTTP layers supply proof-of-identity, allowing the Simple PKI (PKCS #10) message type to be used. Per CMC Section 3.1, the Simple PKI Request MUST NOT be used if proof-of-identity must be included in the message itself; by delegating identity proof to the transport layers, EST avoids the complexity of Full PKI messages for the common case.

pkix, tls, http, security

HTTP 3xx redirections to the same web origin (RFC 6454) SHOULD be handled automatically by the client if all applicable security checks have been enforced on the initial connection. Redirections to other web origins require a new TLS connection with all security checks, and if a CSR already embeds tls-unique information it MUST be recreated to incorporate the tls-unique of the new TLS session.

http, tls, pkix

When an EST server returns HTTP 202 to a /simpleenroll or /simplereenroll request (indicating the request is accepted but pending manual administrator review), it MUST include a Retry-After header. The client MUST wait at least the specified retry-after interval and then repeat the identical request; the server is stateful for retries while the client is stateless.

http, pkix

Certificate validation MUST be performed as per RFC 5280. Both the EST server certificate and EST client certificate MUST conform to the RFC 5280 certificate profile.

pkix, security, tls

EST clients and servers MUST support the /cacerts, /simpleenroll, and /simplereenroll functions. Support for /fullcmc, /serverkeygen, and /csrattrs is OPTIONAL.

pkix, http

For server-side key generation, cipher suites with a NULL confidentiality algorithm MUST NOT be used as they will disclose the contents of an unprotected private key. The cipher suite MUST offer confidentiality commensurate with the private key being delivered.

pkix, security, crypto, tls

For /simplereenroll, the request Subject field and SubjectAltName extension MUST be identical to the corresponding fields in the certificate being renewed or rekeyed. Name changes are indicated using the ChangeSubjectName attribute from RFC 6402.

pkix

HTTP Basic and Digest authentication MUST only be performed over TLS 1.1 or later. NULL and anon cipher suites MUST NOT be used because they do not provide confidentiality or support mutual authentication.

http, tls, security, pkix

HTTPS MUST be used for all EST communications. TLS 1.1 (RFC 4346) or a later version MUST be used. TLS session resumption SHOULD be supported.

tls, pkix, security

Implementations conforming to this standard MUST provide the ability to designate Explicit Trust Anchors and MUST provide the ability to disable use of any Implicit TA database.

pkix, security, tls

The client MUST check EST server authorization before accepting any server responses or responding to HTTP authentication requests. When the Explicit TA database is used, the client MUST check the URI against the server's identity per RFC 6125 Section 6.4, or the EST server certificate MUST contain the id-kp-cmcRA extended key usage extension.

pkix, security, tls

The client MUST NOT respond to the server's HTTP authentication request unless the client has already authorized the EST server (as per Section 3.6). This prevents credential disclosure to unauthenticated servers.

http, security, pkix

The EST server MUST be authenticated during the TLS handshake unless the client is requesting Bootstrap Distribution of CA certificates (Section 4.1.1) or Full CMC (Section 4.3). TLS server authentication with certificates MUST be supported.

tls, pkix, security

When performing TLS renegotiation, TLS secure_renegotiation (RFC 5746) MUST be used. Clients SHOULD link identity and POP by embedding tls-unique information in the certification request; if tls-unique information is included by the client, the server MUST verify it.

tls, pkix, security

When using certificate-less mutual authentication in TLS for enrollment, the cipher suite MUST be resistant to dictionary attack and MUST be based on a zero-knowledge protocol. TLS-SRP cipher suites (those with _SRP_ in the name per RFC 5054) are suitable.

tls, security, crypto, pkix

Bootstrap Distribution of CA Certificates allows minimally configured clients with no TA database to provisionally complete a TLS handshake with the EST server unauthenticated, retrieve /cacerts, and then have a human user verify the CA certificate fingerprint (e.g., SHA-256 or SHA-512 hash) out-of-band before establishing the Explicit TA database.

pkix, security, tls

EST defines six operations mapped to URI path suffixes under /.well-known/est/: /cacerts (distribution of CA certificates), /simpleenroll (initial enrollment), /simplereenroll (renewal/rekey), /fullcmc (Full CMC, optional), /serverkeygen (server-side key generation, optional), and /csrattrs (CSR attributes, optional). An optional CA label path segment between 'est' and the operation path allows a single server to serve multiple CAs.

pkix, http, registry

EST maintains two distinct trust anchor database types on both client and server: Explicit TAs (specifically configured for EST use) and Implicit TAs (broadly available TAs such as those used by web browsers). The client MUST maintain this distinction to support proper authorization; using Implicit TAs allows verifying third-party-issued server certificates but carries different authorization semantics.

pkix, security, tls

Linking of identity and proof-of-possession is achieved by embedding the TLS session's tls-unique value (RFC 5929) as a base64-encoded string in the CSR challenge-password field (RFC 2985 Section 5.4.1). This proves that the authenticated TLS client possesses the private key and generated the CSR after the TLS session was established.

pkix, tls, security, crypto

Server-side key generation allows the EST client to receive a server-generated private key and certificate via /serverkeygen. The private key may optionally be protected with CMS EnvelopedData encryption (symmetric via DecryptKeyIdentifier or asymmetric via AsymmetricDecryptKeyIdentifier) in addition to TLS transport security.

pkix, crypto, security

RFC 7030 defines and registers the application/csrattrs media type for carrying CSR Attributes responses, and registers the /.well-known/est URI path for the EST service under the RFC 5785 Well-Known URIs registry.

pkix, registry, http

RFC 7030 Section 4.4.1.2 defines and registers a new CMS attribute OID id-aa-asymmDecryptKeyID (id-aa 54) with ASN.1 type AsymmetricDecryptKeyIdentifier ::= OCTET STRING, used by EST clients to specify an asymmetric public key for encrypting the server-generated private key.

pkix, registry, crypto

Server-side key generation creates a server that knows a client's private key. It is strongly RECOMMENDED that clients request CMS EnvelopedData wrapping of the private key in addition to TLS transport protection. The server is responsible for proper random number and key generation (RFC 4086); server archiving of generated keys is governed by CA policy.

security, pkix, crypto

Use of an Implicit TA database to authenticate an EST server carries risk: the Implicit TA may authenticate a server that is authorized for other purposes (e.g., HTTPS web browsing) but not specifically authorized as an EST server. Clients that successfully populate an Explicit TA database SHOULD disable the Implicit TA for that EST server and include the Trusted CA Indication TLS extension (RFC 6066) in future sessions.

security, pkix, tls

CSR Attributes responses use Content-Type application/csrattrs with Content-Transfer-Encoding base64. The body is a DER-encoded ASN.1 SEQUENCE of AttrOrOID elements, where each element is either an OBJECT IDENTIFIER or an Attribute. An empty SEQUENCE is equivalent to HTTP 204 or 404.

pkix, http

Server-side key generation (/serverkeygen) successful responses use Content-Type multipart/mixed with two parts: the private key as application/pkcs8 (base64 DER PrivateKeyInfo) if unencrypted, or application/pkcs7-mime with smime-type server-generated-key if CMS EnvelopedData-encrypted; plus the certificate as application/pkcs7-mime matching the /simpleenroll response format.

pkix, http, crypto

Simple enrollment (/simpleenroll, /simplereenroll) requests use Content-Type application/pkcs10 with Content-Transfer-Encoding base64, carrying a PKCS #10 CSR (RFC 2986). Successful responses use Content-Type application/pkcs7-mime with smime-type certs-only, containing only the issued certificate.

pkix, http

The /cacerts response MUST be a certs-only CMC Simple PKI Response (RFC 5272) using Content-Type application/pkcs7-mime with Content-Transfer-Encoding base64. It MUST include the current root CA certificate and all intermediate CA certificates needed to build a chain to the root.

pkix, http