[Docs] [txt|pdf] [Tracker] [WG] [Email] [Diff1] [Diff2] [Nits]

Versions: (draft-pritikin-est) 00 01 02 03 04 05 06 07 08 09 RFC 7030

PKIX                                                    M. Pritikin, Ed.
Internet-Draft                                       Cisco Systems, Inc.
Intended status: Standards Track                             P. Yee, Ed.
Expires: September 30, 2013                                 AKAYLA, Inc.
                                                         D. Harkins, Ed.
                                                          Aruba Networks
                                                          March 29, 2013


                    Enrollment over Secure Transport
                         draft-ietf-pkix-est-06

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) certificate(s).  It also supports client-generated public/
   private key pairs as well as key pairs generated by the CA.

Status of this Memo

   This Internet-Draft is submitted in full conformance with the
   provisions of BCP 78 and BCP 79.

   Internet-Drafts are working documents of the Internet Engineering
   Task Force (IETF).  Note that other groups may also distribute
   working documents as Internet-Drafts.  The list of current Internet-
   Drafts is at http://datatracker.ietf.org/drafts/current/.

   Internet-Drafts are draft documents valid for a maximum of six months
   and may be updated, replaced, or obsoleted by other documents at any
   time.  It is inappropriate to use Internet-Drafts as reference
   material or to cite them other than as "work in progress."

   This Internet-Draft will expire on September 30, 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



Pritikin, et al.       Expires September 30, 2013               [Page 1]

Internet-Draft                     EST                        March 2013


   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 . . . . . . . . . . . . . . . . . . . . . . . . .  4
     1.1.  Terminology  . . . . . . . . . . . . . . . . . . . . . . .  5
   2.  Operational Scenario Overviews . . . . . . . . . . . . . . . .  6
     2.1.  Obtaining CA Certificates  . . . . . . . . . . . . . . . .  7
     2.2.  Initial Enrollment . . . . . . . . . . . . . . . . . . . .  8
       2.2.1.  Certificate TLS authentication . . . . . . . . . . . .  8
       2.2.2.  Certificate-less TLS authentication  . . . . . . . . .  8
       2.2.3.  HTTP-based client authentication . . . . . . . . . . .  9
     2.3.  Client Certificate Re-issuance . . . . . . . . . . . . . .  9
     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  . . . . . . . . . . . . . . . . . . . . 14
     3.2.  HTTP Layer . . . . . . . . . . . . . . . . . . . . . . . . 15
       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  . . . . . . . . . . . . . . . . . . . . 18
     3.3.  TLS Layer  . . . . . . . . . . . . . . . . . . . . . . . . 19
       3.3.1.  TLS-Based Server Authentication  . . . . . . . . . . . 20
       3.3.2.  TLS-Based Client Authentication  . . . . . . . . . . . 20
       3.3.3.  Certificate-less TLS Mutual Authentication . . . . . . 21
     3.4.  Proof-of-Possession  . . . . . . . . . . . . . . . . . . . 21
     3.5.  Linking Identity and PoP information . . . . . . . . . . . 22
     3.6.  Server Authorization . . . . . . . . . . . . . . . . . . . 23
       3.6.1.  Client use of Explicit TA Database . . . . . . . . . . 23
       3.6.2.  Client use of Implicit TA Database . . . . . . . . . . 23
     3.7.  Client Authorization . . . . . . . . . . . . . . . . . . . 24
   4.  Protocol Exchange Details  . . . . . . . . . . . . . . . . . . 24
     4.1.  Distribution of CA certificates  . . . . . . . . . . . . . 24
       4.1.1.  Bootstrap Distribution of CA certificates  . . . . . . 24
       4.1.2.  CA certificates request  . . . . . . . . . . . . . . . 25
       4.1.3.  CA certificates response . . . . . . . . . . . . . . . 25
     4.2.  Client Certificate Request Functions . . . . . . . . . . . 27
       4.2.1.  Simple Enrollment of Clients . . . . . . . . . . . . . 27
       4.2.2.  Simple Re-Enrollment of Clients  . . . . . . . . . . . 28
       4.2.3.  Simple Enroll and Re-Enroll Response . . . . . . . . . 28



Pritikin, et al.       Expires September 30, 2013               [Page 2]

Internet-Draft                     EST                        March 2013


     4.3.  Full CMC . . . . . . . . . . . . . . . . . . . . . . . . . 29
       4.3.1.  Full CMC Request . . . . . . . . . . . . . . . . . . . 29
       4.3.2.  Full CMC Response  . . . . . . . . . . . . . . . . . . 29
     4.4.  Server-side Key Generation . . . . . . . . . . . . . . . . 30
       4.4.1.  Server-side Key Generation Request . . . . . . . . . . 30
         4.4.1.1.  Requests for Symmetric Key Encryption of the
                   Private Key  . . . . . . . . . . . . . . . . . . . 31
         4.4.1.2.  Requests for Asymmetric Encryption of the
                   Private Key  . . . . . . . . . . . . . . . . . . . 31
       4.4.2.  Server-side Key Generation Response  . . . . . . . . . 31
     4.5.  CSR Attributes . . . . . . . . . . . . . . . . . . . . . . 33
       4.5.1.  CSR Attributes Request . . . . . . . . . . . . . . . . 33
       4.5.2.  CSR Attributes Response  . . . . . . . . . . . . . . . 33
   5.  Contributors/Acknowledgements  . . . . . . . . . . . . . . . . 35
   6.  IANA Considerations  . . . . . . . . . . . . . . . . . . . . . 35
   7.  Security Considerations  . . . . . . . . . . . . . . . . . . . 36
   8.  References . . . . . . . . . . . . . . . . . . . . . . . . . . 38
     8.1.  Normative References . . . . . . . . . . . . . . . . . . . 38
     8.2.  Informative References . . . . . . . . . . . . . . . . . . 41
   Appendix A.  Operational Scenario Example Messages . . . . . . . . 42
     A.1.  Obtaining CA Certificates  . . . . . . . . . . . . . . . . 42
     A.2.  Enroll/ReEnroll  . . . . . . . . . . . . . . . . . . . . . 44
     A.3.  Server Key Generation  . . . . . . . . . . . . . . . . . . 46
     A.4.  CSR Attributes . . . . . . . . . . . . . . . . . . . . . . 48
   Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 49


























Pritikin, et al.       Expires September 30, 2013               [Page 3]

Internet-Draft                     EST                        March 2013


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] (or a later
   version) and Hypertext Transfer Protocol (HTTP) 1.1 [RFC2616] (or a
   later version) to provide an authenticated and authorized channel for
   Simple PKI (Public Key Infrastructure) Requests and Responses
   [RFC5272].

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

   EST adopts the Certificate Management Protocol (CMP) [RFC4210] model
   for CA certificate rollover, but 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 content types are used
   in conjunction with TLS.  HTTPS operates over TCP; this document does
   not specify EST over Datagram Transport Layer Security/User Datagram
   Protocol (DTLS/UDP).  Figure 1 shows how the layers build upon each
   other.




















Pritikin, et al.       Expires September 30, 2013               [Page 4]

Internet-Draft                     EST                        March 2013


   EST Layering:

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

                                 Figure 1

   [[EDNOTE: Comments such as this one, included within double brackets
   and initiated with an 'EDNOTE', are for editorial use and shall be
   removed as the document is polished.]]

1.1.  Terminology

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

   It is assumed that the reader is familiar with the terms and concepts
   described in Public Key Cryptography Standard (PKCS) #10 [RFC2314],
   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.







Pritikin, et al.       Expires September 30, 2013               [Page 5]

Internet-Draft                     EST                        March 2013


   Third-Party Trust Anchor (TA):  Any Trust Anchor that is not
      authoritative for the PKI hierarchy the EST server is providing
      services for.

   Explicit Trust Anchor:  Any Trust Anchor 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 Section 3.6 and Section 7).

   Implicit Trust Anchor:  Any third-party Trust Anchor 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 server's to
      authenticate manufacturing installed client credentials.  The
      authorization model for these TAs is different from the
      authorization model for Explicit Trust Anchors.  (See more details
      in Section 3.6.1, Section 3.6.2, and Section 7).

   Certificate-less TLS:  Use of a TLS cipher suite in which neither the
      client nor server use a certificate to authenticate.  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.


