Difference between revisions of "RFC7030"

Latest revision as of 23:38, 1 October 2020

Internet Engineering Task Force (IETF) M. Pritikin, Ed. Request for Comments: 7030 Cisco Systems, Inc. Category: Standards Track P. Yee, Ed. ISSN: 2070-1721 AKAYLA, Inc.

                                                     D. Harkins, Ed.
                                                      Aruba Networks
                                                        October 2013

                Enrollment over Secure Transport

Abstract

This document profiles certificate enrollment for clients using Certificate Management over CMS (CMC) messages over a secure transport. This profile, called Enrollment over Secure Transport (EST), describes a simple, yet functional, certificate management protocol targeting Public Key Infrastructure (PKI) clients that need to acquire client certificates and associated Certification Authority (CA) certificates. It also supports client-generated public/private key pairs as well as key pairs generated by the CA.

Status of This Memo

This is an Internet Standards Track document.

This document is a product of the Internet Engineering Task Force (IETF). It represents the consensus of the IETF community. It has received public review and has been approved for publication by the Internet Engineering Steering Group (IESG). Further information on Internet Standards is available in Section 2 of RFC 5741.

Information about the current status of this document, any errata, and how to provide feedback on it may be obtained at http://www.rfc-editor.org/info/rfc7030.

Copyright Notice

This document is subject to BCP 78 and the IETF Trust's Legal Provisions Relating to IETF Documents (http://trustee.ietf.org/license-info) in effect on the date of publication of this document. Please review these documents carefully, as they describe your rights and restrictions with respect to this document. Code Components extracted from this document must include Simplified BSD License text as described in Section 4.e of the Trust Legal Provisions and are provided without warranty as described in the Simplified BSD License.

              4.4.1.1. Requests for Symmetric Key

              4.4.1.2. Requests for Asymmetric Encryption

Introduction

This document profiles certificate enrollment for clients using Certificate Management over CMS (CMC) RFC5272 messages over a secure transport. Enrollment over Secure Transport (EST) describes the use of Transport Layer Security (TLS) 1.1 RFC4346, 1.2 RFC5246, or any future version) and Hypertext Transfer Protocol (HTTP) RFC2616 to provide an authenticated and authorized channel for Simple Public Key Infrastructure (PKI) Requests and Responses RFC5272.

Architecturally, the EST service is located between a Certification Authority (CA) and a client. It performs several functions traditionally allocated to the Registration Authority (RA) role in a PKI. The nature of communication between an EST server and a CA is not described in this document.

EST adopts the Certificate Management Protocol (CMP) RFC4210 model for CA certificate rollover, but it does not use the CMP message syntax or protocol. EST servers are extensible in that new functions may be defined to provide additional capabilities not specified in CMC RFC5272, and this document defines two such extensions: one for requesting Certificate Signing Request attributes and another for requesting server-generated keys.

EST specifies how to transfer messages securely via HTTP over TLS (HTTPS) RFC2818, where the HTTP headers and media types are used in conjunction with TLS. HTTPS operates over TCP; this document does not specify EST over HTTP/Datagram Transport Layer Security/User Datagram Protocol (HTTP/DTLS/UDP). With a suitable specification for combining HTTP, DTLS, and UDP, there are no EST requirements that would prevent it from working over such a stack. Figure 1 shows how the layers build upon each other.

EST Layering:

Protocols: +--------------------------------------------+ | | | EST request/response messages | | | +--------------------------------------------+ | | | HTTP for message transfer and signaling | | | +--------------------------------------------+ | | | TLS for transport security | | | +--------------------------------------------+ | | | TCP for transport | | | +--------------------------------------------+

                             Figure 1

Terminology

The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in RFC2119.

It is assumed that the reader is familiar with the terms and concepts described in Public Key Cryptography Standard (PKCS) #10 RFC2986, HTTPS RFC2818, CMP RFC4210, CMC RFC5272 RFC5273 RFC5274, and TLS RFC4346.

In addition to the terms defined in the terminology section of CMC RFC5272, the following terms are defined for clarity:

EST CA: For certificate issuing services, the EST CA is reached

  through the EST server; the CA could be logically "behind" the EST
  server or embedded within it.

Third-Party Trust Anchor: Any trust anchor (TA) that is not

  authoritative for the PKI hierarchy for which the EST server is
  providing services.

Explicit Trust Anchor: Any TA that is explicitly configured on the

  client or server for use during EST TLS authentication; for
  example, a TA that is manually configured on the EST client or
  bootstrapped as described in Section 4.1.1.  (See more details in
  Sections 3.6 and 6.)

Implicit Trust Anchor: Any third-party TA that is available on the

  client or server for use during TLS authentication but is not
  specifically indicated for use during EST TLS authentication; for
  example, TAs commonly used by web browsers to authenticate web
  servers or TAs used by servers to authenticate manufacturer-
  installed client credentials (such as certificates populated into
  cable modems or routers in the factory).  The authorization model
  for these TAs is different from the authorization model for
  Explicit Trust Anchors.  (See more details in Sections 3.6.1,
  3.6.2, and 6).

Certificate-Less TLS: Certificate-less TLS cipher suites provide a

  way to perform mutual authentication in situations where neither
  the client nor server have certificates or are willing to use
  them.  The credential used for authentication is a word, phrase,
  code, or key that is shared between the client and server.  The
  credential must be uniquely shared between the client and server
  in order to provide authentication of an individual client to an
  individual server.

Operational Scenario Overviews

This section provides an informative overview of the operational scenarios to better introduce the reader to the protocol discussion.

Both the EST clients and server are configured with information that provides the basis for mutual authentication and for authorization. The specific initialization data depends on the methods available in the client and server, but it can include shared secrets, network service names and locations (e.g., a Uniform Resource Identifier (URI) RFC3986), trust anchor information (e.g., a CA certificate or a hash of a TA's certificate), and enrollment keys and certificates. Depending on an enterprise's acquisition and network management practices, some initialization may be performed by the vendor prior to delivery of client hardware and software. In that case, the client vendor may provide data, such as trust anchors, to the enterprise via a secure procedure. The distribution of this initial information is out of scope.

Distribution of trust anchors and other certificates can be effected via the EST server. However, nothing can be inferred about the authenticity of this data until an out-of-band mechanism is used to verify them.

Sections 2.1-2.3 very closely mirror the text of the Scenarios Appendix of RFC6403 with such modifications as are appropriate for this profile. Sections 2.1-2.6, below, enumerate the set of EST functions (see Figure 5) and provide an informative overview of EST's capabilities.

The general client/server interaction proceeds as follows:

  The client initiates a TLS-secured HTTP session with an EST
  server.

  A specific EST service is requested based on a portion of the URI
  used for the session.

  The client and server authenticate each other.

  The client verifies that the server is authorized to serve this
  client.

  The server verifies that the client is authorized to make use of
  this server and the request that the client has made.

  The server acts upon the client request.

Obtaining CA Certificates

The EST client can request a copy of the current EST CA certificate(s) from the EST server. The EST client is assumed to perform this operation before performing other operations.

Throughout this document we assume the EST CA has a certificate that is used by the client to verify signed objects issued by the CA, e.g., certificates and certificate revocation lists (CRLs), and that a different certificate than the one used to verify signatures on certificates and CRLs is used when EST protocol communication requires additional encryption.

The EST client authenticates and verifies the authorization scope of the EST server when requesting the current CA certificate(s). As detailed in Sections 3.3.1 and 3.3.3, available options include:

o Verifying the EST server's HTTPS URI against the EST server's

  certificate using Implicit TAs (similar to a common HTTPS
  exchange).  This allows the EST server and client to leverage
  existing TAs that might be known to the EST client.

o The client can leverage a previously distributed trust anchor

  specific to the EST server.  This allows the EST client to use an
  existing, potentially older, CA certificate to request a current
  CA certificate.

o For bootstrapping, the EST client can rely upon manual

  authentication performed by the end-user as detailed in
  Section 4.1.1.

o The client can leverage the binding of a shared credential to a

  specific EST server with a certificate-less TLS cipher suite.

Client authentication is not required for this exchange, so it is trivially supported by the EST server.

Initial Enrollment

After authenticating an EST server and verifying that it is authorized to provide services to the client, an EST client can acquire a certificate for itself by submitting an enrollment request to that server.

The EST server authenticates and authorizes the EST client as specified in Sections 3.3.2, 3.3.3, and 3.7. The methods described in the normative text that are discussed in this overview include:

o TLS with a previously issued client certificate (e.g., an existing

  certificate issued by the EST CA);

o TLS with a previously installed certificate (e.g., manufacturer-

  installed certificate or a certificate issued by some other
  party);

o Certificate-less TLS (e.g., with a shared credential distributed

  out-of-band);

o HTTP-based with a username/password distributed out-of-band.

Certificate TLS Authentication

If the EST client has a previously installed certificate issued by a third-party CA, this certificate can be used to authenticate the client's request for a certificate from the EST server (if that CA is recognized by the EST server). An EST client responds to the EST server's TLS certificate request message with the existing certificate already held by the client. The EST server will verify the client's existing certificate and authorize the client's request as described in Section 3.3.2.

Certificate-Less TLS Authentication

The EST client and EST server can be mutually authenticated using a certificate-less TLS cipher suite (see Section 3.3.3).

HTTP-Based Client Authentication

The EST server can optionally also request that the EST client submit a username/password using the HTTP Basic or Digest authentication methods (see Section 3.2.3). This approach is desirable if the EST client cannot be authenticated during the TLS handshake (see Section 3.3.2) or the EST server policy requires additional authentication information; see Section 3.2.3. In all cases, HTTP-based client authentication is only to be performed over a TLS-protected transport (see Section 3.3).

Client Certificate Reissuance

An EST client can renew/rekey its existing client certificate by submitting a re-enrollment request to an EST server.

When the current EST client certificate can be used for TLS client authentication (Section 3.3.2), the client presents this certificate to the EST server for client authentication. When the to be reissued EST client certificate cannot be used for TLS client authentication, any of the authentication methods used for initial enrollment can be used.

For example, if the client has an alternative certificate issued by the EST CA that can be used for TLS client authentication, then it can be used.

The certificate request message includes the same Subject and SubjectAltName as the current certificate. Name changes are requested as specified in Section 4.2.2.

Server Key Generation

The EST client can request a server-generated certificate and key pair (see Section 4.4).

Full PKI Request Messages

Full PKI Request RFC5272 messages can be transported via EST using the Full CMC Request function. This affords access to functions not provided by the Simple Enrollment functions. Full PKI Request messages are defined in Sections 3.2 and 4.2 of RFC5272. See Section 4.3 for a discussion of how EST provides a transport for these messages.

Certificate Signing Request (CSR) Attributes Request

Prior to sending an enrollment request to an EST server, an EST client can query the EST server for a set of additional attributes that the client is requested to use in a subsequent enrollment request.

These attributes can provide additional descriptive information that the EST server cannot access itself, such as the Media Access Control (MAC) address of an interface of the EST client. Alternatively, these attributes can indicate the kind of enrollment request, such as a specific elliptic curve or a specific hash function that the client is expected to use when generating the CSR.

Protocol Design and Layering

Figure 2 provides an expansion of Figure 1, describing how the layers are used. Each aspect is described in more detail in the sections that follow.

EST Layering:

                             Figure 2

Specifying HTTPS as the secure transport for enrollment messages introduces two "layers" to communicate authentication and control messages: TLS and HTTP.

The TLS layer provides integrity and confidentiality during transport. The proof-of-identity is supplied by TLS handshake authentication and optionally also by the HTTP layer headers. The message type and control/error messages are included in the HTTP headers.

CMC (RFC5272, Section 3.1) notes that "the Simple PKI Request MUST NOT be used if a proof-of-identity needs to be included". Since the TLS and HTTP layers can provide proof-of-identity for EST clients and servers, the Simple PKI message types are used.

The TLS layer certificate exchange provides a method for authorizing client enrollment requests using existing certificates. Such certificates may have been issued by the CA (from which the client is requesting a certificate), or they may have been issued under a distinct PKI (e.g., an IEEE 802.1AR Initial Device Identifier (IDevID) [IDevID] credential).

Proof-of-possession (POP) is a distinct issue from proof-of-identity and is included in the Simple PKI message type as described in Section 3.4. A method of linking proof-of-identity and proof-of-possession is described in Section 3.5.

This document also defines transport for CMC RFC5272 that complies with the CMC Transport Protocols RFC5273. CMC's POP and proof-of-identity mechanisms are defined in CMC, but the mechanisms here can also be used in conjunction with those mechanisms in "Full PKI" messages.

During protocol exchanges, different certificates can be used. The following table provides an informative overview. End-entities can have one or more certificates of each type listed in Figure 3 and use one or more trust anchor databases of each type listed in Figure 4.

                             Figure 3

                             Figure 4

Application Layer

The EST client MUST be capable of generating and parsing Simple PKI messages (see Section 4.2). Generating and parsing Full PKI messages is OPTIONAL (see Section 4.3). The client MUST also be able to request CA certificates from the EST server and parse the returned "bag" of certificates (see Section 4.1). Requesting CSR attributes and parsing the returned list of attributes is OPTIONAL (see Section 4.5).

Details of the EST client application configuration are out of scope of the protocol discussion but are necessary for understanding the prerequisites of initiating protocol operations. The EST client is RECOMMENDED to be configured with TA databases for Section 3.3.1 or with a secret key for Section 3.3.3. Implementations conforming to this standard MUST provide the ability to designate Explicit TAs. For human usability reasons, a "fingerprint" of an Explicit TA database entry can be configured for bootstrapping as discussed in Section 4.1.1. Configuration of an Implicit TA database, perhaps by its inclusion within the EST client distribution or available from the operating system, provides flexibility along with the caveats detailed in Section 6. Implementations conforming to this standard MUST provide the ability to disable use of any Implicit TA database.

The EST client is configured with sufficient information to form the EST server URI. This can be the full operation path segment (e.g., https://www.example.com/.well-known/est/ or https://www.example.com/.well-known/est/arbitraryLabel1), or the EST client can be configured with a tuple composed of the authority portion of the URI along with the OPTIONAL label (e.g., "www.example.com:80" and "arbitraryLabel1") or just the authority portion of the URI.

HTTP Layer

HTTP is used to transfer EST messages. URIs are defined for handling each media type (i.e., message type) as described in Section 3.2.2. HTTP is also used for client authentication services when TLS client authentication is not available, due to the lack of a client certificate suitable for use by TLS (see Section 3.2.3). HTTP authentication can also be used in addition to TLS client authentication if the EST server wishes additional authentication information, as noted in Section 2.2.3. Registered media types are used to convey EST messages as specified in Figure 6.

HTTP 1.1 RFC2616 and above support persistent connections. As described in Section 8.1 of RFC 2616, persistent connections may be used to reduce network and processing loads associated with multiple HTTP requests. EST does not require or preclude persistent HTTP connections.

HTTP Headers for Control

The HTTP Status value is used to communicate success or failure of an EST function. HTTP authentication is used by a client when requested by the server.

The media types specified in the HTTP Content-Type header indicate which EST message is being transferred. Media types used by EST are specified in Section 3.2.4.

HTTP redirections (3xx status codes) to the same web origin (see RFC6454) SHOULD be handled by the client without user input so long as all applicable security checks (Sections 3.3 and 3.6) have been enforced on the initial connection. The client initiates a new TLS connection and performs all applicable security checks when redirected to other web origin servers. Redirections to other web origins require the EST client to obtain user input for non-GET or HEAD requests as specified in RFC2616. Additionally, if the client has already generated a CSR that includes linking identity and POP information (Section 3.5), then the CSR will need to be recreated to incorporate the tls-unique from the new, redirected session. Note: the key pair need not be regenerated. These are processing and interface burdens on the client. EST server administrators are advised to take this into consideration.

HTTP URIs for Control

The EST server MUST support the use of the path-prefix of "/.well- known/" as defined in RFC5785 and the registered name of "est". Thus, a valid EST server URI path begins with "https://www.example.com/.well-known/est". Each EST operation is indicated by a path-suffix that indicates the intended operation:

                             Figure 5

The operation path (Figure 5) is appended to the path-prefix to form the URI used with HTTP GET or POST to perform the desired EST operation. An example valid URI absolute path for the "/cacerts" operation is "/.well-known/est/cacerts". To retrieve the CA's certificates, the EST client would use the following HTTP request-line:

GET /.well-known/est/cacerts HTTP/1.1

Likewise, to request a new certificate in this example scheme, the EST client would use the following request-line:

POST /.well-known/est/simpleenroll HTTP/1.1

The use of distinct operation paths simplifies implementation for servers that do not perform client authentication when distributing /cacerts responses.

An EST server MAY provide service for multiple CAs as indicated by an OPTIONAL additional path segment between the registered application name and the operation path. To avoid conflict, the CA label MUST NOT be the same as any defined operation path segment. The EST server MUST provide services regardless of whether the additional path segment is present. The following are three example valid URIs:

1. https://www.example.com/.well-known/est/cacerts

2. https://www.example.com/.well-known/est/arbitraryLabel1/cacerts

3. https://www.example.com/.well-known/est/arbitraryLabel2/cacerts

In this specification, the distinction between enroll and renew/rekey is explicitly indicated by the HTTP URI. When requesting /fullcmc operations, CMC RFC5272 uses the same messages for certificate renewal and certificate rekey.

An EST server can provide additional services using other URIs.

HTTP-Based Client Authentication

The EST server MAY request HTTP-based client authentication. This request can be in addition to successful TLS client authentication (Section 3.3.2) if EST server policy requires additional authentication. (For example, the EST server may require that an EST client "knows" a password in addition to "having" an existing client certificate.) Or, HTTP-based client authentication can be an EST server policy-specified fallback in situations where the EST client did not successfully complete the TLS client authentication. (This might arise if the EST client is enrolling for the first time or if the certificates available to an EST client cannot be used for TLS client authentication.)

HTTP Basic and Digest authentication MUST only be performed over TLS 1.1 RFC4346 or later versions. NULL and anon cipher suites MUST NOT be used because they do not provide confidentiality or support mutual certificate-based or certificate-less authentication, respectively. As specified in "Certificate Management over CMS (CMC): Transport Protocols" RFC5273, the server "MUST NOT assume client support for any type of HTTP authentication such as cookies, Basic authentication, or Digest authentication". Clients SHOULD support the Basic and Digest authentication mechanism.

Servers that wish to use Basic and Digest authentication reject the HTTP request using the HTTP-defined WWW-Authenticate response-header (RFC2616, Section 14.47). The client is expected to retry the request, including the appropriate Authorization Request header (RFC2617, Section 3.2.2), if the client is capable of using the Basic or Digest authentication. If the client is not capable of retrying the request or it is not capable of Basic or Digest authentication, then the client MUST terminate the connection.

A client MAY set the username to the empty string ("") if it is presenting a password that is not associated with a username.

Support for HTTP-based client authentication has security ramifications as discussed in Section 6. The client MUST NOT respond to the server's HTTP authentication request unless the client has authorized the EST server (as per Section 3.6).

Message Types

This document uses existing media types for the messages as specified by FTP and HTTP RFC2585, application/pkcs10 RFC5967, and CMC RFC5272.

For consistency with RFC5273, each distinct EST message type uses an HTTP Content-Type header with a specific media type.

The EST messages and their corresponding media types for each operation are:

                             Figure 6

TLS Layer

TLS provides authentication, which in turn enables authorization decisions. The EST server and EST client are responsible for ensuring that an acceptable cipher suite is negotiated and that mutual authentication has been performed. TLS authentication is most commonly enabled with the use of certificates RFC5280. Alternately, certificate-less TLS authentication, where neither the client nor server present a certificate, is also an acceptable method for EST mutual authentication (Section 3.3.3). 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).

HTTPS RFC2818 specifies how HTTP messages are carried over TLS. HTTPS MUST be used. TLS 1.1 RFC4346 (or a later version) MUST be used for all EST communications. TLS session resumption RFC5077 SHOULD be supported.

TLS channel-binding information can 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. The EST server MUST implement Section 3.5.

TLS-Based Server Authentication

TLS server authentication with certificates MUST be supported.

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

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 Explicit and, if enabled, Implicit TA database(s). The client MUST maintain a distinction between the use of Explicit and Implicit TA databases during authentication in order to support proper authorization. The EST client MUST perform authorization checks as specified in Section 3.6.

If certificate validation fails, the client MAY follow the procedure outlined in Section 4.1.1 for Bootstrap Distribution of CA certificates.

TLS-Based Client Authentication

TLS client authentication is the RECOMMENDED method for identifying EST clients. HTTP-based client authentication (Section 3.2.3) 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.

Generally, the client will use an existing certificate for renew or rekey operations. If the certificate to be renewed or rekeyed is appropriate for the negotiated cipher suite, then the client MUST use it for the TLS handshake, otherwise the client SHOULD use an alternate certificate that is suitable for the cipher suite and contains the same subject identity information. When requesting an enroll operation, the client MAY use a client certificate issued by a third party to authenticate itself.

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

The server validates the TLS client certificate using the EST server Explicit and, if enabled, Implicit TA database(s). The server MUST maintain a distinction between the use of Explicit and Implicit TA databases during authentication in order to support proper authorization.

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 (Section 3.2.3) or certificate-less TLS authentication (Section 3.3.3).

Certificate-Less TLS Mutual Authentication

Certificate-less TLS cipher suites provide a way to perform mutual authentication in situations where neither the client nor server have certificates, do not desire to use certificates, or do not have the trust anchors necessary to verify a certificate. The client and server MAY negotiate a certificate-less cipher suite for mutual authentication.

When using certificate-less mutual authentication in TLS for enrollment, the cipher suite MUST be based on a protocol that is

resistant to dictionary attack and MUST be based on a zero knowledge protocol. Transport Layer Security-Secure Remote Password (TLS-SRP) cipher suites, i.e., those with _SRP_ in the name, listed in Section 2.7 of RFC5054 are suitable for this purpose. Section 6 lists the characteristics of a cipher suite that are suitable for use in certificate-less mutual authentication for enrollment.

Successful authentication using a certificate-less cipher suite proves knowledge of a pre-shared secret that implicitly authorizes a peer in the exchange.

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

Linking Identity and POP Information

Server policy will determine whether clients are required to use the mechanism specified in this section. This specification provides a method of linking identity and proof-of-possession by including information specific to the current authenticated TLS session within the signed certification request. The client can determine if the server requires the linking of identity and POP by examining the CSR Attributes Response (see Section 4.5.2). Regardless of the CSR Attributes Response, 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. 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 "Linking Identity and POP Information" method defined by Section 6 of RFC5272 that is available if Full PKI messages are used.

The client generating the CSR obtains the tls-unique value from the TLS subsystem as described in Channel Bindings for TLS RFC5929. The EST client operations between obtaining the tls-unique value through generation of the CSR that contains the current tls-unique value and the subsequent verification of this value by the EST server are the "phases of the application protocol during which application- layer authentication occurs"; these operations are protected by the synchronization interoperability mechanism described in the "Channel Bindings for TLS" interoperability notes in Section 3.1 of RFC5929.

When performing renegotiation, TLS "secure_renegotiation" RFC5746 MUST be used.

The tls-unique value is base64 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). The challenge-password field is limited to 255 bytes (Section 7.4.9 of RFC5246 indicates that no existing cipher suite would result in an issue with this limitation). If the challenge-password attribute is absent, the client did not include the optional channel-binding information (the presence of the challenge-password attribute indicates the inclusion of tls-unique information).

If the EST server makes use of a 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 the linking of identity and POP information is required.

Server Authorization

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

The EST client authorization method depends on which method was used to authenticate the server. When the Explicit TA database is used to authenticate the EST server, then Section 3.6.1 applies. When the Implicit TA database is used to authenticate the EST server, then

Section 3.6.2 applies. 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.

Client Use of Explicit TA Database

When the EST client Explicit TA database is used to validate the EST server certificate, the client MUST check either the configured URI or the most recent HTTP redirection URI against the server's identity according to the rules specified in RFC6125, Section 6.4, or the EST server certificate MUST contain the id-kp-cmcRA RFC6402 extended key usage extension.

Client Use of Implicit TA Database

When the EST client Implicit TA database is used to validate the EST server certificate, the client MUST check the configured URI and each HTTP redirection URI according to the rules specified in RFC6125, Section 6.4. The provisioned URI or the most recent HTTP redirection URI provides the basis for authorization, and the server's authenticated identity confirms it is the authorized server.

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.

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.

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.

Bootstrap Distribution of CA Certificates

It is possible that the client was not configured with an Implicit TA database that allows a bootstrap installation of the Explicit TA database as described in 4.1.3. This section describes an alternate method by which minimally configured EST clients can populate their Explicit TA database.

If the EST client application does not specify either an Explicit TA database or an Implicit 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 (Sections 4.1.3 or 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-256 or SHA-512 [SHS] hash on the whole CA certificate). In a /fullcmc response, it is the Publish Trust Anchors control (CMC RFC5272, Section 6.15) 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 as specified in Section 3.3.1 or if the optional certificate-less authentication is used as specified in Section 3.3.3.

The EST client uses the /cacerts response to establish an Explicit Trust Anchor database 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).

CA Certificates Request

EST clients request the EST CA 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 SHOULD 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 if certificate-based authentication is used or Section 3.3.3 if the optional certificate-less authentication is used, and check the server's authorization as given in Section 3.6, or follow the procedure outlined in Section 4.1.1.

CA Certificates Response

If successful, the server response MUST have an HTTP 200 response code. Any other response code indicates an error and the client MUST abort the protocol.

A successful response MUST be a certs-only CMC Simple PKI Response, as defined in RFC5272, containing the certificates described in the following paragraph. The HTTP content-type of "application/pkcs7-mime" is used. The Simple PKI Response is sent with a Content-Transfer-Encoding of "base64" RFC2045.

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 EST CA 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 EST CA's most recent self-signed certificate (e.g., NewWithNew certificate) is self-signed and has the latest NotAfter date. If the

EST server does not include these in the response, then after the current EST CA certificate expires, the EST clients will need to be reinitialized with the PKI using the Bootstrap Distribution of CA certificates (Section 4.1.1) method, which involves user interaction.

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 EST client MUST store the extracted EST CA certificate as an Explicit TA database entry for subsequent EST server authentication. The EST client SHOULD disable use of Implicit TA database entries for this EST server now that an Explicit TA database entry is available. If the client disables the Implicit TA database, and if the EST server certificate was verified using an Implicit TA database entry, then the client MUST include the "Trusted CA Indication" extension in future TLS sessions RFC6066. This indicates to the server that only an EST server certificate authenticatable by the Explicit TA database entry is now acceptable (otherwise, the EST server might continue to use a server certificate that is only verifiable by a now disabled Implicit TA).

The EST client SHOULD also make the CA Certificate response information available to the end-entity software for use when validating peer certificates.

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 if certificate-based authentication is used or Section 3.3.3 if the optional certificate-less authentication is used. The client MUST verify the authorization of the EST server as specified in Section 3.6.

The server MUST authenticate the client as specified in Section 3.3.2 if certificate-based authentication is used or Section 3.3.3 if the optional certificate-less authentication is used. 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.)

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 client-possessed private key to the EST server. If the CSR KeyUsage extension indicates that the private key can be used to generate digital signatures, then the client MUST generate the CSR signature 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 MAY still be generated using the private key, but the key MUST NOT be used 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 are used when the key pair cannot 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 RFC5967 with a Content- Transfer-Encoding of "base64" RFC2045.

If the EST client authenticated using a previously installed certificate issued by a third-party CA (see Section 2.2.1), the client MAY include the ChangeSubjectName attribute, as defined in RFC6402, in the CSR to request that the subjectName and SubjectAltName be changed in the new certificate.

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.

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, then the EST server renews the client certificate. If the public key information in the certification request is different than the current client certificate, then the EST server rekeys the client certificate.

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

A successful response MUST be a certs-only CMC Simple PKI Response, as defined in RFC5272, containing only the certificate that was issued. The HTTP content-type of "application/pkcs7-mime" with an smime-type parameter "certs-only" is used, as specified in RFC5273.

The server MUST answer with a suitable 4xx or 5xx HTTP RFC2616 error code when a problem occurs. 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 plaintext human- readable error message containing explanatory 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 states 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.

If the client closes the TLS connections while waiting for the Retry- After time to expire, then the client initiates a new TLS connection and performs all applicable security checks. If the client has already generated a CSR that includes linking identity and POP information (Section 3.5), then the CSR will need to be recreated to incorporate the tls-unique from the new, redirected session. Note: the key pair need not be regenerated. These are processing and interface burdens on the client. EST server administrators are advised to take this into consideration.

The EST client MAY also make the certificate response, and associated private key, available to end-entity software for use as an end-entity certificate.

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.

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" with an smime-type parameter "CMC-request", as specified in RFC5273. The body of the message is the binary value of the encoding of the PKI Request with a Content-Transfer-Encoding of "base64" RFC2045.

Full CMC 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 with an smime-type parameter of "certs-only" or the Full PKI Response with an smime-type parameter "CMC-response", as specified in Section 3.2.1 of RFC5751. The body of the message is the binary value of the encoding of the PKI Response with a Content-Transfer-Encoding of "base64" RFC2045.

