GENWiki

Premier IT Outsourcing and Support Services within the UK

User Tools

Site Tools

Problem, Formatting or Query -  Send Feedback

Was this page helpful?-10+1


rfc:rfc7030

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.

Pritikin, et al. Standards Track [Page 1] RFC 7030 EST October 2013

Copyright Notice

 Copyright (c) 2013 IETF Trust and the persons identified as the
 document authors.  All rights reserved.
 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.

Table of Contents

 1. Introduction ....................................................3
    1.1. Terminology ................................................4
 2. Operational Scenario Overviews ..................................5
    2.1. Obtaining CA Certificates ..................................6
    2.2. Initial Enrollment .........................................7
         2.2.1. Certificate TLS Authentication ......................8
         2.2.2. Certificate-Less TLS Authentication .................8
         2.2.3. HTTP-Based Client Authentication ....................8
    2.3. Client Certificate Reissuance ..............................8
    2.4. Server Key Generation ......................................9
    2.5. Full PKI Request Messages ..................................9
    2.6. Certificate Signing Request (CSR) Attributes Request .......9
 3. Protocol Design and Layering ...................................10
    3.1. Application Layer .........................................13
    3.2. HTTP Layer ................................................14
         3.2.1. HTTP Headers for Control ...........................15
         3.2.2. HTTP URIs for Control ..............................16
         3.2.3. HTTP-Based Client Authentication ...................17
         3.2.4. Message Types ......................................19
    3.3. TLS Layer .................................................20
         3.3.1. TLS-Based Server Authentication ....................20
         3.3.2. TLS-Based Client Authentication ....................21
         3.3.3. Certificate-Less TLS Mutual Authentication .........21
    3.4. Proof-of-Possession .......................................22
    3.5. Linking Identity and POP Information ......................22
    3.6. Server Authorization ......................................23
         3.6.1. Client Use of Explicit TA Database .................24
         3.6.2. Client Use of Implicit TA Database .................24
    3.7. Client Authorization ......................................24
 4. Protocol Exchange Details ......................................25
    4.1. Distribution of CA Certificates ...........................25

Pritikin, et al. Standards Track [Page 2] RFC 7030 EST October 2013

         4.1.1. Bootstrap Distribution of CA Certificates ..........25
         4.1.2. CA Certificates Request ............................26
         4.1.3. CA Certificates Response ...........................26
    4.2. Client Certificate Request Functions ......................27
         4.2.1. Simple Enrollment of Clients .......................28
         4.2.2. Simple Re-enrollment of Clients ....................29
         4.2.3. Simple Enroll and Re-enroll Response ...............29
    4.3. Full CMC ..................................................30
         4.3.1. Full CMC Request ...................................30
         4.3.2. Full CMC Response ..................................30
    4.4. Server-Side Key Generation ................................31
         4.4.1. Server-Side Key Generation Request .................32
                4.4.1.1. Requests for Symmetric Key
                         Encryption of the Private Key .............32
                4.4.1.2. Requests for Asymmetric Encryption
                         of the Private Key ........................33
         4.4.2. Server-Side Key Generation Response ................33
    4.5. CSR Attributes ............................................35
         4.5.1. CSR Attributes Request .............................35
         4.5.2. CSR Attributes Response ............................35
 5. IANA Considerations ............................................37
 6. Security Considerations ........................................39
 7. References .....................................................41
    7.1. Normative References ......................................41
    7.2. Informative References ....................................43
 Appendix A. Operational Scenario Example Messages .................45
   A.1. Obtaining CA Certificates ..................................45
   A.2. CSR Attributes .............................................47
   A.3. Enroll/Re-enroll ...........................................47
   A.4. Server Key Generation ......................................50
 Appendix B. Contributors and Acknowledgements .....................52

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

Pritikin, et al. Standards Track [Page 3] RFC 7030 EST October 2013

 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

1.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].

Pritikin, et al. Standards Track [Page 4] RFC 7030 EST October 2013

 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.

2. Operational Scenario Overviews

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

Pritikin, et al. Standards Track [Page 5] RFC 7030 EST October 2013

 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.

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

Pritikin, et al. Standards Track [Page 6] RFC 7030 EST October 2013

 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.

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

Pritikin, et al. Standards Track [Page 7] RFC 7030 EST October 2013

 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.

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

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

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

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

Pritikin, et al. Standards Track [Page 8] RFC 7030 EST October 2013

 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.

2.4. Server Key Generation

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

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

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

Pritikin, et al. Standards Track [Page 9] RFC 7030 EST October 2013

