doc: Add RFC documents

1 files changed, 2971 insertions, 0 deletions

diff --git a/doc/rfc/rfc7030.txt b/doc/rfc/rfc7030.txt
new file mode 100644
index 0000000..d1d710c
--- /dev/null
+++ b/doc/rfc/rfc7030.txt
@@ -0,0 +1,2971 @@
+
+
+
+
+
+
+Internet Engineering Task Force (IETF)                  M. Pritikin, Ed.
+Request for Comments: 7030                           Cisco Systems, Inc.
+Category: Standards Track                                    P. Yee, Ed.
+ISSN: 2070-1721                                             AKAYLA, Inc.
+                                                         D. Harkins, Ed.
+                                                          Aruba Networks
+                                                            October 2013
+
+
+                    Enrollment over Secure Transport
+
+Abstract
+
+   This document profiles certificate enrollment for clients using
+   Certificate Management over CMS (CMC) messages over a secure
+   transport.  This profile, called Enrollment over Secure Transport
+   (EST), describes a simple, yet functional, certificate management
+   protocol targeting Public Key Infrastructure (PKI) clients that need
+   to acquire client certificates and associated Certification Authority
+   (CA) certificates.  It also supports client-generated public/private
+   key pairs as well as key pairs generated by the CA.
+
+Status of This Memo
+
+   This is an Internet Standards Track document.
+
+   This document is a product of the Internet Engineering Task Force
+   (IETF).  It represents the consensus of the IETF community.  It has
+   received public review and has been approved for publication by the
+   Internet Engineering Steering Group (IESG).  Further information on
+   Internet Standards is available in Section 2 of RFC 5741.
+
+   Information about the current status of this document, any errata,
+   and how to provide feedback on it may be obtained at
+   http://www.rfc-editor.org/info/rfc7030.
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Pritikin, et al.             Standards Track                    [Page 1]
+
+RFC 7030                           EST                      October 2013
+
+
+Copyright Notice
+
+   Copyright (c) 2013 IETF Trust and the persons identified as the
+   document authors.  All rights reserved.
+
+   This document is subject to BCP 78 and the IETF Trust's Legal
+   Provisions Relating to IETF Documents
+   (http://trustee.ietf.org/license-info) in effect on the date of
+   publication of this document.  Please review these documents
+   carefully, as they describe your rights and restrictions with respect
+   to this document.  Code Components extracted from this document must
+   include Simplified BSD License text as described in Section 4.e of
+   the Trust Legal Provisions and are provided without warranty as
+   described in the Simplified BSD License.
+
+Table of Contents
+
+   1. Introduction ....................................................3
+      1.1. Terminology ................................................4
+   2. Operational Scenario Overviews ..................................5
+      2.1. Obtaining CA Certificates ..................................6
+      2.2. Initial Enrollment .........................................7
+           2.2.1. Certificate TLS Authentication ......................8
+           2.2.2. Certificate-Less TLS Authentication .................8
+           2.2.3. HTTP-Based Client Authentication ....................8
+      2.3. Client Certificate Reissuance ..............................8
+      2.4. Server Key Generation ......................................9
+      2.5. Full PKI Request Messages ..................................9
+      2.6. Certificate Signing Request (CSR) Attributes Request .......9
+   3. Protocol Design and Layering ...................................10
+      3.1. Application Layer .........................................13
+      3.2. HTTP Layer ................................................14
+           3.2.1. HTTP Headers for Control ...........................15
+           3.2.2. HTTP URIs for Control ..............................16
+           3.2.3. HTTP-Based Client Authentication ...................17
+           3.2.4. Message Types ......................................19
+      3.3. TLS Layer .................................................20
+           3.3.1. TLS-Based Server Authentication ....................20
+           3.3.2. TLS-Based Client Authentication ....................21
+           3.3.3. Certificate-Less TLS Mutual Authentication .........21
+      3.4. Proof-of-Possession .......................................22
+      3.5. Linking Identity and POP Information ......................22
+      3.6. Server Authorization ......................................23
+           3.6.1. Client Use of Explicit TA Database .................24
+           3.6.2. Client Use of Implicit TA Database .................24
+      3.7. Client Authorization ......................................24
+   4. Protocol Exchange Details ......................................25
+      4.1. Distribution of CA Certificates ...........................25
+
+
+
+Pritikin, et al.             Standards Track                    [Page 2]
+
+RFC 7030                           EST                      October 2013
+
+
+           4.1.1. Bootstrap Distribution of CA Certificates ..........25
+           4.1.2. CA Certificates Request ............................26
+           4.1.3. CA Certificates Response ...........................26
+      4.2. Client Certificate Request Functions ......................27
+           4.2.1. Simple Enrollment of Clients .......................28
+           4.2.2. Simple Re-enrollment of Clients ....................29
+           4.2.3. Simple Enroll and Re-enroll Response ...............29
+      4.3. Full CMC ..................................................30
+           4.3.1. Full CMC Request ...................................30
+           4.3.2. Full CMC Response ..................................30
+      4.4. Server-Side Key Generation ................................31
+           4.4.1. Server-Side Key Generation Request .................32
+                  4.4.1.1. Requests for Symmetric Key
+                           Encryption of the Private Key .............32
+                  4.4.1.2. Requests for Asymmetric Encryption
+                           of the Private Key ........................33
+           4.4.2. Server-Side Key Generation Response ................33
+      4.5. CSR Attributes ............................................35
+           4.5.1. CSR Attributes Request .............................35
+           4.5.2. CSR Attributes Response ............................35
+   5. IANA Considerations ............................................37
+   6. Security Considerations ........................................39
+   7. References .....................................................41
+      7.1. Normative References ......................................41
+      7.2. Informative References ....................................43
+   Appendix A. Operational Scenario Example Messages .................45
+     A.1. Obtaining CA Certificates ..................................45
+     A.2. CSR Attributes .............................................47
+     A.3. Enroll/Re-enroll ...........................................47
+     A.4. Server Key Generation ......................................50
+   Appendix B. Contributors and Acknowledgements .....................52
+
+1.  Introduction
+
+   This document profiles certificate enrollment for clients using
+   Certificate Management over CMS (CMC) [RFC5272] messages over a
+   secure transport.  Enrollment over Secure Transport (EST) describes
+   the use of Transport Layer Security (TLS) 1.1 [RFC4346], 1.2
+   [RFC5246], or any future version) and Hypertext Transfer Protocol
+   (HTTP) [RFC2616] to provide an authenticated and authorized channel
+   for Simple Public Key Infrastructure (PKI) Requests and Responses
+   [RFC5272].
+
+   Architecturally, the EST service is located between a Certification
+   Authority (CA) and a client.  It performs several functions
+   traditionally allocated to the Registration Authority (RA) role in a
+   PKI.  The nature of communication between an EST server and a CA is
+   not described in this document.
+
+
+
+Pritikin, et al.             Standards Track                    [Page 3]
+
+RFC 7030                           EST                      October 2013
+
+
+   EST adopts the Certificate Management Protocol (CMP) [RFC4210] model
+   for CA certificate rollover, but it does not use the CMP message
+   syntax or protocol.  EST servers are extensible in that new functions
+   may be defined to provide additional capabilities not specified in
+   CMC [RFC5272], and this document defines two such extensions: one for
+   requesting Certificate Signing Request attributes and another for
+   requesting server-generated keys.
+
+   EST specifies how to transfer messages securely via HTTP over TLS
+   (HTTPS) [RFC2818], where the HTTP headers and media types are used in
+   conjunction with TLS.  HTTPS operates over TCP; this document does
+   not specify EST over HTTP/Datagram Transport Layer Security/User
+   Datagram Protocol (HTTP/DTLS/UDP).  With a suitable specification for
+   combining HTTP, DTLS, and UDP, there are no EST requirements that
+   would prevent it from working over such a stack.  Figure 1 shows how
+   the layers build upon each other.
+
+   EST Layering:
+
+   Protocols:
+   +--------------------------------------------+
+   |                                            |
+   | EST request/response messages              |
+   |                                            |
+   +--------------------------------------------+
+   |                                            |
+   | HTTP for message transfer and signaling    |
+   |                                            |
+   +--------------------------------------------+
+   |                                            |
+   | TLS for transport security                 |
+   |                                            |
+   +--------------------------------------------+
+   |                                            |
+   | TCP for transport                          |
+   |                                            |
+   +--------------------------------------------+
+
+                                 Figure 1
+
+1.1.  Terminology
+
+   The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
+   "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and
+   "OPTIONAL" in this document are to be interpreted as described in
+   [RFC2119].
+
+
+
+
+
+Pritikin, et al.             Standards Track                    [Page 4]
+
+RFC 7030                           EST                      October 2013
+
+
+   It is assumed that the reader is familiar with the terms and concepts
+   described in Public Key Cryptography Standard (PKCS) #10 [RFC2986],
+   HTTPS [RFC2818], CMP [RFC4210], CMC [RFC5272][RFC5273][RFC5274], and
+   TLS [RFC4346].
+
+   In addition to the terms defined in the terminology section of CMC
+   [RFC5272], the following terms are defined for clarity:
+
+   EST CA:  For certificate issuing services, the EST CA is reached
+      through the EST server; the CA could be logically "behind" the EST
+      server or embedded within it.
+
+   Third-Party Trust Anchor:  Any trust anchor (TA) that is not
+      authoritative for the PKI hierarchy for which the EST server is
+      providing services.
+
+   Explicit Trust Anchor:  Any TA that is explicitly configured on the
+      client or server for use during EST TLS authentication; for
+      example, a TA that is manually configured on the EST client or
+      bootstrapped as described in Section 4.1.1.  (See more details in
+      Sections 3.6 and 6.)
+
+   Implicit Trust Anchor:  Any third-party TA that is available on the
+      client or server for use during TLS authentication but is not
+      specifically indicated for use during EST TLS authentication; for
+      example, TAs commonly used by web browsers to authenticate web
+      servers or TAs used by servers to authenticate manufacturer-
+      installed client credentials (such as certificates populated into
+      cable modems or routers in the factory).  The authorization model
+      for these TAs is different from the authorization model for
+      Explicit Trust Anchors.  (See more details in Sections 3.6.1,
+      3.6.2, and 6).
+
+   Certificate-Less TLS:  Certificate-less TLS cipher suites provide a
+      way to perform mutual authentication in situations where neither
+      the client nor server have certificates or are willing to use
+      them.  The credential used for authentication is a word, phrase,
+      code, or key that is shared between the client and server.  The
+      credential must be uniquely shared between the client and server
+      in order to provide authentication of an individual client to an
+      individual server.
+
+2.  Operational Scenario Overviews
+
+   This section provides an informative overview of the operational
+   scenarios to better introduce the reader to the protocol discussion.
+
+
+
+
+
+Pritikin, et al.             Standards Track                    [Page 5]
+
+RFC 7030                           EST                      October 2013
+
+
+   Both the EST clients and server are configured with information that
+   provides the basis for mutual authentication and for authorization.
+   The specific initialization data depends on the methods available in
+   the client and server, but it can include shared secrets, network
+   service names and locations (e.g., a Uniform Resource Identifier
+   (URI) [RFC3986]), trust anchor information (e.g., a CA certificate or
+   a hash of a TA's certificate), and enrollment keys and certificates.
+   Depending on an enterprise's acquisition and network management
+   practices, some initialization may be performed by the vendor prior
+   to delivery of client hardware and software.  In that case, the
+   client vendor may provide data, such as trust anchors, to the
+   enterprise via a secure procedure.  The distribution of this initial
+   information is out of scope.
+
+   Distribution of trust anchors and other certificates can be effected
+   via the EST server.  However, nothing can be inferred about the
+   authenticity of this data until an out-of-band mechanism is used to
+   verify them.
+
+   Sections 2.1-2.3 very closely mirror the text of the Scenarios
+   Appendix of [RFC6403] with such modifications as are appropriate for
+   this profile.  Sections 2.1-2.6, below, enumerate the set of EST
+   functions (see Figure 5) and provide an informative overview of EST's
+   capabilities.
+
+   The general client/server interaction proceeds as follows:
+
+      The client initiates a TLS-secured HTTP session with an EST
+      server.
+
+      A specific EST service is requested based on a portion of the URI
+      used for the session.
+
+      The client and server authenticate each other.
+
+      The client verifies that the server is authorized to serve this
+      client.
+
+      The server verifies that the client is authorized to make use of
+      this server and the request that the client has made.
+
+      The server acts upon the client request.
+
+2.1.  Obtaining CA Certificates
+
+   The EST client can request a copy of the current EST CA
+   certificate(s) from the EST server.  The EST client is assumed to
+   perform this operation before performing other operations.
+
+
+
+Pritikin, et al.             Standards Track                    [Page 6]
+
+RFC 7030                           EST                      October 2013
+
+
+   Throughout this document we assume the EST CA has a certificate that
+   is used by the client to verify signed objects issued by the CA,
+   e.g., certificates and certificate revocation lists (CRLs), and that
+   a different certificate than the one used to verify signatures on
+   certificates and CRLs is used when EST protocol communication
+   requires additional encryption.
+
+   The EST client authenticates and verifies the authorization scope of
+   the EST server when requesting the current CA certificate(s).  As
+   detailed in Sections 3.3.1 and 3.3.3, available options include:
+
+   o  Verifying the EST server's HTTPS URI against the EST server's
+      certificate using Implicit TAs (similar to a common HTTPS
+      exchange).  This allows the EST server and client to leverage
+      existing TAs that might be known to the EST client.
+
+   o  The client can leverage a previously distributed trust anchor
+      specific to the EST server.  This allows the EST client to use an
+      existing, potentially older, CA certificate to request a current
+      CA certificate.
+
+   o  For bootstrapping, the EST client can rely upon manual
+      authentication performed by the end-user as detailed in
+      Section 4.1.1.
+
+   o  The client can leverage the binding of a shared credential to a
+      specific EST server with a certificate-less TLS cipher suite.
+
+   Client authentication is not required for this exchange, so it is
+   trivially supported by the EST server.
+
+2.2.  Initial Enrollment
+
+   After authenticating an EST server and verifying that it is
+   authorized to provide services to the client, an EST client can
+   acquire a certificate for itself by submitting an enrollment request
+   to that server.
+
+   The EST server authenticates and authorizes the EST client as
+   specified in Sections 3.3.2, 3.3.3, and 3.7.  The methods described
+   in the normative text that are discussed in this overview include:
+
+   o  TLS with a previously issued client certificate (e.g., an existing
+      certificate issued by the EST CA);
+
+   o  TLS with a previously installed certificate (e.g., manufacturer-
+      installed certificate or a certificate issued by some other
+      party);
+
+
+
+Pritikin, et al.             Standards Track                    [Page 7]
+
+RFC 7030                           EST                      October 2013
+
+
+   o  Certificate-less TLS (e.g., with a shared credential distributed
+      out-of-band);
+
+   o  HTTP-based with a username/password distributed out-of-band.
+
+2.2.1.  Certificate TLS Authentication
+
+   If the EST client has a previously installed certificate issued by a
+   third-party CA, this certificate can be used to authenticate the
+   client's request for a certificate from the EST server (if that CA is
+   recognized by the EST server).  An EST client responds to the EST
+   server's TLS certificate request message with the existing
+   certificate already held by the client.  The EST server will verify
+   the client's existing certificate and authorize the client's request
+   as described in Section 3.3.2.
+
+2.2.2.  Certificate-Less TLS Authentication
+
+   The EST client and EST server can be mutually authenticated using a
+   certificate-less TLS cipher suite (see Section 3.3.3).
+
+2.2.3.  HTTP-Based Client Authentication
+
+   The EST server can optionally also request that the EST client submit
+   a username/password using the HTTP Basic or Digest authentication
+   methods (see Section 3.2.3).  This approach is desirable if the EST
+   client cannot be authenticated during the TLS handshake (see
+   Section 3.3.2) or the EST server policy requires additional
+   authentication information; see Section 3.2.3.  In all cases,
+   HTTP-based client authentication is only to be performed over a
+   TLS-protected transport (see Section 3.3).
+
+2.3.  Client Certificate Reissuance
+
+   An EST client can renew/rekey its existing client certificate by
+   submitting a re-enrollment request to an EST server.
+
+   When the current EST client certificate can be used for TLS client
+   authentication (Section 3.3.2), the client presents this certificate
+   to the EST server for client authentication.  When the to be reissued
+   EST client certificate cannot be used for TLS client authentication,
+   any of the authentication methods used for initial enrollment can be
+   used.
+
+   For example, if the client has an alternative certificate issued by
+   the EST CA that can be used for TLS client authentication, then it
+   can be used.
+
+
+
+
+Pritikin, et al.             Standards Track                    [Page 8]
+
+RFC 7030                           EST                      October 2013
+
+
+   The certificate request message includes the same Subject and
+   SubjectAltName as the current certificate.  Name changes are
+   requested as specified in Section 4.2.2.
+
+2.4.  Server Key Generation
+
+   The EST client can request a server-generated certificate and key
+   pair (see Section 4.4).
+
+2.5.  Full PKI Request Messages
+
+   Full PKI Request [RFC5272] messages can be transported via EST using
+   the Full CMC Request function.  This affords access to functions not
+   provided by the Simple Enrollment functions.  Full PKI Request
+   messages are defined in Sections 3.2 and 4.2 of [RFC5272].  See
+   Section 4.3 for a discussion of how EST provides a transport for
+   these messages.
+
+2.6.  Certificate Signing Request (CSR) Attributes Request
+
+   Prior to sending an enrollment request to an EST server, an EST
+   client can query the EST server for a set of additional attributes
+   that the client is requested to use in a subsequent enrollment
+   request.
+
+   These attributes can provide additional descriptive information that
+   the EST server cannot access itself, such as the Media Access Control
+   (MAC) address of an interface of the EST client.  Alternatively,
+   these attributes can indicate the kind of enrollment request, such as
+   a specific elliptic curve or a specific hash function that the client
+   is expected to use when generating the CSR.
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Pritikin, et al.             Standards Track                    [Page 9]
+
+RFC 7030                           EST                      October 2013
+
+
+3.  Protocol Design and Layering
+
+   Figure 2 provides an expansion of Figure 1, describing how the layers
+   are used.  Each aspect is described in more detail in the sections
+   that follow.
+
+   EST Layering:
+
+   Protocols and uses:
+   +----------------------------------------------------+
+   |                                                    |
+   | Message types:                                     |
+   |   - "Simple PKI" messages                          |
+   |     (incorporates proof-of-possession)             |
+   |   - CA certificate retrieval                       |
+   |   - "Full PKI" messages (OPTIONAL)                 |
+   |     (incorporates proof-of-possession)             |
+   |   - CSR Attributes Request (OPTIONAL)              |
+   |   - Server-generated key request (OPTIONAL)        |
+   |                                                    |
+   +----------------------------------------------------+
+   |                                                    |
+   | HTTP:                                              |
+   |   - HTTP headers and URIs for control              |
+   |      - Content-Type headers specify message type   |
+   |      - Headers for control/error messages          |
+   |      - URIs for selecting functions                |
+   |   - Basic or Digest authentication (OPTIONAL)      |
+   |                                                    |
+   +----------------------------------------------------+
+   |                                                    |
+   | TLS for transport security:                        |
+   |   - Authentication of the EST server               |
+   |   - Authentication of the EST client (OPTIONAL)    |
+   |   - Provides communications integrity              |
+   |     and confidentiality                            |
+   |   - Supplies channel-binding [RFC5929] information |
+   |     to link proof-of-identity with message-based   |
+   |     proof-of-possession (OPTIONAL)                 |
+   |                                                    |
+   +----------------------------------------------------+
+
+                                 Figure 2
+
+   Specifying HTTPS as the secure transport for enrollment messages
+   introduces two "layers" to communicate authentication and control
+   messages: TLS and HTTP.
+
+
+
+
+Pritikin, et al.             Standards Track                   [Page 10]
+
+RFC 7030                           EST                      October 2013
+
+
+   The TLS layer provides integrity and confidentiality during
+   transport.  The proof-of-identity is supplied by TLS handshake
+   authentication and optionally also by the HTTP layer headers.  The
+   message type and control/error messages are included in the HTTP
+   headers.
+
+   CMC ([RFC5272], Section 3.1) notes that "the Simple PKI Request MUST
+   NOT be used if a proof-of-identity needs to be included".  Since the
+   TLS and HTTP layers can provide proof-of-identity for EST clients and
+   servers, the Simple PKI message types are used.
+
+   The TLS layer certificate exchange provides a method for authorizing
+   client enrollment requests using existing certificates.  Such
+   certificates may have been issued by the CA (from which the client is
+   requesting a certificate), or they may have been issued under a
+   distinct PKI (e.g., an IEEE 802.1AR Initial Device Identifier
+   (IDevID) [IDevID] credential).
+
+   Proof-of-possession (POP) is a distinct issue from proof-of-identity
+   and is included in the Simple PKI message type as described in
+   Section 3.4.  A method of linking proof-of-identity and
+   proof-of-possession is described in Section 3.5.
+
+   This document also defines transport for CMC [RFC5272] that complies
+   with the CMC Transport Protocols [RFC5273].  CMC's POP and
+   proof-of-identity mechanisms are defined in CMC, but the mechanisms
+   here can also be used in conjunction with those mechanisms in "Full
+   PKI" messages.
+
+   During protocol exchanges, different certificates can be used.  The
+   following table provides an informative overview.  End-entities can
+   have one or more certificates of each type listed in Figure 3 and use
+   one or more trust anchor databases of each type listed in Figure 4.
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Pritikin, et al.             Standards Track                   [Page 11]
+
+RFC 7030                           EST                      October 2013
+
+
+   Certificates and their corresponding uses:
+   +--------------+--------------------+-------------------------------+
+   | Certificate  | Issuer             | Use and section references    |
+   +==============+====================+===============================+
+   | EST server   | The CA served by   | Presented by the EST server   |
+   | certificate  | the EST server     | during the TLS handshake.     |
+   |              |                    |                               |
+   |              |                    | Section 3.3.1                 |
+   +--------------+--------------------+-------------------------------+
+   | EST server   | A CA               | Presented by the EST server   |
+   | certificate  | authenticatable by | during the TLS handshake.     |
+   |              | a third-party TA,  |                               |
+   |              | e.g., a web server | Section 3.3.1 and             |
+   |              | CA                 | Security Considerations       |
+   +--------------+--------------------+-------------------------------+
+   | Third-party  | A CA               | Presented by the EST client   |
+   | EST client   | authenticatable by | to the EST server by clients  |
+   | certificate  | a third-party TA,  | that have not yet enrolled.   |
+   |              | e.g., a device     |                               |
+   |              | manufacturer       | Section 3.3.2                 |
+   +--------------+--------------------+-------------------------------+
+   | EST client   | The CA served by   | Presented to the EST server   |
+   | certificate  | the EST server     | during future EST operations. |
+   |              |                    |                               |
+   |              |                    | Section 3.3.2                 |
+   +--------------+--------------------+-------------------------------+
+   | End-entity   | The CA served by   | Clients can obtain certs      |
+   | certificate  | the EST server     | that are intended for         |
+   |              |                    | non-EST uses.  This includes  |
+   |              |                    | certs that cannot be used     |
+   |              |                    | for EST operations.           |
+   |              |                    |                               |
+   |              |                    | Section 4.2.3                 |
+   +--------------+--------------------+-------------------------------+
+
+
+                                 Figure 3
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Pritikin, et al.             Standards Track                   [Page 12]
+
+RFC 7030                           EST                      October 2013
+
+
+   Trust anchor databases and their corresponding uses:
+   +--------------+----------------------------------------------------+
+   | TA database  | Use and section references                         |
+   +==============+====================================================+
+   | EST server   | EST servers use this TA database to authenticate   |
+   | Explicit     | certificates issued by the EST CA, including EST   |
+   | TA database  | client certificates during enroll/re-enroll        |
+   |              | operations.                                        |
+   |              |                                                    |
+   |              | Section 3.3.2                                      |
+   +--------------+----------------------------------------------------+
+   | EST server   | EST servers use this TA database to authenticate   |
+   | Implicit     | certificates issued by third-party TAs;            |
+   | TA database  | e.g., EST client certificates issued by a device   |
+   |              | manufacturer.                                      |
+   |              | An Implicit TA database can be disabled.           |
+   |              |                                                    |
+   |              | Section 3.3.2                                      |
+   +--------------+----------------------------------------------------+
+   | EST client   | EST clients use this TA database to authenticate   |
+   | Explicit     | certificates issued by the EST CA, including EST   |
+   | TA database  | server certificates.                               |
+   |              |                                                    |
+   |              | Sections 3.1, 3.3.1, 3.6.1, and 4.1.1              |
+   +--------------+----------------------------------------------------+
+   | EST client   | EST clients use this TA database to                |
+   | Implicit     | authenticate an EST server that uses an externally |
+   | TA database  | issued certificate.                                |
+   |              | An Implicit TA database can be disabled.           |
+   |              |                                                    |
+   |              | Sections 3.1, 3.3.1, 3.6.2, and                    |
+   |              | Security Considerations                            |
+   +--------------+----------------------------------------------------+
+
+
+                                 Figure 4
+
+3.1.  Application Layer
+
+   The EST client MUST be capable of generating and parsing Simple PKI
+   messages (see Section 4.2).  Generating and parsing Full PKI messages
+   is OPTIONAL (see Section 4.3).  The client MUST also be able to
+   request CA certificates from the EST server and parse the returned
+   "bag" of certificates (see Section 4.1).  Requesting CSR attributes
+   and parsing the returned list of attributes is OPTIONAL (see
+   Section 4.5).
+
+
+
+
+
+Pritikin, et al.             Standards Track                   [Page 13]
+
+RFC 7030                           EST                      October 2013
+
+
+   Details of the EST client application configuration are out of scope
+   of the protocol discussion but are necessary for understanding the
+   prerequisites of initiating protocol operations.  The EST client is
+   RECOMMENDED to be configured with TA databases for Section 3.3.1 or
+   with a secret key for Section 3.3.3.  Implementations conforming to
+   this standard MUST provide the ability to designate Explicit TAs.
+   For human usability reasons, a "fingerprint" of an Explicit TA
+   database entry can be configured for bootstrapping as discussed in
+   Section 4.1.1.  Configuration of an Implicit TA database, perhaps by
+   its inclusion within the EST client distribution or available from
+   the operating system, provides flexibility along with the caveats
+   detailed in Section 6.  Implementations conforming to this standard
+   MUST provide the ability to disable use of any Implicit TA database.
+
+   The EST client is configured with sufficient information to form the
+   EST server URI.  This can be the full operation path segment (e.g.,
+   https://www.example.com/.well-known/est/ or
+   https://www.example.com/.well-known/est/arbitraryLabel1), or the EST
+   client can be configured with a tuple composed of the authority
+   portion of the URI along with the OPTIONAL label (e.g.,
+   "www.example.com:80" and "arbitraryLabel1") or just the authority
+   portion of the URI.
+
+3.2.  HTTP Layer
+
+   HTTP is used to transfer EST messages.  URIs are defined for handling
+   each media type (i.e., message type) as described in Section 3.2.2.
+   HTTP is also used for client authentication services when TLS client
+   authentication is not available, due to the lack of a client
+   certificate suitable for use by TLS (see Section 3.2.3).  HTTP
+   authentication can also be used in addition to TLS client
+   authentication if the EST server wishes additional authentication
+   information, as noted in Section 2.2.3.  Registered media types are
+   used to convey EST messages as specified in Figure 6.
+
+   HTTP 1.1 [RFC2616] and above support persistent connections.  As
+   described in Section 8.1 of RFC 2616, persistent connections may be
+   used to reduce network and processing loads associated with multiple
+   HTTP requests.  EST does not require or preclude persistent HTTP
+   connections.
+
+
+
+
+
+
+
+
+
+
+
+Pritikin, et al.             Standards Track                   [Page 14]
+
+RFC 7030                           EST                      October 2013
+
+
+3.2.1.  HTTP Headers for Control
+
+   The HTTP Status value is used to communicate success or failure of an
+   EST function.  HTTP authentication is used by a client when requested
+   by the server.
+
+   The media types specified in the HTTP Content-Type header indicate
+   which EST message is being transferred.  Media types used by EST are
+   specified in Section 3.2.4.
+
+   HTTP redirections (3xx status codes) to the same web origin (see
+   [RFC6454]) SHOULD be handled by the client without user input so long
+   as all applicable security checks (Sections 3.3 and 3.6) have been
+   enforced on the initial connection.  The client initiates a new TLS
+   connection and performs all applicable security checks when
+   redirected to other web origin servers.  Redirections to other web
+   origins require the EST client to obtain user input for non-GET or
+   HEAD requests as specified in [RFC2616].  Additionally, if the client
+   has already generated a CSR that includes linking identity and POP
+   information (Section 3.5), then the CSR will need to be recreated to
+   incorporate the tls-unique from the new, redirected session.  Note:
+   the key pair need not be regenerated.  These are processing and
+   interface burdens on the client.  EST server administrators are
+   advised to take this into consideration.
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Pritikin, et al.             Standards Track                   [Page 15]
+
+RFC 7030                           EST                      October 2013
+
+
+3.2.2.  HTTP URIs for Control
+
+   The EST server MUST support the use of the path-prefix of "/.well-
+   known/" as defined in [RFC5785] and the registered name of "est".
+   Thus, a valid EST server URI path begins with
+   "https://www.example.com/.well-known/est".  Each EST operation is
+   indicated by a path-suffix that indicates the intended operation:
+
+   Operations and their corresponding URIs:
+   +------------------------+-----------------+-------------------+
+   | Operation              |Operation path   | Details           |
+   +========================+=================+===================+
+   | Distribution of CA     | /cacerts        | Section 4.1       |
+   | Certificates (MUST)    |                 |                   |
+   +------------------------+-----------------+-------------------+
+   | Enrollment of          | /simpleenroll   | Section 4.2       |
+   | Clients (MUST)         |                 |                   |
+   +------------------------+-----------------+-------------------+
+   | Re-enrollment of       | /simplereenroll | Section 4.2.2     |
+   | Clients (MUST)         |                 |                   |
+   +------------------------+-----------------+-------------------+
+   | Full CMC (OPTIONAL)    | /fullcmc        | Section 4.3       |
+   +------------------------+-----------------+-------------------+
+   | Server-Side Key        | /serverkeygen   | Section 4.4       |
+   | Generation (OPTIONAL)  |                 |                   |
+   +------------------------+-----------------+-------------------+
+   | CSR Attributes         | /csrattrs       | Section 4.5       |
+   | (OPTIONAL)             |                 |                   |
+   +------------------------+-----------------+-------------------+
+
+                                 Figure 5
+
+   The operation path (Figure 5) is appended to the path-prefix to form
+   the URI used with HTTP GET or POST to perform the desired EST
+   operation.  An example valid URI absolute path for the "/cacerts"
+   operation is "/.well-known/est/cacerts".  To retrieve the CA's
+   certificates, the EST client would use the following HTTP
+   request-line:
+
+   GET /.well-known/est/cacerts HTTP/1.1
+
+   Likewise, to request a new certificate in this example scheme, the
+   EST client would use the following request-line:
+
+   POST /.well-known/est/simpleenroll HTTP/1.1
+
+
+
+
+
+
+Pritikin, et al.             Standards Track                   [Page 16]
+
+RFC 7030                           EST                      October 2013
+
+
+   The use of distinct operation paths simplifies implementation for
+   servers that do not perform client authentication when distributing
+   /cacerts responses.
+
+   An EST server MAY provide service for multiple CAs as indicated by an
+   OPTIONAL additional path segment between the registered application
+   name and the operation path.  To avoid conflict, the CA label MUST
+   NOT be the same as any defined operation path segment.  The EST
+   server MUST provide services regardless of whether the additional
+   path segment is present.  The following are three example valid URIs:
+
+   1.  https://www.example.com/.well-known/est/cacerts
+
+   2.  https://www.example.com/.well-known/est/arbitraryLabel1/cacerts
+
+   3.  https://www.example.com/.well-known/est/arbitraryLabel2/cacerts
+
+   In this specification, the distinction between enroll and renew/rekey
+   is explicitly indicated by the HTTP URI.  When requesting /fullcmc
+   operations, CMC [RFC5272] uses the same messages for certificate
+   renewal and certificate rekey.
+
+   An EST server can provide additional services using other URIs.
+
+3.2.3.  HTTP-Based Client Authentication
+
+   The EST server MAY request HTTP-based client authentication.  This
+   request can be in addition to successful TLS client authentication
+   (Section 3.3.2) if EST server policy requires additional
+   authentication.  (For example, the EST server may require that an EST
+   client "knows" a password in addition to "having" an existing client
+   certificate.)  Or, HTTP-based client authentication can be an EST
+   server policy-specified fallback in situations where the EST client
+   did not successfully complete the TLS client authentication.  (This
+   might arise if the EST client is enrolling for the first time or if
+   the certificates available to an EST client cannot be used for TLS
+   client authentication.)
+
+   HTTP Basic and Digest authentication MUST only be performed over TLS
+   1.1 [RFC4346] or later versions.  NULL and anon cipher suites MUST
+   NOT be used because they do not provide confidentiality or support
+   mutual certificate-based or certificate-less authentication,
+   respectively.  As specified in "Certificate Management over CMS
+   (CMC): Transport Protocols" [RFC5273], the server "MUST NOT assume
+   client support for any type of HTTP authentication such as cookies,
+   Basic authentication, or Digest authentication".  Clients SHOULD
+   support the Basic and Digest authentication mechanism.
+
+
+
+
+Pritikin, et al.             Standards Track                   [Page 17]
+
+RFC 7030                           EST                      October 2013
+
+
+   Servers that wish to use Basic and Digest authentication reject the
+   HTTP request using the HTTP-defined WWW-Authenticate response-header
+   ([RFC2616], Section 14.47).  The client is expected to retry the
+   request, including the appropriate Authorization Request header
+   ([RFC2617], Section 3.2.2), if the client is capable of using the
+   Basic or Digest authentication.  If the client is not capable of
+   retrying the request or it is not capable of Basic or Digest
+   authentication, then the client MUST terminate the connection.
+
+   A client MAY set the username to the empty string ("") if it is
+   presenting a password that is not associated with a username.
+
+   Support for HTTP-based client authentication has security
+   ramifications as discussed in Section 6.  The client MUST NOT respond
+   to the server's HTTP authentication request unless the client has
+   authorized the EST server (as per Section 3.6).
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Pritikin, et al.             Standards Track                   [Page 18]
+
+RFC 7030                           EST                      October 2013
+
+
+3.2.4.  Message Types
+
+   This document uses existing media types for the messages as specified
+   by FTP and HTTP [RFC2585], application/pkcs10 [RFC5967], and CMC
+   [RFC5272].
+
+   For consistency with [RFC5273], each distinct EST message type uses
+   an HTTP Content-Type header with a specific media type.
+
+   The EST messages and their corresponding media types for each
+   operation are:
+
+   +--------------------+--------------------------+-------------------+
+   | Message type       | Request media type       | Request section(s)|
+   |                    | Response media type(s)   | Response section  |
+   | (per operation)    | Source(s) of types       |                   |
+   +====================+==========================+===================+
+   | Distribution of CA | N/A                      | Section 4.1       |
+   | Certificates       | application/pkcs7-mime   | Section 4.1.1     |
+   |                    | [RFC5751]                |                   |
+   | /cacerts           |                          |                   |
+   +--------------------+--------------------------+-------------------+
+   | Client Certificate | application/pkcs10       | Sections 4.2/4.2.1|
+   | Request Functions  | application/pkcs7-mime   | Section 4.2.2     |
+   |                    | [RFC5967] [RFC5751]      |                   |
+   | /simpleenroll      |                          |                   |
+   | /simplereenroll    |                          |                   |
+   +--------------------+--------------------------+-------------------+
+   | Full CMC           | application/pkcs7-mime   | Section 4.3.1     |
+   |                    | application/pkcs7-mime   | Section 4.3.2     |
+   | /fullcmc           | [RFC5751]                |                   |
+   +--------------------+--------------------------+-------------------+
+   | Server-Side Key    | application/pkcs10       | Section 4.4.1     |
+   | Generation         | multipart/mixed          | Section 4.4.2     |
+   |                    | (application/pkcs7-mime &|                   |
+   |                    | application/pkcs8)       |                   |
+   |                    | [RFC5967] [RFC5751]      |                   |
+   | /serverkeygen      | [RFC5958]                |                   |
+   +--------------------+--------------------------+-------------------+
+   | CSR Attributes     | N/A                      | Section 4.5.1     |
+   |                    | application/csrattrs     | Section 4.5.2     |
+   |                    | (This document)          |                   |
+   | /csrattrs          |                          |                   |
+   +--------------------+--------------------------+-------------------+
+
+                                 Figure 6
+
+
+
+
+
+Pritikin, et al.             Standards Track                   [Page 19]
+
+RFC 7030                           EST                      October 2013
+
+
+3.3.  TLS Layer
+
+   TLS provides authentication, which in turn enables authorization
+   decisions.  The EST server and EST client are responsible for
+   ensuring that an acceptable cipher suite is negotiated and that
+   mutual authentication has been performed.  TLS authentication is most
+   commonly enabled with the use of certificates [RFC5280].
+   Alternately, certificate-less TLS authentication, where neither the
+   client nor server present a certificate, is also an acceptable method
+   for EST mutual authentication (Section 3.3.3).  The EST server MUST
+   be authenticated during the TLS handshake unless the client is
+   requesting Bootstrap Distribution of CA certificates (Section 4.1.1)
+   or Full CMC (Section 4.3).
+
+   HTTPS [RFC2818] specifies how HTTP messages are carried over TLS.
+   HTTPS MUST be used.  TLS 1.1 [RFC4346] (or a later version) MUST be
+   used for all EST communications.  TLS session resumption [RFC5077]
+   SHOULD be supported.
+
+   TLS channel-binding information can be inserted into a certificate
+   request, as detailed in Section 3.5, in order to provide the EST
+   server with assurance that the authenticated TLS client has access to
+   the private key for the certificate being requested.  The EST server
+   MUST implement Section 3.5.
+
+3.3.1.  TLS-Based Server Authentication
+
+   TLS server authentication with certificates MUST be supported.
+
+   The EST client authenticates the EST server as defined for the cipher
+   suite negotiated.  The following text provides details assuming a
+   certificate-based cipher suite, such as the TLS 1.1 [RFC4346]
+   mandatory cipher suite (TLS_RSA_WITH_3DES_EDE_CBC_SHA).
+
+   Certificate validation MUST be performed as per [RFC5280].  The EST
+   server certificate MUST conform to the [RFC5280] certificate profile.
+
+   The client validates the TLS server certificate using the EST client
+   Explicit and, if enabled, Implicit TA database(s).  The client MUST
+   maintain a distinction between the use of Explicit and Implicit TA
+   databases during authentication in order to support proper
+   authorization.  The EST client MUST perform authorization checks as
+   specified in Section 3.6.
+
+   If certificate validation fails, the client MAY follow the procedure
+   outlined in Section 4.1.1 for Bootstrap Distribution of CA
+   certificates.
+
+
+
+
+Pritikin, et al.             Standards Track                   [Page 20]
+
+RFC 7030                           EST                      October 2013
+
+
+3.3.2.  TLS-Based Client Authentication
+
+   TLS client authentication is the RECOMMENDED method for identifying
+   EST clients.  HTTP-based client authentication (Section 3.2.3) MAY be
+   used.
+
+   The EST server authenticates the EST client as defined for the cipher
+   suite negotiated.  The following text provides details assuming a
+   certificate-based cipher suite such as the TLS 1.1 [RFC4346]
+   mandatory cipher suite (TLS_RSA_WITH_3DES_EDE_CBC_SHA).  The EST
+   server MUST support certificate-based client authentication.
+
+   Generally, the client will use an existing certificate for renew or
+   rekey operations.  If the certificate to be renewed or rekeyed is
+   appropriate for the negotiated cipher suite, then the client MUST use
+   it for the TLS handshake, otherwise the client SHOULD use an
+   alternate certificate that is suitable for the cipher suite and
+   contains the same subject identity information.  When requesting an
+   enroll operation, the client MAY use a client certificate issued by a
+   third party to authenticate itself.
+
+   Certificate validation MUST be performed as per [RFC5280].  The EST
+   client certificate MUST conform to the [RFC5280] certificate profile.
+
+   The server validates the TLS client certificate using the EST server
+   Explicit and, if enabled, Implicit TA database(s).  The server MUST
+   maintain a distinction between the use of Explicit and Implicit TA
+   databases during authentication in order to support proper
+   authorization.
+
+   The EST server MUST perform authorization checks as specified in
+   Section 3.7.
+
+   If a client does not support TLS client authentication, then it MUST
+   support HTTP-based client authentication (Section 3.2.3) or
+   certificate-less TLS authentication (Section 3.3.3).
+
+3.3.3.  Certificate-Less TLS Mutual Authentication
+
+   Certificate-less TLS cipher suites provide a way to perform mutual
+   authentication in situations where neither the client nor server have
+   certificates, do not desire to use certificates, or do not have the
+   trust anchors necessary to verify a certificate.  The client and
+   server MAY negotiate a certificate-less cipher suite for mutual
+   authentication.
+
+   When using certificate-less mutual authentication in TLS for
+   enrollment, the cipher suite MUST be based on a protocol that is
+
+
+
+Pritikin, et al.             Standards Track                   [Page 21]
+
+RFC 7030                           EST                      October 2013
+
+
+   resistant to dictionary attack and MUST be based on a zero knowledge
+   protocol.  Transport Layer Security-Secure Remote Password (TLS-SRP)
+   cipher suites, i.e., those with _SRP_ in the name, listed in
+   Section 2.7 of [RFC5054] are suitable for this purpose.  Section 6
+   lists the characteristics of a cipher suite that are suitable for use
+   in certificate-less mutual authentication for enrollment.
+
+   Successful authentication using a certificate-less cipher suite
+   proves knowledge of a pre-shared secret that implicitly authorizes a
+   peer in the exchange.
+
+3.4.  Proof-of-Possession
+
+   As defined in Section 2.1 of CMC [RFC5272], proof-of-possession (POP)
+   "refers to a value that can be used to prove that the private key
+   corresponding to the public key is in the possession of and can be
+   used by an end-entity".
+
+   The signed enrollment request provides a signature-based
+   proof-of-possession.  The mechanism described in Section 3.5
+   strengthens this by optionally including "Direct"-based
+   proof-of-possession [RFC5272] by including TLS session-specific
+   information within the data covered by the enrollment request
+   signature (thus linking the enrollment request to the authenticated
+   end point of the TLS connection).
+
+3.5.  Linking Identity and POP Information
+
+   Server policy will determine whether clients are required to use the
+   mechanism specified in this section.  This specification provides a
+   method of linking identity and proof-of-possession by including
+   information specific to the current authenticated TLS session within
+   the signed certification request.  The client can determine if the
+   server requires the linking of identity and POP by examining the CSR
+   Attributes Response (see Section 4.5.2).  Regardless of the CSR
+   Attributes Response, clients SHOULD link identity and POP by
+   embedding tls-unique information in the certification request.  If
+   tls-unique information is included by the client, the server MUST
+   verify it.  The EST server MAY reject requests without tls-unique
+   information as indicated by server policy.
+
+   Linking identity and proof-of-possession proves to the server that
+   the authenticated TLS client has possession of the private key
+   associated with the certification request, and that the client was
+   able to sign the certification request after the TLS session was
+   established.  This is an alternative to the "Linking Identity and POP
+   Information" method defined by Section 6 of [RFC5272] that is
+   available if Full PKI messages are used.
+
+
+
+Pritikin, et al.             Standards Track                   [Page 22]
+
+RFC 7030                           EST                      October 2013
+
+
+   The client generating the CSR obtains the tls-unique value from the
+   TLS subsystem as described in Channel Bindings for TLS [RFC5929].
+   The EST client operations between obtaining the tls-unique value
+   through generation of the CSR that contains the current tls-unique
+   value and the subsequent verification of this value by the EST server
+   are the "phases of the application protocol during which application-
+   layer authentication occurs"; these operations are protected by the
+   synchronization interoperability mechanism described in the "Channel
+   Bindings for TLS" interoperability notes in Section 3.1 of [RFC5929].
+
+   When performing renegotiation, TLS "secure_renegotiation" [RFC5746]
+   MUST be used.
+
+   The tls-unique value is base64 encoded as specified in Section 4 of
+   [RFC4648], and the resulting string is placed in the certification
+   request challenge-password field ([RFC2985], Section 5.4.1).  The
+   challenge-password field is limited to 255 bytes (Section 7.4.9 of
+   [RFC5246] indicates that no existing cipher suite would result in an
+   issue with this limitation).  If the challenge-password attribute is
+   absent, the client did not include the optional channel-binding
+   information (the presence of the challenge-password attribute
+   indicates the inclusion of tls-unique information).
+
+   If the EST server makes use of a back-end infrastructure for
+   processing, it is RECOMMENDED that the results of this verification
+   be communicated.  (For example, this communication might use the CMC
+   [RFC5272] "RA POP Witness Control" in a CMC Full PKI Request message.
+   Or, an EST server might TLS-authenticate an EST client as being a
+   trusted infrastructure element that does not forward invalid
+   requests.  A detailed discussion of back-end processing is out of
+   scope.)
+
+   When rejecting requests, the EST server response is as described for
+   all enroll responses (Section 4.2.3).  If a Full PKI Response is
+   included, the CMCFailInfo MUST be set to popFailed.  If a human-
+   readable reject message is included, it SHOULD include an informative
+   text message indicating that the linking of identity and POP
+   information is required.
+
+3.6.  Server Authorization
+
+   The client MUST check EST server authorization before accepting any
+   server responses or responding to HTTP authentication requests.
+
+   The EST client authorization method depends on which method was used
+   to authenticate the server.  When the Explicit TA database is used to
+   authenticate the EST server, then Section 3.6.1 applies.  When the
+   Implicit TA database is used to authenticate the EST server, then
+
+
+
+Pritikin, et al.             Standards Track                   [Page 23]
+
+RFC 7030                           EST                      October 2013
+
+
+   Section 3.6.2 applies.  Successful authentication using a
+   certificate-less cipher suite implies authorization of the server.
+
+   The client MAY perform bootstrapping as specified in Section 4.1.1
+   even if these checks fail.
+
+3.6.1.  Client Use of Explicit TA Database
+
+   When the EST client Explicit TA database is used to validate the EST
+   server certificate, the client MUST check either the configured URI
+   or the most recent HTTP redirection URI against the server's identity
+   according to the rules specified in [RFC6125], Section 6.4, or the
+   EST server certificate MUST contain the id-kp-cmcRA [RFC6402]
+   extended key usage extension.
+
+3.6.2.  Client Use of Implicit TA Database
+
+   When the EST client Implicit TA database is used to validate the EST
+   server certificate, the client MUST check the configured URI and each
+   HTTP redirection URI according to the rules specified in [RFC6125],
+   Section 6.4.  The provisioned URI or the most recent HTTP redirection
+   URI provides the basis for authorization, and the server's
+   authenticated identity confirms it is the authorized server.
+
+3.7.  Client Authorization
+
+   The decision to issue a certificate to a client is always controlled
+   by local CA policy.  The EST server configuration reflects this CA
+   policy.  This document does not specify any constraints on such
+   policy.  EST provides the EST server access to each client's
+   authenticated identity -- e.g., the TLS client's certificate in
+   addition to any HTTP user authentication credentials -- to help in
+   implementing such policy.
+
+   If the client's certificate was issued by the EST CA, and it includes
+   the id-kp-cmcRA [RFC6402] extended key usage extension, then the
+   client is a Registration Authority (RA) as described in [RFC5272] and
+   [RFC6402].  In this case, the EST server SHOULD apply authorization
+   policy consistent with an RA client.  For example, when handling
+   /simpleenroll requests, the EST server could be configured to accept
+   POP linking information that does not match the current TLS session
+   because the authenticated EST client RA has verified this information
+   when acting as an EST server (as specified in Section 3.5).  More
+   specific RA mechanisms are available if the EST client uses /fullcmc
+   methods.
+
+
+
+
+
+
+Pritikin, et al.             Standards Track                   [Page 24]
+
+RFC 7030                           EST                      October 2013
+
+
+4.  Protocol Exchange Details
+
+   Before processing a request, an EST server determines if the client
+   is authorized to receive the requested services.  Likewise, the
+   client determines if it will make requests to the EST server.  These
+   authorization decisions are described in the next two sections.
+   Assuming that both sides of the exchange are authorized, then the
+   actual operations are as described in subsequent sections.
+
+4.1.  Distribution of CA Certificates
+
+   The EST client can request a copy of the current CA certificates.
+   This function is generally performed before other EST functions.
+
+4.1.1.  Bootstrap Distribution of CA Certificates
+
+   It is possible that the client was not configured with an Implicit TA
+   database that allows a bootstrap installation of the Explicit TA
+   database as described in 4.1.3.  This section describes an alternate
+   method by which minimally configured EST clients can populate their
+   Explicit TA database.
+
+   If the EST client application does not specify either an Explicit TA
+   database or an Implicit TA database, then the initial TLS server
+   authentication and authorization will fail.  The client MAY
+   provisionally continue the TLS handshake to completion for the
+   purposes of accessing the /cacerts or /fullcmc method.  If the EST
+   client continues with an unauthenticated connection, the client MUST
+   extract the HTTP content data from the response (Sections 4.1.3 or
+   4.3.2) and engage a human user to authorize the CA certificate using
+   out-of-band data such as a CA certificate "fingerprint" (e.g., a
+   SHA-256 or SHA-512 [SHS] hash on the whole CA certificate).  In a
+   /fullcmc response, it is the Publish Trust Anchors control (CMC
+   [RFC5272], Section 6.15) within the Full PKI Response that must be
+   accepted manually.  It is incumbent on the user to properly verify
+   the TA information, or to provide the "fingerprint" data during
+   configuration that is necessary to verify the TA information.
+
+   HTTP authentication requests MUST NOT be responded to if the server
+   has not been authenticated as specified in Section 3.3.1 or if the
+   optional certificate-less authentication is used as specified in
+   Section 3.3.3.
+
+   The EST client uses the /cacerts response to establish an Explicit
+   Trust Anchor database for subsequent TLS authentication of the EST
+   server.  EST clients MUST NOT engage in any other protocol exchange
+
+
+
+
+
+Pritikin, et al.             Standards Track                   [Page 25]
+
+RFC 7030                           EST                      October 2013
+
+
+   until after the /cacerts response has been accepted and a new TLS
+   session has been established (using TLS certificate-based
+   authentication).
+
+4.1.2.  CA Certificates Request
+
+   EST clients request the EST CA TA database information of the CA (in
+   the form of certificates) with an HTTPS GET message using an
+   operation path of "/cacerts".  EST clients and servers MUST support
+   the /cacerts function.  Clients SHOULD request an up-to-date response
+   before stored information has expired in order to ensure the EST CA
+   TA database is up to date.
+
+   The EST server SHOULD NOT require client authentication or
+   authorization to reply to this request.
+
+   The client MUST authenticate the EST server, as specified in
+   Section 3.3.1 if certificate-based authentication is used or
+   Section 3.3.3 if the optional certificate-less authentication is
+   used, and check the server's authorization as given in Section 3.6,
+   or follow the procedure outlined in Section 4.1.1.
+
+4.1.3.  CA Certificates Response
+
+   If successful, the server response MUST have an HTTP 200 response
+   code.  Any other response code indicates an error and the client MUST
+   abort the protocol.
+
+   A successful response MUST be a certs-only CMC Simple PKI Response,
+   as defined in [RFC5272], containing the certificates described in the
+   following paragraph.  The HTTP content-type of
+   "application/pkcs7-mime" is used.  The Simple PKI Response is sent
+   with a Content-Transfer-Encoding of "base64" [RFC2045].
+
+   The EST server MUST include the current root CA certificate in the
+   response.  The EST server MUST include any additional certificates
+   the client would need to build a chain from an EST CA-issued
+   certificate to the current EST CA TA.  For example, if the EST CA is
+   a subordinate CA, then all the appropriate subordinate CA
+   certificates necessary to build a chain to the root EST CA are
+   included in the response.
+
+   The EST server SHOULD include the three "Root CA Key Update"
+   certificates OldWithOld, OldWithNew, and NewWithOld in the response
+   chain.  These are defined in Section 4.4 of CMP [RFC4210].  The EST
+   client MUST be able to handle these certificates in the response.
+   The EST CA's most recent self-signed certificate (e.g., NewWithNew
+   certificate) is self-signed and has the latest NotAfter date.  If the
+
+
+
+Pritikin, et al.             Standards Track                   [Page 26]
+
+RFC 7030                           EST                      October 2013
+
+
+   EST server does not include these in the response, then after the
+   current EST CA certificate expires, the EST clients will need to be
+   reinitialized with the PKI using the Bootstrap Distribution of CA
+   certificates (Section 4.1.1) method, which involves user interaction.
+
+   After out-of-band validation occurs, all the other certificates MUST
+   be validated using normal [RFC5280] certificate path validation
+   (using the most recent CA certificate as the TA) before they can be
+   used to build certificate paths during certificate validation.
+
+   The EST client MUST store the extracted EST CA certificate as an
+   Explicit TA database entry for subsequent EST server authentication.
+   The EST client SHOULD disable use of Implicit TA database entries for
+   this EST server now that an Explicit TA database entry is available.
+   If the client disables the Implicit TA database, and if the EST
+   server certificate was verified using an Implicit TA database entry,
+   then the client MUST include the "Trusted CA Indication" extension in
+   future TLS sessions [RFC6066].  This indicates to the server that
+   only an EST server certificate authenticatable by the Explicit TA
+   database entry is now acceptable (otherwise, the EST server might
+   continue to use a server certificate that is only verifiable by a now
+   disabled Implicit TA).
+
+   The EST client SHOULD also make the CA Certificate response
+   information available to the end-entity software for use when
+   validating peer certificates.
+
+4.2.  Client Certificate Request Functions
+
+   EST clients request a certificate from the EST server with an HTTPS
+   POST using the operation path value of "/simpleenroll".  EST clients
+   request a renew/rekey of existing certificates with an HTTP POST
+   using the operation path value of "/simplereenroll".  EST servers
+   MUST support the /simpleenroll and /simplereenroll functions.
+
+   It is RECOMMENDED that a client obtain the current CA certificates,
+   as described in Section 4.1, before performing certificate request
+   functions.  This ensures that the client will be able to validate the
+   EST server certificate.  The client MUST authenticate the EST server
+   as specified in Section 3.3.1 if certificate-based authentication is
+   used or Section 3.3.3 if the optional certificate-less authentication
+   is used.  The client MUST verify the authorization of the EST server
+   as specified in Section 3.6.
+
+   The server MUST authenticate the client as specified in Section 3.3.2
+   if certificate-based authentication is used or Section 3.3.3 if the
+   optional certificate-less authentication is used.  The server MUST
+   verify client authorization as specified in Section 3.7.  The EST
+
+
+
+Pritikin, et al.             Standards Track                   [Page 27]
+
+RFC 7030                           EST                      October 2013
+
+
+   server MUST check the tls-unique value, as described in Section 3.5,
+   if one is submitted by the client.
+
+   The server MAY accept a certificate request for manual authorization
+   checking by an administrator.  (Section 4.2.3 describes the use of an
+   HTTP 202 response to the EST client if this occurs.)
+
+4.2.1.  Simple Enrollment of Clients
+
+   When HTTPS POSTing to /simpleenroll, the client MUST include a Simple
+   PKI Request as specified in CMC [RFC5272], Section 3.1 (i.e., a PKCS
+   #10 Certification Request [RFC2986]).
+
+   The Certification Signing Request (CSR) signature provides
+   proof-of-possession of the client-possessed private key to the EST
+   server.  If the CSR KeyUsage extension indicates that the private key
+   can be used to generate digital signatures, then the client MUST
+   generate the CSR signature using the private key.  If the key can be
+   used to generate digital signatures but the requested CSR KeyUsage
+   extension prohibits generation of digital signatures, then the CSR
+   signature MAY still be generated using the private key, but the key
+   MUST NOT be used for any other signature operations (this is
+   consistent with the recommendations concerning submission of
+   proof-of-possession to an RA or CA as described in
+   [SP-800-57-Part-1]).  The use of /fullcmc operations provides access
+   to more advanced proof-of-possession methods that are used when the
+   key pair cannot be used for digital signature generation (see
+   Section 4.3).
+
+   The HTTP content-type of "application/pkcs10" is used here.  The
+   format of the message is as specified in [RFC5967] with a Content-
+   Transfer-Encoding of "base64" [RFC2045].
+
+   If the EST client authenticated using a previously installed
+   certificate issued by a third-party CA (see Section 2.2.1), the
+   client MAY include the ChangeSubjectName attribute, as defined in
+   [RFC6402], in the CSR to request that the subjectName and
+   SubjectAltName be changed in the new certificate.
+
+   The EST client MAY request additional certificates even when using an
+   existing certificate in the TLS client authentication.  For example,
+   the client can use an existing certificate for TLS client
+   authentication when requesting a certificate that cannot be used for
+   TLS client authentication.
+
+
+
+
+
+
+
+Pritikin, et al.             Standards Track                   [Page 28]
+
+RFC 7030                           EST                      October 2013
+
+
+4.2.2.  Simple Re-enrollment of Clients
+
+   EST clients renew/rekey certificates with an HTTPS POST using the
+   operation path value of "/simplereenroll".
+
+   A certificate request employs the same format as the "simpleenroll"
+   request, using the same HTTP content-type.  The request Subject field
+   and SubjectAltName extension MUST be identical to the corresponding
+   fields in the certificate being renewed/rekeyed.  The
+   ChangeSubjectName attribute, as defined in [RFC6402], MAY be included
+   in the CSR to request that these fields be changed in the new
+   certificate.
+
+   If the Subject Public Key Info in the certification request is the
+   same as the current client certificate, then the EST server renews
+   the client certificate.  If the public key information in the
+   certification request is different than the current client
+   certificate, then the EST server rekeys the client certificate.
+
+4.2.3.  Simple Enroll and Re-enroll Response
+
+   If the enrollment is successful, the server response MUST contain an
+   HTTP 200 response code with a content-type of
+   "application/pkcs7-mime".
+
+   A successful response MUST be a certs-only CMC Simple PKI Response,
+   as defined in [RFC5272], containing only the certificate that was
+   issued.  The HTTP content-type of "application/pkcs7-mime" with an
+   smime-type parameter "certs-only" is used, as specified in [RFC5273].
+
+   The server MUST answer with a suitable 4xx or 5xx HTTP [RFC2616]
+   error code when a problem occurs.  A Simple PKI Response with an HTTP
+   content-type of "application/pkcs7-mime" (see Section 4.3.2) MAY be
+   included in the response data to convey an error response.  If the
+   content-type is not set, the response data MUST be a plaintext human-
+   readable error message containing explanatory information describing
+   why the request was rejected (for example, indicating that CSR
+   attributes are incomplete).
+
+   If the server responds with an HTTP [RFC2616] 202, this indicates
+   that the request has been accepted for processing but that a response
+   is not yet available.  The server MUST include a Retry-After header
+   as defined for HTTP 503 responses.  The server also MAY include
+   informative human-readable content.  The client MUST wait at least
+   the specified "retry-after" time before repeating the same request.
+   The client repeats the initial enrollment request after the
+   appropriate "retry-after" interval has expired.  The client SHOULD
+   log or inform the end-user of this event.  The server is responsible
+
+
+
+Pritikin, et al.             Standards Track                   [Page 29]
+
+RFC 7030                           EST                      October 2013
+
+
+   for maintaining all states necessary to recognize and handle retry
+   operations as the client is stateless in this regard; it simply sends
+   the same request repeatedly until it receives a different response
+   code.  All other return codes are handled as specified in HTTP
+   [RFC2616].
+
+   If the client closes the TLS connections while waiting for the Retry-
+   After time to expire, then the client initiates a new TLS connection
+   and performs all applicable security checks.  If the client has
+   already generated a CSR that includes linking identity and POP
+   information (Section 3.5), then the CSR will need to be recreated to
+   incorporate the tls-unique from the new, redirected session.  Note:
+   the key pair need not be regenerated.  These are processing and
+   interface burdens on the client.  EST server administrators are
+   advised to take this into consideration.
+
+   The EST client MAY also make the certificate response, and associated
+   private key, available to end-entity software for use as an
+   end-entity certificate.
+
+4.3.  Full CMC
+
+   An EST client can request a certificate from an EST server with an
+   HTTPS POST using the operation path value of "/fullcmc".  Support for
+   the /fullcmc function is OPTIONAL for both clients and servers.
+
+4.3.1.  Full CMC Request
+
+   If the HTTP POST to /fullcmc is not a valid Full PKI Request, the
+   server MUST reject the message.  The HTTP content-type used is
+   "application/pkcs7-mime" with an smime-type parameter "CMC-request",
+   as specified in [RFC5273].  The body of the message is the binary
+   value of the encoding of the PKI Request with a
+   Content-Transfer-Encoding of "base64" [RFC2045].
+
+4.3.2.  Full CMC Response
+
+   If the enrollment is successful, the server response MUST include an
+   HTTP 200 response code with a content-type of
+   "application/pkcs7-mime" as specified in [RFC5273].  The response
+   data includes either the Simple PKI Response with an smime-type
+   parameter of "certs-only" or the Full PKI Response with an smime-type
+   parameter "CMC-response", as specified in Section 3.2.1 of [RFC5751].
+   The body of the message is the binary value of the encoding of the
+   PKI Response with a Content-Transfer-Encoding of "base64" [RFC2045].
+
+
+
+
+
+
+Pritikin, et al.             Standards Track                   [Page 30]
+
+RFC 7030                           EST                      October 2013
+
+
+   When rejecting a request, the server MUST specify either an HTTP 4xx
+   error or an HTTP 5xx error.  A CMC response with the content-type of
+   "application/pkcs7-mime" MUST be included in the response data for
+   any CMC error response.
+
+   All other return codes are handled as specified in Section 4.2.3 or
+   HTTP [RFC2616].  For example, a client interprets an HTTP 404 or 501
+   response to indicate that this service is not implemented.
+
+4.4.  Server-Side Key Generation
+
+   An EST client may request a private key and associated certificate
+   from an EST server using an HTTPS POST with an operation path value
+   of "/serverkeygen".  Support for the /serverkeygen function is
+   OPTIONAL.
+
+   A client MUST authenticate an EST server, as specified in
+   Section 3.3.1 if certificate-based authentication is used or
+   Section 3.3.3 if the optional certificate-less authentication is
+   used, and check the server's authorization as given in Section 3.6.
+
+   The EST server MUST authenticate the client, as specified in
+   Section 3.3.2 if certificate-based authenticated is used or
+   Section 3.3.3 if the optional certificate-less authentication is
+   used, and check the client's authorization as given in Section 3.7.
+   The EST server applies whatever authorization or logic it chooses to
+   determine if the private key and certificate should be provided.
+
+   Cipher suites that have a NULL confidentiality algorithm MUST NOT be
+   used as they will disclose the contents of an unprotected private
+   key.
+
+   Proper random number and key generation [RFC4086] is a server
+   implementation responsibility, and server archiving of generated keys
+   is determined by CA policy.  The key pair and certificate are
+   transferred over the TLS session.  The cipher suite used to return
+   the private key and certificate MUST offer confidentiality
+   commensurate with the private key being delivered to the client.
+
+   The EST client MAY request additional certificates even when using an
+   existing certificate in the TLS client authentication.  For example,
+   the client can use an existing certificate for TLS client
+   authentication when requesting a certificate that cannot be used for
+   TLS client authentication.
+
+
+
+
+
+
+
+Pritikin, et al.             Standards Track                   [Page 31]
+
+RFC 7030                           EST                      October 2013
+
+
+4.4.1.  Server-Side Key Generation Request
+
+   The certificate request is HTTPS POSTed and is the same format as for
+   the "/simpleenroll" and "/simplereenroll" path extensions with the
+   same content-type and transfer encoding.
+
+   In all respects, the server SHOULD treat the CSR as it would any
+   enroll or re-enroll CSR; the only distinction here is that the server
+   MUST ignore the public key values and signature in the CSR.  These
+   are included in the request only to allow re-use of existing
+   codebases for generating and parsing such requests.
+
+   If the client desires to receive the private key with encryption that
+   exists outside of and in addition to that of the TLS transport used
+   by EST or if server policy requires that the key be delivered in such
+   a form, the client MUST include an attribute in the CSR indicating
+   the encryption key to be used.  Both symmetric and asymmetric
+   encryption are supported as described in the following subsections.
+   The client MUST also include an SMIMECapabilities attribute
+   ([RFC2633], Section 2.5) in the CSR to indicate the key encipherment
+   algorithms the client is willing to use.
+
+   It is strongly RECOMMENDED that the clients request that the returned
+   private key be afforded the additional security of the Cryptographic
+   Message Syntax (CMS) EnvelopedData in addition to the TLS-provided
+   security to protect against unauthorized disclosure.
+
+4.4.1.1.  Requests for Symmetric Key Encryption of the Private Key
+
+   To specify a symmetric encryption key to be used to encrypt the
+   server-generated private key, the client MUST include a
+   DecryptKeyIdentifier attribute (as defined in Section 2.2.5 of
+   [RFC4108]) specifying the identifier of the secret key to be used by
+   the server to encrypt the private key.  While that attribute was
+   originally designated for specifying a firmware encryption key, it
+   exactly mirrors the requirements for specifying a secret key to
+   encrypt a private key.  If the server does not have a secret key
+   matching the identifier specified by the client, the request MUST be
+   terminated and an error returned to the client.  Distribution of the
+   key specified by the DecryptKeyIdentifier to the key generator and
+   the client is outside the scope of this document.
+
+
+
+
+
+
+
+
+
+
+Pritikin, et al.             Standards Track                   [Page 32]
+
+RFC 7030                           EST                      October 2013
+
+
+4.4.1.2.  Requests for Asymmetric Encryption of the Private Key
+
+   To specify an asymmetric encryption key to be used to encrypt the
+   server-generated private key, the client MUST include an
+   AsymmetricDecryptKeyIdentifier attribute.  The
+   AsymmetricDecryptKeyIdentifier attribute is defined as:
+
+   id-aa-asymmDecryptKeyID OBJECT IDENTIFIER ::= {
+       id-aa 54 }
+
+   The asymmetric-decrypt-key-identifier attribute values have ASN.1
+   type AsymmetricDecryptKeyIdentifier (where ASN.1 is defined in
+   [X.680])::
+
+      AsymmetricDecryptKeyIdentifier ::= OCTET STRING
+
+   If the server does not have a public key matching the identifier
+   specified by the client, the request MUST be terminated and an error
+   returned to the client.  Distribution of the key specified by the
+   AsymmetricDecryptKeyIdentifier to the key generator and the client is
+   outside the scope of this document.  If the key identified is bound
+   to an X.509 certificate, then the key MUST either explicitly support
+   keyTransport or keyAgreement or its use MUST be unrestricted.
+
+4.4.2.  Server-Side Key Generation Response
+
+   If the request is successful, the server response MUST have an HTTP
+   200 response code with a content-type of "multipart/mixed" consisting
+   of two parts: one part is the private key data and the other part is
+   the certificate data.
+
+   The format in which the private key data part is returned is
+   dependent on whether the private key is being returned with
+   additional encryption on top of that provided by TLS.
+
+   If additional encryption is not being employed, the private key data
+   MUST be placed in an "application/pkcs8".  An "application/pkcs8"
+   part consists of the base64-encoded DER-encoded [X.690]
+   PrivateKeyInfo with a Content-Transfer-Encoding of "base64"
+   [RFC2045].
+
+   If additional encryption is being employed, the private key is placed
+   inside of a CMS SignedData.  The SignedData is signed by the party
+   that generated the private key, which may or may not be the EST
+   server or the EST CA.  The SignedData is further protected by placing
+   it inside of a CMS EnvelopedData, as described in Section 4 of
+   [RFC5958].  The following list shows how the EncryptedData is used,
+   depending on the type of protection key specified by the client.
+
+
+
+Pritikin, et al.             Standards Track                   [Page 33]
+
+RFC 7030                           EST                      October 2013
+
+
+   o  If the client specified a symmetric encryption key to protect the
+      server-generated private key, the EnvelopedData content is
+      encrypted using the secret key identified in the request.  The
+      EnvelopedData RecipientInfo field MUST indicate the key-encryption
+      kekri key management technique.  The values are as follows:
+      version is set to 4, key-encryption key identifier (kekid) is set
+      to the value of the DecryptKeyIdentifier from Section 4.4.1.1;
+      keyEncryptionAlgorithm is set to one of the key wrap algorithms
+      that the client included in the SMIMECapabilities accompanying the
+      request; and encryptedKey is the encrypted key.
+
+   o  If the client specified an asymmetric encryption key suitable for
+      key transport operations to protect the server-generated private
+      key, the EnvelopedData content is encrypted using a randomly
+      generated symmetric encryption key.  The cryptographic strength of
+      the symmetric encryption key SHOULD be equivalent to the client-
+      specified asymmetric key.  The EnvelopedData RecipientInfo field
+      MUST indicate the KeyTransRecipientInfo (ktri) key management
+      technique.  In KeyTransRecipientInfo, the RecipientIdentifier
+      (rid) is either the subjectKeyIdentifier copied from the attribute
+      defined in Section 4.4.1.2 or the server determines an associated
+      issuerAndSerialNumber from the attribute; version is derived from
+      the choice of rid [RFC5652], keyEncryptionAlgorithm is set to one
+      of the key wrap algorithms that the client included in the
+      SMIMECapabilities accompanying the request, and encryptedKey is
+      the encrypted key.
+
+   o  If the client specified an asymmetric encryption key suitable for
+      key agreement operations to protect the server-generated private
+      key, the EnvelopedData content is encrypted using a randomly
+      generated symmetric encryption key.  The cryptographic strength of
+      the symmetric encryption key SHOULD be equivalent to the client-
+      specified asymmetric key.  The EnvelopedData RecipientInfo field
+      MUST indicate the KeyAgreeRecipientInfo (kari) key management
+      technique.  In the KeyAgreeRecipientInfo type, version,
+      originator, and user keying material (ukm) are as in [RFC5652],
+      and keyEncryptionAlgorithm is set to one of the key wrap
+      algorithms that the client included in the SMIMECapabilities
+      accompanying the request.  The recipient's key identifier is
+      either copied from the attribute defined in Section 4.4.1.2 to
+      subjectKeyIdentifier or the server determines an
+      IssuerAndSerialNumber that corresponds to the value provided in
+      the attribute.
+
+   In all three additional encryption cases, the EnvelopedData is
+   returned in the response as an "application/pkcs7-mime" part with an
+   smime-type parameter of "server-generated-key" and a Content-
+   Transfer-Encoding of "base64".
+
+
+
+Pritikin, et al.             Standards Track                   [Page 34]
+
+RFC 7030                           EST                      October 2013
+
+
+   The certificate data part is an "application/pkcs7-mime" and exactly
+   matches the certificate response to /simpleenroll.
+
+   When rejecting a request, the server MUST specify either an HTTP 4xx
+   error or an HTTP 5xx error.  If the content-type is not set, the
+   response data MUST be a plaintext human-readable error message.
+
+4.5.  CSR Attributes
+
+   CA policy may allow inclusion of client-provided attributes in
+   certificates that it issues, and some of these attributes may
+   describe information that is not available to the CA.  In addition, a
+   CA may desire to certify a certain type of public key and a client
+   may not have a priori knowledge of that fact.  Therefore, clients
+   SHOULD request a list of expected attributes that are required, or
+   desired, by the CA in an enrollment request or if dictated by local
+   policy.
+
+   The EST server SHOULD NOT require client authentication or
+   authorization to reply to this request.
+
+   Requesting CSR attributes is optional, but clients are advised that
+   CAs may refuse enrollment requests that are not encoded according to
+   the CA's policy.
+
+4.5.1.  CSR Attributes Request
+
+   The EST client requests a list of CA-desired CSR attributes from the
+   CA by sending an HTTPS GET message to the EST server with an
+   operations path of "/csrattrs".
+
+4.5.2.  CSR Attributes Response
+
+   If locally configured policy for an authenticated EST client
+   indicates a CSR Attributes Response is to be provided, the server
+   response MUST include an HTTP 200 response code.  An HTTP response
+   code of 204 or 404 indicates that a CSR Attributes Response is not
+   available.  Regardless of the response code, the EST server and CA
+   MAY reject any subsequent enrollment requests for any reason, e.g.,
+   incomplete CSR attributes in the request.
+
+
+
+
+
+
+
+
+
+
+
+Pritikin, et al.             Standards Track                   [Page 35]
+
+RFC 7030                           EST                      October 2013
+
+
+   Responses to attribute request messages MUST be encoded as the
+   content-type of "application/csrattrs" with a
+   Content-Transfer-Encoding of "base64" [RFC2045].  The syntax for
+   application/csrattrs body is as follows:
+
+   CsrAttrs ::= SEQUENCE SIZE (0..MAX) OF AttrOrOID
+
+   AttrOrOID ::= CHOICE (oid OBJECT IDENTIFIER, attribute Attribute }
+
+   Attribute { ATTRIBUTE:IOSet } ::= SEQUENCE {
+        type   ATTRIBUTE.&id({IOSet}),
+        values SET SIZE(1..MAX) OF ATTRIBUTE.&Type({IOSet}{@type}) }
+
+   An EST server includes zero or more OIDs or attributes [RFC2986] that
+   it requests the client to use in the certification request.  The
+   client MUST ignore any OID or attribute it does not recognize.  When
+   the server encodes CSR Attributes as an empty SEQUENCE, it means that
+   the server has no specific additional information it desires in a
+   client certification request (this is functionally equivalent to an
+   HTTP response code of 204 or 404).
+
+   If the CA requires a particular crypto system or use of a particular
+   signature scheme (e.g., certification of a public key based on a
+   certain elliptic curve, or signing using a certain hash algorithm) it
+   MUST provide that information in the CSR Attribute Response.  If an
+   EST server requires the linking of identity and POP information (see
+   Section 3.5), it MUST include the challengePassword OID in the CSR
+   Attributes Response.
+
+   The structure of the CSR Attributes Response SHOULD, to the greatest
+   extent possible, reflect the structure of the CSR it is requesting.
+   Requests to use a particular signature scheme (e.g. using a
+   particular hash function) are represented as an OID to be reflected
+   in the SignatureAlgorithm of the CSR.  Requests to use a particular
+   crypto system (e.g., certification of a public key based on a certain
+   elliptic curve) are represented as an attribute, to be reflected as
+   the AlgorithmIdentifier of the SubjectPublicKeyInfo, with a type
+   indicating the algorithm and the values indicating the particular
+   parameters specific to the algorithm.  Requests for descriptive
+   information from the client are made by an attribute, to be
+   represented as Attributes of the CSR, with a type indicating the
+   [RFC2985] extensionRequest and the values indicating the particular
+   attributes desired to be included in the resulting certificate's
+   extensions.
+
+   The sequence is Distinguished Encoding Rules (DER) encoded [X.690]
+   and then base64 encoded (Section 4 of [RFC4648]).  The resulting text
+   forms the application/csrattr body, without headers.
+
+
+
+Pritikin, et al.             Standards Track                   [Page 36]
+
+RFC 7030                           EST                      October 2013
+
+
+   For example, if a CA requests a client to submit a certification
+   request containing the challengePassword (indicating that linking of
+   identity and POP information is requested; see Section 3.5), an
+   extensionRequest with the Media Access Control (MAC) address
+   ([RFC2307]) of the client, and to use the secp384r1 elliptic curve
+   and to sign with the SHA384 hash function.  Then, it takes the
+   following:
+
+         OID:        challengePassword (1.2.840.113549.1.9.7)
+
+         Attribute:  type = extensionRequest (1.2.840.113549.1.9.14)
+                     value = macAddress (1.3.6.1.1.1.1.22)
+
+         Attribute:  type = id-ecPublicKey (1.2.840.10045.2.1)
+                     value = secp384r1 (1.3.132.0.34)
+
+         OID:        ecdsaWithSHA384 (1.2.840.10045.4.3.3)
+
+   and encodes them into an ASN.1 SEQUENCE to produce:
+
+       30 41 06 09 2a 86 48 86 f7 0d 01 09 07 30 12 06 07 2a 86 48 ce 3d
+       02 01 31 07 06 05 2b 81 04 00 22 30 16 06 09 2a 86 48 86 f7 0d 01
+       09 0e 31 09 06 07 2b 06 01 01 01 01 16 06 08 2a 86 48 ce 3d 04 03
+       03
+
+   and then base64 encodes the resulting ASN.1 SEQUENCE to produce:
+
+       MEEGCSqGSIb3DQEJBzASBgcqhkjOPQIBMQcGBSuBBAAiMBYGCSqGSIb3DQEJDjEJ
+       BgcrBgEBAQEWBggqhkjOPQQDAw==
+
+5.  IANA Considerations
+
+   Section 4.4.1.2 defines an OID that has been registered in an arc
+   delegated by the IANA to the PKIX working group.
+
+   IANA has registered the following:
+
+   IANA updated the well-known URI registry with the following filled-in
+   template from [RFC5785].
+
+      URI suffix: est
+
+      Change controller: IETF
+
+
+
+
+
+
+
+
+Pritikin, et al.             Standards Track                   [Page 37]
+
+RFC 7030                           EST                      October 2013
+
+
+   IANA has updated the "Application Media Types" registry with the
+   following filled-in templates from [RFC6838].
+
+   The media subtype for CSR attributes in a CSR Attributes Response is
+   application/csrattrs.
+
+       Type name: application
+
+       Subtype name: csrattrs
+
+       Required parameters: None
+
+       Optional parameters: None
+
+       Encoding considerations: binary;
+
+       Security Considerations:
+
+         Clients request a list of attributes that servers wish to be in
+         certification requests.  The request/response is normally done
+         in a TLS-protected tunnel.
+
+       Interoperability considerations: None
+
+       Published specification: This memo.
+
+       Applications which use this media type: Enrollment over Secure
+       Transport (EST)
+
+       Additional information:
+
+         Magic number(s): None
+
+         File extension: .csrattrs
+
+       Person & email address to contact for further information:
+
+         Dan Harkins <dharkins@arubanetworks.com>
+
+       Restrictions on usage: None
+
+       Author: Dan Harkins <dharkins@arubanetworks.com>
+
+       Intended usage: COMMON
+
+       Change controller: The IESG <iesg@ietf.org>
+
+
+
+
+
+Pritikin, et al.             Standards Track                   [Page 38]
+
+RFC 7030                           EST                      October 2013
+
+
+   The application/pkcs7-mime content-type defines the optional
+   "smime-type" parameter [RFC5751] with a set of specific values.  This
+   document adds another value, "server-generated-key", as the parameter
+   value for Server-side Key Generation Response.
+
+6.  Security Considerations
+
+   Support for Basic authentication, as specified in HTTP [RFC2617],
+   allows the server access to a client's cleartext password.  This
+   provides support for legacy username/password databases but requires
+   exposing the plaintext password to the EST server.  Use of a PIN or
+   one-time password can help mitigate such exposure, but it is
+   RECOMMENDED that EST clients use such credentials only once to obtain
+   a client certificate (that will be used during future interactions
+   with the EST server).
+
+   When a client uses the Implicit TA database for certificate
+   validation (see Section 3), then authorization proceeds as specified
+   in Section 3.6.2.  In this situation, the client has validated the
+   server as being a responder that is certified by a third party for
+   the URI configured, but it cannot verify that the responder is
+   authorized to act as an RA for the PKI in which the client is trying
+   to enroll.  Clients using an Implicit Trust Anchor database are
+   RECOMMENDED to use only TLS-based client authentication (to prevent
+   exposing HTTP-based client authentication information).  It is
+   RECOMMENDED that such clients include "Linking Identity and POP
+   Information" (Section 3.5) in requests (to prevent such requests from
+   being forwarded to a real EST server by a man in the middle).  It is
+   RECOMMENDED that the Implicit Trust Anchor database used for EST
+   server authentication be carefully managed to reduce the chance of a
+   third-party CA with poor certification practices from being trusted.
+   Disabling the Implicit Trust Anchor database after successfully
+   receiving the Distribution of CA certificates response
+   (Section 4.1.3) limits any vulnerability to the first TLS exchange.
+
+   Certificate-less TLS cipher suites that maintain security and perform
+   the mutual authentication necessary for enrollment have the following
+   properties:
+
+   o  the only information leaked by an active attack is whether or not
+      a single guess of the secret is correct.
+
+   o  any advantage an adversary gains is through interaction and not
+      computation.
+
+   o  it is possible to perform countermeasures, such as exponential
+      backoff after a certain number of failed attempts, to frustrate
+      repeated active attacks.
+
+
+
+Pritikin, et al.             Standards Track                   [Page 39]
+
+RFC 7030                           EST                      October 2013
+
+
+   Using a certificate-less cipher suite that does not have the
+   properties listed above would render the results of enrollment void
+   and potentially result in certificates being issued to
+   unauthenticated and/or unauthorized entities.
+
+   When using a certificate-less TLS cipher suite, the shared secret
+   used for authentication and authorization cannot be shared with an
+   entity that is not a party to the exchange: someone other than the
+   client and the server.  Any additional sharing of secrets voids the
+   security afforded by a certificate-less cipher suite.  Exposure of a
+   shared secret used by a certificate-less cipher suite to a third
+   party enables client impersonation that can result in corruption of a
+   client's trust anchor database.
+
+   TLS cipher suites that include "_EXPORT_" and "_DES_" in their names
+   MUST NOT be used.  These ciphers do not offer a sufficient level of
+   protection; 40-bit crypto in 2013 doesn't offer acceptable
+   protection, and the use of DES is deprecated.
+
+   As described in CMC, Section 6.7 of [RFC5272], "For keys that can be
+   used as signature keys, signing the certification request with the
+   private key serves as a POP on that key pair".  The inclusion of tls-
+   unique within the certification request links the proof-of-possession
+   to the TLS proof-of-identity by enforcing that the POP operation
+   occurred while the TLS session was active.  This implies to the
+   server that the authenticated client currently has access to the
+   private key.  If the authenticated client is known to have specific
+   capabilities, such as hardware protection for authentication
+   credentials and key storage, this implication is strengthened but not
+   proven.
+
+   The server-side key generation method allows keys to be transported
+   over the TLS connection to the client without any application-layer
+   protection.  The distribution of private key material is inherently
+   risky.  Private key distribution uses the encryption mode of the
+   negotiated TLS cipher suite.  Keys are not protected by preferred key
+   wrapping methods such as AES Key Wrap [RFC3394] or as specified in
+   [RFC5958] as encryption of the private key beyond that provided by
+   TLS is optional.  It is RECOMMENDED that EST servers not support this
+   operation by default.  It is RECOMMENDED that clients not request
+   this service unless there is a compelling operational benefit.  Use
+   of an Implicit Trust Anchor database is NOT RECOMMENDED when
+   server-side key generation is employed.  The use of an encrypted CMS
+   Server-Side Key Generation Response is RECOMMENDED.
+
+   Regarding the CSR attributes that the CA may list for inclusion in an
+   enrollment request, there are no real inherent security issues with
+   the content being conveyed, but an adversary who is able to interpose
+
+
+
+Pritikin, et al.             Standards Track                   [Page 40]
+
+RFC 7030                           EST                      October 2013
+
+
+   herself into the conversation could exclude attributes that a server
+   may want, include attributes that a server may not want, and render
+   meaningless other attributes that a server may want.
+
+   ASN.1 encoding rules (e.g., DER and BER) have a type-length-value
+   structure, and it is easy to construct malicious content with invalid
+   length fields that can cause buffer overrun conditions.  ASN.1
+   encoding rules allow for arbitrary levels of nesting, which may make
+   it possible to construct malicious content that will cause a stack
+   overflow.  Interpreters of ASN.1 structures should be aware of these
+   issues and should take appropriate measures to guard against buffer
+   overflows and stack overruns in particular, and malicious content in
+   general.
+
+7.  References
+
+7.1.  Normative References
+
+   [RFC2045]  Freed, N. and N. Borenstein, "Multipurpose Internet Mail
+              Extensions (MIME) Part One: Format of Internet Message
+              Bodies", RFC 2045, November 1996.
+
+   [RFC2119]  Bradner, S., "Key words for use in RFCs to Indicate
+              Requirement Levels", BCP 14, RFC 2119, March 1997.
+
+   [RFC2585]  Housley, R. and P. Hoffman, "Internet X.509 Public Key
+              Infrastructure Operational Protocols: FTP and HTTP", RFC
+              2585, May 1999.
+
+   [RFC2616]  Fielding, R., Gettys, J., Mogul, J., Frystyk, H.,
+              Masinter, L., Leach, P., and T. Berners-Lee, "Hypertext
+              Transfer Protocol -- HTTP/1.1", RFC 2616, June 1999.
+
+   [RFC2617]  Franks, J., Hallam-Baker, P., Hostetler, J., Lawrence, S.,
+              Leach, P., Luotonen, A., and L. Stewart, "HTTP
+              Authentication: Basic and Digest Access Authentication",
+              RFC 2617, June 1999.
+
+   [RFC2633]  Ramsdell, B., "S/MIME Version 3 Message Specification",
+              RFC 2633, June 1999.
+
+   [RFC2986]  Nystrom, M. and B. Kaliski, "PKCS #10: Certification
+              Request Syntax Specification Version 1.7", RFC 2986,
+              November 2000.
+
+   [RFC3986]  Berners-Lee, T., Fielding, R., and L. Masinter, "Uniform
+              Resource Identifier (URI): Generic Syntax", STD 66, RFC
+              3986, January 2005.
+
+
+
+Pritikin, et al.             Standards Track                   [Page 41]
+
+RFC 7030                           EST                      October 2013
+
+
+   [RFC4086]  Eastlake, D., Schiller, J., and S. Crocker, "Randomness
+              Requirements for Security", BCP 106, RFC 4086, June 2005.
+
+   [RFC4108]  Housley, R., "Using Cryptographic Message Syntax (CMS) to
+              Protect Firmware Packages", RFC 4108, August 2005.
+
+   [RFC4210]  Adams, C., Farrell, S., Kause, T., and T. Mononen,
+              "Internet X.509 Public Key Infrastructure Certificate
+              Management Protocol (CMP)", RFC 4210, September 2005.
+
+   [RFC4346]  Dierks, T. and E. Rescorla, "The Transport Layer Security
+              (TLS) Protocol Version 1.1", RFC 4346, April 2006.
+
+   [RFC4648]  Josefsson, S., "The Base16, Base32, and Base64 Data
+              Encodings", RFC 4648, October 2006.
+
+   [RFC5077]  Salowey, J., Zhou, H., Eronen, P., and H. Tschofenig,
+              "Transport Layer Security (TLS) Session Resumption without
+              Server-Side State", RFC 5077, January 2008.
+
+   [RFC5246]  Dierks, T. and E. Rescorla, "The Transport Layer Security
+              (TLS) Protocol Version 1.2", RFC 5246, August 2008.
+
+   [RFC5272]  Schaad, J. and M. Myers, "Certificate Management over CMS
+              (CMC)", RFC 5272, June 2008.
+
+   [RFC5273]  Schaad, J. and M. Myers, "Certificate Management over CMS
+              (CMC): Transport Protocols", RFC 5273, June 2008.
+
+   [RFC5274]  Schaad, J. and M. Myers, "Certificate Management Messages
+              over CMS (CMC): Compliance Requirements", RFC 5274, June
+              2008.
+
+   [RFC5280]  Cooper, D., Santesson, S., Farrell, S., Boeyen, S.,
+              Housley, R., and W. Polk, "Internet X.509 Public Key
+              Infrastructure Certificate and Certificate Revocation List
+              (CRL) Profile", RFC 5280, May 2008.
+
+   [RFC5652]  Housley, R., "Cryptographic Message Syntax (CMS)", STD 70,
+              RFC 5652, September 2009.
+
+   [RFC5746]  Rescorla, E., Ray, M., Dispensa, S., and N. Oskov,
+              "Transport Layer Security (TLS) Renegotiation Indication
+              Extension", RFC 5746, February 2010.
+
+   [RFC5751]  Ramsdell, B. and S. Turner, "Secure/Multipurpose Internet
+              Mail Extensions (S/MIME) Version 3.2 Message
+              Specification", RFC 5751, January 2010.
+
+
+
+Pritikin, et al.             Standards Track                   [Page 42]
+
+RFC 7030                           EST                      October 2013
+
+
+   [RFC5785]  Nottingham, M. and E. Hammer-Lahav, "Defining Well-Known
+              Uniform Resource Identifiers (URIs)", RFC 5785, April
+              2010.
+
+   [RFC5929]  Altman, J., Williams, N., and L. Zhu, "Channel Bindings
+              for TLS", RFC 5929, July 2010.
+
+   [RFC5958]  Turner, S., "Asymmetric Key Packages", RFC 5958, August
+              2010.
+
+   [RFC6066]  Eastlake, D., "Transport Layer Security (TLS) Extensions:
+              Extension Definitions", RFC 6066, January 2011.
+
+   [RFC6125]  Saint-Andre, P. and J. Hodges, "Representation and
+              Verification of Domain-Based Application Service Identity
+              within Internet Public Key Infrastructure Using X.509
+              (PKIX) Certificates in the Context of Transport Layer
+              Security (TLS)", RFC 6125, March 2011.
+
+   [RFC6402]  Schaad, J., "Certificate Management over CMS (CMC)
+              Updates", RFC 6402, November 2011.
+
+   [RFC6454]  Barth, A., "The Web Origin Concept", RFC 6454, December
+              2011.
+
+   [RFC6838]  Freed, N., Klensin, J., and T. Hansen, "Media Type
+              Specifications and Registration Procedures", BCP 13, RFC
+              6838, January 2013.
+
+   [X.680]    ITU-T Recommendation X.680 (2008) | ISO/IEC 8824-1:2008,
+              "Abstract Syntax Notation One (ASN.1): Specification of
+              basic notation", November 2008,
+              <http://www.itu.int/rec/T-REC-X.680-200811-I/en>.
+
+   [X.690]    ITU-T Recommendation X.690 (2008) | ISO/IEC 8825-1:2008,
+              "ASN.1 encoding rules: Specification of Basic Encoding
+              Rules (BER), Canonical Encoding Rules (CER) and
+              Distinguished Encoding Rules (DER)", November 2008,
+              <http://www.itu.int/rec/T-REC-X.690-200811-I/en>.
+
+7.2.  Informative References
+
+   [IDevID]   IEEE Standards Association, "IEEE 802.1AR Secure Device
+              Identifier", December 2009, <http://standards.ieee.org/
+              findstds/standard/802.1AR-2009.html>.
+
+   [RFC2307]  Howard, L., "An Approach for Using LDAP as a Network
+              Information Service", RFC 2307, March 1998.
+
+
+
+Pritikin, et al.             Standards Track                   [Page 43]
+
+RFC 7030                           EST                      October 2013
+
+
+   [RFC2818]  Rescorla, E., "HTTP Over TLS", RFC 2818, May 2000.
+
+   [RFC2985]  Nystrom, M. and B. Kaliski, "PKCS #9: Selected Object
+              Classes and Attribute Types Version 2.0", RFC 2985,
+              November 2000.
+
+   [RFC3394]  Schaad, J. and R. Housley, "Advanced Encryption Standard
+              (AES) Key Wrap Algorithm", RFC 3394, September 2002.
+
+   [RFC5054]  Taylor, D., Wu, T., Mavrogiannopoulos, N., and T. Perrin,
+              "Using the Secure Remote Password (SRP) Protocol for TLS
+              Authentication", RFC 5054, November 2007.
+
+   [RFC5967]  Turner, S., "The application/pkcs10 Media Type", RFC 5967,
+              August 2010.
+
+   [RFC6403]  Zieglar, L., Turner, S., and M. Peck, "Suite B Profile of
+              Certificate Management over CMS", RFC 6403, November 2011.
+
+   [SHS]      National Institute of Standards and Technology, "Secure
+              Hash Standard (SHS)", Federal Information Processing
+              Standard Publication 180-4, March 2012,
+              <http://csrc.nist.gov/publications/fips/
+              fips180-4/fips-180-4.pdf>.
+
+   [SP-800-57-Part-1]
+              National Institute of Standards and Technology,
+              "Recommendation for Key Management - Part 1: General
+              (Revision 3)", July 2012,
+              <http://csrc.nist.gov/publications/nistpubs/800-57/
+              sp800-57_part1_rev3_general.pdf>.
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Pritikin, et al.             Standards Track                   [Page 44]
+
+RFC 7030                           EST                      October 2013
+
+
+Appendix A.  Operational Scenario Example Messages
+
+   (Informative)
+
+   This section expands on the Operational Scenario Overviews by
+   providing detailed examples of the messages at each TLS layer.
+
+A.1.  Obtaining CA Certificates
+
+   The following is an example of a valid /cacerts exchange.
+
+   During the initial TLS handshake, the client can ignore the optional
+   server-generated "certificate request" and can instead proceed with
+   the HTTP GET request:
+
+   GET /.well-known/est/cacerts HTTP/1.1
+   User-Agent: curl/7.22.0 (i686-pc-linux-gnu) libcurl/7.22.0 OpenS
+   SL/1.0.1 zlib/1.2.3.4 libidn/1.23 librtmp/2.3
+   Host: 192.0.2.1:8085
+   Accept: */*
+
+   In response, the server provides the current CA certificates:
+
+   HTTP/1.1 200 OK
+   Status: 200 OK
+   Content-Type: application/pkcs7-mime
+   Content-Transfer-Encoding: base64
+   Content-Length: 4246
+
+   MIIMOQYJKoZIhvcNAQcCoIIMKjCCDCYCAQExADALBgkqhkiG9w0BBwGgggwMMIIC
+   +zCCAeOgAwIBAgIJAJpY3nUZO3qcMA0GCSqGSIb3DQEBBQUAMBsxGTAXBgNVBAMT
+   EGVzdEV4YW1wbGVDQSBPd08wHhcNMTMwNTA5MDM1MzMxWhcNMTQwNTA5MDM1MzMx
+   WjAbMRkwFwYDVQQDExBlc3RFeGFtcGxlQ0EgT3dPMIIBIjANBgkqhkiG9w0BAQEF
+   AAOCAQ8AMIIBCgKCAQEAwDqpiHopaICubpRqbpEN7LqTIqWELFIA9qDDheHIKuyO
+   HW/ZAP7Rl4S5ZU6gaLW/ksseBUxdmox3KNyvtyjehIofTu28eZWhgy6/LCEGWR3P
+   K+fgPBA0l0JfJR/8oeXZa70oLVQc3hI4kCeqjFMs+biYH0vp/RluhftyZ5kzQyH1
+   EGsRkw1/qUKkTZ8PCF8VFlYfqmUoqsaRTyZbjII4J+Y6/jEG+p7QreW9zcz4sPe8
+   3c/uhwMLOWQkZtKsQtgo5CpfYMjuAmk4Q2joQq2vcxlc+WNKHf+wbrDb11ORZril
+   9ISlI94oumcRz3uBG1Yg7z83hdDfasmdfbp8gOSNFQIDAQABo0IwQDAPBgNVHRMB
+   Af8EBTADAQH/MB0GA1UdDgQWBBQITTKxMqATXrfc4ffpCIbt6Gsz0jAOBgNVHQ8B
+   Af8EBAMCAQYwDQYJKoZIhvcNAQEFBQADggEBACPnQPu5WReUGuCMS0nBOGa2tXh6
+   uZP4mS3J1qEfDePam/IiU9ssyYdcDwhVvKMoP4gI/yu4XFqhdpIoy/PyD4T15MT7
+   KADCxXkh5rM1IqMui7FvBKLWYGdy9sjEf90wAkBjHBe/TMO1NNw3uELyONSkHIvo
+   X0pu6aPmm/moIMyGi46niFse1iWlXXldGLkOQsh0e7U+wpBX07QpOr2KB2+Yf+uA
+   KY1SWzEG23bUxXlvcbUMgANDGj5r6z+niKL0VlApip/iCuVEEOcZ91UlmJjVLQWA
+   x6ie+v84oM+pIojiGM0C4XWcVlKKEgcMOsN3S4lvm8Ptpq0GLoIJY8NTD20wggMD
+   MIIB66ADAgECAgEBMA0GCSqGSIb3DQEBBQUAMBsxGTAXBgNVBAMTEGVzdEV4YW1w
+   bGVDQSBPd08wHhcNMTMwNTA5MDM1MzMyWhcNMTQwNTA5MDM1MzMyWjAbMRkwFwYD
+
+
+
+Pritikin, et al.             Standards Track                   [Page 45]
+
+RFC 7030                           EST                      October 2013
+
+
+   VQQDExBlc3RFeGFtcGxlQ0EgTndPMIIBIjANBgkqhkiG9w0BAQEFAAOCAQ8AMIIB
+   CgKCAQEAnn3rZ3rMJHwf7MD9K4mubxHAvtdnrsQf5OfgtMhRIL4aePNhAdgPyj8C
+   loxOgD3UTV+dQ1ViOzVxPN7acikoOnkIdRpjpOpkyMo+KkvHMQXGnQTbsMAv1qWt
+   9S12DMpo0GOA1e4Ge3ud5YPOTR/q6PvjN51IEwYKksG7CglwZwB+5JbwhYr2D/0u
+   btGltriRVixPWrvt+wz/ITp5rcjh/8RS3LE8tQy3kTNhJF3Y/esR2sSgOiPNgIto
+   CATysbaINEPr4MemqML4tDpR/aG9y+8Qe7s1LyMFvDletp2mmBykAC/7nOat/pwU
+   lB0sN524D1XAgz8ZKvWrkh+ZaOr3hwIDAQABo1IwUDAOBgNVHQ8BAf8EBAMCBLAw
+   HQYDVR0OBBYEFLHEaeZbowSn2Jejizu/uWqyMkI8MB8GA1UdIwQYMBaAFAhNMrEy
+   oBNet9zh9+kIhu3oazPSMA0GCSqGSIb3DQEBBQUAA4IBAQCLDkL7aLNV6hSOkIqH
+   q+shV9YLO56/tj00vY/jV5skgDHk5d0B+OGortKVuGa57+v0avTrlJns3bNW8Ntv
+   zkDEhmd00Ak02aPsi4wRHLFgttUf9HdEHAuTkAESPTU43DiptjkfHhtBMfsFrCkd
+   sxWzCz+prDOMHYfUEkhRVV++1zyGEX6ov1Ap2IU2p3E+ASihL/amxTEQAsbwjUTI
+   R52zoL6nMPzpbKeZi2M0eEBVF8sDueA9Hjo6woLjgJqV0/yc5vC2HAxUOhx0cWTY
+   GcRBgL/yOyQLKiY5TKBH951OjQ4vhF2HmcoO7DkcNLYJOge16ssx4ogBHul20VgF
+   XJJjMIIDAzCCAeugAwIBAgIBAjANBgkqhkiG9w0BAQUFADAbMRkwFwYDVQQDExBl
+   c3RFeGFtcGxlQ0EgTndOMB4XDTEzMDUwOTAzNTMzMloXDTE0MDUwOTAzNTMzMlow
+   GzEZMBcGA1UEAxMQZXN0RXhhbXBsZUNBIE93TjCCASIwDQYJKoZIhvcNAQEBBQAD
+   ggEPADCCAQoCggEBAMA6qYh6KWiArm6Uam6RDey6kyKlhCxSAPagw4XhyCrsjh1v
+   2QD+0ZeEuWVOoGi1v5LLHgVMXZqMdyjcr7co3oSKH07tvHmVoYMuvywhBlkdzyvn
+   4DwQNJdCXyUf/KHl2Wu9KC1UHN4SOJAnqoxTLPm4mB9L6f0ZboX7cmeZM0Mh9RBr
+   EZMNf6lCpE2fDwhfFRZWH6plKKrGkU8mW4yCOCfmOv4xBvqe0K3lvc3M+LD3vN3P
+   7ocDCzlkJGbSrELYKOQqX2DI7gJpOENo6EKtr3MZXPljSh3/sG6w29dTkWa4pfSE
+   pSPeKLpnEc97gRtWIO8/N4XQ32rJnX26fIDkjRUCAwEAAaNSMFAwDgYDVR0PAQH/
+   BAQDAgSwMB0GA1UdDgQWBBQITTKxMqATXrfc4ffpCIbt6Gsz0jAfBgNVHSMEGDAW
+   gBSxxGnmW6MEp9iXo4s7v7lqsjJCPDANBgkqhkiG9w0BAQUFAAOCAQEALhDaE6Mp
+   BINBsJozdbXlijrWxL1CSv8f4GwpUFk3CgZjibt/qW9UoaNR4E58yRopuEhjwFZK
+   2w8YtRqx8IZoFhcoLkpBDfgLLwhoztzbYvOVKQMidjBlkBEVNR5MWdrs7F/AxWuy
+   iZ2+8AnR8GwqEIbCD0A7xIghmWEMh/BVI9C7GLqd6PxKrTAjuDfEpfdWhU/uYKmK
+   cL3XDbSwr30j2EQyaTV/3W0Tn2UfuxdwDQ4ZJs9G+Mw50s7AG6CpISyOIFmX6/bU
+   DpJXGLiLwfJ9C/aum9nylYuGCJ68BuTrCs9567KGfXEXI0mdFFCL7TaVR43kjsg3
+   c43kZ7369MeEZzCCAvswggHjoAMCAQICCQDprp3DmjOyETANBgkqhkiG9w0BAQUF
+   ADAbMRkwFwYDVQQDExBlc3RFeGFtcGxlQ0EgTndOMB4XDTEzMDUwOTAzNTMzMloX
+   DTE0MDUwOTAzNTMzMlowGzEZMBcGA1UEAxMQZXN0RXhhbXBsZUNBIE53TjCCASIw
+   DQYJKoZIhvcNAQEBBQADggEPADCCAQoCggEBAJ5962d6zCR8H+zA/SuJrm8RwL7X
+   Z67EH+Tn4LTIUSC+GnjzYQHYD8o/ApaMToA91E1fnUNVYjs1cTze2nIpKDp5CHUa
+   Y6TqZMjKPipLxzEFxp0E27DAL9alrfUtdgzKaNBjgNXuBnt7neWDzk0f6uj74zed
+   SBMGCpLBuwoJcGcAfuSW8IWK9g/9Lm7Rpba4kVYsT1q77fsM/yE6ea3I4f/EUtyx
+   PLUMt5EzYSRd2P3rEdrEoDojzYCLaAgE8rG2iDRD6+DHpqjC+LQ6Uf2hvcvvEHu7
+   NS8jBbw5XradppgcpAAv+5zmrf6cFJQdLDeduA9VwIM/GSr1q5IfmWjq94cCAwEA
+   AaNCMEAwDwYDVR0TAQH/BAUwAwEB/zAdBgNVHQ4EFgQUscRp5lujBKfYl6OLO7+5
+   arIyQjwwDgYDVR0PAQH/BAQDAgEGMA0GCSqGSIb3DQEBBQUAA4IBAQBCz/CWdYvn
+   GM/SdCdEiom5A1VxaW8nKgCWg/EyWtAIiaHQuViB+jTUAE9lona2MbJoFHW8U5e8
+   9dCP0rJpA9UYXXhWvFQzd5ZWpms4wUYt1j3gqqd36KorJIAuPigVng13yKytxM7c
+   VmxQnh0aux3aEnEyRGAhGalHp0RaKdgPRzUaGtipJTNBkSV5S4kD4yDCPHMNbBu+
+   OcluerwEpbz6GvE7CpXl2jrTBZSqBsFelq0iz4kk9++9CnwZwrVgdzklhRfJ1Z4j
+   NkLruwbQ+o4NvBZsXiKxNfn3K2o3SK8AuaEyDWkq18+5rjcfprRO8x4YTW+6mXPq
+   jM0MAGNDEW+1oQAxAA==
+
+
+
+
+Pritikin, et al.             Standards Track                   [Page 46]
+
+RFC 7030                           EST                      October 2013
+
+
+A.2.  CSR Attributes
+
+   The following is an example of a valid /csrattrs exchange.  During
+   this exchange, the EST client authenticates itself using an existing
+   certificate issued by the CA for which the EST server provides
+   services.
+
+   The initial TLS handshake is identical to the enrollment example
+   handshake.  The HTTP GET request:
+
+   GET /.well-known/est/csrattrs HTTP/1.1
+   User-Agent: curl/7.22.0 (i686-pc-linux-gnu) libcurl/7.22.0 OpenS
+   SL/1.0.1 zlib/1.2.3.4 libidn/1.23 librtmp/2.3
+   Host: 192.0.2.1:8085
+   Accept: */*
+
+   In response, the server provides suggested attributes that are
+   appropriate for the authenticated client.  In this example, the EST
+   server also includes two example attributes that the client would
+   ignore unless the attribute type is known to the client:
+
+   HTTP/1.1 200 OK
+   Status: 200 OK
+   Content-Type: application/csrattrs
+   Content-Transfer-Encoding: base64
+   Content-Length: 171
+
+   MHwGBysGAQEBARYwIgYDiDcBMRsTGVBhcnNlIFNFVCBhcyAyLjk5OS4xIGRhdGEG
+   CSqGSIb3DQEJBzAsBgOINwIxJQYDiDcDBgOINwQTGVBhcnNlIFNFVCBhcyAyLjk5
+   OS4yIGRhdGEGCSskAwMCCAEBCwYJYIZIAWUDBAIC
+
+A.3.  Enroll/Re-enroll
+
+   The following is an example of a valid /simpleenroll exchange.  The
+   data messages for /simplereenroll are similar.
+
+   During this exchange, the EST client uses an out-of-band distributed
+   username/password to authenticate itself to the EST server.  This is
+   the normal HTTP WWW-Authenticate behavior and is included here for
+   informative purposes.  When an existing TLS client certificate is
+   used, the server might skip requesting the HTTP WWW-Authenticate
+   header, such as during a /simplereenroll operation.
+
+   During the initial TLS handshake, the client can ignore the optional
+   server-generated "certificate request" and can instead proceed with
+   the HTTP POST request.  In response to the initial HTTP POST attempt,
+
+
+
+
+
+Pritikin, et al.             Standards Track                   [Page 47]
+
+RFC 7030                           EST                      October 2013
+
+
+   the server requests WWW-Authenticate from the client (this might
+   occur even if the client used a client certificate, as detailed in
+   the normative text above):
+
+   HTTP/1.1 401 Unauthorized
+   Content-Length: 0
+   WWW-Authenticate: Digest qop="auth", realm="estrealm",
+   nonce="1368141352"
+
+   In the subsequent HTTP POST, the username/password is included, along
+   with the complete application/pkcs10 content:
+
+   POST /.well-known/est/simpleenroll HTTP/1.1
+   Authorization: Digest username="estuser", realm="estrealm", nonc
+   e="1368141352", uri="/.well-known/est/simpleenroll", cnonce="M
+   TYwMzg3", nc=00000001, qop="auth", response="144cc27f96046f1d70e
+   b16db20f75f22"
+   Host: 192.0.2.1:8085
+   Accept: */*
+   Content-Type: application/pkcs10
+   Content-Transfer-Encoding: base64
+   Content-Length: 882
+
+   MIIChTCCAW0CAQAwHzEdMBsGA1UEAxMUZGVtb3N0ZXA0IDEzNjgxNDEzNTIwggEi
+   MA0GCSqGSIb3DQEBAQUAA4IBDwAwggEKAoIBAQClNp+kdz+Nj8XpEp9kaumWxDZ3
+   eFYJpQKz9ddD5e5OzUeCm103ZIXQIxc0eVtMCatnRr3dnZRCAxGjwbqoB3eKt29/
+   XSQffVv+odbyw0WdkQOIbntCQry8YdcBZ+8LjI/N7M2krmjmoSLmLwU2V4aNKf0Y
+   MLR5Krmah3Ik31jmYCSvwTnv6mx6pr2pTJ82JavhTEIIt/fAYq1RYhkM1CXoBL+y
+   hEoDanN7TzC94skfS3VV+f53J9SkUxTYcy1Rw0k3VXfxWwy+cSKEPREl7I6k0YeK
+   tDEVAgBIEYM/L1S69RXTLujirwnqSRjOquzkAkD31BE961KZCxeYGrhxaR4PAgMB
+   AAGgITAfBgkqhkiG9w0BCQcxEhMQK3JyQ2lyLzcrRVl1NTBUNDANBgkqhkiG9w0B
+   AQUFAAOCAQEARBv0AJeXaHpl1MFIdzWqoi1dOCf6U+qaYWcBzpLADvJrPK1qx5pq
+   wXM830A1O+7RvrFv+nyd6VF2rl/MrNp+IsKuA9LYWIBjVe/LXoBO8dB/KxrYl16c
+   VUS+Yydi1m/a+DaftYSRGolMLtWeiqbc2SDBr2kHXW1TR130hIcpwmr29kC2Kzur
+   5thsuj276FGL1vPu0dRfGQfx4WWa9uAHBgz6tW37CepZsrUKe/0pfVhr2oHxApYh
+   cHGBQDQHVTFVjHccdUjAXicrtbsVhU5o1lPv7f4lEApv3SBQmJcaq5O832BzHw7n
+   PyMFcM15E9gtUVee5C62bVwuk/tbnGsbwQ==
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Pritikin, et al.             Standards Track                   [Page 48]
+
+RFC 7030                           EST                      October 2013
+
+
+   The EST server uses the username/password to perform
+   authentication/authorization and responds with the issued
+   certificate:
+
+   HTTP/1.1 200 OK
+   Status: 200 OK
+   Content-Type: application/pkcs7-mime; smime-type=certs-only
+   Content-Transfer-Encoding: base64
+   Content-Length: 1122
+
+   MIIDOAYJKoZIhvcNAQcCoIIDKTCCAyUCAQExADALBgkqhkiG9w0BBwGgggMLMIID
+   BzCCAe+gAwIBAgIBFTANBgkqhkiG9w0BAQUFADAbMRkwFwYDVQQDExBlc3RFeGFt
+   cGxlQ0EgTndOMB4XDTEzMDUwOTIzMTU1M1oXDTE0MDUwOTIzMTU1M1owHzEdMBsG
+   A1UEAxMUZGVtb3N0ZXA0IDEzNjgxNDEzNTIwggEiMA0GCSqGSIb3DQEBAQUAA4IB
+   DwAwggEKAoIBAQClNp+kdz+Nj8XpEp9kaumWxDZ3eFYJpQKz9ddD5e5OzUeCm103
+   ZIXQIxc0eVtMCatnRr3dnZRCAxGjwbqoB3eKt29/XSQffVv+odbyw0WdkQOIbntC
+   Qry8YdcBZ+8LjI/N7M2krmjmoSLmLwU2V4aNKf0YMLR5Krmah3Ik31jmYCSvwTnv
+   6mx6pr2pTJ82JavhTEIIt/fAYq1RYhkM1CXoBL+yhEoDanN7TzC94skfS3VV+f53
+   J9SkUxTYcy1Rw0k3VXfxWwy+cSKEPREl7I6k0YeKtDEVAgBIEYM/L1S69RXTLuji
+   rwnqSRjOquzkAkD31BE961KZCxeYGrhxaR4PAgMBAAGjUjBQMA4GA1UdDwEB/wQE
+   AwIEsDAdBgNVHQ4EFgQU/qDdB6ii6icQ8wGMXvy1jfE4xtUwHwYDVR0jBBgwFoAU
+   scRp5lujBKfYl6OLO7+5arIyQjwwDQYJKoZIhvcNAQEFBQADggEBACmxg1hvL6+7
+   a+lFTARoxainBx5gxdZ9omSb0L+qL+4PDvg/+KHzKsDnMCrcU6M4YP5n0EDKmGa6
+   4lY8fbET4tt7juJg6ixb95/760Th0vuctwkGr6+D6ETTfqyHnrbhX3lAhnB+0Ja7
+   o1gv4CWxh1I8aRaTXdpOHORvN0SMXdcrlCys2vrtOl+LjR2a3kajJO6eQ5leOdzF
+   QlZfOPhaLWen0e2BLNJI0vsC2Fa+2LMCnfC38XfGALa5A8e7fNHXWZBjXZLBCza3
+   rEs9Mlh2CjA/ocSC/WxmMvd+Eqnt/FpggRy+F8IZSRvBaRUCtGE1lgDmu6AFUxce
+   R4POrT2xz8ChADEA
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Pritikin, et al.             Standards Track                   [Page 49]
+
+RFC 7030                           EST                      October 2013
+
+
+A.4.  Server Key Generation
+
+   The following is an example of a valid /serverkeygen exchange.
+   During this exchange, the EST client authenticates itself using an
+   existing certificate issued by the CA the EST server provides
+   services for.
+
+   The initial TLS handshake is identical to the enrollment example
+   handshake.  An example HTTP POSTed message is:
+
+   POST /.well-known/est/serverkeygen HTTP/1.1
+   Host: 192.0.2.1:8085
+   Accept: */*
+   Expect: 100-continue
+   Content-Type: application/pkcs10
+   Content-Transfer-Encoding: base64
+   Content-Length: 963
+
+   MIICwTCCAakCAQAwWzE+MDwGA1UEAxM1c2VydmVyS2V5R2VuIHJlcSBieSBjbGll
+   bnQgaW4gZGVtbyBzdGVwIDEyIDEzNjgxNDE5NTUxGTAXBgNVBAUTEFBJRDpXaWRn
+   ZXQgU046MTAwggEiMA0GCSqGSIb3DQEBAQUAA4IBDwAwggEKAoIBAQCvE1/6m4A/
+   3/L32Suyzbf28LM9y8CQfp0aepa7o20BSfluvm8HXR44mlV+wpieM8H5n3Ub3RIo
+   RUun/FllIzK9uV7UrkqJ3Yzmq2NOoTd4C+OPsV/RPTu873dhFrssDk3P4NIphlSS
+   sSIkt5rhz7wYbCqCFR5Aphe/30Jx7D+xBI5Rs8e6vRS8IpuImh71BHiLfhq9AFhz
+   4ZJsOUSVpUmqUogFsM7SOQ6XI4dl+djhpjT+YTJ6hQ2PXrqdch3KsTQ8c6aKs+e2
+   5QJxh7O8JHVlPHo4YIxXtAYSutcbbTN5TXWFCWSrWDJ+zuMmk2yU+dio1oW7YR7V
+   ftAvazJ3laQbAgMBAAGgITAfBgkqhkiG9w0BCQcxEhMQZEZzQVhtSm5qb2tCdER2
+   cjANBgkqhkiG9w0BAQUFAAOCAQEAR+I0EQB+hSjrLCAjnVH6bZdHUNGszIdwx1iu
+   L4n+0XK3SfEzeOMkC4T74yFGKj3redS1Ht9atYUPb0D1Qi9Jf9Co8eLblo1l19A6
+   GaS798ofxIF0Pl0Dr6/GqjheqJEIbcDTAJq+kvDihyQ4GQnhosygIZHvKppQlebA
+   gvp2RJSnMroPCe6RgTU9E2fmI9rin/9PyXeWFF1namp+lYbTGwjv1aE1ikhjCLlH
+   veHhCdgOExPw+fqhKhHjp+0ZKBlo2bC3pqRWvDTiZuwt9UpFFfGtuxvpTp44oS/j
+   M/965hWIw/5dshY/wQjIfYs07bbq2ERbpJiw9bAQY34gyoVmEQ==
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Pritikin, et al.             Standards Track                   [Page 50]
+
+RFC 7030                           EST                      October 2013
+
+
+   Because the DecryptKeyIdentifier attribute is not included in this
+   request, the response does not include additional encryption beyond
+   the TLS session.  The EST server response is:
+
+   HTTP/1.1 200 OK
+   Status: 200 OK
+   Content-Type: multipart/mixed ; boundary=estServerExampleBoundary
+   Content-Length: 3219
+
+   This is the preamble.  It is to be ignored, though it
+   is a handy place for estServer to include an explanatory note,
+   including contact or support information.
+   --estServerExampleBoundary
+   Content-Type: application/pkcs8
+   Content-Transfer-Encoding: base64
+
+   MIIEvgIBADANBgkqhkiG9w0BAQEFAASCBKgwggSkAgEAAoIBAQDPwKtwJ7TjMgA+
+   Poj64V909ryql0foP1hU4Yq5y8/bOP5ZTe6ArgVhUye099Ac+dfdwpyP/DESiujU
+   F/dS62Vck3UWNbnw+4O38FUp0enLbbjSTud48KpEW6+FzkeuAanPGZMA1wKyrYy9
+   rD5tQOOJU/CBVhUrITyYLZNYUe4agbpcR0wMtrRr2E58Mu8wQ80ryk6nkL7COk5Z
+   IQdNRxldk7DFvpA85Yn1stumoGRtVLW51iXeTS1LtXwhuUb/j6Lds3vvAiJ2SiZ0
+   Y3rxPlnJVyFmR8Mf2TBOjzuFqva/VLD2ayQjgaGEjq2ZWHXelQAOZ6N3lrChojEK
+   FGq93yOhAgMBAAECggEBALQ5az/nYjd5x9Y3f7NMUffwl+jRRfMHCMTRx/u4AEAo
+   KBYm0hFVZZtxfM+z7xlD8G0Th6gs2hFA6gwcIlUPmiX+UaOLxht0xWaLGgYmcNAm
+   BiCDjLBQ7xRQCWtlcK9WCA5+HBWtcEy6244rXxh+IyWd6NT6bXC165AEcX87y/e3
+   JFJ7XFNeDP656s2DmxSCci+iDte6SaEm7sJvYGu16qevJeMThcQcC9/rJjXkvpGL
+   IKK2px5idad4Pb6+QHpqj3d4oM8djO6wYUvrH8XQLqAaF8Hd5lFWVU57nSYY+H79
+   GaNDTfRTUL6AXr7kmMsKVFOJ0JjZExUCVMZtGiqhB6UCgYEA639OtdWLZCzyZFMe
+   p7VlRddoz0VAtrU2dxnEb4cWD8Gerg8uNvp8OG84gH+6MbPwz4ZYWKCgDFqyrAlw
+   SF02n9Sovh93eoJ5latSbfeYUkLtB8L/HVk5/CBGEsV9MUkdMF0+B43YlhyEDyKW
+   fX2+0UeHLFgRrfpSzP2cXduEieMCgYEA4db/SIrwN2+g1Gjo3oE09kd89VGjVRer
+   srbcqc7DcPXP6Lw42sx96h4jVWWqHVo3DfwFBdUb1LH2cnVXQjgDUHdNdpl01cf/
+   BFYCFINi2qKMqiJYswkhYxZ1BLz/zuQTDbPFL2PgLniKFG2aFLrTS3S/tgeB5QwI
+   RPigH3kfI6sCgYAPqsCJyFMlrvfRRNZdQewi4VnPsEPF4/hjpAs1gD8vfSoZWlkw
+   vylUd9HCerzgYaA7rixieQ0sxTvtxhL6PXlM2NEBFQbV16hPFL6/IiG4F0u9oHNo
+   eG8rHtqKlSjnBn4yoYFm70Dhe7QtbZelcaAoPCH6CUHj2St5B8ZHWDtREQKBgHNp
+   wER+XIy4C2UByCANv9csaXulIOdXlXNbaCGPfOm5dWrm5ddLMf33MO9vaSRe+ku3
+   Q4nbgsGLwPp1ZQZ+QZNZpMi7W6306yp4GdAJ5Pb+oww/ST0VqW5OB7dILyK4A9S4
+   zkiNrf+Rsl8GM/vsDhc9rsuDwqofIAq/VHVBHNzJAoGBAOHQof5L6iGHOHcxLazx
+   4MGvRTpmzU/PX6Q3QxqpetEGFEDZAaL58L67SSS3fFBnKrVAidF6llC1bAH1aoRa
+   fYHUDi45xBoroy0hBwrnTKRxppua4UK75FUH5PPJfR6cCvw5stRkzIevTZHhozkX
+   pM7PYH/x4BiBmgQ3bhOqTp4H
+   --estServerExampleBoundary
+   Content-Type: application/pkcs7-mime; smime-type=certs-only
+   Content-Transfer-Encoding: base64
+
+
+
+
+
+
+Pritikin, et al.             Standards Track                   [Page 51]
+
+RFC 7030                           EST                      October 2013
+
+
+   MIIDRQYJKoZIhvcNAQcCoIIDNjCCAzICAQExADALBgkqhkiG9w0BBwGgggMYMIID
+   FDCCAfygAwIBAgIBFjANBgkqhkiG9w0BAQUFADAbMRkwFwYDVQQDExBlc3RFeGFt
+   cGxlQ0EgTndOMB4XDTEzMDUwOTIzMjU1NloXDTE0MDUwOTIzMjU1NlowLDEqMCgG
+   A1UEAxMhc2VydmVyc2lkZSBrZXkgZ2VuZXJhdGVkIHJlc3BvbnNlMIIBIjANBgkq
+   hkiG9w0BAQEFAAOCAQ8AMIIBCgKCAQEAz8CrcCe04zIAPj6I+uFfdPa8qpdH6D9Y
+   VOGKucvP2zj+WU3ugK4FYVMntPfQHPnX3cKcj/wxEoro1Bf3UutlXJN1FjW58PuD
+   t/BVKdHpy2240k7nePCqRFuvhc5HrgGpzxmTANcCsq2Mvaw+bUDjiVPwgVYVKyE8
+   mC2TWFHuGoG6XEdMDLa0a9hOfDLvMEPNK8pOp5C+wjpOWSEHTUcZXZOwxb6QPOWJ
+   9bLbpqBkbVS1udYl3k0tS7V8IblG/4+i3bN77wIidkomdGN68T5ZyVchZkfDH9kw
+   To87har2v1Sw9mskI4GhhI6tmVh13pUADmejd5awoaIxChRqvd8joQIDAQABo1Iw
+   UDAOBgNVHQ8BAf8EBAMCBLAwHQYDVR0OBBYEFKeZixu9F+appDX2SS5HaxmV6Jr4
+   MB8GA1UdIwQYMBaAFLHEaeZbowSn2Jejizu/uWqyMkI8MA0GCSqGSIb3DQEBBQUA
+   A4IBAQBHhLmRAKrnTapqqBObDM9IQDQPuwW+fW1gYwZKlSm/IWIwHEZL1igXhpjj
+   rf4xqpIkiJMmkaOeoXA8PFniX0/lZM9FQSM/j89CUf5dMoAqWj8s17xuXu9L/hVe
+   XjjXHsL40WuDG6tMPN9vcT8tE3ruor608MKSHFX/NEM6+AaNVSUPTmB33BgYB1Wa
+   E7pn3JMN6pjIxsHnF4pKi8qvoTSVVjaCEwUe8Q/fw1yvjoHoYJtyMn4v5Kb3Rt+m
+   s8Yie1tcfVQrjQutqr34/IJsKdPziZwi92KZa+1958A6M9O/p5OI0up9ZXKg2DEC
+   1O9qT0GyYJ6sxAyKiGTOxk6jMddDoQAxAA==
+   --estServerExampleBoundary--
+   This is the epilogue.  It is also to be ignored.
+
+Appendix B.  Contributors and Acknowledgements
+
+   The editors would like to thank Stephen Kent, Vinod Arjun, Jan
+   Vilhuber, Sean Turner, Russ Housley, and others for their feedback
+   and prototypes of early versions of this document.  Our thanks also
+   go the authors of [RFC6403], around whose document we structured part
+   of this specification.
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Pritikin, et al.             Standards Track                   [Page 52]
+
+RFC 7030                           EST                      October 2013
+
+
+Authors' Addresses
+
+   Max Pritikin (editor)
+   Cisco Systems, Inc.
+   510 McCarthy Drive
+   Milpitas, CA  95035
+   USA
+
+   EMail: pritikin@cisco.com
+
+
+   Peter E. Yee (editor)
+   AKAYLA, Inc.
+   7150 Moorland Drive
+   Clarksville, MD  21029
+   USA
+
+   EMail: peter@akayla.com
+
+
+   Dan Harkins (editor)
+   Aruba Networks
+   1322 Crossman Avenue
+   Sunnyvale, CA  94089-1113
+   USA
+
+   EMail: dharkins@arubanetworks.com
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Pritikin, et al.             Standards Track                   [Page 53]
+