When rejecting a request, the server MUST specify either an HTTP 4xx error or an HTTP 5xx error. A CMC response with the content-type of "application/pkcs7-mime" MUST be included in the response data for any CMC error response.

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

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 if certificate-based authentication is used or Section 3.3.3 if the optional certificate-less authentication is used, and check the server's authorization as given in Section 3.6.

The EST server MUST authenticate the client, as specified in Section 3.3.2 if certificate-based authenticated is used or Section 3.3.3 if the optional certificate-less authentication is used, and check the client's authorization as given in Section 3.7. The EST server applies whatever authorization or logic it chooses to determine if the private key and certificate should be provided.

Cipher suites that have a NULL confidentiality algorithm MUST NOT be used as they will disclose the contents of an unprotected private key.

Proper random number and key generation RFC4086 is a server implementation responsibility, and server archiving of generated keys is determined by CA policy. 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.

Server-Side Key Generation Request

The certificate request is HTTPS POSTed and is the same format as for the "/simpleenroll" and "/simplereenroll" path extensions with the same content-type and transfer encoding.

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 of 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 an attribute in the CSR indicating the encryption key to be used. Both symmetric and asymmetric encryption are supported as described in the following subsections. The client MUST also include an SMIMECapabilities attribute (RFC2633, Section 2.5) in the CSR to indicate the key encipherment algorithms the client is willing to use.

It is strongly RECOMMENDED that the clients request that the returned private key be afforded the additional security of the Cryptographic Message Syntax (CMS) EnvelopedData in addition to the TLS-provided security to protect against unauthorized disclosure.

Requests for Symmetric Key Encryption of the Private Key

To specify a symmetric encryption key to be used to encrypt the server-generated private key, the client MUST include a DecryptKeyIdentifier attribute (as defined in Section 2.2.5 of 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 secret key to encrypt a private 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 DecryptKeyIdentifier to the key generator and the client is outside the scope of this document.

Requests for Asymmetric Encryption of the Private Key

To specify an asymmetric encryption key to be used to encrypt the server-generated private key, the client MUST include an AsymmetricDecryptKeyIdentifier attribute. The AsymmetricDecryptKeyIdentifier attribute is defined as:

id-aa-asymmDecryptKeyID OBJECT IDENTIFIER ::= {

   id-aa 54 }

The asymmetric-decrypt-key-identifier attribute values have ASN.1 type AsymmetricDecryptKeyIdentifier (where ASN.1 is defined in [X.680])::

  AsymmetricDecryptKeyIdentifier ::= OCTET STRING

If the server does not have a public 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 AsymmetricDecryptKeyIdentifier to the key generator and the client is outside the scope of this document. If the key identified is bound to an X.509 certificate, then the key MUST either explicitly support keyTransport or keyAgreement or its use MUST be unrestricted.

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 not being employed, the private key data MUST be placed in an "application/pkcs8". An "application/pkcs8" part consists of the base64-encoded DER-encoded [X.690] PrivateKeyInfo with a Content-Transfer-Encoding of "base64" RFC2045.

If additional encryption is being employed, the private key is placed inside of a CMS SignedData. The SignedData is signed by the party that generated the private key, which may or may not be the EST server or the EST CA. The SignedData is further protected by placing it inside of a CMS EnvelopedData, as described in Section 4 of RFC5958. The following list shows how the EncryptedData is used, depending on the type of protection key specified by the client.

o If the client specified a symmetric encryption key to protect the

  server-generated private key, the EnvelopedData content is
  encrypted using the secret key identified in the request.  The
  EnvelopedData RecipientInfo field MUST indicate the key-encryption
  kekri key management technique.  The values are as follows:
  version is set to 4, key-encryption key identifier (kekid) is set
  to the value of the DecryptKeyIdentifier from Section 4.4.1.1;
  keyEncryptionAlgorithm is set to one of the key wrap algorithms
  that the client included in the SMIMECapabilities accompanying the
  request; and encryptedKey is the encrypted key.

o If the client specified an asymmetric encryption key suitable for

  key transport operations to protect the server-generated private
  key, the EnvelopedData content is encrypted using a randomly
  generated symmetric encryption key.  The cryptographic strength of
  the symmetric encryption key SHOULD be equivalent to the client-
  specified asymmetric key.  The EnvelopedData RecipientInfo field
  MUST indicate the KeyTransRecipientInfo (ktri) key management
  technique.  In KeyTransRecipientInfo, the RecipientIdentifier
  (rid) is either the subjectKeyIdentifier copied from the attribute
  defined in Section 4.4.1.2 or the server determines an associated
  issuerAndSerialNumber from the attribute; version is derived from
  the choice of rid RFC5652, keyEncryptionAlgorithm is set to one
  of the key wrap algorithms that the client included in the
  SMIMECapabilities accompanying the request, and encryptedKey is
  the encrypted key.

o If the client specified an asymmetric encryption key suitable for

  key agreement operations to protect the server-generated private
  key, the EnvelopedData content is encrypted using a randomly
  generated symmetric encryption key.  The cryptographic strength of
  the symmetric encryption key SHOULD be equivalent to the client-
  specified asymmetric key.  The EnvelopedData RecipientInfo field
  MUST indicate the KeyAgreeRecipientInfo (kari) key management
  technique.  In the KeyAgreeRecipientInfo type, version,
  originator, and user keying material (ukm) are as in RFC5652,
  and keyEncryptionAlgorithm is set to one of the key wrap
  algorithms that the client included in the SMIMECapabilities
  accompanying the request.  The recipient's key identifier is
  either copied from the attribute defined in Section 4.4.1.2 to
  subjectKeyIdentifier or the server determines an
  IssuerAndSerialNumber that corresponds to the value provided in
  the attribute.

In all three additional encryption cases, the EnvelopedData is returned in the response as an "application/pkcs7-mime" part with an smime-type parameter of "server-generated-key" and a Content- Transfer-Encoding of "base64".

The certificate data part is an "application/pkcs7-mime" and exactly matches the certificate response to /simpleenroll.

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 plaintext human-readable error message.

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.

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

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

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

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.

Responses to attribute request messages MUST be encoded as the content-type of "application/csrattrs" with a Content-Transfer-Encoding of "base64" RFC2045. The syntax for application/csrattrs body is as follows:

CsrAttrs ::= SEQUENCE SIZE (0..MAX) OF AttrOrOID

AttrOrOID ::= CHOICE (oid OBJECT IDENTIFIER, attribute Attribute }

Attribute { ATTRIBUTE:IOSet } ::= SEQUENCE {

    type   ATTRIBUTE.&id({IOSet}),
    values SET SIZE(1..MAX) OF ATTRIBUTE.&Type({IOSet}{@type}) }

An EST server includes zero or more OIDs or attributes RFC2986 that it requests the client to use in the certification request. The client MUST ignore any OID or attribute it does not recognize. When the server encodes CSR Attributes as an empty SEQUENCE, it means that the server has no specific additional information it desires in a client certification request (this is functionally equivalent to an HTTP response code of 204 or 404).

If the CA requires a particular crypto system or use of a particular signature scheme (e.g., certification of a public key based on a certain elliptic curve, or signing using a certain hash algorithm) it MUST provide that information in the CSR Attribute 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.

The structure of the CSR Attributes Response SHOULD, to the greatest extent possible, reflect the structure of the CSR it is requesting. Requests to use a particular signature scheme (e.g. using a particular hash function) are represented as an OID to be reflected in the SignatureAlgorithm of the CSR. Requests to use a particular crypto system (e.g., certification of a public key based on a certain elliptic curve) are represented as an attribute, to be reflected as the AlgorithmIdentifier of the SubjectPublicKeyInfo, with a type indicating the algorithm and the values indicating the particular parameters specific to the algorithm. Requests for descriptive information from the client are made by an attribute, to be represented as Attributes of the CSR, with a type indicating the RFC2985 extensionRequest and the values indicating the particular attributes desired to be included in the resulting certificate's extensions.

The sequence is Distinguished Encoding Rules (DER) encoded [X.690] 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 challengePassword (indicating that linking of identity and POP information is requested; see Section 3.5), an extensionRequest with the Media Access Control (MAC) address (RFC2307) of the client, and to use the secp384r1 elliptic curve and to sign with the SHA384 hash function. Then, it takes the following:

     OID:        challengePassword (1.2.840.113549.1.9.7)

     Attribute:  type = extensionRequest (1.2.840.113549.1.9.14)
                 value = macAddress (1.3.6.1.1.1.1.22)

     Attribute:  type = id-ecPublicKey (1.2.840.10045.2.1)
                 value = secp384r1 (1.3.132.0.34)

     OID:        ecdsaWithSHA384 (1.2.840.10045.4.3.3)

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

   30 41 06 09 2a 86 48 86 f7 0d 01 09 07 30 12 06 07 2a 86 48 ce 3d
   02 01 31 07 06 05 2b 81 04 00 22 30 16 06 09 2a 86 48 86 f7 0d 01
   09 0e 31 09 06 07 2b 06 01 01 01 01 16 06 08 2a 86 48 ce 3d 04 03
   03

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

   MEEGCSqGSIb3DQEJBzASBgcqhkjOPQIBMQcGBSuBBAAiMBYGCSqGSIb3DQEJDjEJ
   BgcrBgEBAQEWBggqhkjOPQQDAw==

IANA Considerations

Section 4.4.1.2 defines an OID that has been registered in an arc delegated by the IANA to the PKIX working group.

IANA has registered the following:

IANA updated the well-known URI registry with the following filled-in template from RFC5785.

  URI suffix: est

  Change controller: IETF

IANA has updated the "Application Media Types" registry with the following filled-in templates from RFC6838.

The media subtype for CSR attributes in a CSR Attributes Response 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 is normally 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: .csrattrs

   Person & email address to contact for further information:

     Dan Harkins <[email protected]>

   Restrictions on usage: None

   Author: Dan Harkins <[email protected]>

   Intended usage: COMMON

   Change controller: The IESG <[email protected]>

The application/pkcs7-mime content-type defines the optional "smime-type" parameter RFC5751 with a set of specific values. This document adds another value, "server-generated-key", as the parameter value for Server-side Key Generation Response.

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 Implicit TA database for certificate validation (see Section 3), then authorization proceeds as specified in Section 3.6.2. In this situation, the client has validated the server as being a responder that is certified by a third party for the URI configured, but it 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 an Implicit Trust Anchor database are RECOMMENDED to use only 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 man in the middle). It is RECOMMENDED that the Implicit 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. Disabling the Implicit Trust Anchor database after successfully receiving the Distribution of CA certificates response (Section 4.1.3) limits any vulnerability to the first TLS exchange.

Certificate-less TLS cipher suites that maintain security and perform the mutual authentication necessary for enrollment have the following properties:

o the only information leaked by an active attack is whether or not

  a single guess of the secret is correct.

o any advantage an adversary gains is through interaction and not

  computation.

o it is possible to perform countermeasures, such as exponential

  backoff after a certain number of failed attempts, to frustrate
  repeated active attacks.

Using a certificate-less cipher suite that does not have the properties listed above would render the results of enrollment void and potentially result in certificates being issued to unauthenticated and/or unauthorized entities.

When using a certificate-less TLS cipher suite, the shared secret used for authentication and authorization cannot be shared with an entity that is not a party to the exchange: someone other than the client and the server. Any additional 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 result in corruption of a client's trust anchor database.

TLS cipher suites that include "_EXPORT_" and "_DES_" in their names MUST NOT be used. These ciphers do not offer a sufficient level of protection; 40-bit crypto in 2013 doesn't offer acceptable protection, and the use of DES is deprecated.

As described in CMC, Section 6.7 of 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 without any application-layer protection. 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 RECOMMENDED 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 an Implicit 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.

ASN.1 encoding rules (e.g., DER and BER) have a type-length-value structure, and it is easy to construct malicious content with invalid length fields that can cause buffer overrun conditions. ASN.1 encoding rules allow for arbitrary levels of nesting, which may make it possible to construct malicious content that will cause a stack overflow. Interpreters of ASN.1 structures should be aware of these issues and should take appropriate measures to guard against buffer overflows and stack overruns in particular, and malicious content in general.

References

Normative References

RFC2045 Freed, N. and N. Borenstein, "Multipurpose Internet Mail

          Extensions (MIME) Part One: Format of Internet Message
          Bodies", RFC 2045, November 1996.

RFC2119 Bradner, S., "Key words for use in RFCs to Indicate

          Requirement Levels", BCP 14, RFC 2119, March 1997.

RFC2585 Housley, R. and P. Hoffman, "Internet X.509 Public Key

          Infrastructure Operational Protocols: FTP and HTTP", RFC
          2585, 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, 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, June 1999.

RFC2633 Ramsdell, B., "S/MIME Version 3 Message Specification",

          RFC 2633, June 1999.

RFC2986 Nystrom, M. and B. Kaliski, "PKCS #10: Certification

          Request Syntax Specification Version 1.7", RFC 2986,
          November 2000.

RFC3986 Berners-Lee, T., Fielding, R., and L. Masinter, "Uniform

          Resource Identifier (URI): Generic Syntax", STD 66, RFC
          3986, January 2005.

RFC4086 Eastlake, D., Schiller, J., and S. Crocker, "Randomness

          Requirements for Security", BCP 106, RFC 4086, June 2005.

RFC4108 Housley, R., "Using Cryptographic Message Syntax (CMS) to

          Protect Firmware Packages", RFC 4108, August 2005.

RFC4210 Adams, C., Farrell, S., Kause, T., and T. Mononen,

          "Internet X.509 Public Key Infrastructure Certificate
          Management Protocol (CMP)", RFC 4210, September 2005.

RFC4346 Dierks, T. and E. Rescorla, "The Transport Layer Security

          (TLS) Protocol Version 1.1", RFC 4346, April 2006.

RFC4648 Josefsson, S., "The Base16, Base32, and Base64 Data

          Encodings", RFC 4648, October 2006.

RFC5077 Salowey, J., Zhou, H., Eronen, P., and H. Tschofenig,

          "Transport Layer Security (TLS) Session Resumption without
          Server-Side State", RFC 5077, January 2008.

RFC5246 Dierks, T. and E. Rescorla, "The Transport Layer Security

          (TLS) Protocol Version 1.2", RFC 5246, August 2008.

RFC5272 Schaad, J. and M. Myers, "Certificate Management over CMS

          (CMC)", RFC 5272, June 2008.

RFC5273 Schaad, J. and M. Myers, "Certificate Management over CMS

          (CMC): Transport Protocols", RFC 5273, June 2008.

RFC5274 Schaad, J. and M. Myers, "Certificate Management Messages

          over CMS (CMC): Compliance Requirements", RFC 5274, 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, May 2008.

RFC5652 Housley, R., "Cryptographic Message Syntax (CMS)", STD 70,

          RFC 5652, September 2009.

RFC5746 Rescorla, E., Ray, M., Dispensa, S., and N. Oskov,

          "Transport Layer Security (TLS) Renegotiation Indication
          Extension", RFC 5746, February 2010.

RFC5751 Ramsdell, B. and S. Turner, "Secure/Multipurpose Internet

          Mail Extensions (S/MIME) Version 3.2 Message
          Specification", RFC 5751, January 2010.

RFC5785 Nottingham, M. and E. Hammer-Lahav, "Defining Well-Known

          Uniform Resource Identifiers (URIs)", RFC 5785, April
          2010.

RFC5929 Altman, J., Williams, N., and L. Zhu, "Channel Bindings

          for TLS", RFC 5929, July 2010.

RFC5958 Turner, S., "Asymmetric Key Packages", RFC 5958, August

          2010.

RFC6066 Eastlake, D., "Transport Layer Security (TLS) Extensions:

          Extension Definitions", RFC 6066, January 2011.

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, March 2011.

RFC6402 Schaad, J., "Certificate Management over CMS (CMC)

          Updates", RFC 6402, November 2011.

RFC6454 Barth, A., "The Web Origin Concept", RFC 6454, December

          2011.

RFC6838 Freed, N., Klensin, J., and T. Hansen, "Media Type

          Specifications and Registration Procedures", BCP 13, RFC
          6838, January 2013.

[X.680] ITU-T Recommendation X.680 (2008) | ISO/IEC 8824-1:2008,

          "Abstract Syntax Notation One (ASN.1): Specification of
          basic notation", November 2008,
          <http://www.itu.int/rec/T-REC-X.680-200811-I/en>.

[X.690] ITU-T Recommendation X.690 (2008) | ISO/IEC 8825-1:2008,

          "ASN.1 encoding rules: Specification of Basic Encoding
          Rules (BER), Canonical Encoding Rules (CER) and
          Distinguished Encoding Rules (DER)", November 2008,
          <http://www.itu.int/rec/T-REC-X.690-200811-I/en>.

Informative References

[IDevID] IEEE Standards Association, "IEEE 802.1AR Secure Device

          Identifier", December 2009, <http://standards.ieee.org/
          findstds/standard/802.1AR-2009.html>.

RFC2307 Howard, L., "An Approach for Using LDAP as a Network

          Information Service", RFC 2307, March 1998.

RFC2818 Rescorla, E., "HTTP Over TLS", RFC 2818, May 2000.

RFC2985 Nystrom, M. and B. Kaliski, "PKCS #9: Selected Object

          Classes and Attribute Types Version 2.0", RFC 2985,
          November 2000.

RFC3394 Schaad, J. and R. Housley, "Advanced Encryption Standard

          (AES) Key Wrap Algorithm", RFC 3394, September 2002.

RFC5054 Taylor, D., Wu, T., Mavrogiannopoulos, N., and T. Perrin,

          "Using the Secure Remote Password (SRP) Protocol for TLS
          Authentication", RFC 5054, November 2007.

RFC5967 Turner, S., "The application/pkcs10 Media Type", RFC 5967,

          August 2010.

RFC6403 Zieglar, L., Turner, S., and M. Peck, "Suite B Profile of

          Certificate Management over CMS", RFC 6403, November 2011.

[SHS] National Institute of Standards and Technology, "Secure

          Hash Standard (SHS)", Federal Information Processing
          Standard Publication 180-4, March 2012,
          <http://csrc.nist.gov/publications/fips/
          fips180-4/fips-180-4.pdf>.

[SP-800-57-Part-1]

          National Institute of Standards and Technology,
          "Recommendation for Key Management - Part 1: General
          (Revision 3)", July 2012,
          <http://csrc.nist.gov/publications/nistpubs/800-57/
          sp800-57_part1_rev3_general.pdf>.

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 /.well-known/est/cacerts 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: 192.0.2.1:8085 Accept: */*

In response, the server provides the current CA certificates:

HTTP/1.1 200 OK Status: 200 OK Content-Type: application/pkcs7-mime Content-Transfer-Encoding: base64 Content-Length: 4246

MIIMOQYJKoZIhvcNAQcCoIIMKjCCDCYCAQExADALBgkqhkiG9w0BBwGgggwMMIIC +zCCAeOgAwIBAgIJAJpY3nUZO3qcMA0GCSqGSIb3DQEBBQUAMBsxGTAXBgNVBAMT EGVzdEV4YW1wbGVDQSBPd08wHhcNMTMwNTA5MDM1MzMxWhcNMTQwNTA5MDM1MzMx WjAbMRkwFwYDVQQDExBlc3RFeGFtcGxlQ0EgT3dPMIIBIjANBgkqhkiG9w0BAQEF AAOCAQ8AMIIBCgKCAQEAwDqpiHopaICubpRqbpEN7LqTIqWELFIA9qDDheHIKuyO HW/ZAP7Rl4S5ZU6gaLW/ksseBUxdmox3KNyvtyjehIofTu28eZWhgy6/LCEGWR3P K+fgPBA0l0JfJR/8oeXZa70oLVQc3hI4kCeqjFMs+biYH0vp/RluhftyZ5kzQyH1 EGsRkw1/qUKkTZ8PCF8VFlYfqmUoqsaRTyZbjII4J+Y6/jEG+p7QreW9zcz4sPe8 3c/uhwMLOWQkZtKsQtgo5CpfYMjuAmk4Q2joQq2vcxlc+WNKHf+wbrDb11ORZril 9ISlI94oumcRz3uBG1Yg7z83hdDfasmdfbp8gOSNFQIDAQABo0IwQDAPBgNVHRMB Af8EBTADAQH/MB0GA1UdDgQWBBQITTKxMqATXrfc4ffpCIbt6Gsz0jAOBgNVHQ8B Af8EBAMCAQYwDQYJKoZIhvcNAQEFBQADggEBACPnQPu5WReUGuCMS0nBOGa2tXh6 uZP4mS3J1qEfDePam/IiU9ssyYdcDwhVvKMoP4gI/yu4XFqhdpIoy/PyD4T15MT7 KADCxXkh5rM1IqMui7FvBKLWYGdy9sjEf90wAkBjHBe/TMO1NNw3uELyONSkHIvo X0pu6aPmm/moIMyGi46niFse1iWlXXldGLkOQsh0e7U+wpBX07QpOr2KB2+Yf+uA KY1SWzEG23bUxXlvcbUMgANDGj5r6z+niKL0VlApip/iCuVEEOcZ91UlmJjVLQWA x6ie+v84oM+pIojiGM0C4XWcVlKKEgcMOsN3S4lvm8Ptpq0GLoIJY8NTD20wggMD MIIB66ADAgECAgEBMA0GCSqGSIb3DQEBBQUAMBsxGTAXBgNVBAMTEGVzdEV4YW1w bGVDQSBPd08wHhcNMTMwNTA5MDM1MzMyWhcNMTQwNTA5MDM1MzMyWjAbMRkwFwYD

VQQDExBlc3RFeGFtcGxlQ0EgTndPMIIBIjANBgkqhkiG9w0BAQEFAAOCAQ8AMIIB CgKCAQEAnn3rZ3rMJHwf7MD9K4mubxHAvtdnrsQf5OfgtMhRIL4aePNhAdgPyj8C loxOgD3UTV+dQ1ViOzVxPN7acikoOnkIdRpjpOpkyMo+KkvHMQXGnQTbsMAv1qWt 9S12DMpo0GOA1e4Ge3ud5YPOTR/q6PvjN51IEwYKksG7CglwZwB+5JbwhYr2D/0u btGltriRVixPWrvt+wz/ITp5rcjh/8RS3LE8tQy3kTNhJF3Y/esR2sSgOiPNgIto CATysbaINEPr4MemqML4tDpR/aG9y+8Qe7s1LyMFvDletp2mmBykAC/7nOat/pwU lB0sN524D1XAgz8ZKvWrkh+ZaOr3hwIDAQABo1IwUDAOBgNVHQ8BAf8EBAMCBLAw HQYDVR0OBBYEFLHEaeZbowSn2Jejizu/uWqyMkI8MB8GA1UdIwQYMBaAFAhNMrEy oBNet9zh9+kIhu3oazPSMA0GCSqGSIb3DQEBBQUAA4IBAQCLDkL7aLNV6hSOkIqH q+shV9YLO56/tj00vY/jV5skgDHk5d0B+OGortKVuGa57+v0avTrlJns3bNW8Ntv zkDEhmd00Ak02aPsi4wRHLFgttUf9HdEHAuTkAESPTU43DiptjkfHhtBMfsFrCkd sxWzCz+prDOMHYfUEkhRVV++1zyGEX6ov1Ap2IU2p3E+ASihL/amxTEQAsbwjUTI R52zoL6nMPzpbKeZi2M0eEBVF8sDueA9Hjo6woLjgJqV0/yc5vC2HAxUOhx0cWTY GcRBgL/yOyQLKiY5TKBH951OjQ4vhF2HmcoO7DkcNLYJOge16ssx4ogBHul20VgF XJJjMIIDAzCCAeugAwIBAgIBAjANBgkqhkiG9w0BAQUFADAbMRkwFwYDVQQDExBl c3RFeGFtcGxlQ0EgTndOMB4XDTEzMDUwOTAzNTMzMloXDTE0MDUwOTAzNTMzMlow GzEZMBcGA1UEAxMQZXN0RXhhbXBsZUNBIE93TjCCASIwDQYJKoZIhvcNAQEBBQAD ggEPADCCAQoCggEBAMA6qYh6KWiArm6Uam6RDey6kyKlhCxSAPagw4XhyCrsjh1v 2QD+0ZeEuWVOoGi1v5LLHgVMXZqMdyjcr7co3oSKH07tvHmVoYMuvywhBlkdzyvn 4DwQNJdCXyUf/KHl2Wu9KC1UHN4SOJAnqoxTLPm4mB9L6f0ZboX7cmeZM0Mh9RBr EZMNf6lCpE2fDwhfFRZWH6plKKrGkU8mW4yCOCfmOv4xBvqe0K3lvc3M+LD3vN3P 7ocDCzlkJGbSrELYKOQqX2DI7gJpOENo6EKtr3MZXPljSh3/sG6w29dTkWa4pfSE pSPeKLpnEc97gRtWIO8/N4XQ32rJnX26fIDkjRUCAwEAAaNSMFAwDgYDVR0PAQH/ BAQDAgSwMB0GA1UdDgQWBBQITTKxMqATXrfc4ffpCIbt6Gsz0jAfBgNVHSMEGDAW gBSxxGnmW6MEp9iXo4s7v7lqsjJCPDANBgkqhkiG9w0BAQUFAAOCAQEALhDaE6Mp BINBsJozdbXlijrWxL1CSv8f4GwpUFk3CgZjibt/qW9UoaNR4E58yRopuEhjwFZK 2w8YtRqx8IZoFhcoLkpBDfgLLwhoztzbYvOVKQMidjBlkBEVNR5MWdrs7F/AxWuy iZ2+8AnR8GwqEIbCD0A7xIghmWEMh/BVI9C7GLqd6PxKrTAjuDfEpfdWhU/uYKmK cL3XDbSwr30j2EQyaTV/3W0Tn2UfuxdwDQ4ZJs9G+Mw50s7AG6CpISyOIFmX6/bU DpJXGLiLwfJ9C/aum9nylYuGCJ68BuTrCs9567KGfXEXI0mdFFCL7TaVR43kjsg3 c43kZ7369MeEZzCCAvswggHjoAMCAQICCQDprp3DmjOyETANBgkqhkiG9w0BAQUF ADAbMRkwFwYDVQQDExBlc3RFeGFtcGxlQ0EgTndOMB4XDTEzMDUwOTAzNTMzMloX DTE0MDUwOTAzNTMzMlowGzEZMBcGA1UEAxMQZXN0RXhhbXBsZUNBIE53TjCCASIw DQYJKoZIhvcNAQEBBQADggEPADCCAQoCggEBAJ5962d6zCR8H+zA/SuJrm8RwL7X Z67EH+Tn4LTIUSC+GnjzYQHYD8o/ApaMToA91E1fnUNVYjs1cTze2nIpKDp5CHUa Y6TqZMjKPipLxzEFxp0E27DAL9alrfUtdgzKaNBjgNXuBnt7neWDzk0f6uj74zed SBMGCpLBuwoJcGcAfuSW8IWK9g/9Lm7Rpba4kVYsT1q77fsM/yE6ea3I4f/EUtyx PLUMt5EzYSRd2P3rEdrEoDojzYCLaAgE8rG2iDRD6+DHpqjC+LQ6Uf2hvcvvEHu7 NS8jBbw5XradppgcpAAv+5zmrf6cFJQdLDeduA9VwIM/GSr1q5IfmWjq94cCAwEA AaNCMEAwDwYDVR0TAQH/BAUwAwEB/zAdBgNVHQ4EFgQUscRp5lujBKfYl6OLO7+5 arIyQjwwDgYDVR0PAQH/BAQDAgEGMA0GCSqGSIb3DQEBBQUAA4IBAQBCz/CWdYvn GM/SdCdEiom5A1VxaW8nKgCWg/EyWtAIiaHQuViB+jTUAE9lona2MbJoFHW8U5e8 9dCP0rJpA9UYXXhWvFQzd5ZWpms4wUYt1j3gqqd36KorJIAuPigVng13yKytxM7c VmxQnh0aux3aEnEyRGAhGalHp0RaKdgPRzUaGtipJTNBkSV5S4kD4yDCPHMNbBu+ OcluerwEpbz6GvE7CpXl2jrTBZSqBsFelq0iz4kk9++9CnwZwrVgdzklhRfJ1Z4j NkLruwbQ+o4NvBZsXiKxNfn3K2o3SK8AuaEyDWkq18+5rjcfprRO8x4YTW+6mXPq jM0MAGNDEW+1oQAxAA==

A.2. 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 for which the EST server provides services.

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

GET /.well-known/est/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: 192.0.2.1:8085 Accept: */*

In response, the server provides suggested attributes that are appropriate for the authenticated client. In this example, the EST server also includes two example attributes that the client would ignore unless the attribute type is known to the client:

HTTP/1.1 200 OK Status: 200 OK Content-Type: application/csrattrs Content-Transfer-Encoding: base64 Content-Length: 171

MHwGBysGAQEBARYwIgYDiDcBMRsTGVBhcnNlIFNFVCBhcyAyLjk5OS4xIGRhdGEG CSqGSIb3DQEJBzAsBgOINwIxJQYDiDcDBgOINwQTGVBhcnNlIFNFVCBhcyAyLjk5 OS4yIGRhdGEGCSskAwMCCAEBCwYJYIZIAWUDBAIC

A.3. Enroll/Re-enroll

The following is an example of a valid /simpleenroll exchange. The data messages for /simplereenroll are similar.

