+--------------------+--------------------------+-------------------+
| Message type       |Request media type        | Request section(s)|
|                    |Response media type(s)    | Response section  |
|                    |Source(s) of types        |                   |
+====================+==========================+===================+
| CA certificate     | N/A                      | Section 4.1       |
| request            | application/pkcs7-mime   | Section 4.1.1     |
|                    | [RFC5751]                |                   |
+--------------------+--------------------------+-------------------+
| Cert enroll/renew/ | application/pkcs10       | Section 4.2/4.2.1 |
| rekey              | application/pkcs7-mime   | Section 4.2.2     |
|                    | [RFC5967] [RFC5751]      |                   |
+--------------------+--------------------------+-------------------+
| Full CMC           | application/pkcs7-mime   | Section 4.3.1     |
|                    | application/pkcs7-mime   | Section 4.3.2     |
|                    | [RFC5751]                |                   |
+--------------------+--------------------------+-------------------+
| Server-side Key    | application/pkcs10       | Section 4.4.1     |
| Generation         | multipart/mixed          | Section 4.4.2     |
|                    | (application/pkcs7-mime &|                   |
|                    | application/pkcs8)       |                   |
|                    | [RFC5967] [RFC5751] &    |                   |
|                    | [RFC5958]                |                   |
+--------------------+--------------------------+-------------------+
| Request CSR        | N/A                      | Section 4.5.1     |
| attributes         | application/csrattrs     | Section 4.5.2     |
|                    | This RFC                 |                   |
+--------------------+--------------------------+-------------------+

Figure 6

3.3. TLS Layer

TLS provides communications security for the layers above it. The integrity and confidentiality services it provides are leveraged to supply proof-of-identity and to allow authorization decisions to be made. The EST server and EST client are responsible for ensuring that an acceptable cipher suite is negotiated and that bidirectional authentication has been performed. Alternately, certificate-less TLS authentication, where neither the client nor server present a certificate, is also an acceptable method for EST authentication.

HTTPS [RFC2818] and specifies how HTTP messages are carried over TLS. HTTPS MUST be used. TLS 1.1 [RFC4346] (or later) MUST be supported. TLS session resumption [RFC5077] SHOULD be supported.

TLS channel binding information MAY be inserted into a certificate request as detailed in Section 3.5 in order to provide the EST server with assurance that the authenticated TLS client has access to the private key for the certificate being requested.

3.3.1. TLS-Based Server Authentication

The EST server MUST be authenticated during the TLS handshake unless the client is requesting Bootstrap Distribution of CA certificates [BootstrapCACerts] or Full CMC [FullCMC].

The EST client authenticates the EST server as defined for the cipher suite negotiated. The following text provides details assuming a certificate-based cipher suite, such as the TLS 1.1 [RFC4346] mandatory cipher suite (TLS_RSA_WITH_3DES_EDE_CBC_SHA). As an alternative to authentication using a certificate, an EST client MAY support certificate-less TLS authentication (Section 3.3.3).

Certificate validation MUST be performed as per [RFC5280]. The EST server certificate MUST conform to the [RFC5280] certificate profile.

The client validates the TLS server certificate using the EST client TA databases. If certificate validation fails, the client MAY follow the procedure outlined in Section 4.1.1 for bootstrap distribution of CA certificates.

The EST client MUST perform authorization checks as specified in Section 3.6.

3.3.2. TLS-Based Client Authentication

TLS client authentication is the RECOMMENDED method for identifying EST clients. HTTP-Based Client Authentication [HTTPuserAuthCandAuthZ] MAY be used.

The EST server authenticates the EST client as defined for the cipher suite negotiated. The following text provides details assuming a certificate-based cipher suite such as the TLS 1.1 [RFC4346] mandatory cipher suite (TLS_RSA_WITH_3DES_EDE_CBC_SHA). The EST server MUST support certificate based client authentication. As an alternative or as an addition to authentication using a certificate, an EST server MAY support certificate-less TLS authentication [TLSmutualAuth].

When requesting renew/rekey operations the client MUST use the existing client certificate that was issued by the EST server unless this certificate is not appropriate for the negotiated cipher suite. In that case, the client SHOULD use an alternate certificate, with the same subject identity information, that is appropriate for the negotiated cipher suite. When requesting an enroll operation the client MAY use a third-party issued client certificate. The EST server MUST perform authorization checks as specified in Section 3.7.

If a client does not support TLS client authentication, then it MUST support HTTP-based client authentication [HTTPuserAuthCandAuthZ] or certificate-less TLS authentication [TLSmutualAuth].

3.3.3. Certificate-less TLS Mutual Authentication

Certificate-less TLS ciphersuites provide a way to perform mutual authentication in situations where neither the client nor server have certificates, or do not have a way to verify a certificate. The client and server MAY negotiate a certificate-less cipher suite for mutual authentication. Existing documents such as [TLS-SRP] [RFC5054] and [TLS-SRP] [RFC2712] present techniques for a certificate-less TLS connection.

When using certificate-less mutual authentication in TLS for enrollment, the cipher suite MUST be resistant to dictionary attack. This means that the advantage an adversary gains through attack MUST be related to interaction and not computation. TLS cipher suites used with EST to perform certificate-less TLS mutual authentication MUST be based on a zero knowledge protocol to enable proof of knowledge of the shared secret without exposure of the shared secret (or any derived data which can be used to determine the secret). These requirements mean that the adversary gains advantage solely through active attack, and the only thing learned from each active attack is whether a single guess of the secret is successful or not. Implementations of EST that support certificate-less TLS cipher suites SHOULD provide countermeasures, e.g., exponential back off after failed attempts or locking of an account after a certain number of unsuccessful attempts, to mitigate repeated, active attacks.

A certificate-less ciphersuite MUST provide sufficient information to perform the authorization checks. For example if the cipher suite uses a pre-shared secret, provisioned in an out-of-band fashion, as a credential to perform mutual authentication then knowledge of the pre-shared secret implies authorization as a peer in the exchange.

3.4. Proof-of-Possession

As defined in Section 2.1 of CMC [RFC5272], Proof-of-possession (POP) "refers to a value that can be used to prove that the private key corresponding to the public key is in the possession and can be used by an end-entity."

The signed enrollment request provides a signature-based proof-of-possession. The mechanism described in Section 3.5 strengthens this by optionally including "Direct"-based proof-of-possession [RFC5272] by including TLS session-specific information within the data covered by the enrollment request signature (thus linking the enrollment request to the authenticated end-point of the TLS connection).

3.5. Linking Identity and PoP information

Server policy determines whether the server requires that the TLS client identity and proof-of-posession of the private key associated with a certification are linked. This specification provides an OPTIONAL method of linking identity and proof-of-possession by including information specific to the current authenticated TLS session within the signed certification request. Clients are RECOMMENDED to link identity and PoP. If the client does not have local policy configuration the client MAY determine that this method is expected by examining the CSR Attributes Response (see Section 4.5.2). The EST server MUST verify the tls-unique information embedded within the certification request if it is included in the request. The EST server MAY reject requests without tls-unique information as indicated by server policy.

Linking identity and proof-of-possession proves to the server that the authenticated TLS client has possession of the private key associated with the certification request and that the client was able to sign the certification request after the TLS session was established. This is an alternative to the [RFC5272] Section 6.3-defined "Linking Identity and POP information" method available if Full PKI messages are used.

The client generating the request obtains the tls-unique value as defined in Channel Bindings for TLS [RFC5929] from the TLS subsystem. The tls-unique specification includes a synchronization problem as described in Channel Bindings for TLS [RFC5929] section 3.1. To avoid this problem, EST implementations that support this feature MUST use the tls-unique value from the first TLS handshake. EST clients and servers use their tls-unique implementation specific synchronization methods to obtain this first tls-unique value. TLS "secure_renegotiation" [RFC5746] MUST be used. This maintains the binding from the first tls-unique value across renegotiations to the most recently negotiated connection.

The tls-unique value is Base 64 encoded as specified in Section 4 of [RFC4648] and the resulting string is placed in the certification request challenge-password field ([RFC2985], Section 5.4.1). If tls-unique information is not embedded within the certification request the challenge-password field MUST be empty to indicate that the client did not include the optional channel-binding information (any value submitted is verified by the server as tls-unique information).

If the EST server forwards the request to back-end infrastructure for processing, it is RECOMMENDED that the results of this verification be communicated. (For example this communication might use the CMC [RFC5272] "RA POP Witness Control" in a CMC Full PKI Request message. Or an EST server might TLS authenticate an EST client as being a trusted infrastructure element that does not forward invalid requests. A detailed discussion of back-end processing is out of scope).

When rejecting requests, the EST server response is as described for all enroll responses (Section 4.2.3). If a Full PKI Response is included, the CMCFailInfo MUST be set to popFailed. If a human readable reject message is included it SHOULD include an informative text message indicating that linking of identity and POP information is required.

3.6. Server Authorization

The client MUST check EST server authorization before accepting any server responses or responding to HTTP authentication requests.

When the EST client Third-Party TA database is used to validate the EST server certificate the client MUST check the URI "against the server's identity as presented in the server's Certificate message" (HTTP Over TLS Section 3.1 "Server Identity" [RFC2818] and [RFC6125]). The provisioned URI provides the basis for authorization, and the server's authenticated identity confirms it is the authorized server.

When the EST client Absolute TA database is used to validate the EST server certificate the client MUST check either the URI against the server's identity or the EST server certificate MUST contain the id-kp-cmcRA [RFC6402] extended key usage extension. The client MUST maintain a distinction between the Absolute TA database and any Third-Party TAs database in order to make this determination.

Successful authentication using a certificate-less cipher suite implies authorization of the server.

The client MAY perform bootstrapping as specified in Section 4.1.1 even if these checks fail.

3.7. Client Authorization

The decision to issue a certificate to a client is always controlled by local CA policy. The EST server configuration reflects this CA policy. This document does not specify any constraints on such policy. EST provides the EST server access to each client's authenticated identity -- e.g., the TLS client's certificate in addition to any HTTP user authentication credentials -- to help in implementing such policy.

