One document matched: draft-ietf-pkix-est-01.xml
<?xml version="1.0" encoding="US-ASCII"?>
<!-- This template is for creating an Internet Draft using xml2rfc,
which is available here: http://xml.resource.org. -->
<!DOCTYPE rfc SYSTEM "rfc2629.dtd" [
<!-- One method to get references from the online citation libraries.
There has to be one entity for each item to be referenced.
An alternate method (rfc include) is described in the references. -->
<!ENTITY RFC2046 SYSTEM "http://xml.resource.org/public/rfc/bibxml/reference.RFC.2046.xml">
<!ENTITY RFC2119 SYSTEM "http://xml.resource.org/public/rfc/bibxml/reference.RFC.2119.xml">
<!ENTITY RFC2409 SYSTEM "http://xml.resource.org/public/rfc/bibxml/reference.RFC.2409.xml">
<!ENTITY RFC2585 SYSTEM "http://xml.resource.org/public/rfc/bibxml/reference.RFC.2585.xml">
<!ENTITY RFC2616 SYSTEM "http://xml.resource.org/public/rfc/bibxml/reference.RFC.2616.xml">
<!ENTITY RFC2617 SYSTEM "http://xml.resource.org/public/rfc/bibxml/reference.RFC.2617.xml">
<!ENTITY RFC2818 SYSTEM "http://xml.resource.org/public/rfc/bibxml/reference.RFC.2818.xml">
<!ENTITY RFC2986 SYSTEM "http://xml.resource.org/public/rfc/bibxml/reference.RFC.2986.xml">
<!ENTITY RFC4210 SYSTEM "http://xml.resource.org/public/rfc/bibxml/reference.RFC.4210.xml">
<!ENTITY RFC4211 SYSTEM "http://xml.resource.org/public/rfc/bibxml/reference.RFC.4211.xml">
<!ENTITY RFC4346 SYSTEM "http://xml.resource.org/public/rfc/bibxml/reference.RFC.4346.xml">
<!ENTITY RFC4306 SYSTEM "http://xml.resource.org/public/rfc/bibxml/reference.RFC.4306.xml">
<!ENTITY RFC4648 SYSTEM "http://xml.resource.org/public/rfc/bibxml/reference.RFC.4648.xml">
<!ENTITY RFC4945 SYSTEM "http://xml.resource.org/public/rfc/bibxml/reference.RFC.4945.xml">
<!ENTITY RFC5272 SYSTEM "http://xml.resource.org/public/rfc/bibxml/reference.RFC.5272.xml">
<!ENTITY RFC5273 SYSTEM "http://xml.resource.org/public/rfc/bibxml/reference.RFC.5273.xml">
<!ENTITY RFC5280 SYSTEM "http://xml.resource.org/public/rfc/bibxml/reference.RFC.5280.xml">
<!ENTITY RFC5430 SYSTEM "http://xml.resource.org/public/rfc/bibxml/reference.RFC.5430.xml">
<!ENTITY RFC5746 SYSTEM "http://xml.resource.org/public/rfc/bibxml/reference.RFC.5746.xml">
<!ENTITY RFC5929 SYSTEM "http://xml.resource.org/public/rfc/bibxml/reference.RFC.5929.xml">
<!ENTITY RFC5967 SYSTEM "http://xml.resource.org/public/rfc/bibxml/reference.RFC.5967.xml">
<!ENTITY RFC6125 SYSTEM "http://xml.resource.org/public/rfc/bibxml/reference.RFC.6125.xml">
<!ENTITY RFC6403 SYSTEM "http://xml.resource.org/public/rfc/bibxml/reference.RFC.6403.xml">
]>
<?xml-stylesheet type='text/xsl' href='rfc2629.xslt' ?>
<!-- used by XSLT processors -->
<!-- For a complete list and description of processing instructions (PIs),
please see http://xml.resource.org/authoring/README.html. -->
<!-- Below are generally applicable Processing Instructions (PIs) that most I-Ds might want to use.
(Here they are set differently than their defaults in xml2rfc v1.32) -->
<?rfc strict="yes" ?>
<!-- give errors regarding ID-nits and DTD validation -->
<!-- control the table of contents (ToC) -->
<?rfc toc="yes"?>
<!-- generate a ToC -->
<?rfc tocdepth="4"?>
<!-- the number of levels of subsections in ToC. default: 3 -->
<!-- control references -->
<?rfc symrefs="yes"?>
<!-- use symbolic references tags, i.e, [RFC2119] instead of [1] -->
<?rfc sortrefs="yes" ?>
<!-- sort the reference entries alphabetically -->
<!-- control vertical white space
(using these PIs as follows is recommended by the RFC Editor) -->
<?rfc compact="yes" ?>
<!-- do not start each main section on a new page -->
<?rfc subcompact="no" ?>
<!-- keep one blank line between list items -->
<!-- end of list of popular I-D processing instructions -->
<rfc category="std" docName="draft-ietf-pkix-est-01" ipr="trust200902">
<!-- category values: std, bcp, info, exp, and historic
ipr values: full3667, noModification3667, noDerivatives3667
you can add the attributes updates="NNNN" and obsoletes="NNNN"
they will automatically be output with "(if approved)" -->
<!-- ***** FRONT MATTER ***** -->
<front>
<!-- The abbreviated title is used in the page header - it is only necessary if the
full title is longer than 39 characters -->
<title abbrev="EST">Enrollment over Secure Transport</title>
<!-- add 'role="editor"' below for the editors if appropriate -->
<!-- Another author who claims to be an editor -->
<author fullname="Max Pritikin" initials="M" role="editor"
surname="Pritikin">
<organization>Cisco Systems, Inc.</organization>
<address>
<postal>
<street>510 McCarthy Drive</street>
<!-- Reorder these if your country does things differently -->
<city>Milpitas</city>
<region>CA</region>
<code>95035</code>
<country>USA</country>
</postal>
<email>pritikin@cisco.com</email>
<!-- uri and facsimile elements may also be added -->
</address>
</author>
<author fullname="Peter E. Yee" initials="P" role="editor" surname="Yee">
<organization>AKAYLA, Inc.</organization>
<address>
<postal>
<street>7150 Moorland Drive</street>
<!-- Reorder these if your country does things differently -->
<city>Clarksville</city>
<region>MD</region>
<code>21029</code>
<country>USA</country>
</postal>
<email>peter@akayla.com</email>
<!-- uri and facsimile elements may also be added -->
</address>
</author>
<date day="12" month="March" year="2012" />
<!-- If the month and year are both specified and are the current ones, xml2rfc will fill
in the current day for you. If only the current year is specified, xml2rfc will fill
in the current day and month for you. If the year is not the current one, it is
necessary to specify at least a month (xml2rfc assumes day="1" if not specified for the
purpose of calculating the expiry date). With drafts it is normally sufficient to
specify just the year. -->
<!-- Meta-data Declarations -->
<area>Security</area>
<workgroup>PKIX</workgroup>
<!-- WG name at the upperleft corner of the doc,
IETF is fine for individual submissions.
If this element is not present, the default is "Network Working Group",
which is used by the RFC Editor as a nod to the history of the IETF. -->
<keyword>pki,est</keyword>
<!-- Keywords will be incorporated into HTML output
files in a meta tag but they have no effect on text or nroff
output. If you submit your draft to the RFC Editor, the
keywords will be used for the search engine. -->
<abstract>
<t>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).</t>
</abstract>
</front>
<middle>
<section anchor="introduction" title="Introduction">
<t>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.</t>
<t>The TLS <xref target="RFC4346"></xref> protocol combines with a
limited set of features of the <xref target="RFC5272">Certificate
Management over CMS (CMC)</xref> 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.</t>
<!--
"Simple PKI Request" and "Simple PKI Response"
messages although the server MAY also support full CMC messages over
HTTPS. <xref target="RFC5273">"CMC: Transport Protocols"</xref> provides
some guidance for running <xref format="none"
target="RFC5272">CMC</xref> over <xref target="RFC2616">HTTP</xref> but
notes only that "clients MAY attempt to send HTTP requests using TLS 1.0
[TLS] or later, although servers are not required to support TLS". No
attempt is made in that document to specify how the client and server
might take advantage of a secured transport to better leverage the
Simple PKI messages. [I'd like to dispense with this line of
explanation unless we get a lot of feedback on the list. -PEY]
-->
<t>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. <xref target="FIGlayers"></xref> shows how the layers build upon
each other. <figure anchor="FIGlayers">
<artwork><![CDATA[
EST Layering:
Protocols:
+---------------------------------------------------+
| |
| 4) EST messages for requests/responses |
| |
+---------------------------------------------------+
| |
| 3) HTTP for message carriage and signaling |
| |
+---------------------------------------------------+
| |
| 2) TLS for transport security |
| |
+---------------------------------------------------+
| |
| 1) TCP/IP |
| |
+---------------------------------------------------+
]]></artwork>
</figure></t>
<!--
EST is a certificate enrollment protocol that operates over HTTPS,
and thus should be trivially accessible by most clients. This profile
specifies secure transport mechanisms and how values from the TLS
exchange, the HTTP exchange, and the Simple PKI messages layers are used
for authentication and authorization purposes by the server. TLS client
certificate authentication is required for re-enrollment but falls back
on HTTP username/password authentication methods are available for
initial enrollment. When TLS client authentication cannot be leveraged
EST also provides a conduit for full CMC operations. It is assumed that
reader is familiar with the terms and concepts found in Certificate
Management over CMS (CMC) [RFC5272], Certificate Request Message Format
(CRMF) [RFC4211], etc. Unlike <xref target="RFC5273"></xref>, EST uses
both HTTPS GET and POST to support its functions.
-->
<t></t>
<t>[[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.]]</t>
<section title="Requirements Language">
<t>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 <xref
target="RFC2119"></xref>.</t>
</section>
</section>
<section title="Requirements">
<t>[[EDNOTE: The following section is still included here for
succinctness. It will eventually be published independently as
draft-ietf-pkix-estr-00.]]</t>
<!-- I'm going to leave the requirements alone. I'm not sure what Steve
wants.
-->
<t>The following describes goals and technical requirements for initial
PKI certificate enrollment along with a rationale for each
requirement.</t>
<t><list style="hanging">
<t hangText="G1">"Completeness". Server and client implementations
compliant with this document MUST be able to interoperate without
reference to subsequent profiles or additional future
specifications.</t>
</list>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:</t>
<t><list style="hanging">
<t hangText="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.</t>
<t hangText="M2">"Enrollment". A client MUST be able to use the
protocol to submit a certificate request and obtain a
certificate.</t>
<t hangText="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.</t>
<t hangText="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.</t>
</list>End-Entity proof-of-identity authentication mechanisms:</t>
<t><list style="hanging">
<t hangText="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.</t>
<t hangText="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.</t>
<t hangText="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 issued by a 3rd party, such as a
certificate issued by a device manufacturer, to leverage that
credential during initial enrollment.</t>
<t hangText="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.</t>
<t hangText="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".</t>
</list>End-Entity proof-of-possession:</t>
<t><list style="hanging">
<t hangText="P1">Proof-of-possession of subject keys MUST be
supported. As discussed in Appendix C of <xref
target="RFC4211"></xref>, 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".</t>
</list>Key algorithms:</t>
<t><list style="hanging">
<t hangText="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.</t>
</list>Server Identity mechanism:</t>
<t><list style="hanging">
<t hangText="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.</t>
</list></t>
</section>
<section title="Operational Scenario Overviews">
<t>EST provides the following services: 1) acquisition of CA
certificates, 2) certificate enrollment, 3) certificate renewal, and 4)
transport of "full" CMC messages.</t>
<!--
<t>EST uses the HTTPS "GET" and "POST" messages to communicate with the
EST server in the following scenarios. </t>
-->
<t><list style="hanging">
<t hangText="1) Acquisition of CA certificates:"><vspace
blankLines="1" />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. <vspace blankLines="1" /></t>
<!--
<t hangText="1) Acquisition of CA certificates:"><vspace
blankLines="1" />The client does an HTTPS GET to obtain the current
CA certificates from the /CACerts URI. 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 operation is permitted. <vspace
blankLines="1" /></t>
-->
<t hangText="2) Certificate Enrollment"><vspace blankLines="1" />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. <vspace
blankLines="1" /></t>
<!--
<t hangText="2) Certificate Enrollment"><vspace blankLines="1" />The
client does an HTTPS POST of a certification request to the EST
server. The client uses HTTPS to ensure the identity of the EST
server, and the server uses a combination of HTTPS client
authentication and HTTP client authentication to verify the identity
of the client. The server responds with the issued certificate.<vspace
blankLines="1" /></t>
-->
<t hangText="3) Certificate Renewal (re-enrollment)"><vspace
blankLines="1" />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.<vspace blankLines="1" /></t>
<!--
<t hangText="3) Certificate Renewal (re-enrollment)"><vspace
blankLines="1" />This is very similar to the initial enrollment.
Because it is explicitly a re-enrollment attempt the server
verifies the client identity using HTTPS 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 a full CMC request is required.<vspace
blankLines="1" /></t>
-->
<t hangText="4) Full CMC messages"><vspace blankLines="1" />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 <xref
target="RFC5272"></xref>. Support for full CMC message transport is
optional.</t>
</list></t>
<t></t>
</section>
<section title="Protocol Design and Layering">
<t></t>
<!--
<t>The aspects profiled from HTTPS (HTTP over TLS) and CMC are
summarized in <xref target="FIGlayers"></xref>:</t>
-->
<t></t>
<t>The following provides an expansion of <xref
target="FIGlayers"></xref> describing how the layers are used. Each
aspect is profiled in detail in the sections below.</t>
<figure anchor="FIGlayers2">
<artwork><![CDATA[
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) |
| |
+---------------------------------------------------+
]]></artwork>
</figure>
<section anchor="ApplicationLayer" title="Application Layer Design">
<t>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.</t>
<t>An EST client application MUST be capable of generating and parsing
simple CMC messages (see <xref target="Enroll"></xref>). Generating
and parsing full CMC messages is optional (see <xref
target="FullCMC"></xref>). The application MUST also be able to
request CA certificates from the EST server and parse the returned
"bag" of certificates (see <xref target="CACerts"></xref>).</t>
<!--
<t>EST provides a small set of certificate management functions.
These are acquisition of CA certificates, enrollment or renewal of
client certifiates, and passthrough of full CMC messages.</t>
<t>EST supplies a means to acquire CA certificates
by passing back a "bag" of certificates as detailed in
<xref target="CACerts"></xref>. The client simply requests
the EST server return a formatted set of CA certificates
it has. The client does not specify which CA certificates it
wants as all certificates are returned.</t>
<t>The main EST functions are certificate
enrollment and renewal which are jointly provided by CMC's Simple
PKI Request and Simple PKI Response messages. Certificate
enrollment and renewal, while subtly different, are both described
in <xref target="Enroll"></xref>. The client posts a
CMC Simple PKI Request (essentially a PKCS#10 certificate request)
to the server and receives back the newly generated certificate.</t>
<t>When CMC's Simple PKI
messages do not provide sufficient functionality, full CMC messages
may be passed between the client and the EST server. EST transport of
full CMC messages is explained in <xref target="FullCMC">
</xref>.</t>
-->
</section>
<section anchor="HTTP" title="HTTP Layer Design">
<t>HTTP is used to transport EST requests and responses. Specific URIs
are provisioned for handling each type of request as given in <xref
target="HTTPheaders"></xref>. HTTP is also used for client
authentication services when TLS client authentication is not
available, as detailed in Section <xref
target="HTTPuserAuthCandAuthZ"> </xref>. HTTP message types are used
to convey EST requests and responses as specified in <xref
target="MIMEtypes"></xref>.</t>
<section anchor="HTTPheaders" title="HTTP headers for control">
<t>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.<vspace
blankLines="1" /><xref format="none" target="RFC5272">CMC</xref>
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. <vspace blankLines="1" />Various media types as
indicated in the HTTP content-type header are used to transport EST
messages. Valid media times are specified in <xref
target="MessageTypes"></xref>.</t>
</section>
<section anchor="HTTPURIs" title="HTTP URIs for control">
<t>This profile supports four operations indicated by specific
URIs:</t>
<figure anchor="OPERATIONtypes">
<artwork><![CDATA[
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 | | |
+------------------------+-----------------+-------------------+
]]></artwork>
</figure>
<t></t>
<t>In the common manner of HTTP based interactions each operation is
accessed by forming the URI as follows:</t>
<t></t>
<figure title="">
<artwork><![CDATA["GET" BASEPATH OPERATIONPATH
"POST" BASEPATH OPERATIONPATH]]></artwork>
</figure>
<t>where:</t>
<t><list style="symbols">
<t>BASEPATH is a common path for all EST operations</t>
<t>OPERATIONPATH specifies the specific operation.</t>
</list></t>
<t>When a URI is formed, the BASEPATH and OPERATIONPATH are combined
to form the <xref target="RFC2616">abs_path </xref>. The means by
which clients acquire the BASEPATH URI are outside the scope of this
document. The following are two example base URIs:</t>
<t><list style="symbols">
<t>With BASEPATH having the value of /arbitrary/base/path</t>
<t>https://example.org/arbitrary/base/path</t>
<t>https://example2.org:8080/arbitrary/base/path</t>
</list></t>
<t>The following examples are valid complete URIs under this
specification:<list style="symbols">
<t>With BASEPATH having the value /base/path</t>
<t>https://example.org/base/path/CACerts</t>
<t>https://example2.org:8080/base/path/simpleEnroll</t>
<t>https://example3.org/base/path/fullCMC</t>
</list></t>
<t>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.</t>
<!--
<t>Implementation note: A simple Common Gateway Interface (CGI)
application at each fully specified path, with the HTTPS server
configured to provide <xref target="TLSclientAuthC"></xref>, is
sufficient for a working example (the web service can forward the
<xref target="PoP"></xref> proof-of-possession information to the
application using the CGI interface). Additional discussion
regarding the use of CGI can be found in <xref
target="cgiserver"></xref>.</t>
-->
<t>An EST server MAY provide additional, non-EST services on other
URIs.</t>
<t>[[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.]]</t>
</section>
<section anchor="HTTPuserAuthCandAuthZ"
title="HTTP-Based Client Authentication">
<t>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.</t>
<t>Basic and Digest authentication MUST only be performed over <xref
target="RFC4346">TLS</xref>. As specified in <xref
target="RFC5273">CMC: Transport Protocols</xref> 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 <xref target="RFC2616">Basic </xref> and
<xref target="RFC2617">Digest</xref> authentication methods.</t>
<t>Servers that support Basic and Digest authentication methods MAY
reject requests using the <xref format="none"
target="RFC2616">HTTP</xref> defined WWW-Authenticate
response-header (Section 14.47). At that point the client SHOULD
repeat the request, including the appropriate <xref
target="RFC2617"> HTTP</xref> Authorization Request Header (Section
3.2.2).</t>
<t>Support for Basic authentication as specified in <xref
format="none" target="RFC2617">HTTP</xref> allows the 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 <xref target="TLSserverAuthZ"></xref>).</t>
<t>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.</t>
</section>
<section anchor="MessageTypes" title="Message types">
<t>This document uses existing media types for the messages as
specified by <xref target="RFC2585">Internet X.509 Public Key
Infrastructure Operational Protocols: FTP and HTTP</xref> and <xref
target="RFC5967">The application/pkcs10 Media Type</xref> and <xref
target="RFC5272">CMC</xref>. To support distribution of multiple
application/pkix-cert's for the CA certificate chain the <xref
target="RFC2046"></xref> multipart/mixed media type is used.</t>
<t>The message type is specified in the HTTP Content-Type
header.</t>
<!-- This text repeats the profiling discussion more
than describing the message types:
<t>This document profiles the use of two <xref
format="none" target="RFC5272">Certificate Management over
CMS</xref> messages: "Simple PKI Request" and "Simple PKI Response"
and does not require full implementation of all <xref format="none"
target="RFC5272">CMC</xref> features. This is consistent with the
<xref format="none" target="RFC5272">CMC</xref> protocol
specification of "simple" messages for clients to use "in the event
no other services are needed". Thus full CMC messages MAY also
be used.</t>
-->
<!--This was our text on the MIME-types, but the new table is way easier to read:
<t>For simple certificate enrollment and re-enrollment requests,
application/pkcs10 (defined in <xref target="RFC5967"></xref>) is
used as specified in <xref target="Enroll"></xref>. Certificate
responses to enrollment and re-enrollment requests are carried as
application/pkix-cert (defined in <xref target="RFC2585"></xref>) as
specified in <xref target="EnrollResponse"></xref>. Full CMC
requests and responses are both transported as
application/pkcs7-mime (as given in <xref target="RFC5273"></xref>.
Requests for CA certificates generate a response with the media type
multipart/parallel. Within each parallel part is an entity of media
type application/pkix-cert. See <xref target="CACerts"></xref>.</t>
-->
<t>For reference the messages and their corresponding MIME and media
types are:</t>
<figure anchor="MIMEtypes">
<artwork><![CDATA[
+-------------------+--------------------------+-------------------+
| 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)| |
+-------------------+--------------------------+-------------------+
]]></artwork>
</figure>
</section>
</section>
<section anchor="TLSLayer" title="TLS Layer Design">
<t>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.</t>
<section anchor="AuthCandAuthZ" title="TLS for transport security">
<t>HTTPS MUST be used. TLS 'session resumption' SHOULD be
supported.</t>
<t>HTTPS is defined in <xref target="RFC2818">HTTP Over TLS</xref>
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.</t>
<t><xref format="default" target="RFC5272">CMC</xref> 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 <xref target="IDevID">IEEE 802.1AR
IDevID</xref> credential). Additionally this document specifies
username/password authentication methods beyond those included in
<xref format="default" target="RFC5272">CMC</xref>. Authentication
and authorization mechanisms required for certificate issuance (and
renew/rekey) are provided by HTTP and HTTPS mechanisms as described
in this document.<vspace blankLines="1" />Proof-of-possession is a
distinct issue from proof-of-identity and is addressed in <xref
target="PoP"></xref>. <vspace blankLines="1" />This document also
defines transport for the full <xref format="default"
target="RFC5272">CMC</xref> specification compliant with <xref
format="default" target="RFC5273">CMC Transport
Protocols</xref>.</t>
<section anchor="TLSserverAuthC"
title="TLS-Based Server Authentication">
<t>The client MUST validate the TLS server certificate presented
during the <xref target="RFC4346">TLS 1.1</xref> (or above)
exchange-defined Server Certificate message or the client MUST
independently validate the response contents. Validation is
performed as given in <xref target="RFC5280"></xref> and <xref
target="RFC6125"></xref>. The cipher suites are detailed in <xref
target="cryptoalgs"></xref>.</t>
<t>There are multiple methods of validation depending on the
current state of the client:</t>
<t><list style="numbers">
<t>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 <xref
target="RFC2818">HTTP Over TLS</xref>, Section 3.1 "Server
Identity" and <xref target="RFC6125"> </xref>). 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. <!-- I'm leaving this in place for discussion, but I think we can leave it out.
We might also leave out part of the "large store" sentence.
As detailed in <xref
target="SecurityConsiderations"></xref>, clients are RECOMMENDED to
ship with a carefully chosen list of initial trust anchors. Proper
selection of initial trust anchors is out of scope of this
document. <vspace blankLines="1" />[[EDNOTE: is there an RFC
discussing this problem in the HTTPS space that we can
reference? PEY: I couldn't find anything.]]--></t>
<t>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.</t>
<t>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 <xref target="CACerts"></xref>. HTTP
authentication requests MUST NOT be responded to since the
server is unauthenticated (only the content data is accepted
manually).</t>
</list></t>
<t>Methods 1 and 2 are essentially validation as given in <xref
target="RFC5280"></xref>. Method 1 is as described in <xref
target="RFC6125"></xref>, Section 6.6.1 "Match Found". Method 2 is
described in <xref target="RFC6125"></xref> as "No Match Found,
Pinned Certificate". Method 3 is described in <xref
target="RFC6125"></xref>, Section 6.6.4 as "Fallback" and
describes the process of "pinning" the received certificate.</t>
<t>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.</t>
</section>
<section anchor="TLSclientAuthC"
title="TLS-Based Client Authentication">
<t>Clients SHOULD support <xref target="RFC4346"></xref> defined
Certificate request (section 7.4.4). As required by <xref
target="RFC4346"></xref>, 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.</t>
<t>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
<xref target="ClientAuthorization">client
authorization</xref>.</t>
</section>
</section>
</section>
<section anchor="PoP" title="Proof-of-Possession">
<t>As discussed in Appendix C of <xref target="RFC4211">CRMF</xref>,
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".</t>
<t>The signed enrollment request provides a "Signature"-based
proof-of-possession. The mechanism described in <xref
target="IdentityLinkedPOP"></xref> 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).</t>
</section>
<section anchor="IdentityLinkedPOP"
title="Linking Identity and POP information">
<t>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
<xref target="RFC5272"></xref> Section 6.3-defined "Linking Identity
and POP information" method available if full CMC messages are
used.</t>
<t>The client generating the request SHOULD obtain the tls-unique
value as defined in <xref target="RFC5929">Channel Bindings for
TLS</xref> from the TLS subsystem. The tls-unique value is encoded as
specified in Section 4 of <xref target="RFC4648">Base64</xref> and the
resulting string is placed in the certification request
challenge-password field.</t>
<t>The tls-unique specification includes a synchronization issue as
described in <xref target="RFC5929">Channel Bindings for TLS</xref>
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 must use their tls-unique implementation specific
synchronization methods to obtain this first tls-unique value.</t>
<t>Any TLS renegotiation MUST use "secure_renegotiation" <xref
target="RFC5746"></xref> (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).</t>
<t>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.</t>
<t>[[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.]]</t>
<t>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 <xref format="none" target="RFC5272">CMC</xref> "RA POP Witness
Control" in a CMC Full PKI Request message or other mechanisms which
are out-of-scope of this document.</t>
</section>
</section>
<section title="Protocol Exchange Details">
<t>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.</t>
<!-- I was actually thinking perhaps we would make a master authorization
section here to contain the next two sections and then make a separate
section to contain the individual requests. Either that or we need to banish
the authorization discussion to somewhere else. -->
<section anchor="ClientAuthorization" title="Client Authorization">
<t>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.</t>
<t>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.</t>
</section>
<section anchor="TLSserverAuthZ" title="Server Authorization">
<t>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.</t>
<t>There are multiple methods for checking authorization corresponding
to the method of server authentication used (see <xref
target="TLSserverAuthC"></xref>):</t>
<t><list style="numbers">
<t>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" (<xref target="RFC2818">Section 3.1 "Server
Identity"</xref> and <xref target="RFC6125"></xref>). The securely
configured URI provides the authorization statement and the
server's authenticated identity confirms it is the authorized
server.</t>
<t>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 <xref target="RFC5280"></xref>-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.</t>
<t>If fallback logic was invoked to accept the certificate
manually, then that authentication implies authorization of the
EST server.</t>
</list></t>
</section>
<section anchor="CACerts" title="Distribution of CA certificates">
<t>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.</t>
<t>The EST server SHOULD NOT require client authentication or
authorization to reply to this request.</t>
<t>The client MUST authenticate the EST server as specified in <xref
format="default" target="AuthCandAuthZ"></xref>. 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.</t>
<t>Subsequent connections to the EST server SHOULD validate the TLS
server certificate using the stored CA certificates as described in
<xref format="default" target="AuthCandAuthZ"></xref>.</t>
<section anchor="CACertsResp"
title="Distribution of CA certificates response">
<t>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" <xref
format="none" target="RFC4210">CMP</xref> certificates.</t>
<t>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.</t>
<t>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
the three additional <xref format="none"
target="RFC4210">CMP</xref>-defined Root CA Key Update certificates:
OldWithOld, OldWithNew, and NewWithOld.</t>
<t>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.</t>
<t>The NewWithNew certificate is the certificate that is extracted
and authorized using out-of-band information as described in <xref
target="CACerts"></xref>. When out-of-band validation occurs each of
the other three certificates MUST be validated using normal <xref
target="RFC5280"></xref> certificate path validation (using the
NewWithNew certificate as the trust anchor) before they can be used
to build certificate paths during peer certificate validation.</t>
</section>
</section>
<section anchor="Enroll" title="Simple Enrollment of Clients">
<t>At any time the client MAY request a certificate from the EST base
URI with the OPERATIONPATH "/simpleEnroll'.</t>
<t>When HTTPS POSTing to the 'SimpleEnroll' location the client MUST
include a CMC Simple PKI Request as specified in <xref format="none"
target="RFC5272">CMC</xref> Section 3.1 (i.e., a <xref format="none"
target="RFC2986">PKCS#10 Certification Request</xref>).</t>
<t>The content-type of "application/pkcs10" MUST be specified. The
format of the request is as specified in <xref
target="RFC4945">Section 6.4 of </xref>.</t>
<t>The server MUST authenticate the client as specified in <xref
target="AuthCandAuthZ"></xref>. 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.</t>
<t>The client MUST authenticate the EST server as specified in <xref
target="TLSserverAuthC"></xref>.</t>
<section anchor="Re-enroll" title="Simple Re-Enrollment of Clients">
<t>At any time a client MAY request renew/rekey of its certificate
from the EST base URI with the OPERATIONPATH "/simpleReEnroll'.</t>
<t>The certificate request is the same format as for the
"simpleEnroll" path extension with the same content-type.</t>
<t>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 <xref
target="RFC5272">Section 2 of</xref>, 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 (<xref target="TLSclientAuthC"></xref>).</t>
<t>[[EDNOTE: <xref target="RFC6403"></xref> defines a method of
recognizing a re-enroll based on PKCS10 contents, see section 4.1.
The method described herein is explicit.]]</t>
</section>
<section anchor="EnrollResponse"
title="Simple Enroll and Re-Enroll Response">
<t>The server responds to a 'simpleEnroll' or 'simpleReEnroll'
request with the client's newly issued certificate or it provides an
error response.</t>
<t>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 <xref target="RFC4945">Section 6.1
of</xref>.</t>
<t>When rejecting a request the server MUST specify either an <xref
format="none" target="RFC2616">HTTP</xref> 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.</t>
<t>If the server responds with an <xref format="none"
target="RFC2616">HTTP</xref> 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).</t>
<t>All other return codes are handled as specified in <xref
format="none" target="RFC2616">HTTP</xref>.</t>
</section>
</section>
<section anchor="FullCMC" title="Full CMC ">
<t>At any time the client MAY request a certificate from the EST base
URI with the OPERATIONPATH "/fullCMC".</t>
<t>The client MUST authenticate the server as specified in <xref
target="TLSserverAuthC">Server Authentication</xref>.</t>
<t>The server SHOULD authenticate the client as specified in <xref
target="AuthCandAuthZ"></xref>. The server MAY depend on CMC client
authentication methods instead.</t>
<section anchor="FullCMCReq" title="Full CMC Request">
<t>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 <xref
target="RFC5273"></xref>.</t>
</section>
<section anchor="FullCMCResp" title="Full CMC Response">
<t>The server responds with the client's newly issued certificate or
provides an error response.</t>
<t>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 <xref
target="RFC5273"></xref>. The response data includes either the CMC
Simple PKI Response or the CMC Full PKI Response.</t>
<t>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.</t>
<t>All other return codes are handled as specified in <xref
target="EnrollResponse"></xref> or <xref
target="RFC2616">HTTP</xref>.</t>
</section>
</section>
<section title="Server-side Key Generation">
<t>[[EDNOTE: This section is provisional as a response to review
feedback. It is not fully integrated with the rest of this
document.]]</t>
<t>At any time the client MAY request a "private" keypair and
associated certificate from the EST base URI with the OPERATIONPATH
"/serverKeyGen".</t>
<t>The client MUST authenticate the server as specified in <xref
target="TLSserverAuthC"></xref>.</t>
<t>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.</t>
<t>The server MUST authenticate the client as specified in <xref
target="AuthCandAuthZ"></xref>. 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 <xref
format="title" target="TLSclientAuthC"></xref> 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.</t>
<t>Proper random number and key generation and storage is a server
implementation responsibility.</t>
<section title="Server-side Key Generation Request">
<t>The certificate request is HTTPS POSTed and is the same format as
for the "/simpleEnroll" path extension with the same
content-type.</t>
<t>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.</t>
</section>
<section title="Server-side Key Generation Response">
<t>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.</t>
<t>The first submessage is an "application/pkix-privkey" consisting
of the PEM-encoded DER-encoded PrivatekeyInfo between the PEM
headers as described in [RFC5958]:</t>
<t><figure>
<artwork><![CDATA[-----BEGIN PRIVATE KEY-----
MIIBhDCB7gIBADBFMQswCQYDVQQGEwJBVTETMBEGA1UECBMKU29tZS1TdGF0ZTEh
Simplified example of Base64 encoding of DER-encoded PrivateKeyInfo
ED8rf3UDF6HjloiV3jBnpetx4JjZH/BlmD9HMqofVEryb1e4iZgMUvuIgwEjQwpD
8J4OhHvLh1o=
-----END PRIVATE KEY-----]]></artwork>
</figure></t>
<t>The second submessage is an "application/pkix-cert" and exactly
matches the certificate response to /simpleEnroll.</t>
<t>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.</t>
<t>[[EDNOTE: do we have an existing MIME type we can use for the
privatekey?]]</t>
</section>
</section>
</section>
<!-- Possibly a 'Contributors' section ... -->
<section anchor="cryptoalgs" title="Cryptographic Algorithms">
<t>This section details the specific cryptographic algorithms and cipher
suite requirements.</t>
<t>The client SHOULD offer the Suite B compliant cipher suites as
indicated in <xref target="RFC5430"></xref>, Section 4 "Suite B
Compliance and Interoperability Requirements". For greatest
interoperability the client SHOULD also offer
TLS_RSA_WITH_AES_128_CBC_SHA.</t>
<t>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 <xref format="none" target="RFC2986">PKCS#10 Certification
Request</xref>. For example if a <xref target="RFC5430"></xref> 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.</t>
<t>[[EDNOTE: This is in alignment with <xref target="RFC6403"></xref>
section 4.1. To encourage algorithm agility, discussions of the
MUST/SHOULD algorithms should be in a distinct document.]]</t>
</section>
<section title="Contributors/Acknowledgements ">
<t>The editors would like to thank Stephen Kent, Vinod Arjun, Jan
Vilhuber, Sean Turner, and others for their feedback and prototypes of
early drafts.</t>
</section>
<section title="IANA Considerations">
<t>(This section is incomplete)</t>
<t>The following aspects should be registered with IANA
Considerations:</t>
<t>The RA Authorization certificate policy extension OID as discussed in
<xref target="TLSserverAuthZ"></xref> requires registration with
IANA.</t>
<t>[[EDNOTE: The URLs specified in <xref target="introduction"></xref>
probably do not need to be registered with IANA.]]</t>
</section>
<section anchor="SecurityConsiderations" title="Security Considerations">
<t>(This section is incomplete)</t>
<t>"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.</t>
<t>As described in <xref format="none" target="RFC5272">CMC Section
6.7</xref>, "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.</t>
<t>As given in <xref target="TLSclientAuthC"></xref> 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 <xref target="TLSclientAuthC"></xref> and
<xref target="ClientAuthorization"></xref>. The server MAY fall back on
manual authorization by the server administrator.</t>
<t>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 <xref
target="CACerts"> </xref>. Alternatively, a server certificate MAY be
authenticated manually as specified in <xref
target="TLSserverAuthC"></xref> #3.</t>
<t>As noted in <xref target="TLSserverAuthC"></xref> 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 <xref target="TLSserverAuthZ"></xref>. 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). 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 <xref
target="TLSclientAuthC">HTTPS-based client authentication</xref>.
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.</t>
<t><xref target="HTTPuserAuthCandAuthZ"></xref> 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.</t>
<t>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].</t>
</section>
</middle>
<!-- *****BACK MATTER ***** -->
<back>
<!-- References split into informative and normative -->
<!-- There are 2 ways to insert reference entries from the citation libraries:
1. define an ENTITY at the top, and use "ampersand character"RFC2629; here (as shown)
2. simply use a PI "less than character"?rfc include="reference.RFC.2119.xml"?> here
(for I-Ds: include="reference.I-D.narten-iana-considerations-rfc2434bis.xml")
Both are cited textually in the same manner: by using xref elements.
If you use the PI option, xml2rfc will, by default, try to find included files in the same
directory as the including file. You can also define the XML_LIBRARY environment variable
with a value containing a set of directories to search. These can be either in the local
filing system or remote ones accessed by http (http://domain/dir/... ).-->
<references title="Normative References">
&RFC2046;
&RFC2119;
&RFC2585;
&RFC2616;
&RFC2617;
&RFC2986;
&RFC4210;
&RFC4346;
&RFC4648;
&RFC4945;
&RFC5272;
&RFC5273;
&RFC2818;
&RFC5929;
&RFC5280;
&RFC5430;
&RFC5746;
&RFC5967;
&RFC6125;
</references>
<references title="Informative References">
&RFC4211;
&RFC6403;
<reference anchor="IDevID"
target="http://standards.ieee.org/findstds/standard/802.1AR-2009.html">
<front>
<title>IEEE 802.1AR Secure Device Identifier</title>
<author fullname="" surname="IEEE Std">
<organization abbrev="W3C TAG">IEEE</organization>
</author>
<date day="10" month="December" year="2009" />
</front>
</reference>
</references>
<section anchor="discovery" title="Server Discovery">
<t>(informative)</t>
<t>(This section is incomplete)</t>
<t>Clients MAY use DNS-SD or similar discovery algorithms to determine
the EST base URL. In such cases it is expected that <xref
target="TLSserverAuthC">method 2</xref> be used during server
authentication.</t>
</section>
<section anchor="externalconcentrator" title="External TLS concentrator">
<t>(informative)</t>
<t>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.</t>
<t>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.</t>
<t>The TLS concentrator MUST validate the <xref format="none"
target="RFC4346">TLS</xref> Section 7.4.8 'Certificate Verify'.</t>
<t>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.</t>
<t>[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.]</t>
<t>[TBD - the HTTP header field names etc shall be specified here]</t>
<t>The EST server MUST be specifically configured by the administrator
to accept this mechanism.</t>
</section>
<section anchor="cgiserver" title="CGI Server implementation">
<t>(informative)</t>
<t>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.</t>
<t>An HTTPS server MUST insert the client certificate into environment
variables before calling a server CGI application.</t>
<t>[TBD - describe the CGI environment variables here. Can likely follow
the apache example].</t>
<t>An HTTP server MUST insert the client certificate into environment
variables before calling a server CGI application.</t>
<t>[TBD - describe the CGI environment variables here. Can likely follow
the apache example].</t>
</section>
<section title="Updating SCEP implementations">
<t>(informative)</t>
<t>SCEP has been used instead of a full implementation of CMC for the
same simplicity reasons discussed in <xref
target="introduction"></xref>. Such implementations would benefit from
being updated to this specification in the following ways:<list
style="symbols">
<t>Implementing a subset of <xref format="none"
target="RFC5272">CMC</xref> provides an enhancement path if the full
CMC functionality is required.</t>
<t>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.</t>
<t>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.</t>
<t>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 <xref format="none"
target="RFC4210">CMP</xref>.</t>
</list>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:</t>
<t><list style="symbols">
<t>The SCEP client supports HTTPS server authentication and
authorization as detailed <xref target="TLSserverAuthC"></xref>.</t>
<t>The SCEP client supports HTTPS client authentication as detailed
in <xref target="TLSclientAuthC"></xref>.</t>
<t>When performing the "Get CA Cert" SCEP transaction the client
supports the <xref target="CACerts"></xref> 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).</t>
<t>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).</t>
<t>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 <xref target="EnrollResponse"></xref>.</t>
<t>Polling is simplified with clients repeatedly establishing the
full HTTPS connection; no polling specific state information is
encoded into the EST messages.</t>
<t>GetCert is deprecated.</t>
<t>GetCRL is deprecated.</t>
</list>These simplifications to an existing SCEP implementation result
in an SCEP client that is compliant with CMC when using the EST
transport.</t>
<t>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
<xref target="HTTPuserAuthCandAuthZ"></xref> 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.</t>
</section>
<!--
v00 2009-04-13 MCP Initial version
-->
</back>
</rfc>
| PAFTECH AB 2003-2026 | 2026-04-22 22:07:21 |