During this exchange, the EST client uses an out-of-band distributed username/password to authenticate itself to the EST server. This is the normal HTTP WWW-Authenticate behavior and is included here for informative purposes. When an existing TLS client certificate is used, the server might skip requesting the HTTP WWW-Authenticate header, such as during a /simplereenroll operation.

During the initial TLS handshake, the client can ignore the optional server-generated "certificate request" and can instead proceed with the HTTP POST request. In response to the initial HTTP POST attempt,

the server requests WWW-Authenticate from the client (this might occur even if the client used a client certificate, as detailed in the normative text above):

HTTP/1.1 401 Unauthorized Content-Length: 0 WWW-Authenticate: Digest qop="auth", realm="estrealm", nonce="1368141352"

In the subsequent HTTP POST, the username/password is included, along with the complete application/pkcs10 content:

POST /.well-known/est/simpleenroll HTTP/1.1 Authorization: Digest username="estuser", realm="estrealm", nonc e="1368141352", uri="/.well-known/est/simpleenroll", cnonce="M TYwMzg3", nc=00000001, qop="auth", response="144cc27f96046f1d70e b16db20f75f22" Host: 192.0.2.1:8085 Accept: */* Content-Type: application/pkcs10 Content-Transfer-Encoding: base64 Content-Length: 882

MIIChTCCAW0CAQAwHzEdMBsGA1UEAxMUZGVtb3N0ZXA0IDEzNjgxNDEzNTIwggEi MA0GCSqGSIb3DQEBAQUAA4IBDwAwggEKAoIBAQClNp+kdz+Nj8XpEp9kaumWxDZ3 eFYJpQKz9ddD5e5OzUeCm103ZIXQIxc0eVtMCatnRr3dnZRCAxGjwbqoB3eKt29/ XSQffVv+odbyw0WdkQOIbntCQry8YdcBZ+8LjI/N7M2krmjmoSLmLwU2V4aNKf0Y MLR5Krmah3Ik31jmYCSvwTnv6mx6pr2pTJ82JavhTEIIt/fAYq1RYhkM1CXoBL+y hEoDanN7TzC94skfS3VV+f53J9SkUxTYcy1Rw0k3VXfxWwy+cSKEPREl7I6k0YeK tDEVAgBIEYM/L1S69RXTLujirwnqSRjOquzkAkD31BE961KZCxeYGrhxaR4PAgMB AAGgITAfBgkqhkiG9w0BCQcxEhMQK3JyQ2lyLzcrRVl1NTBUNDANBgkqhkiG9w0B AQUFAAOCAQEARBv0AJeXaHpl1MFIdzWqoi1dOCf6U+qaYWcBzpLADvJrPK1qx5pq wXM830A1O+7RvrFv+nyd6VF2rl/MrNp+IsKuA9LYWIBjVe/LXoBO8dB/KxrYl16c VUS+Yydi1m/a+DaftYSRGolMLtWeiqbc2SDBr2kHXW1TR130hIcpwmr29kC2Kzur 5thsuj276FGL1vPu0dRfGQfx4WWa9uAHBgz6tW37CepZsrUKe/0pfVhr2oHxApYh cHGBQDQHVTFVjHccdUjAXicrtbsVhU5o1lPv7f4lEApv3SBQmJcaq5O832BzHw7n PyMFcM15E9gtUVee5C62bVwuk/tbnGsbwQ==

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

HTTP/1.1 200 OK Status: 200 OK Content-Type: application/pkcs7-mime; smime-type=certs-only Content-Transfer-Encoding: base64 Content-Length: 1122

MIIDOAYJKoZIhvcNAQcCoIIDKTCCAyUCAQExADALBgkqhkiG9w0BBwGgggMLMIID BzCCAe+gAwIBAgIBFTANBgkqhkiG9w0BAQUFADAbMRkwFwYDVQQDExBlc3RFeGFt cGxlQ0EgTndOMB4XDTEzMDUwOTIzMTU1M1oXDTE0MDUwOTIzMTU1M1owHzEdMBsG A1UEAxMUZGVtb3N0ZXA0IDEzNjgxNDEzNTIwggEiMA0GCSqGSIb3DQEBAQUAA4IB DwAwggEKAoIBAQClNp+kdz+Nj8XpEp9kaumWxDZ3eFYJpQKz9ddD5e5OzUeCm103 ZIXQIxc0eVtMCatnRr3dnZRCAxGjwbqoB3eKt29/XSQffVv+odbyw0WdkQOIbntC Qry8YdcBZ+8LjI/N7M2krmjmoSLmLwU2V4aNKf0YMLR5Krmah3Ik31jmYCSvwTnv 6mx6pr2pTJ82JavhTEIIt/fAYq1RYhkM1CXoBL+yhEoDanN7TzC94skfS3VV+f53 J9SkUxTYcy1Rw0k3VXfxWwy+cSKEPREl7I6k0YeKtDEVAgBIEYM/L1S69RXTLuji rwnqSRjOquzkAkD31BE961KZCxeYGrhxaR4PAgMBAAGjUjBQMA4GA1UdDwEB/wQE AwIEsDAdBgNVHQ4EFgQU/qDdB6ii6icQ8wGMXvy1jfE4xtUwHwYDVR0jBBgwFoAU scRp5lujBKfYl6OLO7+5arIyQjwwDQYJKoZIhvcNAQEFBQADggEBACmxg1hvL6+7 a+lFTARoxainBx5gxdZ9omSb0L+qL+4PDvg/+KHzKsDnMCrcU6M4YP5n0EDKmGa6 4lY8fbET4tt7juJg6ixb95/760Th0vuctwkGr6+D6ETTfqyHnrbhX3lAhnB+0Ja7 o1gv4CWxh1I8aRaTXdpOHORvN0SMXdcrlCys2vrtOl+LjR2a3kajJO6eQ5leOdzF QlZfOPhaLWen0e2BLNJI0vsC2Fa+2LMCnfC38XfGALa5A8e7fNHXWZBjXZLBCza3 rEs9Mlh2CjA/ocSC/WxmMvd+Eqnt/FpggRy+F8IZSRvBaRUCtGE1lgDmu6AFUxce R4POrT2xz8ChADEA

A.4. 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. An example HTTP POSTed message is:

POST /.well-known/est/serverkeygen HTTP/1.1 Host: 192.0.2.1:8085 Accept: */* Expect: 100-continue Content-Type: application/pkcs10 Content-Transfer-Encoding: base64 Content-Length: 963

MIICwTCCAakCAQAwWzE+MDwGA1UEAxM1c2VydmVyS2V5R2VuIHJlcSBieSBjbGll bnQgaW4gZGVtbyBzdGVwIDEyIDEzNjgxNDE5NTUxGTAXBgNVBAUTEFBJRDpXaWRn ZXQgU046MTAwggEiMA0GCSqGSIb3DQEBAQUAA4IBDwAwggEKAoIBAQCvE1/6m4A/ 3/L32Suyzbf28LM9y8CQfp0aepa7o20BSfluvm8HXR44mlV+wpieM8H5n3Ub3RIo RUun/FllIzK9uV7UrkqJ3Yzmq2NOoTd4C+OPsV/RPTu873dhFrssDk3P4NIphlSS sSIkt5rhz7wYbCqCFR5Aphe/30Jx7D+xBI5Rs8e6vRS8IpuImh71BHiLfhq9AFhz 4ZJsOUSVpUmqUogFsM7SOQ6XI4dl+djhpjT+YTJ6hQ2PXrqdch3KsTQ8c6aKs+e2 5QJxh7O8JHVlPHo4YIxXtAYSutcbbTN5TXWFCWSrWDJ+zuMmk2yU+dio1oW7YR7V ftAvazJ3laQbAgMBAAGgITAfBgkqhkiG9w0BCQcxEhMQZEZzQVhtSm5qb2tCdER2 cjANBgkqhkiG9w0BAQUFAAOCAQEAR+I0EQB+hSjrLCAjnVH6bZdHUNGszIdwx1iu L4n+0XK3SfEzeOMkC4T74yFGKj3redS1Ht9atYUPb0D1Qi9Jf9Co8eLblo1l19A6 GaS798ofxIF0Pl0Dr6/GqjheqJEIbcDTAJq+kvDihyQ4GQnhosygIZHvKppQlebA gvp2RJSnMroPCe6RgTU9E2fmI9rin/9PyXeWFF1namp+lYbTGwjv1aE1ikhjCLlH veHhCdgOExPw+fqhKhHjp+0ZKBlo2bC3pqRWvDTiZuwt9UpFFfGtuxvpTp44oS/j M/965hWIw/5dshY/wQjIfYs07bbq2ERbpJiw9bAQY34gyoVmEQ==

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

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

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 Content-Transfer-Encoding: base64

MIIEvgIBADANBgkqhkiG9w0BAQEFAASCBKgwggSkAgEAAoIBAQDPwKtwJ7TjMgA+ Poj64V909ryql0foP1hU4Yq5y8/bOP5ZTe6ArgVhUye099Ac+dfdwpyP/DESiujU F/dS62Vck3UWNbnw+4O38FUp0enLbbjSTud48KpEW6+FzkeuAanPGZMA1wKyrYy9 rD5tQOOJU/CBVhUrITyYLZNYUe4agbpcR0wMtrRr2E58Mu8wQ80ryk6nkL7COk5Z IQdNRxldk7DFvpA85Yn1stumoGRtVLW51iXeTS1LtXwhuUb/j6Lds3vvAiJ2SiZ0 Y3rxPlnJVyFmR8Mf2TBOjzuFqva/VLD2ayQjgaGEjq2ZWHXelQAOZ6N3lrChojEK FGq93yOhAgMBAAECggEBALQ5az/nYjd5x9Y3f7NMUffwl+jRRfMHCMTRx/u4AEAo KBYm0hFVZZtxfM+z7xlD8G0Th6gs2hFA6gwcIlUPmiX+UaOLxht0xWaLGgYmcNAm BiCDjLBQ7xRQCWtlcK9WCA5+HBWtcEy6244rXxh+IyWd6NT6bXC165AEcX87y/e3 JFJ7XFNeDP656s2DmxSCci+iDte6SaEm7sJvYGu16qevJeMThcQcC9/rJjXkvpGL IKK2px5idad4Pb6+QHpqj3d4oM8djO6wYUvrH8XQLqAaF8Hd5lFWVU57nSYY+H79 GaNDTfRTUL6AXr7kmMsKVFOJ0JjZExUCVMZtGiqhB6UCgYEA639OtdWLZCzyZFMe p7VlRddoz0VAtrU2dxnEb4cWD8Gerg8uNvp8OG84gH+6MbPwz4ZYWKCgDFqyrAlw SF02n9Sovh93eoJ5latSbfeYUkLtB8L/HVk5/CBGEsV9MUkdMF0+B43YlhyEDyKW fX2+0UeHLFgRrfpSzP2cXduEieMCgYEA4db/SIrwN2+g1Gjo3oE09kd89VGjVRer srbcqc7DcPXP6Lw42sx96h4jVWWqHVo3DfwFBdUb1LH2cnVXQjgDUHdNdpl01cf/ BFYCFINi2qKMqiJYswkhYxZ1BLz/zuQTDbPFL2PgLniKFG2aFLrTS3S/tgeB5QwI RPigH3kfI6sCgYAPqsCJyFMlrvfRRNZdQewi4VnPsEPF4/hjpAs1gD8vfSoZWlkw vylUd9HCerzgYaA7rixieQ0sxTvtxhL6PXlM2NEBFQbV16hPFL6/IiG4F0u9oHNo eG8rHtqKlSjnBn4yoYFm70Dhe7QtbZelcaAoPCH6CUHj2St5B8ZHWDtREQKBgHNp wER+XIy4C2UByCANv9csaXulIOdXlXNbaCGPfOm5dWrm5ddLMf33MO9vaSRe+ku3 Q4nbgsGLwPp1ZQZ+QZNZpMi7W6306yp4GdAJ5Pb+oww/ST0VqW5OB7dILyK4A9S4 zkiNrf+Rsl8GM/vsDhc9rsuDwqofIAq/VHVBHNzJAoGBAOHQof5L6iGHOHcxLazx 4MGvRTpmzU/PX6Q3QxqpetEGFEDZAaL58L67SSS3fFBnKrVAidF6llC1bAH1aoRa fYHUDi45xBoroy0hBwrnTKRxppua4UK75FUH5PPJfR6cCvw5stRkzIevTZHhozkX pM7PYH/x4BiBmgQ3bhOqTp4H --estServerExampleBoundary Content-Type: application/pkcs7-mime; smime-type=certs-only Content-Transfer-Encoding: base64

MIIDRQYJKoZIhvcNAQcCoIIDNjCCAzICAQExADALBgkqhkiG9w0BBwGgggMYMIID FDCCAfygAwIBAgIBFjANBgkqhkiG9w0BAQUFADAbMRkwFwYDVQQDExBlc3RFeGFt cGxlQ0EgTndOMB4XDTEzMDUwOTIzMjU1NloXDTE0MDUwOTIzMjU1NlowLDEqMCgG A1UEAxMhc2VydmVyc2lkZSBrZXkgZ2VuZXJhdGVkIHJlc3BvbnNlMIIBIjANBgkq hkiG9w0BAQEFAAOCAQ8AMIIBCgKCAQEAz8CrcCe04zIAPj6I+uFfdPa8qpdH6D9Y VOGKucvP2zj+WU3ugK4FYVMntPfQHPnX3cKcj/wxEoro1Bf3UutlXJN1FjW58PuD t/BVKdHpy2240k7nePCqRFuvhc5HrgGpzxmTANcCsq2Mvaw+bUDjiVPwgVYVKyE8 mC2TWFHuGoG6XEdMDLa0a9hOfDLvMEPNK8pOp5C+wjpOWSEHTUcZXZOwxb6QPOWJ 9bLbpqBkbVS1udYl3k0tS7V8IblG/4+i3bN77wIidkomdGN68T5ZyVchZkfDH9kw To87har2v1Sw9mskI4GhhI6tmVh13pUADmejd5awoaIxChRqvd8joQIDAQABo1Iw UDAOBgNVHQ8BAf8EBAMCBLAwHQYDVR0OBBYEFKeZixu9F+appDX2SS5HaxmV6Jr4 MB8GA1UdIwQYMBaAFLHEaeZbowSn2Jejizu/uWqyMkI8MA0GCSqGSIb3DQEBBQUA A4IBAQBHhLmRAKrnTapqqBObDM9IQDQPuwW+fW1gYwZKlSm/IWIwHEZL1igXhpjj rf4xqpIkiJMmkaOeoXA8PFniX0/lZM9FQSM/j89CUf5dMoAqWj8s17xuXu9L/hVe XjjXHsL40WuDG6tMPN9vcT8tE3ruor608MKSHFX/NEM6+AaNVSUPTmB33BgYB1Wa E7pn3JMN6pjIxsHnF4pKi8qvoTSVVjaCEwUe8Q/fw1yvjoHoYJtyMn4v5Kb3Rt+m s8Yie1tcfVQrjQutqr34/IJsKdPziZwi92KZa+1958A6M9O/p5OI0up9ZXKg2DEC 1O9qT0GyYJ6sxAyKiGTOxk6jMddDoQAxAA== --estServerExampleBoundary-- This is the epilogue. It is also to be ignored.

Appendix B. Contributors and Acknowledgements

The editors would like to thank Stephen Kent, Vinod Arjun, Jan Vilhuber, Sean Turner, Russ Housley, and others for their feedback and prototypes of early versions of this document. Our thanks also go the authors of RFC6403, around whose document we structured part of this specification.

Authors' Addresses

Max Pritikin (editor) Cisco Systems, Inc. 510 McCarthy Drive Milpitas, CA 95035 USA

EMail: [email protected]

Peter E. Yee (editor) AKAYLA, Inc. 7150 Moorland Drive Clarksville, MD 21029 USA

EMail: [email protected]

Dan Harkins (editor) Aruba Networks 1322 Crossman Avenue Sunnyvale, CA 94089-1113 USA

EMail: [email protected]

@@ Line 1: / Line 1: @@
+Internet Engineering Task Force (IETF)                  M. Pritikin, Ed.
+Request for Comments: 7030                          Cisco Systems, Inc.
+Category: Standards Track                                    P. Yee, Ed.
+ISSN: 2070-1721                                            AKAYLA, Inc.
+                                                      D. Harkins, Ed.
+                                                      Aruba Networks
+                                                        October 2013
+                Enrollment over Secure Transport
+'''Abstract'''
-Internet Engineering Task Force (IETF)                  M. Pritikin, Ed.Request for Comments: 7030                          Cisco Systems, Inc.Category: Standards Track                                    P. Yee, Ed.ISSN: 2070-1721                                            AKAYLA, Inc.                                                      D. Harkins, Ed.                                                      Aruba Networks                                                        October 2013
-                Enrollment over Secure Transport
-Abstract
 This document profiles certificate enrollment for clients using
@@ Line 19: / Line 20: @@
 key pairs as well as key pairs generated by the CA.
-Status of This Memo
+'''Status of This Memo'''
 This is an Internet Standards Track document.
@@ Line 33: / Line 34: @@
 http://www.rfc-editor.org/info/rfc7030.
+'''Copyright Notice'''
-Copyright Notice
 Copyright (c) 2013 IETF Trust and the persons identified as the
@@ Line 64: / Line 48: @@
 the Trust Legal Provisions and are provided without warranty as
 described in the Simplified BSD License.
+.4.1.1. Requests for Symmetric Key
+.4.1.2. Requests for Asymmetric Encryption
 == Introduction ==
 This document profiles certificate enrollment for clients using
-Certificate Management over CMS (CMC) [RFC5272] messages over a
+Certificate Management over CMS (CMC) [[RFC5272]] messages over a
 secure transport.  Enrollment over Secure Transport (EST) describes
-the use of Transport Layer Security (TLS) 1.1 [RFC4346], 1.2
+the use of Transport Layer Security (TLS) 1.1 [[RFC4346]], 1.2
-[RFC5246], or any future version) and Hypertext Transfer Protocol
+[[RFC5246]], or any future version) and Hypertext Transfer Protocol
-(HTTP) [RFC2616] to provide an authenticated and authorized channel
+(HTTP) [[RFC2616]] to provide an authenticated and authorized channel
 for Simple Public Key Infrastructure (PKI) Requests and Responses
-[RFC5272].
+[[RFC5272]].
 Architecturally, the EST service is located between a Certification
@@ Line 82: / Line 70: @@
 not described in this document.
+EST adopts the Certificate Management Protocol (CMP) [[RFC4210]] model
-EST adopts the Certificate Management Protocol (CMP) [RFC4210] model
 for CA certificate rollover, but it does not use the CMP message
 syntax or protocol.  EST servers are extensible in that new functions
 may be defined to provide additional capabilities not specified in
-CMC [RFC5272], and this document defines two such extensions: one for
+CMC [[RFC5272]], and this document defines two such extensions: one for
 requesting Certificate Signing Request attributes and another for
 requesting server-generated keys.
 EST specifies how to transfer messages securely via HTTP over TLS
-(HTTPS) [RFC2818], where the HTTP headers and media types are used in
+(HTTPS) [[RFC2818]], where the HTTP headers and media types are used in
 conjunction with TLS.  HTTPS operates over TCP; this document does
 not specify EST over HTTP/Datagram Transport Layer Security/User
@@ Line 131: / Line 115: @@
 "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and
 "OPTIONAL" in this document are to be interpreted as described in
-[RFC2119].
+[[RFC2119]].
 It is assumed that the reader is familiar with the terms and concepts
-described in Public Key Cryptography Standard (PKCS) #10 [RFC2986],
+described in Public Key Cryptography Standard (PKCS) #10 [[RFC2986]],
-HTTPS [RFC2818], CMP [RFC4210], CMC [RFC5272][RFC5273][RFC5274], and
+HTTPS [[RFC2818]], CMP [[RFC4210]], CMC [[RFC5272]][[RFC5273]][[RFC5274]], and
-TLS [RFC4346].
+TLS [[RFC4346]].
 In addition to the terms defined in the terminology section of CMC
-[RFC5272], the following terms are defined for clarity:
+[[RFC5272]], the following terms are defined for clarity:
 EST CA:  For certificate issuing services, the EST CA is reached
@@ Line 185: / Line 163: @@
 This section provides an informative overview of the operational
 scenarios to better introduce the reader to the protocol discussion.
 Both the EST clients and server are configured with information that
@@ Line 197: / Line 169: @@
 the client and server, but it can include shared secrets, network
 service names and locations (e.g., a Uniform Resource Identifier
-(URI) [RFC3986]), trust anchor information (e.g., a CA certificate or
+(URI) [[RFC3986]]), trust anchor information (e.g., a CA certificate or
 a hash of a TA's certificate), and enrollment keys and certificates.
 Depending on an enterprise's acquisition and network management
@@ Line 212: / Line 184: @@
 Sections 2.1-2.3 very closely mirror the text of the Scenarios
-Appendix of [RFC6403] with such modifications as are appropriate for
+Appendix of [[RFC6403]] with such modifications as are appropriate for
 this profile.  Sections 2.1-2.6, below, enumerate the set of EST
 functions (see Figure 5) and provide an informative overview of EST's
@@ Line 240: / Line 212: @@
 certificate(s) from the EST server.  The EST client is assumed to
 perform this operation before performing other operations.
 Throughout this document we assume the EST CA has a certificate that
@@ Line 293: / Line 261: @@
    installed certificate or a certificate issued by some other
    party);
 o  Certificate-less TLS (e.g., with a shared credential distributed
@@ Line 345: / Line 309: @@
 the EST CA that can be used for TLS client authentication, then it
 can be used.
 The certificate request message includes the same Subject and
@@ Line 362: / Line 321: @@
 === Full PKI Request Messages ===
-Full PKI Request [RFC5272] messages can be transported via EST using
+Full PKI Request [[RFC5272]] messages can be transported via EST using
 the Full CMC Request function.  This affords access to functions not
 provided by the Simple Enrollment functions.  Full PKI Request
-messages are defined in Sections 3.2 and 4.2 of [RFC5272].  See
+messages are defined in Sections 3.2 and 4.2 of [[RFC5272]].  See
 Section 4.3 for a discussion of how EST provides a transport for
 these messages.
@@ Line 383: / Line 342: @@
 is expected to use when generating the CSR.
+== Protocol Design and Layering ==
+Figure 2 provides an expansion of Figure 1, describing how the layers
+are used.  Each aspect is described in more detail in the sections
+that follow.
+EST Layering:
-== Protocol Design and Layering ==
-Figure 2 provides an expansion of Figure 1, describing how the layers
-are used.  Each aspect is described in more detail in the sections
-that follow.
-EST Layering:
 Protocols and uses:
@@ Line 440: / Line 378: @@
 |  - Provides communications integrity              |
 |    and confidentiality                            |
-|  - Supplies channel-binding [RFC5929] information |
+|  - Supplies channel-binding [[RFC5929]] information |
 |    to link proof-of-identity with message-based  |
 |    proof-of-possession (OPTIONAL)                |
@@ Line 452: / Line 390: @@
 messages: TLS and HTTP.
+The TLS layer provides integrity and confidentiality during
+transport.  The proof-of-identity is supplied by TLS handshake
-The TLS layer provides integrity and confidentiality during
-transport.  The proof-of-identity is supplied by TLS handshake
 authentication and optionally also by the HTTP layer headers.  The
 message type and control/error messages are included in the HTTP
 headers.
-CMC ([RFC5272], Section 3.1) notes that "the Simple PKI Request MUST
+CMC ([[RFC5272]], Section 3.1) notes that "the Simple PKI Request MUST
 NOT be used if a proof-of-identity needs to be included".  Since the
 TLS and HTTP layers can provide proof-of-identity for EST clients and
@@ Line 480: / Line 413: @@
 proof-of-possession is described in Section 3.5.
-This document also defines transport for CMC [RFC5272] that complies
+This document also defines transport for CMC [[RFC5272]] that complies
-with the CMC Transport Protocols [RFC5273].  CMC's POP and
+with the CMC Transport Protocols [[RFC5273]].  CMC's POP and
 proof-of-identity mechanisms are defined in CMC, but the mechanisms
 here can also be used in conjunction with those mechanisms in "Full
@@ Line 490: / Line 423: @@
 have one or more certificates of each type listed in Figure 3 and use
 one or more trust anchor databases of each type listed in Figure 4.
 Certificates and their corresponding uses:
@@ Line 544: / Line 458: @@
 |              |                    | Section 4.2.3                |
 +--------------+--------------------+-------------------------------+
                                Figure 3
+Trust anchor databases and their corresponding uses:
++--------------+----------------------------------------------------+
+| TA database  | Use and section references                        |
-Trust anchor databases and their corresponding uses:
-+--------------+----------------------------------------------------+
-| TA database  | Use and section references                        |
 +==============+====================================================+
 | EST server  | EST servers use this TA database to authenticate  |
@@ Line 596: / Line 494: @@
 |              | Security Considerations                            |
 +--------------+----------------------------------------------------+
                                Figure 4
@@ Line 609: / Line 506: @@
 and parsing the returned list of attributes is OPTIONAL (see
 Section 4.5).
 Details of the EST client application configuration are out of scope
@@ Line 651: / Line 542: @@
 used to convey EST messages as specified in Figure 6.
-HTTP 1.1 [RFC2616] and above support persistent connections.  As
+HTTP 1.1 [[RFC2616]] and above support persistent connections.  As
 described in Section 8.1 of [[RFC2616|RFC 2616]], persistent connections may be
 used to reduce network and processing loads associated with multiple
@@ Line 657: / Line 548: @@
 connections.
+==== HTTP Headers for Control ====
+The HTTP Status value is used to communicate success or failure of an
+EST function.  HTTP authentication is used by a client when requested
+by the server.
+The media types specified in the HTTP Content-Type header indicate
+which EST message is being transferred.  Media types used by EST are
+specified in Section 3.2.4.
-==== HTTP Headers for Control ====
-The HTTP Status value is used to communicate success or failure of an
-EST function.  HTTP authentication is used by a client when requested
-by the server.
-The media types specified in the HTTP Content-Type header indicate
-which EST message is being transferred.  Media types used by EST are
-specified in Section 3.2.4.
 HTTP redirections (3xx status codes) to the same web origin (see
-[RFC6454]) SHOULD be handled by the client without user input so long
+[[RFC6454]]) SHOULD be handled by the client without user input so long
 as all applicable security checks (Sections 3.3 and 3.6) have been
 enforced on the initial connection.  The client initiates a new TLS
@@ Line 686: / Line 565: @@
 redirected to other web origin servers.  Redirections to other web
 origins require the EST client to obtain user input for non-GET or
-HEAD requests as specified in [RFC2616].  Additionally, if the client
+HEAD requests as specified in [[RFC2616]].  Additionally, if the client
 has already generated a CSR that includes linking identity and POP
 information (Section 3.5), then the CSR will need to be recreated to
@@ Line 694: / Line 573: @@
 advised to take this into consideration.
