One document matched: draft-ietf-pkix-est-04.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 RFC2712 SYSTEM "http://xml.resource.org/public/rfc/bibxml/reference.RFC.2712.xml">
<!ENTITY RFC2818 SYSTEM "http://xml.resource.org/public/rfc/bibxml/reference.RFC.2818.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 RFC3394 SYSTEM "http://xml.resource.org/public/rfc/bibxml/reference.RFC.3394.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 RFC4108 SYSTEM "http://xml.resource.org/public/rfc/bibxml/reference.RFC.4108.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 RFC5054 SYSTEM "http://xml.resource.org/public/rfc/bibxml/reference.RFC.5054.xml">
<!ENTITY RFC5077 SYSTEM "http://xml.resource.org/public/rfc/bibxml/reference.RFC.5077.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 RFC5785 SYSTEM "http://xml.resource.org/public/rfc/bibxml/reference.RFC.5785.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-04" 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="2013"/>
<!-- 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
certificates 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 Transport Layer Security (TLS) 1.1 <xref
target="RFC4346"/> (or a later version) and Hypertext Transfer Protocol
(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 a client
device. It performs several functions traditionally allocated to the PKI
role of the Registration Authority (RA). The nature of communication
between an EST server and a CA is not described in this document.</t>
<t>EST adopts the Certificate Management Protocol (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 requesting Certificate Signing Request attributes
and requests for server-generated keys, are defined in this
document.</t>
<t>EST specifies how to transfer messages securely via HTTP over TLS
(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 Datagram Transport Layer
Security/User Datagram Protocol (DTLS/UDP). <xref target="FIGlayers"/>
shows how the layers build upon each other. <figure anchor="FIGlayers">
<artwork><![CDATA[
EST Layering:
Protocols:
+--------------------------------------------+
| |
| EST 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 Public Key Cryptography Standard (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="RFC4346"/>.</t>
<t>In addition to the terms defined in the terminology section of CMC
<xref target="RFC5272"/> the following terms are defined for reading
clarity:</t>
<t><list style="hanging">
<t hangText="EST CA:">The CA the EST server is providing services
for that ultimately services requests accepted by the EST server.
This term is introduced for readability. The actual CA may be a
member of a complex PKI or it may be a simple embedded CA.</t>
<t hangText="Third-Party Trust Anchor (TA):">Any Trust Anchor that
is not authoritative for the PKI hierarchy the EST server is
providing services for. For example TAs commonly used by web
browsers to authenticate web servers. The trust model for these
TAs is different from the trust model for Absolute Trust Anchors.
(See more details in <xref target="TLSserverAuthZ"/> and <xref
target="SecurityConsiderations"/>.)</t>
<t hangText="Absolute Trust Anchor:">Any Trust Anchor that is
authoritative for the PKI hierarchy the EST server is providing
services for or that is specifically designated as providing trust
for the EST server. An EST client gives these TAs absolute
precedence over Third-Party TAs when selecting a TA to validate a
certificate.</t>
<t hangText="Certificate-less TLS:">Use of a TLS cipher suite in
which neither the client nor server use a certificate to
authenticate. The credential used for authentication is a word,
phrase, code or key that is shared between the client and server.
The credential must be uniquely shared between the client and
server in order to provide authentication of an individual
client.</t>
</list></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 RFC 2119 key words.</t>
<t>Both the EST clients and server are configured with information that
provides the basis for bidirectional authentication and for
authorization. The specific initialization data depends on the methods
available in the client device and server, but can include shared
secrets, network service names and locations (e.g., a Uniform Resource
Identifier (URI) <xref target="RFC3986"/>), trust anchor information
(e.g., a CA certificate or a hash of a TA's certificate), and enrollment
keys and certificates. Depending on an enterprise's acquisition and
network management practices, some initialization may be performed by
the vendor prior to delivery of client hardware and software. In that
case, the client device vendor may provide data, such as trust anchors,
to the enterprise via a secure procedure. The distribution of this
initial information is out of scope.</t>
<t>Distribution of trust anchors and other certificates can be effected
via the EST server. However, nothing can be inferred about the
authenticity of this data until an out-of-band mechanism is used to
verify them.</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). Sections 2.1-2.6, below, enumerate the set of EST
functions (see <xref target="OPERATIONtypes"/>) and provide an
informative overview of EST's capabilities.</t>
<!--
XXX - need to format following paragraph to break at colon and each
XXX - following line. Following lines are indented one stop as well.
XXX - use <vspace blankLines="0"/> for the breaks?
-->
<t>The general client/server interaction proceeds as follows: The client
device initiates a TLS-secured HTTP session with an EST server. A
specific EST service is requested based on a portion of the URI used for
the session. The client device and server authenticate each other. The
client verifies that the server is authorized to serve this client. The
server verifies that the client is authorized to make use of this server
and the request that the client has made. The server acts upon the
client request.</t>
<section title="Obtaining CA Certificates">
<t>The EST client can request a copy of the current CA certificates
under which the EST server's end-entity certificate has issued.
(Throughout this document we assume that a CA may have a certificate
used to verify signed objects issued by the CA, e.g., certificates and
certificate revocation lists (CRLs), and a separate end-entity (EE)
certificate used when communication with the CA requires encryption.)
The EST client is assumed to perform this operation before performing
other operations.</t>
<t>The EST client authenticates and verifies the authorization scope
of the EST server when requesting the current CA certificate(s). As
detailed in <xref target="TLSserverAuthC"/> and <xref
target="TLSmutualAuth"/>) 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 a current
CA certificate.</t>
<t>For bootstrapping, the EST client can rely upon 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 (for itself) 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"/>, <xref
target="TLSmutualAuth"/> and <xref target="ClientAuthorization"/>. The
methods described in the normative text that are discussed in this
overview include:</t>
<t><list style="symbols">
<t>TLS with a previously issued client certificate (e.g., an
existing certificate issued by the EST CA);</t>
<t>TLS with a previously installed certificate (e.g., manufacturer
installed certificate or a certificate issued by some other
party);</t>
<t>Certificate-less TLS (e.g., with a shared credential
distributed out-of-band);</t>
<t>HTTP-based with a username/password distributed
out-of-band.</t>
</list></t>
<section title="Certificate TLS authentication">
<t>If the EST client has a previously installed certificate issued
by a third party CA, this certificate can be used to authenticate
the client's request for a certificate from the EST server's CA (if
that CA is recognized by the EST server). An EST client responds to
the EST server's TLS certificate request message with the existing
certificate already held by the client. The EST server will verify
the client's existing certificate and authorize the client's request
as described in <xref target="TLSclientAuthC"/>.</t>
</section>
<section title="Certificate-less TLS authentication">
<t>The EST client can be authenticated using a certificate-less TLS
ciphersuite. An appropriate ciphersuite will also authenticate the
EST server to the EST client—i.e. it performs mutual
authentication (see <xref target="TLSmutualAuth"/>).</t>
</section>
<section anchor="HTTPclientauthreasons"
title="HTTP-based client authentication">
<!-- -->
<t>If the EST client cannot be authenticated during the TLS
handshake (see <xref target="TLSclientAuthC"/>), or if the EST
server requires additional authentication information, the EST
server can optionally also request that the EST client submit a
username/password using the HTTP Basic or Digest Authentication
methods. See <xref target="HTTPuserAuthCandAuthZ"/>.</t>
</section>
</section>
<section title="Client Certificate Re-issuance">
<t>An EST client can renew/rekey its existing client certificate by
submitting a re-enrollment request to an EST server.</t>
<t>When the current EST client certificate can be used for TLS client
authentication (<xref target="TLSclientAuthC"/>) the client presents
this certificate to the EST server for client authentication. When the
to be re-issued EST client certificate cannot be used for TLS client
authentication any of the authentication methods used for initial
enrollment can be used.</t>
<t>For example if the client has an alternative certificate issued by
the EST CA that can be used for TLS client authentication then it can
be used.</t>
<t>The certification request message includes the same Subject and
SubjectAltName as the current certificate with name changes handled as
specified in <xref target="Re-enroll"/>.</t>
</section>
<section title="Server Key Generation">
<t>The EST client can request a server-generated certificate and key
pair (see <xref target="ServerKeyGen"/>).</t>
</section>
<section title="Full PKI Request messages">
<t>Full PKI Request <xref target="RFC5272"/> messages can be
transported via EST using the Full CMC Request function. This affords
access to functions not provided by the Simple Enrollment functions.
Full PKI Request messages are defined in Sections 3.2 and 4.2 of <xref
target="RFC5272"/>. See <xref target="FullCMC"/> for a discussion of
how EST provides a transport for these functions.</t>
</section>
<section title="Certificate Signing Request (CSR) Attributes Request">
<t>Prior to sending an enrollment request to an EST server, an EST
client can query the EST server for a set of additional attribute(s)
that the client is requested to use in a subsequent enrollment
request.</t>
<t>These attributes can be requests for additional descriptive
information that the server does not have access to, e.g., the MAC
address of an interface, or they can be indicative of the kind of
enrollment request to make, e.g., a specific elliptic curve that the
client is expected to generate a public/private key pair with, or a
specific hash function that the client is expected to use when
generating the CSR.</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 (OPTIONAL) |
| |
+---------------------------------------------------+
| |
| TLS for transport security |
| - Authentication of the EST server |
| - Authentication of the EST client (OPTIONAL) |
| - Provides communications integrity |
| and confidentiality |
| - Channel Binding [RFC5929] to link |
| proof-of-identity with message-based |
| proof-of-possession. (OPTIONAL) |
| |
+---------------------------------------------------+
]]></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 integrity and confidentiality during
transport. The proof-of-identity is supplied by TLS handshake
authentication and optionally also by the HTTP layer headers. The
message type and control/error messages are included in the HTTP
headers.</t>
<t><xref format="default" target="RFC5272">CMC</xref> Section 3.1 notes
that "the Simple PKI Request MUST NOT be used if a proof-of-identity
needs to be included". Since the TLS and HTTP layers provide
proof-of-identity for EST clients and servers 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
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> that complies with <xref format="default"
target="RFC5273">CMC Transport Protocols</xref>.</t>
<t>During protocol exchanges different certificates can be used. The
following table provides an informative overview. End-entities MAY have
one or more certificates of each type listed in <xref
target="FIGlayers3"/> and use one or mor Trust Anchor databases of each
type listed in <xref target="FIGlayers4"/>.</t>
<figure anchor="FIGlayers3">
<artwork><![CDATA[Certificates and their corresponding uses:
+--------------+--------------------+-------------------------------+
| Certificate | Issuer | Use and section references |
+==============+====================+===============================+
| EST server | The CA served by | Presented by the EST server |
| certificate | the EST server | during the TLS handshake |
| | | |
| | | Section 3.3.1 |
+--------------+--------------------+-------------------------------+
| EST server | A CA | Presented by the EST server |
| certificate | authenticatable by | during the TLS handshake |
| | a third-party TA | |
| | | Section 3.3.1, and |
| | | Security Considerations |
+--------------+--------------------+-------------------------------+
| EST client | A CA | Presented by the EST client |
| certificate | authenticatable by | to the EST server by clients |
| | a third-party TA | that have not yet enrolled |
| | e.g., a device | |
| | manufacturer | Section 3.3.2 |
+--------------+--------------------+-------------------------------+
| EST client | The CA served by | Presented by the EST client |
| certificate | the EST server | to PKI End Entities. |
| | | Including to the EST server |
| | | during future EST operations |
| | | |
| | | Section 3.3.2 |
+--------------+--------------------+-------------------------------+
| EST client | The CA served by | Presented by the EST client |
| certificate | the EST server | to PKI End Entities. |
| | | Clients can obtain certs |
| | | that cannot be used for EST |
| | | client authentication |
| | | |
| | | Section 4.2.1 |
+--------------+--------------------+-------------------------------+
]]></artwork>
</figure>
<figure anchor="FIGlayers4">
<artwork><![CDATA[Trust Anchor databases and their corresponding uses:
+--------------+----------------------------------------------------+
| TA database | Use and section references |
+==============+====================================================+
| EST server | EST servers use this TA database to authenticate |
| EST CA | certificates issued by the EST CA, including EST |
| TA database | client certificates during enroll/re-enroll |
| | operations |
| | |
| | Section 3.3.2 |
+--------------+----------------------------------------------------+
| EST server | EST servers use this TA database to authenticate |
| Third-Party | certificates issued by third-party TAs. |
| TA database | e.g., EST client certificates issued by a device |
| | manufacturer |
| | |
| | Section 3.3.2 |
+--------------+----------------------------------------------------+
| EST client | EST clients use this TA database to authenticate |
| Absolute | certificates issued by the EST CA, including EST |
| TA database | server certificates. |
| | |
| | Section 3.3.1 and |
| | Section 4.1 |
+--------------+----------------------------------------------------+
| EST client | EST clients use this trust anchor database to |
| Third-Party | authenticate an EST server that uses an externally |
| TA database | issued certificate. |
| | |
| | |
| | Section 3.1, Section 3.3.1 |
| | The client is RECOMMENDED to use an Absolute TA |
| | database instead of a Third-party TA database for |
| | the reasons detailed in the Security Considerations|
+--------------+----------------------------------------------------+
]]></artwork>
</figure>
<section anchor="ApplicationLayer" title="Application Layer">
<t>The 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>Details of the EST client application configuration are out of
scope of the protocol discussion but are necessary for understanding
the prerequisites of initiating protocol operations. The EST client is
RECOMMENDED to be configured with an Absolute TA database for <xref
target="TLSserverAuthC"/> or with a secret key for <xref
target="TLSmutualAuth"/>. For human usability reasons a "fingerprint"
of the Absolute TA database entry can be configured for bootstrapping
as discussed in <xref target="BootstrapCACerts"/>. Configuration of a
third-party TA database, perhaps by its inclusion within the EST
client distribution or available from the operating system, provides
flexibility along with the caveats detailed in <xref
target="SecurityConsiderations"/>.</t>
<t>The EST client is configured with sufficient information to form
the EST server URI. This can be the full operation path segment (e.g.
https://www.example.com/.well-known/est/ or
https://www.example.com/.well-known/est/arbitraryLabel1) or the EST
client can be configured with a tuple composed of the authority
portion of the URI along with the OPTIONAL label (e.g.
"www.example.com:80", "arbitraryLabel1") or just the authority portion
of the URI.</t>
</section>
<section anchor="HTTP" title="HTTP Layer">
<t>HTTP is used to transfer EST messages. URIs are defined 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 (see Section <xref
target="HTTPuserAuthCandAuthZ"> </xref>). HTTP authentication can also
be used in addition to TLS client authentication if the EST server
wishes additional authentication information, as noted in <xref
target="HTTPclientauthreasons"> </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 described in Section 8.1 of that RFC, persistent
connections may be used to reduce network and processing load
associated with multiple HTTP requests. EST does not require or
preclude persistent HTTP connections and their use is out of scope of
this specification.</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 an EST function. HTTP
authentication is used by a client when requested by the server.</t>
<t>The media types indicated in the HTTP content-type header
indicates which EST message is being transferred. Media types used
by EST are specified in <xref target="MessageTypes"/>.</t>
</section>
<section anchor="HTTPURIs" title="HTTP URIs for control">
<t>The EST server MUST use the <xref target="RFC5785"/> defined
path-prefix of "/.well-known/" and the registered name of "est".
Thus a valid EST server URI path begins with
"https://www.example.com/.well-known/est". Each EST operation is
indicated by a path-suffix that indicates the intended
operation:</t>
<figure anchor="OPERATIONtypes">
<artwork><![CDATA[
Operations and their corresponding URIs:
+------------------------+-----------------+-------------------+
| Operation |Operation Path | Details |
+========================+=================+===================+
| Distribution of CA | /CACerts | Section 4.1 |
| certificates (MUST) | | |
+------------------------+-----------------+-------------------+
| Enrollment of new | /simpleEnroll | Section 4.2. |
| clients (MUST) | | |
+------------------------+-----------------+-------------------+
| Re-Enrollment of | /simpleReEnroll | Section 4.2.2 |
| existing clients (MUST)| | |
+------------------------+-----------------+-------------------+
| Full CMC (OPTIONAL) | /fullCMC | Section 4.3 |
+------------------------+-----------------+-------------------+
| Server-side Key | /serverKeyGen | Section 4.4 |
| Generation (OPTIONAL) | | |
+------------------------+-----------------+-------------------+
| Request CSR attributes | /CSRAttrs | Section 4.5 |
| (OPTIONAL) | | |
+------------------------+-----------------+-------------------+
]]></artwork>
</figure>
<t/>
<t>The operation path (<xref target="OPERATIONtypes"/>) is appended
to the path-prefix to form the URI used with HTTP GET or POST to
perform the desired EST operation. An example valid URI absolute
path for the "/CACerts" operation is "/.well-known/est/CACerts". To
retrieve the CA's certificates, the EST client would use the
following HTTP request:</t>
<t/>
<figure title="">
<artwork><![CDATA[GET /.well-known/est/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 /.well-known/est/simpleEnroll HTTP/1.1]]></artwork>
</figure>
<t>The use of distinct operation paths simplifies implementation for
servers that do not perform client authentication when distributing
/CACerts responses.</t>
<t>An EST server MAY provide service for multiple CAs as indicated
by an OPTIONAL additional path segment between the registered
application name and the operation path. To avoid conflict the CA
label MUST NOT be the same as any defined operation path segment.
The EST server MUST provide services when the additional path
segment is not included. The following are three example valid
URIs:</t>
<t><list style="numbers">
<t>https://www.example.com/.well-known/est/CACerts</t>
<t>https://www.example.com/.well-known/est/arbitraryLabel1/CACerts</t>
<t>https://www.example.com/.well-known/est/arbitraryLabel2/CACerts</t>
</list></t>
<t>In this specification the distinction between enroll and
renew/rekey is explicitly indicated by the HTTP URI. When requesting
/fullCMC operations <xref format="none" target="RFC5272">CMC</xref>
uses the same messages for certificate renewal and certificate
rekey.</t>
<t>An EST server MAY provide additional services using other
URIs.</t>
</section>
<section anchor="HTTPuserAuthCandAuthZ"
title="HTTP-Based Client Authentication">
<t>The EST server 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 may require
that an EST client "knows" a password in addition to "having" an
existing client certificate). Or HTTP-based client authentication
can be an EST server policy specified fallback in situations where
the EST client did not successfully complete the TLS client
authentication. (This might arise if the EST client is enrolling for
the first time or if the certificates available to an EST client
cannot be used for TLS client authentication).</t>
<t>HTTP Basic and Digest authentication MUST only be performed over
<xref target="RFC4346">TLS 1.1</xref> or later versions. 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 SHOULD support the Basic and Digest
authentication mechanism.</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). The client is expected to retry 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>A client MAY set the username to the empty string ("") if it is
presenting a password 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 a CA certificate path, the <xref
target="RFC2046"/> multipart/mixed media type is used.</t>
<t>Each distinct EST message type is specified using a HTTP
Content-Type header with a specific 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>The EST messages and their corresponding media types are:</t>
<figure anchor="MIMEtypes">
<artwork><![CDATA[
+--------------------+--------------------------+-------------------+
| Message type |Request media type | Request section(s)|
| |Response media type(s) | Response section |
| |Source(s) of types | |
+====================+==========================+===================+
| CA certificate | N/A | Section 4.1 |
| request | application/pkcs7-mime | Section 4.1.1 |
| | [RFC5751] | |
+--------------------+--------------------------+-------------------+
| Cert enroll/renew/ | application/pkcs10 | Section 4.2/4.2.1 |
| rekey | application/pkcs7-mime | Section 4.2.2 |
| | [RFC5967] [RFC5751] | |
+--------------------+--------------------------+-------------------+
| Full CMC | application/pkcs7-mime | Section 4.3.1 |
| | application/pkcs7-mime | Section 4.3.2 |
| | [RFC5751] | |
+--------------------+--------------------------+-------------------+
| Server-side Key | application/pkcs10 | Section 4.4.1 |
| Generation | multipart/mixed | Section 4.4.2 |
| | (application/pkcs7-mime &| |
| | application/pkcs8) | |
| | [RFC5967] [RFC5751] & | |
| | [RFC5958] | |
+--------------------+--------------------------+-------------------+
| Request CSR | N/A | Section 4.5.1 |
| attributes | application/csrattrs | Section 4.5.2 |
| | This RFC | |
+--------------------+--------------------------+-------------------+
]]></artwork>
</figure>
</section>
</section>
<section anchor="TLSLayer" title="TLS Layer">
<t>TLS provides communications security for the layers above it. The
integrity and confidentiality services it provides are leveraged to
supply proof-of-identity and to allow authorization decisions to be
made. The EST server and EST client are responsible for ensuring that
an acceptable cipher suite is negotiated and that bidirectional
authentication has been performed. Alternately, certificate-less TLS
authentication, where neither the client nor server present a
certificate, is also an acceptable method for EST authentication.</t>
<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) MUST be supported. TLS session resumption <xref
target="RFC5077"/> SHOULD be supported.</t>
<t>TLS channel binding information MAY be 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 has access to the private key for the certificate being
requested.</t>
<section anchor="TLSserverAuthC"
title="TLS-Based Server Authentication">
<t>The EST server MUST be authenticated during the TLS handshake
unless the client is requesting <xref
target="BootstrapCACerts">Bootstrap Distribution of CA
certificates</xref> or <xref target="FullCMC">Full CMC</xref>.</t>
<t>The EST client authenticates the EST server as defined for the
cipher suite negotiated. The following text provides details
assuming a certificate-based cipher suite, such as the <xref
target="RFC4346">TLS 1.1</xref> mandatory cipher suite
(TLS_RSA_WITH_3DES_EDE_CBC_SHA). As an alternative to authentication
using a certificate, an EST client MAY support certificate-less TLS
authentication (<xref target="TLSmutualAuth"/>).</t>
<t>Certificate validation MUST be performed as per <xref
target="RFC5280"/>. The EST server certificate MUST conform to the
<xref target="RFC5280"/> certificate profile.</t>
<t>The client validates the TLS server certificate using the EST
client TA databases. If certificate validation 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>TLS client authentication is the RECOMMENDED method for
identifying EST clients. <xref
target="HTTPuserAuthCandAuthZ">HTTP-Based Client
Authentication</xref> MAY be used.</t>
<t>The EST server authenticates the EST client as defined for the
cipher suite negotiated. The following text provides details
assuming a certificate-based cipher suite such as the <xref
target="RFC4346">TLS 1.1</xref> mandatory cipher suite
(TLS_RSA_WITH_3DES_EDE_CBC_SHA). The EST server MUST support
certificate based client authentication. As an alternative or as an
addition to authentication using a certificate, an EST server MAY
support <xref target="TLSmutualAuth">certificate-less TLS
authentication</xref>.</t>
<t>When requesting renew/rekey operations the client MUST use the
existing client certificate that was issued by the EST server unless
this certificate is not appropriate for the negotiated cipher suite.
In that case, the client SHOULD use an alternate certificate, with
the same subject identity information, that is appropriate for the
negotiated cipher suite. When requesting an enroll operation the
client MAY use a third-party issued client certificate. The EST
server MUST perform authorization checks as specified in <xref
target="ClientAuthorization"/>.</t>
<t>If a client does not support TLS client authentication, then it
MUST support <xref target="HTTPuserAuthCandAuthZ">HTTP-based client
authentication</xref> or <xref
target="TLSmutualAuth">certificate-less TLS
authentication</xref>.</t>
</section>
<section anchor="TLSmutualAuth"
title="Certificate-less TLS Mutual Authentication">
<t>Certificate-less TLS ciphersuites provide a way to perform mutual
authentication in situations where neither the client nor server
have certificates, or do not have a way to verify a certificate. The
client and server MAY negotiate a certificate-less cipher suite for
mutual authentication. Existing documents such as <xref
format="none" target="RFC5054">[TLS-SRP]</xref> and <xref
format="none" target="RFC2712">[TLS-SRP]</xref>
present techniques for a certificate-less TLS connection.</t>
<t>When using certificate-less mutual authentication in TLS for
enrollment, the cipher suite MUST be resistant to dictionary attack.
This means that the advantage an adversary gains through attack MUST
be related to interaction and not computation. TLS cipher suites
used with EST to perform certificate-less TLS mutual authentication
MUST 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, e.g., 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>A certificate-less ciphersuite 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 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 <xref target="RFC5272"/> by
including TLS session-specific information within the data covered by
the enrollment request signature (thus linking the enrollment request
to the authenticated end-point of the TLS connection).</t>
</section>
<section anchor="IdentityLinkedPOP"
title="Linking Identity and PoP information">
<t>Server policy determines whether the server requires that the TLS
client identity and proof-of-posession of the private key associated
with a certification are linked. 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 are
RECOMMENDED to link identity and PoP. If the client does not have
local policy configuration the client MAY determine that this method
is expected by examining the CSR Attributes Response (see <xref
target="CSRAttrsResp"/>). The EST server MUST verify the tls-unique
information embedded within the certification request if it is
included in the request. The EST server MAY reject requests without
tls-unique information as indicated by server policy.</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 problem as described in <xref target="RFC5929">Channel
Bindings for TLS</xref> section 3.1. To avoid this problem, EST
implementations that support this feature MUST use the tls-unique
value from the first TLS handshake. EST clients and servers use their
tls-unique implementation specific synchronization methods to obtain
this first tls-unique value. TLS "secure_renegotiation" <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>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 an EST server
might TLS authenticate an EST client as being a trusted infrastructure
element that does not forward invalid requests. A detailed discussion
of back-end processing is out of scope).</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 anchor="TLSserverAuthZ" title="Server Authorization">
<t>The client MUST check EST server authorization before accepting any
server responses or responding to HTTP authentication requests.</t>
<t>When the EST client Third-Party TA database is used to validate the
EST server certificate the client MUST check the URI "against the
server's identity as presented in the server's Certificate message"
(<xref target="RFC2818">HTTP Over TLS Section 3.1 "Server
Identity"</xref> and <xref target="RFC6125"/>). The provisioned URI
provides the basis for authorization, and the server's authenticated
identity confirms it is the authorized server.</t>
<t>When the EST client Absolute TA database is used to validate the
EST server certificate the client MUST check either the URI against
the server's identity or the EST server certificate MUST contain the
id-kp-cmcRA <xref target="RFC6402"/> extended key usage extension. The
client MUST maintain a distinction between the Absolute TA database
and any Third-Party TAs database in order to make this
determination.</t>
<t>Successful authentication using a certificate-less cipher suite
implies authorization of the server.</t>
<t>The client MAY perform bootstrapping as specified in <xref
target="BootstrapCACerts"/> even if these checks fail.</t>
</section>
<section anchor="ClientAuthorization" title="Client Authorization">
<t>The decision to issue a certificate to a client is always
controlled by local CA policy. The EST server configuration reflects
this CA policy. This document does not specify any constraints on such
policy. EST provides the EST server access to each client's
authenticated identity -- e.g., the TLS client's certificate in
addition to any HTTP user authentication credentials -- to help in
implementing such policy.</t>
<t>If the client's certificate was issued by the EST CA, and it
includes the id-kp-cmcRA <xref target="RFC6402"/> extended key usage
extension, then the client is a Registration Authority (RA) as
described in <xref target="RFC5272"/> and <xref target="RFC6402"/>. In
this case the EST server SHOULD apply authorization policy consistent
with an RA client. For example when handling /simpleEnroll requests
the EST server could be configured to accept PoP linking information
that does not match the current TLS session because the authenticated
EST client RA has verified this information when acting as an EST
server (as specified in <xref target="IdentityLinkedPOP"/>). More
specific RA mechanisms are available if the EST client uses /fullCMC
methods.</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 make requests to the EST server. These
authorization decisions are described in the next two sections. Assuming
that both sides of the exchange are authorized, then the actual
operations are as described in subsequent sections.</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="CACerts" title="Distribution of CA certificates">
<t>The EST client can request a copy of the current CA certificates.
This function is generally performed before other EST functions.</t>
<section anchor="BootstrapCACerts"
title="Bootstrap Distribution of CA certificates">
<t>When the EST server uses an EST CA issued certificate for TLS
server authentication it is possible that the client was not
configured with the Absolute TA database necessary to validate the
server certificate. This section describes methods by which
minimally configured EST clients can populate their Absolute TA
database.</t>
<t>If the EST client application does not specify either an Absolute
TA database or a Third-party TA database then the initial TLS server
authentication and authorization will fail. The client MAY
provisionally continue the TLS handshake to completion for the
purposes of accessing the /CACerts or /fullCMC method. If the EST
client continues with an unauthenticated connection, the client MUST
extract the HTTP content data from the response (<xref
target="CACertsResp"/> or <xref target="FullCMCResp"/>) and engage a
human user to authorize the CA certificate using out-of-band data
such as a CA certificate "fingerprint" (e.g., a SHA-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 user to properly verify
the TA information, or to provide the "fingerprint" data during
configuration that is necessary to verify the TA information.</t>
<t>HTTP authentication requests MUST NOT be responded to if the
server has not been authenticated. The EST client uses the /CACerts
response to establish a trust anchor for subsequent TLS
authentication of the EST server. EST clients MUST NOT engage in any
other protocol exchange until after the /CACerts response has been
accepted and a new TLS session has been established (using TLS
certificate-based authentication).</t>
</section>
<section anchor="CACertsReq"
title="Distribution of CA certificates request">
<t>EST clients request the Absolute TA database information of the
CA (in the form of certificates) with an HTTPS GET message using an
operation path of "/CACerts". EST clients and servers MUST support
the /CACerts function. Clients SHOULD request an up-to-date response
before stored information has expired in order to ensure the EST CA
TA database is up to date.</t>
<t>The EST server MUST 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="TLSserverAuthC"/> and <xref
target="TLSmutualAuth"/> 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="CACertsResp"
title="Distribution of CA certificates response">
<t>The EST server responds to a Distribution of CA certificates
request with the EST CA certificates within a 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 MUST abort the protocol.</t>
<t>The EST server MUST include the current root CA certificate in
the response. The EST server MUST include any additional
certificates the client would need to build a chain from an EST CA
issued certificate to the current Absolute TA. For example if the
EST CA is a subordinate CA then all the appropriate subordinate CA
certificates necessary to build a chain to the root EST CA are
included in the response.</t>
<t>The EST server SHOULD include the three "Root CA Key Update"
certificates OldWithOld, OldWithNew, and NewWithOld in the response
chain. These are defined in Section 4.4 of <xref format="default"
target="RFC4210">CMP</xref>. The EST client MUST be able to handle
these certificates in the response. The CA's most recent self-signed
certificate (e.g. NewWithNew certificate) is self-signed and has the
latest NotAfter date. This the Absolute TA in the form of a
self-signed certificate. If the EST server does not include these in
the response then after the current Absolute TA certificate expires
the EST clients will need to be (re)enrolled with the PKI using the
<xref target="BootstrapCACerts">Bootstrap Distribution of CA
certificates</xref> method.</t>
<t>The Absolute TA certificate is the certificate that is either
application supplied or is extracted and authorized using
out-of-band information as described in <xref
target="BootstrapCACerts"/>. After out-of-band validation occurs,
all 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 request a certificate from the EST server with an HTTPS
POST using the operation path value of "/simpleEnroll". EST clients
request a renew/rekey of existing certificates with an HTTP POST using
the operation path value of "/simpleReEnroll". EST servers MUST
support the /simpleEnroll and /simpleReEnroll functions.</t>
<t>It is RECOMMENDED that a client obtain the current CA certificates,
as described in <xref target="CACerts"/>, before performing
certificate request functions. This ensures that the client will be
able to validate the EST server certificate. The client MUST
authenticate the EST server as specified in <xref
target="TLSserverAuthC"/> and <xref target="TLSmutualAuth"/>. The
client MUST verify the authorization the EST server as specified in
<xref target="TLSserverAuthZ"/>.</t>
<t>The server MUST authenticate the client as specified in <xref
target="TLSclientAuthC"/> and <xref target="TLSmutualAuth"/>. The
server MUST verify client authorization as specified in <xref
target="ClientAuthorization"/>. The EST server MUST check the
tls-unique value as described in <xref target="IdentityLinkedPOP"/> if
one is submitted by the client.</t>
<t>The server MAY accept a certificate request for manual
authorization checking by an 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 Signing Request (CSR) signature provides
proof-of-possession of the private key to the EST server. If the CSR
KeyUsage extension indicates the private key can be used to generate
digital signatures then the CSR signature MUST be generated using
the private key. If the key can be used to generate digital
signatures but the requested CSR KeyUsage extension prohibits
generation of digital signatures then the CSR signature MUST still
be generated using the private key but the key MUST NOT be used to
for any other signature operations (this is consistent with the
recommendations concerning submission of proof-of-possession to an
RA or CA as described in <xref target="SP-800-57-Part-1"/>). The use
of /fullCMC operations provides access to more advanced
proof-of-possession methods that MUST be used when the key pair can
not be used for digital signature generation (see <xref
target="FullCMC"/>).</t>
<t>The HTTP content-type of "application/pkcs10" is used here. The
format of the message is as specified in <xref
target="RFC4945">Section 6.4 of </xref>.</t>
<t>The EST client MAY request additional certificates even when
using an existing certificate in the TLS client authentication. For
example the client can use an existing certificate for TLS client
authentication when requesting a certificate that cannot be used for
TLS client authentication.</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".</t>
<t>A certificate request employs the same format as the
"simpleEnroll" request, using the same HTTP content-type. The
request Subject field and SubjectAltName extension MUST be identical
to the corresponding fields in the certificate being
renewed/rekeyed. The ChangeSubjectName attribute, as defined in
<xref target="RFC6402"/>, MAY be included in the CSR to request that
these fields be changed in the new certificate.</t>
<t>If the Subject Public Key Info in the certification request is
the same as the current client certificate, the EST server performs
a renew operation. If the public key information is different than
the currently issued certificate then the EST server performs a
rekey operation.</t>
</section>
<section anchor="CertReqResponse"
title="Simple Enroll and Re-Enroll Response">
<t>If the enrollment is successful, the server response MUST contain
an HTTP 200 response code with a content-type of
"application/pkcs7-mime". The response data is a certs-only Simple
PKI Response containing only the certificate that was 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 error, or an HTTP 5xx
error. A Simple PKI Response with an HTTP content-type of
"application/pkcs7-mime" (see <xref target="FullCMCResp"/>) MAY be
included in the response data to convey an error response. If the
content-type is not set the response data MUST be a plain text
human-readable error message containing informative information
describing why the request was rejected (for example indicating that
CSR attributes are incomplete).</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. The server also MAY include informative
human-readable content. The client MUST wait at least the specified
'retry-after' time before repeating the same request. The client
repeats the initial enrollment request after the appropriate
'retry-after' interval has expired. The client SHOULD log or inform
the end user of this event. The server is responsible for
maintaining all state necessary to recognize and handle retry
operations as the client is stateless in this regard; it simply
sends the same request repeatedly until it receives a different
response code.</t>
<t>All other return codes are handled as specified in <xref
format="default" target="RFC2616">HTTP</xref>.</t>
</section>
</section>
<section anchor="FullCMC" title="Full CMC">
<t>An EST client can request a certificate from an EST server with an
HTTPS POST using the operation path value of "/fullCMC". Support for
the /fullCMC function is OPTIONAL for both clients and servers.</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 include
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 as specified in Section 3.2 of <xref
target="RFC5272"/>.</t>
<t>When rejecting a request, the server MUST specify either an HTTP
4xx error or an HTTP 5xx error. A CMC response with content-type of
"application/pkcs7-mime" SHOULD be included in the response data for
any CMC error response. If the content-type is not set the response
data MUST be a plain text human-readable error message containing
informative information describing why the request was rejected (for
example indicating that CSR attributes are incomplete).</t>
<t>All other return codes are handled as specified in <xref
target="CertReqResponse"/> or <xref target="RFC2616">HTTP</xref>.
For example, a 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>An EST client may request a private key and associated certificate
from an EST server using an HTTPS POST with an operation path value of
"/serverKeyGen". Support for the /serverKeyGen function is
OPTIONAL.</t>
<t>A client MUST authenticate an EST server as specified in <xref
target="TLSserverAuthC"/> and <xref target="TLSmutualAuth"/>.</t>
<t>The EST server MUST authenticate the client as specified in <xref
target="TLSclientAuthC"/> and <xref target="TLSmutualAuth"/>. The
server SHOULD use <xref format="title" target="ClientAuthorization"/>
for authorization purposes. The EST server applies whatever
authorization or logic it chooses to determine if the private key and
certificate should be provided.</t>
<t>Proper random number and key generation <xref target="RFC4086"/> is
a server implementation responsibility and server storage of generated
keys is a local option. The key pair and certificate are transferred
over the TLS session. The cipher suite used to return the private key
and certificate MUST offer confidentiality commensurate with the
private key being delivered to the client.</t>
<t>The EST client MAY request additional certificates even when using
an existing certificate in the TLS client authentication. For example
the client can use an existing certificate for TLS client
authentication when requesting a certificate that cannot be used for
TLS client authentication.</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>In all respects the server SHOULD treat the CSR as it would any
enroll or re-enroll CSR; the only distinction here is that the
server MUST ignore the public key values and signature in the CSR.
These are included in the request only to allow re-use of existing
codebases for generating and parsing such requests.</t>
<t>If the client desires to receive the private key with encryption
that exists outside and in addition to that of the TLS transport
used by EST or if server policy requires that the key be delivered
in such a form, the client MUST include a DecryptKeyIdentifier
attribute (as defined in Section 2.2.5, <xref target="RFC4108"/>)
specifying the identifier of the secret key to be used by the server
to encrypt the private key. While that attribute was originally
designated for specifying a firmware encryption key, it exactly
mirrors the requirements for specifying a private key encryption
key. If the server does not have a secret key matching the
identifier specified by the client, the request must be terminated
and an error returned to the client. Distribution of the key
specified by the DecryptKeyIdentifer to the key generator and the
client is outside the scope of this document.</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 format in which the private key data part is returned is
dependent on whether the private key is being returned with
additional encryption on top of that provided by TLS.</t>
<t><list hangIndent="4" style="symbols">
<t>If additional encryption is being employed, the private key
data part MUST be an "application/pkcs7-mime". The content of
this message is an Asymmetric Key Package (see Section 2 <xref
target="RFC5958"/>) protected inside of a CMS
<xref target="RFC5652"/> SignedData content
which is further protected inside of a CMS EnvelopedData, as
described in Section 4 of <xref target="RFC5958"/>. The Signed Data
is signed by the party that generated the private key, which may
or may not be the EST server. The EnvelopedData content is
encrypted using the secret key identified in the request.</t>
<t>If additional encryption is not being employed, the private
key data MUST be an "application/pkcs8". An "application/pkcs8"
part consists of the Base64 encoded DER-encoded PrivateKeyInfo
sandwiched between headers as described in <xref
target="RFC5958"/>.</t>
</list></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>
<figure>
<artwork><![CDATA[-----BEGIN PRIVATE KEY-----
MIIBhDCB7gIBADBFMQswCQYDVQQGEwJBVTETMBEGA1UECBMKU29tZS1TdGF0ZTEh
Simplified example of Base64 encoding of DER-encoded PrivateKeyInfo
ED8rf3UDF6HjloiV3jBnpetx4JjZH/BlmD9HMqofVEryb1e4iZgMUvuIgwEjQwpD
8J4OhHvLh1o=
-----END PRIVATE KEY-----
or
-----BEGIN PKCS7-----
MIIBhDCB7gIBADBFMQswCQYDVQQGEwJBVTETMBEGA1UECBMKU29tZS1TdGF0ZTEh
Simplified example of Base64 encoding of CMS secured Private key
ED8rf3UDF6HjloiV3jBnpetx4JjZH/BlmD9HMqofVEryb1e4iZgMUvuIgwEjQwpD
8J4OhHvLh1o=
-----END PKCS7-----
]]></artwork>
</figure>
<t/>
<t>When rejecting a request, the server MUST specify either an HTTP
4xx error, or an HTTP 5xx error. If the content-type is not set, the
response data MUST be a plain text human-readable error message.</t>
</section>
</section>
<section anchor="CSRAttrs" title="CSR Attributes">
<t>CA policy may allow inclusion of client-provided attributes in
certificates that it issues, and some of these attributes may describe
information that is not available to the CA. In addition, a CA may
desire to certify a certain type of public key and a client may not
have a priori knowledge of that fact. Therefore, clients SHOULD
request a list of expected attributes that are required, or desired,
by the CA in an enrollment request, or if dictated by local
policy.</t>
<t>Requesting CSR Attributes is optional but clients are advised that
CA's may refuse enrollment requests that are not encoded according to
the CA's policy.</t>
<section anchor="CSRAttrsReq" title="CSR Attributes Request">
<t>The EST client requests a list of CA-desired CSR attributes from
the CA by sending an HTTPS GET message to the EST server with an
operations path of "/CSRAttrs".</t>
</section>
<section anchor="CSRAttrsResp" title="CSR Attributes Response">
<t>If locally configured policy for an authenticated EST client
indicates a CSR Attributes Response is to be provided, the server
response MUST include an HTTP 200 response code. An HTTP response
code of 204 or 404 indicates that a CSR Attributes Response is not
available. Regardless of the response code, the EST server and CA
MAY reject any subsequent enrollment requests for any reason, e.g.,
incomplete CSR attributes in the request.</t>
<t>If the CA requires a particular crypto system (e.g.,
certification of a public key based on a certain elliptic curve) it
MUST provide that information in the CSR Attributes response. If an
EST server requires the linking of identity and PoP information (see
<xref target="IdentityLinkedPOP"/>) it MUST include the
challengePassword OID in the CSR Attributes response.</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>An EST server includes zero or more object identifiers that it
requests the client to include in a certification request. When the
server encodes Csrattrs as an empty SEQUENCE it means that the
server has no specific additional attributes it requests in a client
certification request (this is functionally equivalent to an HTTP
response code of 204 or 404.) The sequence is Distinguished Encoding
Rules (DER) encoded and then base64 encoded (section 4 of
[RFC4648]). The resulting text forms the application/csrattr body,
without headers.</t>
<t>For example, if a CA requests a client to submit a certification
request containing the Media Access Control (MAC) address <xref
target="RFC2397"/> of a device, the challengePassword (indicating
that Linking of Identity and POP information is requested, see <xref
target="IdentityLinkedPOP"/>), to use the
the secp384r1 elliptic curve, and to use the SH384 hash function
then it sends 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>
<t>the secp384r1 elliptic curve: 1.3.132.0.4</t>
<t>the SHA384 hash function: 2.16.840.1.101.3.4.2.2</t>
</list> and encodes them into an ASN.1 SEQUENCE to produce:
<list hangIndent="4" style="empty">
<t>30 26 06 07 2B 06 01 01 01 01 16 06 09 2A 86 48 86 F7 0D 01
09 07 06 05 2B 81 04 00 04 06 09 60 86 48 01 65 03 04 02 02</t>
</list> and then base64 encodes the resulting ASN.1 SEQUENCE to
produce: <list hangIndent="4" style="empty">
<t>MCYGBysGAQEBARYGCSqGSIb3DQEJBwYFK4EEAAQGCWCGSAFlAwQCAg==</t>
</list> The EST client parses the OID's in the response and
handles each OID independently. When an OID indicates a known
descriptive CSR attribute type, the client SHOULD include the
requested information in the subsequent CSR that it submits, either
in the CSR attributes or in any other appropriate CSR field. When an
OID indicates a particular way to generate the CSR, the client
SHOULD generate its CSR according to the parsed OID. When an OID is
of an unknown type the OID MUST be ignored by the client.</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 well-known URI registry with the following
filled-in template from <xref target="RFC5785"/>.</t>
<t><list style="empty">
<t>URI suffix: est</t>
<t>Change controller: IETF</t>
</list></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 a client's cleartext password. This provides support for legacy
username/password databases but requires exposing the plaintext password
to the EST server. Use of a PIN or one-time-password can help mitigate
such exposure, but it is RECOMMENDED that EST clients use such
credentials only once to obtain a client certificate (that will be used
during future interactions with the EST server).</t>
<t>When a client uses the Third-Party TA 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
certified-by-a-third-party responder for the URI configured, but cannot
verify that the responder is authorized to act as an RA for the PKI in
which the client is trying to enroll. Clients using a third-party trust
anchor database are RECOMMENDED to only use TLS-based client
authentication (to prevent exposing HTTP-based Client Authentication
information). It is RECOMMENDED that such clients include "Linking
Identity and POP information" (<xref target="IdentityLinkedPOP"/>) in
requests (to prevent such requests from being forwarded to a real EST
server by a MITM). Additionally it is RECOMMENDED that the third-party
trust anchor database used for EST server authentication be carefully
managed, to reduce the chance of a third-party CA with poor
certification practices from being trusted.</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 further sharing
of secrets voids the security afforded by a certificate-less cipher
suite. Exposure of a shared secret used by a certificate-less cipher
suite to a third-party enables client impersonation that can results in
corruption of a client's trust anchor database.</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 occurred while the TLS session was active. This
implies to the server that the authenticated client currently has access
to the private key. If the authenticated client is known to have
specific capabilities, such as hardware protection for authentication
credentials and key storage, this implication is strengthened but not
proven.</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. Private key distribution uses the
encryption mode of the negotiated TLS cipher suite. Keys are not
protected by preferred key wrapping methods such as <xref
target="RFC3394">AES Key Wrap</xref> or as specified in <xref
target="RFC5958"/> as encryption of the private key beyond that provided
by TLS is optional. It is RECOMMEND that EST servers not support this
operation by default. It is RECOMMENDED that clients not request this
service unless there is a compelling operational benefit. Use of a
third-party trust anchor database is NOT RECOMMENDED when server-side
key generation is employed. The use of an encrypted CMS Server-side Key
Generation Response is RECOMMENDED.</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>
</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;
&RFC4108;
&RFC4210;
&RFC4288;
&RFC4346;
&RFC4648;
&RFC4945;
&RFC5054;
&RFC5077;
&RFC5272;
&RFC5273;
&RFC5274;
&RFC5280;
&RFC5652;
&RFC5746;
&RFC5785;
&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;
&RFC2712;
&RFC3394;
&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="Certificate TLS authentication">
<t>The following is an example of a valid /simpleEnroll exchange.
During this exchange the EST client uses an existing certificate
issued by a thirt-party CA 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 EST CA
("estExampleCA") and it includes the distinguished name of a
third-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 third 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 EST CA.</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 third 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>Because the DecryptKeyIdentifier attribute is not included in the
request the response does not include additional encryption beyond the
TLS session. The EST server response is:</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:09:17 |