2.  Operational Scenario Overviews

   This section provides an informative overview of the operational
   scenarios to better introduce the reader to the protocol discussion.
   This section does not include RFC 2119 key words.

   Both the EST clients and server are configured with information that
   provides the basis for bidirectional authentication and for
   authorization.  The specific initialization data depends on the
   methods available in the client device and server, but 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 device 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.




Pritikin, et al.       Expires September 30, 2013               [Page 6]

Internet-Draft                     EST                        March 2013


   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
   device 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 device 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 certificates
   from the EST server.  The EST client is assumed to perform this
   operation before performing other operations.

   Throughout this document we assume the EST CA has a certificate that
   is used by the client to verify signed objects issued by the CA,
   e.g., certificates and certificate revocation lists (CRLs), and that
   a separate end-entity (EE) certificate is used when EST protocol
   communication requires additional encryption.  This operation is used
   to obtain the EST CA certificate(s).

   The EST client authenticates and verifies the authorization scope of
   the EST server when requesting the current CA certificate(s).  As
   detailed in Section 3.3.1 and Section 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.




Pritikin, et al.       Expires September 30, 2013               [Page 7]

Internet-Draft                     EST                        March 2013


   o  For bootstrapping, the EST client can rely upon manual
      authentication performed by the end user as detailed in
      Section 4.1.1.

   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 Section 3.3.2, Section 3.3.3 and Section 3.7.  The
   methods described in the normative text that are discussed in this
   overview include:

   o  TLS with a previously issued client certificate (e.g., an existing
      certificate issued by the EST CA);

   o  TLS with a previously installed certificate (e.g., manufacturer
      installed certificate or a certificate issued by some other
      party);

   o  Certificate-less TLS (e.g., with a shared credential distributed
      out-of-band);

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

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





Pritikin, et al.       Expires September 30, 2013               [Page 8]

Internet-Draft                     EST                        March 2013


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.

2.3.  Client Certificate Re-issuance

   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 re-
   issued EST client certificate cannot be used for TLS client
   authentication, any of the authentication methods used for initial
   enrollment can be used.

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

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

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 attribute(s)
   that the client is requested to use in a subsequent enrollment



Pritikin, et al.       Expires September 30, 2013               [Page 9]

Internet-Draft                     EST                        March 2013


   request.

   These attributes can provide additional descriptive information that
   the EST server cannot access itself, such as the MAC address of an
   interface.  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.


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.




































Pritikin, et al.       Expires September 30, 2013              [Page 10]

Internet-Draft                     EST                        March 2013


   EST Layering:

   Protocols and uses:
   +---------------------------------------------------+
   |                                                   |
   | Message types:                                    |
   |   - "Simple PKI" messages                         |
   |     (incorporating proof-of-possession)           |
   |   - CA certificate retrieval                      |
   |   - "Full PKI" messages (OPTIONAL)                |
   |   - CSR attribute 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                           |
   |   - Channel Binding [RFC5929] 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.

   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



Pritikin, et al.       Expires September 30, 2013              [Page 11]

Internet-Draft                     EST                        March 2013


   be used if a proof-of-identity needs to be included".  Since the TLS
   and HTTP layers 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 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 CMC Transport Protocols [RFC5273].

   During protocol exchanges different certificates can be used.  The
   following table provides an informative overview.  End-entities MAY
   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.       Expires September 30, 2013              [Page 12]

Internet-Draft                     EST                        March 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 can not be used    |
   |              |                    | for EST operations.           |
   |              |                    |                               |
   |              |                    | Section 4.2.3                 |
   +--------------+--------------------+-------------------------------+


                                 Figure 3














Pritikin, et al.       Expires September 30, 2013              [Page 13]

Internet-Draft                     EST                        March 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.                               |
   |              |                                                    |
   |              | Section 3.1, Section 3.3.1, Section 3.6.1 and      |
   |              | Section 4.1.1                                      |
   +--------------+----------------------------------------------------+
   | EST client   | EST clients use this trust anchor database to      |
   | Implicit     | authenticate an EST server that uses an externally |
   | TA database  | issued certificate.                                |
   |              | An Implicit TA database can be disabled.           |
   |              |                                                    |
   |              | Section 3.1, Section 3.3.1, Section 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.       Expires September 30, 2013              [Page 14]

Internet-Draft                     EST                        March 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 7.  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", "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 lack of a client certificate
   suitable for use by TLS (see Section 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 that RFC, persistent connections may be
   used to reduce network and processing load associated with multiple
   HTTP requests.  EST does not require or preclude persistent HTTP
   connections and their use is out of scope of this specification.

3.2.1.  HTTP headers for control

   This document profiles the HTTP content-type header (as defined in
   [RFC2046], but see Figure 6 for specific values) to indicate the
   media type for EST messages and to specify control messages for EST.
   The HTTP Status value is used to communicate success or failure of an
   EST function.  HTTP authentication is used by a client when requested



Pritikin, et al.       Expires September 30, 2013              [Page 15]

Internet-Draft                     EST                        March 2013


   by the server.

   The media types indicated in the HTTP content-type header indicates
   which EST message is being transferred.  Media types used by EST are
   specified in Section 3.2.4.

3.2.2.  HTTP URIs for control

   The EST server MUST use the [RFC5785] defined path-prefix of "/.well-
   known/" 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 new      | /simpleEnroll   | Section 4.2.      |
   | clients (MUST)         |                 |                   |
   +------------------------+-----------------+-------------------+
   | Re-Enrollment of       | /simpleReEnroll | Section 4.2.2     |
   | existing clients (MUST)|                 |                   |
   +------------------------+-----------------+-------------------+
   | Full CMC (OPTIONAL)    | /fullCMC        | Section 4.3       |
   +------------------------+-----------------+-------------------+
   | Server-side Key        | /serverKeyGen   | Section 4.4       |
   | Generation (OPTIONAL)  |                 |                   |
   +------------------------+-----------------+-------------------+
   | Request 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:

   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:



Pritikin, et al.       Expires September 30, 2013              [Page 16]

Internet-Draft                     EST                        March 2013


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

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

   An EST server MAY provide service for multiple CAs as indicated by an
   OPTIONAL additional path segment between the registered application
   name and the operation path.  To avoid conflict the CA label MUST NOT
   be the same as any defined operation path segment.  The EST server
   MUST provide services when the additional path segment is not
   included.  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 uses the same messages for certificate renewal and
   certificate rekey.

   An EST server MAY 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.  As specified in CMC: Transport
   Protocols [RFC5273] the server "MUST NOT assume client support for
   any type of HTTP authentication such as cookies, Basic
   authentication, or Digest authentication".  Clients SHOULD support
   the Basic and Digest authentication mechanism.

   Servers that wish to use Basic and Digest authentication reject the



Pritikin, et al.       Expires September 30, 2013              [Page 17]

Internet-Draft                     EST                        March 2013


   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 7.  The client MUST NOT respond
   to the server's HTTP authentication request unless the client has
   authenticated the EST server (as per Section 3.6).

3.2.4.  Message types

   This document uses existing media types for the messages as specified
   by [RFC2585], [RFC5967], and CMC [RFC5272].  To support distribution
   of multiple certificates for a CA certificate path, the [RFC2046]
   multipart/mixed media type is used.

   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 are:
























Pritikin, et al.       Expires September 30, 2013              [Page 18]

Internet-Draft                     EST                        March 2013


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


                                 Figure 6

3.3.  TLS Layer

   TLS provides 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
   bidirectional authentication has been performed.  Alternately,
   certificate-less TLS authentication, where neither the client nor
   server present a certificate, is also an acceptable method for EST
   mutual authentication.

   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 TLS session resumption [RFC5077] SHOULD be supported.

   TLS channel binding information MAY be inserted into a certificate
   request as detailed in Section 3.5 in order to provide the EST server



Pritikin, et al.       Expires September 30, 2013              [Page 19]

Internet-Draft                     EST                        March 2013


   with assurance that the authenticated TLS client has access to the
   private key for the certificate being requested.

3.3.1.  TLS-Based Server Authentication

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

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

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

   The client validates the TLS server certificate using the EST client
   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.

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.  As an
   alternative or as an addition to authentication using a certificate,
   an EST server MAY support certificate-less TLS authentication
   (Section 3.3.3).

   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



Pritikin, et al.       Expires September 30, 2013              [Page 20]

Internet-Draft                     EST                        March 2013


   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 third-party issued client
   certificate 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 server 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
   resistant to dictionary attack and MUST be based on a zero knowledge
   protocol.  TLS-SRP ciphersuites listed in section 2.7 of [RFC5054]
   are suitable for this purpose.  Section 7 lists the characteristics
   of a ciphersuite 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 which 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 and can be used



Pritikin, et al.       Expires September 30, 2013              [Page 21]

Internet-Draft                     EST                        March 2013


   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 the server requires the
   mechanism specified in this section be used by the client.  This
   specification provides an OPTIONAL method of linking identity and
   proof-of-possession by including information specific to the current
   authenticated TLS session within the signed certification request.
   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
   are RECOMMENDED to 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 [RFC5272] Section 6.3-
   defined "Linking Identity and POP information" method available if
   Full PKI messages are used.

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

   The tls-unique value is base 64-encoded as specified in Section 4 of
   [RFC4648] and the resulting string is placed in the certification
   request challenge-password field ([RFC2985], Section 5.4.1).  If tls-



Pritikin, et al.       Expires September 30, 2013              [Page 22]

Internet-Draft                     EST                        March 2013


   unique information is not embedded within the certification request
   the challenge-password field MUST be empty to indicate that the
   client did not include the optional channel-binding information (any
   value submitted is verified by the server as tls-unique information).

   If the EST server 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
   "RA POP Witness Control" in a CMC Full PKI Request message.  Or an
   EST server might TLS authenticate an EST client as being a trusted
   infrastructure element that does not forward invalid requests.  A
   detailed discussion of back-end processing is out of scope).

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