3. 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:
 +----------------------------------------------------+
 |                                                    |
 | Message types:                                     |
 |   - "Simple PKI" messages                          |
 |     (incorporates proof-of-possession)             |
 |   - CA certificate retrieval                       |
 |   - "Full PKI" messages (OPTIONAL)                 |
 |     (incorporates proof-of-possession)             |
 |   - CSR Attributes Request (OPTIONAL)              |
 |   - Server-generated key request (OPTIONAL)        |
 |                                                    |
 +----------------------------------------------------+
 |                                                    |
 | HTTP:                                              |
 |   - HTTP headers and URIs for control              |
 |      - Content-Type headers specify message type   |
 |      - Headers for control/error messages          |
 |      - URIs for selecting functions                |
 |   - Basic or Digest authentication (OPTIONAL)      |
 |                                                    |
 +----------------------------------------------------+
 |                                                    |
 | TLS for transport security:                        |
 |   - Authentication of the EST server               |
 |   - Authentication of the EST client (OPTIONAL)    |
 |   - Provides communications integrity              |
 |     and confidentiality                            |
 |   - Supplies channel-binding [RFC5929] information |
 |     to link proof-of-identity with message-based   |
 |     proof-of-possession (OPTIONAL)                 |
 |                                                    |
 +----------------------------------------------------+
                               Figure 2
 Specifying HTTPS as the secure transport for enrollment messages
 introduces two "layers" to communicate authentication and control
 messages: TLS and HTTP.

Pritikin, et al. Standards Track [Page 10] RFC 7030 EST October 2013

 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.

Pritikin, et al. Standards Track [Page 11] RFC 7030 EST October 2013

 Certificates and their corresponding uses:
 +--------------+--------------------+-------------------------------+
 | Certificate  | Issuer             | Use and section references    |
 +==============+====================+===============================+
 | EST server   | The CA served by   | Presented by the EST server   |
 | certificate  | the EST server     | during the TLS handshake.     |
 |              |                    |                               |
 |              |                    | Section 3.3.1                 |
 +--------------+--------------------+-------------------------------+
 | EST server   | A CA               | Presented by the EST server   |
 | certificate  | authenticatable by | during the TLS handshake.     |
 |              | a third-party TA,  |                               |
 |              | e.g., a web server | Section 3.3.1 and             |
 |              | CA                 | Security Considerations       |
 +--------------+--------------------+-------------------------------+
 | Third-party  | A CA               | Presented by the EST client   |
 | EST client   | authenticatable by | to the EST server by clients  |
 | certificate  | a third-party TA,  | that have not yet enrolled.   |
 |              | e.g., a device     |                               |
 |              | manufacturer       | Section 3.3.2                 |
 +--------------+--------------------+-------------------------------+
 | EST client   | The CA served by   | Presented to the EST server   |
 | certificate  | the EST server     | during future EST operations. |
 |              |                    |                               |
 |              |                    | Section 3.3.2                 |
 +--------------+--------------------+-------------------------------+
 | End-entity   | The CA served by   | Clients can obtain certs      |
 | certificate  | the EST server     | that are intended for         |
 |              |                    | non-EST uses.  This includes  |
 |              |                    | certs that cannot be used     |
 |              |                    | for EST operations.           |
 |              |                    |                               |
 |              |                    | Section 4.2.3                 |
 +--------------+--------------------+-------------------------------+
                               Figure 3

Pritikin, et al. Standards Track [Page 12] RFC 7030 EST October 2013

 Trust anchor databases and their corresponding uses:
 +--------------+----------------------------------------------------+
 | TA database  | Use and section references                         |
 +==============+====================================================+
 | EST server   | EST servers use this TA database to authenticate   |
 | Explicit     | certificates issued by the EST CA, including EST   |
 | TA database  | client certificates during enroll/re-enroll        |
 |              | operations.                                        |
 |              |                                                    |
 |              | Section 3.3.2                                      |
 +--------------+----------------------------------------------------+
 | EST server   | EST servers use this TA database to authenticate   |
 | Implicit     | certificates issued by third-party TAs;            |
 | TA database  | e.g., EST client certificates issued by a device   |
 |              | manufacturer.                                      |
 |              | An Implicit TA database can be disabled.           |
 |              |                                                    |
 |              | Section 3.3.2                                      |
 +--------------+----------------------------------------------------+
 | EST client   | EST clients use this TA database to authenticate   |
 | Explicit     | certificates issued by the EST CA, including EST   |
 | TA database  | server certificates.                               |
 |              |                                                    |
 |              | Sections 3.1, 3.3.1, 3.6.1, and 4.1.1              |
 +--------------+----------------------------------------------------+
 | EST client   | EST clients use this TA database to                |
 | Implicit     | authenticate an EST server that uses an externally |
 | TA database  | issued certificate.                                |
 |              | An Implicit TA database can be disabled.           |
 |              |                                                    |
 |              | Sections 3.1, 3.3.1, 3.6.2, and                    |
 |              | Security Considerations                            |
 +--------------+----------------------------------------------------+
                               Figure 4

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