If the client's certificate was issued by the EST CA, and it includes the id-kp-cmcRA [RFC6402] extended key usage extension, then the client is a Registration Authority (RA) as described in [RFC5272] and [RFC6402]. In this case the EST server SHOULD apply authorization policy consistent with an RA client. For example when handling /simpleEnroll requests the EST server could be configured to accept PoP linking information that does not match the current TLS session because the authenticated EST client RA has verified this information when acting as an EST server (as specified in Section 3.5). More specific RA mechanisms are available if the EST client uses /fullCMC methods.

4. Protocol Exchange Details

Before processing a request, an EST server determines if the client is authorized to receive the requested services. Likewise, the client determines if it will make requests to the EST server. These authorization decisions are described in the next two sections. Assuming that both sides of the exchange are authorized, then the actual operations are as described in subsequent sections.

4.1. Distribution of CA certificates

The EST client can request a copy of the current CA certificates. This function is generally performed before other EST functions.

4.1.1. Bootstrap Distribution of CA certificates

When the EST server uses an EST CA issued certificate for TLS server authentication it is possible that the client was not configured with the Absolute TA database necessary to validate the server certificate. This section describes methods by which minimally configured EST clients can populate their Absolute TA database.

If the EST client application does not specify either an Absolute TA database or a Third-party TA database then the initial TLS server authentication and authorization will fail. The client MAY provisionally continue the TLS handshake to completion for the purposes of accessing the /CACerts or /fullCMC method. If the EST client continues with an unauthenticated connection, the client MUST extract the HTTP content data from the response (Section 4.1.3 or Section 4.3.2) and engage a human user to authorize the CA certificate using out-of-band data such as a CA certificate "fingerprint" (e.g., a SHA-1, SHA-256, SHA-512 [SHS], or MD5 [RFC1321] hash on the whole CA certificate). In a /fullCMC response it is the Publish Trust Anchors control within the Full PKI Response that must be accepted manually. It is incumbent on the user to properly verify the TA information, or to provide the "fingerprint" data during configuration that is necessary to verify the TA information.

HTTP authentication requests MUST NOT be responded to if the server has not been authenticated. The EST client uses the /CACerts response to establish a trust anchor for subsequent TLS authentication of the EST server. EST clients MUST NOT engage in any other protocol exchange until after the /CACerts response has been accepted and a new TLS session has been established (using TLS certificate-based authentication).

4.1.2. Distribution of CA certificates request

EST clients request the Absolute TA database information of the CA (in the form of certificates) with an HTTPS GET message using an operation path of "/CACerts". EST clients and servers MUST support the /CACerts function. Clients SHOULD request an up-to-date response before stored information has expired in order to ensure the EST CA TA database is up to date.

The EST server MUST NOT require client authentication or authorization to reply to this request.

The client MUST authenticate the EST server as specified in Section 3.3.1 and Section 3.3.3 and check the server's authorization as given in Section 3.6 or follow the procedure outlined in Section 4.1.1.

4.1.3. Distribution of CA certificates response

The EST server responds to a Distribution of CA certificates request with the EST CA certificates within a Simple PKI Response. If the certificates are successfully returned, the server response MUST have an HTTP 200 response code with a content-type of "application/pkcs7-mime". Any other response code indicates an error and the client MUST abort the protocol.

The EST server MUST include the current root CA certificate in the response. The EST server MUST include any additional certificates the client would need to build a chain from an EST CA issued certificate to the current Absolute TA. For example if the EST CA is a subordinate CA then all the appropriate subordinate CA certificates necessary to build a chain to the root EST CA are included in the response.

The EST server SHOULD include the three "Root CA Key Update" certificates OldWithOld, OldWithNew, and NewWithOld in the response chain. These are defined in Section 4.4 of CMP [RFC4210]. The EST client MUST be able to handle these certificates in the response. The CA's most recent self-signed certificate (e.g. NewWithNew certificate) is self-signed and has the latest NotAfter date. This the Absolute TA in the form of a self-signed certificate. If the EST server does not include these in the response then after the current Absolute TA certificate expires the EST clients will need to be (re)enrolled with the PKI using the Bootstrap Distribution of CA certificates [BootstrapCACerts] method.

The Absolute TA certificate is the certificate that is either application supplied or is extracted and authorized using out-of-band information as described in Section 4.1.1. After out-of-band validation occurs, all the other certificates MUST be validated using normal [RFC5280] certificate path validation (using the most recent CA certificate as the TA) before they can be used to build certificate paths during certificate validation.

The response format is the CMC Simple PKI Response, as defined in [RFC5272]. The HTTP content-type of "application/pkcs7-mime" is used. The Simple PKI response is Base64 encoded, as specified in Section 4 of [RFC4648], and sandwiched between headers:

-----BEGIN PKCS7-----
MIIBhDCB7gIBADBFMQswCQYDVQQGEwJBVTETMBEGA1UECBMKU29tZS1TdGF0ZTEh
Simplified example of Base64 encoding of CMC Simple PKI Response
ED8rf3UDF6HjloiV3jBnpetx4JjZH/BlmD9HMqofVEryb1e4iZgMUvuIgwEjQwpD
8J4OhHvLh1o=
-----END PKCS7-----

4.2. Client Certificate Request Functions

EST clients request a certificate from the EST server with an HTTPS POST using the operation path value of "/simpleEnroll". EST clients request a renew/rekey of existing certificates with an HTTP POST using the operation path value of "/simpleReEnroll". EST servers MUST support the /simpleEnroll and /simpleReEnroll functions.

It is RECOMMENDED that a client obtain the current CA certificates, as described in Section 4.1, before performing certificate request functions. This ensures that the client will be able to validate the EST server certificate. The client MUST authenticate the EST server as specified in Section 3.3.1 and Section 3.3.3. The client MUST verify the authorization the EST server as specified in Section 3.6.

The server MUST authenticate the client as specified in Section 3.3.2 and Section 3.3.3. The server MUST verify client authorization as specified in Section 3.7. The EST server MUST check the tls-unique value as described in Section 3.5 if one is submitted by the client.

The server MAY accept a certificate request for manual authorization checking by an administrator. (Section 4.2.3 describes the use of an HTTP 202 response to the EST client if this occurs).

4.2.1. Simple Enrollment of Clients