3.6.  Server Authorization

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

   The EST client authorization method depends on which method was used
   to authenticate the server.  When the Explicit TA database is used to
   authenticate the EST server then Section 3.6.1 applies.  When the
   Implicit TA database is used to authenticate the EST server then
   Section 3.6.2 applies.  Successful authentication using a
   certificate-less cipher suite implies authorization of the server.

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

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
   against the server's identity, 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 URI "against the
   server's identity as presented in the server's Certificate message"
   (HTTP Over TLS Section 3.1 "Server Identity" [RFC2818] and



Pritikin, et al.       Expires September 30, 2013              [Page 23]

Internet-Draft                     EST                        March 2013


   [RFC6125]).  The provisioned 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.


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 the TA
   database(s) necessary to validate the EST server certificate.  This
   section describes a method by which minimally configured EST clients
   can populate their Explicit TA database.




Pritikin, et al.       Expires September 30, 2013              [Page 24]

Internet-Draft                     EST                        March 2013


   If the EST client application does not specify either an Explicit TA
   database or a 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 (Section 4.1.3 or
   Section 4.3.2) and engage a human user to authorize the CA
   certificate using out-of-band data such as a CA certificate
   "fingerprint" (e.g., a SHA-256 or SHA-512 [SHS] hash on the whole CA
   certificate).  In a /fullCMC response it is the Publish Trust Anchors
   control within the Full PKI Response that must be accepted manually.
   It is incumbent on the user to properly verify the TA information, or
   to provide the "fingerprint" data during configuration that is
   necessary to verify the TA information.

   HTTP authentication requests MUST NOT be responded to if the server
   has not been authenticated.

   The EST client uses the /CACerts response to establish an Explicit
   Trust Anchor database for subsequent TLS authentication of the EST
   server.  EST clients MUST NOT engage in any other protocol exchange
   until after the /CACerts response has been accepted and a new TLS
   session has been established (using TLS certificate-based
   authentication).

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 MUST NOT require client authentication or
   authorization to reply to this request.

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

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



Pritikin, et al.       Expires September 30, 2013              [Page 25]

Internet-Draft                     EST                        March 2013


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

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

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

   After out-of-band validation occurs, all the other certificates MUST
   be validated using normal [RFC5280] certificate path validation
   (using the most recent CA certificate as the TA) before they can be
   used to build certificate paths during certificate validation.

   The EST client MUST store the extracted EST CA certificate as an
   Explicit TA database entry for subsequent EST server authentication.
   The EST client SHOULD disable use of Implicit TA database entries for
   this EST server, now that an Explicit TA database entry is available.
   If the client disables the Implicit TA database, and if the EST
   server certificate was verified using an Implicit TA database entry,
   then the client MUST include the "Trusted CA Indication" extension in
   future TLS sessions [RFC4366].  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.





Pritikin, et al.       Expires September 30, 2013              [Page 26]

Internet-Draft                     EST                        March 2013


4.2.  Client Certificate Request Functions

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

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

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

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

4.2.1.  Simple Enrollment of Clients

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

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

   The HTTP content-type of "application/pkcs10" is used here.  The
   format of the message is as specified in [RFC5967] with a Content-
   Transfer-Encoding of "base64" [RFC2045].



Pritikin, et al.       Expires September 30, 2013              [Page 27]

Internet-Draft                     EST                        March 2013


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

4.2.2.  Simple Re-Enrollment of Clients

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

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

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

4.2.3.  Simple Enroll and Re-Enroll Response

   If the enrollment is successful, the server response MUST contain an
   HTTP 200 response code with a content-type of "application/
   pkcs7-mime".

   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" is used.
   The Simple PKI response is sent with a Content-Transfer-Encoding of
   "base64" [RFC2045].

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

   If the server responds with an HTTP [RFC2616] 202, this indicates
   that the request has been accepted for processing but that a response



Pritikin, et al.       Expires September 30, 2013              [Page 28]

Internet-Draft                     EST                        March 2013


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

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

   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", 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 or the Full PKI Response as specified
   in Section 3.2 of [RFC5272].  The body of the message is the binary
   value of the encoding of the PKI Response with a Content-Transfer-
   Encoding of "base64" [RFC2045].

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



Pritikin, et al.       Expires September 30, 2013              [Page 29]

Internet-Draft                     EST                        March 2013


   example indicating that CSR attributes are incomplete).

   All other return codes are handled as specified in Section 4.2.3 or
   HTTP [RFC2616].  For example, a client interprets 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 and authorize an EST server as specified
   in Section 3.3.1, Section 3.6, and Section 3.3.3.

   The EST server MUST authenticate and authorize the client as
   specified in Section 3.3.2, Section 3.7, and Section 3.3.3.  The EST
   server applies whatever authorization or logic it chooses to
   determine if the private key and certificate should be provided.

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

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

4.4.1.  Server-side Key Generation Request

   The certificate request is HTTPS POSTed and is the same format as for
   the "/simpleEnroll" and "/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 and in addition to that of the TLS transport used by



Pritikin, et al.       Expires September 30, 2013              [Page 30]

Internet-Draft                     EST                        March 2013


   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.

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,
   [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 DecryptKeyIdentifer to the key generator and the
   client is outside the scope of this document.

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-pkix TBD }

   The asymmetric-decrypt-key-identifier attribute values have ASN.1
   type AsymmetricDecryptKeyIdentifier:

       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
   AysmmetricDecryptKeyIdentifer to the key generator and the client is
   outside the scope of this document.

4.4.2.  Server-side Key Generation Response

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




Pritikin, et al.       Expires September 30, 2013              [Page 31]

