Skip to main content

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

The information below is for an old version of the document.
Document Type
This is an older version of an Internet-Draft that was ultimately published as RFC 7030.
Authors Max Pritikin , Peter E. Yee
Last updated 2012-03-12
Replaces draft-pritikin-est
RFC stream Internet Engineering Task Force (IETF)
Formats
Reviews
Additional resources Mailing list discussion
Stream WG state WG Document
Document shepherd (None)
IESG IESG state Became RFC 7030 (Proposed Standard)
Consensus boilerplate Unknown
Telechat date (None)
Responsible AD (None)
Send notices to (None)
draft-ietf-pkix-est-01
PKIX                                                    M. Pritikin, Ed.
Internet-Draft                                       Cisco Systems, Inc.
Intended status: Standards Track                             P. Yee, Ed.
Expires: September 13, 2012                                 AKAYLA, Inc.
                                                          March 12, 2012

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

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 simple Public Key Infrastructure clients that need
   to acquire client certificate(s) and associated Certification
   Authority (CA) certificate(s).

Status of this Memo

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

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

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

   This Internet-Draft will expire on September 13, 2012.

Copyright Notice

   Copyright (c) 2012 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

Pritikin & Yee         Expires September 13, 2012               [Page 1]
Internet-Draft                     EST                        March 2012

   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.

Pritikin & Yee         Expires September 13, 2012               [Page 2]
Internet-Draft                     EST                        March 2012

Table of Contents

   1.  Introduction . . . . . . . . . . . . . . . . . . . . . . . . .  4
     1.1.  Requirements Language  . . . . . . . . . . . . . . . . . .  5
   2.  Requirements . . . . . . . . . . . . . . . . . . . . . . . . .  5
   3.  Operational Scenario Overviews . . . . . . . . . . . . . . . .  7
   4.  Protocol Design and Layering . . . . . . . . . . . . . . . . .  9
     4.1.  Application Layer Design . . . . . . . . . . . . . . . . .  9
     4.2.  HTTP Layer Design  . . . . . . . . . . . . . . . . . . . . 10
       4.2.1.  HTTP headers for control . . . . . . . . . . . . . . . 10
       4.2.2.  HTTP URIs for control  . . . . . . . . . . . . . . . . 10
       4.2.3.  HTTP-Based Client Authentication . . . . . . . . . . . 12
       4.2.4.  Message types  . . . . . . . . . . . . . . . . . . . . 13
     4.3.  TLS Layer Design . . . . . . . . . . . . . . . . . . . . . 14
       4.3.1.  TLS for transport security . . . . . . . . . . . . . . 14
         4.3.1.1.  TLS-Based Server Authentication  . . . . . . . . . 14
         4.3.1.2.  TLS-Based Client Authentication  . . . . . . . . . 16
     4.4.  Proof-of-Possession  . . . . . . . . . . . . . . . . . . . 16
     4.5.  Linking Identity and POP information . . . . . . . . . . . 16
   5.  Protocol Exchange Details  . . . . . . . . . . . . . . . . . . 17
     5.1.  Client Authorization . . . . . . . . . . . . . . . . . . . 18
     5.2.  Server Authorization . . . . . . . . . . . . . . . . . . . 18
     5.3.  Distribution of CA certificates  . . . . . . . . . . . . . 19
       5.3.1.  Distribution of CA certificates response . . . . . . . 19
     5.4.  Simple Enrollment of Clients . . . . . . . . . . . . . . . 20
       5.4.1.  Simple Re-Enrollment of Clients  . . . . . . . . . . . 20
       5.4.2.  Simple Enroll and Re-Enroll Response . . . . . . . . . 21
     5.5.  Full CMC . . . . . . . . . . . . . . . . . . . . . . . . . 22
       5.5.1.  Full CMC Request . . . . . . . . . . . . . . . . . . . 22
       5.5.2.  Full CMC Response  . . . . . . . . . . . . . . . . . . 22
     5.6.  Server-side Key Generation . . . . . . . . . . . . . . . . 22
       5.6.1.  Server-side Key Generation Request . . . . . . . . . . 23
       5.6.2.  Server-side Key Generation Response  . . . . . . . . . 23
   6.  Cryptographic Algorithms . . . . . . . . . . . . . . . . . . . 24
   7.  Contributors/Acknowledgements  . . . . . . . . . . . . . . . . 24
   8.  IANA Considerations  . . . . . . . . . . . . . . . . . . . . . 24
   9.  Security Considerations  . . . . . . . . . . . . . . . . . . . 25
   10. References . . . . . . . . . . . . . . . . . . . . . . . . . . 26
     10.1. Normative References . . . . . . . . . . . . . . . . . . . 26
     10.2. Informative References . . . . . . . . . . . . . . . . . . 28
   Appendix A.  Server Discovery  . . . . . . . . . . . . . . . . . . 28
   Appendix B.  External TLS concentrator . . . . . . . . . . . . . . 28
   Appendix C.  CGI Server implementation . . . . . . . . . . . . . . 29
   Appendix D.  Updating SCEP implementations . . . . . . . . . . . . 29
   Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 31

Pritikin & Yee         Expires September 13, 2012               [Page 3]
Internet-Draft                     EST                        March 2012

1.  Introduction

   This document specifies a protocol for certificate Enrollment over
   Secure Transport (EST).  EST is designed to be easily implemented by
   clients and servers using common "off the shelf" PKI, HTTP, and TLS
   components.  An EST server providing certificate management functions
   is operated by (or on behalf of) a CA or RA.  The goal is to provide
   a small set of functions for certificate enrollment that are simpler
   to implement and use than full CMP or CMC.  While less functional
   than those protocols, EST satisfies basic needs by providing an
   easily implemented means for both devices as well as user-operated
   computers to request certificates.

   The TLS [RFC4346] protocol combines with a limited set of features of
   the Certificate Management over CMS (CMC) [RFC5272] to provide the
   security for EST.  In the most basic cases, CMC "simple" messages are
   used for certificate requests and responses, but EST also allows the
   optional use of "full" CMC messages as needed.  EST adopts the CMP
   model for CA certificate distribution, but does not incorporate its
   syntax or protocol.  An EST server supports several means of
   authenticating a certificate requester, leveraging the layering of
   the protocols that make up EST.

   EST works by transporting CMC messages securely.  These message can
   be "simple" CMC messages but optionally, "full" CMC messages may also
   be used.  The messages are sent over an HTTPS transport in which HTTP
   headers and content types are used in conjunction with TLS security.
   TCP/IP sits under HTTPS; this document does not specify EST over DTLS
   or UDP.  Figure 1 shows how the layers build upon each other.

