One document matched: draft-ietf-pkix-est-03.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 RFC1321 SYSTEM "http://xml.resource.org/public/rfc/bibxml/reference.RFC.1321.xml">
<!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 RFC2314 SYSTEM "http://xml.resource.org/public/rfc/bibxml/reference.RFC.2314.xml">
<!ENTITY RFC2409 SYSTEM "http://xml.resource.org/public/rfc/bibxml/reference.RFC.2409.xml">
<!ENTITY RFC2397 SYSTEM "http://xml.resource.org/public/rfc/bibxml/reference.RFC.2397.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 RFC2925 SYSTEM "http://xml.resource.org/public/rfc/bibxml/reference.RFC.2925.xml">
<!ENTITY RFC2985 SYSTEM "http://xml.resource.org/public/rfc/bibxml/reference.RFC.2985.xml">
<!ENTITY RFC2986 SYSTEM "http://xml.resource.org/public/rfc/bibxml/reference.RFC.2986.xml">
<!ENTITY RFC3986 SYSTEM "http://xml.resource.org/public/rfc/bibxml/reference.RFC.3986.xml">
<!ENTITY RFC4086 SYSTEM "http://xml.resource.org/public/rfc/bibxml/reference.RFC.4086.xml">
<!ENTITY RFC4210 SYSTEM "http://xml.resource.org/public/rfc/bibxml/reference.RFC.4210.xml">
<!ENTITY RFC4288 SYSTEM "http://xml.resource.org/public/rfc/bibxml/reference.RFC.4288.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 RFC5077 SYSTEM "http://xml.resource.org/public/rfc/bibxml/reference.RFC.5077.xml">
<!ENTITY RFC5246 SYSTEM "http://xml.resource.org/public/rfc/bibxml/reference.RFC.5246.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 RFC5274 SYSTEM "http://xml.resource.org/public/rfc/bibxml/reference.RFC.5274.xml">
<!ENTITY RFC5280 SYSTEM "http://xml.resource.org/public/rfc/bibxml/reference.RFC.5280.xml">
<!ENTITY RFC5652 SYSTEM "http://xml.resource.org/public/rfc/bibxml/reference.RFC.5652.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 RFC5958 SYSTEM "http://xml.resource.org/public/rfc/bibxml/reference.RFC.5958.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 RFC6402 SYSTEM "http://xml.resource.org/public/rfc/bibxml/reference.RFC.6402.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-03" 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>
<author fullname="Dan Harkins" initials="D" role="editor"
surname="Harkins">
<organization>Aruba Networks</organization>
<address>
<postal>
<street>1322 Crossman Avenue</street>
<!-- Reorder these if your country does things differently -->
<city>Sunnyvale</city>
<region>CA</region>
<code>94089-1113</code>
<country>USA</country>
</postal>
<email>dharkins@arubanetworks.com</email>
<!-- uri and facsimile elements may also be added -->
</address>
</author>
<date 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 Public
Key Infrastructure (PKI) 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 profiles certificate enrollment for clients using
Certificate Management over CMS (CMC) <xref target="RFC5272"/> messages
over a secure transport. Enrollment over Secure Transport (EST)
describes the use of TLS 1.1 <xref target="RFC4346"/> (or a later
version) and HTTP 1.1 <xref target="RFC2616"/> to provide an
authenticated and authorized channel for Simple PKI Requests and
Responses <xref target="RFC5272"/>.</t>
<t>Architecturally the EST service is located between a CA and the
client device. It performs several functions traditionally allocated to
the PKI role of the Registration Authority (RA). The nature of the
communication of EST server to CA is not described in this document.</t>
<t>EST adopts the CMP <xref target="RFC4210"/> model for CA certificate
rollover, but does not use the CMP message syntax or protocol. EST
servers are extensible in that new functions may be defined to provide
additional capabilities not specified in <xref
target="RFC5272">CMC</xref>. Non-CMC-based extensions such as the
requesting of Certificate Signing Request attributes and requests for
server generated keys are defined in this document.</t>
<t>EST specifies the transferring of messages securely over HTTPS <xref
target="RFC2818"/> where the HTTP headers and content types are used in
conjunction with TLS. HTTPS operates over TCP; this document does not
specify EST over DTLS/UDP. <xref target="FIGlayers"/> shows how the
layers build upon each other. <figure anchor="FIGlayers">
<artwork><![CDATA[
EST Layering:
Protocols:
+--------------------------------------------+
| |
| EST messages for request/response messages |
| |
+--------------------------------------------+
| |
| HTTP for message transfer and signaling |
| |
+--------------------------------------------+
| |
| TLS for transport security |
| |
+--------------------------------------------+
| |
| TCP for transport |
| |
+--------------------------------------------+
]]></artwork>
</figure></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="Terminology">
<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"/>.</t>
<t>It is assumed that the reader is familiar with the terms and
concepts described in PKCS#10 <xref target="RFC2314"/>, HTTPS <xref
target="RFC2818"/>, CMP <xref target="RFC4210"/>, CMC <xref
target="RFC5272"/><xref target="RFC5273"/><xref target="RFC5274"/>,
and TLS <xref target="RFC5246"/>.</t>
</section>
</section>
<section title="Operational Scenario Overviews">
<t>This section provides an informative overview of the operational
scenarios to better introduce the reader to the protocol discussion.
This section does not include <xref target="RFC2119"/> key words.</t>
<t>Both the EST clients and server are configured with information that
will be the basis of authentication and authorization. The specific
initialization data depends on the methods available in the client
device and server, but can include shared secrets, network service names
and locations (e.g. a URI <xref target="RFC3986"/>), trust anchor
information (e.g. current CA certificate or third party TA(s) or a hash
of the CA's root certificate), and enrollment keys and certificates.
Depending on the enterprise's acquisition and network management
practices, some initialization may be performed by the vendor prior to
client delivery. In that case, the client device vendor will provide
data, such as trust anchors, to the enterprise via a secure procedural
mechanism. The distribution of this initial information is out of
scope.</t>
<t>Distribution of trust anchors and certificates can be made through
the EST server. However, nothing can be inferred about the authenticity
of these trust anchors and certificates until an out-of-band mechanism
from the above list is used to verify them.</t>
<t>Sections 2.1-2.3 very closely mirror the text of the Scenarios
Appendix of <xref target="RFC6403"/> with such modifications as are
appropriate for this profile. (Our thanks are extended to the authors of
that document). More importantly, Sections 2.1-2.6 mirror the set of EST
functions (see <xref target="OPERATIONtypes"/>) and provide an
informative overview of EST's capabilities.</t>
<t>The client device begins by initiating a TLS-secured HTTP session
with the EST server. The specific EST service requested is named in an
operational URI portion. The client device and server authenticate each
other, and the client ascertains the authorization of the server. The
server ascertains the authorization of the client and services the
request.</t>
<section title="Obtaining CA Certificates">
<t>The EST client can request a copy of the current CA certificates.
The EST client is assumed to perform this operation before performing
other operations.</t>
<t>The EST client authenticates and authorizes the EST server when
requesting the current CA certificates. As detailed in <xref
target="TLSserverAuthC"/> and <xref target="TLSmutualAuth"/>) the
available options include:</t>
<t><list style="symbols">
<t>Verifying the EST server's HTTPS URI against the EST server's
certificate using third party TAs (similar to a common HTTPS
exchange). This allows the EST server and client to leverage
existing TAs that might be known to the EST client.</t>
<t>The client can leverage a previously distributed trust anchor
specific to the EST server. This allows the EST client to use an
existing, potentially older, CA certificate to request more recent
CA certificates.</t>
<t>For bootstrapping the the EST client can accept manual
authentication performed by the end user as detailed in <xref
target="BootstrapCACerts"/>.</t>
</list>Client authentication is not required for this exchange, so
it is trivially supported by the EST server.</t>
</section>
<section title="Initial Enrollment">
<t>After authenticating an EST server and verifying that it is
authorized to provide services to the client, an EST client can
acquire a certificate by submitting an enrollment request to that
server. <!-- DNH: this section describes what happens after authenticating and
authorizing the the EST server so saying that the client
authenticates and authorizes the EST server seems unnecessary.
Also and attempts to tweak it for certificate-less is difficult
so how about if it's just left out?
Following the logic laid out in <xref target="TLSserverAuthC"/> the EST
client authenticates and authorizes the EST server.--></t>
<t>The EST server authenticates and authorizes the EST client as
specified in <xref target="TLSclientAuthC"/> and <xref
target="ClientAuthorization"/>. The methods described in the normative
text that are expanded on in this overview include:</t>
<t><list style="symbols">
<t>Previously installed certificate (e.g., Manufacturer Installed
Certificate or 3rd party issued certificate);</t>
<t>Username/password distributed out-of-band</t>
</list></t>
<section title="Previously Installed Client Certificate">
<t>If the EST client has a previously installed certificate that was
issued by a 3rd party this certificate can be used to authenticate
the client's request for a certificate from the EST server's CA. An
EST client responds to the EST server's TLS certificate request
message with the existing certificate (i.e., it provides the
previously issued certificate to the EST server). The EST server
will authenticate the client's existing certificate and authorize
the client's request as described in <xref
target="TLSclientAuthC"/>.</t>
</section>
<section title="Username/Password Distributed Out-of-Band">
<!---->
<t>When the EST client is not authenticated during the TLS handshake
(see <xref target="TLSclientAuthC"/>), or if the EST server wishes
additional authentication information, the EST server can requests
that the EST client submit a username/password using the HTTP Basic
or Digest Authentication methods. See <xref
target="HTTPuserAuthCandAuthZ"/>.</t>
<t>Alternately, the server and client can mutually authenticate
using <xref target="TLSmutualAuth"> certificate-less TLS
authentication</xref>.</t>
</section>
</section>
<section title="Client Certificate Re-issuance">
<t>An EST client can renew/rekey an existing client certificate by
submitting a re-enrollment request to an EST server. As with initial
enrollment, the EST server authenticates the client using any
combination of the existing client certificate (see <xref
target="TLSclientAuthC"/>) and/or HTTP Basic or Digest Authentication
with a username/password (see <xref
target="HTTPuserAuthCandAuthZ"/>).</t>
<t>Two common renew/rekey scenarios for clients that are already
enrolled are described here. One addresses the renew/rekey of
signature certificates and the other addresses the renew/rekey of key
exchange certificates. The certification request message includes the
same Subject and SubjectAltName as the current key exchange
certificate with name changes handled as specified in <xref
target="Re-enroll"/>.</t>
<section title="Re-issuance of Signature Certificates">
<t>When a signature certificate is re-issued, the existing
certificate can be used by an EST client for authentication.</t>
</section>
<section title="Re-issuance of Key Exchange Certificates">
<t>When a key exchange certificate is re-issued an existing
signature certificate is used by an EST client for authentication.
If there is no current signature certificate available, the EST
server falls back on the HTTP authentication method (<xref
target="HTTPuserAuthCandAuthZ"/>).</t>
</section>
</section>
<section title="Server Key Generation">
<t>The EST client can request a server-generated certificate and key
pair.</t>
</section>
<section title="Full PKI Request messages">
<t>Full PKI Request messages can be transported via EST with the Full
CMC Request function, allowing access to functionality not provided by
the Simple Enrollment of Clients functions. Full PKI Request messages
are defined in Sections 3.2 and 4.2 of <xref target="RFC5272"/>. See
<xref target="FullCMC"/> for a discussion of how EST provides a
transport for these functions.</t>
</section>
<section title="CSR (Certificate Signing Request) Attributes Request">
<t>Prior to sending an enrollment request to an EST server, an EST
client can query the EST server for the set of additional attribute(s)
that the client is requested to supply in the subsequent enrollment
request(s).</t>
</section>
</section>
<section anchor="ProtocolDesignandLayering"
title="Protocol Design and Layering">
<t>Figure 2 provides an expansion of <xref target="FIGlayers"/>
describing how the layers are used. Each aspect is described in more
detail in the sections that follow.</t>
<figure anchor="FIGlayers2">
<artwork><![CDATA[
EST Layering:
Protocols and uses:
+---------------------------------------------------+
| |
| Message types: |
| - "Simple PKI" messages |
| (incorporating proof-of-possession) |
| - CA certificate retrieval |
| - "Full PKI" messages (OPTIONAL) |
| - CSR attribute request (OPTIONAL) |
| - Server-generated key request (OPTIONAL) |
| |
+---------------------------------------------------+
| |
| HTTP: |
| - HTTP headers and URIs for control |
| - Content-Type headers specify message type |
| - Headers for control/error messages |
| - URIs for selecting functions |
| - Basic or Digest authentication if no |
| client certificate |
| |
+---------------------------------------------------+
| |
| TLS for transport security |
| - Authentication is REQUIRED for EST server |
| OPTIONAL for EST clients |
| - Indirectly provides proof-of-identity for EST |
| - Provides communications integrity |
| - Channel Binding [RFC5929] to link |
| proof-of-identity with message-based |
| proof-of-possession. (OPTIONAL) |
| |
+---------------------------------------------------+
]]></artwork>
</figure>
<t/>
<t>Specifying HTTPS as the secure transport for enrollment messages
introduces two 'layers' to communicate authentication and control
messages: TLS and HTTP.</t>
<t>The TLS layer provides message authentication and integrity during
transport. The proof-of-identity is supplied by either the certificate
exchange during the TLS handshake or within the HTTP layer headers. The
message type along with control/error messages are included in the HTTP
headers.</t>
<t>The TLS and HTTP layer provided proof-of-identity means the <xref
format="default" target="RFC5272">CMC</xref> Section 3.1 note that "the
Simple PKI Request MUST NOT be used if a proof-of-identity needs to be
included" is not applicable and thus the Simple PKI message types are
used.</t>
<t>The TLS layer certificate exchange provides a method for authorizing
client enrollment requests using existing certificates. Such existing
certificates may have been issued by the CA (from which the client is
requesting a certificate) or they may have been issued under a distinct
PKI (e.g., an <xref target="IDevID">IEEE 802.1AR IDevID</xref>
credential).</t>
<t/>
<t>Proof-of-possession is a distinct issue from proof-of-identity and is
included in the Simple PKI message type as described in <xref
target="PoP"/>. A method of linking proof-of-identity and
proof-of-possession is described in <xref
target="IdentityLinkedPOP"/>.</t>
<t>This document also defines transport for <xref format="default"
target="RFC5272">CMC</xref> specification compliant with <xref
format="default" target="RFC5273">CMC Transport Protocols</xref>.</t>
<t>During the protocol operations various different certificates can be
used. The following table provides an informative overview. End-entities
MAY have one or more certificates of each type listed in <xref
target="FIGlayers3"/>:</t>
<figure anchor="FIGlayers3">
<artwork><![CDATA[Certificates/Trust-anchors and their corresponding uses:
+--------------+--------------------+-------------------------------+
| Certificate/ | Issuer | Use |
| TA database | | |
+==============+====================+===============================+
| EST server | The CA served by | Presented by the EST server |
| certificate | the EST server | during the TLS handshake |
| | | |
| | | Section: 3.3.1.1 |
+--------------+--------------------+-------------------------------+
| EST server | An unrelated CA | Presented by the EST server |
| certificate | e.g., a Web site | during the TLS handshake |
| | CA | |
| | | Section: 3.3.1.1 |
+--------------+--------------------+-------------------------------+
| EST client | Trust anchor for | EST clients use this |
| Trust Anchor | the CA issuing | trust anchor database to |
| Database | certificates. | authenticate certificates |
| | | issued by the CA, including |
| | | EST server certificates |
| | | Section 3.3.1.1 |
+--------------+--------------------+-------------------------------+
| EST client | Trust anchors for | EST clients can use this |
| third party | third party CAs | trust anchor database to |
| Trust Anchor | e.g., a list of | authenticate an EST server |
| Database | Web site CA root | that uses an externally |
| | certificates | issued certificate |
| | | Section: 3.3.1.1 |
+--------------+--------------------+-------------------------------+
| EST client | An unrelated CA | Presented by the EST client |
| certificate | e.g., a device | to the EST server by clients |
| | manufacturer | that have not yet enrolled |
| | | Section: 3.3.1.2 |
+--------------+--------------------+-------------------------------+
| EST client | The CA served by | Presented by the EST client |
| certificate | the EST server | to PKI End Entities. |
| | | Including to the EST server |
| | | during future EST operations |
| | | Section: 3.3.1.2 |
+--------------+--------------------+-------------------------------+
| EST client | The CA served by | Clients can obtain certs |
| certificate | the EST server | that can not be used for |
| | | EST authentication |
| | | (e.g., Key Encryption certs) |
| | | Section: 4.4.1 |
+--------------+--------------------+-------------------------------+
]]></artwork>
</figure>
<section anchor="ApplicationLayer" title="Application Layer Design">
<t>An EST client SHOULD have its own client certificate suitable for
TLS client authentication (e.g., the digitalSignature bit is set). The
client certificate, if available, MUST be used when authenticating to
the EST server. If a client does not have a certificate, then the
client MUST use HTTP Basic or Digest authentication credentials (see
<xref target="HTTPuserAuthCandAuthZ"/>). HTTP authentication provides
a bootstrap for clients that have not yet been issued a certificate.
EST clients obtaining a certificates for other protocol purposes are
RECOMMENDED to first obtain an appropriate certificate for use when
authenticating to the EST server.</t>
<t>The client also SHOULD also have a CA certificate that will be used
to authenticate the EST server.</t>
<t>An EST client MUST be capable of generating and parsing Simple PKI
messages (see <xref target="CertReq"/>). Generating and parsing Full
PKI messages is OPTIONAL (see <xref target="FullCMC"/>). The client
MUST also be able to request CA certificates from the EST server and
parse the returned "bag" of certificates (see <xref
target="CACerts"/>). Requesting CSR attributes and parsing the
returned list of attributes is OPTIONAL (see <xref
target="CSRAttrs"/>).</t>
<!--
<t>EST provides a small set of certificate management functions.
These are acquisition of CA certificates, enrollment or renewal of
client certifiates, and optional 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="CertReq"></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 transfer EST messages. URIs are provisioned for
handling each media type (i.e., message type) as described in <xref
target="HTTPURIs"/>. HTTP is also used for client authentication
services when TLS client authentication is not available due to lack
of a client certificate suitable for use by TLS, as detailed in
Section <xref target="HTTPuserAuthCandAuthZ"> </xref>. Registered
media types are used to convey EST messages as specified in <xref
target="MIMEtypes"/>.</t>
<t><xref target="RFC2616">HTTP 1.1</xref> and above support persistent
connections. As given in Section 8.1 of that RFC persistent
connections may be used to reduce network and processing load
associated with multiple HTTP requests. EST does not require or
preclude persistent HTTP connections and their use is out of scope of
this specification.</t>
<section anchor="HTTPheaders" title="HTTP headers for control">
<t>This document profiles the HTTP content-type header (as defined
in <xref target="RFC2046"/>, but see <xref target="MIMEtypes"/> for
specific values) to indicate the media type for EST messages and to
specify control messages for EST. The HTTP Status value is used to
communicate success or failure of EST functions Support for the HTTP
authentication methods is available for a client that does not have
a certificate. <vspace blankLines="1"/><xref format="none"
target="RFC5272">CMC</xref> uses the same messages for certificate
renewal and certificate rekey. This specification defines the
renewal and rekey behavior of both the client and server. It does so
by using the HTTP control mechanisms employed by the client and
server as opposed to using CMC. <vspace blankLines="1"/>Various
media types as indicated in the HTTP content-type header are used to
transfer EST messages. Media types used by EST are specified in
<xref target="MessageTypes"/>.</t>
</section>
<section anchor="HTTPURIs" title="HTTP URIs for control">
<t>This profile supports six operations indicated by specific
URIs:</t>
<figure anchor="OPERATIONtypes">
<artwork><![CDATA[
Operations and their corresponding URIs:
+------------------------+-----------------+-------------------+
| Operation |Operation Path | Details |
+========================+=================+===================+
| Distribution of CA | /CACerts | Section 4.3 |
| certificates (MUST) | | |
+------------------------+-----------------+-------------------+
| Enrollment of new | /simpleEnroll | Section 4.4 |
| clients (MUST) | | |
+------------------------+-----------------+-------------------+
| Re-Enrollment of | /simpleReEnroll | Section 4.4.1 |
| existing clients (MUST)| | |
+------------------------+-----------------+-------------------+
| Full CMC (OPTIONAL) | /fullCMC | Section 4.5 |
+------------------------+-----------------+-------------------+
| Server-side Key | /serverKeyGen | Section 4.6 |
| Generation (OPTIONAL) | | |
+------------------------+-----------------+-------------------+
| Request CSR attributes | /CSRAttrs | Section 4.7 |
| (OPTIONAL) | | |
+------------------------+-----------------+-------------------+
]]></artwork>
</figure>
<t/>
<t>An HTTP base path common for all of an EST server's requests is
defined in the form of an path-absolute (<xref target="RFC3986">
</xref>, section 3.3). The operation path (<xref
target="OPERATIONtypes"/> is appended to the base path to form the
URI used with HTTP GET or POST to perform the desired EST
operation.</t>
<t>An example:</t>
<t>With a base path of "/arbitrary/path" and an operation path of
"/CACerts", the EST client would combine them to form an absolute
path of "/arbitrary/path/CACerts". Thus, to retrieve the CA's
certificates, the EST client would use the following HTTP
request:</t>
<t/>
<figure title="">
<artwork><![CDATA[GET /arbitrary/path/CACerts HTTP/1.1]]></artwork>
</figure>
<t>Likewise, to request a new certificate in this example scheme,
the EST client would use the following request:</t>
<t/>
<figure title="">
<artwork><![CDATA[POST /arbitrary/path/simpleEnroll HTTP/1.1]]></artwork>
</figure>
<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 operation paths
simplifies implementation for servers that do not perform client
authentication when distributing /CACerts responses.</t>
<t>EST clients are provided with the base path URI of the EST
server. Potential methods of distributing the URI are discussed
within the Security Considerations (see <xref
target="SecurityConsiderations"/> and <xref
target="TLSserverAuthZ"/>).</t>
<t>An EST server MAY provide additional, services using other
URIs.</t>
<t>An EST server MAY use multiple base paths in order to provide
service for multiple CAs. Each CA would use a distinct base path,
but operations are otherwise the same as specified for an EST server
operating on behalf of only one CA.</t>
</section>
<section anchor="HTTPuserAuthCandAuthZ"
title="HTTP-Based Client Authentication">
<t>An EST server that has authenticated itself to the client MAY
request HTTP-based client authentication. This request can be in
addition to successful TLS client authentication (<xref
target="TLSclientAuthC"/>) if EST server policy requires additional
authentication (for example the EST server wishes to confirm the EST
client "knows" a password in addition to "having" an existing client
certificate). Or HTTP-based client authentication can be an EST
server policy specified fallback in situations where the EST client
did not successfully complete the TLS client authentication (for
example if the EST client is enrolling for the first time or the
existing EST client certificates can not be used for TLS client
authentication).</t>
<t>HTTP Basic and Digest authentication MUST only be performed over
<xref target="RFC4346">TLS 1.1</xref> (or later). 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 Basic and Digest authentication
methods.</t>
<t>Servers that wish to use Basic and Digest authentication reject
the HTTP request using the HTTP defined WWW-Authenticate
response-header (<xref format="default" target="RFC2616"/>, Section
14.47). At that point the client SHOULD repeat the request,
including the appropriate Authorization Request Header (<xref
target="RFC2617"/>, Section 3.2.2) if the client is capable of using
the Basic or Digest authentication. If the client is not capable
then the client MUST terminate the connection.</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>
<t>Support for HTTP-based client authentication has security
ramifications as discussed in <xref
target="SecurityConsiderations"/>. The client MUST NOT respond to
the server's HTTP authentication request unless the client has
authenticated the EST server (as per <xref
target="TLSserverAuthZ"/>).</t>
</section>
<section anchor="MessageTypes" title="Message types">
<t>This document uses existing media types for the messages as
specified by <xref target="RFC2585"/>, <xref target="RFC5967"/>, and
<xref target="RFC5272">CMC</xref>. To support distribution of
multiple certificates for the CA certificate chain, the <xref
target="RFC2046"/> multipart/mixed media type is used.</t>
<t>The message type is specified in the HTTP Content-Type header
with a media type. The use herein is consistent with <xref
target="RFC5273"/>.</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="CertReq"></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="CertReqResponse"></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 media types
are:</t>
<figure anchor="MIMEtypes">
<artwork><![CDATA[
+--------------------+--------------------------+-------------------+
| Message type |Request media type | Request section |
| |Response media type | Response section |
| |Source(s) of types | |
+====================+==========================+===================+
| CA certificate | N/A | Section 4.3 |
| request | application/pkcs7-mime | Section 4.3.1 |
| | [RFC5751] | |
+--------------------+--------------------------+-------------------+
| Cert enroll/renew/ | application/pkcs10 | Section 4.4/4.4.1 |
| rekey | application/pkcs7-mime | Section 4.4.2 |
| | [RFC5967] [RFC5751] | |
+--------------------+--------------------------+-------------------+
| Full CMC | application/pkcs7-mime | Section 4.5.1 |
| | application/pkcs7-mime | Section 4.5.2 |
| | [RFC5751] | |
+--------------------+--------------------------+-------------------+
| Server-side Key | application/pkcs10 | Section 4.6.1 |
| Generation | multipart/mixed | Section 4.6.2 |
| | (application/pkcs7-mime &| |
| | application/pkcs8) | |
| | [RFC5967] [RFC5751] | |
+--------------------+--------------------------+-------------------+
| Request CSR | N/A | Section 4.7.1 |
| attributes | application/csrattrs | Section 4.7.2 |
| | This RFC | |
+--------------------+--------------------------+-------------------+
]]></artwork>
</figure>
</section>
</section>
<section anchor="TLSLayer" title="TLS Layer Design">
<t>TLS provides communications security for the layers above it. The
integrity and authentication services it provides are leveraged to
supply proof-of-identity and to allow authorization decisions to be
made. The higher layer EST server and EST client are responsible for
ensuring that an acceptable cipher suite is used and that
bidirectional authentication has been established. Alternately,
certificate-less TLS authentication-- where neither the client nor
server present a certificate-- is also an acceptable method for EST
server and client authentication.</t>
<t>When the EST server uses a certificate for authentication, TLS
client authentication is the preferred method for identifying EST
clients. If the EST client does not yet have a suitable client
certificate the EST server can request HTTP Basic or Digest
authentication protected by the TLS encryption. Alternately,
certificate-less TLS authentication-- where neither the client nor
server present a certificate-- is also an acceptable method for EST
client authentication.</t>
<t>TLS channel binding information may be optionally inserted into a
certificate request as detailed in <xref target="IdentityLinkedPOP"/>
in order to provide the EST server with assurance that the
authenticated TLS client entity has possession of the private key for
the certificate being requested.</t>
<section anchor="AuthCandAuthZ" title="TLS for transport security">
<t>HTTPS <xref target="RFC2818"/> and specifies how HTTP messages
are carried over TLS. HTTPS MUST be used. TLS 1.1 <xref
target="RFC4346"/> (or later) SHOULD be supported. TLS session
resumption <xref target="RFC5077"/> SHOULD be supported.</t>
<section anchor="TLSserverAuthC"
title="TLS-Based Server Authentication">
<t>The EST client authenticates the EST server as appropriate for
the cipher suite negotiated. The following provides details
assuming the <xref target="RFC4346">TLS 1.1</xref> Section 9
Mandatory Cipher Suite TLS_RSA_WITH_3DES_EDE_CBC_SHA with a TLS
server certificate presented during the <xref target="RFC4346">TLS
1.1</xref> (or later) exchange-defined Server Certificate message.
As an alternative to authentication using a certificate, an EST
client MAY support certificate-less TLS authentication (<xref
target="TLSmutualAuth"/>).</t>
<t>Certificate validation MUST be performed as given in <xref
target="RFC5280"/> and <xref target="RFC6125"/>. The EST server
certificate MUST conform to the <xref target="RFC5280"/>
certificate profile.</t>
<t>The client validates the TLS server certificate using local
TAs, which may be in the form of certificates. If certificate
verification fails the client MAY follow the procedure outlined in
<xref target="BootstrapCACerts"/> for bootstrap distribution of CA
certificates.</t>
<t>The EST client MUST perform authorization checks as specified
in <xref target="TLSserverAuthZ"/>.</t>
</section>
<section anchor="TLSclientAuthC"
title="TLS-Based Client Authentication">
<t>The EST server MUST authenticate the EST client as appropriate
for the cipher suite negotiated. The following provides details
assuming the <xref target="RFC4346">TLS 1.1</xref> Section 9
Mandatory Cipher Suite TLS_RSA_WITH_3DES_EDE_CBC_SHA with a TLS
client certificate presented during the <xref target="RFC4346">TLS
1.1</xref> (or later) exchange-defined Client certificate message.
As an alternative to authentication using a certificate, an EST
server MAY support <xref target="TLSmutualAuth">certificate-less
TLS authentication.</xref></t>
<t>Clients SHOULD support <xref target="RFC4346"/>-defined (or
later) Certificate request (section 7.4.4). As required by <xref
target="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.</t>
<t>If a client does not support TLS client authentication, then it
MUST support <xref target="HTTPuserAuthCandAuthZ">HTTP-based
client authentication.</xref>.</t>
<t>The EST server MUST perform authorization checks as specified
in <xref target="ClientAuthorization"/>.</t>
</section>
<section anchor="TLSmutualAuth"
title="Certificate-less TLS Mutual Authentication">
<t>The client and server MAY negotiate a certificate-less cipher
suite for mutual authentication. When using certificate-less
mutual authentication in TLS for enrollment, the cipher suite MUST
be resistant to dictionary attack and MUST provide sufficient
information to perform the authorization checks. For example if
the cipher suite uses a pre-shared secret, provisioned in an
out-of-band fashion, as a credential to perform mutual
authentication then knowledge of the pre-shared secret implies
authorization as a peer in the exchange.</t>
</section>
</section>
</section>
<section anchor="PoP" title="Proof-of-Possession">
<t>As defined in Section 2.1 of <xref target="RFC5272">CMC</xref>,
Proof-of-possession (POP) "refers to a value that can be used to prove
that the private key corresponding to the public key is in the
possession and can be used by an end-entity."</t>
<t>The signed enrollment request provides a "Signature"-based
proof-of-possession. The mechanism described in <xref
target="IdentityLinkedPOP"/> strengthens this by optionally including
"Direct"-based proof-of-possession by including TLS session specific
information within the data covered by the enrollment request
signature (thus linking the enrollment request to the authenticated
end-point of the TLS connection).</t>
</section>
<section anchor="IdentityLinkedPOP"
title="Linking Identity and POP information">
<t>This specification provides an OPTIONAL method of linking identity
and proof-of-possession by including information specific to the
current authenticated TLS session within the signed certification
request. Clients MAY use this method as a result of client
configuration. If configuration is not possible the client can
determine that this method is required by parsing the error responses
or by examining the CSR Attributes Response (see <xref
target="CSRAttrsResp"/>).</t>
<t>Linking identity and proof-of-possession proves to the server that
the authenticated TLS client has possession of the private key
associated with the certification request and that the client was able
to sign the certification request after the TLS session was
established. This is an alternative to the <xref target="RFC5272"/>
Section 6.3-defined "Linking Identity and POP information" method
available if Full PKI messages are used.</t>
<t>The client generating the request obtains the tls-unique value as
defined in <xref target="RFC5929">Channel Bindings for TLS</xref> from
the TLS subsystem. The tls-unique specification includes a
synchronization issue as described in <xref target="RFC5929">Channel
Bindings for TLS</xref> section 3.1. To avoid this problem EST
implementations MUST use the tls-unique value from the first TLS
handshake. EST clients and servers use their tls-unique implementation
specific synchronization methods to obtain this first tls-unique
value. TLS "secure_renegotiation" <xref target="RFC5746"/> MUST be
used. This maintains the binding from the first tls-unique value
across renegotiations to the most recently negotiated connection.</t>
<t>The tls-unique value is Base 64 encoded as specified in Section 4
of <xref target="RFC4648"/> and the resulting string is placed in the
certification request challenge-password field (<xref
target="RFC2985"/>, Section 5.4.1). If tls-unique information is not
embedded within the certification request the challenge-password field
MUST be empty to indicate that the client did not include the optional
channel-binding information (any value submitted is verified by the
server as tls-unique information).</t>
<t>The EST server MUST verify the tls-unique information embedded
within the certification request according to server policy regarding
the authenticated client. If the EST server forwards the request to
back-end infrastructure for processing it is RECOMMENDED that the
results of this verification be communicated. (For example this
communication might use the <xref format="none"
target="RFC5272">CMC</xref> "RA POP Witness Control" in a CMC Full PKI
Request message or the back-end infrastructure might authenticate the
EST server as being a trusted infrastructure element that does not
forward invalid requests. A detailed discussion of back-end processing
is out of scope).</t>
<t>When rejecting requests the EST server response is as described for
all enroll responses (<xref target="CertReqResponse"/>). If a Full PKI
Response is included the CMCFailInfo MUST be set to popFailed. If a
human readable reject message is included it SHOULD include an
informative text message indicating that linking of identity and POP
information is required.</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
determines if it will accept services from the EST server. These
authorization decisions are described in the next two sections. Assuming
that both sides of the exchange are authorized, then the actual
operations are as described in the sections that follow.</t>
<!-- [[EDNOTE: 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="TLSserverAuthZ" title="Server Authorization">
<t>The client MUST check the EST server authorization before accepting
any server responses or responding to HTTP authentication
requests.</t>
<t>When the server authenticates with a certificate the client MUST
check the URI "against the server's identity as presented in the
server's Certificate message" (<xref target="RFC2818">HTTP Over TLS
Section 3.1 "Server Identity"</xref> and <xref target="RFC6125"/>).
The provisioned URI provides the authorization statement and the
server's authenticated identity confirms it is the authorized server.
Successful authentication using a certificate-less cipher suite
implies authorization of the server.</t>
<t>If the URI does not match the server identity check then the TLS
server certificate MUST contain the id-kp-cmcRA [CMC RFC6402] extended
key usage extension and the TLS server certificate MUST be issued by
the CA the EST server is providing services for.</t>
<t>The client MUST maintain the distinction between the EST specific
TA for the CA issuing certificates and the TAs for third party CAs in
order to make this determination (see, <xref
target="ProtocolDesignandLayering"/>).</t>
<t>If these checks fail then authorization of the EST server does not
occur except for as specified in <xref
target="BootstrapCACerts"/>.</t>
</section>
<section anchor="ClientAuthorization" title="Client Authorization">
<t>When the EST server receives a Simple PKI Request or rekey/renew
message, the decision to issue a certificate is always the CA's. The
EST server configuration reflects the CA policy and can use any data
it wishes in determining whether to issue the certificate (e.g. CSR
attributes, client identity, linking of client identity and
proof-of-possession, etc). The details are out-of-scope. EST provides
the EST server access to client's authenticated identity-- e.g. the
TLS client's certificate in addition to any HTTP user authentication
credentials-- to help in implementing configured policy.</t>
<t>If the client's authenticated certificate was issued by the EST
server CA and includes the id-kp-cmcRA <xref target="RFC6402"/>
extended key usage extension then the CA SHOULD apply policy
consistent with a client that is acting as an RA (such as policy to
support enrollment requests initiated either by the RA itself or by
clients that are in communication with the RA).</t>
</section>
<section anchor="CACerts" title="Distribution of CA certificates">
<t>The EST client can request a copy of the current CA certificates
and this function is generally performed before other EST
functions.</t>
<section anchor="CACertsReq"
title="Distribution of CA certificates request">
<t>EST clients MAY request TA information of the CA (in the form of
certificates) with an HTTPS GET message with an operation path of
"/CACerts". EST clients and servers MUST support the /CACerts
function. Clients SHOULD request an up-to-date response before
stored information has expired in order to maintain continuity of
trust.</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"/> and check the server's
authorization as given in <xref target="TLSserverAuthZ"/> or follow
the procedure outlined in <xref target="BootstrapCACerts"/>.</t>
</section>
<section anchor="BootstrapCACerts"
title="Bootstrap Distribution of CA certificates">
<t>If the TLS authentication or authorization fails then the client
MAY provisionally continue the TLS handshake to completion for the
purposes of accessing the /CACerts or /fullCMC method. If the EST
client continues with an unauthenticated connection the EST client
MUST extract the HTTP content data from the response (<xref
target="CACertsResp"/> or <xref target="FullCMCResp"/>) 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 <xref target="SHS"/>, or MD5 <xref
target="RFC1321"/> hash on the whole CA certificate). In a /fullCMC
response it is the Publish Trust Anchors control within the Full PKI
Response that must be accepted manually. It is incumbent on the end
user to properly verify the fingerprint or to provide valid
out-of-band data necessary to verify the fingerprint.</t>
<t>HTTP authentication requests MUST NOT be responded to since the
server is unauthenticated. The EST client uses the /CACerts response
to build the trust anchor for subsequent TLS server authentication.
EST clients MUST NOT make any other protocol exchange until after
the /CACerts response has been accepted and a new TLS session
established.</t>
</section>
<section anchor="CACertsResp"
title="Distribution of CA certificates response">
<t>The EST server responds to the client HTTPS GET request with an
HTTP GET response that includes CA trust anchor information, in the
form of certificates within the Simple PKI Response. If the
certificates are successfully returned, the server response MUST
have an HTTP 200 response code with a content-type of
"application/pkcs7-mime". Any other response code indicates an error
and the client should abort the protocol.</t>
<t>The EST server MUST include the current CA certificate in the
response. The EST server MUST include any additional certificates
the client would need to build a chain to the current root CA
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 to chain to the root CA are included in
this response.</t>
<t>If support for the CMP root certificate update mechanism is
provided by the CA then the server MUST include the three "Root CA
Key Update" certificates OldWithOld, OldWithNew, and NewWithOld.
These are defined in Section 4.4 of <xref format="default"
target="RFC4210">CMP</xref>.</t>
<t>The client can always find the current TA in the form of a
self-signed certificate by examining the received certificates. The
CA's most recent self signed certificate (e.g. NewWithNew
certificate) is self-signed and has the latest NotAfter date.</t>
<t>The most recent CA certificate is the certificate that is
extracted and authorized using out-of-band information as described
in <xref target="BootstrapCACerts"/>. After out-of-band validation
occurs each of the other certificates MUST be validated using normal
<xref target="RFC5280"/> certificate path validation (using the most
recent CA certificate as the TA) before they can be used to build
certificate paths during certificate validation.</t>
<t>The response format is the CMC Simple PKI Response as defined in
<xref target="RFC5272"/>. The HTTP content-type of
"application/pkcs7-mime" is used. The Simple PKI response is Base64
encoded, as specified in Section 4 of [RFC4648], and sandwiched
between headers:</t>
<t><figure>
<artwork><![CDATA[-----BEGIN PKCS7-----
MIIBhDCB7gIBADBFMQswCQYDVQQGEwJBVTETMBEGA1UECBMKU29tZS1TdGF0ZTEh
Simplified example of Base64 encoding of CMC Simple PKI Response
ED8rf3UDF6HjloiV3jBnpetx4JjZH/BlmD9HMqofVEryb1e4iZgMUvuIgwEjQwpD
8J4OhHvLh1o=
-----END PKCS7-----]]></artwork>
</figure></t>
</section>
</section>
<section anchor="CertReq" title="Client Certificate Request Functions">
<t>EST clients MAY request a certificate from the EST server with an
HTTPS POST using the operation path value of "/simpleEnroll". The EST
server MUST support the /simpleEnroll function. EST clients MAY
request a renew/rekey of existing certificates with an HTTP POST using
the operation path value of "/simpleReEnroll". The EST server SHOULD
support the /simpleReEnroll function.</t>
<t>The client is RECOMMENDED to have obtained the current CA
certificates using <xref target="CACerts"/> before performing
certificate request functions to ensure it can validate the EST server
certificate. The client MUST authenticate the EST server as specified
in <xref target="TLSserverAuthC"/>. The client MUST authorize the EST
server as specified in <xref target="TLSserverAuthZ"/>.</t>
<t>The server MUST check client authentication as specified in <xref
target="TLSclientAuthC"/>. The server MUST check client authorization
as specified in <xref target="ClientAuthorization"/>. The EST server
MUST check the tls-unique value as described in <xref
target="IdentityLinkedPOP"/>.</t>
<t>The server MAY accept the certificate request for manual
authorization by the administrator. (<xref target="CertReqResponse"/>
describes the use of an HTTP 202 response to the EST client if this
occurs).</t>
<section anchor="Enroll" title="Simple Enrollment of Clients">
<t>When HTTPS POSTing to /simpleEnroll the client MUST include a
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 Certification Request signature provides proof-of-possession
of the private key to the EST server. If the requested KeyUsage
extensions support digital signing operations then the certification
request signature MUST be generated using the private key
corresponding to the public key in the CertificationRequestInfo. If
the requested KeyUsage extensions do not allow for digital signing
operations the request MAY sign the certificate request, however the
private key MUST NOT be used to perform signature operations after
certificate issuance. The use of /fullCMC operations provides access
to more advanced proof-of-possession methods that SHOULD be used
when the keys are not available for digital signing operations. This
is consistent with the recommendations concerning submission of
proof-of-possession to an RA or CA as described in <xref
target="SP-800-57-Part-1"/>.</t>
<t>The HTTP content-type of "application/pkcs10" is used. The format
of the message is as specified in <xref target="RFC4945">Section 6.4
of </xref>.</t>
<t>The client MAY request an additional certificate even when using
an existing certificate in the TLS client authentication. For
example the client can use an existing signature certificate to
request a key exchange certificate.</t>
</section>
<section anchor="Re-enroll" title="Simple Re-Enrollment of Clients">
<t>EST clients renew/rekey certificates with an HTTPS POST using the
operation path value of "/simpleReEnroll". EST clients and server
MUST support the /simpleReEnroll function.</t>
<t>The certificate request is the same format as for the
"simpleEnroll" request with the same HTTP content-type. The request
Subject and SubjectAltName field(s) MUST contain the identity of the
certificate being renewed/rekeyed. The ChangeSubjectName attribute,
as defined in <xref target="RFC6402"/>, MAY be included in the
certificate request.</t>
<t>If the public key information in the certification request is the
same as the currently issued certificate the EST server performs a
renew operation. If the public key information is different than the
currently issued certificate then the EST server performs a rekey
operation. The specifics of these operations are out of scope of
this profile.</t>
</section>
<section anchor="CertReqResponse"
title="Simple Enroll and Re-Enroll Response">
<t>If the enrollment is successful, the server response MUST have an
HTTP 200 response code with a content-type of
"application/pkcs7-mime". The response data is a degenerate
certs-only Simple PKI Response containing only the certificate
issued. The Simple PKI response is Base64 encoded and sandwiched
between headers:</t>
<t><figure>
<artwork><![CDATA[-----BEGIN PKCS7-----
MIIBhDCB7gIBADBFMQswCQYDVQQGEwJBVTETMBEGA1UECBMKU29tZS1TdGF0ZTEh
Simplified example of Base64 encoding of CMC Simple PKI Response
ED8rf3UDF6HjloiV3jBnpetx4JjZH/BlmD9HMqofVEryb1e4iZgMUvuIgwEjQwpD
8J4OhHvLh1o=
-----END PKCS7-----]]></artwork>
</figure></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 PKI Response with an HTTP content-type of
"application/pkcs7-mime" (see <xref target="FullCMCResp"/>) 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 containing informative information
concerning why the request was rejected (for example indicating that
CSR attributes are incomplete). 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="default"
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="default" target="RFC2616">HTTP</xref>.</t>
<t>If the EST client has not obtained the current CA certificates
using <xref target="CACerts"/> then it may not be able to validate
the certificate received.</t>
</section>
</section>
<section anchor="FullCMC" title="Full CMC">
<t>EST clients can also request a certificate from the EST server with
an HTTPS POST using the operation path value of "/fullCMC". Support
for the /fullCMC function is OPTIONAL.</t>
<t>The client SHOULD authenticate the server as specified in <xref
target="TLSserverAuthC">Server Authentication</xref>. Bootstrap
distribution of CA certificates is specified in <xref
target="BootstrapCACerts"/>.</t>
<t>The server SHOULD authenticate the client as specified in <xref
target="AuthCandAuthZ"/>. The server MAY depend on CMC client
authentication methods instead.</t>
<section anchor="FullCMCReq" title="Full CMC Request">
<t>If the HTTP POST to /fullCMC is not a valid Full PKI Request, the
server MUST reject the message. The HTTP content-type used is
"application/pkcs7-mime", as specified in <xref
target="RFC5273"/>.</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"/>.
The response data includes either the Simple PKI Response or the
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" SHOULD be included in the response data
for any CMC error response. The client parses the CMC response to
determine the current status.</t>
<t>All other return codes are handled as specified in <xref
target="CertReqResponse"/> or <xref target="RFC2616">HTTP</xref>.
For example the client interprets a HTTP 404 or 501 response to
indicate that this service is not implemented.</t>
<t>The Full PKI Response is Base64 encoded and sandwiched between
headers:</t>
<t><figure>
<artwork><![CDATA[-----BEGIN PKCS7-----
MIIBhDCB7gIBADBFMQswCQYDVQQGEwJBVTETMBEGA1UECBMKU29tZS1TdGF0ZTEh
Simplified example of Base64 encoding of CMC Full PKI Response
ED8rf3UDF6HjloiV3jBnpetx4JjZH/BlmD9HMqofVEryb1e4iZgMUvuIgwEjQwpD
8J4OhHvLh1o=
-----END PKCS7-----]]></artwork>
</figure></t>
</section>
</section>
<section anchor="ServerKeyGen" title="Server-side Key Generation">
<t>[[EDNOTE: This section includes references
[draft-ietf-pkix-cmc-serverkeygeneration-00] which has not yet been
published.]]</t>
<t>EST clients request a "private" key and associated certificate from
the EST server with an HTTPS POST using the operation path value of
"/serverKeyGen". Support for the /serverKeyGen function is
OPTIONAL.</t>
<t>The client MUST authenticate the server as specified in <xref
target="TLSserverAuthC"/>. The EST client is RECOMMENDED to have
obtained the current CA certificates using <xref target="CACerts"/> to
ensure it can validate the EST server certificate.</t>
<t>The EST server MUST authenticate the client as specified in <xref
target="AuthCandAuthZ"/>. The server SHOULD use <xref format="title"
target="TLSclientAuthC"/> for authorization purposes. The EST server
applies whatever authorization or policy logic it chooses to determine
if the "private" key and certificate should be generated.</t>
<t>Proper random number and key generation <xref target="RFC4086"/> as
well as storage is a server implementation responsibility. The key
pair and certificate are transferred over the TLS session; the EST
server MUST verify that the current cipher suite is acceptable for
securing the key data.</t>
<section anchor="ServerKeyGenReq"
title="Server-side Key Generation Request">
<t>The certificate request is HTTPS POSTed and is the same format as
for the "/simpleEnroll" and "/simpeReEnroll" path extensions with
the same content-type.</t>
<t>The Subject and SubjectAltName field(s) or ChangeSubjectName
attribute in the request MAY, as can all fields in a CSR, be ignored
by the server as these are only requests. The server uses these
fields, along with the authenticated client identity and server
policy, to determine if it wishes to generate a new "private" key
when servicing the request or re-use an escrowed "private" key. The
client MAY request multiple keys and certificates.</t>
<t>In all respects the server SHOULD treat the request as it would
any enroll or re-enroll request; with the only distinction being
that the server MUST ignore the public key values of the certificate
request and the request signature. These are included in the request
only to allow re-use of existing codebases for generating and
parsing such requests.</t>
</section>
<section anchor="ServerKeyGenResp"
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. One part is the "private" key data and the
other part is the certificate data.</t>
<t>The "private" key data MAY be an "application/pkcs8" consisting
of the Base64 encoded DER-encoded PrivatekeyInfo sandwiched between
the headers as described in <xref target="RFC5958"/>. Alternatively
the "private" key data SHOULD be an "application/pkcs7-mime"
containing a CMS <xref target="RFC5652"/> message (also as described
in <xref target="RFC5958"/>). The content of this message is an
EncryptedData or EnvelopedData content type containing the binary
DER-encoded PrivatekeyInfo. The RecipientInfo MAY use any valid key
management technique as determined by server policy and
authenticated client identity. For example when the client uses a
TLS client certificate for authentication the server can use this as
the KeyTransRecipientInfo rid. The use of a CMS provides security to
the AsymmetricKeyPackage:</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 certificate data part is an "application/pkcs7-mime" and
exactly matches the certificate response to /simpleEnroll. If both
parts are "application/pkcs7-mime" the client checks each (one will
be a certs-only Simple PKI response and the other will be the CMS
message with the encrypted data).</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>Future work might define addtional certification request
attributes to communicate key management information in addition to
using the client's authenticated identity. Such attributes are
out-of-scope of this document.</t>
</section>
</section>
<section anchor="CSRAttrs" title="CSR Attributes">
<t>The CA MAY want to include client-provided attributes in
certificates that it issues and some of these attributes may describe
information that is not available to the CA. For this reason, the EST
client MAY request a set of attributes from the EST server to include
in its certification request.</t>
<section anchor="CSRAttrsReq" title="CSR Attributes Request">
<t>The EST Client MAY request a list of CA-desired CSR attributes
from the CA by sending an HTTPS GET message to the EST server with
an operations path of "/CSRAttrs". Clients SHOULD request such a
list if they have no a priori knowledge of what attributes are
desired by the CA in an enrollment request or when dictated by
policy.</t>
</section>
<section anchor="CSRAttrsResp" title="CSR Attributes Response">
<t>If policy for the authenticated EST client indicates a CSR
Attributes Response will be provided the server response MUST have
an HTTP 200 response code. An HTTP response code of 204 or 404
indicates that a CSR Attributes Response is not available.
Regardless of the response code the EST server and CA MAY reject any
subsequent enrollment requests for any reason, including incomplete
CSR attributes in the request.</t>
<t>Responses to attribute request messages MUST be encoded as
content type "application/csrattrs". The syntax for
application/csrattrs body is as follows:</t>
<t>Csrattrs ::= SEQUENCE SIZE (0..MAX) OF OBJECT IDENTIFIER { }</t>
<t>Servers include zero or more object identifiers that they wish
the client to include in their certification request. When the
server encodes Csrattrs as an empty SEQUENCE it means that the
server has no specific additional attributes it wants in the client
certification requests (this is functionally equivalent to an HTTP
response code of 204 or 404). The sequence is DER (preferred) or BER
encoded and then base64 encoded (section 4 of [RFC4648]). The
resulting text forms the application/csrattr body, without
headers.</t>
<t>For example, if a CA wishes the authenticated client to submit a
certification request containing the MAC address <xref
target="RFC2397"/> of a device and the challengePassword (indicating
that Linking of Identity and POP information is requested, see <xref
target="IdentityLinkedPOP"/>) it takes the following object
identifiers: <list hangIndent="4" style="symbols">
<t>macAddress: 1.3.6.1.1.1.1.22</t>
<t>challengePassword: 1.2.840.113549.1.9.7</t>
</list> and encodes them into an ASN.1 SEQUENCE to produce: <list
hangIndent="4" style="empty">
<t>30 14 06 07 2B 06 01 01 01 01 16 06 09 2A 86 48 86 F7 0D 01
09 07</t>
</list> and then base64 encodes the resulting ASN.1 SEQUENCE to
produce: <list hangIndent="4" style="empty">
<t>MBQGBysGAQEBARYGCSqGSIb3DQEJBw==</t>
</list> The EST client parses the response OID's and handles each
OID independently on a best effort basis. When an OID indicates a
known CSR attribute type the client SHOULD include that CSR
attribute in the subsequent CSR submitted, either in the CSR
attributes or in any other appropriate CSR field. When an OID is of
an unknown type the OID MAY be ignored by the client.</t>
</section>
</section>
</section>
<!-- Possibly a 'Contributors' section ... -->
<!-- To be moved to another document
<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"/>, 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"/> 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"/> 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>IANA is requested to register the following:</t>
<t>IANA SHALL update the Application Media Types registry with the
following filled-in template from <xref target="RFC4288"/>.</t>
<t>The media subtype for Attributes in a CertificationRequest is
application/csrattrs. <list hangIndent="4" style="empty">
<t>Type name: application</t>
<t>Subtype name: csrattrs</t>
<t>Required parameters: None</t>
<t>Optional parameters: None</t>
<t>Encoding considerations: binary;</t>
<t>Security Considerations:</t>
</list></t>
<t><list hangIndent="6" style="empty">
<t>Clients request a list of attributes that servers wish to be in
certification requests. The request/response SHOULD be done in a
TLS-protected tunnel.</t>
</list></t>
<t><list hangIndent="4" style="empty">
<t>Interoperability considerations: None</t>
<t>Published specification: This memo.</t>
<t>Applications which use this media type:</t>
<t>Enrollment over Secure Transport (EST)</t>
<t>Additional information:</t>
</list></t>
<t><list hangIndent="6" style="empty">
<t>Magic number(s): None</t>
<t>File extension: None</t>
<t>Macintosh File Type Code(s):</t>
</list></t>
<t><list hangIndent="4" style="empty">
<t>Person & email address to contact for further
information:</t>
<t>Dan Harkins <dharkins@arubanetworks.com></t>
<t>Restrictions on usage: None</t>
<t>Author: Dan Harkins <dharkins@arubanetworks.com></t>
<t>Intended usage: COMMON</t>
<t>Change controller: The IESG</t>
</list></t>
</section>
<section anchor="SecurityConsiderations" title="Security Considerations">
<t>Support for Basic authentication as specified in <xref
format="default" 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. Use of a PIN or one-time-password can help
mitigate concerns but EST clients are RECOMMENDED to use such
credentials only once to obtain an appropriate client certificate to be
used during future interactions with the EST server.</t>
<t>When the client uses a third party trust anchor database for
certificate validation (see <xref target="ProtocolDesignandLayering"/>)
then authorization proceeds as specified in <xref
target="TLSserverAuthZ"/>. 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-in PKI hierarchy. Possible avenues for an attack could be
an erroneous URI injected into the client via an initial configuration
method, or the server could have compromised a third party trust anchor
to obtain an apparently valid server certificate. Clients using a third
party trust anchor database are RECOMMENDED to only use TLS-based client
authentication (to prevent leaking HTTP-based Client Authentication
information). Such clients are RECOMMENDED to include "Linking Identity
and POP information" (<xref target="IdentityLinkedPOP"/>) in requests
(to minimize the chance that such requests could be proxied to the real
EST server). Additionally it is RECOMMENDED that the third party trust
anchor database available for EST server authentication be carefully
constructed (to reduce the risk of improperly managed third party
CAs).</t>
<t/>
<t>When using a certificate-less TLS cipher suite, the shared secret
used for authentication and authorization MUST be known only to the two
parties to the exchange-- the client and the server. Any sharing of
secrets completely voids the security afforded by a certificate-less
cipher suite. Exposure of a shared secret used by a certificate-less
cipher suite to a third party enables client impersonation that can
results in corruption of a client's trust anchor database.</t>
<t>Any certificate-less TLS cipher suite used with EST MUST be resistant
to dictionary attack. This means that the advantage an adversary gains
through attack MUST be related to interaction and not computation.
Certificate-less TLS cipher suites used with EST MUST also be based on a
zero knowledge protocol to enable proof of knowledge of the shared
secret without exposure of the shared secret (or any derived data which
can be used to determine the secret). These requirements mean that the
adversary gains advantage solely through active attack and the only
thing learned from each active attack is whether a single guess of the
secret is successful or not. Implementations of EST that support
certificate-less TLS cipher suites SHOULD provide countermeasures-- for
example, exponential back off after failed attempts or locking of an
account after a certain number of unsuccessful attempts-- to mitigate
repeated active attacks.</t>
<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 proof-of-possession to the TLS proof-of-identity by enforcing
that the POP operation occured while the TLS session is active. This
strongly implies to the server that it is the authenticated client that
has possession of the private key. If client authentication indicates a
client with specific known behaviour this implication is strengthened
but not proven.</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. Use of a third
party trust anchor database is NOT RECOMMENDED for server-side key
generation. The use of an encrypted CMS Server-side Key Generation
Response is RECOMMENDED. </t>
<t>Regarding the CSR attributes that the CA may list for inclusion in an
enrollment request, there are no real inherent security issues with the
content being conveyed but an adversary who is able to interpose herself
into the conversation could exclude attributes that a server may want,
include attributes that a server may not want, and render meaningless
other attributes that a server may want.</t>
<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">
&RFC1321;
&RFC2046;
&RFC2119;
&RFC2314;
&RFC2585;
&RFC2616;
&RFC2617;
&RFC2818;
&RFC2985;
&RFC2986;
&RFC3986;
&RFC4086;
&RFC4210;
&RFC4288;
&RFC4346;
&RFC4648;
&RFC4945;
&RFC5077;
&RFC5246;
&RFC5272;
&RFC5273;
&RFC5274;
&RFC5280;
&RFC5652;
&RFC5746;
&RFC5929;
&RFC5958;
&RFC5967;
&RFC6125;
&RFC6402;
<reference anchor="SHS"
target="http://csrc.nist.gov/publications/fips/fips180-4/fips-180-4.pdf">
<front>
<title>Federal Information Processing Standard Publication 180-4:
Secure Hash Standard (SHS)</title>
<author fullname=""
surname="National Institute of Standards and Technology">
<organization abbrev="NIST">National Institute of Standards and
Technology</organization>
</author>
<date month="March" year="2012"/>
</front>
</reference>
<reference anchor="X.680"
target="http://www.itu.int/rec/T-REC-X.680-200811-I/en">
<front>
<title>ITU-T Recommendation X.680 Abstract Syntax Notation One
(ASN.1): Specification of basic notation</title>
<author fullname="" surname="ITU-T Recommendation">
<organization abbrev="ITU-T">International Telecommunication Union
Telecommunication Standardization Sector</organization>
</author>
<date month="November" year="2008"/>
</front>
</reference>
<reference anchor="X.690"
target="http://www.itu.int/rec/T-REC-X.690-200811-I/en">
<front>
<title>ITU-T Recommendation X.690 ASN.1 encoding rules:
Specification of Basic Encoding Rules (BER), Canonical Encoding
Rules (CER) and Distinguished Encoding Rules (DER)</title>
<author fullname="" surname="ITU-T Recommendation">
<organization abbrev="ITU-T">International Telecommunication Union
Telecommunication Standardization Sector</organization>
</author>
<date month="November" year="2008"/>
</front>
</reference>
</references>
<references title="Informative References">
&RFC2397;
&RFC2925;
&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="IEEE">IEEE</organization>
</author>
<date month="December" year="2009"/>
</front>
</reference>
<reference anchor="X.520"
target="http://www.itu.int/rec/T-REC-X.520-200811-I/en">
<front>
<title>ITU-T Recommendation X.520 The Directory: Selected attribute
types</title>
<author fullname="" surname="ITU-T Recommendation">
<organization abbrev="ITU-T">International Telecommunication Union
Telecommunication Standardization Sector</organization>
</author>
<date month="November" year="2008"/>
</front>
</reference>
<reference anchor="SP-800-57-Part-1"
target="http://csrc.nist.gov/publications/nistpubs/800-57/sp800-57_part1_rev3_general.pdf">
<front>
<title>Recommendation for Key Management - Part 1: General (Revision
3)</title>
<author fullname=""
surname="National Institute of Standards and Technology">
<organization abbrev="NIST">National Institute of Standards and
Technology</organization>
</author>
<date month="July" year="2012"/>
</front>
</reference>
</references>
<section title="Operational Scenario Example Messages">
<t>(informative)</t>
<t>This section expands on the Operational Scenario Overviews by
providing detailed examples of the messages at each TLS layer.</t>
<section title="Obtaining CA Certificates">
<t>The following is an example of a valid /CACerts exchange.</t>
<t>During the initial TLS handshake the client can ignore the optional
server generated "certificate request" and can instead proceed with
the HTTP GET request:</t>
<t><figure>
<artwork><![CDATA[GET /CACerts HTTP/1.1
User-Agent: curl/7.24.0 (i686-pc-linux-gnu) libcurl/7.24.0 OpenS
SL/0.9.8b zlib/1.2.3 libidn/0.6.5
Host: 127.0.0.1:8085
Accept: */* ]]></artwork>
</figure></t>
<t>In response the server provides the current CA certificate:</t>
<figure>
<artwork><![CDATA[<= Recv header, 38 bytes (0x26)
Content-Type: application/pkcs7-mime
== Info: no chunk, no close, no size. Assume close to signal end
<= Recv header, 2 bytes (0x2)
<= Recv data, 1111 bytes (0x457)
-----BEGIN PKCS7-----.MIIDEQYJKoZIhvcNAQcCoIIDAjCCAv4CAQExADALBg
kqhkiG9w0BBwGgggLkMIIC.4DCCAcigAwIBAgIJAOjxMZcXhE5wMA0GCSqGSIb3D
QEBBQUAMBcxFTATBgNVBAMT.DGVzdEV4YW1wbGVDQTAeFw0xMjA3MDQxODM5Mjda
Fw0xMzA3MDQxODM5MjdaMBcx.FTATBgNVBAMTDGVzdEV4YW1wbGVDQTCCASIwDQY
JKoZIhvcNAQEBBQADggEPADCC.AQoCggEBALQ7SjZSt6qrnBzUnBNj9z4oxYkvMA
Vh0OIOVRkNhz/2kDGsds0ne7cw.W33kYlxPba4psdLMixCT/O8ZQMpgA+QFKtwb9
VPE8EFUgGzxSYHQHjhJsbg0BVaN.Ya38vjKMjvosuSXUHwkvU57SInSkMr3/aNtS
T8qFfeC6Vuf/G/GLHGuHQKAy/DSo.206MjaMNmWYRVQQVErGookRA4GBF/YE+G/C
SlTsCQNE0KyBFz8JWIkgYY2gYkxb7.wWMvvhaU/Esp+2DG92v9Dhs2MRgrR+WPs7
Y6CYOLD5Mr5lEdkHg27IxkSAoRrI6D.fnVVEQGCj7QrrsUgfXFVYv6cCWFfhMcCA
wEAAaMvMC0wDAYDVR0TBAUwAwEB/zAd.BgNVHQ4EFgQUhH9KxW5TsjkgL7kg2kxJ
yy5tD/MwDQYJKoZIhvcNAQEFBQADggEB.AD+vydZo292XFb2vXojdKD57Gv4tKVm
hvXRdVInntzkY/0AyFCfHJ4BwndgtMh4t.rvBD8+8dL+W3jfPjcSCcUQ/JEnFuMn
b5+kivLeqOnUshETasFPBz2Xq4C1sHDno9.CWOcsjPPw08Tn4dSrzDBSq1NdXB2z
9NOpaVnbpb01qQGhXSOaEvcbZcDuGiW7Di3.gV++remokuPph/s6XoZffzc7ZVzf
Job6tS4RwNz01sutPybXiRWivOz7+QeCOT87.nTGlkQH/+RImUyJ2jefjAW/GDFT
Pzek6cZnabAtsg32n0Pv0j0/1RTNSdYGxPIVA.2f9fhMqMz+vm3w4CFNkGZnOhAD
EA.-----END PKCS7-----.
]]></artwork>
</figure>
</section>
<section title="Previously Installed Signature Certificate">
<t>The following is an example of a valid /simpleEnroll exchange.
During this exchange the EST client uses an existing certificate
issued by a trusted 3rd party PKI to obtain an initial certificate
from the EST server.</t>
<t>During the initial TLS handshake the server generated "certificate
request" includes both the distinguished name of the CA the EST server
provides services for ("estExampleCA") and it includes the
distinguished name of a trusted 3rd party CA ("estEXTERNALCA"):</t>
<t/>
<figure>
<artwork><![CDATA[0d 00 00 3d 03 01 02 40 00 37 00 1a 30 18 31 16 ...=...@.7..0.1.
30 14 06 03 55 04 03 13 0d 65 73 74 45 58 54 45 0...U....estEXTE
52 4e 41 4c 43 41 00 19 30 17 31 15 30 13 06 03 RNALCA..0.1.0...
55 04 03 13 0c 65 73 74 45 78 61 6d 70 6c 65 43 U....estExampleC
41 A
Which decodes as:
Acceptable client certificate CA names
/CN=estEXTERNALCA
/CN=estExampleCA
]]></artwork>
</figure>
<t>The EST client provides a certificate issued by "estEXTERNALCA" in
the certificate response and the TLS handshake proceeds to completion.
The EST server accepts the EST client certificate for authentication
and accepts the EST client's POSTed certificate request:</t>
<figure>
<artwork><![CDATA[POST /simpleEnroll HTTP/1.1
User-Agent: curl/7.24.0 (i686-pc-linux-gnu) libcurl/7.24.0 OpenS
SL/0.9.8b zlib/1.2.3 libidn/0.6.5
Host: 127.0.0.1:8085
Accept: */*
Content-Type: application/pkcs10
Content-Length: 952
=> Send data, 952 bytes (0x3b8)
-----BEGIN CERTIFICATE REQUEST-----.MIIChjCCAW4CAQAwQTElMCMGA1UE
AxMccmVxIGJ5IGNsaWVudCBpbiBkZW1vIHN0.ZXAgNjEYMBYGA1UEBRMPUElEOld
pZGdldCBTTjo2MIIBIjANBgkqhkiG9w0BAQEF.AAOCAQ8AMIIBCgKCAQEAwhYyI+
aYezyx+kW0GVUbMKLf2BUd8BgGykkIJYxms6SH.Bv5S4ktcpYbEpR9iCmp96vK6a
Ar57ArZtMmi0Y6eLX4c+njJnYhUeTivnfyfMM5d.hNVwyzKbJagm5f+RLTMfp0y0
ykqrfZ1hFhcNrRzF6mJeaORTHBehMdu8RXcbmy5R.s+vjnUC4Fe3/oLHtXePyYv1
qqlkk0XDrw/+lx0y4Px5tiyb84iPnQOXjG2tuStM+.iEvfpNAnwU0+3GDjl3sjx0
+gTKvblp6Diw9NSaqIAKupcgWsA0JlyYkgPiJnXFKL.vy6rXoOyx3wAbGKLrKCxT
l+RH3oNXf3UCH70aD758QIDAQABoAAwDQYJKoZIhvcN.AQEFBQADggEBADwpafWU
BsOJ2g2oyHQ7Ksw6MwvimjhB7GhjweCcceTSLInUMk10.4E0TfNqaWcoQengMVZr
IcbOb+sa69BWNB/WYIULfEtJIV23/g3n/y3JltMNw/q+R.200t0bNAViijHQHmlF
6dt93tkRrTzXnhV70Ijnff08G7P9HfnXQH4Eiv3zOB6Pak.JoL7QlWQ+w5vHpPo6
WGH5n2iE+Ql76F0HykGeqaR402+ae0WlGLHEvcN9wiFQVKh.KUHteU10SEPijlqf
QW+hciLleX2CwuZY5MqKb4qqyDTs4HSQCBCl8jR2cXsGDuN4.PcMPp+9A1/UPuGD
jhwPt/K3y6aV8zUEh8Ws=.-----END CERTIFICATE REQUEST-----.]]></artwork>
</figure>
<t>The EST server uses the trusted 3rd party CA issued certificate to
perform additional authorization and issues a certificate to the
client:</t>
<figure>
<artwork><![CDATA[<= Recv header, 38 bytes (0x26)
Content-Type: application/pkcs7-mime
== Info: no chunk, no close, no size. Assume close to signal end
<= Recv header, 2 bytes (0x2)
<= Recv data, 1200 bytes (0x4b0)
-----BEGIN PKCS7-----.MIIDUQYJKoZIhvcNAQcCoIIDQjCCAz4CAQExADALBg
kqhkiG9w0BBwGgggMkMIID.IDCCAgigAwIBAgIBBjANBgkqhkiG9w0BAQUFADAXM
RUwEwYDVQQDEwxlc3RFeGFt.cGxlQ0EwHhcNMTIwNzA0MTgzOTM3WhcNMTMwNzA0
MTgzOTM3WjBBMSUwIwYDVQQD.ExxyZXEgYnkgY2xpZW50IGluIGRlbW8gc3RlcCA
2MRgwFgYDVQQFEw9QSUQ6V2lk.Z2V0IFNOOjYwggEiMA0GCSqGSIb3DQEBAQUAA4
IBDwAwggEKAoIBAQDCFjIj5ph7.PLH6RbQZVRswot/YFR3wGAbKSQgljGazpIcG/
lLiS1ylhsSlH2IKan3q8rpoCvns.Ctm0yaLRjp4tfhz6eMmdiFR5OK+d/J8wzl2E
1XDLMpslqCbl/5EtMx+nTLTKSqt9.nWEWFw2tHMXqYl5o5FMcF6Ex27xFdxubLlG
z6+OdQLgV7f+gse1d4/Ji/WqqWSTR.cOvD/6XHTLg/Hm2LJvziI+dA5eMba25K0z
6IS9+k0CfBTT7cYOOXeyPHT6BMq9uW.noOLD01JqogAq6lyBawDQmXJiSA+ImdcU
ou/Lqteg7LHfABsYousoLFOX5Efeg1d./dQIfvRoPvnxAgMBAAGjTTBLMAkGA1Ud
EwQCMAAwHQYDVR0OBBYEFJv4oLLeNxNK.OMmQDDujyNR+zaVPMB8GA1UdIwQYMBa
AFIR/SsVuU7I5IC+5INpMScsubQ/zMA0G.CSqGSIb3DQEBBQUAA4IBAQCMdomfdR
9vi4VUYdF+eym7F8qVUG/1jtjfaxmrzKeZ.7LQ1F758RtwG9CDu2GPHNPjjeM+DJ
RQZN999eLs3Qd/DIJCNimaqdDqmkeBFC5hq.LZOxbKhSmhlR7YKjIZuyI299rOaI
W54ULyz8k0zw6R1/0lMJTsDFGJM+9yDeaARE.n3vtKnUDGHsVU3fYpDENaqUunoU
MZfuEdejfHhU7lVbJI1oSJbnRwBFkPr/RQ3/5.FymcrBD9RpAM5MsQIn0BONil/o
JM+LjOJqyZLbBxz6P3w/OiJGYJNfFT8YudLfjZ.LDX8A8FFcReapNELC4QxE4OrA
hN3sQUT2O7ndIsit4kJoQAxAA==.-----END PKCS7-----.]]></artwork>
</figure>
</section>
<section title="Username/Password Distributed Out-of-Band">
<t>The following is an example of a valid /simpleEnroll exchange.
During this exchange the EST client uses an out-of-band distributed
username/password to authenticate itself to the EST server.</t>
<t>During the initial TLS handshake the client can ignore the optional
server generated "certificate request" and can instead proceed with
the HTTP POST request:</t>
<figure>
<artwork><![CDATA[POST /simpleEnroll HTTP/1.1
User-Agent: curl/7.24.0 (i686-pc-linux-gnu) libcurl/7.24.0 OpenS
SL/0.9.8b zlib/1.2.3 libidn/0.6.5
Host: 127.0.0.1:8085
Accept: */*
Content-Type: application/pkcs10
Content-Length: 952
=> Send data, 952 bytes (0x3b8)
-----BEGIN CERTIFICATE REQUEST-----.MIIChjCCAW4CAQAwQTElMCMGA1UE
AxMccmVxIGJ5IGNsaWVudCBpbiBkZW1vIHN0.ZXAgMjEYMBYGA1UEBRMPUElEOld
pZGdldCBTTjoyMIIBIjANBgkqhkiG9w0BAQEF.AAOCAQ8AMIIBCgKCAQEAz9lXz9
MowulOx0W5v1k7GKlsNy7mAgmkz/wZDImBDXez.QZCb8lrO8iTD3tI0NH2xpkY3b
uqFjdtQTzCmANLyNWtR1sC5GjN/EM1JSCrO/zZM.ig835RXJTP878N/jNW7EzSxb
/zK5OzKJoRbZ4HgZm4NDapMfMcB4jqBdPxoPAqeR.+KTkv1+9m1vvsdKIs5Hm4Sp
O2WolHPw5BCXdu5zleb6ACih7Zpd2cpHFz6ZHC0G1.Of+F//0BzkFSqWsmUomyJy
WCfLCuX9grs1CNlLxw0gcMprdTxLxjc18z03ZmBCq0.qq5/mUK/tv9R2k8+WuP3a
kzTUIkeHtcp6FVFl3D+TwIDAQABoAAwDQYJKoZIhvcN.AQEFBQADggEBAJH7Etuy
B/oQgQeals08mD2U31FfQ/uYqjNxzZpZJSzVLGMASv9a.pNzaWdfqPdIs+ZZ+gAQ
QkVcXjdbqY3pAf/EeWk+KnuAUjOIPKu3ZBPVbWbXu/Ie7.F1ekQ7TLkFNkHSxHRu
2/bPIByBLRVfWNVXd3wPq+QxqMqgIjBGaTJM5kuHndYFGj.Xdf4rlGRPyOOwG/Xf
QrKBB3tzpbJCy+cwOUAJFPOTO+86RUjf9Wh+yoM182vlg8O.FyEaaA/PMpl3aEcT
BlRZmPx4e7FLwGIhbgE7/6K0nF99xdGd7JYPHasbcWszxD0Z.oPYm+44g0gOnhlj
OWpRiKXcnngSSutRILaw=.-----END CERTIFICATE REQUEST-----.
== Info: upload completely sent off: 952 out of 952 bytes
== Info: HTTP 1.1 or later with persistent connection, pipelining
supported
]]></artwork>
</figure>
<t>The EST server accepts this request but since a client certificate
was not provided for authentication/authorization the EST server
responds with the WWW-authenticate header:</t>
<figure>
<artwork><![CDATA[<= Recv header, 27 bytes (0x1b)
HTTP/1.1 401 Unauthorized
<= Recv header, 75 bytes (0x4b)
WWW-Authenticate: Digest qop="auth", realm="estrealm", nonce="13
41427174"]]></artwork>
</figure>
<t>The EST client repeats the request, this time including the
requested Authorization header:</t>
<figure>
<artwork><![CDATA[== Info: SSL connection using AES256-SHA
== Info: Server certificate:
== Info: subject: CN=127.0.0.1
== Info: start date: 2012-07-04 18:39:27 GMT
== Info: expire date: 2013-07-04 18:39:27 GMT
== Info: common name: 127.0.0.1 (matched)
== Info: issuer: CN=estExampleCA
== Info: SSL certificate verify ok.
== Info: Server auth using Digest with user 'estuser'
=> Send header, 416 bytes (0x1a0)
POST /simpleEnroll HTTP/1.1
Authorization: Digest username="estuser", realm="estrealm", nonc
e="1341427174", uri="/simpleEnroll", cnonce="ODc0OTk2", nc=00000
001, qop="auth", response="48a2b671ccb6596adfef039e134b7d5d"
User-Agent: curl/7.24.0 (i686-pc-linux-gnu) libcurl/7.24.0 OpenS
SL/0.9.8b zlib/1.2.3 libidn/0.6.5
Host: 127.0.0.1:8085
Accept: */*
Content-Type: application/pkcs10
Content-Length: 952
=> Send data, 952 bytes (0x3b8)
-----BEGIN CERTIFICATE REQUEST-----.MIIChjCCAW4CAQAwQTElMCMGA1UE
AxMccmVxIGJ5IGNsaWVudCBpbiBkZW1vIHN0.ZXAgMjEYMBYGA1UEBRMPUElEOld
pZGdldCBTTjoyMIIBIjANBgkqhkiG9w0BAQEF.AAOCAQ8AMIIBCgKCAQEAz9lXz9
MowulOx0W5v1k7GKlsNy7mAgmkz/wZDImBDXez.QZCb8lrO8iTD3tI0NH2xpkY3b
uqFjdtQTzCmANLyNWtR1sC5GjN/EM1JSCrO/zZM.ig835RXJTP878N/jNW7EzSxb
/zK5OzKJoRbZ4HgZm4NDapMfMcB4jqBdPxoPAqeR.+KTkv1+9m1vvsdKIs5Hm4Sp
O2WolHPw5BCXdu5zleb6ACih7Zpd2cpHFz6ZHC0G1.Of+F//0BzkFSqWsmUomyJy
WCfLCuX9grs1CNlLxw0gcMprdTxLxjc18z03ZmBCq0.qq5/mUK/tv9R2k8+WuP3a
kzTUIkeHtcp6FVFl3D+TwIDAQABoAAwDQYJKoZIhvcN.AQEFBQADggEBAJH7Etuy
B/oQgQeals08mD2U31FfQ/uYqjNxzZpZJSzVLGMASv9a.pNzaWdfqPdIs+ZZ+gAQ
QkVcXjdbqY3pAf/EeWk+KnuAUjOIPKu3ZBPVbWbXu/Ie7.F1ekQ7TLkFNkHSxHRu
2/bPIByBLRVfWNVXd3wPq+QxqMqgIjBGaTJM5kuHndYFGj.Xdf4rlGRPyOOwG/Xf
QrKBB3tzpbJCy+cwOUAJFPOTO+86RUjf9Wh+yoM182vlg8O.FyEaaA/PMpl3aEcT
BlRZmPx4e7FLwGIhbgE7/6K0nF99xdGd7JYPHasbcWszxD0Z.oPYm+44g0gOnhlj
OWpRiKXcnngSSutRILaw=.-----END CERTIFICATE REQUEST-----.]]></artwork>
</figure>
<t>The ESTserver uses the username/password to perform
authentication/authorization and responds with the issued
certificate:</t>
<figure>
<artwork><![CDATA[<= Recv header, 38 bytes (0x26)
0000: Content-Type: application/pkcs7-mime
== Info: no chunk, no close, no size. Assume close to signal end
<= Recv header, 2 bytes (0x2)
<= Recv data, 1200 bytes (0x4b0)
-----BEGIN PKCS7-----.MIIDUQYJKoZIhvcNAQcCoIIDQjCCAz4CAQExADALBg
kqhkiG9w0BBwGgggMkMIID.IDCCAgigAwIBAgIBAjANBgkqhkiG9w0BAQUFADAXM
RUwEwYDVQQDEwxlc3RFeGFt.cGxlQ0EwHhcNMTIwNzA0MTgzOTM0WhcNMTMwNzA0
MTgzOTM0WjBBMSUwIwYDVQQD.ExxyZXEgYnkgY2xpZW50IGluIGRlbW8gc3RlcCA
yMRgwFgYDVQQFEw9QSUQ6V2lk.Z2V0IFNOOjIwggEiMA0GCSqGSIb3DQEBAQUAA4
IBDwAwggEKAoIBAQDP2VfP0yjC.6U7HRbm/WTsYqWw3LuYCCaTP/BkMiYENd7NBk
JvyWs7yJMPe0jQ0fbGmRjdu6oWN.21BPMKYA0vI1a1HWwLkaM38QzUlIKs7/NkyK
DzflFclM/zvw3+M1bsTNLFv/Mrk7.MomhFtngeBmbg0Nqkx8xwHiOoF0/Gg8Cp5H
4pOS/X72bW++x0oizkebhKk7ZaiUc./DkEJd27nOV5voAKKHtml3ZykcXPpkcLQb
U5/4X//QHOQVKpayZSibInJYJ8sK5f.2CuzUI2UvHDSBwymt1PEvGNzXzPTdmYEK
rSqrn+ZQr+2/1HaTz5a4/dqTNNQiR4e.1ynoVUWXcP5PAgMBAAGjTTBLMAkGA1Ud
EwQCMAAwHQYDVR0OBBYEFChDQpKEfG9c.e4JaMf8438tb2XOIMB8GA1UdIwQYMBa
AFIR/SsVuU7I5IC+5INpMScsubQ/zMA0G.CSqGSIb3DQEBBQUAA4IBAQAn42mIVG
piaY4yqFD0F8KyUhKsdNnyKeeISQxP//lp.quIieJzdWSc7bhWZNldSzNswCod8B
4eJToQejLSNb8JBDC849z0tcuyHgN6N/p8z.IwI+hAlfXS9q02OECyFes4Jmzc7r
erE5jtOdGsEDBIscw/A+Kv86wv6BKbagMslQ.51AJyPsL6iBhm7LPFrErJgH2kWN
jDKFH9CcVFjXvgriMrLPFeqQWOpj/2XF+4m+c.f9QP5tSjieHJR1hnYk2tlodfE7
iV4pJ07Mmf3yBf753VSUVybqWiMCd0Lm7oghSX.E2GAxrsU1N+N1odn+gJ2wmxTu
AC2aHt9VPRViov4RRTvoQAxAA==.-----END PKCS7-----.]]></artwork>
</figure>
<t/>
</section>
<section title="Re-Enrollment">
<t>The following is an example of a valid /simpleReEnroll exchange.
During this exchange the EST client authenticates itself using an
existing certificate issued by the CA the EST server provides services
for.</t>
<t>Initially this exchange is identical to enrollment using an
externally issued certificate for client authentication since the
server is not yet aware of the client's intention. As in that example
the EST server the server generated "certificate request" includes
both the distinguished name of the CA the EST server provides services
for ("estExampleCA") and it includes the distinguished name of a
trusted 3rd party CA ("estEXTERNALCA").</t>
<figure>
<artwork><![CDATA[0d 00 00 3d 03 01 02 40 00 37 00 1a 30 18 31 16 ...=...@.7..0.1.
30 14 06 03 55 04 03 13 0d 65 73 74 45 58 54 45 0...U....estEXTE
52 4e 41 4c 43 41 00 19 30 17 31 15 30 13 06 03 RNALCA..0.1.0...
55 04 03 13 0c 65 73 74 45 78 61 6d 70 6c 65 43 U....estExampleC
41 A
In text format this is:
Acceptable client certificate CA names
/CN=estEXTERNALCA
/CN=estExampleCA
]]></artwork>
</figure>
<t>The EST client provides a certificate issued by "estExampleCA" in
the certificate response and the TLS handshake proceeds to completion.
The EST server accepts the EST client certificate for authentication
and accepts the EST client's POSTed certificate request.</t>
<t>The rest of the protocol traffic is effectively identical to a
normal enrollment.</t>
</section>
<section title="Server Key Generation">
<t>The following is an example of a valid /serverKeyGen exchange.
During this exchange the EST client authenticates itself using an
existing certificate issued by the CA the EST server provides services
for.</t>
<t>The initial TLS handshake is identical to the enrollment example
handshake. The HTTP POSTed message is:</t>
<figure>
<artwork><![CDATA[POST /serverKeyGen HTTP/1.1
User-Agent: curl/7.24.0 (i686-pc-linux-gnu) libcurl/7.24.0 OpenS
SL/0.9.8b zlib/1.2.3 libidn/0.6.5
Host: 127.0.0.1:8085
Accept: */*
Content-Type: application/pkcs10
Content-Length: 968
=> Send data, 968 bytes (0x3c8)
-----BEGIN CERTIFICATE REQUEST-----.MIICkzCCAXsCAQAwTjEyMDAGA1UE
AxMpc2VydmVyS2V5R2VuIHJlcSBieSBjbGll.bnQgaW4gZGVtbyBzdGVwIDUxGDA
WBgNVBAUTD1BJRDpXaWRnZXQgU046NTCCASIw.DQYJKoZIhvcNAQEBBQADggEPAD
CCAQoCggEBAMnlUlq0ag/fDAVhLgrXEAD6WtZw.Y2rVGev5saWirer2n0OzghB59
uJByxPo0DYBYqZRuoRF0FTL1ZZTMaZxivge0ecA.ZcoR46jwSBoceMT1jkwFyAER
t9Q2EwdnJLIPo/Ib2PLJNb4Jo8NNKmxtg55BgIVi.vkIB+rMtLeYRUVL0RUaBAqX
FmtXRDceVFIEY24iUQw6vESGJKpArht592aT8lyaP.24bZovuG19dd5xtTX3j37K
x49SlkUvLSpD6ZavIFAZn7Yv19LBKHvRIemybUo294.QeLb/VYP1O+EAthV/igiX
1DHqlUZCZp5SdyUXUwZPatFboNwEVR0R3MJwVECAwEA.AaAAMA0GCSqGSIb3DQEB
BQUAA4IBAQAqhHezK5/tvbXleHO/aTBVYO9l414NM+WA.wJcnS2UaJYScPBqlYK/
gij+dqAtFE+5ukAj56t7HnooI4EFo9r8jqCHewx7iLZYh.JDxo4hWOsAvHV+Iziy
jkhJNdHBIqGM7Gd5f/2VJLEPQPmwNOL5P+2O4eQC/QeEYc.bAmfhOS8b/ZH09/9T
PeaeQpjspjOui/100OuLE8KvU3FM0sXMYt1Va0A0jxzl+5k.EiEJo+ltXsQwdP0H
csoTNBN+j3K18omJQS0e91X8v0xkMWYhUtonXD0YZ6SO/B9c.AE6GTADHA/xpSvA
cqlWa+FHxjwEMXdmViHvMUywo31fDZ/TUvCPX.-----END CERTIFICATE REQUE
ST-----.
]]></artwork>
</figure>
<t>After processing the request the EST server response is:</t>
<figure>
<artwork><![CDATA[<= Recv header, 17 bytes (0x11)
HTTP/1.1 200 OK
<= Recv header, 16 bytes (0x10)
Status: 200 OK
<= Recv header, 67 bytes (0x43)
Content-Type: multipart/mixed ; boundary=estServerExampleBoundar
y
== Info: no chunk, no close, no size. Assume close to signal end
<= Recv header, 2 bytes (0x2)
<= Recv data, 3234 bytes (0xca2)
This is the preamble. It is to be ignored, though it.is a handy
place for estServer to include an explanatory note.including con
tact or support information..--estServerExampleBoundary.Content-
Type=application/pkcs8..-----BEGIN PRIVATE KEY-----.MIIEvQIBADAN
BgkqhkiG9w0BAQEFAASCBKcwggSjAgEAAoIBAQC0781l7tri0yii.Mb9ZZYch8ze
izXrjMPF/Rxoz2C9IU2THCrhPGXGQMne/zivce0m8/BMkkUc+DsSM.tzxn4l+9tI
sVDkAe4FyzN0hLd/zawgj6kUoCi3mxZnb2rWaRYAmM5w41ImDV3blv.aMUKDSJhV
bQ+z/G1W1TRx3iWi5CMHYb+1pJXPTJz/GuWr/b/+Efqwz2ZlwGcj4Dx.Igbx9vG0
mftIIxM4TUX28KBbaLgJbalsiuOx3C2bEyaSPerdzqgvXFHGGAhg1FU8.DQiQEki
nn66GPMtm1SNgitxFxWouFqpsax5MWn/i52TfEaF2PNThOuzKtilweJhk.g0gMIQ
TXAgMBAAECggEANlrz8XNX/lxBELixK0H83o4aYKYqDKZfZkUN8hU33xpu.Y/0sc
VbLbu46WzysoIfJFyUC+zFJnbMCCOPjGbI/4NWkEqc9TAlKz+wDo+hf5bf0.ypFr
EmikHk8R3fkpnvKi69ldw0iYnqcFVhq7VtGrSmJcy6Hckwbk7EBoUZGL0wtp.xlO
6XlhksAvn8+75qoWzsNhi7S/L0IVCVLbUaV3hodTHlH5M4daFbqyRWD7UiPKt.Q3
hdw1rpyVZg8ZbBFp0Ej4f9GdRaq88SIKMKCDu3t9ibn/v1kEte+PxhuwyW+d0o.h
kKSEW0yLKCzQm5tujsPq0UVzPBkLJACUnFAi+a4AQKBgQDu6VLH2eYoTjPPTyAv.
vOJnNWP7oMzyJ4/eFqdE9m+2Ajm/0qaMY95ftZ+GpEKggvC6Z5DFevEmgH4Sg2+G
.gFd93diyRPScVbNE8SmpXxLPU2UoykVmICuQZzLDNE18B3buxAm2GJ219NEnZOe
c.jPMOV/IcG1aLzTqQssL3zo/0gQKBgQDB4Olpg3EBggtJ/+dlkLHUw8c7Pe3UyL
kS.VxVsyQwioYt8xMeCWuPvPNFcOjcW53KN/YSpCVjpttKGsPtLibMlKYKgasEqg
cvl.Vb5OFtA/jNAP3mdAgCzBn6IF1NhVQe2dclo5puZ0gO38HDWq7EtqSi9Q0JSM
g3YC.QNcOORptVwKBgQCHrCafaYWDhA11/+g2U9x6Yd56ifF43rCbnV+2EQCVaqQ
i49xC.w4AH+Bs0mdlgT5unL6MOEmgZxkRR/SP7TKzixHYHnpMOqLhaQV24Wk5TQH
ek92D7.wu8aXRB9vBj4g0CuDNO6/jWpm/KenXXN+Fka3ySVg4zdbVmBzJJdqYckg
QKBgFXS.zSBzGgwz1/F7AaDZK49m1wPnhyeBb0OqHwbX/LI71rZ1mWef+nSF9Juh
/Y77B5/J.UPdO9vgGgS00nRk0LIRP2s5OU5IQgQTVLvf8a1UmbVgI+KX511Yi5yM
ztEwRcjEX.VM9ejXeXN0I57pvqG/xCOK3Kl2eYLh4TO9/E8WjjAoGAA1mqUV4Hnf
4yvF1rydMp.fpvoWekiiRE33iEbYZNATYhsl7uxwn760pqVifkq2DSrZeYm4+lw9
jwWMtUoPzpg.CJYMoGl846nhiZrbbJ5b5twoLV6GRmkk/CfOxPXNzCtSoQA86HHq
7rRdhXSau/bY.EXc91tnhLjFzZxdBgrd+f4k=.-----END PRIVATE KEY-----.
--estServerExampleBoundary.Content-Type: application/pkcs7-mime.
.-----BEGIN PKCS7-----.MIIDPAYJKoZIhvcNAQcCoIIDLTCCAykCAQExADALB
gkqhkiG9w0BBwGgggMPMIID.CzCCAfOgAwIBAgIBBTANBgkqhkiG9w0BAQUFADAX
MRUwEwYDVQQDEwxlc3RFeGFt.cGxlQ0EwHhcNMTIwNzA0MTgzOTM2WhcNMTMwNzA
0MTgzOTM2WjAsMSowKAYDVQQD.EyFzZXJ2ZXJzaWRlIGtleSBnZW5lcmF0ZWQgcm
VzcG9uc2UwggEiMA0GCSqGSIb3.DQEBAQUAA4IBDwAwggEKAoIBAQC0781l7tri0
yiiMb9ZZYch8zeizXrjMPF/Rxoz.2C9IU2THCrhPGXGQMne/zivce0m8/BMkkUc+
DsSMtzxn4l+9tIsVDkAe4FyzN0hL.d/zawgj6kUoCi3mxZnb2rWaRYAmM5w41ImD
V3blvaMUKDSJhVbQ+z/G1W1TRx3iW.i5CMHYb+1pJXPTJz/GuWr/b/+Efqwz2Zlw
Gcj4DxIgbx9vG0mftIIxM4TUX28KBb.aLgJbalsiuOx3C2bEyaSPerdzqgvXFHGG
Ahg1FU8DQiQEkinn66GPMtm1SNgitxF.xWouFqpsax5MWn/i52TfEaF2PNThOuzK
tilweJhkg0gMIQTXAgMBAAGjTTBLMAkG.A1UdEwQCMAAwHQYDVR0OBBYEFLylcQN
0D5xTfRdayv+0GDULR2+EMB8GA1UdIwQY.MBaAFIR/SsVuU7I5IC+5INpMScsubQ
/zMA0GCSqGSIb3DQEBBQUAA4IBAQButIeM.DB9PkwlGGe7zqvUWVD8y99zowwV6A
rAOXWX+JO0bihgMtZaUfvPCX/LhZVEKDAki.W5orjAEvIu10b6l38ZzX2oyJgkYy
Mmbb14lzTsRyjiqFw9j1PXxwgZvhwcaCF4b7.eDUUBQIeZg3AnkQrEwnHR5oVIN5
8qo0P7PSKC3Vl3H6DlQh3y7w87nN12923/wk0.v/bS3lv7lDX3HdmbQD1r2KPtBs
JGF4jMdstT7FTx32ZFKObycbK7WJ4LHytNJDci.4iXf+B0S3D6Zbf1cXj80/W+jC
GvU0+4SV3cgEXFE5VQvXd8x40W4h0dTSkQCDPOS.nPj4Dl/PsLqX3lDboQAxAA==
.-----END PKCS7-----.--estServerExampleBoundary--.This is the ep
ilogue. It is also to be ignored..
In text format this is:
HTTP/1.1 200 OK
Status: 200 OK
Content-Type: multipart/mixed ; boundary=estServerExampleBoundary
This is the preamble. It is to be ignored, though it
is a handy place for estServer to include an explanatory note
including contact or support information.
--estServerExampleBoundary
Content-Type=application/pkcs8
-----BEGIN PRIVATE KEY-----
MIIEvQIBADANBgkqhkiG9w0BAQEFAASCBKcwggSjAgEAAoIBAQC0781l7tri0yii
Mb9ZZYch8zeizXrjMPF/Rxoz2C9IU2THCrhPGXGQMne/zivce0m8/BMkkUc+DsSM
tzxn4l+9tIsVDkAe4FyzN0hLd/zawgj6kUoCi3mxZnb2rWaRYAmM5w41ImDV3blv
aMUKDSJhVbQ+z/G1W1TRx3iWi5CMHYb+1pJXPTJz/GuWr/b/+Efqwz2ZlwGcj4Dx
Igbx9vG0mftIIxM4TUX28KBbaLgJbalsiuOx3C2bEyaSPerdzqgvXFHGGAhg1FU8
DQiQEkinn66GPMtm1SNgitxFxWouFqpsax5MWn/i52TfEaF2PNThOuzKtilweJhk
g0gMIQTXAgMBAAECggEANlrz8XNX/lxBELixK0H83o4aYKYqDKZfZkUN8hU33xpu
Y/0scVbLbu46WzysoIfJFyUC+zFJnbMCCOPjGbI/4NWkEqc9TAlKz+wDo+hf5bf0
ypFrEmikHk8R3fkpnvKi69ldw0iYnqcFVhq7VtGrSmJcy6Hckwbk7EBoUZGL0wtp
xlO6XlhksAvn8+75qoWzsNhi7S/L0IVCVLbUaV3hodTHlH5M4daFbqyRWD7UiPKt
Q3hdw1rpyVZg8ZbBFp0Ej4f9GdRaq88SIKMKCDu3t9ibn/v1kEte+PxhuwyW+d0o
hkKSEW0yLKCzQm5tujsPq0UVzPBkLJACUnFAi+a4AQKBgQDu6VLH2eYoTjPPTyAv
vOJnNWP7oMzyJ4/eFqdE9m+2Ajm/0qaMY95ftZ+GpEKggvC6Z5DFevEmgH4Sg2+G
gFd93diyRPScVbNE8SmpXxLPU2UoykVmICuQZzLDNE18B3buxAm2GJ219NEnZOec
jPMOV/IcG1aLzTqQssL3zo/0gQKBgQDB4Olpg3EBggtJ/+dlkLHUw8c7Pe3UyLkS
VxVsyQwioYt8xMeCWuPvPNFcOjcW53KN/YSpCVjpttKGsPtLibMlKYKgasEqgcvl
Vb5OFtA/jNAP3mdAgCzBn6IF1NhVQe2dclo5puZ0gO38HDWq7EtqSi9Q0JSMg3YC
QNcOORptVwKBgQCHrCafaYWDhA11/+g2U9x6Yd56ifF43rCbnV+2EQCVaqQi49xC
w4AH+Bs0mdlgT5unL6MOEmgZxkRR/SP7TKzixHYHnpMOqLhaQV24Wk5TQHek92D7
wu8aXRB9vBj4g0CuDNO6/jWpm/KenXXN+Fka3ySVg4zdbVmBzJJdqYckgQKBgFXS
zSBzGgwz1/F7AaDZK49m1wPnhyeBb0OqHwbX/LI71rZ1mWef+nSF9Juh/Y77B5/J
UPdO9vgGgS00nRk0LIRP2s5OU5IQgQTVLvf8a1UmbVgI+KX511Yi5yMztEwRcjEX
VM9ejXeXN0I57pvqG/xCOK3Kl2eYLh4TO9/E8WjjAoGAA1mqUV4Hnf4yvF1rydMp
fpvoWekiiRE33iEbYZNATYhsl7uxwn760pqVifkq2DSrZeYm4+lw9jwWMtUoPzpg
CJYMoGl846nhiZrbbJ5b5twoLV6GRmkk/CfOxPXNzCtSoQA86HHq7rRdhXSau/bY
EXc91tnhLjFzZxdBgrd+f4k=
-----END PRIVATE KEY-----
--estServerExampleBoundary
Content-Type: application/pkcs7-mime
-----BEGIN PKCS7-----
MIIDPAYJKoZIhvcNAQcCoIIDLTCCAykCAQExADALBgkqhkiG9w0BBwGgggMPMIID
CzCCAfOgAwIBAgIBBTANBgkqhkiG9w0BAQUFADAXMRUwEwYDVQQDEwxlc3RFeGFt
cGxlQ0EwHhcNMTIwNzA0MTgzOTM2WhcNMTMwNzA0MTgzOTM2WjAsMSowKAYDVQQD
EyFzZXJ2ZXJzaWRlIGtleSBnZW5lcmF0ZWQgcmVzcG9uc2UwggEiMA0GCSqGSIb3
DQEBAQUAA4IBDwAwggEKAoIBAQC0781l7tri0yiiMb9ZZYch8zeizXrjMPF/Rxoz
2C9IU2THCrhPGXGQMne/zivce0m8/BMkkUc+DsSMtzxn4l+9tIsVDkAe4FyzN0hL
d/zawgj6kUoCi3mxZnb2rWaRYAmM5w41ImDV3blvaMUKDSJhVbQ+z/G1W1TRx3iW
i5CMHYb+1pJXPTJz/GuWr/b/+Efqwz2ZlwGcj4DxIgbx9vG0mftIIxM4TUX28KBb
aLgJbalsiuOx3C2bEyaSPerdzqgvXFHGGAhg1FU8DQiQEkinn66GPMtm1SNgitxF
xWouFqpsax5MWn/i52TfEaF2PNThOuzKtilweJhkg0gMIQTXAgMBAAGjTTBLMAkG
A1UdEwQCMAAwHQYDVR0OBBYEFLylcQN0D5xTfRdayv+0GDULR2+EMB8GA1UdIwQY
MBaAFIR/SsVuU7I5IC+5INpMScsubQ/zMA0GCSqGSIb3DQEBBQUAA4IBAQButIeM
DB9PkwlGGe7zqvUWVD8y99zowwV6ArAOXWX+JO0bihgMtZaUfvPCX/LhZVEKDAki
W5orjAEvIu10b6l38ZzX2oyJgkYyMmbb14lzTsRyjiqFw9j1PXxwgZvhwcaCF4b7
eDUUBQIeZg3AnkQrEwnHR5oVIN58qo0P7PSKC3Vl3H6DlQh3y7w87nN12923/wk0
v/bS3lv7lDX3HdmbQD1r2KPtBsJGF4jMdstT7FTx32ZFKObycbK7WJ4LHytNJDci
4iXf+B0S3D6Zbf1cXj80/W+jCGvU0+4SV3cgEXFE5VQvXd8x40W4h0dTSkQCDPOS
nPj4Dl/PsLqX3lDboQAxAA==
-----END PKCS7-----
--estServerExampleBoundary--
This is the epilogue. It is also to be ignored. ]]></artwork>
</figure>
<t/>
</section>
<section title="CSR Attributes ">
<t>The following is an example of a valid /CSRAttrs exchange. During
this exchange the EST client authenticates itself using an existing
certificate issued by the CA the EST server provides services for.</t>
<t>The initial TLS handshake is identical to the enrollment example
handshake. The HTTP GET request:</t>
<figure>
<artwork><![CDATA[GET /CSRAttrs HTTP/1.1
User-Agent: curl/7.22.0 (i686-pc-linux-gnu) libcurl/7.22.0 OpenS
SL/1.0.1 zlib/1.2.3.4 libidn/1.23 librtmp/2.3
Host: 127.0.0.1:8085
Accept: */*]]></artwork>
</figure>
<t/>
<t>In response the server provides suggested attributes that are
appropriate for the authenticated client:</t>
<figure>
<artwork><![CDATA[<= Recv header, 36 bytes (0x24)
Content-Type: application/csrattrs
== Info: no chunk, no close, no size. Assume close to signal end
<= Recv header, 2 bytes (0x2)
<= Recv data, 33 bytes (0x21)
0000: MBQGBysGAQEBARYGCSqGSIb3DQEJBw==.]]></artwork>
</figure>
<t/>
</section>
</section>
<!--
v00 2009-04-13 MCP Initial version
-->
</back>
</rfc>
| PAFTECH AB 2003-2026 | 2026-04-22 22:15:06 |