Internet-Draft                     EST                        March 2013


   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 base 64-encoded DER-encoded 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 inside of
   a CMS EnvelopedData, as described in Section 4 of [RFC5958].  The
   following list shows how the EncryptedData is used, depending on the
   type of protection key specified by the client.

   o   If the client specified a symmetric encryption key to protect the
       server-generated private key, the EnvelopedData content is
       encrypted using the secret key identified in the request.  The
       EnvelopedData RecipientInfo field MUST indicate the ori (Other
       Recipient Info) key management technique.  The oriType will be
       set to TBD and the oriValue will be set to TBD.

   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 ktri (KeyTransRecipientInfo) key
       management technique.  The KeyTransRecipInfo carries the random
       symmetric encryption key wrapped in the asymmetric key.  The rid
       (recipient identification) field in the KeyTransRecipInfo MUST be
       ignored by the client.

   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 kari (KeyAgreeRecipientInfo) key
       management technique.  The RecipientEncryptedKey carries the
       random symmetric encryption key encrypted in the key derived from
       the key agreement process.  The rid (recipient identification)
       field in the RecipientEncryptedKey field and the
       KeyAgreeRecipientIdentifier field MUST be ignored by the client.



Pritikin, et al.       Expires September 30, 2013              [Page 32]

Internet-Draft                     EST                        March 2013


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

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

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

4.5.  CSR Attributes

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

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

4.5.1.  CSR Attributes Request

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

4.5.2.  CSR Attributes Response

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

   If the CA requires a particular crypto system (e.g., certification of
   a public key based on a certain elliptic curve) it MUST provide that
   information in the CSR Attributes response.  If an EST server



Pritikin, et al.       Expires September 30, 2013              [Page 33]

Internet-Draft                     EST                        March 2013


   requires the linking of identity and PoP information (see
   Section 3.5) it MUST include the challengePassword OID in the CSR
   Attributes response.

   Responses to attribute request messages MUST be encoded as content-
   type 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 OBJECT IDENTIFIER { }

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

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

   o   macAddress: 1.3.6.1.1.1.1.22

   o   challengePassword: 1.2.840.113549.1.9.7

   o   the secp384r1 elliptic curve: 1.3.132.0.34

   o   the SHA384 hash function: 2.16.840.1.101.3.4.2.2

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

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

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

       MCYGBysGAQEBARYGCSqGSIb3DQEJBwYFK4EEACIGCWCGSAFlAwQCAg==

   The EST client parses the OID's in the response and handles each OID
   independently.  When an OID indicates a known descriptive CSR
   attribute type, the client SHOULD include the requested information



Pritikin, et al.       Expires September 30, 2013              [Page 34]

Internet-Draft                     EST                        March 2013


   in the subsequent CSR that it submits, either in the CSR attributes
   or in any other appropriate CSR field.  When an OID indicates a
   particular way to generate the CSR, the client SHOULD generate its
   CSR according to the parsed OID.  When an OID is of an unknown type
   the OID MUST be ignored by the client.


5.  Contributors/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 drafts.  Our thanks also go the authors of
   [RFC6403] around whose document we structured part of this
   specification.


6.  IANA Considerations

   There is one OID in Section 4.4.1.2 that needs to be registered in
   the PKIX Arc.

   IANA is requested to register the following:

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

      URI suffix: est

      Change controller: IETF

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

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

       Type name: application

       Subtype name: csrattrs

       Required parameters: None

       Optional parameters: None

       Encoding considerations: binary;

       Security Considerations:




Pritikin, et al.       Expires September 30, 2013              [Page 35]

Internet-Draft                     EST                        March 2013


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

       Interoperability considerations: None

       Published specification: This memo.

       Applications which use this media type:

       Enrollment over Secure Transport (EST)

       Additional information:

         Magic number(s): None

         File extension: None

         Macintosh File Type Code(s):

       Person & email address to contact for further information:

       Dan Harkins <dharkins@arubanetworks.com>

       Restrictions on usage: None

       Author: Dan Harkins <dharkins@arubanetworks.com>

       Intended usage: COMMON

       Change controller: The IESG


7.  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 certified-by-a-third-party responder for the URI



Pritikin, et al.       Expires September 30, 2013              [Page 36]

Internet-Draft                     EST                        March 2013


   configured, but cannot verify that the responder is authorized to act
   as an RA for the PKI in which the client is trying to enroll.
   Clients using an implicit trust anchor database are RECOMMENDED to
   only use TLS-based client authentication (to prevent exposing HTTP-
   based Client Authentication information).  It is RECOMMENDED that
   such clients include "Linking Identity and POP information"
   (Section 3.5) in requests (to prevent such requests from being
   forwarded to a real EST server by a MITM).  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 succesfully recieving the
   Distribution of CA Certificates response (Section 4.1.3) limits any
   vulnerability to the first TLS enchange.

   Certificate-less TLS ciphersuites that maintain security and perform
   the mutual authentiation necessary for enrollment have the following
   properties:

   o   the only information leaked by an active attack is whether a
       single guess of the secret is correct or not.

   o   any advantage an adversary gains is through interaction and not
       compuation.

   o   it is possible to perform countermeasures, such as exponential
       backoff after a certain number of failed attempts, to frustrate
       repeated active attacks.

   Using a certificate-less ciphersuite 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 results in corruption of
   a client's trust anchor database.

   As described in CMC Section 6.7, "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



Pritikin, et al.       Expires September 30, 2013              [Page 37]

Internet-Draft                     EST                        March 2013


   while the TLS session was active.  This implies to the server that
   the authenticated client currently has access to the private key.  If
   the authenticated client is known to have specific capabilities, such
   as hardware protection for authentication credentials and key
   storage, this implication is strengthened but not proven.

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

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


8.  References

8.1.  Normative References

   [RFC1321]  Rivest, R., "The MD5 Message-Digest Algorithm", RFC 1321,
              April 1992.

   [RFC2045]  Freed, N. and N. Borenstein, "Multipurpose Internet Mail
              Extensions (MIME) Part One: Format of Internet Message
              Bodies", RFC 2045, November 1996.

   [RFC2046]  Freed, N. and N. Borenstein, "Multipurpose Internet Mail
              Extensions (MIME) Part Two: Media Types", RFC 2046,
              November 1996.

   [RFC2119]  Bradner, S., "Key words for use in RFCs to Indicate
              Requirement Levels", BCP 14, RFC 2119, March 1997.

   [RFC2314]  Kaliski, B., "PKCS #10: Certification Request Syntax
              Version 1.5", RFC 2314, March 1998.




Pritikin, et al.       Expires September 30, 2013              [Page 38]

Internet-Draft                     EST                        March 2013


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

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

   [RFC2986]  Nystrom, M. and B. Kaliski, "PKCS #10: Certification
              Request Syntax Specification Version 1.7", RFC 2986,
              November 2000.

   [RFC3986]  Berners-Lee, T., Fielding, R., and L. Masinter, "Uniform
              Resource Identifier (URI): Generic Syntax", STD 66,
              RFC 3986, January 2005.

   [RFC4086]  Eastlake, D., Schiller, J., and S. Crocker, "Randomness
              Requirements for Security", BCP 106, RFC 4086, June 2005.

   [RFC4108]  Housley, R., "Using Cryptographic Message Syntax (CMS) to
              Protect Firmware Packages", RFC 4108, August 2005.

   [RFC4210]  Adams, C., Farrell, S., Kause, T., and T. Mononen,
              "Internet X.509 Public Key Infrastructure Certificate
              Management Protocol (CMP)", RFC 4210, September 2005.

   [RFC4288]  Freed, N. and J. Klensin, "Media Type Specifications and
              Registration Procedures", RFC 4288, December 2005.

   [RFC4346]  Dierks, T. and E. Rescorla, "The Transport Layer Security
              (TLS) Protocol Version 1.1", RFC 4346, April 2006.

   [RFC4366]  Blake-Wilson, S., Nystrom, M., Hopwood, D., Mikkelsen, J.,
              and T. Wright, "Transport Layer Security (TLS)
              Extensions", RFC 4366, April 2006.

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



Pritikin, et al.       Expires September 30, 2013              [Page 39]