Pritikin & Yee         Expires September 13, 2012               [Page 4]
Internet-Draft                     EST                        March 2012

   EST Layering:

   Protocols:
   +---------------------------------------------------+
   |                                                   |
   | 4) EST messages for requests/responses            |
   |                                                   |
   +---------------------------------------------------+
   |                                                   |
   | 3) HTTP for message carriage and signaling        |
   |                                                   |
   +---------------------------------------------------+
   |                                                   |
   | 2) TLS for transport security                     |
   |                                                   |
   +---------------------------------------------------+
   |                                                   |
   | 1) TCP/IP                                         |
   |                                                   |
   +---------------------------------------------------+

                                 Figure 1

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

1.1.  Requirements Language

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

2.  Requirements

   [[EDNOTE: The following section is still included here for
   succinctness.  It will eventually be published independently as
   draft-ietf-pkix-estr-00.]]

   The following describes goals and technical requirements for initial
   PKI certificate enrollment along with a rationale for each
   requirement.

Pritikin & Yee         Expires September 13, 2012               [Page 5]
Internet-Draft                     EST                        March 2012

   G1 "Completeness".  Server and client implementations compliant with
      this document MUST be able to interoperate without reference to
      subsequent profiles or additional future specifications.

   The goal of this enrollment protocol is to provide a simple and easy-
   to-implement method for end-entities to request, obtain, and update a
   certificate issued from a specified Certification Authority.  The
   following certificate management operations are required.  Additional
   operations NEED NOT be supported (via this protocol) although the
   protocol design SHOULD be extensible:

   M1 "Distribution of current CA certificates".  Clients MUST be able
      to obtain the current certificate for the CA under which the
      client's certificate was issued.  Certificates have a finite
      lifetime and will need to be updated on a periodic basis.  It must
      be possible for the client to obtain the updated CA certificates.

   M2 "Enrollment".  A client MUST be able to use the protocol to submit
      a certificate request and obtain a certificate.

   M3 "Renew/Rekey".  Certificates have a finite lifetime and will need
      to be updated on a periodic basis.  A client MUST be able to use
      the protocol for certificate renewal or rekey operations.

   M4 "Server-side Key Generation".  In some infrastructures it may not
      be appropriate for the client to generate its own keys.  A client
      MUST be able to use this protocol but allow the server to make all
      key generation and distribution decisions.

   End-Entity proof-of-identity authentication mechanisms:

   A1 "Username/Password".  It MUST be possible to identify a username
      specified client as being in possession of an associated symmetric
      key.  This allows users currently in possession of a username and
      password to obtain a certificate.

   A2 "Password".  It MUST be possible to identify a client without
      reference to a "username".  A common operational model is to
      distribute a "one-time password" that is presented to a CA or RA
      to authorize enrollment.

   A3 "Existing Certificate".  It MUST be possible to authenticate a
      client by making use of an existing certificate associated with
      the client.  A certificate used for client identification need not
      be issued under the same PKI as the certificate that is being
      requested.  This allows clients that are already in a PKI to use a
      certificate from that PKI to obtain additional certificates.
      Additionally this capability allows a client who has a certificate

Pritikin & Yee         Expires September 13, 2012               [Page 6]
Internet-Draft                     EST                        March 2012

      issued by a 3rd party, such as a certificate issued by a device
      manufacturer, to leverage that credential during initial
      enrollment.

   A4 "Username/password and Certificate".  It MUST be possible to
      authenticate a client by using a combination of a username and
      password and an existing certificate.  This is a combination of A1
      and A3.  This supports "two-factor authentication" where the
      client proves possession of the private keys for an existing
      certificate stored within a hardware device and knowledge of a
      username/password.

   A5 "Password and certificate".  It MUST be possible to authenticate a
      client by using a combination of a secret value that is not
      associated with a "username" and an existing certificate.  This is
      a combination of A2 and A3.  This requirement is similar to A4
      except that the client is in possession of a "one-time password".

   End-Entity proof-of-possession:

   P1 Proof-of-possession of subject keys MUST be supported.  As
      discussed in Appendix C of [RFC4211], Proof-of-possession "means
      that the CA is adequately convinced that the entity requesting a
      certificate for the public key Y, has access to the corresponding
      private key X".

   Key algorithms:

   K1 "Algorithm agility".  The protocol MUST support algorithm agility.
      It must be possible to employ different cryptographic algorithms
      for securing the transport or for signing the certificates.  The
      protocol SHOULD demonstrate this agility by being shown to work
      with existing RSA-based solutions as well as providing for other
      algorithms such as Elliptic Curve cryptography.

   Server Identity mechanism:

   I1 "RA certificate".  It MUST be possible for a client to verify
      authorization of the EST server as a representative of the CA.
      The protocol operations allow the client to send a username/
      password or (one-time) password to the EST server.  These values
      cannot be safely transmitted to an unauthorized server.

3.  Operational Scenario Overviews

   EST provides the following services: 1) acquisition of CA
   certificates, 2) certificate enrollment, 3) certificate renewal, and

Pritikin & Yee         Expires September 13, 2012               [Page 7]
Internet-Draft                     EST                        March 2012

   4) transport of "full" CMC messages.

   1) Acquisition of CA certificates:

      The client retrieves the current CA certificates from the EST
      server.  The client uses HTTPS to ensure the identity of the EST
      server.  If the client successfully authenticates the server the
      certificates are accepted directly, otherwise a manual
      authentication operation is permitted.

   2) Certificate Enrollment

      The client sends a certification request via HTTPS (HTTP over TLS)
      to the EST server.  The client uses TLS to ensure the identity of
      the EST server, and the server uses TLS client authentication to
      verify the identity of the client.  TLS-protected HTTP client
      authentication may also be employed by the EST server if TLS
      authentication does not suffice to verify the identity of the
      client.  The certification request includes proof-of-possession
      (of the client's private key), and a mechanism is defined that
      allows the server to link the EST client's TLS identity to this
      specific certification request.  The server responds with the
      newly issued certificate.

   3) Certificate Renewal (re-enrollment)

      This is highly similar to the initial enrollment.  Because it is
      explicitly a re-enrollment attempt the server verifies the client
      identity using TLS client certificate authentication.  Only
      certificates that are suitable for TLS client authentication can
      be re-enrolled using this operation because of the reliance on the
      TLS authentication.  For other types of certificates, use of the
      full CMC operation is required.

   4) Full CMC messages

      Full CMC messages can be transported allowing access to
      functionality not provided by the simple CMC message.  When using
      full CMC messages the HTTPS connection does not need to be
      authenticated.  "Full" CMC messages are as defined in Sections 3.2
      and 4.2 of [RFC5272].  Support for full CMC message transport is
      optional.