When HTTPS POSTing to /simpleEnroll the client MUST include a Simple PKI Request as specified in CMC [RFC5272] Section 3.1 (i.e., a PKCS#10 Certification Request [RFC2986]).

The Certification Signing Request (CSR) signature provides proof-of-possession of the private key to the EST server. If the CSR KeyUsage extension indicates the private key can be used to generate digital signatures then the CSR signature MUST be generated using the private key. If the key can be used to generate digital signatures but the requested CSR KeyUsage extension prohibits generation of digital signatures then the CSR signature MUST still be generated using the private key but the key MUST NOT be used to for any other signature operations (this is consistent with the recommendations concerning submission of proof-of-possession to an RA or CA as described in [SP-800-57-Part-1]). The use of /fullCMC operations provides access to more advanced proof-of-possession methods that MUST be used when the key pair can not be used for digital signature generation (see Section 4.3).

The HTTP content-type of "application/pkcs10" is used here. The format of the message is as specified in Section 6.4 of [RFC4945].

The EST client MAY request additional certificates even when using an existing certificate in the TLS client authentication. For example the client can use an existing certificate for TLS client authentication when requesting a certificate that cannot be used for TLS client authentication.

4.2.2. Simple Re-Enrollment of Clients

EST clients renew/rekey certificates with an HTTPS POST using the operation path value of "/simpleReEnroll".

A certificate request employs the same format as the "simpleEnroll" request, using the same HTTP content-type. The request Subject field and SubjectAltName extension MUST be identical to the corresponding fields in the certificate being renewed/rekeyed. The ChangeSubjectName attribute, as defined in [RFC6402], MAY be included in the CSR to request that these fields be changed in the new certificate.

If the Subject Public Key Info in the certification request is the same as the current client certificate, the EST server performs a renew operation. If the public key information is different than the currently issued certificate then the EST server performs a rekey operation.

4.2.3. Simple Enroll and Re-Enroll Response

If the enrollment is successful, the server response MUST contain an HTTP 200 response code with a content-type of "application/pkcs7-mime". The response data is a certs-only Simple PKI Response containing only the certificate that was issued. The Simple PKI response is Base64 encoded and sandwiched between headers:

-----BEGIN PKCS7-----
MIIBhDCB7gIBADBFMQswCQYDVQQGEwJBVTETMBEGA1UECBMKU29tZS1TdGF0ZTEh
Simplified example of Base64 encoding of CMC Simple PKI Response
ED8rf3UDF6HjloiV3jBnpetx4JjZH/BlmD9HMqofVEryb1e4iZgMUvuIgwEjQwpD
8J4OhHvLh1o=
-----END PKCS7-----

When rejecting a request the server MUST specify either an HTTP [RFC2616] 4xx error, or an HTTP 5xx error. A Simple PKI Response with an HTTP content-type of "application/pkcs7-mime" (see Section 4.3.2) MAY be included in the response data to convey an error response. If the content-type is not set the response data MUST be a plain text human-readable error message containing informative information describing why the request was rejected (for example indicating that CSR attributes are incomplete).

If the server responds with an HTTP [RFC2616] 202, this indicates that the request has been accepted for processing but that a response is not yet available. The server MUST include a Retry-After header as defined for HTTP 503 responses. The server also MAY include informative human-readable content. The client MUST wait at least the specified 'retry-after' time before repeating the same request. The client repeats the initial enrollment request after the appropriate 'retry-after' interval has expired. The client SHOULD log or inform the end user of this event. The server is responsible for maintaining all state necessary to recognize and handle retry operations as the client is stateless in this regard; it simply sends the same request repeatedly until it receives a different response code.

All other return codes are handled as specified in HTTP [RFC2616].

4.3. Full CMC

An EST client can request a certificate from an EST server with an HTTPS POST using the operation path value of "/fullCMC". Support for the /fullCMC function is OPTIONAL for both clients and servers.

4.3.1. Full CMC Request

If the HTTP POST to /fullCMC is not a valid Full PKI Request, the server MUST reject the message. The HTTP content-type used is "application/pkcs7-mime", as specified in [RFC5273].

4.3.2. Full CMC Response

The server responds with the client's newly issued certificate or provides an error response.

If the enrollment is successful, the server response MUST include an HTTP 200 response code with a content-type of "application/pkcs7-mime" as specified in [RFC5273]. The response data includes either the Simple PKI Response or the Full PKI Response as specified in Section 3.2 of [RFC5272].

When rejecting a request, the server MUST specify either an HTTP 4xx error or an HTTP 5xx error. A CMC response with content-type of "application/pkcs7-mime" SHOULD be included in the response data for any CMC error response. If the content-type is not set the response data MUST be a plain text human-readable error message containing informative information describing why the request was rejected (for example indicating that CSR attributes are incomplete).

All other return codes are handled as specified in Section 4.2.3 or HTTP [RFC2616]. For example, a client interprets a HTTP 404 or 501 response to indicate that this service is not implemented.

The Full PKI Response is Base64 encoded and sandwiched between headers:

-----BEGIN PKCS7-----
MIIBhDCB7gIBADBFMQswCQYDVQQGEwJBVTETMBEGA1UECBMKU29tZS1TdGF0ZTEh
Simplified example of Base64 encoding of CMC Full PKI Response
ED8rf3UDF6HjloiV3jBnpetx4JjZH/BlmD9HMqofVEryb1e4iZgMUvuIgwEjQwpD
8J4OhHvLh1o=
-----END PKCS7-----

4.4. Server-side Key Generation

An EST client may request a private key and associated certificate from an EST server using an HTTPS POST with an operation path value of "/serverKeyGen". Support for the /serverKeyGen function is OPTIONAL.

A client MUST authenticate an EST server as specified in Section 3.3.1 and Section 3.3.3.

The EST server MUST authenticate the client as specified in Section 3.3.2 and Section 3.3.3. The server SHOULD use Client Authorization for authorization purposes. The EST server applies whatever authorization or logic it chooses to determine if the private key and certificate should be provided.

Proper random number and key generation [RFC4086] is a server implementation responsibility and server storage of generated keys is a local option. The key pair and certificate are transferred over the TLS session. The cipher suite used to return the private key and certificate MUST offer confidentiality commensurate with the private key being delivered to the client.

The EST client MAY request additional certificates even when using an existing certificate in the TLS client authentication. For example the client can use an existing certificate for TLS client authentication when requesting a certificate that cannot be used for TLS client authentication.

4.4.1. Server-side Key Generation Request

The certificate request is HTTPS POSTed and is the same format as for the "/simpleEnroll" and "/simpeReEnroll" path extensions with the same content-type.

In all respects the server SHOULD treat the CSR as it would any enroll or re-enroll CSR; the only distinction here is that the server MUST ignore the public key values and signature in the CSR. These are included in the request only to allow re-use of existing codebases for generating and parsing such requests.

If the client desires to receive the private key with encryption that exists outside and in addition to that of the TLS transport used by EST or if server policy requires that the key be delivered in such a form, the client MUST include a DecryptKeyIdentifier attribute (as defined in Section 2.2.5, [RFC4108]) specifying the identifier of the secret key to be used by the server to encrypt the private key. While that attribute was originally designated for specifying a firmware encryption key, it exactly mirrors the requirements for specifying a private key encryption key. If the server does not have a secret key matching the identifier specified by the client, the request must be terminated and an error returned to the client. Distribution of the key specified by the DecryptKeyIdentifer to the key generator and the client is outside the scope of this document.

4.4.2. Server-side Key Generation Response

If the request is successful, the server response MUST have an HTTP 200 response code with a content-type of "multipart/mixed" consisting of two parts. One part is the private key data and the other part is the certificate data.

The format in which the private key data part is returned is dependent on whether the private key is being returned with additional encryption on top of that provided by TLS.

• If additional encryption is being employed, the private key data part MUST be an "application/pkcs7-mime". The content of this message is an Asymmetric Key Package (see Section 2 [RFC5958]) protected inside of a CMS [RFC5652] SignedData content which is further protected inside of a CMS EnvelopedData, as described in Section 4 of [RFC5958]. The Signed Data is signed by the party that generated the private key, which may or may not be the EST server. The EnvelopedData content is encrypted using the secret key identified in the request.
• If additional encryption is not being employed, the private key data MUST be an "application/pkcs8". An "application/pkcs8" part consists of the Base64 encoded DER-encoded PrivateKeyInfo sandwiched between headers as described in [RFC5958].

The certificate data part is an "application/pkcs7-mime" and exactly matches the certificate response to /simpleEnroll. If both parts are "application/pkcs7-mime" the client checks each; one will be a certs-only Simple PKI response and the other will be the CMS message with the encrypted data.

-----BEGIN PRIVATE KEY-----
MIIBhDCB7gIBADBFMQswCQYDVQQGEwJBVTETMBEGA1UECBMKU29tZS1TdGF0ZTEh
Simplified example of Base64 encoding of DER-encoded PrivateKeyInfo
ED8rf3UDF6HjloiV3jBnpetx4JjZH/BlmD9HMqofVEryb1e4iZgMUvuIgwEjQwpD
8J4OhHvLh1o=
-----END PRIVATE KEY-----

or

-----BEGIN PKCS7-----
MIIBhDCB7gIBADBFMQswCQYDVQQGEwJBVTETMBEGA1UECBMKU29tZS1TdGF0ZTEh
Simplified example of Base64 encoding of CMS secured Private key
ED8rf3UDF6HjloiV3jBnpetx4JjZH/BlmD9HMqofVEryb1e4iZgMUvuIgwEjQwpD
8J4OhHvLh1o=
-----END PKCS7-----

When rejecting a request, the server MUST specify either an HTTP 4xx error, or an HTTP 5xx error. If the content-type is not set, the response data MUST be a plain text human-readable error message.

4.5. CSR Attributes

CA policy may allow inclusion of client-provided attributes in certificates that it issues, and some of these attributes may describe information that is not available to the CA. In addition, a CA may desire to certify a certain type of public key and a client may not have a priori knowledge of that fact. Therefore, clients SHOULD request a list of expected attributes that are required, or desired, by the CA in an enrollment request, or if dictated by local policy.

Requesting CSR Attributes is optional but clients are advised that CA's may refuse enrollment requests that are not encoded according to the CA's policy.

4.5.1. CSR Attributes Request

The EST client requests a list of CA-desired CSR attributes from the CA by sending an HTTPS GET message to the EST server with an operations path of "/CSRAttrs".

4.5.2. CSR Attributes Response

If locally configured policy for an authenticated EST client indicates a CSR Attributes Response is to be provided, the server response MUST include an HTTP 200 response code. An HTTP response code of 204 or 404 indicates that a CSR Attributes Response is not available. Regardless of the response code, the EST server and CA MAY reject any subsequent enrollment requests for any reason, e.g., incomplete CSR attributes in the request.

If the CA requires a particular crypto system (e.g., certification of a public key based on a certain elliptic curve) it MUST provide that information in the CSR Attributes response. If an EST server requires the linking of identity and PoP information (see Section 3.5) it MUST include the challengePassword OID in the CSR Attributes response.

Responses to attribute request messages MUST be encoded as content type "application/csrattrs". The syntax for application/csrattrs body is as follows:

Csrattrs ::= SEQUENCE SIZE (0..MAX) OF OBJECT IDENTIFIER { }

An EST server includes zero or more object identifiers that it requests the client to include in a certification request. When the server encodes Csrattrs as an empty SEQUENCE it means that the server has no specific additional attributes it requests in a client certification request (this is functionally equivalent to an HTTP response code of 204 or 404.) The sequence is Distinguished Encoding Rules (DER) encoded and then base64 encoded (section 4 of [RFC4648]). The resulting text forms the application/csrattr body, without headers.

For example, if a CA requests a client to submit a certification request containing the Media Access Control (MAC) address [RFC2397] of a device, the challengePassword (indicating that Linking of Identity and POP information is requested, see Section 3.5), to use the the secp384r1 elliptic curve, and to use the SH384 hash function then it sends the following object identifiers:

• macAddress: 1.3.6.1.1.1.1.22
• challengePassword: 1.2.840.113549.1.9.7
• the secp384r1 elliptic curve: 1.3.132.0.4
• the SHA384 hash function: 2.16.840.1.101.3.4.2.2

and encodes them into an ASN.1 SEQUENCE to produce:

• 30 26 06 07 2B 06 01 01 01 01 16 06 09 2A 86 48 86 F7 0D 01 09 07 06 05 2B 81 04 00 04 06 09 60 86 48 01 65 03 04 02 02

and then base64 encodes the resulting ASN.1 SEQUENCE to produce:

• MCYGBysGAQEBARYGCSqGSIb3DQEJBwYFK4EEAAQGCWCGSAFlAwQCAg==

The EST client parses the OID's in the response and handles each OID independently. When an OID indicates a known descriptive CSR attribute type, the client SHOULD include the requested information in the subsequent CSR that it submits, either in the CSR attributes or in any other appropriate CSR field. When an OID indicates a particular way to generate the CSR, the client SHOULD generate its CSR according to the parsed OID. When an OID is of an unknown type the OID MUST be ignored by the client.

5. IANA Considerations

(This section is incomplete)

IANA is requested to register the following:

IANA SHALL update the well-known URI registry with the following filled-in template from [RFC5785].

• URI suffix: est
• Change controller: IETF

IANA SHALL update the Application Media Types registry with the following filled-in template from [RFC4288].

The media subtype for Attributes in a CertificationRequest is application/csrattrs.

• Type name: application
• Subtype name: csrattrs
• Required parameters: None
• Optional parameters: None
• Encoding considerations: binary;
• Security Considerations:

• Clients request a list of attributes that servers wish to be in certification requests. The request/response SHOULD be done in a TLS-protected tunnel.

• Interoperability considerations: None
• Published specification: This memo.
• Applications which use this media type:
• Enrollment over Secure Transport (EST)
• Additional information:

• Magic number(s): None
• File extension: None
• Macintosh File Type Code(s):

• Person & email address to contact for further information:
• Dan Harkins <dharkins@arubanetworks.com>
• Restrictions on usage: None
• Author: Dan Harkins <dharkins@arubanetworks.com>
• Intended usage: COMMON
• Change controller: The IESG

6. Security Considerations

Support for Basic authentication as specified in HTTP [RFC2617] allows the server access to a client's cleartext password. This provides support for legacy username/password databases but requires exposing the plaintext password to the EST server. Use of a PIN or one-time-password can help mitigate such exposure, but it is RECOMMENDED that EST clients use such credentials only once to obtain a client certificate (that will be used during future interactions with the EST server).

When a client uses the Third-Party TA database for certificate validation (see Section 3) then authorization proceeds as specified in Section 3.6. In this situation, the client has validated the server as being a certified-by-a-third-party responder for the URI configured, but cannot verify that the responder is authorized to act as an RA for the PKI in which the client is trying to enroll. Clients using a third-party trust anchor database are RECOMMENDED to only use TLS-based client authentication (to prevent exposing HTTP-based Client Authentication information). It is RECOMMENDED that such clients include "Linking Identity and POP information" (Section 3.5) in requests (to prevent such requests from being forwarded to a real EST server by a MITM). Additionally it is RECOMMENDED that the third-party trust anchor database used for EST server authentication be carefully managed, to reduce the chance of a third-party CA with poor certification practices from being trusted.

When using a certificate-less TLS cipher suite, the shared secret used for authentication and authorization MUST be known only to the two parties to the exchange: the client and the server. Any further sharing of secrets voids the security afforded by a certificate-less cipher suite. Exposure of a shared secret used by a certificate-less cipher suite to a third-party enables client impersonation that can results in corruption of a client's trust anchor database.

As described in CMC Section 6.7 [RFC5272], "For keys that can be used as signature keys, signing the certification request with the private key serves as a POP on that key pair". The inclusion of tls-unique within the certification request links the proof-of-possession to the TLS proof-of-identity by enforcing that the POP operation occurred while the TLS session was active. This implies to the server that the authenticated client currently has access to the private key. If the authenticated client is known to have specific capabilities, such as hardware protection for authentication credentials and key storage, this implication is strengthened but not proven.

The server-side key generation method allows keys to be transported over the TLS connection to the client. The distribution of private key material is inherently risky. Private key distribution uses the encryption mode of the negotiated TLS cipher suite. Keys are not protected by preferred key wrapping methods such as AES Key Wrap [RFC3394] or as specified in [RFC5958] as encryption of the private key beyond that provided by TLS is optional. It is RECOMMEND that EST servers not support this operation by default. It is RECOMMENDED that clients not request this service unless there is a compelling operational benefit. Use of a third-party trust anchor database is NOT RECOMMENDED when server-side key generation is employed. The use of an encrypted CMS Server-side Key Generation Response is RECOMMENDED.

Regarding the CSR attributes that the CA may list for inclusion in an enrollment request, there are no real inherent security issues with the content being conveyed but an adversary who is able to interpose herself into the conversation could exclude attributes that a server may want, include attributes that a server may not want, and render meaningless other attributes that a server may want.

7. References

7.1. Normative References

[RFC1321]	Rivest, R., "The MD5 Message-Digest Algorithm", RFC 1321, DOI 10.17487/RFC1321, April 1992.
[RFC2046]	Freed, N. and N. Borenstein, "Multipurpose Internet Mail Extensions (MIME) Part Two: Media Types", RFC 2046, DOI 10.17487/RFC2046, November 1996.
[RFC2119]	Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, DOI 10.17487/RFC2119, March 1997.
[RFC2314]	Kaliski, B., "PKCS #10: Certification Request Syntax Version 1.5", RFC 2314, DOI 10.17487/RFC2314, March 1998.
[RFC2585]	Housley, R. and P. Hoffman, "Internet X.509 Public Key Infrastructure Operational Protocols: FTP and HTTP", RFC 2585, DOI 10.17487/RFC2585, May 1999.
[RFC2616]	Fielding, R., Gettys, J., Mogul, J., Frystyk, H., Masinter, L., Leach, P. and T. Berners-Lee, "Hypertext Transfer Protocol -- HTTP/1.1", RFC 2616, DOI 10.17487/RFC2616, June 1999.
[RFC2617]	Franks, J., Hallam-Baker, P., Hostetler, J., Lawrence, S., Leach, P., Luotonen, A. and L. Stewart, "HTTP Authentication: Basic and Digest Access Authentication", RFC 2617, DOI 10.17487/RFC2617, June 1999.
[RFC2818]	Rescorla, E., "HTTP Over TLS", RFC 2818, DOI 10.17487/RFC2818, May 2000.
[RFC2985]	Nystrom, M. and B. Kaliski, "PKCS #9: Selected Object Classes and Attribute Types Version 2.0", RFC 2985, DOI 10.17487/RFC2985, November 2000.
[RFC2986]	Nystrom, M. and B. Kaliski, "PKCS #10: Certification Request Syntax Specification Version 1.7", RFC 2986, DOI 10.17487/RFC2986, November 2000.
[RFC3986]	Berners-Lee, T., Fielding, R. and L. Masinter, "Uniform Resource Identifier (URI): Generic Syntax", STD 66, RFC 3986, DOI 10.17487/RFC3986, January 2005.
[RFC4086]	Eastlake 3rd, D., Schiller, J. and S. Crocker, "Randomness Requirements for Security", BCP 106, RFC 4086, DOI 10.17487/RFC4086, June 2005.
[RFC4108]	Housley, R., "Using Cryptographic Message Syntax (CMS) to Protect Firmware Packages", RFC 4108, DOI 10.17487/RFC4108, August 2005.
[RFC4210]	Adams, C., Farrell, S., Kause, T. and T. Mononen, "Internet X.509 Public Key Infrastructure Certificate Management Protocol (CMP)", RFC 4210, DOI 10.17487/RFC4210, September 2005.
[RFC4288]	Freed, N. and J. Klensin, "Media Type Specifications and Registration Procedures", RFC 4288, DOI 10.17487/RFC4288, December 2005.
[RFC4346]	Dierks, T. and E. Rescorla, "The Transport Layer Security (TLS) Protocol Version 1.1", RFC 4346, DOI 10.17487/RFC4346, April 2006.
[RFC4648]	Josefsson, S., "The Base16, Base32, and Base64 Data Encodings", RFC 4648, DOI 10.17487/RFC4648, October 2006.
[RFC4945]	Korver, B., "The Internet IP Security PKI Profile of IKEv1/ISAKMP, IKEv2, and PKIX", RFC 4945, DOI 10.17487/RFC4945, August 2007.
[RFC5054]	Taylor, D., Wu, T., Mavrogiannopoulos, N. and T. Perrin, "Using the Secure Remote Password (SRP) Protocol for TLS Authentication", RFC 5054, DOI 10.17487/RFC5054, November 2007.
[RFC5077]	Salowey, J., Zhou, H., Eronen, P. and H. Tschofenig, "Transport Layer Security (TLS) Session Resumption without Server-Side State", RFC 5077, DOI 10.17487/RFC5077, January 2008.
[RFC5272]	Schaad, J. and M. Myers, "Certificate Management over CMS (CMC)", RFC 5272, DOI 10.17487/RFC5272, June 2008.
[RFC5273]	Schaad, J. and M. Myers, "Certificate Management over CMS (CMC): Transport Protocols", RFC 5273, DOI 10.17487/RFC5273, June 2008.
[RFC5274]	Schaad, J. and M. Myers, "Certificate Management Messages over CMS (CMC): Compliance Requirements", RFC 5274, DOI 10.17487/RFC5274, June 2008.
[RFC5280]	Cooper, D., Santesson, S., Farrell, S., Boeyen, S., Housley, R. and W. Polk, "Internet X.509 Public Key Infrastructure Certificate and Certificate Revocation List (CRL) Profile", RFC 5280, DOI 10.17487/RFC5280, May 2008.
[RFC5652]	Housley, R., "Cryptographic Message Syntax (CMS)", STD 70, RFC 5652, DOI 10.17487/RFC5652, September 2009.
[RFC5746]	Rescorla, E., Ray, M., Dispensa, S. and N. Oskov, "Transport Layer Security (TLS) Renegotiation Indication Extension", RFC 5746, DOI 10.17487/RFC5746, February 2010.
[RFC5785]	Nottingham, M. and E. Hammer-Lahav, "Defining Well-Known Uniform Resource Identifiers (URIs)", RFC 5785, DOI 10.17487/RFC5785, April 2010.
[RFC5929]	Altman, J., Williams, N. and L. Zhu, "Channel Bindings for TLS", RFC 5929, DOI 10.17487/RFC5929, July 2010.
[RFC5958]	Turner, S., "Asymmetric Key Packages", RFC 5958, DOI 10.17487/RFC5958, August 2010.
[RFC5967]	Turner, S., "The application/pkcs10 Media Type", RFC 5967, DOI 10.17487/RFC5967, August 2010.
[RFC6125]	Saint-Andre, P. and J. Hodges, "Representation and Verification of Domain-Based Application Service Identity within Internet Public Key Infrastructure Using X.509 (PKIX) Certificates in the Context of Transport Layer Security (TLS)", RFC 6125, DOI 10.17487/RFC6125, March 2011.
[RFC6402]	Schaad, J., "Certificate Management over CMS (CMC) Updates", RFC 6402, DOI 10.17487/RFC6402, November 2011.
[SHS]	National Institute of Standards and Technology, , "Federal Information Processing Standard Publication 180-4: Secure Hash Standard (SHS)", March 2012.
[X.680]	ITU-T Recommendation, , "ITU-T Recommendation X.680 Abstract Syntax Notation One (ASN.1): Specification of basic notation", November 2008.
[X.690]	ITU-T Recommendation, , "ITU-T Recommendation X.690 ASN.1 encoding rules: Specification of Basic Encoding Rules (BER), Canonical Encoding Rules (CER) and Distinguished Encoding Rules (DER)", November 2008.

7.2. Informative References

[IDevID]	IEEE Std, , "IEEE 802.1AR Secure Device Identifier", December 2009.
[RFC2397]	Masinter, L., "The "data" URL scheme", RFC 2397, DOI 10.17487/RFC2397, August 1998.
[RFC2712]	Medvinsky, A. and M. Hur, "Addition of Kerberos Cipher Suites to Transport Layer Security (TLS)", RFC 2712, DOI 10.17487/RFC2712, October 1999.
[RFC3394]	Schaad, J. and R. Housley, "Advanced Encryption Standard (AES) Key Wrap Algorithm", RFC 3394, DOI 10.17487/RFC3394, September 2002.
[RFC6403]	Zieglar, L., Turner, S. and M. Peck, "Suite B Profile of Certificate Management over CMS", RFC 6403, DOI 10.17487/RFC6403, November 2011.
[SP-800-57-Part-1]	National Institute of Standards and Technology, , "Recommendation for Key Management - Part 1: General (Revision 3)", July 2012.
[X.520]	ITU-T Recommendation, , "ITU-T Recommendation X.520 The Directory: Selected attribute types", November 2008.

Appendix A. Operational Scenario Example Messages

(informative)

This section expands on the Operational Scenario Overviews by providing detailed examples of the messages at each TLS layer.

A.1. Obtaining CA Certificates

The following is an example of a valid /CACerts exchange.

During the initial TLS handshake the client can ignore the optional server generated "certificate request" and can instead proceed with the HTTP GET request:

GET /CACerts HTTP/1.1
User-Agent: curl/7.24.0 (i686-pc-linux-gnu) libcurl/7.24.0 OpenS
SL/0.9.8b zlib/1.2.3 libidn/0.6.5
Host: 127.0.0.1:8085
Accept: */* 

In response the server provides the current CA certificate:

<= Recv header, 38 bytes (0x26)
Content-Type: application/pkcs7-mime
== Info: no chunk, no close, no size. Assume close to signal end
<= Recv header, 2 bytes (0x2)
 
<= Recv data, 1111 bytes (0x457)
-----BEGIN PKCS7-----.MIIDEQYJKoZIhvcNAQcCoIIDAjCCAv4CAQExADALBg
kqhkiG9w0BBwGgggLkMIIC.4DCCAcigAwIBAgIJAOjxMZcXhE5wMA0GCSqGSIb3D
QEBBQUAMBcxFTATBgNVBAMT.DGVzdEV4YW1wbGVDQTAeFw0xMjA3MDQxODM5Mjda
Fw0xMzA3MDQxODM5MjdaMBcx.FTATBgNVBAMTDGVzdEV4YW1wbGVDQTCCASIwDQY
JKoZIhvcNAQEBBQADggEPADCC.AQoCggEBALQ7SjZSt6qrnBzUnBNj9z4oxYkvMA
Vh0OIOVRkNhz/2kDGsds0ne7cw.W33kYlxPba4psdLMixCT/O8ZQMpgA+QFKtwb9
VPE8EFUgGzxSYHQHjhJsbg0BVaN.Ya38vjKMjvosuSXUHwkvU57SInSkMr3/aNtS
T8qFfeC6Vuf/G/GLHGuHQKAy/DSo.206MjaMNmWYRVQQVErGookRA4GBF/YE+G/C
SlTsCQNE0KyBFz8JWIkgYY2gYkxb7.wWMvvhaU/Esp+2DG92v9Dhs2MRgrR+WPs7
Y6CYOLD5Mr5lEdkHg27IxkSAoRrI6D.fnVVEQGCj7QrrsUgfXFVYv6cCWFfhMcCA
wEAAaMvMC0wDAYDVR0TBAUwAwEB/zAd.BgNVHQ4EFgQUhH9KxW5TsjkgL7kg2kxJ
yy5tD/MwDQYJKoZIhvcNAQEFBQADggEB.AD+vydZo292XFb2vXojdKD57Gv4tKVm
hvXRdVInntzkY/0AyFCfHJ4BwndgtMh4t.rvBD8+8dL+W3jfPjcSCcUQ/JEnFuMn
b5+kivLeqOnUshETasFPBz2Xq4C1sHDno9.CWOcsjPPw08Tn4dSrzDBSq1NdXB2z
9NOpaVnbpb01qQGhXSOaEvcbZcDuGiW7Di3.gV++remokuPph/s6XoZffzc7ZVzf
Job6tS4RwNz01sutPybXiRWivOz7+QeCOT87.nTGlkQH/+RImUyJ2jefjAW/GDFT
Pzek6cZnabAtsg32n0Pv0j0/1RTNSdYGxPIVA.2f9fhMqMz+vm3w4CFNkGZnOhAD
EA.-----END PKCS7-----.

A.2. Certificate TLS authentication

The following is an example of a valid /simpleEnroll exchange. During this exchange the EST client uses an existing certificate issued by a thirt-party CA to obtain an initial certificate from the EST server.

During the initial TLS handshake the server generated "certificate request" includes both the distinguished name of the EST CA ("estExampleCA") and it includes the distinguished name of a third-party CA ("estEXTERNALCA"):

0d 00 00 3d 03 01 02 40 00 37 00 1a 30 18 31 16 ...=...@.7..0.1.
30 14 06 03 55 04 03 13 0d 65 73 74 45 58 54 45 0...U....estEXTE
52 4e 41 4c 43 41 00 19 30 17 31 15 30 13 06 03 RNALCA..0.1.0...
55 04 03 13 0c 65 73 74 45 78 61 6d 70 6c 65 43 U....estExampleC
41                                              A

Which decodes as:

Acceptable client certificate CA names
/CN=estEXTERNALCA
/CN=estExampleCA

The EST client provides a certificate issued by "estEXTERNALCA" in the certificate response and the TLS handshake proceeds to completion. The EST server accepts the EST client certificate for authentication and accepts the EST client's POSTed certificate request:

POST /simpleEnroll HTTP/1.1
User-Agent: curl/7.24.0 (i686-pc-linux-gnu) libcurl/7.24.0 OpenS
SL/0.9.8b zlib/1.2.3 libidn/0.6.5
Host: 127.0.0.1:8085
Accept: */*
Content-Type: application/pkcs10
Content-Length: 952
 
=> Send data, 952 bytes (0x3b8)
-----BEGIN CERTIFICATE REQUEST-----.MIIChjCCAW4CAQAwQTElMCMGA1UE
AxMccmVxIGJ5IGNsaWVudCBpbiBkZW1vIHN0.ZXAgNjEYMBYGA1UEBRMPUElEOld
pZGdldCBTTjo2MIIBIjANBgkqhkiG9w0BAQEF.AAOCAQ8AMIIBCgKCAQEAwhYyI+
aYezyx+kW0GVUbMKLf2BUd8BgGykkIJYxms6SH.Bv5S4ktcpYbEpR9iCmp96vK6a
Ar57ArZtMmi0Y6eLX4c+njJnYhUeTivnfyfMM5d.hNVwyzKbJagm5f+RLTMfp0y0
ykqrfZ1hFhcNrRzF6mJeaORTHBehMdu8RXcbmy5R.s+vjnUC4Fe3/oLHtXePyYv1
qqlkk0XDrw/+lx0y4Px5tiyb84iPnQOXjG2tuStM+.iEvfpNAnwU0+3GDjl3sjx0
+gTKvblp6Diw9NSaqIAKupcgWsA0JlyYkgPiJnXFKL.vy6rXoOyx3wAbGKLrKCxT
l+RH3oNXf3UCH70aD758QIDAQABoAAwDQYJKoZIhvcN.AQEFBQADggEBADwpafWU
BsOJ2g2oyHQ7Ksw6MwvimjhB7GhjweCcceTSLInUMk10.4E0TfNqaWcoQengMVZr
IcbOb+sa69BWNB/WYIULfEtJIV23/g3n/y3JltMNw/q+R.200t0bNAViijHQHmlF
6dt93tkRrTzXnhV70Ijnff08G7P9HfnXQH4Eiv3zOB6Pak.JoL7QlWQ+w5vHpPo6
WGH5n2iE+Ql76F0HykGeqaR402+ae0WlGLHEvcN9wiFQVKh.KUHteU10SEPijlqf
QW+hciLleX2CwuZY5MqKb4qqyDTs4HSQCBCl8jR2cXsGDuN4.PcMPp+9A1/UPuGD
jhwPt/K3y6aV8zUEh8Ws=.-----END CERTIFICATE REQUEST-----.

The EST server uses the trusted third party CA issued certificate to perform additional authorization and issues a certificate to the client:

<= Recv header, 38 bytes (0x26)
Content-Type: application/pkcs7-mime
== Info: no chunk, no close, no size. Assume close to signal end
<= Recv header, 2 bytes (0x2)
 
<= Recv data, 1200 bytes (0x4b0)
-----BEGIN PKCS7-----.MIIDUQYJKoZIhvcNAQcCoIIDQjCCAz4CAQExADALBg
kqhkiG9w0BBwGgggMkMIID.IDCCAgigAwIBAgIBBjANBgkqhkiG9w0BAQUFADAXM
RUwEwYDVQQDEwxlc3RFeGFt.cGxlQ0EwHhcNMTIwNzA0MTgzOTM3WhcNMTMwNzA0
MTgzOTM3WjBBMSUwIwYDVQQD.ExxyZXEgYnkgY2xpZW50IGluIGRlbW8gc3RlcCA
2MRgwFgYDVQQFEw9QSUQ6V2lk.Z2V0IFNOOjYwggEiMA0GCSqGSIb3DQEBAQUAA4
IBDwAwggEKAoIBAQDCFjIj5ph7.PLH6RbQZVRswot/YFR3wGAbKSQgljGazpIcG/
lLiS1ylhsSlH2IKan3q8rpoCvns.Ctm0yaLRjp4tfhz6eMmdiFR5OK+d/J8wzl2E
1XDLMpslqCbl/5EtMx+nTLTKSqt9.nWEWFw2tHMXqYl5o5FMcF6Ex27xFdxubLlG
z6+OdQLgV7f+gse1d4/Ji/WqqWSTR.cOvD/6XHTLg/Hm2LJvziI+dA5eMba25K0z
6IS9+k0CfBTT7cYOOXeyPHT6BMq9uW.noOLD01JqogAq6lyBawDQmXJiSA+ImdcU
ou/Lqteg7LHfABsYousoLFOX5Efeg1d./dQIfvRoPvnxAgMBAAGjTTBLMAkGA1Ud
EwQCMAAwHQYDVR0OBBYEFJv4oLLeNxNK.OMmQDDujyNR+zaVPMB8GA1UdIwQYMBa
AFIR/SsVuU7I5IC+5INpMScsubQ/zMA0G.CSqGSIb3DQEBBQUAA4IBAQCMdomfdR
9vi4VUYdF+eym7F8qVUG/1jtjfaxmrzKeZ.7LQ1F758RtwG9CDu2GPHNPjjeM+DJ
RQZN999eLs3Qd/DIJCNimaqdDqmkeBFC5hq.LZOxbKhSmhlR7YKjIZuyI299rOaI
W54ULyz8k0zw6R1/0lMJTsDFGJM+9yDeaARE.n3vtKnUDGHsVU3fYpDENaqUunoU
MZfuEdejfHhU7lVbJI1oSJbnRwBFkPr/RQ3/5.FymcrBD9RpAM5MsQIn0BONil/o
JM+LjOJqyZLbBxz6P3w/OiJGYJNfFT8YudLfjZ.LDX8A8FFcReapNELC4QxE4OrA
hN3sQUT2O7ndIsit4kJoQAxAA==.-----END PKCS7-----.

A.3. Username/Password Distributed Out-of-Band

The following is an example of a valid /simpleEnroll exchange. During this exchange the EST client uses an out-of-band distributed username/password to authenticate itself to the EST server.

During the initial TLS handshake the client can ignore the optional server generated "certificate request" and can instead proceed with the HTTP POST request:

POST /simpleEnroll HTTP/1.1
User-Agent: curl/7.24.0 (i686-pc-linux-gnu) libcurl/7.24.0 OpenS
SL/0.9.8b zlib/1.2.3 libidn/0.6.5
Host: 127.0.0.1:8085
Accept: */*
Content-Type: application/pkcs10
Content-Length: 952
 
=> Send data, 952 bytes (0x3b8)
-----BEGIN CERTIFICATE REQUEST-----.MIIChjCCAW4CAQAwQTElMCMGA1UE
AxMccmVxIGJ5IGNsaWVudCBpbiBkZW1vIHN0.ZXAgMjEYMBYGA1UEBRMPUElEOld
pZGdldCBTTjoyMIIBIjANBgkqhkiG9w0BAQEF.AAOCAQ8AMIIBCgKCAQEAz9lXz9
MowulOx0W5v1k7GKlsNy7mAgmkz/wZDImBDXez.QZCb8lrO8iTD3tI0NH2xpkY3b
uqFjdtQTzCmANLyNWtR1sC5GjN/EM1JSCrO/zZM.ig835RXJTP878N/jNW7EzSxb
/zK5OzKJoRbZ4HgZm4NDapMfMcB4jqBdPxoPAqeR.+KTkv1+9m1vvsdKIs5Hm4Sp
O2WolHPw5BCXdu5zleb6ACih7Zpd2cpHFz6ZHC0G1.Of+F//0BzkFSqWsmUomyJy
WCfLCuX9grs1CNlLxw0gcMprdTxLxjc18z03ZmBCq0.qq5/mUK/tv9R2k8+WuP3a
kzTUIkeHtcp6FVFl3D+TwIDAQABoAAwDQYJKoZIhvcN.AQEFBQADggEBAJH7Etuy
B/oQgQeals08mD2U31FfQ/uYqjNxzZpZJSzVLGMASv9a.pNzaWdfqPdIs+ZZ+gAQ
QkVcXjdbqY3pAf/EeWk+KnuAUjOIPKu3ZBPVbWbXu/Ie7.F1ekQ7TLkFNkHSxHRu
2/bPIByBLRVfWNVXd3wPq+QxqMqgIjBGaTJM5kuHndYFGj.Xdf4rlGRPyOOwG/Xf
QrKBB3tzpbJCy+cwOUAJFPOTO+86RUjf9Wh+yoM182vlg8O.FyEaaA/PMpl3aEcT
BlRZmPx4e7FLwGIhbgE7/6K0nF99xdGd7JYPHasbcWszxD0Z.oPYm+44g0gOnhlj
OWpRiKXcnngSSutRILaw=.-----END CERTIFICATE REQUEST-----.
== Info: upload completely sent off: 952 out of 952 bytes
== Info: HTTP 1.1 or later with persistent connection, pipelining 
   supported

The EST server accepts this request but since a client certificate was not provided for authentication/authorization the EST server responds with the WWW-authenticate header:

<= Recv header, 27 bytes (0x1b)
HTTP/1.1 401 Unauthorized
<= Recv header, 75 bytes (0x4b)
WWW-Authenticate: Digest qop="auth", realm="estrealm", nonce="13
41427174"

The EST client repeats the request, this time including the requested Authorization header:

== Info: SSL connection using AES256-SHA
== Info: Server certificate:
== Info:  subject: CN=127.0.0.1
== Info:  start date: 2012-07-04 18:39:27 GMT
== Info:  expire date: 2013-07-04 18:39:27 GMT
== Info:  common name: 127.0.0.1 (matched)
== Info:  issuer: CN=estExampleCA
== Info:  SSL certificate verify ok.
== Info: Server auth using Digest with user 'estuser'
=> Send header, 416 bytes (0x1a0)
POST /simpleEnroll HTTP/1.1
Authorization: Digest username="estuser", realm="estrealm", nonc
e="1341427174", uri="/simpleEnroll", cnonce="ODc0OTk2", nc=00000
001, qop="auth", response="48a2b671ccb6596adfef039e134b7d5d"
User-Agent: curl/7.24.0 (i686-pc-linux-gnu) libcurl/7.24.0 OpenS
SL/0.9.8b zlib/1.2.3 libidn/0.6.5
Host: 127.0.0.1:8085
Accept: */*
Content-Type: application/pkcs10
Content-Length: 952

=> Send data, 952 bytes (0x3b8)
-----BEGIN CERTIFICATE REQUEST-----.MIIChjCCAW4CAQAwQTElMCMGA1UE
AxMccmVxIGJ5IGNsaWVudCBpbiBkZW1vIHN0.ZXAgMjEYMBYGA1UEBRMPUElEOld
pZGdldCBTTjoyMIIBIjANBgkqhkiG9w0BAQEF.AAOCAQ8AMIIBCgKCAQEAz9lXz9
MowulOx0W5v1k7GKlsNy7mAgmkz/wZDImBDXez.QZCb8lrO8iTD3tI0NH2xpkY3b
uqFjdtQTzCmANLyNWtR1sC5GjN/EM1JSCrO/zZM.ig835RXJTP878N/jNW7EzSxb
/zK5OzKJoRbZ4HgZm4NDapMfMcB4jqBdPxoPAqeR.+KTkv1+9m1vvsdKIs5Hm4Sp
O2WolHPw5BCXdu5zleb6ACih7Zpd2cpHFz6ZHC0G1.Of+F//0BzkFSqWsmUomyJy
WCfLCuX9grs1CNlLxw0gcMprdTxLxjc18z03ZmBCq0.qq5/mUK/tv9R2k8+WuP3a
kzTUIkeHtcp6FVFl3D+TwIDAQABoAAwDQYJKoZIhvcN.AQEFBQADggEBAJH7Etuy
B/oQgQeals08mD2U31FfQ/uYqjNxzZpZJSzVLGMASv9a.pNzaWdfqPdIs+ZZ+gAQ
QkVcXjdbqY3pAf/EeWk+KnuAUjOIPKu3ZBPVbWbXu/Ie7.F1ekQ7TLkFNkHSxHRu
2/bPIByBLRVfWNVXd3wPq+QxqMqgIjBGaTJM5kuHndYFGj.Xdf4rlGRPyOOwG/Xf
QrKBB3tzpbJCy+cwOUAJFPOTO+86RUjf9Wh+yoM182vlg8O.FyEaaA/PMpl3aEcT
BlRZmPx4e7FLwGIhbgE7/6K0nF99xdGd7JYPHasbcWszxD0Z.oPYm+44g0gOnhlj
OWpRiKXcnngSSutRILaw=.-----END CERTIFICATE REQUEST-----.

The ESTserver uses the username/password to perform authentication/authorization and responds with the issued certificate:

<= Recv header, 38 bytes (0x26)
0000: Content-Type: application/pkcs7-mime
== Info: no chunk, no close, no size. Assume close to signal end
<= Recv header, 2 bytes (0x2)
 
<= Recv data, 1200 bytes (0x4b0)
-----BEGIN PKCS7-----.MIIDUQYJKoZIhvcNAQcCoIIDQjCCAz4CAQExADALBg
kqhkiG9w0BBwGgggMkMIID.IDCCAgigAwIBAgIBAjANBgkqhkiG9w0BAQUFADAXM
RUwEwYDVQQDEwxlc3RFeGFt.cGxlQ0EwHhcNMTIwNzA0MTgzOTM0WhcNMTMwNzA0
MTgzOTM0WjBBMSUwIwYDVQQD.ExxyZXEgYnkgY2xpZW50IGluIGRlbW8gc3RlcCA
yMRgwFgYDVQQFEw9QSUQ6V2lk.Z2V0IFNOOjIwggEiMA0GCSqGSIb3DQEBAQUAA4
IBDwAwggEKAoIBAQDP2VfP0yjC.6U7HRbm/WTsYqWw3LuYCCaTP/BkMiYENd7NBk
JvyWs7yJMPe0jQ0fbGmRjdu6oWN.21BPMKYA0vI1a1HWwLkaM38QzUlIKs7/NkyK
DzflFclM/zvw3+M1bsTNLFv/Mrk7.MomhFtngeBmbg0Nqkx8xwHiOoF0/Gg8Cp5H
4pOS/X72bW++x0oizkebhKk7ZaiUc./DkEJd27nOV5voAKKHtml3ZykcXPpkcLQb
U5/4X//QHOQVKpayZSibInJYJ8sK5f.2CuzUI2UvHDSBwymt1PEvGNzXzPTdmYEK
rSqrn+ZQr+2/1HaTz5a4/dqTNNQiR4e.1ynoVUWXcP5PAgMBAAGjTTBLMAkGA1Ud
EwQCMAAwHQYDVR0OBBYEFChDQpKEfG9c.e4JaMf8438tb2XOIMB8GA1UdIwQYMBa
AFIR/SsVuU7I5IC+5INpMScsubQ/zMA0G.CSqGSIb3DQEBBQUAA4IBAQAn42mIVG
piaY4yqFD0F8KyUhKsdNnyKeeISQxP//lp.quIieJzdWSc7bhWZNldSzNswCod8B
4eJToQejLSNb8JBDC849z0tcuyHgN6N/p8z.IwI+hAlfXS9q02OECyFes4Jmzc7r
erE5jtOdGsEDBIscw/A+Kv86wv6BKbagMslQ.51AJyPsL6iBhm7LPFrErJgH2kWN
jDKFH9CcVFjXvgriMrLPFeqQWOpj/2XF+4m+c.f9QP5tSjieHJR1hnYk2tlodfE7
iV4pJ07Mmf3yBf753VSUVybqWiMCd0Lm7oghSX.E2GAxrsU1N+N1odn+gJ2wmxTu
AC2aHt9VPRViov4RRTvoQAxAA==.-----END PKCS7-----.

A.4. Re-Enrollment

The following is an example of a valid /simpleReEnroll exchange. During this exchange the EST client authenticates itself using an existing certificate issued by the EST CA.

Initially this exchange is identical to enrollment using an externally issued certificate for client authentication since the server is not yet aware of the client's intention. As in that example the EST server the server generated "certificate request" includes both the distinguished name of the CA the EST server provides services for ("estExampleCA") and it includes the distinguished name of a trusted third party CA ("estEXTERNALCA").

0d 00 00 3d 03 01 02 40 00 37 00 1a 30 18 31 16 ...=...@.7..0.1.
30 14 06 03 55 04 03 13 0d 65 73 74 45 58 54 45 0...U....estEXTE
52 4e 41 4c 43 41 00 19 30 17 31 15 30 13 06 03 RNALCA..0.1.0...
55 04 03 13 0c 65 73 74 45 78 61 6d 70 6c 65 43 U....estExampleC
41                                              A

In text format this is:

Acceptable client certificate CA names
/CN=estEXTERNALCA
/CN=estExampleCA

The EST client provides a certificate issued by "estExampleCA" in the certificate response and the TLS handshake proceeds to completion. The EST server accepts the EST client certificate for authentication and accepts the EST client's POSTed certificate request.

The rest of the protocol traffic is effectively identical to a normal enrollment.

A.5. Server Key Generation

The following is an example of a valid /serverKeyGen exchange. During this exchange the EST client authenticates itself using an existing certificate issued by the CA the EST server provides services for.

The initial TLS handshake is identical to the enrollment example handshake. The HTTP POSTed message is:

POST /serverKeyGen HTTP/1.1
User-Agent: curl/7.24.0 (i686-pc-linux-gnu) libcurl/7.24.0 OpenS
SL/0.9.8b zlib/1.2.3 libidn/0.6.5
Host: 127.0.0.1:8085
Accept: */*
Content-Type: application/pkcs10
Content-Length: 968

=> Send data, 968 bytes (0x3c8)
-----BEGIN CERTIFICATE REQUEST-----.MIICkzCCAXsCAQAwTjEyMDAGA1UE
AxMpc2VydmVyS2V5R2VuIHJlcSBieSBjbGll.bnQgaW4gZGVtbyBzdGVwIDUxGDA
WBgNVBAUTD1BJRDpXaWRnZXQgU046NTCCASIw.DQYJKoZIhvcNAQEBBQADggEPAD
CCAQoCggEBAMnlUlq0ag/fDAVhLgrXEAD6WtZw.Y2rVGev5saWirer2n0OzghB59
uJByxPo0DYBYqZRuoRF0FTL1ZZTMaZxivge0ecA.ZcoR46jwSBoceMT1jkwFyAER
t9Q2EwdnJLIPo/Ib2PLJNb4Jo8NNKmxtg55BgIVi.vkIB+rMtLeYRUVL0RUaBAqX
FmtXRDceVFIEY24iUQw6vESGJKpArht592aT8lyaP.24bZovuG19dd5xtTX3j37K
x49SlkUvLSpD6ZavIFAZn7Yv19LBKHvRIemybUo294.QeLb/VYP1O+EAthV/igiX
1DHqlUZCZp5SdyUXUwZPatFboNwEVR0R3MJwVECAwEA.AaAAMA0GCSqGSIb3DQEB
BQUAA4IBAQAqhHezK5/tvbXleHO/aTBVYO9l414NM+WA.wJcnS2UaJYScPBqlYK/
gij+dqAtFE+5ukAj56t7HnooI4EFo9r8jqCHewx7iLZYh.JDxo4hWOsAvHV+Iziy
jkhJNdHBIqGM7Gd5f/2VJLEPQPmwNOL5P+2O4eQC/QeEYc.bAmfhOS8b/ZH09/9T
PeaeQpjspjOui/100OuLE8KvU3FM0sXMYt1Va0A0jxzl+5k.EiEJo+ltXsQwdP0H
csoTNBN+j3K18omJQS0e91X8v0xkMWYhUtonXD0YZ6SO/B9c.AE6GTADHA/xpSvA
cqlWa+FHxjwEMXdmViHvMUywo31fDZ/TUvCPX.-----END CERTIFICATE REQUE
ST-----.

Because the DecryptKeyIdentifier attribute is not included in the request the response does not include additional encryption beyond the TLS session. The EST server response is:

<= Recv header, 17 bytes (0x11)
HTTP/1.1 200 OK
<= Recv header, 16 bytes (0x10)
Status: 200 OK
<= Recv header, 67 bytes (0x43)
Content-Type: multipart/mixed ; boundary=estServerExampleBoundar
y
== Info: no chunk, no close, no size. Assume close to signal end
<= Recv header, 2 bytes (0x2)
 
<= Recv data, 3234 bytes (0xca2)
This is the preamble. It is to be ignored, though it.is a handy 
place for estServer to include an explanatory note.including con
tact or support information..--estServerExampleBoundary.Content-
Type=application/pkcs8..-----BEGIN PRIVATE KEY-----.MIIEvQIBADAN
BgkqhkiG9w0BAQEFAASCBKcwggSjAgEAAoIBAQC0781l7tri0yii.Mb9ZZYch8ze
izXrjMPF/Rxoz2C9IU2THCrhPGXGQMne/zivce0m8/BMkkUc+DsSM.tzxn4l+9tI
sVDkAe4FyzN0hLd/zawgj6kUoCi3mxZnb2rWaRYAmM5w41ImDV3blv.aMUKDSJhV
bQ+z/G1W1TRx3iWi5CMHYb+1pJXPTJz/GuWr/b/+Efqwz2ZlwGcj4Dx.Igbx9vG0
mftIIxM4TUX28KBbaLgJbalsiuOx3C2bEyaSPerdzqgvXFHGGAhg1FU8.DQiQEki
nn66GPMtm1SNgitxFxWouFqpsax5MWn/i52TfEaF2PNThOuzKtilweJhk.g0gMIQ
TXAgMBAAECggEANlrz8XNX/lxBELixK0H83o4aYKYqDKZfZkUN8hU33xpu.Y/0sc
VbLbu46WzysoIfJFyUC+zFJnbMCCOPjGbI/4NWkEqc9TAlKz+wDo+hf5bf0.ypFr
EmikHk8R3fkpnvKi69ldw0iYnqcFVhq7VtGrSmJcy6Hckwbk7EBoUZGL0wtp.xlO
6XlhksAvn8+75qoWzsNhi7S/L0IVCVLbUaV3hodTHlH5M4daFbqyRWD7UiPKt.Q3
hdw1rpyVZg8ZbBFp0Ej4f9GdRaq88SIKMKCDu3t9ibn/v1kEte+PxhuwyW+d0o.h
kKSEW0yLKCzQm5tujsPq0UVzPBkLJACUnFAi+a4AQKBgQDu6VLH2eYoTjPPTyAv.
vOJnNWP7oMzyJ4/eFqdE9m+2Ajm/0qaMY95ftZ+GpEKggvC6Z5DFevEmgH4Sg2+G
.gFd93diyRPScVbNE8SmpXxLPU2UoykVmICuQZzLDNE18B3buxAm2GJ219NEnZOe
c.jPMOV/IcG1aLzTqQssL3zo/0gQKBgQDB4Olpg3EBggtJ/+dlkLHUw8c7Pe3UyL
kS.VxVsyQwioYt8xMeCWuPvPNFcOjcW53KN/YSpCVjpttKGsPtLibMlKYKgasEqg
cvl.Vb5OFtA/jNAP3mdAgCzBn6IF1NhVQe2dclo5puZ0gO38HDWq7EtqSi9Q0JSM
g3YC.QNcOORptVwKBgQCHrCafaYWDhA11/+g2U9x6Yd56ifF43rCbnV+2EQCVaqQ
i49xC.w4AH+Bs0mdlgT5unL6MOEmgZxkRR/SP7TKzixHYHnpMOqLhaQV24Wk5TQH
ek92D7.wu8aXRB9vBj4g0CuDNO6/jWpm/KenXXN+Fka3ySVg4zdbVmBzJJdqYckg
QKBgFXS.zSBzGgwz1/F7AaDZK49m1wPnhyeBb0OqHwbX/LI71rZ1mWef+nSF9Juh
/Y77B5/J.UPdO9vgGgS00nRk0LIRP2s5OU5IQgQTVLvf8a1UmbVgI+KX511Yi5yM
ztEwRcjEX.VM9ejXeXN0I57pvqG/xCOK3Kl2eYLh4TO9/E8WjjAoGAA1mqUV4Hnf
4yvF1rydMp.fpvoWekiiRE33iEbYZNATYhsl7uxwn760pqVifkq2DSrZeYm4+lw9
jwWMtUoPzpg.CJYMoGl846nhiZrbbJ5b5twoLV6GRmkk/CfOxPXNzCtSoQA86HHq
7rRdhXSau/bY.EXc91tnhLjFzZxdBgrd+f4k=.-----END PRIVATE KEY-----.
--estServerExampleBoundary.Content-Type: application/pkcs7-mime.
.-----BEGIN PKCS7-----.MIIDPAYJKoZIhvcNAQcCoIIDLTCCAykCAQExADALB
gkqhkiG9w0BBwGgggMPMIID.CzCCAfOgAwIBAgIBBTANBgkqhkiG9w0BAQUFADAX
MRUwEwYDVQQDEwxlc3RFeGFt.cGxlQ0EwHhcNMTIwNzA0MTgzOTM2WhcNMTMwNzA
0MTgzOTM2WjAsMSowKAYDVQQD.EyFzZXJ2ZXJzaWRlIGtleSBnZW5lcmF0ZWQgcm
VzcG9uc2UwggEiMA0GCSqGSIb3.DQEBAQUAA4IBDwAwggEKAoIBAQC0781l7tri0
yiiMb9ZZYch8zeizXrjMPF/Rxoz.2C9IU2THCrhPGXGQMne/zivce0m8/BMkkUc+
DsSMtzxn4l+9tIsVDkAe4FyzN0hL.d/zawgj6kUoCi3mxZnb2rWaRYAmM5w41ImD
V3blvaMUKDSJhVbQ+z/G1W1TRx3iW.i5CMHYb+1pJXPTJz/GuWr/b/+Efqwz2Zlw
Gcj4DxIgbx9vG0mftIIxM4TUX28KBb.aLgJbalsiuOx3C2bEyaSPerdzqgvXFHGG
Ahg1FU8DQiQEkinn66GPMtm1SNgitxF.xWouFqpsax5MWn/i52TfEaF2PNThOuzK
tilweJhkg0gMIQTXAgMBAAGjTTBLMAkG.A1UdEwQCMAAwHQYDVR0OBBYEFLylcQN
0D5xTfRdayv+0GDULR2+EMB8GA1UdIwQY.MBaAFIR/SsVuU7I5IC+5INpMScsubQ
/zMA0GCSqGSIb3DQEBBQUAA4IBAQButIeM.DB9PkwlGGe7zqvUWVD8y99zowwV6A
rAOXWX+JO0bihgMtZaUfvPCX/LhZVEKDAki.W5orjAEvIu10b6l38ZzX2oyJgkYy
Mmbb14lzTsRyjiqFw9j1PXxwgZvhwcaCF4b7.eDUUBQIeZg3AnkQrEwnHR5oVIN5
8qo0P7PSKC3Vl3H6DlQh3y7w87nN12923/wk0.v/bS3lv7lDX3HdmbQD1r2KPtBs
JGF4jMdstT7FTx32ZFKObycbK7WJ4LHytNJDci.4iXf+B0S3D6Zbf1cXj80/W+jC
GvU0+4SV3cgEXFE5VQvXd8x40W4h0dTSkQCDPOS.nPj4Dl/PsLqX3lDboQAxAA==
.-----END PKCS7-----.--estServerExampleBoundary--.This is the ep
ilogue. It is also to be ignored..

In text format this is:

HTTP/1.1 200 OK
Status: 200 OK
Content-Type: multipart/mixed ; boundary=estServerExampleBoundary

This is the preamble. It is to be ignored, though it
is a handy place for estServer to include an explanatory note
including contact or support information.
--estServerExampleBoundary
Content-Type=application/pkcs8

-----BEGIN PRIVATE KEY-----
MIIEvQIBADANBgkqhkiG9w0BAQEFAASCBKcwggSjAgEAAoIBAQC0781l7tri0yii
Mb9ZZYch8zeizXrjMPF/Rxoz2C9IU2THCrhPGXGQMne/zivce0m8/BMkkUc+DsSM
tzxn4l+9tIsVDkAe4FyzN0hLd/zawgj6kUoCi3mxZnb2rWaRYAmM5w41ImDV3blv
aMUKDSJhVbQ+z/G1W1TRx3iWi5CMHYb+1pJXPTJz/GuWr/b/+Efqwz2ZlwGcj4Dx
Igbx9vG0mftIIxM4TUX28KBbaLgJbalsiuOx3C2bEyaSPerdzqgvXFHGGAhg1FU8
DQiQEkinn66GPMtm1SNgitxFxWouFqpsax5MWn/i52TfEaF2PNThOuzKtilweJhk
g0gMIQTXAgMBAAECggEANlrz8XNX/lxBELixK0H83o4aYKYqDKZfZkUN8hU33xpu
Y/0scVbLbu46WzysoIfJFyUC+zFJnbMCCOPjGbI/4NWkEqc9TAlKz+wDo+hf5bf0
ypFrEmikHk8R3fkpnvKi69ldw0iYnqcFVhq7VtGrSmJcy6Hckwbk7EBoUZGL0wtp
xlO6XlhksAvn8+75qoWzsNhi7S/L0IVCVLbUaV3hodTHlH5M4daFbqyRWD7UiPKt
Q3hdw1rpyVZg8ZbBFp0Ej4f9GdRaq88SIKMKCDu3t9ibn/v1kEte+PxhuwyW+d0o
hkKSEW0yLKCzQm5tujsPq0UVzPBkLJACUnFAi+a4AQKBgQDu6VLH2eYoTjPPTyAv
vOJnNWP7oMzyJ4/eFqdE9m+2Ajm/0qaMY95ftZ+GpEKggvC6Z5DFevEmgH4Sg2+G
gFd93diyRPScVbNE8SmpXxLPU2UoykVmICuQZzLDNE18B3buxAm2GJ219NEnZOec
jPMOV/IcG1aLzTqQssL3zo/0gQKBgQDB4Olpg3EBggtJ/+dlkLHUw8c7Pe3UyLkS
VxVsyQwioYt8xMeCWuPvPNFcOjcW53KN/YSpCVjpttKGsPtLibMlKYKgasEqgcvl
Vb5OFtA/jNAP3mdAgCzBn6IF1NhVQe2dclo5puZ0gO38HDWq7EtqSi9Q0JSMg3YC
QNcOORptVwKBgQCHrCafaYWDhA11/+g2U9x6Yd56ifF43rCbnV+2EQCVaqQi49xC
w4AH+Bs0mdlgT5unL6MOEmgZxkRR/SP7TKzixHYHnpMOqLhaQV24Wk5TQHek92D7
wu8aXRB9vBj4g0CuDNO6/jWpm/KenXXN+Fka3ySVg4zdbVmBzJJdqYckgQKBgFXS
zSBzGgwz1/F7AaDZK49m1wPnhyeBb0OqHwbX/LI71rZ1mWef+nSF9Juh/Y77B5/J
UPdO9vgGgS00nRk0LIRP2s5OU5IQgQTVLvf8a1UmbVgI+KX511Yi5yMztEwRcjEX
VM9ejXeXN0I57pvqG/xCOK3Kl2eYLh4TO9/E8WjjAoGAA1mqUV4Hnf4yvF1rydMp
fpvoWekiiRE33iEbYZNATYhsl7uxwn760pqVifkq2DSrZeYm4+lw9jwWMtUoPzpg
CJYMoGl846nhiZrbbJ5b5twoLV6GRmkk/CfOxPXNzCtSoQA86HHq7rRdhXSau/bY
EXc91tnhLjFzZxdBgrd+f4k=
-----END PRIVATE KEY-----
--estServerExampleBoundary
Content-Type: application/pkcs7-mime

-----BEGIN PKCS7-----
MIIDPAYJKoZIhvcNAQcCoIIDLTCCAykCAQExADALBgkqhkiG9w0BBwGgggMPMIID
CzCCAfOgAwIBAgIBBTANBgkqhkiG9w0BAQUFADAXMRUwEwYDVQQDEwxlc3RFeGFt
cGxlQ0EwHhcNMTIwNzA0MTgzOTM2WhcNMTMwNzA0MTgzOTM2WjAsMSowKAYDVQQD
EyFzZXJ2ZXJzaWRlIGtleSBnZW5lcmF0ZWQgcmVzcG9uc2UwggEiMA0GCSqGSIb3
DQEBAQUAA4IBDwAwggEKAoIBAQC0781l7tri0yiiMb9ZZYch8zeizXrjMPF/Rxoz
2C9IU2THCrhPGXGQMne/zivce0m8/BMkkUc+DsSMtzxn4l+9tIsVDkAe4FyzN0hL
d/zawgj6kUoCi3mxZnb2rWaRYAmM5w41ImDV3blvaMUKDSJhVbQ+z/G1W1TRx3iW
i5CMHYb+1pJXPTJz/GuWr/b/+Efqwz2ZlwGcj4DxIgbx9vG0mftIIxM4TUX28KBb
aLgJbalsiuOx3C2bEyaSPerdzqgvXFHGGAhg1FU8DQiQEkinn66GPMtm1SNgitxF
xWouFqpsax5MWn/i52TfEaF2PNThOuzKtilweJhkg0gMIQTXAgMBAAGjTTBLMAkG
A1UdEwQCMAAwHQYDVR0OBBYEFLylcQN0D5xTfRdayv+0GDULR2+EMB8GA1UdIwQY
MBaAFIR/SsVuU7I5IC+5INpMScsubQ/zMA0GCSqGSIb3DQEBBQUAA4IBAQButIeM
DB9PkwlGGe7zqvUWVD8y99zowwV6ArAOXWX+JO0bihgMtZaUfvPCX/LhZVEKDAki
W5orjAEvIu10b6l38ZzX2oyJgkYyMmbb14lzTsRyjiqFw9j1PXxwgZvhwcaCF4b7
eDUUBQIeZg3AnkQrEwnHR5oVIN58qo0P7PSKC3Vl3H6DlQh3y7w87nN12923/wk0
v/bS3lv7lDX3HdmbQD1r2KPtBsJGF4jMdstT7FTx32ZFKObycbK7WJ4LHytNJDci
4iXf+B0S3D6Zbf1cXj80/W+jCGvU0+4SV3cgEXFE5VQvXd8x40W4h0dTSkQCDPOS
nPj4Dl/PsLqX3lDboQAxAA==
-----END PKCS7-----
--estServerExampleBoundary--
This is the epilogue. It is also to be ignored. 

A.6. CSR Attributes

The following is an example of a valid /CSRAttrs exchange. During this exchange the EST client authenticates itself using an existing certificate issued by the CA the EST server provides services for.

The initial TLS handshake is identical to the enrollment example handshake. The HTTP GET request:

GET /CSRAttrs HTTP/1.1
User-Agent: curl/7.22.0 (i686-pc-linux-gnu) libcurl/7.22.0 OpenS
SL/1.0.1 zlib/1.2.3.4 libidn/1.23 librtmp/2.3
Host: 127.0.0.1:8085
Accept: */*

In response the server provides suggested attributes that are appropriate for the authenticated client:

<= Recv header, 36 bytes (0x24)
Content-Type: application/csrattrs
== Info: no chunk, no close, no size. Assume close to signal end
<= Recv header, 2 bytes (0x2)
 
<= Recv data, 33 bytes (0x21)
0000: MBQGBysGAQEBARYGCSqGSIb3DQEJBw==.

Authors' Addresses