Internet-Draft                     EST                        March 2013


              Encodings", RFC 4648, October 2006.

   [RFC5054]  Taylor, D., Wu, T., Mavrogiannopoulos, N., and T. Perrin,
              "Using the Secure Remote Password (SRP) Protocol for TLS
              Authentication", RFC 5054, November 2007.

   [RFC5077]  Salowey, J., Zhou, H., Eronen, P., and H. Tschofenig,
              "Transport Layer Security (TLS) Session Resumption without
              Server-Side State", RFC 5077, January 2008.

   [RFC5272]  Schaad, J. and M. Myers, "Certificate Management over CMS
              (CMC)", RFC 5272, June 2008.

   [RFC5273]  Schaad, J. and M. Myers, "Certificate Management over CMS
              (CMC): Transport Protocols", RFC 5273, June 2008.

   [RFC5274]  Schaad, J. and M. Myers, "Certificate Management Messages
              over CMS (CMC): Compliance Requirements", RFC 5274,
              June 2008.

   [RFC5280]  Cooper, D., Santesson, S., Farrell, S., Boeyen, S.,
              Housley, R., and W. Polk, "Internet X.509 Public Key
              Infrastructure Certificate and Certificate Revocation List
              (CRL) Profile", RFC 5280, May 2008.

   [RFC5652]  Housley, R., "Cryptographic Message Syntax (CMS)", STD 70,
              RFC 5652, September 2009.

   [RFC5746]  Rescorla, E., Ray, M., Dispensa, S., and N. Oskov,
              "Transport Layer Security (TLS) Renegotiation Indication
              Extension", RFC 5746, February 2010.

   [RFC5751]  Ramsdell, B. and S. Turner, "Secure/Multipurpose Internet
              Mail Extensions (S/MIME) Version 3.2 Message
              Specification", RFC 5751, January 2010.

   [RFC5785]  Nottingham, M. and E. Hammer-Lahav, "Defining Well-Known
              Uniform Resource Identifiers (URIs)", RFC 5785,
              April 2010.

   [RFC5929]  Altman, J., Williams, N., and L. Zhu, "Channel Bindings
              for TLS", RFC 5929, July 2010.

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

   [RFC5967]  Turner, S., "The application/pkcs10 Media Type", RFC 5967,
              August 2010.



Pritikin, et al.       Expires September 30, 2013              [Page 40]

Internet-Draft                     EST                        March 2013


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

   [SHS]      National Institute of Standards and Technology, "Federal
              Information Processing Standard Publication 180-4: Secure
              Hash Standard (SHS)", March 2012, <http://csrc.nist.gov/
              publications/fips/fips180-4/fips-180-4.pdf>.

   [X.680]    ITU-T Recommendation, "ITU-T Recommendation X.680 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, "ITU-T Recommendation X.690 ASN.1
              encoding rules: Specification of Basic Encoding Rules
              (BER), Canonical Encoding Rules (CER) and Distinguished
              Encoding Rules (DER)", November 2008,
              <http://www.itu.int/rec/T-REC-X.690-200811-I/en>.

8.2.  Informative References

   [IDevID]   IEEE Std, "IEEE 802.1AR Secure Device Identifier",
              December 2009, <http://standards.ieee.org/findstds/
              standard/802.1AR-2009.html>.

   [RFC2397]  Masinter, L., "The "data" URL scheme", RFC 2397,
              August 1998.

   [RFC2712]  Medvinsky, A. and M. Hur, "Addition of Kerberos Cipher
              Suites to Transport Layer Security (TLS)", RFC 2712,
              October 1999.

   [RFC3394]  Schaad, J. and R. Housley, "Advanced Encryption Standard
              (AES) Key Wrap Algorithm", RFC 3394, September 2002.

   [RFC6403]  Zieglar, L., Turner, S., and M. Peck, "Suite B Profile of
              Certificate Management over CMS", RFC 6403, November 2011.

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



Pritikin, et al.       Expires September 30, 2013              [Page 41]

Internet-Draft                     EST                        March 2013


              publications/nistpubs/800-57/
              sp800-57_part1_rev3_general.pdf>.

   [X.520]    ITU-T Recommendation, "ITU-T Recommendation X.520 The
              Directory: Selected attribute types", November 2008,
              <http://www.itu.int/rec/T-REC-X.520-200811-I/en>.


Appendix A.  Operational Scenario Example Messages

   (informative)

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

A.1.  Obtaining CA Certificates

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

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

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

   In response the server provides the current CA certificates:
   HTTP/1.1 200 OK
   Status: 200 OK
   Content-Type: application/pkcs7-mime
   Content-Transfer-Encoding: base64
   Content-Length: 4181

   MIIMCQYJKoZIhvcNAQcCoIIL+jCCC/YCAQExADALBgkqhkiG9w0BBwGgggvcMIIC
   6DCCAdCgAwIBAgIJAOp44LEB7buwMA0GCSqGSIb3DQEBBQUAMBsxGTAXBgNVBAMT
   EGVzdEV4YW1wbGVDQSBPd08wHhcNMTMwMzIwMjI1NTMwWhcNMTQwMzIwMjI1NTMw
   WjAbMRkwFwYDVQQDExBlc3RFeGFtcGxlQ0EgT3dPMIIBIjANBgkqhkiG9w0BAQEF
   AAOCAQ8AMIIBCgKCAQEA3fJbVP2x1kDpCqMGgMS5YIsP1CeINHM6yuaS/PLgtcxw
   Wr07XUZPypgo6HTwYKTksmYZ5q4NObmRtjUYTRBO0OimKweNkv+peDJ7K7ItxrW9
   nCFE4MapAJI3ZmOnBOVMglHL+5vRq7PD+m65zTz++8FSkEpVPfIxNkakw263EIl/
   i3otp97J9z8fY6ep0kTLGpKaNC/gBeprX74IZEW2mynrkaVDFPIJr2iaPmc/H4pN
   wU82DVcES6PI13mxH+aMVCfrz/CZzqgwY6bNtVHV3mI6XEUTcnzABtAO4rqm5YTm
   xQrOH5fTCPHXDYFRHF+DOCIhWXgXSl4wv30iUT+/IwIDAQABoy8wLTAMBgNVHRME
   BTADAQH/MB0GA1UdDgQWBBSnQZgJxiXNt/pNMgOcDzZ7W1foODANBgkqhkiG9w0B
   AQUFAAOCAQEAA1N9Xsu86NZgkhfpOQi2iouXRrFeW7dsr4UkFxwjnCdFTV7RQ/XR



Pritikin, et al.       Expires September 30, 2013              [Page 42]