Pritikin & Yee         Expires September 13, 2012               [Page 8]
Internet-Draft                     EST                        March 2012

4.  Protocol Design and Layering

   The following provides an expansion of Figure 1 describing how the
   layers are used.  Each aspect is profiled in detail in the sections
   below.

   EST Layering:

   Protocols and uses:
   +---------------------------------------------------+
   |                                                   |
   | 4) Message types:                                 |
   |    - CMC "Simple PKI" messages                    |
   |      (including proof-of-possession)              |
   |    - CA certificates retrieval                    |
   |    - "Full" CMC messages (optional)               |
   |                                                   |
   +---------------------------------------------------+
   |                                                   |
   | 3) HTTP:                                          |
   |    - HTTP headers and URIs for control            |
   |       - Content-Type headers specify message type |
   |       - Headers for control/error messages        |
   |       - URIs for selecting operations             |
   |    - Basic authentication in some cases           |
   |                                                   |
   +---------------------------------------------------+
   |                                                   |
   | 2) TLS for transport security                     |
   |    - Authentication for EST server and optionally |
   |      EST client                                   |
   |    - Indirectly provides proof-of-identity for EST|
   |    - Communications integrity                     |
   |    - "Channel binding" to link proof-of-identity  |
   |      with message based proof-of-possession.      |
   |      (optional)                                   |
   |                                                   |
   +---------------------------------------------------+

                                 Figure 2

4.1.  Application Layer Design

   An EST client application SHOULD have its own client certificate and
   a copy of a CA certificate.  The client certificate is used to
   provide client authentication for EST and MAY be used in other
   certificate consuming protocols as well.  The client's copy of the CA
   certificate is used to authenticate the EST server.

Pritikin & Yee         Expires September 13, 2012               [Page 9]
Internet-Draft                     EST                        March 2012

   An EST client application MUST be capable of generating and parsing
   simple CMC messages (see Section 5.4).  Generating and parsing full
   CMC messages is optional (see Section 5.5).  The application MUST
   also be able to request CA certificates from the EST server and parse
   the returned "bag" of certificates (see Section 5.3).

4.2.  HTTP Layer Design

   HTTP is used to transport EST requests and responses.  Specific URIs
   are provisioned for handling each type of request as given in
   Section 4.2.1.  HTTP is also used for client authentication services
   when TLS client authentication is not available, as detailed in
   Section Section 4.2.3.  HTTP message types are used to convey EST
   requests and responses as specified in Figure 4.

4.2.1.  HTTP headers for control

   This document profiles the HTTP content-type header to indicate the
   message type and to provide the protocol control messages.  Support
   for the HTTP username/password methods is profiled.

   CMC does not provide explicit messages for renewal and rekey.  This
   profile clarifies the renewal and rekey behavior of both the client
   and server.  It does so by specifying the HTTP control mechanisms
   required of the client and server without requiring a distinct
   message type.

   Various media types as indicated in the HTTP content-type header are
   used to transport EST messages.  Valid media times are specified in
   Section 4.2.4.

4.2.2.  HTTP URIs for control

   This profile supports four operations indicated by specific URIs:

Pritikin & Yee         Expires September 13, 2012              [Page 10]
Internet-Draft                     EST                        March 2012

   Operations and their corresponding URIs:
   +------------------------+-----------------+
   | Operation              |Operation Path   |
   +========================+=================+===================+
   | Distribution of CA     | /CACerts        | Section 5.3       |
   | certificates           |                 |                   |
   +------------------------+-----------------+-------------------+
   | Enrollment of new      | /simpleEnroll   | Section 5.4       |
   | clients                |                 |                   |
   +------------------------+-----------------+-------------------+
   | Re-Enrollment of       | /simpleReEnroll | Section 5.4.1     |
   | existing clients       |                 |                   |
   +------------------------+-----------------+-------------------+
   | Full CMC               | /fullCMC        | Section 5.5       |
   +------------------------+-----------------+-------------------+
   | Server-side Key        | /serverKeyGen   | Section 5.6       |
   | Generation             |                 |                   |
   +------------------------+-----------------+-------------------+

                                 Figure 3

   In the common manner of HTTP based interactions each operation is
   accessed by forming the URI as follows:

   "GET" BASEPATH OPERATIONPATH
   "POST" BASEPATH OPERATIONPATH

   where:

   o  BASEPATH is a common path for all EST operations

   o  OPERATIONPATH specifies the specific operation.

   When a URI is formed, the BASEPATH and OPERATIONPATH are combined to
   form the abs_path [RFC2616].  The means by which clients acquire the
   BASEPATH URI are outside the scope of this document.  The following
   are two example base URIs:

   o  With BASEPATH having the value of /arbitrary/base/path

   o  https://example.org/arbitrary/base/path

   o  https://example2.org:8080/arbitrary/base/path

   The following examples are valid complete URIs under this
   specification:

Pritikin & Yee         Expires September 13, 2012              [Page 11]
Internet-Draft                     EST                        March 2012

   o  With BASEPATH having the value /base/path

   o  https://example.org/base/path/CACerts

   o  https://example2.org:8080/base/path/simpleEnroll

   o  https://example3.org/base/path/fullCMC

   The mechanisms by which the EST server interacts with an HTTPS server
   to handle GET and POST operations at these URIs is outside the scope
   of this document.  The use of distinct URIs simplifies implementation
   for servers that do not perform client authentication when
   distributing "CACerts" responses.

   An EST server MAY provide additional, non-EST services on other URIs.

   [[EDNOTE: This does not use the mechanism specified in "Defining
   Well-Known Uniform Resource Identifiers (URIs)" [RFC5785].  That
   would be a possibility here for a base URL of
   "https://example.org/.well-known/EST" but such would preclude the
   flexibility associated with multiple base URLs being handled by the
   same server unless some form of "?designator=value" is included.]]

4.2.3.  HTTP-Based Client Authentication

   While TLS client authentication is the preferred method for
   authentication of EST requests, there are times when TLS client
   authentication is not possible.  In those cases, an EST server MAY
   fall back to using HTTP-based client authentication, as specified
   below.

   Basic and Digest authentication MUST only be performed over TLS
   [RFC4346].  As specified in CMC: Transport Protocols [RFC5273] the
   server "MUST NOT assume client support for any type of HTTP
   authentication such as cookies, Basic authentication, or Digest
   authentication".  Clients intended for deployments where password
   authentication is advantageous SHOULD support the Basic and Digest
   authentication mechanism.  Servers MAY provide configuration
   mechanisms for administrators to enable Basic [RFC2616] and Digest
   [RFC2617] authentication methods.

   Servers that support Basic and Digest authentication methods MAY
   reject requests using the HTTP defined WWW-Authenticate response-
   header (Section 14.47).  At that point the client SHOULD repeat the
   request, including the appropriate HTTP [RFC2617] Authorization
   Request Header (Section 3.2.2).

   Support for Basic authentication as specified in HTTP allows the