Pritikin, et al. Standards Track [Page 13] RFC 7030 EST October 2013

 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.

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

Pritikin, et al. Standards Track [Page 14] RFC 7030 EST October 2013

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

Pritikin, et al. Standards Track [Page 15] RFC 7030 EST October 2013

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

Pritikin, et al. Standards Track [Page 16] RFC 7030 EST October 2013

 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.

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

Pritikin, et al. Standards Track [Page 17] RFC 7030 EST October 2013

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

Pritikin, et al. Standards Track [Page 18] RFC 7030 EST October 2013

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

Pritikin, et al. Standards Track [Page 19] RFC 7030 EST October 2013

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

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

Pritikin, et al. Standards Track [Page 20] RFC 7030 EST October 2013

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

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

Pritikin, et al. Standards Track [Page 21] RFC 7030 EST October 2013

 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.

3.4. Proof-of-Possession

 As defined in Section 2.1 of CMC [RFC5272], proof-of-possession (POP)
 "refers to a value that can be used to prove that the private key
 corresponding to the public key is in the possession 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).

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

Pritikin, et al. Standards Track [Page 22] RFC 7030 EST October 2013

 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.

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

Pritikin, et al. Standards Track [Page 23] RFC 7030 EST October 2013

 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.

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

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

3.7. Client Authorization

 The decision to issue a certificate to a client is always controlled
 by local CA policy.  The EST server configuration reflects this CA
 policy.  This document does not specify any constraints on such
 policy.  EST provides the EST server access to each client's
 authenticated identity -- e.g., the TLS client's certificate in
 addition to any HTTP user authentication credentials -- to help in
 implementing such policy.
 If the client's certificate was issued by the EST CA, and it includes
 the id-kp-cmcRA [RFC6402] extended key usage extension, then the
 client is a Registration Authority (RA) as described in [RFC5272] and
 [RFC6402].  In this case, the EST server SHOULD apply authorization
 policy consistent with an RA client.  For example, when handling
 /simpleenroll requests, the EST server could be configured to accept
 POP linking information that does not match the current TLS session
 because the authenticated EST client RA has verified this information
 when acting as an EST server (as specified in Section 3.5).  More
 specific RA mechanisms are available if the EST client uses /fullcmc
 methods.

Pritikin, et al. Standards Track [Page 24] RFC 7030 EST October 2013

4. Protocol Exchange Details

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

4.1. Distribution of CA Certificates

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

4.1.1. Bootstrap Distribution of CA Certificates

 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

Pritikin, et al. Standards Track [Page 25] RFC 7030 EST October 2013

 until after the /cacerts response has been accepted and a new TLS
 session has been established (using TLS certificate-based
 authentication).

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

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

Pritikin, et al. Standards Track [Page 26] RFC 7030 EST October 2013

 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.

4.2. Client Certificate Request Functions

 EST clients request a certificate from the EST server with an HTTPS
 POST using the operation path value of "/simpleenroll".  EST clients
 request a renew/rekey of existing certificates with an HTTP POST
 using the operation path value of "/simplereenroll".  EST servers
 MUST support the /simpleenroll and /simplereenroll functions.
 It is RECOMMENDED that a client obtain the current CA certificates,
 as described in Section 4.1, before performing certificate request
 functions.  This ensures that the client will be able to validate the
 EST server certificate.  The client MUST authenticate the EST server
 as specified in Section 3.3.1 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

Pritikin, et al. Standards Track [Page 27] RFC 7030 EST October 2013

 server MUST check the tls-unique value, as described in Section 3.5,
 if one is submitted by the client.
 The server MAY accept a certificate request for manual authorization
 checking by an administrator.  (Section 4.2.3 describes the use of an
 HTTP 202 response to the EST client if this occurs.)

4.2.1. Simple Enrollment of Clients

 When HTTPS POSTing to /simpleenroll, the client MUST include a Simple
 PKI Request as specified in CMC [RFC5272], Section 3.1 (i.e., a PKCS
 #10 Certification Request [RFC2986]).
 The Certification Signing Request (CSR) signature provides
 proof-of-possession of the 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.

Pritikin, et al. Standards Track [Page 28] RFC 7030 EST October 2013

4.2.2. Simple Re-enrollment of Clients

 EST clients renew/rekey certificates with an HTTPS POST using the
 operation path value of "/simplereenroll".
 A certificate request employs the same format as the "simpleenroll"
 request, using the same HTTP content-type.  The request Subject field
 and SubjectAltName extension MUST be identical to the corresponding
 fields in the certificate being renewed/rekeyed.  The
 ChangeSubjectName attribute, as defined in [RFC6402], MAY be included
 in the CSR to request that these fields be changed in the new
 certificate.
 If the Subject Public Key Info in the certification request is the
 same as the current client certificate, 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.

4.2.3. Simple Enroll and Re-enroll Response

 If the enrollment is successful, the server response MUST contain an
 HTTP 200 response code with a content-type of
 "application/pkcs7-mime".
 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

Pritikin, et al. Standards Track [Page 29] RFC 7030 EST October 2013

 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.

4.3. Full CMC

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

4.3.1. Full CMC Request

 If the HTTP POST to /fullcmc is not a valid Full PKI Request, the
 server MUST reject the message.  The HTTP content-type used is
 "application/pkcs7-mime" 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].