Internet-Draft                     EST                        March 2013


   MKvAmW6QyBf4kYd0iLt+iRY9EA9aS7cZutLVK0MezYqWO5yfr1MnWu9jcyMsnT5g
   KFJ11MKtgMmXfOHCZ6e5L8PzIJ0q40NVb6hrPasZK84ew12Gb23GN2FUeSucCFlc
   CuiOLpaMYtS60gwd8B3Nbg4Kptvbv113SeIKie3RsIMZxhbTD2htBQ6Y3TeDF1ea
   Hq9wLJIwggBlPy7Isp+gyp1uB++RU3J4xn1WI6BAdUM7FiZ+JaVnJOwK0SO1px7L
   qyzfzwL0D1cIQz7MeRK/9URKKTyjoSUm3jCCAv4wggHmoAMCAQICAQEwDQYJKoZI
   hvcNAQEFBQAwGzEZMBcGA1UEAxMQZXN0RXhhbXBsZUNBIE93TzAeFw0xMzAzMjAy
   MjU1MzFaFw0xNDAzMjAyMjU1MzFaMBsxGTAXBgNVBAMTEGVzdEV4YW1wbGVDQSBO
   d08wggEiMA0GCSqGSIb3DQEBAQUAA4IBDwAwggEKAoIBAQC4Qnq1DrvZea5fx/gG
   IAveDvI3GXb9uAMm443EAdSiIZSiWU3A7tT0uA+BC/Ddn9iWja8m3YDP9+zAcaEJ
   iZZFLa+s+7yOPS6UwrIxMvDzevHT/hEae4eDrs+dDysjcEr0YGk78EPL5jCISeLX
   8sGn+vt/CV03H8rx5iUAFMnK5gaTWBQJbYu3RAPXUptEOOM7Skcx/DObrmQNd8B0
   GJgW4bZcIjMt5VIBM7FKTTF70Re8hy05FPFSp6yzCmjXpuox6vKke1ISOzWE3zw2
   lAjKv7wtVu4THBAk+0jcrZFsCxnvlaQXFhHhMwYvEbfq9+KRT5xb3zjhtpd54wNp
   sw09AgMBAAGjTTBLMAkGA1UdEwQCMAAwHQYDVR0OBBYEFI5rJ3wKlAo28FkeRGZ0
   5C8QQmyhMB8GA1UdIwQYMBaAFKdBmAnGJc23+k0yA5wPNntbV+g4MA0GCSqGSIb3
   DQEBBQUAA4IBAQBd03qDjEYiOtaFA6i7U6PF+ZUEl2Z0+vvtT/jIlpbCOXO2M54v
   Do6FFYe7YzF+XkG5ZqquMIgzSGR53GNkUPjTJZ/DHzRn1garcVGnr8rsk/+PPDvZ
   vqLc5SGQBk9KfZMV0oMOqlvioFP3oxdWwyyhJ2cY2qbP1s9uGSXg5uPmBKbboX7G
   P13bEoApMRr49nfPNMtiIs6BU7tyurPG2/mCcN1BX4P365CxqMAB2krP9mAhxYaA
   e98XLBz3yQ8CaMoAjX+B6fXzf30e5s7F3Nd8S5G4vsC92Iugre+yPyp6afQsjcbU
   pqvP/16M1z22ZKfoXkfoCyLbggLPGbI6MSVEMIIC/jCCAeagAwIBAgIBAjANBgkq
   hkiG9w0BAQUFADAbMRkwFwYDVQQDExBlc3RFeGFtcGxlQ0EgTndOMB4XDTEzMDMy
   MDIyNTUzMVoXDTE0MDMyMDIyNTUzMVowGzEZMBcGA1UEAxMQZXN0RXhhbXBsZUNB
   IE93TjCCASIwDQYJKoZIhvcNAQEBBQADggEPADCCAQoCggEBAN3yW1T9sdZA6Qqj
   BoDEuWCLD9QniDRzOsrmkvzy4LXMcFq9O11GT8qYKOh08GCk5LJmGeauDTm5kbY1
   GE0QTtDopisHjZL/qXgyeyuyLca1vZwhRODGqQCSN2ZjpwTlTIJRy/ub0auzw/pu
   uc08/vvBUpBKVT3yMTZGpMNutxCJf4t6Lafeyfc/H2OnqdJEyxqSmjQv4AXqa1++
   CGRFtpsp65GlQxTyCa9omj5nPx+KTcFPNg1XBEujyNd5sR/mjFQn68/wmc6oMGOm
   zbVR1d5iOlxFE3J8wAbQDuK6puWE5sUKzh+X0wjx1w2BURxfgzgiIVl4F0peML99
   IlE/vyMCAwEAAaNNMEswCQYDVR0TBAIwADAdBgNVHQ4EFgQUp0GYCcYlzbf6TTID
   nA82e1tX6DgwHwYDVR0jBBgwFoAUjmsnfAqUCjbwWR5EZnTkLxBCbKEwDQYJKoZI
   hvcNAQEFBQADggEBAKriJh0+BtoHOhCMVshYt8Org80jCMIDY1KYuXJO9avg2P/l
   bQOQ2ED+qE8xmUf6T/h/yv2550ICUJ98KY3xCUsATHcX6b5vOENlC3N/STtUrVPG
   33sN+daU5NwsciUnMl3SoqeZRHSJDopNORsslFF2Av4+A7hkeaER9oNzP+Jj5sEC
   t5/1jOtKu7YxZnMOUOqXoYXa4R8cI50iMQxdd32z8d+eJRgxd66YS5+MzOL/Wc4o
   nP3rvkpk820kRTELAk61Dv/xjpa05cyxTJtRvQwNxQMdgHaFKYd9owStHFMZuBI3
   mBH3V0jq4IAYVTQzBfhDmaGh230/WabUcYOgtXIwggLoMIIB0KADAgECAgkAxzoD
   SD8/y/gwDQYJKoZIhvcNAQEFBQAwGzEZMBcGA1UEAxMQZXN0RXhhbXBsZUNBIE53
   TjAeFw0xMzAzMjAyMjU1MzFaFw0xNDAzMjAyMjU1MzFaMBsxGTAXBgNVBAMTEGVz
   dEV4YW1wbGVDQSBOd04wggEiMA0GCSqGSIb3DQEBAQUAA4IBDwAwggEKAoIBAQC4
   Qnq1DrvZea5fx/gGIAveDvI3GXb9uAMm443EAdSiIZSiWU3A7tT0uA+BC/Ddn9iW
   ja8m3YDP9+zAcaEJiZZFLa+s+7yOPS6UwrIxMvDzevHT/hEae4eDrs+dDysjcEr0
   YGk78EPL5jCISeLX8sGn+vt/CV03H8rx5iUAFMnK5gaTWBQJbYu3RAPXUptEOOM7
   Skcx/DObrmQNd8B0GJgW4bZcIjMt5VIBM7FKTTF70Re8hy05FPFSp6yzCmjXpuox
   6vKke1ISOzWE3zw2lAjKv7wtVu4THBAk+0jcrZFsCxnvlaQXFhHhMwYvEbfq9+KR
   T5xb3zjhtpd54wNpsw09AgMBAAGjLzAtMAwGA1UdEwQFMAMBAf8wHQYDVR0OBBYE
   FI5rJ3wKlAo28FkeRGZ05C8QQmyhMA0GCSqGSIb3DQEBBQUAA4IBAQAjhssE+fXi
   RW+c8+ORpHaYOYS/o+O9Ui60W1kkK0TSKDoeJD7z7BWdIoj1hNbahQZOO8AzSulY



Pritikin, et al.       Expires September 30, 2013              [Page 43]

Internet-Draft                     EST                        March 2013


   knNVdonCC3AtPuBYndnPulF0cQifKEQCZDx00IkPr6+0o60aX4kWRBRiavzaHdqJ
   /+xL0K/P1NlIdkbx93Xb8/XLQ01wOBCFSmPmQ22k/Of+EydB+nteGsYvIoCuxsBw
   ZBKUMX//tKi2BUTS31WA6IRAolTL8V5IgyYP8Ub0M4n/fr5/tqzCjw5aiJ1ga4ED
   yrpd9XSBO3Og5/AWtr3BCaWkY8fiRt9ZcSmTWRWL84nAELGZEuEKODA4WMdY76TF
   Rs8Se9pRkVgxoQAxAA==

A.2.  Enroll/ReEnroll

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

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

   During the initial TLS handshake the client can ignore the optional
   server generated "certificate request" and can instead proceed with
   the HTTP POST request.  In response to the initial HTTP POST attempt
   the server requests WWW-Authenticate from the client (this might
   occur even if the client used a client certificate, as detailed in
   the normative text above):
   HTTP/1.1 401 Unauthorized
   Content-Length: 0
   WWW-Authenticate: Digest qop="auth", realm="estrealm",
   nonce="1363821319"


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



















Pritikin, et al.       Expires September 30, 2013              [Page 44]