Pritikin & Yee         Expires September 13, 2012              [Page 12]
Internet-Draft                     EST                        March 2012

   server access to the client's cleartext password.  This provides
   integration with legacy username/password databases but requires
   exposing the plaintext password to the EST server.  The client MUST
   NOT respond to this request unless the client has authenticated the
   EST server (as per Section 5.2).

   Clients MAY set the username to the empty string ("") if they wish to
   present a "one-time password" or "PIN" that is not associated with a
   username.

4.2.4.  Message types

   This document uses existing media types for the messages as specified
   by Internet X.509 Public Key Infrastructure Operational Protocols:
   FTP and HTTP [RFC2585] and The application/pkcs10 Media Type
   [RFC5967] and CMC [RFC5272].  To support distribution of multiple
   application/pkix-cert's for the CA certificate chain the [RFC2046]
   multipart/mixed media type is used.

   The message type is specified in the HTTP Content-Type header.

   For reference the messages and their corresponding MIME and media
   types are:

   +-------------------+--------------------------+-------------------+
   | Message type      |Request type              | Request section   |
   |                   |Response type             | Response section  |
   +===================+==========================+===================+
   | CA certificate    | N/A                      | Section 5.3       |
   | request           | multipart/mixed          | Section 5.3.1     |
   |                   | (application/pkix-cert's)|                   |
   +-------------------+--------------------------+-------------------+
   | Cert enroll/renew | application/pkcs10       | Section 5.4/5.4.1 |
   |                   | application/pkix-cert    | Section 5.4.2     |
   +-------------------+--------------------------+-------------------+
   | Full CMC          | application/pkcs7-mime   | Section 5.5.1     |
   |                   | application/pkcs7-mime   | Section 5.5.2     |
   +-------------------+--------------------------+-------------------+
   | Server-side Key   | application/pkcs10       | Section 5.6.1     |
   | Generation        | multipart/mixed          | Section 5.6.2     |
   |                   | (application/pkcs7-cert &|                   |
   |                   | application/pkix-privkey)|                   |
   +-------------------+--------------------------+-------------------+

                                 Figure 4

Pritikin & Yee         Expires September 13, 2012              [Page 13]
Internet-Draft                     EST                        March 2012

4.3.  TLS Layer Design

   TLS provides communications security for the layers above it.
   Specifically, the integrity and authentication services it provides
   are leveraged to provide proof-of-identity and to allow authorization
   decisions to be made.

4.3.1.  TLS for transport security

   HTTPS MUST be used.  TLS 'session resumption' SHOULD be supported.

   HTTPS is defined in HTTP Over TLS [RFC2818] and is a definition of
   how HTTP messages are carried over TLS.  HTTPS is a commonly used
   secure transport and can be easily layered on top of extremely simple
   client or server code.  In some environments HTTPS can be utilized
   through an external process.  Specifying HTTPS as the secure
   transport for PKI enrollment messages introduces two potential
   'layers' for communication of authorization and control messages
   during the protocol exchange: TLS and HTTP.

   CMC [RFC5272] section 3.1 notes that "the Simple PKI Request MUST NOT
   be used if a proof-of-identity needs to be included".  This precludes
   use of these messages if inline authentication and/or authorization
   is required, unless a secured transport that provides proof-of-
   identity is also specified.  Many simple clients engaged in
   certificate enrollment operations will have a TLS client
   implementation available for secure transport, so use of TLS is
   specified herein.  This document specifies a method for authorizing
   client enrollment requests using existing certificates.  Such
   existing certificates may have been issued by the Certification
   Authority (CA) (from which the client is requesting a certificate) or
   they may have been issued under a distinct PKI (e.g., an IEEE 802.1AR
   IDevID [IDevID] credential).  Additionally this document specifies
   username/password authentication methods beyond those included in CMC
   [RFC5272].  Authentication and authorization mechanisms required for
   certificate issuance (and renew/rekey) are provided by HTTP and HTTPS
   mechanisms as described in this document.

   Proof-of-possession is a distinct issue from proof-of-identity and is
   addressed in Section 4.4.

   This document also defines transport for the full CMC [RFC5272]
   specification compliant with CMC Transport Protocols [RFC5273].

4.3.1.1.  TLS-Based Server Authentication

   The client MUST validate the TLS server certificate presented during
   the TLS 1.1 [RFC4346] (or above) exchange-defined Server Certificate

Pritikin & Yee         Expires September 13, 2012              [Page 14]
Internet-Draft                     EST                        March 2012

   message or the client MUST independently validate the response
   contents.  Validation is performed as given in [RFC5280] and
   [RFC6125].  The cipher suites are detailed in Section 6.

   There are multiple methods of validation depending on the current
   state of the client:

   1.  If the client has a store of trust anchors, which may be in the
       form of certificates, for validating TLS connections the client
       MAY validate the TLS server certificate using the standard HTTPS
       logic of checking the server's identity as presented in the
       server's Certificate message against the URI provisioned for the
       EST server (see HTTP Over TLS [RFC2818], Section 3.1 "Server
       Identity" and [RFC6125]).  This method makes it possible for
       clients with a store of trust anchors to securely obtain the CA
       certificate by leveraging the HTTPS security model.  The EST
       server URI SHOULD be made available to the client in a secure
       fashion so that the client only obtains EST functions from a
       desired server.

   2.  If the client already has one or more trust anchors associated
       with this EST server, the client MUST validate the EST server
       certificate using these trust anchors.  The EST server URI MAY be
       made available to the client in an insecure fashion.  The EST
       server certificate MUST contain the id-kp-cmcRA [CMC RFC5272bis]
       extended key usage extension.

   3.  If the client does not yet have a trust anchor associated with
       this EST server then the client MAY provisionally accept the TLS
       connection, but the HTTP content data MUST be accepted manually
       as described in Section 5.3.  HTTP authentication requests MUST
       NOT be responded to since the server is unauthenticated (only the
       content data is accepted manually).

   Methods 1 and 2 are essentially validation as given in [RFC5280].
   Method 1 is as described in [RFC6125], Section 6.6.1 "Match Found".
   Method 2 is described in [RFC6125] as "No Match Found, Pinned
   Certificate".  Method 3 is described in [RFC6125], Section 6.6.4 as
   "Fallback" and describes the process of "pinning" the received
   certificate.

   If one of these validation methods succeeds the CA certificate(s) are
   stored and "pinned" for future use.  If none of these validation
   methods succeeds the client MUST reject the EST server response and
   SHOULD log and/or inform the end user.

Pritikin & Yee         Expires September 13, 2012              [Page 15]
Internet-Draft                     EST                        March 2012

4.3.1.2.  TLS-Based Client Authentication

   Clients SHOULD support [RFC4346] defined Certificate request (section
   7.4.4).  As required by [RFC4346], the client certificate needs to
   indicate support for digital signatures.  The client SHOULD support
   this method in order to leverage /simpleReEnroll using client
   authentication by existing certificate.

   The certificate presented by the client MAY be from the same PKI as
   the Server Certificate, from a completely different PKI.  The
   certificate supplied during authentication is used during client
   authorization (Section 5.1).

4.4.  Proof-of-Possession

   As discussed in Appendix C of CRMF [RFC4211], Proof-of-possession
   (POP) "means that the CA is adequately convinced that the entity
   requesting a certificate for the public key Y, has access to the
   corresponding private key X".

   The signed enrollment request provides a "Signature"-based proof-of-
   possession.  The mechanism described in Section 4.5 strengthens this
   by optionally including identity linking information within the data
   covered by the enrollment request signature (thus ensuring that the
   enrollment request was signed after the TLS tunnel was established).

4.5.  Linking Identity and POP information

   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.
   This proves to the server that the authenticated TLS client has
   possession of the private key associated with the certification
   request and that the client was able to sign the certification
   request after the TLS session was established.  This is an
   alternative to the [RFC5272] Section 6.3-defined "Linking Identity
   and POP information" method available if full CMC messages are used.

   The client generating the request SHOULD obtain the tls-unique value
   as defined in Channel Bindings for TLS [RFC5929] from the TLS
   subsystem.  The tls-unique value is encoded as specified in Section 4
   of Base64 [RFC4648] and the resulting string is placed in the
   certification request challenge-password field.

   The tls-unique specification includes a synchronization issue as
   described in Channel Bindings for TLS [RFC5929] section 3.1.  This
   problem is avoided for EST implementations.  The tls-unique value
   used MUST be from the first TLS handshake.  EST client and servers

Pritikin & Yee         Expires September 13, 2012              [Page 16]
Internet-Draft                     EST                        March 2012

   must use their tls-unique implementation specific synchronization
   methods to obtain this first tls-unique value.

   Any TLS renegotiation MUST use "secure_renegotiation" [RFC5746] (thus
   maintaining the binding).  Mandating secure renegotiation secures
   this method of avoiding the synchronization issues encountered when
   using the most recent tls-unique value (which is defined as the the
   value from the most recent TLS handshake).

   The server SHOULD verify the tls-unique information.  This ensures
   that the authenticated TLS client is in possession of the private key
   used to sign the certification request.

   [[EDNOTE: A specific error code (TBD) is returned indicating this
   additional linkage might be useful.  This would be similar to the
   "WWW-Authenticate response-header" control message.  Alternatively
   simply rejecting the request with an informative text message would
   work in many use cases.]]

   The tls-unique value is encoded into the certification request by the
   client but back-end infrastructure elements that process the request
   after the EST server might not have access to the initial TLS
   session.  Such infrastructure elements validate the source of the
   certification request to determine if POP checks have already been
   performed.  For example if the EST client authentication results in
   an authenticated client identity of an RA that is known to
   independently verify the proof-of-possession then the back-end
   infrastructure does not need to perform proof-of-possession checks a
   second time.  If the EST server forwards a request to a back-end
   process it SHOULD communicate the authentication results.  This
   communication might use the CMC "RA POP Witness Control" in a CMC
   Full PKI Request message or other mechanisms which are out-of-scope
   of this document.

5.  Protocol Exchange Details

   Before processing a request, an EST server determines if the client
   is authorized to receive the requested services.  Likewise, the
   client must make a determination if it will accept services from the
   EST server.  Those determinations are described in the next two
   sections.  Assuming that both sides of the exchange are authorized,
   then the actual operations are as described in the sections
   following.

Pritikin & Yee         Expires September 13, 2012              [Page 17]
Internet-Draft                     EST                        March 2012

5.1.  Client Authorization

   When the EST server receives a CMC Simple PKI Request or rekey/renew
   message, the decision to issue a certificates is always a matter of
   local policy.  Thus the CA can use any data it wishes in making that
   determination.  The EST protocol exchange provides the EST server
   access to the TLS client certificate in addition to any HTTP user
   authentication credentials to help in that determination.  The
   communication channel between the TLS server implementation and the
   EST software implementation is out-of-scope of this document.

   If the client authentication is incomplete (for example if the client
   certificate is self-signed or issued by an unknown PKI or if the
   client offered an unknown username/password during HTTP
   authentication) the server MAY extract the certificate request for
   manual authorization by the administrator.

5.2.  Server Authorization

   The client MUST check the EST server authorization before accepting
   the server's response.  The presented certificate MUST be an end-
   entity certificate such as a CMC Registration Authority (RA)
   certificate.

   There are multiple methods for checking authorization corresponding
   to the method of server authentication used (see Section 4.3.1.1):

   1.  If the client authenticated the EST server using the client's TLS
       trust anchors store, then the client MUST have obtained the EST
       server's URI in a secure fashion.  The client MUST check the URI
       "against the server's identity as presented in the server's
       Certificate message" (Section 3.1 "Server Identity" [RFC2818] and
       [RFC6125]).  The securely configured URI provides the
       authorization statement and the server's authenticated identity
       confirms it is the authorized server.

   2.  If the previous check fails or is not applicable, or if the EST
       server's URI was made available to the client in an insecure
       fashion, then the EST server certificate MUST contain the id-kp-
       cmcRA [CMC RFC5272bis] extended key usage extension.  The client
       MUST further verify the server's authorization by checking that
       the [RFC5280]-defined certificate policy extension sequence
       contains the 'RA Authorization' policy OID.  The RA Authorization
       policy OID is defined as: id-cmc [[EDNOTE: TBD, perhaps 35]].
       The RA Authorization policy information MUST NOT contain any
       optional qualifiers.

Pritikin & Yee         Expires September 13, 2012              [Page 18]
Internet-Draft                     EST                        March 2012

   3.  If fallback logic was invoked to accept the certificate manually,
       then that authentication implies authorization of the EST server.

5.3.  Distribution of CA certificates

   Before engaging in enrollment operations, clients MUST request trust
   anchor information (in the form of certificates) by sending an HTTPS
   GET message to the EST base URI with the relative path extension
   '/CACerts'.  Clients SHOULD request an up-to-date response before
   stored information has expired.

   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 4.3.1.  If the authentication and authorization is not
   successful then the client MAY extract the CA certificate and engage
   the end-user to authorize the CA certificate using out-of-band pre-
   configuration data such as a CA certificate "fingerprint" (e.g., a
   SHA-1, SHA-256, SHA-512, or MD5 hash on the whole CA certificate).
   In this case it is incumbent on the end user to properly verify the
   fingerprint or to provide valid out-of-band data necessary to verify
   the fingerprint.

   Subsequent connections to the EST server SHOULD validate the TLS
   server certificate using the stored CA certificates as described in
   Section 4.3.1.

5.3.1.  Distribution of CA certificates response

   The EST server MUST respond to the client HTTPS GET message with CA
   trust anchor information in the form of a certificate.  Additionally
   the server MUST include any "Root CA Key Update" CMP certificates.

   The response format is the media type multipart/mixed.  Within each
   parallel part is an entity of media type application/pkix-cert.  One
   part MUST be the the current self-signed CA certificate.  The EST
   server MUST include any additional certificates the client would need
   to build a chain to the root certificate.  For example if the EST
   server is configured to use a subordinate CA when signing new client
   requests then the appropriate subordinate CA certificates must be
   included in this response.

   Additional parts MAY be included.  The server SHOULD support
   distribution of an updated root certificate, prior to the expiration
   of the current root certificate, so that clients can leverage their
   existing stored credential to obtain the update.  If support for the
   CMP root certificate update mechanism is desired, then there MUST be

Pritikin & Yee         Expires September 13, 2012              [Page 19]
Internet-Draft                     EST                        March 2012

   the three additional CMP-defined Root CA Key Update certificates:
   OldWithOld, OldWithNew, and NewWithOld.

   The client can always find the current self-signed CA certificate by
   examining the certificates received.  The NewWithNew certificate is
   self-signed and has the latest NotAfter date.

   The NewWithNew certificate is the certificate that is extracted and
   authorized using out-of-band information as described in Section 5.3.
   When out-of-band validation occurs each of the other three
   certificates MUST be validated using normal [RFC5280] certificate
   path validation (using the NewWithNew certificate as the trust
   anchor) before they can be used to build certificate paths during
   peer certificate validation.

5.4.  Simple Enrollment of Clients

   At any time the client MAY request a certificate from the EST base
   URI with the OPERATIONPATH "/simpleEnroll'.

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

   The content-type of "application/pkcs10" MUST be specified.  The
   format of the request is as specified in Section 6.4 of [RFC4945].

   The server MUST authenticate the client as specified in
   Section 4.3.1.  The server applies whatever authorization or policy
   logic it chooses in determining if the certificate should be issued.
   The client MAY request an additional certificate even when using an
   existing certificate in the TLS client authentication.

   The client MUST authenticate the EST server as specified in
   Section 4.3.1.1.

5.4.1.  Simple Re-Enrollment of Clients

   At any time a client MAY request renew/rekey of its certificate from
   the EST base URI with the OPERATIONPATH "/simpleReEnroll'.

   The certificate request is the same format as for the "simpleEnroll"
   path extension with the same content-type.

   The EST server MUST handle enrollment requests submitted to the
   "simpleReEnroll" URI as renewal or rekey request.  (This is an
   alternative to the /fullCMC method of depending on the method of
   identifying a renewal or rekey request specified in Section 2 of

Pritikin & Yee         Expires September 13, 2012              [Page 20]
Internet-Draft                     EST                        March 2012

   [RFC5272], that "renewal and rekey requests look the same as any
   certification request, except that the identity proof is supplied by
   existing certificates from a trusted CA".)  The proof of client
   identity is supplied by client authentication during the HTTPS
   handshake.  When attempting to renew or rekey the client SHOULD use
   its existing certificate for TLS client authentication
   (Section 4.3.1.2).

   [[EDNOTE: [RFC6403] defines a method of recognizing a re-enroll based
   on PKCS10 contents, see section 4.1.  The method described herein is
   explicit.]]

5.4.2.  Simple Enroll and Re-Enroll Response

   The server responds to a 'simpleEnroll' or 'simpleReEnroll' request
   with the client's newly issued certificate or it provides an error
   response.

   If the enrollment is successful the server response MUST have an HTTP
   200 response code with a content-type of "application/pkix-cert".
   The response data is the certificate formatted as specified in
   Section 6.1 of [RFC4945].

   When rejecting a request the server MUST specify either an HTTP 4xx/
   401 error, or an HTTP 5xx error.  A CMC Simple PKI Response with an
   HTTP content-type of "application/pkcs7-mime" MAY be included in the
   response data for any error response.  If the content-type is not set
   the response data MUST be a plain text human-readable error message.
   A client MAY elect not to parse a CMC error response in favor of a
   generic error message.

   If the server responds with an HTTP 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 and MAY include informative human-
   readable content.  The client MUST wait at least the specified
   'retry-after' time before repeating the same request.  The client
   repeats the initial enrollment request after the appropriate 'retry-
   after' interval has expired.  The client SHOULD log or inform the end
   user of this event.  The server is responsible for maintaining all
   state necessary to recognize and handle retry operations as the
   client is stateless in this regard (it simply sends the same request
   repeatedly until it receives a different response code).

   All other return codes are handled as specified in HTTP.

Pritikin & Yee         Expires September 13, 2012              [Page 21]
Internet-Draft                     EST                        March 2012

5.5.  Full CMC

   At any time the client MAY request a certificate from the EST base
   URI with the OPERATIONPATH "/fullCMC".

   The client MUST authenticate the server as specified in Server
   Authentication (Section 4.3.1.1).

   The server SHOULD authenticate the client as specified in
   Section 4.3.1.  The server MAY depend on CMC client authentication
   methods instead.

5.5.1.  Full CMC Request

   When HTTPS POSTing to the "fullCMC" location the client MUST include
   a valid CMC message.  The content-type MUST be set to "application/
   pkcs7-mime" as specified in [RFC5273].

5.5.2.  Full CMC Response

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

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

   When rejecting a request the server MAY specify either an HTTP 4xx/
   401 error or an HTTP 5xx error.  A CMC response with content-type of
   "application/pkcs7-mime" MUST be included in the response data for
   any error response.  The client MUST parse the CMC response to
   determine the current status.

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

5.6.  Server-side Key Generation

   [[EDNOTE: This section is provisional as a response to review
   feedback.  It is not fully integrated with the rest of this
   document.]]

   At any time the client MAY request a "private" keypair and associated
   certificate from the EST base URI with the OPERATIONPATH
   "/serverKeyGen".

   The client MUST authenticate the server as specified in

Pritikin & Yee         Expires September 13, 2012              [Page 22]
Internet-Draft                     EST                        March 2012

   Section 4.3.1.1.

   The document [serverkeygen] describes a number of options for how the
   client can authenticate itself and for how server generated key
   material can be sent to the client.  This document does not attempt
   to provide all these options as they are available using the
   "/fullCMC" method.  Instead a direct method for clients to access a
   server provided key and certificate is described.

   The server MUST authenticate the client as specified in
   Section 4.3.1.  The server applies whatever authorization or policy
   logic it chooses to determine if the "private" key and certificate
   should be distributed.  The server SHOULD use TLS-Based Client
   Authentication for authorization purposes.  The server SHOULD respond
   to repeated requests from the same client with the same "private" key
   and certificate.  Clients that wish multiple "private" keys and
   certificates using this method MUST use different client identities.

   Proper random number and key generation and storage is a server
   implementation responsibility.

5.6.1.  Server-side Key Generation Request

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

   The public key values of the certificate request and the request
   signature MUST be ignored by the server.  The server response MUST
   use the same SubjectPublicKeyInfo as requested or the request MUST be
   denied.

5.6.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.  The first part is the "private" key data and the
   second part is the certificate data.

   The first submessage is an "application/pkix-privkey" consisting of
   the PEM-encoded DER-encoded PrivatekeyInfo between the PEM headers as
   described in [RFC5958]:

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

Pritikin & Yee         Expires September 13, 2012              [Page 23]
Internet-Draft                     EST                        March 2012

   The second submessage is an "application/pkix-cert" and exactly
   matches the certificate response to /simpleEnroll.

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

   [[EDNOTE: do we have an existing MIME type we can use for the
   privatekey?]]

6.  Cryptographic Algorithms

   This section details the specific cryptographic algorithms and cipher
   suite requirements.

   The client SHOULD offer the Suite B compliant cipher suites as
   indicated in [RFC5430], Section 4 "Suite B Compliance and
   Interoperability Requirements".  For greatest interoperability the
   client SHOULD also offer TLS_RSA_WITH_AES_128_CBC_SHA.

   When the client accesses the "simpleReEnroll" method the TLS cipher
   suite in use MUST be appropriate for the existing certificate.  The
   certificate type used determines the appropriate signatureAlgorithm
   for the PKCS#10 Certification Request.  For example if a [RFC5430]
   cipher suite is used the signatureAlgorithm MAY be ecdsa-with-sha256
   for P-256 certification requests, or MAY be ecdsa-with-sha384 for
   P-384 certification requests.

   [[EDNOTE: This is in alignment with [RFC6403] section 4.1.  To
   encourage algorithm agility, discussions of the MUST/SHOULD
   algorithms should be in a distinct document.]]

7.  Contributors/Acknowledgements

   The editors would like to thank Stephen Kent, Vinod Arjun, Jan
   Vilhuber, Sean Turner, and others for their feedback and prototypes
   of early drafts.

8.  IANA Considerations

   (This section is incomplete)

   The following aspects should be registered with IANA Considerations:

   The RA Authorization certificate policy extension OID as discussed in

Pritikin & Yee         Expires September 13, 2012              [Page 24]
Internet-Draft                     EST                        March 2012

   Section 5.2 requires registration with IANA.

   [[EDNOTE: The URLs specified in Section 1 probably do not need to be
   registered with IANA.]]

9.  Security Considerations

   (This section is incomplete)

   "Badges?  We ain't got no badges.  We don't need no badges!  I don't
   have to show you any stinkin' badges!" -- The Treasure of the Sierra
   Madre.

   As described in CMC Section 6.7, "For keys that can be used as
   signature keys, signing the certification request with the private
   key serves as a POP on that key pair".  The inclusion of tls-unique
   within the certification request links the the proof-of-possession to
   the TLS proof-of-identity.  For support of keys that can not be used
   for signing the certification request the full CMC specification MUST
   be used.

   As given in Section 4.3.1.2 clients use an existing certificate for
   TLS client authentication.  If a certificate with appropriate key
   usage is not available the client MAY generate one.  If a self-signed
   certificate with appropriate key usage is used the server SHOULD
   require HTTP-based client authentication according to server policy
   as described in Section 4.3.1.2 and Section 5.1.  The server MAY fall
   back on manual authorization by the server administrator.

   Clients authenticate EST servers by means of TLS authentication.  If
   a client does not possess a root certificate suitable for validating
   an EST server certificate, it MAY rely upon other trusted root
   certificates it has (such as those found in its HTTPS store).  The
   client then is able to retrieve additional root certificates as given
   in Section 5.3.  Alternatively, a server certificate MAY be
   authenticated manually as specified in Section 4.3.1.1 #3.

   As noted in Section 4.3.1.1 servers use an existing certificate for
   TLS server authentication.  When the server certificate is issued by
   a mutually trusted PKI hierarchy, validation proceeds as specified in
   Section 5.2.  In this situation the client has validated the server
   as being a valid responder for the URI configured but can not
   directly verify that the responder is authorized as an RA within the
   to-be-enrolled PKI hierarchy.  A client may thus be enticed to expose
   username/password or certificate enrollment requests to an
   unauthorized server (if the server presents a valid HTTPS certificate
   for an erroneous URL that the client has been tricked into using).

Pritikin & Yee         Expires September 13, 2012              [Page 25]
Internet-Draft                     EST                        March 2012

   Proof-of-identity and Proof-of-possession checks by the CA prevent an
   illegitimate RA from leveraging such misconfigured clients to act as
   a man-in-the-middle during client authenticated operations but it is
   possible for such illegitimate RAs to send the client doctored
   messages or erroneous CA certificate lists.  If the illegitimate RA
   has successfully phished a username/password or PIN from the client
   it might try to use these values to enroll its own keypair with the
   real PKI hierarchy.  EST servers identified with an externally issued
   server certificate SHOULD require HTTPS-based client authentication
   (Section 4.3.1.2).  Similarly EST clients SHOULD use an existing
   client certificate to identify themselves and otherwise prevent
   "private data" (obviously including passwords but also including
   private identity information) from being exposed during the
   enrollment exchange a weak server authorization method is used.

   Section 4.2.3 allows clients to optionally authenticate using HTTP-
   based authentication in place of TLS-based authentication.  HTTP-
   based authentication MUST NOT take place unless performed over a TLS-
   protected link.

   The server-side key generation method allows keys to be transported
   over the TLS connection to the client.  The distribution of "private"
   key material is inherently risky and servers are NOT RECOMMENDED to
   support this operation by default.  Clients are NOT RECOMMENDED to
   request this service unless there is a compelling operational benefit
   such as the use of [BGPsec RPKI].

10.  References

10.1.  Normative References

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

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

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

Pritikin & Yee         Expires September 13, 2012              [Page 26]
Internet-Draft                     EST                        March 2012

              Leach, P., Luotonen, A., and L. Stewart, "HTTP
              Authentication: Basic and Digest Access Authentication",
              RFC 2617, June 1999.

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

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

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

   [RFC4945]  Korver, B., "The Internet IP Security PKI Profile of
              IKEv1/ISAKMP, IKEv2, and PKIX", RFC 4945, August 2007.

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

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

   [RFC5430]  Salter, M., Rescorla, E., and R. Housley, "Suite B Profile
              for Transport Layer Security (TLS)", RFC 5430, March 2009.

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

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

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

   [RFC6125]  Saint-Andre, P. and J. Hodges, "Representation and

Pritikin & Yee         Expires September 13, 2012              [Page 27]
Internet-Draft                     EST                        March 2012

              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.

10.2.  Informative References

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

   [RFC4211]  Schaad, J., "Internet X.509 Public Key Infrastructure
              Certificate Request Message Format (CRMF)", RFC 4211,
              September 2005.

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

Appendix A.  Server Discovery

   (informative)

   (This section is incomplete)

   Clients MAY use DNS-SD or similar discovery algorithms to determine
   the EST base URL.  In such cases it is expected that method 2
   (Section 4.3.1.1) be used during server authentication.

Appendix B.  External TLS concentrator

   (informative)

   In some deployments it may be beneficial to use a TLS concentrator to
   offload the TLS processing from the server.  In such a deployment the
   TLS client authentication result must, in some way, be forwarded to
   the server.

   The TLS server SHOULD NOT reject the connection based on PKIX
   validation of the client certificate.  The client certificate SHOULD
   be passed to the EST layer for verification and authorization.  This
   allows support of external TLS concentrators, or an external web
   server, that might provide an independent TLS implementation.

   The TLS concentrator MUST validate the TLS Section 7.4.8 'Certificate
   Verify'.

Pritikin & Yee         Expires September 13, 2012              [Page 28]
Internet-Draft                     EST                        March 2012

   A TLS concentrator MUST insert the client certificate into the HTTP
   header.  The TLS concentrator MUST first remove any existing client
   certificates, possibly inserted by a nefarious client, from the HTTP
   headers before forwarding the HTTP connection to the server.

   [TBD - need to better understand what would happen in the case of
   proxy's or multiple concentrators.  Or specifically state that as out
   of scope.]

   [TBD - the HTTP header field names etc shall be specified here]

   The EST server MUST be specifically configured by the administrator
   to accept this mechanism.

Appendix C.  CGI Server implementation

   (informative)

   In some deployments it may be beneficial to use a HTTPS server that
   runs the EST server as a CGI application.  In such a deployment the
   HTTPS server client authentication result must, in some way, be
   forwarded to the server.

   An HTTPS server MUST insert the client certificate into environment
   variables before calling a server CGI application.

   [TBD - describe the CGI environment variables here.  Can likely
   follow the apache example].

   An HTTP server MUST insert the client certificate into environment
   variables before calling a server CGI application.

   [TBD - describe the CGI environment variables here.  Can likely
   follow the apache example].

Appendix D.  Updating SCEP implementations

   (informative)

   SCEP has been used instead of a full implementation of CMC for the
   same simplicity reasons discussed in Section 1.  Such implementations
   would benefit from being updated to this specification in the
   following ways:

   o  Implementing a subset of CMC provides an enhancement path if the
      full CMC functionality is required.

Pritikin & Yee         Expires September 13, 2012              [Page 29]
Internet-Draft                     EST                        March 2012

   o  The use of HTTPS as a transport is often perceived as more secure.
      Although the SCEP protocol specification includes mechanisms (and
      complexity) to address security issues avoiding a vendor
      requirement to educate systems administrators is beneficial.
      Implementors can benefit from the wide availability of existing
      HTTPS/TLS libraries.

   o  SCEP servers can use their CA certificate to protect SCEP traffic
      in ways that are not appropriate.  (See SCEP draft Section 8.2).
      This specification precludes those misuses.

   o  The SCEP draft Appendix D renew and rekey functionalities imply a
      'flag moment' where the PKI infrastructure transitions from an
      (expired) CA certificate to a new CA certificate.  This
      specification specifies the better mechanism defined in CMP.

   Updating an SCEP client implementation to support this protocol
   involves the following changes to the SCEP implementation.  There is
   no server-side indication that SCEP clients should be so modified so
   this depends on a client-side configuration:

   o  The SCEP client supports HTTPS server authentication and
      authorization as detailed Section 4.3.1.1.

   o  The SCEP client supports HTTPS client authentication as detailed
      in Section 4.3.1.2.

   o  When performing the "Get CA Cert" SCEP transaction the client
      supports the Section 5.3 described CMC Simple PKI Response (ref
      CMC 4.1, which is extremely similar to the SCEP "CA/RA Certificate
      Response Message Format" if not exactly the same).

   o  When performing the certificate enrollment via SCEP PKCSReq the
      outgoing message is simplified to be only the inner PKCS10 (ref
      CMC section 3.2.1.2.1).

   o  When handling the certificate enrollment response the response
      format is simplified to be only the SCEP inner 'messageData'
      containing the actual certificates in the degenerate PKCS7 form.
      (ref CMC 4.1) The only 'authenticatedAttributes' value of
      remaining importance is the 'pkiStatus' and this value is now
      found in the HTTP header as defined in Section 5.4.2.

   o  Polling is simplified with clients repeatedly establishing the
      full HTTPS connection; no polling specific state information is
      encoded into the EST messages.

Pritikin & Yee         Expires September 13, 2012              [Page 30]
Internet-Draft                     EST                        March 2012

   o  GetCert is deprecated.

   o  GetCRL is deprecated.

   These simplifications to an existing SCEP implementation result in an
   SCEP client that is compliant with CMC when using the EST transport.

   Implementation note: The use of tls-unique-securerenegotiation
   precludes the use of SCEP 'challenge-password' within the pkcs10 for
   password/PIN assertion.  Instead these values must be asserted with
   the Section 4.2.3 described mechanism.  A side effect of this is that
   a client communicating with an EST server can not embed an SCEP
   'challenge-password' within the PKCS#10.  An EST service running as
   an RA thus can not forward the PKCS#10 using SCEP to an SCEP server
   that expects the 'challenge-password' to be populated.

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

Pritikin & Yee         Expires September 13, 2012              [Page 31]