+==== HTTP URIs for Control ====
+The EST server MUST support the use of the path-prefix of "/.well-
+known/" as defined in [[RFC5785]] and the registered name of "est".
+Thus, a valid EST server URI path begins with
+"https://www.example.com/.well-known/est".  Each EST operation is
+indicated by a path-suffix that indicates the intended operation:
+Operations and their corresponding URIs:
++------------------------+-----------------+-------------------+
+| Operation              |Operation path  | Details          |
++========================+=================+===================+
+| Distribution of CA    | /cacerts        | Section 4.1      |
+| Certificates (MUST)    |                |                  |
++------------------------+-----------------+-------------------+
+| Enrollment of          | /simpleenroll  | Section 4.2      |
+| Clients (MUST)        |                |                  |
++------------------------+-----------------+-------------------+
+| Re-enrollment of      | /simplereenroll | Section 4.2.2    |
+| Clients (MUST)        |                |                  |
++------------------------+-----------------+-------------------+
+| Full CMC (OPTIONAL)    | /fullcmc        | Section 4.3      |
++------------------------+-----------------+-------------------+
+| Server-Side Key        | /serverkeygen  | Section 4.4      |
+| Generation (OPTIONAL)  |                |                  |
++------------------------+-----------------+-------------------+
+| CSR Attributes        | /csrattrs      | Section 4.5      |
+| (OPTIONAL)            |                |                  |
++------------------------+-----------------+-------------------+
+                              Figure 5
+The operation path (Figure 5) is appended to the path-prefix to form
+the URI used with HTTP GET or POST to perform the desired EST
+operation.  An example valid URI absolute path for the "/cacerts"
+operation is "/.well-known/est/cacerts".  To retrieve the CA's
+certificates, the EST client would use the following HTTP
+request-line:
+GET /.well-known/est/cacerts HTTP/1.1
+Likewise, to request a new certificate in this example scheme, the
+EST client would use the following request-line:
+POST /.well-known/est/simpleenroll HTTP/1.1
+The use of distinct operation paths simplifies implementation for
+servers that do not perform client authentication when distributing
+/cacerts responses.
+An EST server MAY provide service for multiple CAs as indicated by an
+OPTIONAL additional path segment between the registered application
+name and the operation path.  To avoid conflict, the CA label MUST
+NOT be the same as any defined operation path segment.  The EST
+server MUST provide services regardless of whether the additional
+path segment is present.  The following are three example valid URIs:
+.  https://www.example.com/.well-known/est/cacerts
+.  https://www.example.com/.well-known/est/arbitraryLabel1/cacerts
+.  https://www.example.com/.well-known/est/arbitraryLabel2/cacerts
+In this specification, the distinction between enroll and renew/rekey
+is explicitly indicated by the HTTP URI.  When requesting /fullcmc
+operations, CMC [[RFC5272]] uses the same messages for certificate
+renewal and certificate rekey.
+An EST server can provide additional services using other URIs.
+==== HTTP-Based Client Authentication ====
+The EST server MAY request HTTP-based client authentication.  This
+request can be in addition to successful TLS client authentication
+(Section 3.3.2) if EST server policy requires additional
+authentication.  (For example, the EST server may require that an EST
+client "knows" a password in addition to "having" an existing client
+certificate.)  Or, HTTP-based client authentication can be an EST
+server policy-specified fallback in situations where the EST client
+did not successfully complete the TLS client authentication.  (This
+might arise if the EST client is enrolling for the first time or if
+the certificates available to an EST client cannot be used for TLS
+client authentication.)
+HTTP Basic and Digest authentication MUST only be performed over TLS
+.1 [[RFC4346]] or later versions.  NULL and anon cipher suites MUST
+NOT be used because they do not provide confidentiality or support
+mutual certificate-based or certificate-less authentication,
+respectively.  As specified in "Certificate Management over CMS
+(CMC): Transport Protocols" [[RFC5273]], the server "MUST NOT assume
+client support for any type of HTTP authentication such as cookies,
+Basic authentication, or Digest authentication".  Clients SHOULD
+support the Basic and Digest authentication mechanism.
+Servers that wish to use Basic and Digest authentication reject the
+HTTP request using the HTTP-defined WWW-Authenticate response-header
+([[RFC2616]], Section 14.47).  The client is expected to retry the
+request, including the appropriate Authorization Request header
+([[RFC2617]], Section 3.2.2), if the client is capable of using the
+Basic or Digest authentication.  If the client is not capable of
+retrying the request or it is not capable of Basic or Digest
+authentication, then the client MUST terminate the connection.
+A client MAY set the username to the empty string ("") if it is
+presenting a password that is not associated with a username.
+Support for HTTP-based client authentication has security
+ramifications as discussed in Section 6.  The client MUST NOT respond
+to the server's HTTP authentication request unless the client has
+authorized the EST server (as per Section 3.6).
+==== Message Types ====
+This document uses existing media types for the messages as specified
+by FTP and HTTP [[RFC2585]], application/pkcs10 [[RFC5967]], and CMC
+[[RFC5272]].
+For consistency with [[RFC5273]], each distinct EST message type uses
+an HTTP Content-Type header with a specific media type.
+The EST messages and their corresponding media types for each
+operation are:
++--------------------+--------------------------+-------------------+
+| Message type      | Request media type      | Request section(s)|
+|                    | Response media type(s)  | Response section  |
+| (per operation)    | Source(s) of types      |                  |
++====================+==========================+===================+
+| Distribution of CA | N/A                      | Section 4.1      |
+| Certificates      | application/pkcs7-mime  | Section 4.1.1    |
+|                    | [[RFC5751]]                |                  |
+| /cacerts          |                          |                  |
++--------------------+--------------------------+-------------------+
+| Client Certificate | application/pkcs10      | Sections 4.2/4.2.1|
+| Request Functions  | application/pkcs7-mime  | Section 4.2.2    |
+|                    | [[RFC5967]] [[RFC5751]]      |                  |
+| /simpleenroll      |                          |                  |
+| /simplereenroll    |                          |                  |
++--------------------+--------------------------+-------------------+
+| Full CMC          | application/pkcs7-mime  | Section 4.3.1    |
+|                    | application/pkcs7-mime  | Section 4.3.2    |
+| /fullcmc          | [[RFC5751]]                |                  |
++--------------------+--------------------------+-------------------+
+| Server-Side Key    | application/pkcs10      | Section 4.4.1    |
+| Generation        | multipart/mixed          | Section 4.4.2    |
+|                    | (application/pkcs7-mime &|                  |
+|                    | application/pkcs8)      |                  |
+|                    | [[RFC5967]] [[RFC5751]]      |                  |
+| /serverkeygen      | [[RFC5958]]                |                  |
++--------------------+--------------------------+-------------------+
+| CSR Attributes    | N/A                      | Section 4.5.1    |
+|                    | application/csrattrs    | Section 4.5.2    |
+|                    | (This document)          |                  |
+| /csrattrs          |                          |                  |
++--------------------+--------------------------+-------------------+
+                              Figure 6
+=== TLS Layer ===
+TLS provides authentication, which in turn enables authorization
+decisions.  The EST server and EST client are responsible for
+ensuring that an acceptable cipher suite is negotiated and that
+mutual authentication has been performed.  TLS authentication is most
+commonly enabled with the use of certificates [[RFC5280]].
+Alternately, certificate-less TLS authentication, where neither the
+client nor server present a certificate, is also an acceptable method
+for EST mutual authentication (Section 3.3.3).  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).
-==== HTTP URIs for Control ====
+HTTPS [[RFC2818]] specifies how HTTP messages are carried over TLS.
+HTTPS MUST be used.  TLS 1.1 [[RFC4346]] (or a later version) MUST be
-The EST server MUST support the use of the path-prefix of "/.well-
+used for all EST communications.  TLS session resumption [[RFC5077]]
-known/" as defined in [RFC5785] and the registered name of "est".
+SHOULD be supported.
-Thus, a valid EST server URI path begins with
-"https://www.example.com/.well-known/est".  Each EST operation is
-indicated by a path-suffix that indicates the intended operation:
-Operations and their corresponding URIs:
-+------------------------+-----------------+-------------------+
-| Operation              |Operation path  | Details          |
-+========================+=================+===================+
-| Distribution of CA    | /cacerts        | Section 4.1       |
-| Certificates (MUST)   |                |                  |
-+------------------------+-----------------+-------------------+
-| Enrollment of          | /simpleenroll  | Section 4.2      |
-| Clients (MUST)        |                |                  |
-+------------------------+-----------------+-------------------+
-| Re-enrollment of      | /simplereenroll | Section 4.2.2    |
-| Clients (MUST)        |                |                  |
-+------------------------+-----------------+-------------------+
-| Full CMC (OPTIONAL)    | /fullcmc        | Section 4.3      |
-+------------------------+-----------------+-------------------+
-| Server-Side Key        | /serverkeygen  | Section 4.4      |
-| Generation (OPTIONAL)  |                |                  |
-+------------------------+-----------------+-------------------+
-| CSR Attributes        | /csrattrs      | Section 4.5      |
-| (OPTIONAL)            |                |                  |
-+------------------------+-----------------+-------------------+
-                              Figure 5
-The operation path (Figure 5) is appended to the path-prefix to form
-the URI used with HTTP GET or POST to perform the desired EST
-operation.  An example valid URI absolute path for the "/cacerts"
-operation is "/.well-known/est/cacerts".  To retrieve the CA's
-certificates, the EST client would use the following HTTP
-request-line:
-GET /.well-known/est/cacerts HTTP/1.1
+TLS channel-binding information can 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.  The EST server
+MUST implement Section 3.5.
-Likewise, to request a new certificate in this example scheme, the
+==== TLS-Based Server Authentication ====
-EST client would use the following request-line:
-POST /.well-known/est/simpleenroll HTTP/1.1
+TLS server authentication with certificates MUST be supported.
+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).
+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
+Explicit and, if enabled, Implicit TA database(s).  The client MUST
+maintain a distinction between the use of Explicit and Implicit TA
+databases during authentication in order to support proper
+authorization.  The EST client MUST perform authorization checks as
+specified in Section 3.6.
+If certificate validation fails, the client MAY follow the procedure
+outlined in Section 4.1.1 for Bootstrap Distribution of CA
+certificates.
+==== TLS-Based Client Authentication ====
+TLS client authentication is the RECOMMENDED method for identifying
+EST clients.  HTTP-based client authentication (Section 3.2.3) 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.
-The use of distinct operation paths simplifies implementation for
+Generally, the client will use an existing certificate for renew or
-servers that do not perform client authentication when distributing
+rekey operations.  If the certificate to be renewed or rekeyed is
-/cacerts responses.
+appropriate for the negotiated cipher suite, then the client MUST use
+it for the TLS handshake, otherwise the client SHOULD use an
+alternate certificate that is suitable for the cipher suite and
+contains the same subject identity information.  When requesting an
+enroll operation, the client MAY use a client certificate issued by a
+third party to authenticate itself.
-An EST server MAY provide service for multiple CAs as indicated by an
+Certificate validation MUST be performed as per [[RFC5280]].  The EST
-OPTIONAL additional path segment between the registered application
+client certificate MUST conform to the [[RFC5280]] certificate profile.
-name and the operation path.  To avoid conflict, the CA label MUST
-NOT be the same as any defined operation path segment.  The EST
-server MUST provide services regardless of whether the additional
-path segment is present.  The following are three example valid URIs:
-.  https://www.example.com/.well-known/est/cacerts
+The server validates the TLS client certificate using the EST server
+Explicit and, if enabled, Implicit TA database(s).  The server MUST
+maintain a distinction between the use of Explicit and Implicit TA
+databases during authentication in order to support proper
+authorization.
-.  https://www.example.com/.well-known/est/arbitraryLabel1/cacerts
+The EST server MUST perform authorization checks as specified in
+Section 3.7.
-.  https://www.example.com/.well-known/est/arbitraryLabel2/cacerts
+If a client does not support TLS client authentication, then it MUST
+support HTTP-based client authentication (Section 3.2.3) or
+certificate-less TLS authentication (Section 3.3.3).
-In this specification, the distinction between enroll and renew/rekey
+==== Certificate-Less TLS Mutual Authentication ====
-is explicitly indicated by the HTTP URI.  When requesting /fullcmc
-operations, CMC [RFC5272] uses the same messages for certificate
-renewal and certificate rekey.
-An EST server can provide additional services using other URIs.
+Certificate-less TLS cipher suites provide a way to perform mutual
+authentication in situations where neither the client nor server have
+certificates, do not desire to use certificates, or do not have the
+trust anchors necessary to verify a certificate.  The client and
+server MAY negotiate a certificate-less cipher suite for mutual
+authentication.
-==== HTTP-Based Client Authentication ====
+When using certificate-less mutual authentication in TLS for
+enrollment, the cipher suite MUST be based on a protocol that is
-The EST server MAY request HTTP-based client authentication.  This
+resistant to dictionary attack and MUST be based on a zero knowledge
-request can be in addition to successful TLS client authentication
+protocol.  Transport Layer Security-Secure Remote Password (TLS-SRP)
-(Section 3.3.2) if EST server policy requires additional
+cipher suites, i.e., those with _SRP_ in the name, listed in
-authentication.  (For example, the EST server may require that an EST
+Section 2.7 of [[RFC5054]] are suitable for this purpose.  Section 6
-client "knows" a password in addition to "having" an existing client
+lists the characteristics of a cipher suite that are suitable for use
-certificate.)  Or, HTTP-based client authentication can be an EST
+in certificate-less mutual authentication for enrollment.
-server policy-specified fallback in situations where the EST client
-did not successfully complete the TLS client authentication.  (This
-might arise if the EST client is enrolling for the first time or if
-the certificates available to an EST client cannot be used for TLS
-client authentication.)
-HTTP Basic and Digest authentication MUST only be performed over TLS
+Successful authentication using a certificate-less cipher suite
-.1 [RFC4346] or later versions.  NULL and anon cipher suites MUST
+proves knowledge of a pre-shared secret that implicitly authorizes a
-NOT be used because they do not provide confidentiality or support
+peer in the exchange.
-mutual certificate-based or certificate-less authentication,
-respectively.  As specified in "Certificate Management over CMS
-(CMC): Transport Protocols" [RFC5273], the server "MUST NOT assume
-client support for any type of HTTP authentication such as cookies,
-Basic authentication, or Digest authentication".  Clients SHOULD
-support the Basic and Digest authentication mechanism.
+=== 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 of 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).
+=== Linking Identity and POP Information ===
+Server policy will determine whether clients are required to use the
+mechanism specified in this section.  This specification provides a
+method of linking identity and proof-of-possession by including
+information specific to the current authenticated TLS session within
+the signed certification request.  The client can determine if the
+server requires the linking of identity and POP by examining the CSR
+Attributes Response (see Section 4.5.2).  Regardless of the CSR
+Attributes Response, 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.  The EST server MAY reject requests without tls-unique
+information as indicated by server policy.
-Servers that wish to use Basic and Digest authentication reject the
+Linking identity and proof-of-possession proves to the server that
-HTTP request using the HTTP-defined WWW-Authenticate response-header
+the authenticated TLS client has possession of the private key
-([RFC2616], Section 14.47).  The client is expected to retry the
+associated with the certification request, and that the client was
-request, including the appropriate Authorization Request header
+able to sign the certification request after the TLS session was
-([RFC2617], Section 3.2.2), if the client is capable of using the
+established.  This is an alternative to the "Linking Identity and POP
-Basic or Digest authentication.  If the client is not capable of
+Information" method defined by Section 6 of [[RFC5272]] that is
-retrying the request or it is not capable of Basic or Digest
+available if Full PKI messages are used.
-authentication, then the client MUST terminate the connection.
-A client MAY set the username to the empty string ("") if it is
-presenting a password that is not associated with a username.
-Support for HTTP-based client authentication has security
-ramifications as discussed in Section 6.  The client MUST NOT respond
-to the server's HTTP authentication request unless the client has
-authorized the EST server (as per Section 3.6).
+The client generating the CSR obtains the tls-unique value from the
+TLS subsystem as described in Channel Bindings for TLS [[RFC5929]].
+The EST client operations between obtaining the tls-unique value
+through generation of the CSR that contains the current tls-unique
+value and the subsequent verification of this value by the EST server
+are the "phases of the application protocol during which application-
+layer authentication occurs"; these operations are protected by the
+synchronization interoperability mechanism described in the "Channel
+Bindings for TLS" interoperability notes in Section 3.1 of [[RFC5929]].
+When performing renegotiation, TLS "secure_renegotiation" [[RFC5746]]
+MUST be used.
+The tls-unique value is base64 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).  The
+challenge-password field is limited to 255 bytes (Section 7.4.9 of
+[[RFC5246]] indicates that no existing cipher suite would result in an
+issue with this limitation).  If the challenge-password attribute is
+absent, the client did not include the optional channel-binding
+information (the presence of the challenge-password attribute
+indicates the inclusion of tls-unique information).
+If the EST server makes use of a 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 the linking of identity and POP
+information is required.
+=== Server Authorization ===
+The client MUST check EST server authorization before accepting any
+server responses or responding to HTTP authentication requests.
+The EST client authorization method depends on which method was used
+to authenticate the server.  When the Explicit TA database is used to
+authenticate the EST server, then Section 3.6.1 applies.  When the
+Implicit TA database is used to authenticate the EST server, then
+Section 3.6.2 applies.  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.
+==== Client Use of Explicit TA Database ====
+When the EST client Explicit TA database is used to validate the EST
+server certificate, the client MUST check either the configured URI
+or the most recent HTTP redirection URI against the server's identity
+according to the rules specified in [[RFC6125]], Section 6.4, or the
+EST server certificate MUST contain the id-kp-cmcRA [[RFC6402]]
+extended key usage extension.
+==== Client Use of Implicit TA Database ====
+When the EST client Implicit TA database is used to validate the EST
+server certificate, the client MUST check the configured URI and each
+HTTP redirection URI according to the rules specified in [[RFC6125]],
+Section 6.4.  The provisioned URI or the most recent HTTP redirection
+URI provides the basis for authorization, and the server's
+authenticated identity confirms it is the authorized server.
+=== 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.
+== 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.
+=== 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.
+==== Bootstrap Distribution of CA Certificates ====
+It is possible that the client was not configured with an Implicit TA
+database that allows a bootstrap installation of the Explicit TA
+database as described in 4.1.3.  This section describes an alternate
+method by which minimally configured EST clients can populate their
+Explicit TA database.
+If the EST client application does not specify either an Explicit TA
+database or an Implicit 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 (Sections 4.1.3 or
+.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-256 or SHA-512 [SHS] hash on the whole CA certificate).  In a
+/fullcmc response, it is the Publish Trust Anchors control (CMC
+[[RFC5272]], Section 6.15) 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 as specified in Section 3.3.1 or if the
+optional certificate-less authentication is used as specified in
+Section 3.3.3.
+The EST client uses the /cacerts response to establish an Explicit
+Trust Anchor database 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).
+==== CA Certificates Request ====
+EST clients request the EST CA 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 SHOULD 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 if certificate-based authentication is used or
+Section 3.3.3 if the optional certificate-less authentication is
+used, and check the server's authorization as given in Section 3.6,
+or follow the procedure outlined in Section 4.1.1.
-==== Message Types ====
+==== CA Certificates Response ====
-This document uses existing media types for the messages as specified
+If successful, the server response MUST have an HTTP 200 response
-by FTP and HTTP [RFC2585], application/pkcs10 [RFC5967], and CMC
+code.  Any other response code indicates an error and the client MUST
-[RFC5272].
+abort the protocol.
-For consistency with [RFC5273], each distinct EST message type uses
+A successful response MUST be a certs-only CMC Simple PKI Response,
-an HTTP Content-Type header with a specific media type.
+as defined in [[RFC5272]], containing the certificates described in the
+following paragraph.  The HTTP content-type of
+"application/pkcs7-mime" is used.  The Simple PKI Response is sent
+with a Content-Transfer-Encoding of "base64" [[RFC2045]].
-The EST messages and their corresponding media types for each
+The EST server MUST include the current root CA certificate in the
-operation are:
+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 EST CA 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"
-| Message type      | Request media type      | Request section(s)|
+certificates OldWithOld, OldWithNew, and NewWithOld in the response
-|                    | Response media type(s)  | Response section  |
+chain.  These are defined in Section 4.4 of CMP [[RFC4210]].  The EST
-| (per operation)    | Source(s) of types      |                  |
+client MUST be able to handle these certificates in the response.
-+====================+==========================+===================+
+The EST CA's most recent self-signed certificate (e.g., NewWithNew
-| Distribution of CA | N/A                      | Section 4.1      |
+certificate) is self-signed and has the latest NotAfter date.  If the
-| Certificates      | application/pkcs7-mime  | Section 4.1.1    |
-|                    | [RFC5751]                |                  |
-| /cacerts          |                          |                  |
-+--------------------+--------------------------+-------------------+
-| Client Certificate | application/pkcs10      | Sections 4.2/4.2.1|
-| Request Functions  | application/pkcs7-mime  | Section 4.2.2    |
-|                    | [RFC5967] [RFC5751]     |                  |
-| /simpleenroll      |                          |                  |
-| /simplereenroll    |                          |                  |
-+--------------------+--------------------------+-------------------+
-| Full CMC          | application/pkcs7-mime  | Section 4.3.1    |
-|                    | application/pkcs7-mime  | Section 4.3.2    |
-| /fullcmc          | [RFC5751]                |                  |
-+--------------------+--------------------------+-------------------+
-| Server-Side Key    | application/pkcs10      | Section 4.4.1    |
-| Generation        | multipart/mixed          | Section 4.4.2    |
-|                    | (application/pkcs7-mime &|                  |
-|                    | application/pkcs8)       |                  |
-|                    | [RFC5967] [RFC5751]      |                  |
-| /serverkeygen      | [RFC5958]                |                  |
-+--------------------+--------------------------+-------------------+
-| CSR Attributes    | N/A                      | Section 4.5.1    |
-|                    | application/csrattrs    | Section 4.5.2    |
-|                    | (This document)          |                  |
-| /csrattrs          |                          |                  |
-+--------------------+--------------------------+-------------------+
-                              Figure 6
+EST server does not include these in the response, then after the
+current EST CA certificate expires, the EST clients will need to be
+reinitialized with the PKI using the Bootstrap Distribution of CA
+certificates (Section 4.1.1) method, which involves user interaction.
+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 EST client MUST store the extracted EST CA certificate as an
+Explicit TA database entry for subsequent EST server authentication.
+The EST client SHOULD disable use of Implicit TA database entries for
+this EST server now that an Explicit TA database entry is available.
+If the client disables the Implicit TA database, and if the EST
+server certificate was verified using an Implicit TA database entry,
+then the client MUST include the "Trusted CA Indication" extension in
+future TLS sessions [[RFC6066]].  This indicates to the server that
+only an EST server certificate authenticatable by the Explicit TA
+database entry is now acceptable (otherwise, the EST server might
+continue to use a server certificate that is only verifiable by a now
+disabled Implicit TA).
+The EST client SHOULD also make the CA Certificate response
+information available to the end-entity software for use when
+validating peer certificates.
+=== 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 if certificate-based authentication is
+used or Section 3.3.3 if the optional certificate-less authentication
+is used.  The client MUST verify the authorization of the EST server
+as specified in Section 3.6.
-=== TLS Layer ===
+The server MUST authenticate the client as specified in Section 3.3.2
+if certificate-based authentication is used or Section 3.3.3 if the
-TLS provides authentication, which in turn enables authorization
+optional certificate-less authentication is used.  The server MUST
-decisions.  The EST server and EST client are responsible for
+verify client authorization as specified in Section 3.7.  The EST
-ensuring that an acceptable cipher suite is negotiated and that
-mutual authentication has been performed.  TLS authentication is most
-commonly enabled with the use of certificates [RFC5280].
-Alternately, certificate-less TLS authentication, where neither the
-client nor server present a certificate, is also an acceptable method
-for EST mutual authentication (Section 3.3.3).  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).
-HTTPS [RFC2818] specifies how HTTP messages are carried over TLS.
-HTTPS MUST be used.  TLS 1.1 [RFC4346] (or a later version) MUST be
-used for all EST communications.  TLS session resumption [RFC5077]
-SHOULD be supported.
-TLS channel-binding information can be inserted into a certificate
+server MUST check the tls-unique value, as described in Section 3.5,
-request, as detailed in Section 3.5, in order to provide the EST
+if one is submitted by the client.
-server with assurance that the authenticated TLS client has access to
-the private key for the certificate being requested.  The EST server
-MUST implement Section 3.5.
-==== TLS-Based Server Authentication ====
+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.)
-TLS server authentication with certificates MUST be supported.
+==== Simple Enrollment of Clients ====
-The EST client authenticates the EST server as defined for the cipher
+When HTTPS POSTing to /simpleenroll, the client MUST include a Simple
-suite negotiated.  The following text provides details assuming a
+PKI Request as specified in CMC [[RFC5272]], Section 3.1 (i.e., a PKCS
-certificate-based cipher suite, such as the TLS 1.1 [RFC4346]
+#10 Certification Request [[RFC2986]]).
-mandatory cipher suite (TLS_RSA_WITH_3DES_EDE_CBC_SHA).
-Certificate validation MUST be performed as per [RFC5280].  The EST
+The Certification Signing Request (CSR) signature provides
-server certificate MUST conform to the [RFC5280] certificate profile.
+proof-of-possession of the client-possessed private key to the EST
+server.  If the CSR KeyUsage extension indicates that the private key
+can be used to generate digital signatures, then the client MUST
+generate the CSR signature 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 MAY still be generated using the private key, but the key
+MUST NOT be used 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 are used when the
+key pair cannot be used for digital signature generation (see
+Section 4.3).
-The client validates the TLS server certificate using the EST client
+The HTTP content-type of "application/pkcs10" is used here.  The
-Explicit and, if enabled, Implicit TA database(s).  The client MUST
+format of the message is as specified in [[RFC5967]] with a Content-
-maintain a distinction between the use of Explicit and Implicit TA
+Transfer-Encoding of "base64" [[RFC2045]].
-databases during authentication in order to support proper
-authorization.  The EST client MUST perform authorization checks as
-specified in Section 3.6.
-If certificate validation fails, the client MAY follow the procedure
+If the EST client authenticated using a previously installed
-outlined in Section 4.1.1 for Bootstrap Distribution of CA
+certificate issued by a third-party CA (see Section 2.2.1), the
-certificates.
+client MAY include the ChangeSubjectName attribute, as defined in
+[[RFC6402]], in the CSR to request that the subjectName and
+SubjectAltName be changed in the new certificate.
+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.
+==== 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, then the EST server renews
+the client certificate.  If the public key information in the
+certification request is different than the current client
+certificate, then the EST server rekeys the client certificate.
-==== TLS-Based Client Authentication ====
+==== Simple Enroll and Re-enroll Response ====
-TLS client authentication is the RECOMMENDED method for identifying
+If the enrollment is successful, the server response MUST contain an
-EST clients.  HTTP-based client authentication (Section 3.2.3) MAY be
+HTTP 200 response code with a content-type of
-used.
+"application/pkcs7-mime".
-The EST server authenticates the EST client as defined for the cipher
+A successful response MUST be a certs-only CMC Simple PKI Response,
-suite negotiated.  The following text provides details assuming a
+as defined in [[RFC5272]], containing only the certificate that was
-certificate-based cipher suite such as the TLS 1.1 [RFC4346]
+issued.  The HTTP content-type of "application/pkcs7-mime" with an
-mandatory cipher suite (TLS_RSA_WITH_3DES_EDE_CBC_SHA).  The EST
+smime-type parameter "certs-only" is used, as specified in [[RFC5273]].
-server MUST support certificate-based client authentication.
-Generally, the client will use an existing certificate for renew or
+The server MUST answer with a suitable 4xx or 5xx HTTP [[RFC2616]]
-rekey operations.  If the certificate to be renewed or rekeyed is
+error code when a problem occurs.  A Simple PKI Response with an HTTP
-appropriate for the negotiated cipher suite, then the client MUST use
+content-type of "application/pkcs7-mime" (see Section 4.3.2) MAY be
-it for the TLS handshake, otherwise the client SHOULD use an
+included in the response data to convey an error response.  If the
-alternate certificate that is suitable for the cipher suite and
+content-type is not set, the response data MUST be a plaintext human-
-contains the same subject identity information.  When requesting an
+readable error message containing explanatory information describing
-enroll operation, the client MAY use a client certificate issued by a
+why the request was rejected (for example, indicating that CSR
-third party to authenticate itself.
+attributes are incomplete).
-Certificate validation MUST be performed as per [RFC5280].  The EST
+If the server responds with an HTTP [[RFC2616]] 202, this indicates
-client certificate MUST conform to the [RFC5280] certificate profile.
+that the request has been accepted for processing but that a response
+is not yet available.  The server MUST include a Retry-After header
-The server validates the TLS client certificate using the EST server
+as defined for HTTP 503 responses.  The server also MAY include
-Explicit and, if enabled, Implicit TA database(s).  The server MUST
+informative human-readable content.  The client MUST wait at least
-maintain a distinction between the use of Explicit and Implicit TA
+the specified "retry-after" time before repeating the same request.
-databases during authentication in order to support proper
+The client repeats the initial enrollment request after the
-authorization.
+appropriate "retry-after" interval has expired.  The client SHOULD
+log or inform the end-user of this event.  The server is responsible
-The EST server MUST perform authorization checks as specified in
+for maintaining all states necessary to recognize and handle retry
-Section 3.7.
+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]].
-If a client does not support TLS client authentication, then it MUST
+If the client closes the TLS connections while waiting for the Retry-
-support HTTP-based client authentication (Section 3.2.3) or
+After time to expire, then the client initiates a new TLS connection
-certificate-less TLS authentication (Section 3.3.3).
+and performs all applicable security checks.  If the client has
+already generated a CSR that includes linking identity and POP
+information (Section 3.5), then the CSR will need to be recreated to
+incorporate the tls-unique from the new, redirected session.  Note:
+the key pair need not be regenerated.  These are processing and
+interface burdens on the client.  EST server administrators are
+advised to take this into consideration.
-==== Certificate-Less TLS Mutual Authentication ====
+The EST client MAY also make the certificate response, and associated
+private key, available to end-entity software for use as an
+end-entity certificate.
-Certificate-less TLS cipher suites provide a way to perform mutual
+=== Full CMC ===
-authentication in situations where neither the client nor server have
-certificates, do not desire to use certificates, or do not have the
-trust anchors necessary to verify a certificate.  The client and
-server MAY negotiate a certificate-less cipher suite for mutual
-authentication.
-When using certificate-less mutual authentication in TLS for
+An EST client can request a certificate from an EST server with an
-enrollment, the cipher suite MUST be based on a protocol that is
+HTTPS POST using the operation path value of "/fullcmc".  Support for
+the /fullcmc function is OPTIONAL for both clients and servers.
+==== 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" with an smime-type parameter "CMC-request",
+as specified in [[RFC5273]].  The body of the message is the binary
+value of the encoding of the PKI Request with a
+Content-Transfer-Encoding of "base64" [[RFC2045]].
+==== Full CMC 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 with an smime-type
+parameter of "certs-only" or the Full PKI Response with an smime-type
+parameter "CMC-response", as specified in Section 3.2.1 of [[RFC5751]].
+The body of the message is the binary value of the encoding of the
+PKI Response with a Content-Transfer-Encoding of "base64" [[RFC2045]].
-resistant to dictionary attack and MUST be based on a zero knowledge
+When rejecting a request, the server MUST specify either an HTTP 4xx
-protocol.  Transport Layer Security-Secure Remote Password (TLS-SRP)
+error or an HTTP 5xx error.  A CMC response with the content-type of
-cipher suites, i.e., those with _SRP_ in the name, listed in
+"application/pkcs7-mime" MUST be included in the response data for
-Section 2.7 of [RFC5054] are suitable for this purpose.  Section 6
+any CMC error response.
-lists the characteristics of a cipher suite that are suitable for use
-in certificate-less mutual authentication for enrollment.
-Successful authentication using a certificate-less cipher suite
+All other return codes are handled as specified in Section 4.2.3 or
-proves knowledge of a pre-shared secret that implicitly authorizes a
+HTTP [[RFC2616]].  For example, a client interprets an HTTP 404 or 501
-peer in the exchange.
+response to indicate that this service is not implemented.
-=== Proof-of-Possession ===
+=== Server-Side Key Generation ===
-As defined in Section 2.1 of CMC [RFC5272], proof-of-possession (POP)
+An EST client may request a private key and associated certificate
-"refers to a value that can be used to prove that the private key
+from an EST server using an HTTPS POST with an operation path value
-corresponding to the public key is in the possession of and can be
+of "/serverkeygen".  Support for the /serverkeygen function is
-used by an end-entity".
+OPTIONAL.
-The signed enrollment request provides a signature-based
+A client MUST authenticate an EST server, as specified in
-proof-of-possession.  The mechanism described in Section 3.5
+Section 3.3.1 if certificate-based authentication is used or
-strengthens this by optionally including "Direct"-based
+Section 3.3.3 if the optional certificate-less authentication is
-proof-of-possession [RFC5272] by including TLS session-specific
+used, and check the server's authorization as given in Section 3.6.
-information within the data covered by the enrollment request
-signature (thus linking the enrollment request to the authenticated
-end point of the TLS connection).
-=== Linking Identity and POP Information ===
+The EST server MUST authenticate the client, as specified in
+Section 3.3.2 if certificate-based authenticated is used or
-Server policy will determine whether clients are required to use the
+Section 3.3.3 if the optional certificate-less authentication is
-mechanism specified in this section.  This specification provides a
+used, and check the client's authorization as given in Section 3.7.
-method of linking identity and proof-of-possession by including
+The EST server applies whatever authorization or logic it chooses to
-information specific to the current authenticated TLS session within
+determine if the private key and certificate should be provided.
-the signed certification request.  The client can determine if the
-server requires the linking of identity and POP by examining the CSR
-Attributes Response (see Section 4.5.2).  Regardless of the CSR
-Attributes Response, 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.  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
+Cipher suites that have a NULL confidentiality algorithm MUST NOT be
-the authenticated TLS client has possession of the private key
+used as they will disclose the contents of an unprotected private
-associated with the certification request, and that the client was
+key.
-able to sign the certification request after the TLS session was
-established.  This is an alternative to the "Linking Identity and POP
-Information" method defined by Section 6 of [RFC5272] that is
-available if Full PKI messages are used.
+Proper random number and key generation [[RFC4086]] is a server
+implementation responsibility, and server archiving of generated keys
+is determined by CA policy.  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.
+==== Server-Side Key Generation Request ====
+The certificate request is HTTPS POSTed and is the same format as for
+the "/simpleenroll" and "/simplereenroll" path extensions with the
+same content-type and transfer encoding.
-The client generating the CSR obtains the tls-unique value from the
+In all respects, the server SHOULD treat the CSR as it would any
-TLS subsystem as described in Channel Bindings for TLS [RFC5929].
+enroll or re-enroll CSR; the only distinction here is that the server
-The EST client operations between obtaining the tls-unique value
+MUST ignore the public key values and signature in the CSR.  These
-through generation of the CSR that contains the current tls-unique
+are included in the request only to allow re-use of existing
-value and the subsequent verification of this value by the EST server
+codebases for generating and parsing such requests.
-are the "phases of the application protocol during which application-
-layer authentication occurs"; these operations are protected by the
-synchronization interoperability mechanism described in the "Channel
-Bindings for TLS" interoperability notes in Section 3.1 of [RFC5929].
-When performing renegotiation, TLS "secure_renegotiation" [RFC5746]
+If the client desires to receive the private key with encryption that
-MUST be used.
+exists outside of 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 an attribute in the CSR indicating
+the encryption key to be used.  Both symmetric and asymmetric
+encryption are supported as described in the following subsections.
+The client MUST also include an SMIMECapabilities attribute
+([[RFC2633]], Section 2.5) in the CSR to indicate the key encipherment
+algorithms the client is willing to use.
-The tls-unique value is base64 encoded as specified in Section 4 of
+It is strongly RECOMMENDED that the clients request that the returned
-[RFC4648], and the resulting string is placed in the certification
+private key be afforded the additional security of the Cryptographic
-request challenge-password field ([RFC2985], Section 5.4.1).  The
+Message Syntax (CMS) EnvelopedData in addition to the TLS-provided
-challenge-password field is limited to 255 bytes (Section 7.4.9 of
+security to protect against unauthorized disclosure.
-[RFC5246] indicates that no existing cipher suite would result in an
-issue with this limitation).  If the challenge-password attribute is
-absent, the client did not include the optional channel-binding
-information (the presence of the challenge-password attribute
-indicates the inclusion of tls-unique information).
-If the EST server makes use of a 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
+===== Requests for Symmetric Key Encryption of the Private Key =====
-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 the linking of identity and POP
-information is required.
-=== Server Authorization ===
+To specify a symmetric encryption key to be used to encrypt the
+server-generated private key, the client MUST include a
+DecryptKeyIdentifier attribute (as defined in Section 2.2.5 of
+[[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 secret key to
+encrypt a private 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 DecryptKeyIdentifier to the key generator and
+the client is outside the scope of this document.
-The client MUST check EST server authorization before accepting any
+===== Requests for Asymmetric Encryption of the Private Key =====
-server responses or responding to HTTP authentication requests.
-The EST client authorization method depends on which method was used
+To specify an asymmetric encryption key to be used to encrypt the
-to authenticate the server.  When the Explicit TA database is used to
+server-generated private key, the client MUST include an
-authenticate the EST server, then Section 3.6.1 applies.  When the
+AsymmetricDecryptKeyIdentifier attribute.  The
-Implicit TA database is used to authenticate the EST server, then
+AsymmetricDecryptKeyIdentifier attribute is defined as:
+id-aa-asymmDecryptKeyID OBJECT IDENTIFIER ::= {
+    id-aa 54 }
+The asymmetric-decrypt-key-identifier attribute values have ASN.1
+type AsymmetricDecryptKeyIdentifier (where ASN.1 is defined in
+[X.680])::
+  AsymmetricDecryptKeyIdentifier ::= OCTET STRING
+If the server does not have a public 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
+AsymmetricDecryptKeyIdentifier to the key generator and the client is
+outside the scope of this document.  If the key identified is bound
+to an X.509 certificate, then the key MUST either explicitly support
+keyTransport or keyAgreement or its use MUST be unrestricted.
-Section 3.6.2 applies.  Successful authentication using a
+==== Server-Side Key Generation Response ====
-certificate-less cipher suite implies authorization of the server.
-The client MAY perform bootstrapping as specified in Section 4.1.1
+If the request is successful, the server response MUST have an HTTP
-even if these checks fail.
+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.
-==== Client Use of Explicit TA Database ====
+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.
-When the EST client Explicit TA database is used to validate the EST
+If additional encryption is not being employed, the private key data
-server certificate, the client MUST check either the configured URI
+MUST be placed in an "application/pkcs8".  An "application/pkcs8"
-or the most recent HTTP redirection URI against the server's identity
+part consists of the base64-encoded DER-encoded [X.690]
-according to the rules specified in [RFC6125], Section 6.4, or the
+PrivateKeyInfo with a Content-Transfer-Encoding of "base64"
-EST server certificate MUST contain the id-kp-cmcRA [RFC6402]
+[[RFC2045]].
-extended key usage extension.
-==== Client Use of Implicit TA Database ====
+If additional encryption is being employed, the private key is placed
+inside of a CMS SignedData.  The SignedData is signed by the party
+that generated the private key, which may or may not be the EST
+server or the EST CA.  The SignedData is further protected by placing
+it inside of a CMS EnvelopedData, as described in Section 4 of
+[[RFC5958]].  The following list shows how the EncryptedData is used,
+depending on the type of protection key specified by the client.
-When the EST client Implicit TA database is used to validate the EST
+o  If the client specified a symmetric encryption key to protect the
-server certificate, the client MUST check the configured URI and each
+  server-generated private key, the EnvelopedData content is
-HTTP redirection URI according to the rules specified in [RFC6125],
+  encrypted using the secret key identified in the request.  The
-Section 6.4.  The provisioned URI or the most recent HTTP redirection
+  EnvelopedData RecipientInfo field MUST indicate the key-encryption
-URI provides the basis for authorization, and the server's
+  kekri key management technique.  The values are as follows:
-authenticated identity confirms it is the authorized server.
+  version is set to 4, key-encryption key identifier (kekid) is set
+  to the value of the DecryptKeyIdentifier from Section 4.4.1.1;
+  keyEncryptionAlgorithm is set to one of the key wrap algorithms
+  that the client included in the SMIMECapabilities accompanying the
+  request; and encryptedKey is the encrypted key.
-=== Client Authorization ===
+o  If the client specified an asymmetric encryption key suitable for
+  key transport operations to protect the server-generated private
+  key, the EnvelopedData content is encrypted using a randomly
+  generated symmetric encryption key.  The cryptographic strength of
+  the symmetric encryption key SHOULD be equivalent to the client-
+  specified asymmetric key.  The EnvelopedData RecipientInfo field
+  MUST indicate the KeyTransRecipientInfo (ktri) key management
+  technique.  In KeyTransRecipientInfo, the RecipientIdentifier
+  (rid) is either the subjectKeyIdentifier copied from the attribute
+  defined in Section 4.4.1.2 or the server determines an associated
+  issuerAndSerialNumber from the attribute; version is derived from
+  the choice of rid [[RFC5652]], keyEncryptionAlgorithm is set to one
+  of the key wrap algorithms that the client included in the
+  SMIMECapabilities accompanying the request, and encryptedKey is
+  the encrypted key.
-The decision to issue a certificate to a client is always controlled
+o  If the client specified an asymmetric encryption key suitable for
-by local CA policy.  The EST server configuration reflects this CA
+  key agreement operations to protect the server-generated private
-policy.  This document does not specify any constraints on such
+  key, the EnvelopedData content is encrypted using a randomly
-policy.  EST provides the EST server access to each client's
+  generated symmetric encryption key.  The cryptographic strength of
-authenticated identity -- e.g., the TLS client's certificate in
+  the symmetric encryption key SHOULD be equivalent to the client-
-addition to any HTTP user authentication credentials -- to help in
+  specified asymmetric key.  The EnvelopedData RecipientInfo field
-implementing such policy.
+  MUST indicate the KeyAgreeRecipientInfo (kari) key management
+  technique.  In the KeyAgreeRecipientInfo type, version,
+  originator, and user keying material (ukm) are as in [[RFC5652]],
+  and keyEncryptionAlgorithm is set to one of the key wrap
+  algorithms that the client included in the SMIMECapabilities
+  accompanying the request.  The recipient's key identifier is
+  either copied from the attribute defined in Section 4.4.1.2 to
+  subjectKeyIdentifier or the server determines an
+  IssuerAndSerialNumber that corresponds to the value provided in
+  the attribute.
-If the client's certificate was issued by the EST CA, and it includes
+In all three additional encryption cases, the EnvelopedData is
-the id-kp-cmcRA [RFC6402] extended key usage extension, then the
+returned in the response as an "application/pkcs7-mime" part with an
-client is a Registration Authority (RA) as described in [RFC5272] and
+smime-type parameter of "server-generated-key" and a Content-
-[RFC6402].  In this case, the EST server SHOULD apply authorization
+Transfer-Encoding of "base64".
-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.
+The certificate data part is an "application/pkcs7-mime" and exactly
+matches the certificate response to /simpleenroll.
+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 plaintext human-readable error message.
+=== 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.
+The EST server SHOULD NOT require client authentication or
+authorization to reply to this request.
+Requesting CSR attributes is optional, but clients are advised that
+CAs may refuse enrollment requests that are not encoded according to
+the CA's policy.
+==== 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".
-== Protocol Exchange Details ==
+==== CSR Attributes Response ====
-Before processing a request, an EST server determines if the client
+If locally configured policy for an authenticated EST client
-is authorized to receive the requested services.  Likewise, the
+indicates a CSR Attributes Response is to be provided, the server
-client determines if it will make requests to the EST server.  These
+response MUST include an HTTP 200 response code.  An HTTP response
-authorization decisions are described in the next two sections.
+code of 204 or 404 indicates that a CSR Attributes Response is not
-Assuming that both sides of the exchange are authorized, then the
+available.  Regardless of the response code, the EST server and CA
-actual operations are as described in subsequent sections.
+MAY reject any subsequent enrollment requests for any reason, e.g.,
+incomplete CSR attributes in the request.
-=== Distribution of CA Certificates ===
+Responses to attribute request messages MUST be encoded as the
+content-type of "application/csrattrs" with a
+Content-Transfer-Encoding of "base64" [[RFC2045]].  The syntax for
+application/csrattrs body is as follows:
-The EST client can request a copy of the current CA certificates.
+CsrAttrs ::= SEQUENCE SIZE (0..MAX) OF AttrOrOID
-This function is generally performed before other EST functions.
-==== Bootstrap Distribution of CA Certificates ====
+AttrOrOID ::= CHOICE (oid OBJECT IDENTIFIER, attribute Attribute }
-It is possible that the client was not configured with an Implicit TA
+Attribute { ATTRIBUTE:IOSet } ::= SEQUENCE {
-database that allows a bootstrap installation of the Explicit TA
+    type  ATTRIBUTE.&id({IOSet}),
-database as described in 4.1.3.  This section describes an alternate
+    values SET SIZE(1..MAX) OF ATTRIBUTE.&Type({IOSet}{@type}) }
-method by which minimally configured EST clients can populate their
-Explicit TA database.
-If the EST client application does not specify either an Explicit TA
+An EST server includes zero or more OIDs or attributes [[RFC2986]] that
-database or an Implicit TA database, then the initial TLS server
+it requests the client to use in the certification request.  The
-authentication and authorization will fail.  The client MAY
+client MUST ignore any OID or attribute it does not recognize.  When
-provisionally continue the TLS handshake to completion for the
+the server encodes CSR Attributes as an empty SEQUENCE, it means that
-purposes of accessing the /cacerts or /fullcmc method.  If the EST
+the server has no specific additional information it desires in a
-client continues with an unauthenticated connection, the client MUST
+client certification request (this is functionally equivalent to an
-extract the HTTP content data from the response (Sections 4.1.3 or
+HTTP response code of 204 or 404).
-.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-256 or SHA-512 [SHS] hash on the whole CA certificate).  In a
-/fullcmc response, it is the Publish Trust Anchors control (CMC
-[RFC5272], Section 6.15) 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
+If the CA requires a particular crypto system or use of a particular
-has not been authenticated as specified in Section 3.3.1 or if the
+signature scheme (e.g., certification of a public key based on a
-optional certificate-less authentication is used as specified in
+certain elliptic curve, or signing using a certain hash algorithm) it
-Section 3.3.3.
+MUST provide that information in the CSR Attribute 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.
-The EST client uses the /cacerts response to establish an Explicit
+The structure of the CSR Attributes Response SHOULD, to the greatest
-Trust Anchor database for subsequent TLS authentication of the EST
+extent possible, reflect the structure of the CSR it is requesting.
-server.  EST clients MUST NOT engage in any other protocol exchange
+Requests to use a particular signature scheme (e.g. using a
+particular hash function) are represented as an OID to be reflected
+in the SignatureAlgorithm of the CSR.  Requests to use a particular
+crypto system (e.g., certification of a public key based on a certain
+elliptic curve) are represented as an attribute, to be reflected as
+the AlgorithmIdentifier of the SubjectPublicKeyInfo, with a type
+indicating the algorithm and the values indicating the particular
+parameters specific to the algorithm.  Requests for descriptive
+information from the client are made by an attribute, to be
+represented as Attributes of the CSR, with a type indicating the
+[[RFC2985]] extensionRequest and the values indicating the particular
+attributes desired to be included in the resulting certificate's
+extensions.
+The sequence is Distinguished Encoding Rules (DER) encoded [X.690]
+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 challengePassword (indicating that linking of
+identity and POP information is requested; see Section 3.5), an
+extensionRequest with the Media Access Control (MAC) address
+([[RFC2307]]) of the client, and to use the secp384r1 elliptic curve
+and to sign with the SHA384 hash function.  Then, it takes the
+following:
+      OID:        challengePassword (1.2.840.113549.1.9.7)
+      Attribute:  type = extensionRequest (1.2.840.113549.1.9.14)
+                  value = macAddress (1.3.6.1.1.1.1.22)
+      Attribute:  type = id-ecPublicKey (1.2.840.10045.2.1)
+                  value = secp384r1 (1.3.132.0.34)
+      OID:        ecdsaWithSHA384 (1.2.840.10045.4.3.3)
-until after the /cacerts response has been accepted and a new TLS
+and encodes them into an ASN.1 SEQUENCE to produce:
-session has been established (using TLS certificate-based
-authentication).
+41 06 09 2a 86 48 86 f7 0d 01 09 07 30 12 06 07 2a 86 48 ce 3d
+01 31 07 06 05 2b 81 04 00 22 30 16 06 09 2a 86 48 86 f7 0d 01
+0e 31 09 06 07 2b 06 01 01 01 01 16 06 08 2a 86 48 ce 3d 04 03
-==== CA Certificates Request ====
+and then base64 encodes the resulting ASN.1 SEQUENCE to produce:
-EST clients request the EST CA TA database information of the CA (in
+    MEEGCSqGSIb3DQEJBzASBgcqhkjOPQIBMQcGBSuBBAAiMBYGCSqGSIb3DQEJDjEJ
-the form of certificates) with an HTTPS GET message using an
+    BgcrBgEBAQEWBggqhkjOPQQDAw==
-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 SHOULD NOT require client authentication or
+== IANA Considerations ==
-authorization to reply to this request.
-The client MUST authenticate the EST server, as specified in
+Section 4.4.1.2 defines an OID that has been registered in an arc
-Section 3.3.1 if certificate-based authentication is used or
+delegated by the IANA to the PKIX working group.
-Section 3.3.3 if the optional certificate-less authentication is
-used, and check the server's authorization as given in Section 3.6,
-or follow the procedure outlined in Section 4.1.1.
-==== CA Certificates Response ====
+IANA has registered the following:
-If successful, the server response MUST have an HTTP 200 response
+IANA updated the well-known URI registry with the following filled-in
-code.  Any other response code indicates an error and the client MUST
+template from [[RFC5785]].
-abort the protocol.
+  URI suffix: est
-A successful response MUST be a certs-only CMC Simple PKI Response,
+  Change controller: IETF
-as defined in [RFC5272], containing the certificates described in the
-following paragraph.  The HTTP content-type of
-"application/pkcs7-mime" is used.  The Simple PKI Response is sent
-with a Content-Transfer-Encoding of "base64" [RFC2045].
-The EST server MUST include the current root CA certificate in the
+IANA has updated the "Application Media Types" registry with the
-response.  The EST server MUST include any additional certificates
+following filled-in templates from [[RFC6838]].
-the client would need to build a chain from an EST CA-issued
-certificate to the current EST CA 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"
+The media subtype for CSR attributes in a CSR Attributes Response is
-certificates OldWithOld, OldWithNew, and NewWithOld in the response
+application/csrattrs.
-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 EST CA's most recent self-signed certificate (e.g., NewWithNew
-certificate) is self-signed and has the latest NotAfter date.  If the
+    Type name: application
+    Subtype name: csrattrs
+    Required parameters: None
+    Optional parameters: None
-EST server does not include these in the response, then after the
+    Encoding considerations: binary;
-current EST CA certificate expires, the EST clients will need to be
-reinitialized with the PKI using the Bootstrap Distribution of CA
-certificates (Section 4.1.1) method, which involves user interaction.
-After out-of-band validation occurs, all the other certificates MUST
+    Security Considerations:
-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 EST client MUST store the extracted EST CA certificate as an
+      Clients request a list of attributes that servers wish to be in
-Explicit TA database entry for subsequent EST server authentication.
+      certification requests.  The request/response is normally done
-The EST client SHOULD disable use of Implicit TA database entries for
+      in a TLS-protected tunnel.
-this EST server now that an Explicit TA database entry is available.
-If the client disables the Implicit TA database, and if the EST
-server certificate was verified using an Implicit TA database entry,
-then the client MUST include the "Trusted CA Indication" extension in
-future TLS sessions [RFC6066].  This indicates to the server that
-only an EST server certificate authenticatable by the Explicit TA
-database entry is now acceptable (otherwise, the EST server might
-continue to use a server certificate that is only verifiable by a now
-disabled Implicit TA).
-The EST client SHOULD also make the CA Certificate response
+    Interoperability considerations: None
-information available to the end-entity software for use when
-validating peer certificates.
-=== Client Certificate Request Functions ===
+    Published specification: This memo.
-EST clients request a certificate from the EST server with an HTTPS
+    Applications which use this media type: Enrollment over Secure
-POST using the operation path value of "/simpleenroll".  EST clients
+    Transport (EST)
-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,
+    Additional information:
-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 if certificate-based authentication is
-used or Section 3.3.3 if the optional certificate-less authentication
-is used.  The client MUST verify the authorization of the EST server
-as specified in Section 3.6.
-The server MUST authenticate the client as specified in Section 3.3.2
+      Magic number(s): None
-if certificate-based authentication is used or Section 3.3.3 if the
-optional certificate-less authentication is used.  The server MUST
-verify client authorization as specified in Section 3.7.  The EST
+      File extension: .csrattrs
+    Person & email address to contact for further information:
+      Dan Harkins <[email protected]>
+    Restrictions on usage: None
-server MUST check the tls-unique value, as described in Section 3.5,
+    Author: Dan Harkins <dharkins@arubanetworks.com>
-if one is submitted by the client.
-The server MAY accept a certificate request for manual authorization
+    Intended usage: COMMON
-checking by an administrator.  (Section 4.2.3 describes the use of an
-HTTP 202 response to the EST client if this occurs.)
-==== Simple Enrollment of Clients ====
+    Change controller: The IESG <[email protected]>
-When HTTPS POSTing to /simpleenroll, the client MUST include a Simple
+The application/pkcs7-mime content-type defines the optional
-PKI Request as specified in CMC [RFC5272], Section 3.1 (i.e., a PKCS
+"smime-type" parameter [[RFC5751]] with a set of specific values.  This
-#10 Certification Request [RFC2986]).
+document adds another value, "server-generated-key", as the parameter
+value for Server-side Key Generation Response.
-The Certification Signing Request (CSR) signature provides
+== Security Considerations ==
-proof-of-possession of the client-possessed private key to the EST
-server.  If the CSR KeyUsage extension indicates that the private key
-can be used to generate digital signatures, then the client MUST
-generate the CSR signature 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 MAY still be generated using the private key, but the key
-MUST NOT be used 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 are used when the
-key pair cannot be used for digital signature generation (see
-Section 4.3).
-The HTTP content-type of "application/pkcs10" is used here.  The
+Support for Basic authentication, as specified in HTTP [[RFC2617]],
-format of the message is as specified in [RFC5967] with a Content-
+allows the server access to a client's cleartext password.  This
-Transfer-Encoding of "base64" [RFC2045].
+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).
-If the EST client authenticated using a previously installed
+When a client uses the Implicit TA database for certificate
-certificate issued by a third-party CA (see Section 2.2.1), the
+validation (see Section 3), then authorization proceeds as specified
-client MAY include the ChangeSubjectName attribute, as defined in
+in Section 3.6.2.  In this situation, the client has validated the
-[RFC6402], in the CSR to request that the subjectName and
+server as being a responder that is certified by a third party for
-SubjectAltName be changed in the new certificate.
+the URI configured, but it 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 an Implicit Trust Anchor database are
+RECOMMENDED to use only 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 man in the middle).  It is
+RECOMMENDED that the Implicit 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.
+Disabling the Implicit Trust Anchor database after successfully
+receiving the Distribution of CA certificates response
+(Section 4.1.3) limits any vulnerability to the first TLS exchange.
-The EST client MAY request additional certificates even when using an
+Certificate-less TLS cipher suites that maintain security and perform
-existing certificate in the TLS client authentication.  For example,
+the mutual authentication necessary for enrollment have the following
-the client can use an existing certificate for TLS client
+properties:
-authentication when requesting a certificate that cannot be used for
-TLS client authentication.
+o  the only information leaked by an active attack is whether or not
+  a single guess of the secret is correct.
+o  any advantage an adversary gains is through interaction and not
+  computation.
+o  it is possible to perform countermeasures, such as exponential
+  backoff after a certain number of failed attempts, to frustrate
+  repeated active attacks.
+Using a certificate-less cipher suite that does not have the
+properties listed above would render the results of enrollment void
+and potentially result in certificates being issued to
+unauthenticated and/or unauthorized entities.
+When using a certificate-less TLS cipher suite, the shared secret
+used for authentication and authorization cannot be shared with an
+entity that is not a party to the exchange: someone other than the
+client and the server.  Any additional 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 result in corruption of a
+client's trust anchor database.
+TLS cipher suites that include "_EXPORT_" and "_DES_" in their names
+MUST NOT be used.  These ciphers do not offer a sufficient level of
+protection; 40-bit crypto in 2013 doesn't offer acceptable
+protection, and the use of DES is deprecated.
+As described in CMC, Section 6.7 of [[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 without any application-layer
+protection.  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 RECOMMENDED 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 an Implicit 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.
-==== Simple Re-enrollment of Clients ====
+Regarding the CSR attributes that the CA may list for inclusion in an
+enrollment request, there are no real inherent security issues with
-EST clients renew/rekey certificates with an HTTPS POST using the
+the content being conveyed, but an adversary who is able to interpose
-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, then the EST server renews
-the client certificate.  If the public key information in the
-certification request is different than the current client
-certificate, then the EST server rekeys the client certificate.
-==== Simple Enroll and Re-enroll Response ====
+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.
-If the enrollment is successful, the server response MUST contain an
+ASN.1 encoding rules (e.g., DER and BER) have a type-length-value
-HTTP 200 response code with a content-type of
+structure, and it is easy to construct malicious content with invalid
-"application/pkcs7-mime".
+length fields that can cause buffer overrun conditions.  ASN.1
+encoding rules allow for arbitrary levels of nesting, which may make
+it possible to construct malicious content that will cause a stack
+overflow.  Interpreters of ASN.1 structures should be aware of these
+issues and should take appropriate measures to guard against buffer
+overflows and stack overruns in particular, and malicious content in
+general.
-A successful response MUST be a certs-only CMC Simple PKI Response,
+== References ==
-as defined in [RFC5272], containing only the certificate that was
-issued.  The HTTP content-type of "application/pkcs7-mime" with an
-smime-type parameter "certs-only" is used, as specified in [RFC5273].
-The server MUST answer with a suitable 4xx or 5xx HTTP [RFC2616]
+=== Normative References ===
-error code when a problem occurs.  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 plaintext human-
-readable error message containing explanatory 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
+[[RFC2045]]  Freed, N. and N. Borenstein, "Multipurpose Internet Mail
-that the request has been accepted for processing but that a response
+          Extensions (MIME) Part One: Format of Internet Message
-is not yet available.  The server MUST include a Retry-After header
+          Bodies", [[RFC2045|RFC 2045]], November 1996.
-as defined for HTTP 503 responses.  The server also MAY include
-informative human-readable content.  The client MUST wait at least
+[[RFC2119]]  Bradner, S., "Key words for use in RFCs to Indicate
-the specified "retry-after" time before repeating the same request.
+          Requirement Levels", [[BCP14|BCP 14]], [[RFC2119|RFC 2119]], March 1997.
-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
+[[RFC2585]]  Housley, R. and P. Hoffman, "Internet X.509 Public Key
+          Infrastructure Operational Protocols: FTP and HTTP", RFC
+, 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", [[RFC2616|RFC 2616]], 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",
+          [[RFC2617|RFC 2617]], June 1999.
+[[RFC2633]]  Ramsdell, B., "S/MIME Version 3 Message Specification",
+          [[RFC2633|RFC 2633]], June 1999.
-for maintaining all states necessary to recognize and handle retry
+[[RFC2986]]  Nystrom, M. and B. Kaliski, "PKCS #10: Certification
-operations as the client is stateless in this regard; it simply sends
+          Request Syntax Specification Version 1.7", [[RFC2986|RFC 2986]],
-the same request repeatedly until it receives a different response
+          November 2000.
-code.  All other return codes are handled as specified in HTTP
-[RFC2616].
-If the client closes the TLS connections while waiting for the Retry-
+[[RFC3986]]  Berners-Lee, T., Fielding, R., and L. Masinter, "Uniform
-After time to expire, then the client initiates a new TLS connection
+          Resource Identifier (URI): Generic Syntax", [[STD66|STD 66]], RFC
-and performs all applicable security checks.  If the client has
+, January 2005.
-already generated a CSR that includes linking identity and POP
-information (Section 3.5), then the CSR will need to be recreated to
-incorporate the tls-unique from the new, redirected session.  Note:
-the key pair need not be regenerated.  These are processing and
-interface burdens on the client.  EST server administrators are
-advised to take this into consideration.
-The EST client MAY also make the certificate response, and associated
+[[RFC4086]]  Eastlake, D., Schiller, J., and S. Crocker, "Randomness
-private key, available to end-entity software for use as an
+          Requirements for Security", [[BCP106|BCP 106]], [[RFC4086|RFC 4086]], June 2005.
-end-entity certificate.
-=== Full CMC ===
+[[RFC4108]]  Housley, R., "Using Cryptographic Message Syntax (CMS) to
+          Protect Firmware Packages", [[RFC4108|RFC 4108]], August 2005.
-An EST client can request a certificate from an EST server with an
+[[RFC4210]]  Adams, C., Farrell, S., Kause, T., and T. Mononen,
-HTTPS POST using the operation path value of "/fullcmc".  Support for
+          "Internet X.509 Public Key Infrastructure Certificate
-the /fullcmc function is OPTIONAL for both clients and servers.
+          Management Protocol (CMP)", [[RFC4210|RFC 4210]], September 2005.
-==== Full CMC Request ====
+[[RFC4346]]  Dierks, T. and E. Rescorla, "The Transport Layer Security
+          (TLS) Protocol Version 1.1", [[RFC4346|RFC 4346]], April 2006.
-If the HTTP POST to /fullcmc is not a valid Full PKI Request, the
+[[RFC4648]]  Josefsson, S., "The Base16, Base32, and Base64 Data
-server MUST reject the message.  The HTTP content-type used is
+          Encodings", [[RFC4648|RFC 4648]], October 2006.
-"application/pkcs7-mime" with an smime-type parameter "CMC-request",
-as specified in [RFC5273].  The body of the message is the binary
+[[RFC5077]]  Salowey, J., Zhou, H., Eronen, P., and H. Tschofenig,
-value of the encoding of the PKI Request with a
+          "Transport Layer Security (TLS) Session Resumption without
-Content-Transfer-Encoding of "base64" [RFC2045].
+          Server-Side State", [[RFC5077|RFC 5077]], January 2008.
+[[RFC5246]]  Dierks, T. and E. Rescorla, "The Transport Layer Security
+          (TLS) Protocol Version 1.2", [[RFC5246|RFC 5246]], August 2008.
+[[RFC5272]]  Schaad, J. and M. Myers, "Certificate Management over CMS
+          (CMC)", [[RFC5272|RFC 5272]], June 2008.
-==== Full CMC Response ====
+[[RFC5273]]  Schaad, J. and M. Myers, "Certificate Management over CMS
+          (CMC): Transport Protocols", [[RFC5273|RFC 5273]], June 2008.
-If the enrollment is successful, the server response MUST include an
+[[RFC5274]]  Schaad, J. and M. Myers, "Certificate Management Messages
-HTTP 200 response code with a content-type of
+          over CMS (CMC): Compliance Requirements", [[RFC5274|RFC 5274]], June
-"application/pkcs7-mime" as specified in [RFC5273].  The response
+.
-data includes either the Simple PKI Response with an smime-type
-parameter of "certs-only" or the Full PKI Response with an smime-type
-parameter "CMC-response", as specified in Section 3.2.1 of [RFC5751].
-The body of the message is the binary value of the encoding of the
-PKI Response with a Content-Transfer-Encoding of "base64" [RFC2045].
+[[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", [[RFC5280|RFC 5280]], May 2008.
+[[RFC5652]]  Housley, R., "Cryptographic Message Syntax (CMS)", [[STD70|STD 70]],
+          [[RFC5652|RFC 5652]], September 2009.
+[[RFC5746]]  Rescorla, E., Ray, M., Dispensa, S., and N. Oskov,
+          "Transport Layer Security (TLS) Renegotiation Indication
+          Extension", [[RFC5746|RFC 5746]], February 2010.
+[[RFC5751]]  Ramsdell, B. and S. Turner, "Secure/Multipurpose Internet
+          Mail Extensions (S/MIME) Version 3.2 Message
+          Specification", [[RFC5751|RFC 5751]], January 2010.
+[[RFC5785]]  Nottingham, M. and E. Hammer-Lahav, "Defining Well-Known
+          Uniform Resource Identifiers (URIs)", [[RFC5785|RFC 5785]], April
+.
+[[RFC5929]]  Altman, J., Williams, N., and L. Zhu, "Channel Bindings
+          for TLS", [[RFC5929|RFC 5929]], July 2010.
+[[RFC5958]]  Turner, S., "Asymmetric Key Packages", [[RFC5958|RFC 5958]], August
+.
-When rejecting a request, the server MUST specify either an HTTP 4xx
+[[RFC6066]]  Eastlake, D., "Transport Layer Security (TLS) Extensions:
-error or an HTTP 5xx error.  A CMC response with the content-type of
+          Extension Definitions", [[RFC6066|RFC 6066]], January 2011.
-"application/pkcs7-mime" MUST be included in the response data for
-any CMC error response.
-All other return codes are handled as specified in Section 4.2.3 or
+[[RFC6125]]  Saint-Andre, P. and J. Hodges, "Representation and
-HTTP [RFC2616].  For example, a client interprets an HTTP 404 or 501
+          Verification of Domain-Based Application Service Identity
-response to indicate that this service is not implemented.
+          within Internet Public Key Infrastructure Using X.509
+          (PKIX) Certificates in the Context of Transport Layer
+          Security (TLS)", [[RFC6125|RFC 6125]], March 2011.
-=== Server-Side Key Generation ===
+[[RFC6402]]  Schaad, J., "Certificate Management over CMS (CMC)
+          Updates", [[RFC6402|RFC 6402]], November 2011.
-An EST client may request a private key and associated certificate
+[[RFC6454]]  Barth, A., "The Web Origin Concept", [[RFC6454|RFC 6454]], December
-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
+[[RFC6838]]  Freed, N., Klensin, J., and T. Hansen, "Media Type
-Section 3.3.1 if certificate-based authentication is used or
+          Specifications and Registration Procedures", [[BCP13|BCP 13]], RFC
-Section 3.3.3 if the optional certificate-less authentication is
+, January 2013.
-used, and check the server's authorization as given in Section 3.6.
-The EST server MUST authenticate the client, as specified in
+[X.680]    ITU-T Recommendation X.680 (2008) | ISO/IEC 8824-1:2008,
-Section 3.3.2 if certificate-based authenticated is used or
+          "Abstract Syntax Notation One (ASN.1): Specification of
-Section 3.3.3 if the optional certificate-less authentication is
+          basic notation", November 2008,
-used, and check the client's authorization as given in Section 3.7.
+          <http://www.itu.int/rec/T-REC-X.680-200811-I/en>.
-The EST server applies whatever authorization or logic it chooses to
-determine if the private key and certificate should be provided.
+[X.690]    ITU-T Recommendation X.690 (2008) | ISO/IEC 8825-1:2008,
+          "ASN.1 encoding rules: Specification of Basic Encoding
+          Rules (BER), Canonical Encoding Rules (CER) and
+          Distinguished Encoding Rules (DER)", November 2008,
+          <http://www.itu.int/rec/T-REC-X.690-200811-I/en>.
-Cipher suites that have a NULL confidentiality algorithm MUST NOT be
+=== Informative References ===
-used as they will disclose the contents of an unprotected private
-key.
-Proper random number and key generation [RFC4086] is a server
+[IDevID]   IEEE Standards Association, "IEEE 802.1AR Secure Device
-implementation responsibility, and server archiving of generated keys
+          Identifier", December 2009, <http://standards.ieee.org/
-is determined by CA policy.  The key pair and certificate are
+          findstds/standard/802.1AR-2009.html>.
-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
+[[RFC2307]]  Howard, L., "An Approach for Using LDAP as a Network
-existing certificate in the TLS client authentication.  For example,
+          Information Service", [[RFC2307|RFC 2307]], March 1998.
-the client can use an existing certificate for TLS client
-authentication when requesting a certificate that cannot be used for
-TLS client authentication.
+[[RFC2818]]  Rescorla, E., "HTTP Over TLS", [[RFC2818|RFC 2818]], May 2000.
+[[RFC2985]]  Nystrom, M. and B. Kaliski, "PKCS #9: Selected Object
+          Classes and Attribute Types Version 2.0", [[RFC2985|RFC 2985]],
+          November 2000.
+[[RFC3394]]  Schaad, J. and R. Housley, "Advanced Encryption Standard
+          (AES) Key Wrap Algorithm", [[RFC3394|RFC 3394]], September 2002.
+[[RFC5054]]  Taylor, D., Wu, T., Mavrogiannopoulos, N., and T. Perrin,
+          "Using the Secure Remote Password (SRP) Protocol for TLS
+          Authentication", [[RFC5054|RFC 5054]], November 2007.
+[[RFC5967]]  Turner, S., "The application/pkcs10 Media Type", [[RFC5967|RFC 5967]],
+          August 2010.
+[[RFC6403]]  Zieglar, L., Turner, S., and M. Peck, "Suite B Profile of
+          Certificate Management over CMS", [[RFC6403|RFC 6403]], November 2011.
+[SHS]      National Institute of Standards and Technology, "Secure
+          Hash Standard (SHS)", Federal Information Processing
+          Standard Publication 180-4, March 2012,
+          <http://csrc.nist.gov/publications/fips/
+          fips180-4/fips-180-4.pdf>.
+[SP-800-57-Part-1]
+          National Institute of Standards and Technology,
+          "Recommendation for Key Management - Part 1: General
+          (Revision 3)", July 2012,
+          <http://csrc.nist.gov/publications/nistpubs/800-57/
+          sp800-57_part1_rev3_general.pdf>.
-==== Server-Side Key Generation Request ====
+Appendix A.  Operational Scenario Example Messages
-The certificate request is HTTPS POSTed and is the same format as for
+(Informative)
-the "/simpleenroll" and "/simplereenroll" path extensions with the
-same content-type and transfer encoding.
-In all respects, the server SHOULD treat the CSR as it would any
+This section expands on the Operational Scenario Overviews by
-enroll or re-enroll CSR; the only distinction here is that the server
+providing detailed examples of the messages at each TLS layer.
-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
+A.1.  Obtaining CA Certificates
-exists outside of and in addition to that of the TLS transport used
-by EST or if server policy requires that the key be delivered in such
+The following is an example of a valid /cacerts exchange.
-a form, the client MUST include an attribute in the CSR indicating
-the encryption key to be used.  Both symmetric and asymmetric
-encryption are supported as described in the following subsections.
-The client MUST also include an SMIMECapabilities attribute
-([RFC2633], Section 2.5) in the CSR to indicate the key encipherment
-algorithms the client is willing to use.
-It is strongly RECOMMENDED that the clients request that the returned
+During the initial TLS handshake, the client can ignore the optional
-private key be afforded the additional security of the Cryptographic
+server-generated "certificate request" and can instead proceed with
-Message Syntax (CMS) EnvelopedData in addition to the TLS-provided
+the HTTP GET request:
-security to protect against unauthorized disclosure.
-.4.1.1.  Requests for Symmetric Key Encryption of the Private Key
+GET /.well-known/est/cacerts HTTP/1.1
+User-Agent: curl/7.22.0 (i686-pc-linux-gnu) libcurl/7.22.0 OpenS
-To specify a symmetric encryption key to be used to encrypt the
+SL/1.0.1 zlib/1.2.3.4 libidn/1.23 librtmp/2.3
-server-generated private key, the client MUST include a
+Host: 192.0.2.1:8085
-DecryptKeyIdentifier attribute (as defined in Section 2.2.5 of
+Accept: */*
-[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 secret key to
-encrypt a private 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 DecryptKeyIdentifier to the key generator and
-the client is outside the scope of this document.
-.4.1.2.  Requests for Asymmetric Encryption of the Private Key
-To specify an asymmetric encryption key to be used to encrypt the
-server-generated private key, the client MUST include an
-AsymmetricDecryptKeyIdentifier attribute.  The
-AsymmetricDecryptKeyIdentifier attribute is defined as:
-id-aa-asymmDecryptKeyID OBJECT IDENTIFIER ::= {
-    id-aa 54 }
-The asymmetric-decrypt-key-identifier attribute values have ASN.1
-type AsymmetricDecryptKeyIdentifier (where ASN.1 is defined in
-[X.680])::
-  AsymmetricDecryptKeyIdentifier ::= OCTET STRING
-If the server does not have a public 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
-AsymmetricDecryptKeyIdentifier to the key generator and the client is
-outside the scope of this document.  If the key identified is bound
-to an X.509 certificate, then the key MUST either explicitly support
-keyTransport or keyAgreement or its use MUST be unrestricted.
-==== Server-Side Key Generation Response ====
-If the request is successful, the server response MUST have an HTTP
-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 not being employed, the private key data
-MUST be placed in an "application/pkcs8".  An "application/pkcs8"
-part consists of the base64-encoded DER-encoded [X.690]
-PrivateKeyInfo with a Content-Transfer-Encoding of "base64"
-[RFC2045].
-If additional encryption is being employed, the private key is placed
-inside of a CMS SignedData.  The SignedData is signed by the party
-that generated the private key, which may or may not be the EST
-server or the EST CA.  The SignedData is further protected by placing
-it inside of a CMS EnvelopedData, as described in Section 4 of
-[RFC5958].  The following list shows how the EncryptedData is used,
-depending on the type of protection key specified by the client.
-o  If the client specified a symmetric encryption key to protect the
-  server-generated private key, the EnvelopedData content is
-  encrypted using the secret key identified in the request.  The
-  EnvelopedData RecipientInfo field MUST indicate the key-encryption
-  kekri key management technique.  The values are as follows:
-  version is set to 4, key-encryption key identifier (kekid) is set
-  to the value of the DecryptKeyIdentifier from Section 4.4.1.1;
-  keyEncryptionAlgorithm is set to one of the key wrap algorithms
-  that the client included in the SMIMECapabilities accompanying the
-  request; and encryptedKey is the encrypted key.
-o  If the client specified an asymmetric encryption key suitable for
-  key transport operations to protect the server-generated private
-  key, the EnvelopedData content is encrypted using a randomly
-  generated symmetric encryption key.  The cryptographic strength of
-  the symmetric encryption key SHOULD be equivalent to the client-
-  specified asymmetric key.  The EnvelopedData RecipientInfo field
-  MUST indicate the KeyTransRecipientInfo (ktri) key management
-  technique.  In KeyTransRecipientInfo, the RecipientIdentifier
-  (rid) is either the subjectKeyIdentifier copied from the attribute
-  defined in Section 4.4.1.2 or the server determines an associated
-  issuerAndSerialNumber from the attribute; version is derived from
-  the choice of rid [RFC5652], keyEncryptionAlgorithm is set to one
-  of the key wrap algorithms that the client included in the
-  SMIMECapabilities accompanying the request, and encryptedKey is
-  the encrypted key.
-o  If the client specified an asymmetric encryption key suitable for
-  key agreement operations to protect the server-generated private
-  key, the EnvelopedData content is encrypted using a randomly
-  generated symmetric encryption key.  The cryptographic strength of
-  the symmetric encryption key SHOULD be equivalent to the client-
-  specified asymmetric key.  The EnvelopedData RecipientInfo field
-  MUST indicate the KeyAgreeRecipientInfo (kari) key management
-  technique.  In the KeyAgreeRecipientInfo type, version,
-  originator, and user keying material (ukm) are as in [RFC5652],
-  and keyEncryptionAlgorithm is set to one of the key wrap
-  algorithms that the client included in the SMIMECapabilities
-  accompanying the request.  The recipient's key identifier is
-  either copied from the attribute defined in Section 4.4.1.2 to
-  subjectKeyIdentifier or the server determines an
-  IssuerAndSerialNumber that corresponds to the value provided in
-  the attribute.
-In all three additional encryption cases, the EnvelopedData is
-returned in the response as an "application/pkcs7-mime" part with an
-smime-type parameter of "server-generated-key" and a Content-
-Transfer-Encoding of "base64".
-The certificate data part is an "application/pkcs7-mime" and exactly
-matches the certificate response to /simpleenroll.
-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 plaintext human-readable error message.
-=== 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.
-The EST server SHOULD NOT require client authentication or
-authorization to reply to this request.
-Requesting CSR attributes is optional, but clients are advised that
-CAs may refuse enrollment requests that are not encoded according to
-the CA's policy.
-==== 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".
-==== 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.
-Responses to attribute request messages MUST be encoded as the
-content-type of "application/csrattrs" with a
-Content-Transfer-Encoding of "base64" [RFC2045].  The syntax for
-application/csrattrs body is as follows:
-CsrAttrs ::= SEQUENCE SIZE (0..MAX) OF AttrOrOID
-AttrOrOID ::= CHOICE (oid OBJECT IDENTIFIER, attribute Attribute }
-Attribute { ATTRIBUTE:IOSet } ::= SEQUENCE {
-    type  ATTRIBUTE.&id({IOSet}),
-    values SET SIZE(1..MAX) OF ATTRIBUTE.&Type({IOSet}{@type}) }
-An EST server includes zero or more OIDs or attributes [RFC2986] that
-it requests the client to use in the certification request.  The
-client MUST ignore any OID or attribute it does not recognize.  When
-the server encodes CSR Attributes as an empty SEQUENCE, it means that
-the server has no specific additional information it desires in a
-client certification request (this is functionally equivalent to an
-HTTP response code of 204 or 404).
-If the CA requires a particular crypto system or use of a particular
-signature scheme (e.g., certification of a public key based on a
-certain elliptic curve, or signing using a certain hash algorithm) it
-MUST provide that information in the CSR Attribute 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.
-The structure of the CSR Attributes Response SHOULD, to the greatest
-extent possible, reflect the structure of the CSR it is requesting.
-Requests to use a particular signature scheme (e.g. using a
-particular hash function) are represented as an OID to be reflected
-in the SignatureAlgorithm of the CSR.  Requests to use a particular
-crypto system (e.g., certification of a public key based on a certain
-elliptic curve) are represented as an attribute, to be reflected as
-the AlgorithmIdentifier of the SubjectPublicKeyInfo, with a type
-indicating the algorithm and the values indicating the particular
-parameters specific to the algorithm.  Requests for descriptive
-information from the client are made by an attribute, to be
-represented as Attributes of the CSR, with a type indicating the
-[RFC2985] extensionRequest and the values indicating the particular
-attributes desired to be included in the resulting certificate's
-extensions.
-The sequence is Distinguished Encoding Rules (DER) encoded [X.690]
-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 challengePassword (indicating that linking of
-identity and POP information is requested; see Section 3.5), an
-extensionRequest with the Media Access Control (MAC) address
-([RFC2307]) of the client, and to use the secp384r1 elliptic curve
-and to sign with the SHA384 hash function.  Then, it takes the
-following:
-      OID:        challengePassword (1.2.840.113549.1.9.7)
-      Attribute:  type = extensionRequest (1.2.840.113549.1.9.14)
-                  value = macAddress (1.3.6.1.1.1.1.22)
-      Attribute:  type = id-ecPublicKey (1.2.840.10045.2.1)
-                  value = secp384r1 (1.3.132.0.34)
-      OID:        ecdsaWithSHA384 (1.2.840.10045.4.3.3)
-and encodes them into an ASN.1 SEQUENCE to produce:
-41 06 09 2a 86 48 86 f7 0d 01 09 07 30 12 06 07 2a 86 48 ce 3d
-01 31 07 06 05 2b 81 04 00 22 30 16 06 09 2a 86 48 86 f7 0d 01
-0e 31 09 06 07 2b 06 01 01 01 01 16 06 08 2a 86 48 ce 3d 04 03
-and then base64 encodes the resulting ASN.1 SEQUENCE to produce:
-    MEEGCSqGSIb3DQEJBzASBgcqhkjOPQIBMQcGBSuBBAAiMBYGCSqGSIb3DQEJDjEJ
-    BgcrBgEBAQEWBggqhkjOPQQDAw==
-== IANA Considerations ==
-Section 4.4.1.2 defines an OID that has been registered in an arc
-delegated by the IANA to the PKIX working group.
-IANA has registered the following:
-IANA updated the well-known URI registry with the following filled-in
-template from [RFC5785].
-  URI suffix: est
-  Change controller: IETF
-IANA has updated the "Application Media Types" registry with the
-following filled-in templates from [RFC6838].
-The media subtype for CSR attributes in a CSR Attributes Response 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 is normally 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: .csrattrs
-    Person & email address to contact for further information:
-      Dan Harkins <[email protected]>
-    Restrictions on usage: None
-    Author: Dan Harkins <[email protected]>
-    Intended usage: COMMON
-    Change controller: The IESG <[email protected]>
-The application/pkcs7-mime content-type defines the optional
-"smime-type" parameter [RFC5751] with a set of specific values.  This
-document adds another value, "server-generated-key", as the parameter
-value for Server-side Key Generation Response.
-== 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 Implicit TA database for certificate
-validation (see Section 3), then authorization proceeds as specified
-in Section 3.6.2.  In this situation, the client has validated the
-server as being a responder that is certified by a third party for
-the URI configured, but it 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 an Implicit Trust Anchor database are
-RECOMMENDED to use only 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 man in the middle).  It is
-RECOMMENDED that the Implicit 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.
-Disabling the Implicit Trust Anchor database after successfully
-receiving the Distribution of CA certificates response
-(Section 4.1.3) limits any vulnerability to the first TLS exchange.
-Certificate-less TLS cipher suites that maintain security and perform
-the mutual authentication necessary for enrollment have the following
-properties:
-o  the only information leaked by an active attack is whether or not
-  a single guess of the secret is correct.
-o  any advantage an adversary gains is through interaction and not
-  computation.
-o  it is possible to perform countermeasures, such as exponential
-  backoff after a certain number of failed attempts, to frustrate
-  repeated active attacks.
-Using a certificate-less cipher suite that does not have the
-properties listed above would render the results of enrollment void
-and potentially result in certificates being issued to
-unauthenticated and/or unauthorized entities.
-When using a certificate-less TLS cipher suite, the shared secret
-used for authentication and authorization cannot be shared with an
-entity that is not a party to the exchange: someone other than the
-client and the server.  Any additional 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 result in corruption of a
-client's trust anchor database.
-TLS cipher suites that include "_EXPORT_" and "_DES_" in their names
-MUST NOT be used.  These ciphers do not offer a sufficient level of
-protection; 40-bit crypto in 2013 doesn't offer acceptable
-protection, and the use of DES is deprecated.
-As described in CMC, Section 6.7 of [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 without any application-layer
-protection.  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 RECOMMENDED 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 an Implicit 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.
-ASN.1 encoding rules (e.g., DER and BER) have a type-length-value
-structure, and it is easy to construct malicious content with invalid
-length fields that can cause buffer overrun conditions.  ASN.1
-encoding rules allow for arbitrary levels of nesting, which may make
-it possible to construct malicious content that will cause a stack
-overflow.  Interpreters of ASN.1 structures should be aware of these
-issues and should take appropriate measures to guard against buffer
-overflows and stack overruns in particular, and malicious content in
-general.
-== References ==
-=== Normative References ===
-[RFC2045]  Freed, N. and N. Borenstein, "Multipurpose Internet Mail          Extensions (MIME) Part One: Format of Internet Message          Bodies", [[RFC2045|RFC 2045]], November 1996.
-[RFC2119]  Bradner, S., "Key words for use in RFCs to Indicate          Requirement Levels", [[BCP14|BCP 14]], [[RFC2119|RFC 2119]], March 1997.
-[RFC2585]  Housley, R. and P. Hoffman, "Internet X.509 Public Key          Infrastructure Operational Protocols: FTP and HTTP", RFC          2585, 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", [[RFC2616|RFC 2616]], 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",          [[RFC2617|RFC 2617]], June 1999.
-[RFC2633]  Ramsdell, B., "S/MIME Version 3 Message Specification",          [[RFC2633|RFC 2633]], June 1999.
-[RFC2986]  Nystrom, M. and B. Kaliski, "PKCS #10: Certification          Request Syntax Specification Version 1.7", [[RFC2986|RFC 2986]],          November 2000.
-[RFC3986]  Berners-Lee, T., Fielding, R., and L. Masinter, "Uniform          Resource Identifier (URI): Generic Syntax", STD 66, RFC          3986, January 2005.
-[RFC4086]  Eastlake, D., Schiller, J., and S. Crocker, "Randomness          Requirements for Security", [[BCP106|BCP 106]], [[RFC4086|RFC 4086]], June 2005.
-[RFC4108]  Housley, R., "Using Cryptographic Message Syntax (CMS) to          Protect Firmware Packages", [[RFC4108|RFC 4108]], August 2005.
-[RFC4210]  Adams, C., Farrell, S., Kause, T., and T. Mononen,          "Internet X.509 Public Key Infrastructure Certificate          Management Protocol (CMP)", [[RFC4210|RFC 4210]], September 2005.
-[RFC4346]  Dierks, T. and E. Rescorla, "The Transport Layer Security          (TLS) Protocol Version 1.1", [[RFC4346|RFC 4346]], April 2006.
-[RFC4648]  Josefsson, S., "The Base16, Base32, and Base64 Data          Encodings", [[RFC4648|RFC 4648]], October 2006.
-[RFC5077]  Salowey, J., Zhou, H., Eronen, P., and H. Tschofenig,          "Transport Layer Security (TLS) Session Resumption without          Server-Side State", [[RFC5077|RFC 5077]], January 2008.
-[RFC5246]  Dierks, T. and E. Rescorla, "The Transport Layer Security          (TLS) Protocol Version 1.2", [[RFC5246|RFC 5246]], August 2008.
-[RFC5272]  Schaad, J. and M. Myers, "Certificate Management over CMS          (CMC)", [[RFC5272|RFC 5272]], June 2008.
-[RFC5273]  Schaad, J. and M. Myers, "Certificate Management over CMS          (CMC): Transport Protocols", [[RFC5273|RFC 5273]], June 2008.
-[RFC5274]  Schaad, J. and M. Myers, "Certificate Management Messages          over CMS (CMC): Compliance Requirements", [[RFC5274|RFC 5274]], 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", [[RFC5280|RFC 5280]], May 2008.
-[RFC5652]  Housley, R., "Cryptographic Message Syntax (CMS)", STD 70,          [[RFC5652|RFC 5652]], September 2009.
-[RFC5746]  Rescorla, E., Ray, M., Dispensa, S., and N. Oskov,          "Transport Layer Security (TLS) Renegotiation Indication          Extension", [[RFC5746|RFC 5746]], February 2010.
-[RFC5751]  Ramsdell, B. and S. Turner, "Secure/Multipurpose Internet          Mail Extensions (S/MIME) Version 3.2 Message          Specification", [[RFC5751|RFC 5751]], January 2010.
-[RFC5785]  Nottingham, M. and E. Hammer-Lahav, "Defining Well-Known          Uniform Resource Identifiers (URIs)", [[RFC5785|RFC 5785]], April          2010.
-[RFC5929]  Altman, J., Williams, N., and L. Zhu, "Channel Bindings          for TLS", [[RFC5929|RFC 5929]], July 2010.
-[RFC5958]  Turner, S., "Asymmetric Key Packages", [[RFC5958|RFC 5958]], August          2010.
-[RFC6066]  Eastlake, D., "Transport Layer Security (TLS) Extensions:          Extension Definitions", [[RFC6066|RFC 6066]], January 2011.
-[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)", [[RFC6125|RFC 6125]], March 2011.
-[RFC6402]  Schaad, J., "Certificate Management over CMS (CMC)          Updates", [[RFC6402|RFC 6402]], November 2011.
-[RFC6454]  Barth, A., "The Web Origin Concept", [[RFC6454|RFC 6454]], December          2011.
-[RFC6838]  Freed, N., Klensin, J., and T. Hansen, "Media Type          Specifications and Registration Procedures", [[BCP13|BCP 13]], RFC          6838, January 2013.
-[X.680]    ITU-T Recommendation X.680 (2008) | ISO/IEC 8824-1:2008,          "Abstract Syntax Notation One (ASN.1): Specification of          basic notation", November 2008,          <http://www.itu.int/rec/T-REC-X.680-200811-I/en>.
-[X.690]    ITU-T Recommendation X.690 (2008) | ISO/IEC 8825-1:2008,          "ASN.1 encoding rules: Specification of Basic Encoding          Rules (BER), Canonical Encoding Rules (CER) and          Distinguished Encoding Rules (DER)", November 2008,          <http://www.itu.int/rec/T-REC-X.690-200811-I/en>.
-=== Informative References ===
-[IDevID]  IEEE Standards Association, "IEEE 802.1AR Secure Device          Identifier", December 2009, <http://standards.ieee.org/          findstds/standard/802.1AR-2009.html>.
-[RFC2307]  Howard, L., "An Approach for Using LDAP as a Network          Information Service", [[RFC2307|RFC 2307]], March 1998.
-[RFC2818]  Rescorla, E., "HTTP Over TLS", [[RFC2818|RFC 2818]], May 2000.
-[RFC2985]  Nystrom, M. and B. Kaliski, "PKCS #9: Selected Object          Classes and Attribute Types Version 2.0", [[RFC2985|RFC 2985]],          November 2000.
-[RFC3394]  Schaad, J. and R. Housley, "Advanced Encryption Standard          (AES) Key Wrap Algorithm", [[RFC3394|RFC 3394]], September 2002.
-[RFC5054]  Taylor, D., Wu, T., Mavrogiannopoulos, N., and T. Perrin,          "Using the Secure Remote Password (SRP) Protocol for TLS          Authentication", [[RFC5054|RFC 5054]], November 2007.
-[RFC5967]  Turner, S., "The application/pkcs10 Media Type", [[RFC5967|RFC 5967]],          August 2010.
-[RFC6403]  Zieglar, L., Turner, S., and M. Peck, "Suite B Profile of          Certificate Management over CMS", [[RFC6403|RFC 6403]], November 2011.
-[SHS]      National Institute of Standards and Technology, "Secure          Hash Standard (SHS)", Federal Information Processing          Standard Publication 180-4, March 2012,          <http://csrc.nist.gov/publications/fips/          fips180-4/fips-180-4.pdf>.
-[SP-800-57-Part-1]          National Institute of Standards and Technology,          "Recommendation for Key Management - Part 1: General          (Revision 3)", July 2012,          <http://csrc.nist.gov/publications/nistpubs/800-57/          sp800-57_part1_rev3_general.pdf>.
-Appendix A.  Operational Scenario Example Messages
-(Informative)
-This section expands on the Operational Scenario Overviews byproviding 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 optionalserver-generated "certificate request" and can instead proceed withthe HTTP GET request:
-GET /.well-known/est/cacerts HTTP/1.1User-Agent: curl/7.22.0 (i686-pc-linux-gnu) libcurl/7.22.0 OpenSSL/1.0.1 zlib/1.2.3.4 libidn/1.23 librtmp/2.3Host: 192.0.2.1:8085Accept: */*
-In response, the server provides the current CA certificates:
-HTTP/1.1 200 OKStatus: 200 OKContent-Type: application/pkcs7-mimeContent-Transfer-Encoding: base64Content-Length: 4246
-MIIMOQYJKoZIhvcNAQcCoIIMKjCCDCYCAQExADALBgkqhkiG9w0BBwGgggwMMIIC+zCCAeOgAwIBAgIJAJpY3nUZO3qcMA0GCSqGSIb3DQEBBQUAMBsxGTAXBgNVBAMTEGVzdEV4YW1wbGVDQSBPd08wHhcNMTMwNTA5MDM1MzMxWhcNMTQwNTA5MDM1MzMxWjAbMRkwFwYDVQQDExBlc3RFeGFtcGxlQ0EgT3dPMIIBIjANBgkqhkiG9w0BAQEFAAOCAQ8AMIIBCgKCAQEAwDqpiHopaICubpRqbpEN7LqTIqWELFIA9qDDheHIKuyOHW/ZAP7Rl4S5ZU6gaLW/ksseBUxdmox3KNyvtyjehIofTu28eZWhgy6/LCEGWR3PK+fgPBA0l0JfJR/8oeXZa70oLVQc3hI4kCeqjFMs+biYH0vp/RluhftyZ5kzQyH1EGsRkw1/qUKkTZ8PCF8VFlYfqmUoqsaRTyZbjII4J+Y6/jEG+p7QreW9zcz4sPe83c/uhwMLOWQkZtKsQtgo5CpfYMjuAmk4Q2joQq2vcxlc+WNKHf+wbrDb11ORZril9ISlI94oumcRz3uBG1Yg7z83hdDfasmdfbp8gOSNFQIDAQABo0IwQDAPBgNVHRMBAf8EBTADAQH/MB0GA1UdDgQWBBQITTKxMqATXrfc4ffpCIbt6Gsz0jAOBgNVHQ8BAf8EBAMCAQYwDQYJKoZIhvcNAQEFBQADggEBACPnQPu5WReUGuCMS0nBOGa2tXh6uZP4mS3J1qEfDePam/IiU9ssyYdcDwhVvKMoP4gI/yu4XFqhdpIoy/PyD4T15MT7KADCxXkh5rM1IqMui7FvBKLWYGdy9sjEf90wAkBjHBe/TMO1NNw3uELyONSkHIvoX0pu6aPmm/moIMyGi46niFse1iWlXXldGLkOQsh0e7U+wpBX07QpOr2KB2+Yf+uAKY1SWzEG23bUxXlvcbUMgANDGj5r6z+niKL0VlApip/iCuVEEOcZ91UlmJjVLQWAx6ie+v84oM+pIojiGM0C4XWcVlKKEgcMOsN3S4lvm8Ptpq0GLoIJY8NTD20wggMDMIIB66ADAgECAgEBMA0GCSqGSIb3DQEBBQUAMBsxGTAXBgNVBAMTEGVzdEV4YW1wbGVDQSBPd08wHhcNMTMwNTA5MDM1MzMyWhcNMTQwNTA5MDM1MzMyWjAbMRkwFwYD
-VQQDExBlc3RFeGFtcGxlQ0EgTndPMIIBIjANBgkqhkiG9w0BAQEFAAOCAQ8AMIIBCgKCAQEAnn3rZ3rMJHwf7MD9K4mubxHAvtdnrsQf5OfgtMhRIL4aePNhAdgPyj8CloxOgD3UTV+dQ1ViOzVxPN7acikoOnkIdRpjpOpkyMo+KkvHMQXGnQTbsMAv1qWt9S12DMpo0GOA1e4Ge3ud5YPOTR/q6PvjN51IEwYKksG7CglwZwB+5JbwhYr2D/0ubtGltriRVixPWrvt+wz/ITp5rcjh/8RS3LE8tQy3kTNhJF3Y/esR2sSgOiPNgItoCATysbaINEPr4MemqML4tDpR/aG9y+8Qe7s1LyMFvDletp2mmBykAC/7nOat/pwUlB0sN524D1XAgz8ZKvWrkh+ZaOr3hwIDAQABo1IwUDAOBgNVHQ8BAf8EBAMCBLAwHQYDVR0OBBYEFLHEaeZbowSn2Jejizu/uWqyMkI8MB8GA1UdIwQYMBaAFAhNMrEyoBNet9zh9+kIhu3oazPSMA0GCSqGSIb3DQEBBQUAA4IBAQCLDkL7aLNV6hSOkIqHq+shV9YLO56/tj00vY/jV5skgDHk5d0B+OGortKVuGa57+v0avTrlJns3bNW8NtvzkDEhmd00Ak02aPsi4wRHLFgttUf9HdEHAuTkAESPTU43DiptjkfHhtBMfsFrCkdsxWzCz+prDOMHYfUEkhRVV++1zyGEX6ov1Ap2IU2p3E+ASihL/amxTEQAsbwjUTIR52zoL6nMPzpbKeZi2M0eEBVF8sDueA9Hjo6woLjgJqV0/yc5vC2HAxUOhx0cWTYGcRBgL/yOyQLKiY5TKBH951OjQ4vhF2HmcoO7DkcNLYJOge16ssx4ogBHul20VgFXJJjMIIDAzCCAeugAwIBAgIBAjANBgkqhkiG9w0BAQUFADAbMRkwFwYDVQQDExBlc3RFeGFtcGxlQ0EgTndOMB4XDTEzMDUwOTAzNTMzMloXDTE0MDUwOTAzNTMzMlowGzEZMBcGA1UEAxMQZXN0RXhhbXBsZUNBIE93TjCCASIwDQYJKoZIhvcNAQEBBQADggEPADCCAQoCggEBAMA6qYh6KWiArm6Uam6RDey6kyKlhCxSAPagw4XhyCrsjh1v2QD+0ZeEuWVOoGi1v5LLHgVMXZqMdyjcr7co3oSKH07tvHmVoYMuvywhBlkdzyvn4DwQNJdCXyUf/KHl2Wu9KC1UHN4SOJAnqoxTLPm4mB9L6f0ZboX7cmeZM0Mh9RBrEZMNf6lCpE2fDwhfFRZWH6plKKrGkU8mW4yCOCfmOv4xBvqe0K3lvc3M+LD3vN3P7ocDCzlkJGbSrELYKOQqX2DI7gJpOENo6EKtr3MZXPljSh3/sG6w29dTkWa4pfSEpSPeKLpnEc97gRtWIO8/N4XQ32rJnX26fIDkjRUCAwEAAaNSMFAwDgYDVR0PAQH/BAQDAgSwMB0GA1UdDgQWBBQITTKxMqATXrfc4ffpCIbt6Gsz0jAfBgNVHSMEGDAWgBSxxGnmW6MEp9iXo4s7v7lqsjJCPDANBgkqhkiG9w0BAQUFAAOCAQEALhDaE6MpBINBsJozdbXlijrWxL1CSv8f4GwpUFk3CgZjibt/qW9UoaNR4E58yRopuEhjwFZK2w8YtRqx8IZoFhcoLkpBDfgLLwhoztzbYvOVKQMidjBlkBEVNR5MWdrs7F/AxWuyiZ2+8AnR8GwqEIbCD0A7xIghmWEMh/BVI9C7GLqd6PxKrTAjuDfEpfdWhU/uYKmKcL3XDbSwr30j2EQyaTV/3W0Tn2UfuxdwDQ4ZJs9G+Mw50s7AG6CpISyOIFmX6/bUDpJXGLiLwfJ9C/aum9nylYuGCJ68BuTrCs9567KGfXEXI0mdFFCL7TaVR43kjsg3c43kZ7369MeEZzCCAvswggHjoAMCAQICCQDprp3DmjOyETANBgkqhkiG9w0BAQUFADAbMRkwFwYDVQQDExBlc3RFeGFtcGxlQ0EgTndOMB4XDTEzMDUwOTAzNTMzMloXDTE0MDUwOTAzNTMzMlowGzEZMBcGA1UEAxMQZXN0RXhhbXBsZUNBIE53TjCCASIwDQYJKoZIhvcNAQEBBQADggEPADCCAQoCggEBAJ5962d6zCR8H+zA/SuJrm8RwL7XZ67EH+Tn4LTIUSC+GnjzYQHYD8o/ApaMToA91E1fnUNVYjs1cTze2nIpKDp5CHUaY6TqZMjKPipLxzEFxp0E27DAL9alrfUtdgzKaNBjgNXuBnt7neWDzk0f6uj74zedSBMGCpLBuwoJcGcAfuSW8IWK9g/9Lm7Rpba4kVYsT1q77fsM/yE6ea3I4f/EUtyxPLUMt5EzYSRd2P3rEdrEoDojzYCLaAgE8rG2iDRD6+DHpqjC+LQ6Uf2hvcvvEHu7NS8jBbw5XradppgcpAAv+5zmrf6cFJQdLDeduA9VwIM/GSr1q5IfmWjq94cCAwEAAaNCMEAwDwYDVR0TAQH/BAUwAwEB/zAdBgNVHQ4EFgQUscRp5lujBKfYl6OLO7+5arIyQjwwDgYDVR0PAQH/BAQDAgEGMA0GCSqGSIb3DQEBBQUAA4IBAQBCz/CWdYvnGM/SdCdEiom5A1VxaW8nKgCWg/EyWtAIiaHQuViB+jTUAE9lona2MbJoFHW8U5e89dCP0rJpA9UYXXhWvFQzd5ZWpms4wUYt1j3gqqd36KorJIAuPigVng13yKytxM7cVmxQnh0aux3aEnEyRGAhGalHp0RaKdgPRzUaGtipJTNBkSV5S4kD4yDCPHMNbBu+OcluerwEpbz6GvE7CpXl2jrTBZSqBsFelq0iz4kk9++9CnwZwrVgdzklhRfJ1Z4jNkLruwbQ+o4NvBZsXiKxNfn3K2o3SK8AuaEyDWkq18+5rjcfprRO8x4YTW+6mXPqjM0MAGNDEW+1oQAxAA==
-A.2.  CSR Attributes
-The following is an example of a valid /csrattrs exchange.  Duringthis exchange, the EST client authenticates itself using an existingcertificate issued by the CA for which the EST server providesservices.
-The initial TLS handshake is identical to the enrollment examplehandshake.  The HTTP GET request:
-GET /.well-known/est/csrattrs HTTP/1.1User-Agent: curl/7.22.0 (i686-pc-linux-gnu) libcurl/7.22.0 OpenSSL/1.0.1 zlib/1.2.3.4 libidn/1.23 librtmp/2.3Host: 192.0.2.1:8085Accept: */*
-In response, the server provides suggested attributes that areappropriate for the authenticated client.  In this example, the ESTserver also includes two example attributes that the client wouldignore unless the attribute type is known to the client:
-HTTP/1.1 200 OKStatus: 200 OKContent-Type: application/csrattrsContent-Transfer-Encoding: base64Content-Length: 171
-MHwGBysGAQEBARYwIgYDiDcBMRsTGVBhcnNlIFNFVCBhcyAyLjk5OS4xIGRhdGEGCSqGSIb3DQEJBzAsBgOINwIxJQYDiDcDBgOINwQTGVBhcnNlIFNFVCBhcyAyLjk5OS4yIGRhdGEGCSskAwMCCAEBCwYJYIZIAWUDBAIC
-A.3.  Enroll/Re-enroll
-The following is an example of a valid /simpleenroll exchange.  Thedata messages for /simplereenroll are similar.
-During this exchange, the EST client uses an out-of-band distributedusername/password to authenticate itself to the EST server.  This isthe normal HTTP WWW-Authenticate behavior and is included here forinformative purposes.  When an existing TLS client certificate isused, the server might skip requesting the HTTP WWW-Authenticateheader, such as during a /simplereenroll operation.
-During the initial TLS handshake, the client can ignore the optionalserver-generated "certificate request" and can instead proceed withthe HTTP POST request.  In response to the initial HTTP POST attempt,
-the server requests WWW-Authenticate from the client (this mightoccur even if the client used a client certificate, as detailed inthe normative text above):
-HTTP/1.1 401 UnauthorizedContent-Length: 0WWW-Authenticate: Digest qop="auth", realm="estrealm",nonce="1368141352"
-In the subsequent HTTP POST, the username/password is included, alongwith the complete application/pkcs10 content:
-POST /.well-known/est/simpleenroll HTTP/1.1Authorization: Digest username="estuser", realm="estrealm", nonce="1368141352", uri="/.well-known/est/simpleenroll", cnonce="MTYwMzg3", nc=00000001, qop="auth", response="144cc27f96046f1d70eb16db20f75f22"Host: 192.0.2.1:8085Accept: */*Content-Type: application/pkcs10Content-Transfer-Encoding: base64Content-Length: 882
-MIIChTCCAW0CAQAwHzEdMBsGA1UEAxMUZGVtb3N0ZXA0IDEzNjgxNDEzNTIwggEiMA0GCSqGSIb3DQEBAQUAA4IBDwAwggEKAoIBAQClNp+kdz+Nj8XpEp9kaumWxDZ3eFYJpQKz9ddD5e5OzUeCm103ZIXQIxc0eVtMCatnRr3dnZRCAxGjwbqoB3eKt29/XSQffVv+odbyw0WdkQOIbntCQry8YdcBZ+8LjI/N7M2krmjmoSLmLwU2V4aNKf0YMLR5Krmah3Ik31jmYCSvwTnv6mx6pr2pTJ82JavhTEIIt/fAYq1RYhkM1CXoBL+yhEoDanN7TzC94skfS3VV+f53J9SkUxTYcy1Rw0k3VXfxWwy+cSKEPREl7I6k0YeKtDEVAgBIEYM/L1S69RXTLujirwnqSRjOquzkAkD31BE961KZCxeYGrhxaR4PAgMBAAGgITAfBgkqhkiG9w0BCQcxEhMQK3JyQ2lyLzcrRVl1NTBUNDANBgkqhkiG9w0BAQUFAAOCAQEARBv0AJeXaHpl1MFIdzWqoi1dOCf6U+qaYWcBzpLADvJrPK1qx5pqwXM830A1O+7RvrFv+nyd6VF2rl/MrNp+IsKuA9LYWIBjVe/LXoBO8dB/KxrYl16cVUS+Yydi1m/a+DaftYSRGolMLtWeiqbc2SDBr2kHXW1TR130hIcpwmr29kC2Kzur5thsuj276FGL1vPu0dRfGQfx4WWa9uAHBgz6tW37CepZsrUKe/0pfVhr2oHxApYhcHGBQDQHVTFVjHccdUjAXicrtbsVhU5o1lPv7f4lEApv3SBQmJcaq5O832BzHw7nPyMFcM15E9gtUVee5C62bVwuk/tbnGsbwQ==
-The EST server uses the username/password to performauthentication/authorization and responds with the issuedcertificate:
-HTTP/1.1 200 OKStatus: 200 OKContent-Type: application/pkcs7-mime; smime-type=certs-onlyContent-Transfer-Encoding: base64Content-Length: 1122
-MIIDOAYJKoZIhvcNAQcCoIIDKTCCAyUCAQExADALBgkqhkiG9w0BBwGgggMLMIIDBzCCAe+gAwIBAgIBFTANBgkqhkiG9w0BAQUFADAbMRkwFwYDVQQDExBlc3RFeGFtcGxlQ0EgTndOMB4XDTEzMDUwOTIzMTU1M1oXDTE0MDUwOTIzMTU1M1owHzEdMBsGA1UEAxMUZGVtb3N0ZXA0IDEzNjgxNDEzNTIwggEiMA0GCSqGSIb3DQEBAQUAA4IBDwAwggEKAoIBAQClNp+kdz+Nj8XpEp9kaumWxDZ3eFYJpQKz9ddD5e5OzUeCm103ZIXQIxc0eVtMCatnRr3dnZRCAxGjwbqoB3eKt29/XSQffVv+odbyw0WdkQOIbntCQry8YdcBZ+8LjI/N7M2krmjmoSLmLwU2V4aNKf0YMLR5Krmah3Ik31jmYCSvwTnv6mx6pr2pTJ82JavhTEIIt/fAYq1RYhkM1CXoBL+yhEoDanN7TzC94skfS3VV+f53J9SkUxTYcy1Rw0k3VXfxWwy+cSKEPREl7I6k0YeKtDEVAgBIEYM/L1S69RXTLujirwnqSRjOquzkAkD31BE961KZCxeYGrhxaR4PAgMBAAGjUjBQMA4GA1UdDwEB/wQEAwIEsDAdBgNVHQ4EFgQU/qDdB6ii6icQ8wGMXvy1jfE4xtUwHwYDVR0jBBgwFoAUscRp5lujBKfYl6OLO7+5arIyQjwwDQYJKoZIhvcNAQEFBQADggEBACmxg1hvL6+7a+lFTARoxainBx5gxdZ9omSb0L+qL+4PDvg/+KHzKsDnMCrcU6M4YP5n0EDKmGa64lY8fbET4tt7juJg6ixb95/760Th0vuctwkGr6+D6ETTfqyHnrbhX3lAhnB+0Ja7o1gv4CWxh1I8aRaTXdpOHORvN0SMXdcrlCys2vrtOl+LjR2a3kajJO6eQ5leOdzFQlZfOPhaLWen0e2BLNJI0vsC2Fa+2LMCnfC38XfGALa5A8e7fNHXWZBjXZLBCza3rEs9Mlh2CjA/ocSC/WxmMvd+Eqnt/FpggRy+F8IZSRvBaRUCtGE1lgDmu6AFUxceR4POrT2xz8ChADEA
+In response, the server provides the current CA certificates:
+HTTP/1.1 200 OK
+Status: 200 OK
+Content-Type: application/pkcs7-mime
+Content-Transfer-Encoding: base64
+Content-Length: 4246
+MIIMOQYJKoZIhvcNAQcCoIIMKjCCDCYCAQExADALBgkqhkiG9w0BBwGgggwMMIIC
++zCCAeOgAwIBAgIJAJpY3nUZO3qcMA0GCSqGSIb3DQEBBQUAMBsxGTAXBgNVBAMT
+EGVzdEV4YW1wbGVDQSBPd08wHhcNMTMwNTA5MDM1MzMxWhcNMTQwNTA5MDM1MzMx
+WjAbMRkwFwYDVQQDExBlc3RFeGFtcGxlQ0EgT3dPMIIBIjANBgkqhkiG9w0BAQEF
+AAOCAQ8AMIIBCgKCAQEAwDqpiHopaICubpRqbpEN7LqTIqWELFIA9qDDheHIKuyO
+HW/ZAP7Rl4S5ZU6gaLW/ksseBUxdmox3KNyvtyjehIofTu28eZWhgy6/LCEGWR3P
+K+fgPBA0l0JfJR/8oeXZa70oLVQc3hI4kCeqjFMs+biYH0vp/RluhftyZ5kzQyH1
+EGsRkw1/qUKkTZ8PCF8VFlYfqmUoqsaRTyZbjII4J+Y6/jEG+p7QreW9zcz4sPe8
+c/uhwMLOWQkZtKsQtgo5CpfYMjuAmk4Q2joQq2vcxlc+WNKHf+wbrDb11ORZril
+ISlI94oumcRz3uBG1Yg7z83hdDfasmdfbp8gOSNFQIDAQABo0IwQDAPBgNVHRMB
+Af8EBTADAQH/MB0GA1UdDgQWBBQITTKxMqATXrfc4ffpCIbt6Gsz0jAOBgNVHQ8B
+Af8EBAMCAQYwDQYJKoZIhvcNAQEFBQADggEBACPnQPu5WReUGuCMS0nBOGa2tXh6
+uZP4mS3J1qEfDePam/IiU9ssyYdcDwhVvKMoP4gI/yu4XFqhdpIoy/PyD4T15MT7
+KADCxXkh5rM1IqMui7FvBKLWYGdy9sjEf90wAkBjHBe/TMO1NNw3uELyONSkHIvo
+X0pu6aPmm/moIMyGi46niFse1iWlXXldGLkOQsh0e7U+wpBX07QpOr2KB2+Yf+uA
+KY1SWzEG23bUxXlvcbUMgANDGj5r6z+niKL0VlApip/iCuVEEOcZ91UlmJjVLQWA
+x6ie+v84oM+pIojiGM0C4XWcVlKKEgcMOsN3S4lvm8Ptpq0GLoIJY8NTD20wggMD
+MIIB66ADAgECAgEBMA0GCSqGSIb3DQEBBQUAMBsxGTAXBgNVBAMTEGVzdEV4YW1w
+bGVDQSBPd08wHhcNMTMwNTA5MDM1MzMyWhcNMTQwNTA5MDM1MzMyWjAbMRkwFwYD
+VQQDExBlc3RFeGFtcGxlQ0EgTndPMIIBIjANBgkqhkiG9w0BAQEFAAOCAQ8AMIIB
+CgKCAQEAnn3rZ3rMJHwf7MD9K4mubxHAvtdnrsQf5OfgtMhRIL4aePNhAdgPyj8C
+loxOgD3UTV+dQ1ViOzVxPN7acikoOnkIdRpjpOpkyMo+KkvHMQXGnQTbsMAv1qWt
+S12DMpo0GOA1e4Ge3ud5YPOTR/q6PvjN51IEwYKksG7CglwZwB+5JbwhYr2D/0u
+btGltriRVixPWrvt+wz/ITp5rcjh/8RS3LE8tQy3kTNhJF3Y/esR2sSgOiPNgIto
+CATysbaINEPr4MemqML4tDpR/aG9y+8Qe7s1LyMFvDletp2mmBykAC/7nOat/pwU
+lB0sN524D1XAgz8ZKvWrkh+ZaOr3hwIDAQABo1IwUDAOBgNVHQ8BAf8EBAMCBLAw
+HQYDVR0OBBYEFLHEaeZbowSn2Jejizu/uWqyMkI8MB8GA1UdIwQYMBaAFAhNMrEy
+oBNet9zh9+kIhu3oazPSMA0GCSqGSIb3DQEBBQUAA4IBAQCLDkL7aLNV6hSOkIqH
+q+shV9YLO56/tj00vY/jV5skgDHk5d0B+OGortKVuGa57+v0avTrlJns3bNW8Ntv
+zkDEhmd00Ak02aPsi4wRHLFgttUf9HdEHAuTkAESPTU43DiptjkfHhtBMfsFrCkd
+sxWzCz+prDOMHYfUEkhRVV++1zyGEX6ov1Ap2IU2p3E+ASihL/amxTEQAsbwjUTI
+R52zoL6nMPzpbKeZi2M0eEBVF8sDueA9Hjo6woLjgJqV0/yc5vC2HAxUOhx0cWTY
+GcRBgL/yOyQLKiY5TKBH951OjQ4vhF2HmcoO7DkcNLYJOge16ssx4ogBHul20VgF
+XJJjMIIDAzCCAeugAwIBAgIBAjANBgkqhkiG9w0BAQUFADAbMRkwFwYDVQQDExBl
+c3RFeGFtcGxlQ0EgTndOMB4XDTEzMDUwOTAzNTMzMloXDTE0MDUwOTAzNTMzMlow
+GzEZMBcGA1UEAxMQZXN0RXhhbXBsZUNBIE93TjCCASIwDQYJKoZIhvcNAQEBBQAD
+ggEPADCCAQoCggEBAMA6qYh6KWiArm6Uam6RDey6kyKlhCxSAPagw4XhyCrsjh1v
+QD+0ZeEuWVOoGi1v5LLHgVMXZqMdyjcr7co3oSKH07tvHmVoYMuvywhBlkdzyvn
+DwQNJdCXyUf/KHl2Wu9KC1UHN4SOJAnqoxTLPm4mB9L6f0ZboX7cmeZM0Mh9RBr
+EZMNf6lCpE2fDwhfFRZWH6plKKrGkU8mW4yCOCfmOv4xBvqe0K3lvc3M+LD3vN3P
+ocDCzlkJGbSrELYKOQqX2DI7gJpOENo6EKtr3MZXPljSh3/sG6w29dTkWa4pfSE
+pSPeKLpnEc97gRtWIO8/N4XQ32rJnX26fIDkjRUCAwEAAaNSMFAwDgYDVR0PAQH/
+BAQDAgSwMB0GA1UdDgQWBBQITTKxMqATXrfc4ffpCIbt6Gsz0jAfBgNVHSMEGDAW
+gBSxxGnmW6MEp9iXo4s7v7lqsjJCPDANBgkqhkiG9w0BAQUFAAOCAQEALhDaE6Mp
+BINBsJozdbXlijrWxL1CSv8f4GwpUFk3CgZjibt/qW9UoaNR4E58yRopuEhjwFZK
+w8YtRqx8IZoFhcoLkpBDfgLLwhoztzbYvOVKQMidjBlkBEVNR5MWdrs7F/AxWuy
+iZ2+8AnR8GwqEIbCD0A7xIghmWEMh/BVI9C7GLqd6PxKrTAjuDfEpfdWhU/uYKmK
+cL3XDbSwr30j2EQyaTV/3W0Tn2UfuxdwDQ4ZJs9G+Mw50s7AG6CpISyOIFmX6/bU
+DpJXGLiLwfJ9C/aum9nylYuGCJ68BuTrCs9567KGfXEXI0mdFFCL7TaVR43kjsg3
+c43kZ7369MeEZzCCAvswggHjoAMCAQICCQDprp3DmjOyETANBgkqhkiG9w0BAQUF
+ADAbMRkwFwYDVQQDExBlc3RFeGFtcGxlQ0EgTndOMB4XDTEzMDUwOTAzNTMzMloX
+DTE0MDUwOTAzNTMzMlowGzEZMBcGA1UEAxMQZXN0RXhhbXBsZUNBIE53TjCCASIw
+DQYJKoZIhvcNAQEBBQADggEPADCCAQoCggEBAJ5962d6zCR8H+zA/SuJrm8RwL7X
+Z67EH+Tn4LTIUSC+GnjzYQHYD8o/ApaMToA91E1fnUNVYjs1cTze2nIpKDp5CHUa
+Y6TqZMjKPipLxzEFxp0E27DAL9alrfUtdgzKaNBjgNXuBnt7neWDzk0f6uj74zed
+SBMGCpLBuwoJcGcAfuSW8IWK9g/9Lm7Rpba4kVYsT1q77fsM/yE6ea3I4f/EUtyx
+PLUMt5EzYSRd2P3rEdrEoDojzYCLaAgE8rG2iDRD6+DHpqjC+LQ6Uf2hvcvvEHu7
+NS8jBbw5XradppgcpAAv+5zmrf6cFJQdLDeduA9VwIM/GSr1q5IfmWjq94cCAwEA
+AaNCMEAwDwYDVR0TAQH/BAUwAwEB/zAdBgNVHQ4EFgQUscRp5lujBKfYl6OLO7+5
+arIyQjwwDgYDVR0PAQH/BAQDAgEGMA0GCSqGSIb3DQEBBQUAA4IBAQBCz/CWdYvn
+GM/SdCdEiom5A1VxaW8nKgCWg/EyWtAIiaHQuViB+jTUAE9lona2MbJoFHW8U5e8
+dCP0rJpA9UYXXhWvFQzd5ZWpms4wUYt1j3gqqd36KorJIAuPigVng13yKytxM7c
+VmxQnh0aux3aEnEyRGAhGalHp0RaKdgPRzUaGtipJTNBkSV5S4kD4yDCPHMNbBu+
+OcluerwEpbz6GvE7CpXl2jrTBZSqBsFelq0iz4kk9++9CnwZwrVgdzklhRfJ1Z4j
+NkLruwbQ+o4NvBZsXiKxNfn3K2o3SK8AuaEyDWkq18+5rjcfprRO8x4YTW+6mXPq
+jM0MAGNDEW+1oQAxAA==
+A.2.  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 for which the EST server provides
+services.
+The initial TLS handshake is identical to the enrollment example
+handshake.  The HTTP GET request:
+GET /.well-known/est/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: 192.0.2.1:8085
+Accept: */*
+In response, the server provides suggested attributes that are
+appropriate for the authenticated client.  In this example, the EST
+server also includes two example attributes that the client would
+ignore unless the attribute type is known to the client:
+HTTP/1.1 200 OK
+Status: 200 OK
+Content-Type: application/csrattrs
+Content-Transfer-Encoding: base64
+Content-Length: 171
+MHwGBysGAQEBARYwIgYDiDcBMRsTGVBhcnNlIFNFVCBhcyAyLjk5OS4xIGRhdGEG
+CSqGSIb3DQEJBzAsBgOINwIxJQYDiDcDBgOINwQTGVBhcnNlIFNFVCBhcyAyLjk5
+OS4yIGRhdGEGCSskAwMCCAEBCwYJYIZIAWUDBAIC
+A.3.  Enroll/Re-enroll
+The following is an example of a valid /simpleenroll exchange.  The
+data messages for /simplereenroll are similar.
+During this exchange, the EST client uses an out-of-band distributed
+username/password to authenticate itself to the EST server.  This is
+the normal HTTP WWW-Authenticate behavior and is included here for
+informative purposes.  When an existing TLS client certificate is
+used, the server might skip requesting the HTTP WWW-Authenticate
+header, such as during a /simplereenroll operation.
+During the initial TLS handshake, the client can ignore the optional
+server-generated "certificate request" and can instead proceed with
+the HTTP POST request.  In response to the initial HTTP POST attempt,
+the server requests WWW-Authenticate from the client (this might
+occur even if the client used a client certificate, as detailed in
+the normative text above):
+HTTP/1.1 401 Unauthorized
+Content-Length: 0
+WWW-Authenticate: Digest qop="auth", realm="estrealm",
+nonce="1368141352"
+In the subsequent HTTP POST, the username/password is included, along
+with the complete application/pkcs10 content:
+POST /.well-known/est/simpleenroll HTTP/1.1
+Authorization: Digest username="estuser", realm="estrealm", nonc
+e="1368141352", uri="/.well-known/est/simpleenroll", cnonce="M
+TYwMzg3", nc=00000001, qop="auth", response="144cc27f96046f1d70e
+b16db20f75f22"
+Host: 192.0.2.1:8085
+Accept: */*
+Content-Type: application/pkcs10
+Content-Transfer-Encoding: base64
+Content-Length: 882
+MIIChTCCAW0CAQAwHzEdMBsGA1UEAxMUZGVtb3N0ZXA0IDEzNjgxNDEzNTIwggEi
+MA0GCSqGSIb3DQEBAQUAA4IBDwAwggEKAoIBAQClNp+kdz+Nj8XpEp9kaumWxDZ3
+eFYJpQKz9ddD5e5OzUeCm103ZIXQIxc0eVtMCatnRr3dnZRCAxGjwbqoB3eKt29/
+XSQffVv+odbyw0WdkQOIbntCQry8YdcBZ+8LjI/N7M2krmjmoSLmLwU2V4aNKf0Y
+MLR5Krmah3Ik31jmYCSvwTnv6mx6pr2pTJ82JavhTEIIt/fAYq1RYhkM1CXoBL+y
+hEoDanN7TzC94skfS3VV+f53J9SkUxTYcy1Rw0k3VXfxWwy+cSKEPREl7I6k0YeK
+tDEVAgBIEYM/L1S69RXTLujirwnqSRjOquzkAkD31BE961KZCxeYGrhxaR4PAgMB
+AAGgITAfBgkqhkiG9w0BCQcxEhMQK3JyQ2lyLzcrRVl1NTBUNDANBgkqhkiG9w0B
+AQUFAAOCAQEARBv0AJeXaHpl1MFIdzWqoi1dOCf6U+qaYWcBzpLADvJrPK1qx5pq
+wXM830A1O+7RvrFv+nyd6VF2rl/MrNp+IsKuA9LYWIBjVe/LXoBO8dB/KxrYl16c
+VUS+Yydi1m/a+DaftYSRGolMLtWeiqbc2SDBr2kHXW1TR130hIcpwmr29kC2Kzur
+thsuj276FGL1vPu0dRfGQfx4WWa9uAHBgz6tW37CepZsrUKe/0pfVhr2oHxApYh
+cHGBQDQHVTFVjHccdUjAXicrtbsVhU5o1lPv7f4lEApv3SBQmJcaq5O832BzHw7n
+PyMFcM15E9gtUVee5C62bVwuk/tbnGsbwQ==
+The EST server uses the username/password to perform
+authentication/authorization and responds with the issued
+certificate:
+HTTP/1.1 200 OK
+Status: 200 OK
+Content-Type: application/pkcs7-mime; smime-type=certs-only
+Content-Transfer-Encoding: base64
+Content-Length: 1122
+MIIDOAYJKoZIhvcNAQcCoIIDKTCCAyUCAQExADALBgkqhkiG9w0BBwGgggMLMIID
+BzCCAe+gAwIBAgIBFTANBgkqhkiG9w0BAQUFADAbMRkwFwYDVQQDExBlc3RFeGFt
+cGxlQ0EgTndOMB4XDTEzMDUwOTIzMTU1M1oXDTE0MDUwOTIzMTU1M1owHzEdMBsG
+A1UEAxMUZGVtb3N0ZXA0IDEzNjgxNDEzNTIwggEiMA0GCSqGSIb3DQEBAQUAA4IB
+DwAwggEKAoIBAQClNp+kdz+Nj8XpEp9kaumWxDZ3eFYJpQKz9ddD5e5OzUeCm103
+ZIXQIxc0eVtMCatnRr3dnZRCAxGjwbqoB3eKt29/XSQffVv+odbyw0WdkQOIbntC
+Qry8YdcBZ+8LjI/N7M2krmjmoSLmLwU2V4aNKf0YMLR5Krmah3Ik31jmYCSvwTnv
+mx6pr2pTJ82JavhTEIIt/fAYq1RYhkM1CXoBL+yhEoDanN7TzC94skfS3VV+f53
+J9SkUxTYcy1Rw0k3VXfxWwy+cSKEPREl7I6k0YeKtDEVAgBIEYM/L1S69RXTLuji
+rwnqSRjOquzkAkD31BE961KZCxeYGrhxaR4PAgMBAAGjUjBQMA4GA1UdDwEB/wQE
+AwIEsDAdBgNVHQ4EFgQU/qDdB6ii6icQ8wGMXvy1jfE4xtUwHwYDVR0jBBgwFoAU
+scRp5lujBKfYl6OLO7+5arIyQjwwDQYJKoZIhvcNAQEFBQADggEBACmxg1hvL6+7
+a+lFTARoxainBx5gxdZ9omSb0L+qL+4PDvg/+KHzKsDnMCrcU6M4YP5n0EDKmGa6
+lY8fbET4tt7juJg6ixb95/760Th0vuctwkGr6+D6ETTfqyHnrbhX3lAhnB+0Ja7
+o1gv4CWxh1I8aRaTXdpOHORvN0SMXdcrlCys2vrtOl+LjR2a3kajJO6eQ5leOdzF
+QlZfOPhaLWen0e2BLNJI0vsC2Fa+2LMCnfC38XfGALa5A8e7fNHXWZBjXZLBCza3
+rEs9Mlh2CjA/ocSC/WxmMvd+Eqnt/FpggRy+F8IZSRvBaRUCtGE1lgDmu6AFUxce
+R4POrT2xz8ChADEA
 A.4.  Server Key Generation
-The following is an example of a valid /serverkeygen exchange.During this exchange, the EST client authenticates itself using anexisting certificate issued by the CA the EST server providesservices for.
-The initial TLS handshake is identical to the enrollment examplehandshake.  An example HTTP POSTed message is:
-POST /.well-known/est/serverkeygen HTTP/1.1Host: 192.0.2.1:8085Accept: */*Expect: 100-continueContent-Type: application/pkcs10Content-Transfer-Encoding: base64Content-Length: 963
-MIICwTCCAakCAQAwWzE+MDwGA1UEAxM1c2VydmVyS2V5R2VuIHJlcSBieSBjbGllbnQgaW4gZGVtbyBzdGVwIDEyIDEzNjgxNDE5NTUxGTAXBgNVBAUTEFBJRDpXaWRnZXQgU046MTAwggEiMA0GCSqGSIb3DQEBAQUAA4IBDwAwggEKAoIBAQCvE1/6m4A/3/L32Suyzbf28LM9y8CQfp0aepa7o20BSfluvm8HXR44mlV+wpieM8H5n3Ub3RIoRUun/FllIzK9uV7UrkqJ3Yzmq2NOoTd4C+OPsV/RPTu873dhFrssDk3P4NIphlSSsSIkt5rhz7wYbCqCFR5Aphe/30Jx7D+xBI5Rs8e6vRS8IpuImh71BHiLfhq9AFhz4ZJsOUSVpUmqUogFsM7SOQ6XI4dl+djhpjT+YTJ6hQ2PXrqdch3KsTQ8c6aKs+e25QJxh7O8JHVlPHo4YIxXtAYSutcbbTN5TXWFCWSrWDJ+zuMmk2yU+dio1oW7YR7VftAvazJ3laQbAgMBAAGgITAfBgkqhkiG9w0BCQcxEhMQZEZzQVhtSm5qb2tCdER2cjANBgkqhkiG9w0BAQUFAAOCAQEAR+I0EQB+hSjrLCAjnVH6bZdHUNGszIdwx1iuL4n+0XK3SfEzeOMkC4T74yFGKj3redS1Ht9atYUPb0D1Qi9Jf9Co8eLblo1l19A6GaS798ofxIF0Pl0Dr6/GqjheqJEIbcDTAJq+kvDihyQ4GQnhosygIZHvKppQlebAgvp2RJSnMroPCe6RgTU9E2fmI9rin/9PyXeWFF1namp+lYbTGwjv1aE1ikhjCLlHveHhCdgOExPw+fqhKhHjp+0ZKBlo2bC3pqRWvDTiZuwt9UpFFfGtuxvpTp44oS/jM/965hWIw/5dshY/wQjIfYs07bbq2ERbpJiw9bAQY34gyoVmEQ==
+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.  An example HTTP POSTed message is:
+POST /.well-known/est/serverkeygen HTTP/1.1
+Host: 192.0.2.1:8085
+Accept: */*
+Expect: 100-continue
+Content-Type: application/pkcs10
+Content-Transfer-Encoding: base64
+Content-Length: 963
+MIICwTCCAakCAQAwWzE+MDwGA1UEAxM1c2VydmVyS2V5R2VuIHJlcSBieSBjbGll
+bnQgaW4gZGVtbyBzdGVwIDEyIDEzNjgxNDE5NTUxGTAXBgNVBAUTEFBJRDpXaWRn
+ZXQgU046MTAwggEiMA0GCSqGSIb3DQEBAQUAA4IBDwAwggEKAoIBAQCvE1/6m4A/
+/L32Suyzbf28LM9y8CQfp0aepa7o20BSfluvm8HXR44mlV+wpieM8H5n3Ub3RIo
+RUun/FllIzK9uV7UrkqJ3Yzmq2NOoTd4C+OPsV/RPTu873dhFrssDk3P4NIphlSS
+sSIkt5rhz7wYbCqCFR5Aphe/30Jx7D+xBI5Rs8e6vRS8IpuImh71BHiLfhq9AFhz
+ZJsOUSVpUmqUogFsM7SOQ6XI4dl+djhpjT+YTJ6hQ2PXrqdch3KsTQ8c6aKs+e2
+QJxh7O8JHVlPHo4YIxXtAYSutcbbTN5TXWFCWSrWDJ+zuMmk2yU+dio1oW7YR7V
+ftAvazJ3laQbAgMBAAGgITAfBgkqhkiG9w0BCQcxEhMQZEZzQVhtSm5qb2tCdER2
+cjANBgkqhkiG9w0BAQUFAAOCAQEAR+I0EQB+hSjrLCAjnVH6bZdHUNGszIdwx1iu
+L4n+0XK3SfEzeOMkC4T74yFGKj3redS1Ht9atYUPb0D1Qi9Jf9Co8eLblo1l19A6
+GaS798ofxIF0Pl0Dr6/GqjheqJEIbcDTAJq+kvDihyQ4GQnhosygIZHvKppQlebA
+gvp2RJSnMroPCe6RgTU9E2fmI9rin/9PyXeWFF1namp+lYbTGwjv1aE1ikhjCLlH
+veHhCdgOExPw+fqhKhHjp+0ZKBlo2bC3pqRWvDTiZuwt9UpFFfGtuxvpTp44oS/j
+M/965hWIw/5dshY/wQjIfYs07bbq2ERbpJiw9bAQY34gyoVmEQ==
+Because the DecryptKeyIdentifier attribute is not included in this
+request, the response does not include additional encryption beyond
+the TLS session.  The EST server response is:
+HTTP/1.1 200 OK
+Status: 200 OK
+Content-Type: multipart/mixed ; boundary=estServerExampleBoundary
+Content-Length: 3219
+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
+Content-Transfer-Encoding: base64
+MIIEvgIBADANBgkqhkiG9w0BAQEFAASCBKgwggSkAgEAAoIBAQDPwKtwJ7TjMgA+
+Poj64V909ryql0foP1hU4Yq5y8/bOP5ZTe6ArgVhUye099Ac+dfdwpyP/DESiujU
+F/dS62Vck3UWNbnw+4O38FUp0enLbbjSTud48KpEW6+FzkeuAanPGZMA1wKyrYy9
+rD5tQOOJU/CBVhUrITyYLZNYUe4agbpcR0wMtrRr2E58Mu8wQ80ryk6nkL7COk5Z
+IQdNRxldk7DFvpA85Yn1stumoGRtVLW51iXeTS1LtXwhuUb/j6Lds3vvAiJ2SiZ0
+Y3rxPlnJVyFmR8Mf2TBOjzuFqva/VLD2ayQjgaGEjq2ZWHXelQAOZ6N3lrChojEK
+FGq93yOhAgMBAAECggEBALQ5az/nYjd5x9Y3f7NMUffwl+jRRfMHCMTRx/u4AEAo
+KBYm0hFVZZtxfM+z7xlD8G0Th6gs2hFA6gwcIlUPmiX+UaOLxht0xWaLGgYmcNAm
+BiCDjLBQ7xRQCWtlcK9WCA5+HBWtcEy6244rXxh+IyWd6NT6bXC165AEcX87y/e3
+JFJ7XFNeDP656s2DmxSCci+iDte6SaEm7sJvYGu16qevJeMThcQcC9/rJjXkvpGL
+IKK2px5idad4Pb6+QHpqj3d4oM8djO6wYUvrH8XQLqAaF8Hd5lFWVU57nSYY+H79
+GaNDTfRTUL6AXr7kmMsKVFOJ0JjZExUCVMZtGiqhB6UCgYEA639OtdWLZCzyZFMe
+p7VlRddoz0VAtrU2dxnEb4cWD8Gerg8uNvp8OG84gH+6MbPwz4ZYWKCgDFqyrAlw
+SF02n9Sovh93eoJ5latSbfeYUkLtB8L/HVk5/CBGEsV9MUkdMF0+B43YlhyEDyKW
+fX2+0UeHLFgRrfpSzP2cXduEieMCgYEA4db/SIrwN2+g1Gjo3oE09kd89VGjVRer
+srbcqc7DcPXP6Lw42sx96h4jVWWqHVo3DfwFBdUb1LH2cnVXQjgDUHdNdpl01cf/
+BFYCFINi2qKMqiJYswkhYxZ1BLz/zuQTDbPFL2PgLniKFG2aFLrTS3S/tgeB5QwI
+RPigH3kfI6sCgYAPqsCJyFMlrvfRRNZdQewi4VnPsEPF4/hjpAs1gD8vfSoZWlkw
+vylUd9HCerzgYaA7rixieQ0sxTvtxhL6PXlM2NEBFQbV16hPFL6/IiG4F0u9oHNo
+eG8rHtqKlSjnBn4yoYFm70Dhe7QtbZelcaAoPCH6CUHj2St5B8ZHWDtREQKBgHNp
+wER+XIy4C2UByCANv9csaXulIOdXlXNbaCGPfOm5dWrm5ddLMf33MO9vaSRe+ku3
+Q4nbgsGLwPp1ZQZ+QZNZpMi7W6306yp4GdAJ5Pb+oww/ST0VqW5OB7dILyK4A9S4
+zkiNrf+Rsl8GM/vsDhc9rsuDwqofIAq/VHVBHNzJAoGBAOHQof5L6iGHOHcxLazx
+MGvRTpmzU/PX6Q3QxqpetEGFEDZAaL58L67SSS3fFBnKrVAidF6llC1bAH1aoRa
+fYHUDi45xBoroy0hBwrnTKRxppua4UK75FUH5PPJfR6cCvw5stRkzIevTZHhozkX
+pM7PYH/x4BiBmgQ3bhOqTp4H
+--estServerExampleBoundary
+Content-Type: application/pkcs7-mime; smime-type=certs-only
+Content-Transfer-Encoding: base64
-Because the DecryptKeyIdentifier attribute is not included in thisrequest, the response does not include additional encryption beyondthe TLS session.  The EST server response is:
+MIIDRQYJKoZIhvcNAQcCoIIDNjCCAzICAQExADALBgkqhkiG9w0BBwGgggMYMIID
-HTTP/1.1 200 OKStatus: 200 OKContent-Type: multipart/mixed ; boundary=estServerExampleBoundaryContent-Length: 3219
+FDCCAfygAwIBAgIBFjANBgkqhkiG9w0BAQUFADAbMRkwFwYDVQQDExBlc3RFeGFt
-This is the preamble.  It is to be ignored, though itis a handy place for estServer to include an explanatory note,including contact or support information.--estServerExampleBoundaryContent-Type: application/pkcs8Content-Transfer-Encoding: base64
+cGxlQ0EgTndOMB4XDTEzMDUwOTIzMjU1NloXDTE0MDUwOTIzMjU1NlowLDEqMCgG
-MIIEvgIBADANBgkqhkiG9w0BAQEFAASCBKgwggSkAgEAAoIBAQDPwKtwJ7TjMgA+Poj64V909ryql0foP1hU4Yq5y8/bOP5ZTe6ArgVhUye099Ac+dfdwpyP/DESiujUF/dS62Vck3UWNbnw+4O38FUp0enLbbjSTud48KpEW6+FzkeuAanPGZMA1wKyrYy9rD5tQOOJU/CBVhUrITyYLZNYUe4agbpcR0wMtrRr2E58Mu8wQ80ryk6nkL7COk5ZIQdNRxldk7DFvpA85Yn1stumoGRtVLW51iXeTS1LtXwhuUb/j6Lds3vvAiJ2SiZ0Y3rxPlnJVyFmR8Mf2TBOjzuFqva/VLD2ayQjgaGEjq2ZWHXelQAOZ6N3lrChojEKFGq93yOhAgMBAAECggEBALQ5az/nYjd5x9Y3f7NMUffwl+jRRfMHCMTRx/u4AEAoKBYm0hFVZZtxfM+z7xlD8G0Th6gs2hFA6gwcIlUPmiX+UaOLxht0xWaLGgYmcNAmBiCDjLBQ7xRQCWtlcK9WCA5+HBWtcEy6244rXxh+IyWd6NT6bXC165AEcX87y/e3JFJ7XFNeDP656s2DmxSCci+iDte6SaEm7sJvYGu16qevJeMThcQcC9/rJjXkvpGLIKK2px5idad4Pb6+QHpqj3d4oM8djO6wYUvrH8XQLqAaF8Hd5lFWVU57nSYY+H79GaNDTfRTUL6AXr7kmMsKVFOJ0JjZExUCVMZtGiqhB6UCgYEA639OtdWLZCzyZFMep7VlRddoz0VAtrU2dxnEb4cWD8Gerg8uNvp8OG84gH+6MbPwz4ZYWKCgDFqyrAlwSF02n9Sovh93eoJ5latSbfeYUkLtB8L/HVk5/CBGEsV9MUkdMF0+B43YlhyEDyKWfX2+0UeHLFgRrfpSzP2cXduEieMCgYEA4db/SIrwN2+g1Gjo3oE09kd89VGjVRersrbcqc7DcPXP6Lw42sx96h4jVWWqHVo3DfwFBdUb1LH2cnVXQjgDUHdNdpl01cf/BFYCFINi2qKMqiJYswkhYxZ1BLz/zuQTDbPFL2PgLniKFG2aFLrTS3S/tgeB5QwIRPigH3kfI6sCgYAPqsCJyFMlrvfRRNZdQewi4VnPsEPF4/hjpAs1gD8vfSoZWlkwvylUd9HCerzgYaA7rixieQ0sxTvtxhL6PXlM2NEBFQbV16hPFL6/IiG4F0u9oHNoeG8rHtqKlSjnBn4yoYFm70Dhe7QtbZelcaAoPCH6CUHj2St5B8ZHWDtREQKBgHNpwER+XIy4C2UByCANv9csaXulIOdXlXNbaCGPfOm5dWrm5ddLMf33MO9vaSRe+ku3Q4nbgsGLwPp1ZQZ+QZNZpMi7W6306yp4GdAJ5Pb+oww/ST0VqW5OB7dILyK4A9S4zkiNrf+Rsl8GM/vsDhc9rsuDwqofIAq/VHVBHNzJAoGBAOHQof5L6iGHOHcxLazx4MGvRTpmzU/PX6Q3QxqpetEGFEDZAaL58L67SSS3fFBnKrVAidF6llC1bAH1aoRafYHUDi45xBoroy0hBwrnTKRxppua4UK75FUH5PPJfR6cCvw5stRkzIevTZHhozkXpM7PYH/x4BiBmgQ3bhOqTp4H--estServerExampleBoundaryContent-Type: application/pkcs7-mime; smime-type=certs-onlyContent-Transfer-Encoding: base64
+A1UEAxMhc2VydmVyc2lkZSBrZXkgZ2VuZXJhdGVkIHJlc3BvbnNlMIIBIjANBgkq
+hkiG9w0BAQEFAAOCAQ8AMIIBCgKCAQEAz8CrcCe04zIAPj6I+uFfdPa8qpdH6D9Y
+VOGKucvP2zj+WU3ugK4FYVMntPfQHPnX3cKcj/wxEoro1Bf3UutlXJN1FjW58PuD
+t/BVKdHpy2240k7nePCqRFuvhc5HrgGpzxmTANcCsq2Mvaw+bUDjiVPwgVYVKyE8
+mC2TWFHuGoG6XEdMDLa0a9hOfDLvMEPNK8pOp5C+wjpOWSEHTUcZXZOwxb6QPOWJ
+bLbpqBkbVS1udYl3k0tS7V8IblG/4+i3bN77wIidkomdGN68T5ZyVchZkfDH9kw
+To87har2v1Sw9mskI4GhhI6tmVh13pUADmejd5awoaIxChRqvd8joQIDAQABo1Iw
+UDAOBgNVHQ8BAf8EBAMCBLAwHQYDVR0OBBYEFKeZixu9F+appDX2SS5HaxmV6Jr4
+MB8GA1UdIwQYMBaAFLHEaeZbowSn2Jejizu/uWqyMkI8MA0GCSqGSIb3DQEBBQUA
+A4IBAQBHhLmRAKrnTapqqBObDM9IQDQPuwW+fW1gYwZKlSm/IWIwHEZL1igXhpjj
+rf4xqpIkiJMmkaOeoXA8PFniX0/lZM9FQSM/j89CUf5dMoAqWj8s17xuXu9L/hVe
+XjjXHsL40WuDG6tMPN9vcT8tE3ruor608MKSHFX/NEM6+AaNVSUPTmB33BgYB1Wa
+E7pn3JMN6pjIxsHnF4pKi8qvoTSVVjaCEwUe8Q/fw1yvjoHoYJtyMn4v5Kb3Rt+m
+s8Yie1tcfVQrjQutqr34/IJsKdPziZwi92KZa+1958A6M9O/p5OI0up9ZXKg2DEC
+O9qT0GyYJ6sxAyKiGTOxk6jMddDoQAxAA==
+--estServerExampleBoundary--
+This is the epilogue.  It is also to be ignored.
-MIIDRQYJKoZIhvcNAQcCoIIDNjCCAzICAQExADALBgkqhkiG9w0BBwGgggMYMIIDFDCCAfygAwIBAgIBFjANBgkqhkiG9w0BAQUFADAbMRkwFwYDVQQDExBlc3RFeGFtcGxlQ0EgTndOMB4XDTEzMDUwOTIzMjU1NloXDTE0MDUwOTIzMjU1NlowLDEqMCgGA1UEAxMhc2VydmVyc2lkZSBrZXkgZ2VuZXJhdGVkIHJlc3BvbnNlMIIBIjANBgkqhkiG9w0BAQEFAAOCAQ8AMIIBCgKCAQEAz8CrcCe04zIAPj6I+uFfdPa8qpdH6D9YVOGKucvP2zj+WU3ugK4FYVMntPfQHPnX3cKcj/wxEoro1Bf3UutlXJN1FjW58PuDt/BVKdHpy2240k7nePCqRFuvhc5HrgGpzxmTANcCsq2Mvaw+bUDjiVPwgVYVKyE8mC2TWFHuGoG6XEdMDLa0a9hOfDLvMEPNK8pOp5C+wjpOWSEHTUcZXZOwxb6QPOWJ9bLbpqBkbVS1udYl3k0tS7V8IblG/4+i3bN77wIidkomdGN68T5ZyVchZkfDH9kwTo87har2v1Sw9mskI4GhhI6tmVh13pUADmejd5awoaIxChRqvd8joQIDAQABo1IwUDAOBgNVHQ8BAf8EBAMCBLAwHQYDVR0OBBYEFKeZixu9F+appDX2SS5HaxmV6Jr4MB8GA1UdIwQYMBaAFLHEaeZbowSn2Jejizu/uWqyMkI8MA0GCSqGSIb3DQEBBQUAA4IBAQBHhLmRAKrnTapqqBObDM9IQDQPuwW+fW1gYwZKlSm/IWIwHEZL1igXhpjjrf4xqpIkiJMmkaOeoXA8PFniX0/lZM9FQSM/j89CUf5dMoAqWj8s17xuXu9L/hVeXjjXHsL40WuDG6tMPN9vcT8tE3ruor608MKSHFX/NEM6+AaNVSUPTmB33BgYB1WaE7pn3JMN6pjIxsHnF4pKi8qvoTSVVjaCEwUe8Q/fw1yvjoHoYJtyMn4v5Kb3Rt+ms8Yie1tcfVQrjQutqr34/IJsKdPziZwi92KZa+1958A6M9O/p5OI0up9ZXKg2DEC1O9qT0GyYJ6sxAyKiGTOxk6jMddDoQAxAA==--estServerExampleBoundary--This is the epilogue.  It is also to be ignored.
 Appendix B.  Contributors and Acknowledgements
-The editors would like to thank Stephen Kent, Vinod Arjun, JanVilhuber, Sean Turner, Russ Housley, and others for their feedbackand prototypes of early versions of this document.  Our thanks alsogo the authors of [RFC6403], around whose document we structured partof this specification.
+The editors would like to thank Stephen Kent, Vinod Arjun, Jan
+Vilhuber, Sean Turner, Russ Housley, and others for their feedback
+and prototypes of early versions of this document.  Our thanks also
+go the authors of [[RFC6403]], around whose document we structured part
+of this specification.
 Authors' Addresses
@@ Line 2,297: / Line 2,229: @@
 EMail: [email protected]
 Peter E. Yee (editor)
@@ Line 2,306: / Line 2,237: @@
 EMail: [email protected]
 Dan Harkins (editor)
@@ Line 2,315: / Line 2,245: @@
 EMail: [email protected]
 [[Category:Standards Track]]

Anonymous

Search

Difference between revisions of "RFC7030"

Latest revision as of 23:38, 1 October 2020

Contents

Introduction

Terminology

Operational Scenario Overviews

Obtaining CA Certificates

Initial Enrollment

Certificate TLS Authentication

Certificate-Less TLS Authentication

HTTP-Based Client Authentication

Client Certificate Reissuance

Server Key Generation

Full PKI Request Messages

Certificate Signing Request (CSR) Attributes Request

Protocol Design and Layering

Application Layer

HTTP Layer

HTTP Headers for Control

HTTP URIs for Control

HTTP-Based Client Authentication

Message Types

TLS Layer

TLS-Based Server Authentication

TLS-Based Client Authentication

Certificate-Less TLS Mutual Authentication

Proof-of-Possession

Linking Identity and POP Information

Server Authorization

Client Use of Explicit TA Database

Client Use of Implicit TA Database

Client Authorization

Protocol Exchange Details

Distribution of CA Certificates

Bootstrap Distribution of CA Certificates

CA Certificates Request

CA Certificates Response

Client Certificate Request Functions

Simple Enrollment of Clients

Simple Re-enrollment of Clients

Simple Enroll and Re-enroll Response

Full CMC

Full CMC Request

Full CMC Response

Server-Side Key Generation

Server-Side Key Generation Request

Requests for Symmetric Key Encryption of the Private Key

Requests for Asymmetric Encryption of the Private Key

Server-Side Key Generation Response

CSR Attributes

CSR Attributes Request

CSR Attributes Response

IANA Considerations

Security Considerations

References

Normative References

Informative References

Navigation

Wiki tools

Page tools

Categories