Internet-Draft                     EST                        March 2013


   POST /.well-known/est/simpleEnroll HTTP/1.1
   Authorization: Digest username="estuser", realm="estrealm", nonc
   e="1363821164", uri="/.well-known/est/simpleEnroll", cnonce="MDY
   2OTcz", nc=00000002, qop="auth", response="93731653b26bd4693de10
   2745c294769"
   User-Agent: curl/7.22.0 (i686-pc-linux-gnu) libcurl/7.22.0 OpenS
   SL/1.0.1 zlib/1.2.3.4 libidn/1.23 librtmp/2.3
   Host: 127.0.0.1:8085
   Accept: */*
   Content-Type: application/pkcs10
   Content-Transfer-Encoding: base64
   Content-Length: 882

   MIIChjCCAW4CAQAwQTElMCMGA1UEAxMccmVxIGJ5IGNsaWVudCBpbiBkZW1vIHN0
   ZXAgMjEYMBYGA1UEBRMPUElEOldpZGdldCBTTjoyMIIBIjANBgkqhkiG9w0BAQEF
   AAOCAQ8AMIIBCgKCAQEA4Pw1JvjhOFL87eMmhIA/bXDORRItgxRZwq6FEQ3cWQvO
   wiA52hiAfrh/vQZFxIO/d44msbSxwbnG61aOEohhQgijUUGn2VxDi5S2xKUZAxnF
   +UfIP7PpZFg5c6aGO94ZFg6gT8iI0nRtXvd/T272sTY7n8GTKHfWhzv1nUV11DOz
   hWG57UC5+rfSqjNhiqtRsHM94emXR7rtjtfqY6KFN08x/z5CFKq+EmI5+1GmyUmb
   zfiCiFejgSULvHqtuMtVuqyaUDWKil0VRbFu0QK3oy5GiIsC4qwoguDRHsW7yO4E
   5BOLgK9n5PldpJNdEjyEgS7+dl5MD0nI5j2/pfeFkQIDAQABoAAwDQYJKoZIhvcN
   AQEFBQADggEBAKyuduqjuFc9INrFzvXSz1ZXU68FZtrmlaMfYRbk0xKbVAbB9dwe
   /NmkPQCQWGpiVyXo4rKgclcenlOYuFRbFGOxzprO9x0b99NNMP2bZscIUf0f6Xhb
   FXoGb6mFpft2HU4U1/hLmjOzBPeOOrcYrYqPTlDd+iniIMPTMn2ytP7ph6YEhc9S
   6W4O2VrBQQVhefoPh36MU4PvUF4+pbiPWkDzLvjTg01FB5rz3ECVVyodDgzVSeIT
   f3JxhMaYnfxcQ0ELdhhgSxcQhnfFSqc/k7LiAWE0yzUFJj3qilPBRJ2Q+uqA74Ct
   WHSWUBnkq5W4ZKpmxaqFxeZKy/Eyapyqwuk=


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




















Pritikin, et al.       Expires September 30, 2013              [Page 45]

Internet-Draft                     EST                        March 2013


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

   MIIDVQYJKoZIhvcNAQcCoIIDRjCCA0ICAQExADALBgkqhkiG9w0BBwGgggMoMIID
   JDCCAgygAwIBAgIBGjANBgkqhkiG9w0BAQUFADAbMRkwFwYDVQQDExBlc3RFeGFt
   cGxlQ0EgTndOMB4XDTEzMDMyMDIzMTUxOVoXDTE0MDMyMDIzMTUxOVowQTElMCMG
   A1UEAxMccmVxIGJ5IGNsaWVudCBpbiBkZW1vIHN0ZXAgMjEYMBYGA1UEBRMPUElE
   OldpZGdldCBTTjoyMIIBIjANBgkqhkiG9w0BAQEFAAOCAQ8AMIIBCgKCAQEA4Pw1
   JvjhOFL87eMmhIA/bXDORRItgxRZwq6FEQ3cWQvOwiA52hiAfrh/vQZFxIO/d44m
   sbSxwbnG61aOEohhQgijUUGn2VxDi5S2xKUZAxnF+UfIP7PpZFg5c6aGO94ZFg6g
   T8iI0nRtXvd/T272sTY7n8GTKHfWhzv1nUV11DOzhWG57UC5+rfSqjNhiqtRsHM9
   4emXR7rtjtfqY6KFN08x/z5CFKq+EmI5+1GmyUmbzfiCiFejgSULvHqtuMtVuqya
   UDWKil0VRbFu0QK3oy5GiIsC4qwoguDRHsW7yO4E5BOLgK9n5PldpJNdEjyEgS7+
   dl5MD0nI5j2/pfeFkQIDAQABo00wSzAJBgNVHRMEAjAAMB0GA1UdDgQWBBSxOOKP
   RyQb246sgl7MxX+t1fvpWzAfBgNVHSMEGDAWgBSOayd8CpQKNvBZHkRmdOQvEEJs
   oTANBgkqhkiG9w0BAQUFAAOCAQEAgTNqMhUL1p5TNHiH9McYZuhKF1gW3dLxYpnj
   QweZcnSq/cEr1/qRTmMoyb25OySPHzE7Puqh2M2KQb/LqsB/4G1wuQY7eeumOcd+
   xwrC8ic+jZaxcNA0+PNXvMdP9JafHZqZVTgF9DoD8a0++7UzUnXG2zSgkN5bvgik
   kcAP/D4/4Y1PNFDnolCFg5qGRwCXkPxQU7k458OZI8KHWGXTf5p8Vdo91tVH3LwM
   e9qeUMS7U8vRtOLye9PsRQ0rsGX3XDATDD6cPvRaImQRDtD0Uludl5QGw3Dxa1FI
   5zziAdaLFFbfLx6D/HfHrRZe9OLtkPc+1X3LSITE94VEzHfsSqEAMQA=


A.3.  Server Key Generation

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

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
















Pritikin, et al.       Expires September 30, 2013              [Page 46]

Internet-Draft                     EST                        March 2013


   POST /.well-known/est/serverKeyGen HTTP/1.1
   User-Agent: curl/7.22.0 (i686-pc-linux-gnu) libcurl/7.22.0 OpenS
   SL/1.0.1 zlib/1.2.3.4 libidn/1.23 librtmp/2.3
   Host: 127.0.0.1:8085
   Accept: */*
   Content-Type: application/pkcs10
   Content-Transfer-Encoding: base64
   Content-Length: 898

   MIICkzCCAXsCAQAwTjEyMDAGA1UEAxMpc2VydmVyS2V5R2VuIHJlcSBieSBjbGll
   bnQgaW4gZGVtbyBzdGVwIDUxGDAWBgNVBAUTD1BJRDpXaWRnZXQgU046NTCCASIw
   DQYJKoZIhvcNAQEBBQADggEPADCCAQoCggEBAL3VrdX1IaAcEhQepAtRoA3vhrl/
   tVS7ANr8SfCEt6xLNG6YorHoF+jSSYc7bE4gPC1cPkVs8a/tpySnHglD3WdJiCi4
   o9ClCl8FZzvqpLS4YSpLEtcBQCBItDCaObJzJbyaxS7XnJUUbXd2vbjPla5P7m9R
   69LEx0pODY5v2m1ck/0zPUvQRbo61jiXKrzaD4ufYZlD90SZq8Z5Br3caP9GAK9m
   pf1MdoRpbz62r1+2IljfcVnGIktHy7pY3l8+UlengC3/UybmkKxuaiE8yFBYiImw
   iM9GrUSWQCWvrQrk11U9xodCRlLr6Ywe6G7Pb96Oyt2uHW1Qu2sdjR4Kqz8CAwEA
   AaAAMA0GCSqGSIb3DQEBBQUAA4IBAQAK6QaV4VgbeGm1tDPu1vX5H7Q6GzPwJZLK
   VwyvI3mLXA6vRAfcd20q0rJNddGL9A555L2dEuS4Qo3iqiPBh067M/TUvYU73dSl
   kLl0rmqw/Iocvs7LTv4DoCiElmQq2vMIK6IN3vUm96csvDB6WQbd3eqKyPeHlJQf
   HAKhpoAn2bls1OLssOmIcWwtZ00GbchIy9XDzJSXKI8EIxZOK1xQ3p5cRO0kNcx9
   /MbSg+/wjJ9Xk2DTUux2DOCskCbyc7sizZWF4+LPBtaJOihT5sZyVgEE03hCYAVv
   U8z1QKILkt7t7VpWj9GpSHqTWFAyIf4xtfsJwZQWhdsbyT3zZUxS


   Because the DecryptKeyIdentifier attribute is not included in the
   request the response does not include additional encryption beyond
   the TLS session.  The EST server response is:
   HTTP/1.1 200 OK
   Status: 200 OK
   Content-Type: multipart/mixed ; boundary=estServerExampleBoundary
   Content-Length: 3211

   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

   MIIEvQIBADANBgkqhkiG9w0BAQEFAASCBKcwggSjAgEAAoIBAQDUuonyyFBAQzHY
   QiHK7pLMc0jDR4LSKtTNQ+Ng9vNMy/PUoJscXKwJzy+D36oLteAKlwIlgAYWMjS6
   0VnNN5zLzA43xAIZy4n6yDiCjXNOKiC7S4zC4c5e1wZbOnkBhxVb0T2pZ+DqQHqN
   z0GoWv0KYm8g5gLsJs4yrUxMB5KuevXI4NE7hUoAciYncX7gkZsHANHVpx2nw0d4
   3fyLSs21t2vkFvUvDBSQYaXEhZczjf2Yx1riz/E0j9hKUVDVOgCOLYGUvt27MAwk
   XFiEtKSOHzuZq+cTjEHcRUXvFwJLjx1+tcssbLZKwbXHpGnCP5GY2eW5YwMToI23
   Gn6FYKoLAgMBAAECggEAHI0czrUL8FQUcI4PswjqMv6WGX+Tk1mkThh6gB0k8n29
   MCCOMPRPMtHX8r8mN4QlmcZCx32zU29RnHFUuDJqnP+6OMnZ7lRfJIWS8BLEEw2c