4.3.2. 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].

Pritikin, et al. Standards Track [Page 30] RFC 7030 EST October 2013

 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.

4.4. Server-Side Key Generation

 An EST client may request a private key and associated certificate
 from an EST server using an HTTPS POST with an operation path value
 of "/serverkeygen".  Support for the /serverkeygen function is
 OPTIONAL.
 A client MUST authenticate an EST server, as specified in
 Section 3.3.1 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.

Pritikin, et al. Standards Track [Page 31] RFC 7030 EST October 2013

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

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

Pritikin, et al. Standards Track [Page 32] RFC 7030 EST October 2013

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

4.4.2. Server-Side Key Generation Response

 If the request is successful, the server response MUST have an HTTP
 200 response code with a content-type of "multipart/mixed" consisting
 of two parts: one part is the private key data and the other part is
 the certificate data.
 The format in which the private key data part is returned is
 dependent on whether the private key is being returned with
 additional encryption on top of that provided by TLS.
 If additional encryption is 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.

Pritikin, et al. Standards Track [Page 33] RFC 7030 EST October 2013

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

Pritikin, et al. Standards Track [Page 34] RFC 7030 EST October 2013

 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.

4.5. CSR Attributes

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

4.5.1. CSR Attributes Request

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

4.5.2. CSR Attributes Response

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

Pritikin, et al. Standards Track [Page 35] RFC 7030 EST October 2013

 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.

Pritikin, et al. Standards Track [Page 36] RFC 7030 EST October 2013

 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==

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

Pritikin, et al. Standards Track [Page 37] RFC 7030 EST October 2013

 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 <dharkins@arubanetworks.com>
     Restrictions on usage: None
     Author: Dan Harkins <dharkins@arubanetworks.com>
     Intended usage: COMMON
     Change controller: The IESG <iesg@ietf.org>

Pritikin, et al. Standards Track [Page 38] RFC 7030 EST October 2013

 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.

6. Security Considerations

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

Pritikin, et al. Standards Track [Page 39] RFC 7030 EST October 2013

 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

Pritikin, et al. Standards Track [Page 40] RFC 7030 EST October 2013

 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.

7. References

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

Pritikin, et al. Standards Track [Page 41] RFC 7030 EST October 2013

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

Pritikin, et al. Standards Track [Page 42] RFC 7030 EST October 2013

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

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

Pritikin, et al. Standards Track [Page 43] RFC 7030 EST October 2013

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

Pritikin, et al. Standards Track [Page 44] RFC 7030 EST October 2013

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

Pritikin, et al. Standards Track [Page 45] RFC 7030 EST October 2013

 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==

Pritikin, et al. Standards Track [Page 46] RFC 7030 EST October 2013

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,

Pritikin, et al. Standards Track [Page 47] RFC 7030 EST October 2013

 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==

Pritikin, et al. Standards Track [Page 48] RFC 7030 EST October 2013

 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

Pritikin, et al. Standards Track [Page 49] RFC 7030 EST October 2013

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==

Pritikin, et al. Standards Track [Page 50] RFC 7030 EST October 2013

 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

Pritikin, et al. Standards Track [Page 51] RFC 7030 EST October 2013

 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.

Pritikin, et al. Standards Track [Page 52] RFC 7030 EST October 2013

Authors' Addresses

 Max Pritikin (editor)
 Cisco Systems, Inc.
 510 McCarthy Drive
 Milpitas, CA  95035
 USA
 EMail: pritikin@cisco.com
 Peter E. Yee (editor)
 AKAYLA, Inc.
 7150 Moorland Drive
 Clarksville, MD  21029
 USA
 EMail: peter@akayla.com
 Dan Harkins (editor)
 Aruba Networks
 1322 Crossman Avenue
 Sunnyvale, CA  94089-1113
 USA
 EMail: dharkins@arubanetworks.com

Pritikin, et al. Standards Track [Page 53]

/data/webs/external/dokuwiki/data/pages/rfc/rfc7030.txt · Last modified: 2013/10/23 21:40 (external edit)