Pritikin, et al.       Expires September 30, 2013              [Page 47]

Internet-Draft                     EST                        March 2013


   bwbo0Y80/42kkMH8U7QprbUbrYz/pvEYgcf7a/kqVSZ4+9VjNwbOTgbsYpfxm/Eu
   HAJVqP6Xe6tJ3bamrWteyjGvCc7QmF54srok+sPBx8uWSwogUEaPAm/DQge0XMR4
   rEyuTsaxmk3LZcVRaS3A0GzIFpFlhP3v3tIS8vE/2d1XV//F6rgXS8x1AEAHl/lw
   dNvH6YJGyT1hP1GKaoK5Oa2E9GsAGvmLEx6PAz+AgQKBgQD5YrzfL5+GAqjYLBuy
   Sdrlwxom90C4TNoFbWil7LIEQ+M47cOa5n+lYeFcEC1i6NLZodWYHU9sJ7khf3kC
   zCzPs+tCVtgZdeEQ/gAYkZB5zWriFugrIS9cHOl1jUvA+VSfbBRRfUxw+XCJt411
   E+o1kv0Tj0s5fMHsmb2Akn/V+wKBgQDaXujfrBRRfPLv41aaS3LykjxQbYnVQVOh
   tEvJQ2vVkKO1gVCT1vV2fKcBW4yFp0IGfSIdPjJkqEW51PPNjiPVhMM4vczNoYa4
   MDL8oaTXqDjptj8Ud5n1HiEAF5tLzG+Q3Ym0ND4uZc0zJNja85FwJrqEkxoZviuj
   MN+qbO0PMQKBgBUfft3sm7dvHDwLKGFmjgruBpYMVUgHAmR5Suba8I0Z7vIQeYPy
   SBeK/dqdaCq7i7hxU7UprmN7zdt/f5F0F8uT8rZQwscNS/3zdbCfC7y1YHs783hL
   vEYyELgrOqJiu/8w2Vu5oDLlfdm8WVf0Ut8szxDMD1QUNBzFPN7aCcfnAoGALJDY
   F+Xnk6XbcqfD4eNqByVfF87zJUmaxtKj8ORImqJVNtK4XiOtnsvbzYQgjppO+EIL
   d0pdQHuzFzTluNq8Z3Qb33Wk2YaQlwCHN1XJ7ZVQYCoof4XVLthCReGLeRG05yy/
   UL6kvhVapohrlWvGD8xnnmzjE8Pi5gAwdXibfNECgYEAviTObA3hGULCT4YZ33wQ
   BQjFV2ktUegkNofeTsdixYq+rBJp/KTb/YKSLsqTFfHxmFLDbEKl2hWLCmjQtqjb
   s8/XAffa5adeMV1uAcSM8M2ngJM9BNYPg7uD7odVfBgjT/CGUsq9/vYdN4xhqctp
   MRWeTA9hNk730g8tNnL92K4=
   --estServerExampleBoundary
   Content-Type: application/pkcs7-mime
   Content-Transfer-Encoding: base64

   MIIDQAYJKoZIhvcNAQcCoIIDMTCCAy0CAQExADALBgkqhkiG9w0BBwGgggMTMIID
   DzCCAfegAwIBAgIBGzANBgkqhkiG9w0BAQUFADAbMRkwFwYDVQQDExBlc3RFeGFt
   cGxlQ0EgTndOMB4XDTEzMDMyMDIzMzkyOFoXDTE0MDMyMDIzMzkyOFowLDEqMCgG
   A1UEAxMhc2VydmVyc2lkZSBrZXkgZ2VuZXJhdGVkIHJlc3BvbnNlMIIBIjANBgkq
   hkiG9w0BAQEFAAOCAQ8AMIIBCgKCAQEA1LqJ8shQQEMx2EIhyu6SzHNIw0eC0irU
   zUPjYPbzTMvz1KCbHFysCc8vg9+qC7XgCpcCJYAGFjI0utFZzTecy8wON8QCGcuJ
   +sg4go1zTiogu0uMwuHOXtcGWzp5AYcVW9E9qWfg6kB6jc9BqFr9CmJvIOYC7CbO
   Mq1MTAeSrnr1yODRO4VKAHImJ3F+4JGbBwDR1acdp8NHeN38i0rNtbdr5Bb1LwwU
   kGGlxIWXM439mMda4s/xNI/YSlFQ1ToAji2BlL7duzAMJFxYhLSkjh87mavnE4xB
   3EVF7xcCS48dfrXLLGy2SsG1x6Rpwj+RmNnluWMDE6CNtxp+hWCqCwIDAQABo00w
   SzAJBgNVHRMEAjAAMB0GA1UdDgQWBBRawN1+4APoSakGRwvD/6i2s+4pDDAfBgNV
   HSMEGDAWgBSOayd8CpQKNvBZHkRmdOQvEEJsoTANBgkqhkiG9w0BAQUFAAOCAQEA
   YtPAbK4t+sk2ec5svdiNgvK8nsXpyTaHUyX9shuMfTghL/sA6HoSL8y55Cq2pAC/
   Ts+vLWvjeJoN8xH7F9lLjx74gFmq/oxkysYCXsc5VcD4Pw5ppQvAL0n52WgX6MZh
   GqbGIJykJGvg/FSjqrt4oGo/RQakPnB7dJY/fp9k27DV2nTTkISgPSUzDglM94yj
   AbktKu32LN1kv8mt8wBEl1cNUAA2ZpZmzp9fnMgaFNgZBqpbjg07SkgEu8NRcMA5
   ffE3BoMxMRCtGUznugNtlYnYzOVppaT7pkSSpdv8Lt4k3Zh5E/nRl1OERkHUxn7N
   f7pEl6EI99JfWRNHIXMXvKEAMQA=
   --estServerExampleBoundary--
   This is the epilogue. It is also to be ignored.

A.4.  CSR Attributes

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



Pritikin, et al.       Expires September 30, 2013              [Page 48]

Internet-Draft                     EST                        March 2013


   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: 127.0.0.1:8085
   Accept: */*


   In response the server provides suggested attributes that are
   appropriate for the authenticated client:
   HTTP/1.1 200 OK
   Status: 200 OK
   Content-Type: application/csrattrs
   Content-Transfer-Encoding: base64
   Content-Length: 57

   MCYGBysGAQEBARYGCSqGSIb3DQEJBwYFK4EEACIGCWCGSAFlAwQCAg==


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.       Expires September 30, 2013              [Page 49]


Html markup produced by rfcmarkup 1.107, available from http://tools.ietf.org/tools/rfcmarkup/