Internet DRAFT - draft-turner-est-extensions
draft-turner-est-extensions
Network Working Group Sean Turner
Internet Draft sn3rd
Intended Status: Standards Track October 12, 2017
Expires: April 15, 2018
EST (Enrollment over Secure Transport) Extensions
draft-turner-est-extensions-11.txt
Abstract
The EST (Enrollment over Secure Transport) protocol defined a Well-
Known URI (Uniform Resource Identifier): /.well-known/est along with
a number of other path components that clients use for PKI (Public
Key Infrastructure) services, namely certificate enrollment (e.g.,
/simpleenroll). This document defines a number of other PKI services
as additional path components, specifically firmware and trust
anchors as well as symmetric, asymmetric, and encrypted keys. This
document also specifies the PAL (Package Availability List), which is
an XML (Extensible Markup Language) file or JSON (JavaScript Object
Notation) object that clients use to retrieve packages available and
authorized for them. This document extends the EST server path
components to provide these additional services.
Status of this Memo
This Internet-Draft is submitted in full conformance with the
provisions of BCP 78 and BCP 79.
Internet-Drafts are working documents of the Internet Engineering
Task Force (IETF). Note that other groups may also distribute
working documents as Internet-Drafts. The list of current Internet-
Drafts is at http://datatracker.ietf.org/drafts/current/.
Internet-Drafts are draft documents valid for a maximum of six months
and may be updated, replaced, or obsoleted by other documents at any
time. It is inappropriate to use Internet-Drafts as reference
material or to cite them other than as "work in progress."
Copyright Notice
Copyright (c) 2017 IETF Trust and the persons identified as the
document authors. All rights reserved.
This document is subject to BCP 78 and the IETF Trust's Legal
Provisions Relating to IETF Documents
(http://trustee.ietf.org/license-info) in effect on the date of
publication of this document. Please review these documents
carefully, as they describe your rights and restrictions with respect
Turner Expires April 15, 2018 [Page 1]
Internet-Draft EST Extensions October 12, 2017
to this document. Code Components extracted from this document must
include Simplified BSD License text as described in Section 4.e of
the Trust Legal Provisions and are provided without warranty as
described in the Simplified BSD License.
Table of Contents
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3
1.1. Definitions . . . . . . . . . . . . . . . . . . . . . . . 5
1.2. Authentication and Authorization . . . . . . . . . . . . . 6
1.3. TLS Cipher Suites . . . . . . . . . . . . . . . . . . . . 6
1.4. URI Configuration . . . . . . . . . . . . . . . . . . . . 6
1.5. Message Types . . . . . . . . . . . . . . . . . . . . . . 6
1.6. Key Words . . . . . . . . . . . . . . . . . . . . . . . . 8
2. Locate Available Packages . . . . . . . . . . . . . . . . . . 9
2.1. PAL Format . . . . . . . . . . . . . . . . . . . . . . . . 11
2.1.1. PAL Package Types . . . . . . . . . . . . . . . . . . 12
2.1.2. PAL XML Schema . . . . . . . . . . . . . . . . . . . . 17
2.1.3. PAL JSON Object . . . . . . . . . . . . . . . . . . . 20
2.2. Request PAL . . . . . . . . . . . . . . . . . . . . . . . 21
2.3. Provide PAL . . . . . . . . . . . . . . . . . . . . . . . 21
3. Distribute EE Certificates . . . . . . . . . . . . . . . . . . 22
3.1. EE Certificate Request . . . . . . . . . . . . . . . . . . 23
3.2. EE Certificate Response . . . . . . . . . . . . . . . . . 23
4. Distribute CRLs and ARLs . . . . . . . . . . . . . . . . . . . 23
4.1. CRL Request . . . . . . . . . . . . . . . . . . . . . . . 23
4.2. CRL Response . . . . . . . . . . . . . . . . . . . . . . . 24
5. Symmetric Keys, Receipts, and Errors . . . . . . . . . . . . . 24
5.1. Symmetric Keys . . . . . . . . . . . . . . . . . . . . . . 24
5.1.1. Distribute Symmetric Keys . . . . . . . . . . . . . . 25
5.1.2. Symmetric Key Response . . . . . . . . . . . . . . . . 25
5.2. Symmetric Key Receipts and Errors . . . . . . . . . . . . 26
5.2.1. Provide Symmetric Key Receipt or Error . . . . . . . . 27
5.2.2. Symmetric Key Receipt or Error Response . . . . . . . 28
6. Firmware, Receipts, and Errors . . . . . . . . . . . . . . . . 28
6.1. Firmware . . . . . . . . . . . . . . . . . . . . . . . . . 28
6.1.1. Distribute Firmware . . . . . . . . . . . . . . . . . 28
6.1.2. Firmware Response . . . . . . . . . . . . . . . . . . 29
6.2. Firmware Receipts and Errors . . . . . . . . . . . . . . . 29
6.2.1. Provide Firmware Receipt or Error . . . . . . . . . . 30
6.2.2. Firmware Receipt or Error Response . . . . . . . . . . 30
7. Trust Anchor Management Protocol . . . . . . . . . . . . . . . 30
7.1. TAMP Status Query, Trust Anchor Update, Apex Trust
Anchor Update, . . . . . . . . . . . . . . . . . . . . . . 31
Community Update, and Sequence Number Adjust . . . . . . . . 31
7.1.1. Request TAMP Packages . . . . . . . . . . . . . . . . 31
7.1.2. Return TAMP Packages . . . . . . . . . . . . . . . . . 31
Turner Expires April 15, 2018 [Page 2]
Internet-Draft EST Extensions October 12, 2017
7.2. TAMP Response, Confirm, and Errors . . . . . . . . . . . . 32
7.2.1. Provide TAMP Response, Confirm, or Error . . . . . . . 32
7.2.2. TAMP Response, Confirm, and Error Response . . . . . . 32
8. Asymmetric Keys, Receipts, and Errors . . . . . . . . . . . . 33
8.1. Asymmetric Key Encapsulation . . . . . . . . . . . . . . . 33
8.2. Asymmetric Key Package Receipts and Errors . . . . . . . . 34
8.3. PKCS#12 . . . . . . . . . . . . . . . . . . . . . . . . . 35
8.3.1. Server-Side Key Generation Request . . . . . . . . . . 35
8.3.2. Server-Side Key Generation Response . . . . . . . . . 35
9. PAL & Certificate Enrollment . . . . . . . . . . . . . . . . . 36
10. Security Considerations . . . . . . . . . . . . . . . . . . . 38
11. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 39
11.1. PAL Name Space . . . . . . . . . . . . . . . . . . . . . 39
11.2. PAL XML Schema . . . . . . . . . . . . . . . . . . . . . 39
11.3. PAL Package Types . . . . . . . . . . . . . . . . . . . . 40
12. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 40
13. References . . . . . . . . . . . . . . . . . . . . . . . . . 40
13.1. Normative References . . . . . . . . . . . . . . . . . . 40
13.2. Informative References . . . . . . . . . . . . . . . . . 45
Appendix A. Example Use of PAL . . . . . . . . . . . . . . . . . 45
Appendix B. Additional CSR Attributes . . . . . . . . . . . . . . 47
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 48
1. Introduction
The EST (Enrollment over Secure Transport) protocol [RFC7030] defines
the Well-Known URI (Uniform Resource Identifier) /.well-known/est to
support selected PKI (Public Key Infrastructure) related services
with path components (PCs) such as simple enrollment with
/simpleenroll, rekey or renew with /simplereenroll, etc. A server
that wishes to support additional PKI-related services and other
security-related packages could use the same .well-known URI by
defining additional PCs. This document defines six such PCs:
o /pal - The PAL (Package Availability List) provides a list of all
known packages available and authorized for a client. By
accessing the service provided by this PC first, the client can
walk through the PAL and download all the packages necessary to
begin operating securely. The PAL essentially points to other
PCs including the ones defined in this document as well as those
defined in [RFC7030], which include /cacerts, /simpleenroll,
/simplereenroll, /fullcmc, /serverkeygen, and /csrattrs. The
/pal PC is described in Section 2.
o /eecerts - EE (End-Entity) certificates [RFC5280] are needed by
the client when they invoke a security protocol for communicating
with a peer (i.e., they become operational and do something
Turner Expires April 15, 2018 [Page 3]
Internet-Draft EST Extensions October 12, 2017
meaningful as opposed to just communicating with the
infrastructure). If the infrastructure knows the certificate(s)
needed by the client, then providing the peer's certificate
avoids the client having to discover the peer's certificate.
This service is not meant to be a general purpose repository to
which clients query a "repository" and then get a response; this
is purely a push mechanism. The /eecerts PC is described in
Section 3.
o /crls - CRLs (Certificate Revocation Lists) and Authority
Revocation Lists (ARLs) [RFC5280] are also needed by the client
when they validate certificate paths. CRLs (and ARLs) from TAs
(Trust Anchors) and intermediate CAs (Certification Authorities)
are needed to validate the certificates used to generate the
client's certificate or the peer's certificate, which is provided
by the /eecerts PC, and providing them saves the client from
having to "discover" them and then retrieve them. CRL
"discovery" is greatly aided by the inclusion of the CRL
Distribution Point certificate extension [RFC5280], but this
extension is not always present in certificates and requires
another connection to retrieve them. Like the /eecerts PC, this
service is not meant to be a general purpose repository to which
clients query a repository and then get a response; this is
purely a push mechanism. The /crls PC is described in Section 4.
o /symmetrickeys - In some cases, clients use symmetric keys
[RFC6031] when communicating with their peers. If the client's
peers are known by the server a priori, then providing them saves
the client or an administrator from later having to find,
retrieve and install them. Like the /eecerts and /crls PCs, this
service is not meant to be a general purpose repository to which
clients query a repository and then get a response; this is
purely a push mechanism for the keys themselves. However, things
do not always go as planned and clients need to inform the server
about any errors. If things did go well, then the client, if
requested, needs to provide a receipt [RFC7191]. The
/symmetrickeys and /symmetrickeys/return PCs are described in
Section 5.
o /firmware - Some client firmware and software support automatic
update mechanisms and some do not. For those that do not, the
/firmware PC provides a mechanism for the infrastructure to
inform the client that firmware and software updates [RFC4108]
are available. Because updates do not always go as planned and
because sometimes the server needs to know whether the firmware
was received and processed, this PC also provides a mechanism to
return errors and receipts. The /firmware and /firmware/return
PCs are defined in Section 6.
Turner Expires April 15, 2018 [Page 4]
Internet-Draft EST Extensions October 12, 2017
o /tamp - To control the TAs in client TA databases, servers use
the /tamp PC to request that clients retrieve a TAMP (Trust
Anchor Management Protocol) query, update, and adjust packages
[RFC5934] and clients use the /tamp/return PC to return TAMP
response, confirm, and error [RFC5934]. The /tamp and
/tamp/return PCs are defined in Section 7.
This document also extends the /est/serverkeygen PC [RFC7030] to
support (see Section 8):
o Returning asymmetric key package receipts and errors [RFC7191].
o Encapsulating returned asymmetric keys in additional CMS content
types [RFC7193].
o Returning server-generated public key pairs encapsulated in
PKCS#12 [RFC7292].
While the motivation is to provide packages to clients during
enrollment so that they can perform securely after enrollment, the
services defined in this specification can be used after enrollment.
1.1. Definitions
Familiarity with Using Cryptographic Message Syntax (CMS) to Protect
Firmware Packages [RFC4108], Certificate Management over CMS (CMC)
[RFC5272], Cryptographic Message Syntax (CMS) Encrypted Key Package
[RFC6032], Cryptographic Message Syntax (CMS) [RFC5652][RFC6268],
Trust Anchor Management Protocol (TAMP) [RFC5934], Cryptographic
Message Syntax (CMS) Content Constraints Extension [RFC6010], CMS
Symmetric Key Package Content Type [RFC6031], Enrollment over Secure
Transport protocol [RFC7030], CMS Key Package Receipt and Error
Content Types [RFC7191] is assumed. Also, familiarity with the CMS
protecting content types signed data and encrypted data is assumed;
CMS signed data and encrypted data are defined in [RFC5652] and CMS
encrypted key package is defined in [RFC6032].
In addition to the definitions found in [RFC7030], the following
definitions are used in this document:
Agent: An entity that performs functions on behalf of a client.
Agents can service a) one or more clients on the same network as the
server, b) clients on non-IP based networks, or c) clients that have
a non-electronic air gap [RFC4949] between themselves and the server.
Interactions between the agent and client in the last two cases are
beyond the scope of this document. Before an agent can service
clients, the agent must have a trust relationship with the server, be
authorized to act on behalf of clients.
Turner Expires April 15, 2018 [Page 5]
Internet-Draft EST Extensions October 12, 2017
Client: A device that ultimately consumes and uses the packages to
enable communications. In other words, the client is the end-point
for the packages and an agent may have one or more clients. To avoid
confusion, this document henceforth uses the term client to refer to
both agents and clients.
Package: An object that contains one or more content types. There
are numerous types of packages: Asymmetric Keys, Symmetric Keys,
Encrypted Keys, CRLs, Public Key Certificate Management, Firmware,
Public Key Certificates, and TAMP packages. All of these packages
are digitally signed by their creator and encapsulated in a CMS
signed data [RFC5652][RFC6268] (except the public key certificates
and CRLs that are already digitally signed by a CA); Firmware
receipts and errors, TAMP responses, confirms, and errors, as well as
Key Package receipts and errors that can be optionally signed.
Certificate and CRLs are included in a package that uses signed data,
which is often referred to as a degenerate CMS or "certs-only" or
"crls-only" message [RFC5751][RFC6268], but no signature or content
is present; hence the name certs-only and crls-only.
Note: As per [RFC7030], the creator may or may not be the EST server
or the EST CA.
1.2. Authentication and Authorization
Client and server authentication as well as client and server
authorization are as defined in [RFC7030]. The requirements for each
are discussed in the request and response sections of each of the PCs
defined by this document.
The requirements for the TA databases are as specified in [RFC7030]
as well.
1.3. TLS Cipher Suites
TLS cipher suite and issues associated with them are as defined in
[RFC7030].
1.4. URI Configuration
As specified in Section 3.1 of [RFC7030], the client is configured
with sufficient information to form the server URI [RFC3986]. Like
EST, this configuration mechanism is beyond the scope of this
document.
1.5. Message Types
This document uses existing media types for the messages as specified
Turner Expires April 15, 2018 [Page 6]
Internet-Draft EST Extensions October 12, 2017
by "Internet X.509 Public Key Infrastructure Protocol: FTP and HTTP"
[RFC2585], "The application/pkcs10 Media Type" [RFC5967], and CMC
[RFC5272].
For consistency with [RFC5273], each distinct EST message type uses
an HTTP Content-Type header with a specific media type.
The EST messages and their corresponding media types for each
operation are:
+--------------------+--------------------------+-------------------+
| Message type | Request media type | Request section(s)|
| | Response media type(s) | Response section |
| (per operation) | Source(s) of types | |
+====================+==========================+===================+
| Locate Available | N/A | Section 2.2 |
| Packages | application/xml or | Section 2.3 |
| | application/json | |
| | [RFC7303][RFC7159] | |
| /pal | | |
+====================+==========================+===================+
| Distribute EE | N/A | Section 3.1 |
| Certificates | application/pkcs7-mime | Section 3.2 |
| | [RFC5751] | |
| /eecerts | | |
+====================+==========================+===================+
| Distribute CRLs | N/A | Section 4.1 |
| | application/pkcs7-mime | Section 4.2 |
| | [RFC5751] | |
| /crls | | |
+====================+==========================+===================+
| Symmetric Key | N/A | Section 5.1.1 |
| Distribution | application/cms | Section 5.1.2 |
| | [RFC7193] | |
| /symmetrickeys | | |
+====================+==========================+===================+
| Return Symmetric | application/cms | Section 5.2.1 |
| Key | N/A | Section 5.2.2 |
| Receipts/Errors | [RFC7193] | |
| | | |
| /symmetrickeys/ | | |
| return | | |
+====================+==========================+===================+
| Firmware | N/A | Section 6.1.1 |
| Distribution | application/cms | Section 6.1.2 |
| | [RFC7193] | |
| /firmware | | |
+====================+==========================+===================+
Turner Expires April 15, 2018 [Page 7]
Internet-Draft EST Extensions October 12, 2017
| Return Firmware | application/cms | Section 6.2.1 |
| Receipts/Errors | N/A | Section 6.2.2 |
| | [RFC7193] | |
| /firmware/return | | |
+====================+==========================+===================+
| Trust Anchor | N/A | Section 7.1.1 |
| Management | application/ | Section 7.1.2 |
| | tamp-status-query | |
| | tamp-update | |
| | tamp-apex-update | |
| | tamp-community-update | |
| | tamp-sequence-adjust | |
| | [RFC5934] | |
| /tamp | | |
+====================+==========================+===================+
| Return TAMP | application/ | Section 7.2.1 |
| Responses/ | tamp-status-query-response | |
| Confirms/ | tamp-update-confirm | |
| Errors | tamp-apex-update-confirm | |
| | tamp-community-update-confirm | |
| | tamp-sequence-adjust-confirm | |
| | tamp-error | |
| | N/A | Section 7.2.2 |
| | [RFC5934] | |
| /tamp/return | | |
+====================+==========================+===================+
| Server-Side Key | application/pkcs10 with | Section 8.1 |
| Generation | content type attribute | |
| | CSR | |
| | application/cms | Section 8.1 |
| /serverkeygen | [RFC7193] | |
+====================+==========================+===================+
| Return Asymmetric | application/cms | Section 8.2 |
| Key | N/A | Section 8.2 |
| Receipts/Errors | [RFC7193] | |
| | | |
| /serverkeygen/ | | |
| return | | |
+====================+==========================+===================+
| Server-Side Key | application/pkcs10 | Section 8.3.1 |
| Generation: | application/pkcs12 | Section 8.3.2 |
| PKCS#12 | | |
| | | |
| /serverkeygen | [RFC7193] | |
+====================+==========================+===================+
1.6. Key Words
Turner Expires April 15, 2018 [Page 8]
Internet-Draft EST Extensions October 12, 2017
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
"SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and
"OPTIONAL" in this document are to be interpreted as described in
[RFC2119].
2. Locate Available Packages
The PAL (Package Availability List) is either an XML (Extensible
Markup Language) [XML] or JSON (JavasScript Object Notation)
[RFC7159] object available through the /pal PC that furnishes the
following information to clients:
o Advertisements for available packages that can be retrieved from
the server;
o Notifications to begin public key certificate management or to
return package receipts and errors; and
o Advertisement for another PAL.
After being configured (see Section 1.4), the client can use this
service to retrieve their PAL (see Section 2.1) that, if properly
constructed (see Section 2.3), allows the client to determine some or
all of the security-related packages needed for bootstrapping. Each
PAL entry refers to other PCs, defined in this document as well as
those defined in [RFC7030], that clients use to retrieve packages,
e.g., CA certificates, firmware, trust anchors, symmetric keys, and
asymmetric keys, available for it or to be notified to initiate
public key certificate enrollment. PAL entries can also be used to
notify clients they are to return receipts or errors for certain
packages (see Section 2.1.1). Placing these entries after entries
that clients used to retrieve the packages is the same as requesting
receipts in the originally distributed package. Figure 1 provides a
ladder diagram for the /pal PC protocol flow. Appendix A provides a
detailed example.
| |
Client | Establish TLS | Server
| Session |
|<-------------------->|
| |
| Request PAL |
| (HTTP GET Request) |
|--------------------->|
|<---------------------|
| Deliver PAL |
| (HTTP GET Response) |
| |
Turner Expires April 15, 2018 [Page 9]
Internet-Draft EST Extensions October 12, 2017
| Request package by |
| specified URI |
| (HTTP GET or POST |
| Request) |
|--------------------->|
|<---------------------|
| Deliver requested |
| CMS package product |
| (HTTP GET or POST |
| Response) |
| |
repeat as necessary
Figure 1 - /pal Message Sequence
PALs are designed to support an arbitrary number of entries, but for
PALs that need to be divided for whatever reason there is a special
PAL entry type, which are collectively referred to as PAL Package
Types (see Sections 2.1 and 2.1.1), number 0001 is defined that
refers to another PAL. If present, the 0001 package type is always
last because other entries after it are ignored. Also, the 0001
package type cannot be the only PAL entry to avoid needlessly
dereferencing URIs.
In addition to using the PAL during bootstrapping, clients can be
configured to periodically poll the server to determine if there are
updated packages available for it. Note that the mechanism to
configure how often clients poll the server is out-of-scope.
However, there are some services that support indicating when to
return (e.g., simple enrollment and re-enroll responses include the
Retry-After header [RFC7030]).
As noted earlier, the PAL support two variants: XML and JSON.
Clients include the HTTP Accept header [RFC7231] when they connect to
the server to indicate whether they support XML or JSON.
The client MUST authenticate the server as specified in [RFC7030] and
the client MUST check the server's authorization as specified in
[RFC7030].
The server MUST authenticate the client as specified in [RFC7030] and
the server MUST check the client's authorization as specified in
[RFC7030].
PAL support is OPTIONAL. It is shown in figures throughout this
document but clients need not support the PAL to access services
offered by the server.
Turner Expires April 15, 2018 [Page 10]
Internet-Draft EST Extensions October 12, 2017
2.1. PAL Format
Each PAL is composed of zero or more entries. Each entry is composed
of four fields, type, date, size, and info, whose semantics follow:
Note: Both XML elements and JSON values are described below. XML
elements are enclosed in angle brackets <> and JSON values are
enclosed in single quotes ''. When described together they are
enclosed in brackets [] separated by |.
o [<type> | 'type'] uniquely identifies each package that a client
may retrieve from the server with a 4-digit string.
[<type> | 'type'] MUST be present. The PAL Package Types are
defined in Section 2.1.1.
o [<date> | 'date'] either indicates:
* The date and time that the client last successfully downloaded
the identified package from the server. [<date> | 'date'] MUST
be represented as Generalized Time with 20 characters:
YYYY-MM-DDTHH:MM:SSZ; <date> matches the dateTime production in
"canonical representation" [XMLSCHEMA]; 'date' is a string.
Implementations SHOULD NOT rely on time resolution finer than
seconds and MUST NOT generate time instants that specify leap
seconds.
* The omission of [<date> | 'date'] indicates that:
- There is no indication the client has successfully downloaded
the identified package, or
- The PAL entry corresponds to a pointer to the next PAL or the
server is requesting a package from the client (e.g.,
certification request, receipt, error).
o [<size> | 'size'] indicates the size in bytes of the package;
<size> is a nonNegativeInteger and 'size' is a number. A package
size of zero (i.e., "0" without the quotes) indicates that the
client needs to begin a transaction or return an error or
receipt. [<size> | 'size'] MUST be present.
o [<info> | 'info'] provides either an SKI (Subject Key
Identifier), a DN (Distinguished Name), an Issuer and Serial
Number tuple or a URI, i.e., it is a choice between these four
all of which are defined in [RFC5280]. When a URI [RFC3986] is
included, [<uri> | 'uri'] indicates the location where the
identified package can be retrieved. When a DN, an SKI, or an
Issuer Name and Serial Number tuple is included it points to a
Turner Expires April 15, 2018 [Page 11]
Internet-Draft EST Extensions October 12, 2017
certificate that is the subject of the notification (i.e., the
certificate to be rekeyed or renewed); [<dn> | 'dn'] is encoded
as a string with the format defined in [RFC4514]; <ski> is a
hexBinary and 'ski' is a string of hex digits (i.e., 0-9, a-f,
and A-F); [<iasn> | 'iasn'] includes both [<issuer> | 'issuer']
and [<serial> | 'serial'] as a complexType in XML and an object
in JSON. [<issuer> | 'issuer'] is a DN encoded as a string with
the format defined in [RFC4514]; <serial> is a positiveInteger
and 'serial' is a number. [<info> | 'info'] MUST be present and
[<info> | 'info'] MUST include exactly one [<dn> | 'dn'],
[<ski> | 'ski'], [<iasn> | 'iasn'], or [<uri> | 'uri'].
Clients are often limited by the size of objects they can consume,
the PAL is not immune to these limitations. As opposed to picking a
limit for all clients, a special package type is defined, see Section
2.1.1, to indicate that another PAL is available. Servers can use
this value to limit the size of the PALs provided to clients. The
mechanism for servers to know client PAL size limits is beyond the
scope of the document; one possible solution is through provisioned
information.
2.1.1. PAL Package Types
Table 1 lists the PAL package types that are defined by this
document:
NOTE: CSR is Certificate Signing Request, DS is Digital Signature and
KE is Key Establishment.
Package Package Description
Number
-------- ---------------------------------------------------
0000: Reserved
0001: Additional PAL value present
0002: X.509 CA certificate
0003: X.509 EE certificate
0004: X.509 ARL
0005: X.509 CRL
0006: Start DS certificate enrollment with CSR attribute
0007: Start DS certificate enrollment
0008: DS certificate enrollment (success)
0009: DS certificate enrollment (failure)
0010: Start DS certificate re-enrollment
0011: DS certificate re-enrollment (success)
0012: DS certificate re-enrollment (failure)
0013: Start KE certificate enrollment with CSR attribute
0014: Start KE certificate enrollment
0015: KE certificate enrollment (success)
Turner Expires April 15, 2018 [Page 12]
Internet-Draft EST Extensions October 12, 2017
0016: KE certificate enrollment (failure)
0017: Start KE certificate re-enrollment
0018: KE certificate re-enrollment (success)
0019: KE certificate re-enrollment (failure)
0020: Asymmetric Key Package (PKCS#8)
0021: Asymmetric Key Package (CMS)
0022: Asymmetric Key Package (PKCS#12)
0023: Asymmetric Key Package Receipt or Error
0024: Symmetric Key Package
0025: Symmetric Key Package Receipt or Error
0026: Firmware Package
0027: Firmware Package Receipt or Error
0028: TAMP Status Query
0029: TAMP Status Query Response or Error
0030: Trust Anchor Update
0031: Trust Anchor Update Confirm or Error
0032: Apex Trust Anchor Update
0033: Apex Trust Anchor Update Confirm or Error
0034: Community Update
0035: Community Update Confirm or Error
0036: Sequence Number Adjust
0037: Sequence Number Adjust Confirm or Error
Table 1 - PAL Package Types
PAL package types are essentially hints about the type of package the
client is about to retrieve or is asked to return. Savvy clients can
parse the packages to determine what has been provided, but in some
instances it is better to know before retrieving the package. The
hint provided here does not obviate the need for clients to check the
type of package provided before they store it possibly in specially
allocated locations (i.e., some clients might store Root ARLs
separately from intermediate CRLs). For packages provided by the
client, the server is asking the client to provide an enrollment
package, receipt, response, confirm or error.
The PAL package types have the following meaning:
NOTE: The semantics behind Codes 0002 and 0006-0021 are defined in
[RFC7030].
0000 Reserved: Reserved for future use.
0001 Additional PAL value present: Indicates that this PAL entry
refers to another PAL by referring to another /pal URI, which
is defined in this section. This PAL package type limits the
size of PALs to a more manageable size for clients. If this
PAL Package Type appears it MUST be the last entry in the PAL.
Turner Expires April 15, 2018 [Page 13]
Internet-Draft EST Extensions October 12, 2017
Additionally, this PAL Package Type MUST NOT the only entry
to avoid endless dereferencing URIs.
0002 X.509 CA certificate: Indicates that one or more CA certificates
[RFC5280] are available for the client by pointing to a
/cacerts URI, which is defined in [RFC7030].
0003 X.509 EE certificate: Indicates that one or more EE certificate
[RFC5280] is available for the client by pointing to an
/eecerts URI, which is defined in Section 3.
0004 X.509 ARL: Indicates that one or more ARL (Authority Revocation
List) [RFC5280] is available for the client by pointing to a
/crls URI, which is defined in Section 4.
0005 X.509 CRL: Indicates that one or more CRL (Certificate
Revocation List) [RFC5280] is available for the client by
pointing to a /crls URI, which is defined in Section 4.
NOTE: See Section 9 for additional information about PAL and
certificate enrollment interaction. See Appendix B for additional
informative information.
0006 Start DS (Digital Signature) certificate enrollment with CSR:
Indicates that the client begin enrolling their DS certificate
(i.e., those certificates for which the key usage extension
will have digital signature set) using a template provided by
the server with a CSR (Certificate Signing Request) attribute
(see Appendix B). The PAL entry points to a /csrattrs URI,
which is defined in [RFC7030].
0007 Start DS (Digital Signature) certificate enrollment: Indicates
that the client begin enrolling their DS certificate. The PAL
entry points to a /simpleenroll URI, which is defined in
[RFC7030].
0008 DS certificate enrollment (success): Indicates that the client
retrieve a successful certification response. The PAL entry
points to a /simpleenroll or a /fullcmc URI, which are both
defined in [RFC7030].
0009 DS certificate enrollment (failure): Indicates that the client
retrieve a failed certification response for a DS certificate.
This PAL entry points to a /simpleenroll or a /fullcmc URI.
0010 Start DS certificate re-enrollment: Indicates that the client
rekey or renew a DS certificate. The PAL entry points to a
/simplereenroll or a /fullcmc URI.
Turner Expires April 15, 2018 [Page 14]
Internet-Draft EST Extensions October 12, 2017
0011 DS certificate re-enrollment (success): See PAL package type
0008.
0012 DS certificate re-enrollment (failure): See PAL package type
0009.
NOTE: The KE (Key Establishment) responses that follow use the same
URIs as DS certificates except in the requested certificates the key
usage extension request will have only either key agreement or key
transport set.
0013 Start KE certificate enrollment with CSR: See PAL package type
0006.
0014 Start KE certificate enrollment: See PAL package type 0007.
0015 KE certificate enrollment (success): See PAL package type 0008.
0016 KE certificate enrollment (failure): See PAL package type 0009.
0017 Start KE certificate re-enrollment: See PAL package type 0010.
0018 KE certificate re-enrollment (success): See PAL package type
0008.
0019 KE certificate re-enrollment (failure): See PAL package type
0009.
NOTE: The variations on the asymmetric key packages is due to the
number of CMS content types that can be used to protect the
asymmetric key; the syntax for the asymmetric key is the same but
additional ASN.1 is needed to include it in a signed data (i.e., the
ASN.1 needs to be a CMS content type not the private key info type).
See Section 8 of this document for additional information.
0020 Asymmetric Key Package (PKCS#8): Indicates that an asymmetric
key generated by the server is available for the client; the
package is an asymmetric key without additional encryption as
specified in Section 4.4.2 of [RFC7030]. The PAL entry points
to a /serverkeygen or a /fullcmc URI, which are defined in
[RFC7030].
0021 Asymmetric Key Package (CMS): See PAL package type 0020. The
difference being that the package available is an asymmetric
key package [RFC5958] that is signed and encapsulated in a
signed data content type, as specified in Section 4.4.2 of
[RFC7030]. Also, see Section 8.1 of this document.
Turner Expires April 15, 2018 [Page 15]
Internet-Draft EST Extensions October 12, 2017
0022 Asymmetric Key Package (PKCS#12): See PAL package type 0020.
The difference being that the package available is PKCS12
[RFC7292] content type. See Section 8.3 of this document.
0023 Asymmetric Key Package Receipt or Error: Indicates that the
server wants the client to return a key package receipt or
error [RFC7191] to the /serverkeygen/return URI, which is
defined in Section 8.
0024 Symmetric Key Package: Indicates that a symmetric key package
[RFC6031] is available for the client by pointing to a
/symmetrickeys URI, which is defined in Section 5.
0025 Symmetric Key Package Receipt or Error: Indicates that the
server wants the client to return a key package receipt or an
error [RFC7191] to the /symmetrickeys/return URI, which is
defined in Section 5.
0026 Firmware Package: Indicates that a firmware package [RFC4108] is
available for the client using the /firmware URI, which is
defined in Section 6.
0027 Firmware Package Receipt or Error: Indicates that the server
wants the client to return a firmware package load receipt or
error [RFC4108] to the /firmware/return URI, which is defined
in Section 6.
NOTE: The /tamp and tamp/return URIs are defined in Section 7.
0028 TAMP Status Query: Indicates that a TAMP Status Query package
[RFC5934] is available for the client using the /tamp URI.
0029 TAMP Status Query Response or Error: Indicates that the server
wants the client to return a TAMP Status Query Response or
Error [RFC5934] to the /tamp/return URI.
0030 Trust Anchor Update: Indicates that a Trust Anchor Update
package [RFC5934] is available for the client using the /tamp
URI.
0031 Trust Anchor Update Confirm or Error: Indicates that the server
wants the client to return a Trust Anchor Update Confirm or
Error [RFC5934] to the /tamp/return URI.
0032 Apex Trust Anchor Update: Indicates that an Apex Trust Anchor
Update package [RFC5934] is available for the client using the
/tamp URI.
Turner Expires April 15, 2018 [Page 16]
Internet-Draft EST Extensions October 12, 2017
0033 Apex Trust Anchor Update Confirm or Error: Indicates that the
server wants the client to return an Apex Trust Anchor Update
Confirm or Error [RFC5934] to the /tamp/return URI.
0034 Community Update: Indicates that a Community Update package
[RFC5934] is available for the client using the /tamp URI.
0035 Community Update Confirm or Error: Indicates that the server
wants the client to return a Community Update Confirm or Error
[RFC5934] to the /tamp/return URI.
0036 Sequence Number Adjust: Indicates that a Sequence Number Adjust
package [RFC5934] is available for the client using the /tamp
URI.
0037 Sequence Number Adjust Confirm or Error: Indicates that the
server wants the client to return a Sequence Number Adjust
Confirm or Error [RFC5934] to the /tamp/return URI.
2.1.2. PAL XML Schema
The name space is specified in Section 11.1. The fields in the
schema were discussed earlier in Sections 2.1 and 2.1.1.
<?xml version="1.0" encoding="UTF-8"?>
<xsd:schema xmlns:xsd="http://www.w3.org/2001/XMLSchema"
xmlns:pal="urn:ietf:params:xml:ns:pal"
targetNamespace="urn:ietf:params:xml:ns:pal"
elementFormDefault="qualified" attributeFormDefault="unqualified"
version="1.0">
<xsd:annotation>
<xsd:documentation>
This schema defines the types and elements needed
to retrieve client packages from the server or for the
client to post packages to the server.
</xsd:documentation>
</xsd:annotation>
<!-- ===== Element Declarations ===== -->
<xsd:element name="pal" type="pal:PAL" />
<!-- ===== Complex Data Element Type Definitions ===== -->
<xsd:complexType name="PAL">
<xsd:annotation>
<xsd:documentation>
This type defines the Package Availability List (PAL).
Turner Expires April 15, 2018 [Page 17]
Internet-Draft EST Extensions October 12, 2017
</xsd:documentation>
</xsd:annotation>
<xsd:sequence>
<xsd:element name="message" type="pal:PALEntry"
minOccurs="0" maxOccurs="unbounded">
<xsd:annotation>
<xsd:documentation>
Contains information about the package and a link that
the client uses to download or post the package.
</xsd:documentation>
</xsd:annotation>
</xsd:element>
</xsd:sequence>
</xsd:complexType>
<xsd:complexType name="PALEntry">
<xsd:annotation>
<xsd:documentation>
This type defines a product in the PAL.
</xsd:documentation>
</xsd:annotation>
<xsd:sequence>
<xsd:element name="type" type="pal:PackageType" />
<xsd:element name="date" type="pal:GeneralizedTimeType"
minOccurs="0" />
<xsd:element name="size" type="xsd:nonNegativeInteger">
<xsd:annotation>
<xsd:documentation>
Indicates the package's size.
</xsd:documentation>
</xsd:annotation>
<xsd:element name="info" type="pal:PackageInfoType" />
</xsd:sequence>
</xsd:complexType>
<xsd:complexType name="PackageInfoType">
<xsd:annotation>
<xsd:documentation>
This type allows a choice of X.500 Distinguished Name,
Subject Key Identifier, Issuer and Serial Number tuple,
or URI.
</xsd:documentation>
</xsd:annotation>
<xsd:choice>
<xsd:element name="dn" type="pal:DistinguishedName" />
<xsd:element name="ski" type="pal:SubjectKeyIdentifier" />
<xsd:element name="iasn" type="pal:IssuerAndSerialNumber" />
<xsd:element name="uri" type="pal:ThisURI" />
Turner Expires April 15, 2018 [Page 18]
Internet-Draft EST Extensions October 12, 2017
</xsd:choice>
</xsd:complexType>
<xsd:complexType name="IssuerAndSerialNumber">
<xsd:annotation>
<xsd:documentation>
This type holds the issuer Distinguished Name and
serial number of a referenced certificate.
</xsd:documentation>
</xsd:annotation>
<xsd:sequence>
<xsd:element name="issuer" type="pal:DistinguishedName" />
<xsd:element name="serial" type="xsd:positiveInteger" />
</xsd:sequence>
</xsd:complexType>
<!-- =====Simple Data Element Type Definitions ===== -->
<xsd:simpleType name="PackageType">
<xsd:annotation>
<xsd:documentation>
Identifies each package that a client may retrieve from
the server with a 4-digit string.
</xsd:documentation>
</xsd:annotation>
<xsd:restriction base="xsd:string">
<xsd:pattern value="d{4}" />
</xsd:restriction>
</xsd:simpleType>
<xsd:simpleType name="GeneralizedTimeType">
<xsd:annotation>
<xsd:documentation>
Indicates the date and time (YYYY-MM-DDTHH:MM:SSZ) the
client last acknowledged successful receipt of the
package or is absent if a) there is no indication
the package has been downloaded or b) the PAL entry
corresponds to a pointer to the next PAL.
</xsd:documentation>
</xsd:annotation>
<xsd:restriction base="xsd:dateTime">
<xsd:pattern value=".*:d{2}Z" />
<xsd:minInclusive value="2013-05-23T00:00:00Z" />
</xsd:restriction>
</xsd:simpleType>
<xsd:simpleType name="DistinguishedName">
<xsd:annotation>
Turner Expires April 15, 2018 [Page 19]
Internet-Draft EST Extensions October 12, 2017
<xsd:documentation>
This type holds an X.500 Distinguished Name.
</xsd:documentation>
</xsd:annotation>
<xsd:restriction base="xsd:string">
<xsd:maxLength value="1024" />
</xsd:restriction>
</xsd:simpleType>
<xsd:simpleType name="SubjectKeyIdentifier">
<xsd:annotation>
<xsd:documentation>
This type holds a hex string representing the value of a
certificate's SubjectKeyIdentifier.
</xsd:documentation>
</xsd:annotation>
<xsd:restriction base="xsd:hexBinary">
<xsd:maxLength value="1024" />
</xsd:restriction>
</xsd:simpleType>
<xsd:simpleType name="ThisURI">
<xsd:annotation>
<xsd:documentation>
This type holds a URI, but is length limited.
</xsd:documentation>
</xsd:annotation>
<xsd:restriction base="xsd:anyURI" />
<xsd:maxLength value="1024" />
</xsd:simpleType>
</xsd:schema>
2.1.3. PAL JSON Object
The following is an example PAL JSON object. The fields in the
object were discussed earlier in Sections 2.1 and 2.1.1.
[
{
"type": "0003",
"date": "2016-12-29T09:28:00Z",
"size": 1234,
"info":
{
"uri": "https://www.example.com/.well-known/est/eecerts/1234"
}
},
Turner Expires April 15, 2018 [Page 20]
Internet-Draft EST Extensions October 12, 2017
{
"type": "0006",
"date": "2016-12-29T09:28:00Z",
"size": 1234,
"info":
{
"iasn":
{
"issuer": "CN=Sean Turner,O=sn3rd,C=US",
"serial": 0
}
}
}
]
2.2. Request PAL
Clients request their PAL with an HTTP GET [RFC7231] using an
operation path of "/pal". Clients indicate whether they would prefer
XML or JSON by including the HTTP Accept header [RFC7231] with either
"application/xml" or "application/json", respectively.
2.3. Provide PAL
If the server has a PAL for the client, the server response MUST
contain an HTTP 200 response code with a content-type of
"application/xml" [RFC7303] or "application/json" [RFC7159].
When the server constructs a PAL, an order of precedence for PAL
offerings is based on the following rationale:
o /cacerts and /crls packages are the most important because they
support validation decisions on certificates used to sign and
encrypt other listed PAL items.
o /csrattrs are the next in importance, since they provide
information that the server would like the client to include in
its certificate enrollment request.
o /simpleenroll, /simplereenroll, and /fullcmc packages items are
next in importance, since they can impact a certificate used by
the client to sign CMS content or a certificate to establish keys
for encrypting content exchanged with the client.
* A client engaged in a certificate management SHOULD accept and
process CA-provided transactions as soon as possible to avoid
undue delays that might lead to protocol failure.
Turner Expires April 15, 2018 [Page 21]
Internet-Draft EST Extensions October 12, 2017
o /symmetrickeys, /firmware, /tamp, and /eecerts packages
containing keys and other types of products are last. Precedence
SHOULD be given to packages that the client has not previously
downloaded. The items listed in a PAL may not identify all of
the packages available for a device. This can be for any of the
following reasons:
* The server may temporarily withhold some outstanding PAL items
to simplify client processing.
* If a CA has more than one certificate ready for the client, the
server will provide a notice for one at a time. Pending
notices will be serviced in order of the earliest date when the
certificate will be used.
When rejecting a request the server specifies either an HTTP 4xx
error, or an HTTP 5xx error.
All other return codes are handled as specified in Section 4.2.3 of
[RFC7030] (i.e., 202 handling and all other HTTP response codes).
3. Distribute EE Certificates
Numerous mechanisms exist for clients to query repositories for
certificates. The service provided by the /eecerts PC is different
in that it is not a general purpose query for client certificates
instead it allows the server to provide peer certificates to a client
that the server knows through an out-of-band mechanism that the
client will be communicating with. For example, a router being
provisioned that connects to two peers can be provisioned with not
only its certificate but also with the peers' certificates.
The server need not authenticate or authorize the client for
distributing an EE certificate because the package contents are
already signed by a CA (i.e., the certificate(s) in a certs-only
message have already been signed by a CA). The message flow is
similar to Figure 1 except that the connection need not be HTTPS:
| |
Client | Establish TLS | Server
| Session |
|<-------------------->|
| |
| Request PAL |
| (HTTP GET Request) |
|--------------------->|
|<---------------------|
| Deliver PAL |
Turner Expires April 15, 2018 [Page 22]
Internet-Draft EST Extensions October 12, 2017
| (HTTP GET Response) |
| |
| Request EE Cert(s) |
| (HTTP GET Request) |
|--------------------->|
|<---------------------|
| Deliver EE Cert(s) |
| (HTTP GET Response) |
| |
Figure 2 - /eecerts Message Sequence
3.1. EE Certificate Request
Clients request EE certificates with an HTTP GET [RFC7231] using an
operation path of "/eecerts".
3.2. EE Certificate Response
The response and processing of the returned error codes is identical
to that in Section 4.1.3 of [RFC7030] except that the certificate
provided is not the one issued to the client but instead one or more
client's peer certificates is returned in the certs-only message.
Clients MUST reject EE certificates that do not validate to an
authorized TA.
4. Distribute CRLs and ARLs
CRLs (and ARLs) are needed in many instances to perform certificate
path validation [RFC5280]. They can be obtained from repositories if
their location is provided in the certificate. However, the client
needs to parse the certificate and perform an additional round trip
to retrieve them. Providing CRLs at the time of bootstrap obviates
the need for the client to parse certificate and aid those clients
who might be unable to retrieve the CRL. Clients are free to obtain
CRLs on which they rely from sources other than the server (e.g., a
local directory). The /crls PC allows servers to distribute CRLs at
the same time clients retrieve their certificate(s) and CA
certificate(s) as well as peer certificates.
The server need not authenticate or authorize the client for
distributing a CRL because the package content is already signed by a
CA (i.e., the CRLs in a crls-only message have already been signed by
a CA). The message flow is as depicted in Figure 2 but with "CRL(s)"
instead of "EE Cert(s)".
4.1. CRL Request
Turner Expires April 15, 2018 [Page 23]
Internet-Draft EST Extensions October 12, 2017
Clients request CRLs with an HTTP GET [RFC7231] using an operation
path of "/crls".
4.2. CRL Response
The response and processing of the response is identical to that in
Section 4.1.3 of [RFC7030] except that instead of providing the
issued certificate one of more CRLs are returned in the crls-only
message.
Clients MUST reject CRLs that do not validate to an authorized TA.
5. Symmetric Keys, Receipts, and Errors
In addition to public keys, clients often need one or more symmetric
keys to communicate with their peers. The /symmetrickeys PC allows
the server to distribute symmetric keys to clients.
Distribution of keys does not always work as planned and clients need
a way to inform the server that something has gone wrong; they also
need a way to inform the server, if asked, that the distribution
process has successfully completed. The /symmetrickeys/return PC
allows client to provide errors and receipts.
Clients MUST authenticate the server and clients MUST check the
server's authorization.
The server MUST authenticate clients and the server MUST check the
client's authorization.
HTTP GET [RFC7231] is used when the server provides the key to the
client (see Section 5.1) using the /symmetrickeys PC; HTTP POST
[RFC7231] is used when the client provides a receipt (see Section
5.2) or an error (see Section 5.2) to the server with the
/symmetrickeys/return PC.
5.1. Symmetric Keys
Servers use /symmetrickeys to provide clients symmetric keys;
symmetric key package is defined in [RFC6031].
As with the /serverkeygen PC defined in [RFC7030], the default
distribution method of the symmetric key uses the encryption mode of
the negotiated TLS cipher suite. Keys are not protected by preferred
key wrapping methods such as AES Key Wrap [RFC3394] or AES Key Wrap
with Padding [RFC5649] because encryption of the symmetric key beyond
that provided by TLS is OPTIONAL. Therefore, the cipher suite used
to return the symmetric key MUST offer commensurate cryptographic
Turner Expires April 15, 2018 [Page 24]
Internet-Draft EST Extensions October 12, 2017
strength with the symmetric key being delivered to the client. The
cipher suite used MUST NOT have NULL encryption algorithm as this
will disclose the unprotected symmetric key. It is strongly
RECOMMENDED that servers always return encrypted symmetric keys.
The following depicts the protocol flow:
| |
Client | Establish TLS | Server
| Session |
|<-------------------->|
| |
| Request PAL |
| (HTTP GET Request) |
|--------------------->|
|<---------------------|
| Deliver PAL |
| (HTTP GET Response) |
| |
| Req Symmetric Key |
| (HTTP GET Request) |
|--------------------->|
|<---------------------|
| Res Symmetric Key |
| (HTTP GET Response) |
| |
Figure 3 - /symmetrickeys Message Sequence
5.1.1. Distribute Symmetric Keys
Clients request the symmetric key from the server with an HTTP GET
[RFC7231] using an operation path of "/symmetrickeys".
5.1.2. Symmetric Key Response
If the request is successful, the server response MUST have an HTTP
200 response code with a Content-Type of application/cms [RFC7193].
The optional application/cms encapsulatingContent and innerContent
parameters SHOULD be included with the Content-Type to indicate the
protection afforded to the returned symmetric key. The returned
content varies:
o If additional encryption is not being employed, the content
associated with application/cms is a DER-encoded [X.690]
symmetric key package.
o If additional encryption is employed, the content associated with
Turner Expires April 15, 2018 [Page 25]
Internet-Draft EST Extensions October 12, 2017
application/cms is DER-encoded enveloped data that encapsulates a
signed data that further encapsulates a symmetric key package.
o If additional encryption and origin authentication are employed,
the content associated with application/cms is a DER-encoded
signed data that encapsulates an enveloped data that encapsulates
a signed data that further encapsulates a symmetric key package.
o If CCC (CMS Content Constraints) [RFC6010] is supported the
content associated with application/cms is a DER-encoded
encrypted key package [RFC6032]. Encrypted key package provides
three choices to encapsulate keys: encrypted data, enveloped
data, and authenticated enveloped data. Prior to employing one
of these three encryption choices the key package can be
encapsulated in a signed data.
How the server knows whether the client supports the encrypted key
package is beyond the scope of this document.
When rejecting a request, the server specifies either an HTTP 4xx
error, or an HTTP 5xx error.
If a symmetric key package (which might be signed) or an encrypted
key package (which might be signed before and after encryption) is
digitally signed, the client MUST reject it if the digital signature
does not validate back to an authorized TA.
Note: absent a policy on the client side requiring signature, a
malicious EST server can simply strip the signature, thus bypassing
that check. In that case, this requirement is merely a sanity check,
serving to detect mis-signed packages or misconfigured clients.
[RFC3370], [RFC5753], [RFC5754], [RFC6033], [RFC6160], and [RFC6161]
provide algorithm details for use when protecting the symmetric key
package and encrypted key package.
5.2. Symmetric Key Receipts and Errors
Clients use /symmetrickeys/return to provide symmetric key package
receipts; the key package receipt content type is defined in
[RFC7191]. Clients can be configured to automatically return
receipts after processing a symmetric key package, return receipts
based on processing of the key-package-identifier-and-receipt-request
attribute [RFC7191], or return receipts when prompted by a PAL entry.
Servers can indicate that clients return a receipt by including the
key-package-identifier-and-receipt-request attribute in a signed data
as a signed attribute. However, this attribute only appears when
Turner Expires April 15, 2018 [Page 26]
Internet-Draft EST Extensions October 12, 2017
additional encryption is employed (see Section 5.1.2).
Clients also use /symmetrickeys/return to return symmetric key
package errors; the key package error content type is defined in
[RFC7191]. Clients can be configured to automatically return errors
after processing a symmetric key package or based on a PAL entry.
The following depicts the protocol flow:
| |
Client | Establish TLS | Server
| Session |
|<-------------------->|
| |
| Request PAL |
| (HTTP GET Request) |
|--------------------->|
|<---------------------|
| Deliver PAL |
| (HTTP GET Response) |
| |
| Return Receipt/Error |
| (HTTP POST Request) |
|--------------------->|
|<---------------------|
| (HTTP POST Response) |
| status code only |
| no content |
| |
Figure 4 - /symmetrickeys/return Message Sequence
5.2.1. Provide Symmetric Key Receipt or Error
Clients return symmetric key receipts and errors to the server with
an HTTP POST [RFC7231] using an operation path of
"/symmetrickeys/return". The returned content varies:
o The key package receipt is digitally signed [RFC7191], the
Content-Type is application/cms [RFC7193] and the associated
content is signed data, which encapsulates a key package receipt.
o If the key package error is not digitally signed, the Content-
Type is application/cms and the associated content is key package
error. If the key package error is digitally signed, the
Content-Type is application/cms and the associated content is
signed data, which encapsulates a key package error.
Turner Expires April 15, 2018 [Page 27]
Internet-Draft EST Extensions October 12, 2017
The optional application/cms encapsulatingContent and innerContent
parameters SHOULD be included with the Content-Type to indicate the
protection afforded to the receipt or error.
[RFC3370], [RFC5753], [RFC5754], and [RFC7192] provide algorithm
details for use when protecting the key package receipt or key
package error.
5.2.2. Symmetric Key Receipt or Error Response
If the client successfully provides a receipt or error, the server
response has an HTTP 204 response code (i.e., no content is
returned).
When rejecting a request, the server specifies either an HTTP 4xx
error, or an HTTP 5xx error.
If a key package receipt or key package error is digitally signed,
the server MUST reject it if the digital signature does not validate
back to an authorized TA.
6. Firmware, Receipts, and Errors
Servers can distribute object code for cryptographic algorithms and
software with the firmware package [RFC4108].
Clients MUST authenticate the server and clients MUST check the
server's authorization.
The server MUST authenticate the client and the server MUST check the
client's authorization.
The /firmware PC uses an HTTP GET [RFC7231] and the /firmware/return
PC uses an HTTP POST [RFC7231]. GET is used when the client
retrieves firmware from the server (see Section 6.1); POST is used
when the client provides a receipt (see Section 6.2) or an error (see
Section 6.2).
6.1. Firmware
The /firmware URI is used by servers to provide firmware packages to
clients.
The message flow is as depicted in Figure 3 modulo replacing
"Symmetric Key" with "Firmware Package".
6.1.1. Distribute Firmware
Turner Expires April 15, 2018 [Page 28]
Internet-Draft EST Extensions October 12, 2017
Clients request firmware from the server with an HTTP GET [RFC7231]
using an operation path of "/firmware".
6.1.2. Firmware Response
If the request is successful, the server response MUST have an HTTP
200 response code with a Content-Type of "application/cms" [RFC7193].
The optional encapsulatingContent and innerContent parameters SHOULD
be included with Content-Type to indicate the protection afforded to
the returned firmware. The returned content varies:
o If the firmware is unprotected, then the Content-Type is
application/cms and the content is the DER-encoded [X.690]
firmware package.
o If the firmware is compressed, then the Content-Type is
application/cms and the content is the DER-encoded [X.690]
compressed data that encapsulates the firmware package.
o If the firmware is encrypted, then the Content-Type is
application/cms and the content is the DER-encoded [X.690]
encrypted data that encapsulates the firmware package (which
might be compressed prior to encryption).
o If the firmware is signed, then the Content-Type is
application/cms and the content is the DER-encoded [X.690] signed
data that encapsulates the firmware package (which might be
compressed, encrypted, or compressed and then encrypted prior to
signature).
How the server knows whether the client supports the unprotected,
signed, compressed and/or encrypted firmware package is beyond the
scope of this document
When rejecting a request, the server specifies either an HTTP 4xx
error, or an HTTP 5xx error.
If a firmware package is digitally signed, the client MUST reject it
if the digital signature does not validate back to an authorized TA.
[RFC3370], [RFC5753], and [RFC5754] provide algorithm details for use
when protecting the firmware package.
6.2. Firmware Receipts and Errors
Clients use the /firmware/return PC to provide firmware package load
receipts and errors [RFC4108]. Clients can be configured to
automatically return receipts and errors after processing a firmware
Turner Expires April 15, 2018 [Page 29]
Internet-Draft EST Extensions October 12, 2017
package or based on a PAL entry.
The message flow is as depicted in Figure 4 modulo the receipt or
error is for a firmware package.
6.2.1. Provide Firmware Receipt or Error
Clients return firmware receipts and errors to the server with an
HTTP POST [RFC7231] using an operation path of "/firmware/return".
The optional encapsulatingContent and innerContent parameters SHOULD
be included with Content-Type to indicate the protection afforded to
the returned firmware receipt or error. The returned content varies:
o If the firmware receipt is not digitally signed, the Content-Type
is application/cms [RFC7193] and the content is the DER-encoded
firmware receipt.
o If the firmware receipt is digitally signed, the Content-Type is
application/cms and the content is the DER-encoded signed data
encapsulating the firmware receipt.
o If the firmware error is not digitally signed, the Content-Type
is application/cms and the content is the DER-encoded firmware
error.
o If the firmware error is digitally signed, the Content-Type is
application/cms and the content is the DER-encoded signed data
encapsulating the firmware error.
[RFC3370], [RFC5753], and [RFC5754] provide algorithm details for use
when protecting the firmware receipt or firmware error.
6.2.2. Firmware Receipt or Error Response
If the request is successful, the server response MUST have an HTTP
204 response code (i.e., no content is returned).
When rejecting a request, the server MUST specify either an HTTP 4xx
error, or an HTTP 5xx error.
If a firmware receipt or firmware error is digitally signed, the
server MUST reject it if the digital signature does not validate back
to an authorized TA.
7. Trust Anchor Management Protocol
Servers distribute TAMP packages to manage TAs in a client's trust
anchor databases; TAMP packages are defined in [RFC5934]. TAMP will
Turner Expires April 15, 2018 [Page 30]
Internet-Draft EST Extensions October 12, 2017
allow the flexibility for a device to load authorities while
maintaining an operational state. Unlike other systems that require
new software loads when new PKI Roots are authorized for use, TAMP
allows for automated management of roots for provisioning or
replacement as needed.
Clients MUST authenticate the server and clients MUST check the
server's authorization.
The server MUST authenticate the client and the server MUST check the
client's authorization.
The /tamp PC uses an HTTP GET [RFC7231] and the tamp/return PC uses
an HTTP POST [RFC7231]. GET is used when the server requests that
the client retrieve a TAMP package (see Section 7.1); POST is used
when the client provides a confirm (see Section 7.2), provides a
response (see Section 7.2), or provides an error (see Section 7.2)
for the TAMP package.
7.1. TAMP Status Query, Trust Anchor Update, Apex Trust Anchor Update,
Community Update, and Sequence Number Adjust
Clients use the /tamp PC to retrieve the TAMP packages: TAMP Status
Query, Trust Anchor Update, Apex Trust Anchor Update, Community
Update, and Sequence Number Adjust. Clients can be configured to
periodically poll the server for these packages or contact the server
based on a PAL entry.
The message flow is as depicted in Figure 3 modulo replacing
"Symmetric Key" with the appropriate TAMP message.
7.1.1. Request TAMP Packages
Clients request the TAMP packages from the server with an HTTP GET
[RFC7231] using an operation path of "/tamp".
7.1.2. Return TAMP Packages
If the request is successful, the server response MUST have an HTTP
200 response code and a Content-Type of:
o application/tamp-status-query for TAMP Status Query
o application/tamp-update for Trust Anchor Update
o application/tamp-apex-update for Apex Trust Anchor Update
o application/tamp-community-update for Community Update
o application/tamp-sequence-adjust for Sequence Number Adjust
As specified in [RFC5934], these content types are digitally signed
and clients must support validating the packages directly signed by
Turner Expires April 15, 2018 [Page 31]
Internet-Draft EST Extensions October 12, 2017
TAs. For this specification, clients MUST support validation with a
certificate and clients MUST reject it if the digital signature does
not validate back to an authorized TA.
[RFC3370], [RFC5753], and [RFC5754] provide algorithm details for use
when protecting the TAMP packages.
7.2. TAMP Response, Confirm, and Errors
Clients return the TAMP Status Query Response, Trust Anchor Update
Confirm, Apex Trust Anchor Update Confirm, Community Update Confirm,
Sequence Number Adjust Confirm, and TAMP Error to servers using the
/tamp/return PC. Clients can be configured to automatically return
responses, confirms, and errors after processing a TAMP package or
based on a PAL entry.
The message flow is as depicted in Figure 4 modulo replacing
"Receipt/Error" with the appropriate TAMP response, confirm, or
error.
7.2.1. Provide TAMP Response, Confirm, or Error
Clients provide the TAMP responses, confirms, and errors to the
server with an HTTP POST using an operation path of "/tamp/return".
Content-Type is:
o application/tamp-status-query-response for TAMP Status Query
Response
o application/tamp-update-confirm for Trust Anchor Update Confirm
o application/tamp-apex-update-confirm for Apex Trust Anchor Update
Confirm
o application/tamp-community-update-confirm for Community Update
Confirm
o application/tamp-sequence-adjust-confirm for Sequence Number
Adjust Confirm
o application/tamp-error for TAMP Error
As specified in [RFC5934], these content types should be signed. If
signed, a signed data encapsulates the TAMP content.
[RFC3370], [RFC5753], and [RFC5754] provide algorithm details for use
when protecting the TAMP packages.
7.2.2. TAMP Response, Confirm, and Error Response
If the request is successful, the server response MUST have an HTTP
204 response code (i.e., no content is returned).
Turner Expires April 15, 2018 [Page 32]
Internet-Draft EST Extensions October 12, 2017
When rejecting a request, the server MUST specify either an HTTP 4xx
error, or an HTTP 5xx error.
If the package is digitally signed, the server MUST reject it if
digital signature does not validate back to an authorized TA.
8. Asymmetric Keys, Receipts, and Errors
[RFC7030] defines the /serverkeygen PC to support server-side
generation of asymmetric keys. Keys are returned either as an
unprotected PKCS#8 when additional security beyond TLS is not
employed or as a CMS asymmetric key package content type that is
encapsulated in a signed data content type that is further
encapsulated in an enveloped data content type when additional
security beyond TLS is requested. Some implementations prefer the
use of other CMS content types to encapsulate the asymmetric key
package; this document extends the content types that can be returned
in Section 8.1.
[RFC7191] defines content types for key package receipts and errors.
This document defines the /serverkeygen/return PC to add support for
returning receipts and errors for asymmetric key packages in Section
8.2.
PKCS#12 [RFC7292], sometimes referred to as "PFX" (Personal
inFormation eXchange), "P12", and "PKCS#12" files, are often used to
distribute asymmetric private keys and the associated certificate.
This document extends the /serverkeygen PC to allow servers to
distribute using PKCS#12 server-generated asymmetric private keys and
the associated certificate to clients in Section 8.3.
8.1. Asymmetric Key Encapsulation
CMS supports a number of content types to encapsulate other CMS
content types; [RFC7030] includes one such possibility; note that
when only relying on TLS the returned key is not a CMS content type.
This document extends the CMS content types that can be returned.
If the client supports CCC [RFC6010], then the client can indicate
that it supports encapsulated asymmetric keys in the encrypted key
package [RFC5958] by including the encrypted key package's OID in a
content type attribute [RFC2985] in the CSR (Certificate Signing
Request), aka the certification request, it provides to the server.
If the client knows a priori that the server supports the encrypted
key package content type, then the client need not include the
content type attribute in the CSR.
In all instances defined herein, the Content-Type is
Turner Expires April 15, 2018 [Page 33]
Internet-Draft EST Extensions October 12, 2017
"application/cms" [RFC7193]. The optional encapsulatingContent and
innerContent parameters SHOULD be included with Content-Type to
indicate the protection afforded to the returned asymmetric key
package.
If additional encryption and origin authentication is employed, the
content associated with application/cms is a DER-encoded signed data
that encapsulates an enveloped data that encapsulates a signed data
that further encapsulates an asymmetric key package.
If CCC (CMS Content Constraints) is supported and additional
encryption is employed, the content associated with application/cms
is a DER-encoded encrypted key package [RFC6032] content type that
encapsulates a signed data that further encapsulates an asymmetric
key package.
If CCC is supported and additional encryption and additional origin
authentication is employed, the content associated with
application/cms is a DER-encoded signed data that encapsulates an
encrypted key package content type that encapsulates a signed data
that further encapsulates an asymmetric key package.
Encrypted key package [RFC6032] provides three choices to encapsulate
keys, encrypted data, enveloped data, and authenticated data, with
enveloped data being the mandatory to implement choice.
When rejecting a request, the server specifies either an HTTP 4xx
error, or an HTTP 5xx error.
If an asymmetric key package or an encrypted key package is digitally
signed, the client MUST reject it if the digital signature does not
validate back to an authorized TA.
Note: absent a policy on the client side requiring signature, a
malicious EST server can simply strip the signature, thus bypassing
that check. In that case, this requirement is merely a sanity check,
serving to detect mis-signed packages or misconfigured clients.
[RFC3370], [RFC5753], [RFC5754], [RFC6033], [RFC6161], and [RFC6162]
provide algorithm details for use when protecting the asymmetric key
package and encrypted key package.
8.2. Asymmetric Key Package Receipts and Errors
Clients can be configured to automatically return receipts after
processing an asymmetric key package, return receipts based on
processing of the key-package-identifier-and-receipt-request
attribute [RFC7191], or return receipts when prompted by a PAL entry.
Turner Expires April 15, 2018 [Page 34]
Internet-Draft EST Extensions October 12, 2017
Servers can indicate that clients return a receipt by including the
key-package-identifier-and-receipt-request attribute [RFC7191] in a
signed data as a signed attribute.
The protocol flow is identical to that depicted in Figure 4 modulo
the receipt or error is for asymmetric keys.
The server and client processing is as described in Section 5.2.1 and
5.2.2 modulo the PC, which for Asymmetric Key Packages is
"/serverkeygen/return".
8.3. PKCS#12
PFX is widely deployed and supports protecting keys in the same
fashion as CMS but it does so differently.
8.3.1. Server-Side Key Generation Request
Similar to the other server-generated asymmetric keys provided
through the /serverkeygen PC:
o The certificate request is HTTPS POSTed and is the same format as
for the "/simpleenroll" and "/simplereenroll" path extensions
with the same content-type and transfer encoding.
o 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.
PBE (password based encryption) shrouding of PKCS#12 is supported and
this specification makes no attempt to alter this de facto standard.
As such, there is no support of the DecryptKeyIdentifier specified in
[RFC7030] for use with PKCS#12 (i.e., "enveloping" is not supported).
NOTE: Use of PBE requires the password be distributed to the client;
methods to distribute this password are out-of-scope.
8.3.2. Server-Side Key Generation Response
If the request is successful, the server response MUST have an HTTP
200 response code with a content-type of "application/pkcs12" that
consists of a base64-encoded DER-encoded [X.690] PFX [RFC7292].
Note that this response is different than the response returned in
Section 4.4.2 of [RFC7030] because here the private key and the
certificate are included in the same PFX.
Turner Expires April 15, 2018 [Page 35]
Internet-Draft EST Extensions October 12, 2017
When rejecting a request, the server MUST specify either an HTTP 4xx
error or an HTTP 5xx error. The response data's content-type MAY be
"text/plain" [RFC2046] to convey human-readable error messages.
9. PAL & Certificate Enrollment
The /fullcmc PC is defined in [RFC7030]; the CMC (Certificate
Management over Cryptographic Message Syntax) requirements and
packages are defined in [RFC5272], [RFC5273], [RFC5274], and
[RFC6402]. This section describes PAL interactions.
Under normal circumstances the client-server interactions for PKI
enrollment are as follows:
Client Server
--------------------->
POST req: PKIRequest
Content-Type: application/pkcs10
or
POST req: PKIRequest
Content-Type: application/pkcs7-mime
smime-type=CMC-request
<--------------------
POST res: PKIResponse
Content-Type: application/pkcs7-mime
smime-type=certs-only
or
POST res: PKIResponse
Content-Type: application/pkcs7-mime
smime-type=CMC-response
if the response is rejected during the same session:
Client Server
--------------------->
POST req: PKIRequest
Content-Type: application/pkcs10
or
POST req: PKIRequest
Content-Type: application/pkcs7-mime
smime-type=CMC-request
<--------------------
POST res: empty
HTTPS Status Code
or
POST res: PKIResponse
Turner Expires April 15, 2018 [Page 36]
Internet-Draft EST Extensions October 12, 2017
Content-Type: application/pkcs7-mime
smime-type=CMC-response
if the request is to be filled later:
Client Server
--------------------->
POST req: PKIRequest
Content-Type: application/pkcs10
or
POST req: PKIRequest
Content-Type: application/pkcs7-mime
smime-type=CMC-request
<--------------------
POST res: empty
HTTPS Status Code
+ Retry-After
or
POST res: PKIResponse (pending)
Content-Type: application/pkcs7-mime
smime-type=CMC-response
--------------------->
POST req: PKIRequest (same request)
Content-Type: application/pkcs10
or
POST req: PKIRequest (CMC Status Info only)
Content-Type: application/pkcs7-mime
smime-type=CMC-request
<--------------------
POST res: PKIResponse
Content-Type: application/pkcs7-mime
smime-type=certs-only
or
POST res: PKIResponse
Content-Type: application/pkcs7-mime
smime-type=CMC-response
With the PAL, the client begins after pulling the PAL and a Start
Issuance PAL package type essentially adding the following before the
request:
Client Server
--------------------->
GET req: PAL
Turner Expires April 15, 2018 [Page 37]
Internet-Draft EST Extensions October 12, 2017
<--------------------
GET res: PAL
Content-Type: application/xml
The client then proceeds as above with a simple PKI Enroll, Full CMC
Enrollment, or begin enrollment assisted with a CSR:
Client Server
--------------------->
GET req: DS certificate with CSR
<--------------------
GET res: PAL
Content-Type: application/csr-attrs
For immediately rejected request, CMC works well. If the server
prematurely closes the connection, then the procedures in Section
8.2.4 of [RFC7231] apply. But, this might leave the client and
server in a different state. The client could merely resubmit the
request but another option, documented herein, is for the client to
instead download the PAL to see if the server has processed the
request. Clients might also use this process when they are unable to
remain connected to the server for the entire enrollment process; if
the server does not or is not able to return a PKIData indicating a
status of pending, then the client will not know whether the request
was received. If a client uses the PAL and reconnects to determine
if the certification or rekey or renew request was processed:
o Clients MUST authenticate the server and clients MUST check the
server's authorization.
o Server MUST authenticate the client and the server MUST check the
client's authorization.
o Clients retrieve the PAL using the /pal URI.
o Clients and servers use the operation path of "/simpleenroll",
"simplereenroll", or "/fullcmc", based on the PAL entry, with an
HTTP GET [RFC7231] to get the success or failure response.
Responses are as specified in [RFC7030].
10. Security Considerations
This document relies on many other specifications; however, all of
the security considerations [RFC7030] apply. For HTTP, HTTPS, and
TLS security considerations see [RFC7231], [RFC2818], and [RFC5246];
for URI security considerations see [RFC3986]; for content type
Turner Expires April 15, 2018 [Page 38]
Internet-Draft EST Extensions October 12, 2017
security considerations see [RFC4073], [RFC4108], [RFC5272],
[RFC5652], [RFC5751], [RFC5934], [RFC5958] [RFC6031], [RFC6032],
[RFC6268], [RFC6402], [RFC7191], and [RFC7292]; for algorithms used
to protect packages see [RFC3370], [RFC5649], [RFC5753], [RFC5754],
[RFC5959], [RFC6033], [RFC6160], [RFC6161], [RFC6162] and [RFC7192];
for random numbers see [RFC4086]; for server-generated asymmetric key
pairs see [RFC7030].
11. IANA Considerations
IANA is requested to create the PAL Package Type registry and perform
three registrations: PAL Name Space, PAL XML Schema, and PAL Package
Types.
11.1. PAL Name Space
This section registers a new XML namespace [XMLNS],
"urn:ietf:params:xml:ns:pal" per the guidelines in [RFC3688]:
URI: urn:ietf:params:xml:ns:pal
Registrant Contact: Sean Turner (sean@sn3rd.com)
XML:
BEGIN
<?xml version="1.0"?>
<!DOCTYPE html PUBLIC "-//W3C//DTD XHTML 1.0 Strict//EN"
"http://www.w3.org/TR/xhtml1/DTD/xhtml1-strict.dtd">
<html xmlns="http://www.w3.org/1999/xhtml" xml:lang="en">
<head>
<title>Package Availability List</title>
</head>
<body>
<h1>Namespace for Package Availability List</h1>
<h2>urn:ietf:params:xml:ns:pal</h2>
<p>See RFC TBD</p>
</body>
</html>
END
11.2. PAL XML Schema
This section registers an XML schema as per the guidelines in
[RFC3688].
URI: urn:ietf:params:xml:schema:pal
Registrant Contact: Sean Turner sean@sn3rd.com
XML: See Section 2.1.2.
Turner Expires April 15, 2018 [Page 39]
Internet-Draft EST Extensions October 12, 2017
11.3. PAL Package Types
IANA is kindly requested to create a new registry named: PAL Package
Type. This registry is for PAL Package Types whose initial values
are found in Section 2.1.1. Future PAL Package Types registrations
are to be subject to Expert Review, as defined in RFC 8126 [RFC8126].
Package types MUST be paired with a media type; package types
specify the path component to be used that in turn specify the media
type used.
12. Acknowledgements
Thanks in no particular order go to Alexey Melnikov, Paul Hoffman,
Brad McInnis, Max Pritikin, Francois Rousseau, Chris Bonatti, and
Russ Housley for taking time to provide comments.
13. References
13.1. Normative References
[RFC2045] Freed, N. and N. Borenstein, "Multipurpose Internet Mail
Extensions (MIME) Part One: Format of Internet Message
Bodies", RFC 2045, DOI 10.17487/RFC2045, November 1996,
<http://www.rfc-editor.org/info/rfc2045>.
[RFC2046] Freed, N. and N. Borenstein, "Multipurpose Internet Mail
Extensions (MIME) Part Two: Media Types", RFC 2046, DOI
10.17487/RFC2046, November 1996, <http://www.rfc-
editor.org/info/rfc2046>.
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
Requirement Levels", BCP 14, RFC 2119, DOI
10.17487/RFC2119, March 1997, <http://www.rfc-
editor.org/info/rfc2119>.
[RFC2585] Housley, R. and P. Hoffman, "Internet X.509 Public Key
Infrastructure Operational Protocols: FTP and HTTP",
RFC 2585, DOI 10.17487/RFC2585, May 1999, <http://www.rfc-
editor.org/info/rfc2585>.
[RFC2818] Rescorla, E., "HTTP Over TLS", RFC 2818, DOI
10.17487/RFC2818, May 2000, <http://www.rfc-
editor.org/info/rfc2818>.
[RFC2985] Nystrom, M. and B. Kaliski, "PKCS #9: Selected Object
Classes and Attribute Types Version 2.0", RFC 2985, DOI
10.17487/RFC2985, November 2000, <http://www.rfc-
editor.org/info/rfc2985>.
Turner Expires April 15, 2018 [Page 40]
Internet-Draft EST Extensions October 12, 2017
[RFC3370] Housley, R., "Cryptographic Message Syntax (CMS)
Algorithms", RFC 3370, DOI 10.17487/RFC3370, August 2002,
<http://www.rfc-editor.org/info/rfc3370>.
[RFC3394] Schaad, J. and R. Housley, "Advanced Encryption Standard
(AES) Key Wrap Algorithm", RFC 3394, DOI 10.17487/RFC3394,
September 2002, <http://www.rfc-editor.org/info/rfc3394>.
[RFC3688] Mealling, M., "The IETF XML Registry", BCP 81, RFC 3688,
DOI 10.17487/RFC3688, January 2004, <http://www.rfc-
editor.org/info/rfc3688>.
[RFC3986] Berners-Lee, T., Fielding, R., and L. Masinter, "Uniform
Resource Identifier (URI): Generic Syntax", STD 66,
RFC 3986, DOI 10.17487/RFC3986, January 2005,
<http://www.rfc-editor.org/info/rfc3986>.
[RFC4073] Housley, R., "Protecting Multiple Contents with the
Cryptographic Message Syntax (CMS)", RFC 4073, DOI
10.17487/RFC4073, May 2005, <http://www.rfc-
editor.org/info/rfc4073>.
[RFC4108] Housley, R., "Using Cryptographic Message Syntax (CMS) to
Protect Firmware Packages", RFC 4108, DOI 10.17487/RFC4108,
August 2005, <http://www.rfc-editor.org/info/rfc4108>.
[RFC4514] Zeilenga, K., Ed., "Lightweight Directory Access Protocol
(LDAP): String Representation of Distinguished Names",
RFC 4514, DOI 10.17487/RFC4514, June 2006, <http://www.rfc-
editor.org/info/rfc4514>.
[RFC5246] Dierks, T. and E. Rescorla, "The Transport Layer Security
(TLS) Protocol Version 1.2", RFC 5246, DOI
10.17487/RFC5246, August 2008, <http://www.rfc-
editor.org/info/rfc5246>.
[RFC5272] Schaad, J. and M. Myers, "Certificate Management over CMS
(CMC)", RFC 5272, DOI 10.17487/RFC5272, June 2008,
<http://www.rfc-editor.org/info/rfc5272>.
[RFC5273] Schaad, J. and M. Myers, "Certificate Management over CMS
(CMC): Transport Protocols", RFC 5273, DOI
10.17487/RFC5273, June 2008, <http://www.rfc-
editor.org/info/rfc5273>.
[RFC5274] Schaad, J. and M. Myers, "Certificate Management Messages
over CMS (CMC): Compliance Requirements", RFC 5274, DOI
10.17487/RFC5274, June 2008, <http://www.rfc-
Turner Expires April 15, 2018 [Page 41]
Internet-Draft EST Extensions October 12, 2017
editor.org/info/rfc5274>.
[RFC5280] Cooper, D., Santesson, S., Farrell, S., Boeyen, S.,
Housley, R., and W. Polk, "Internet X.509 Public Key
Infrastructure Certificate and Certificate Revocation List
(CRL) Profile", RFC 5280, DOI 10.17487/RFC5280, May 2008,
<http://www.rfc-editor.org/info/rfc5280>.
[RFC5649] Housley, R. and M. Dworkin, "Advanced Encryption Standard
(AES) Key Wrap with Padding Algorithm", RFC 5649, DOI
10.17487/RFC5649, September 2009, <http://www.rfc-
editor.org/info/rfc5649>.
[RFC5652] Housley, R., "Cryptographic Message Syntax (CMS)", STD 70,
RFC 5652, DOI 10.17487/RFC5652, September 2009,
<http://www.rfc-editor.org/info/rfc5652>.
[RFC5751] Ramsdell, B. and S. Turner, "Secure/Multipurpose Internet
Mail Extensions (S/MIME) Version 3.2 Message
Specification", RFC 5751, DOI 10.17487/RFC5751, January
2010, <http://www.rfc-editor.org/info/rfc5751>.
[RFC5753] Turner, S. and D. Brown, "Use of Elliptic Curve
Cryptography (ECC) Algorithms in Cryptographic Message
Syntax (CMS)", RFC 5753, DOI 10.17487/RFC5753, January
2010, <http://www.rfc-editor.org/info/rfc5753>.
[RFC5754] Turner, S., "Using SHA2 Algorithms with Cryptographic
Message Syntax", RFC 5754, DOI 10.17487/RFC5754, January
2010, <http://www.rfc-editor.org/info/rfc5754>.
[RFC5934] Housley, R., Ashmore, S., and C. Wallace, "Trust Anchor
Management Protocol (TAMP)", RFC 5934, DOI
10.17487/RFC5934, August 2010, <http://www.rfc-
editor.org/info/rfc5934>.
[RFC5958] Turner, S., "Asymmetric Key Packages", RFC 5958, DOI
10.17487/RFC5958, August 2010, <http://www.rfc-
editor.org/info/rfc5958>.
[RFC5959] Turner, S., "Algorithms for Asymmetric Key Package Content
Type", RFC 5959, DOI 10.17487/RFC5959, August 2010,
<http://www.rfc-editor.org/info/rfc5959>.
[RFC5967] Turner, S., "The application/pkcs10 Media Type", RFC 5967,
DOI 10.17487/RFC5967, August 2010, <http://www.rfc-
editor.org/info/rfc5967>.
Turner Expires April 15, 2018 [Page 42]
Internet-Draft EST Extensions October 12, 2017
[RFC6010] Housley, R., Ashmore, S., and C. Wallace, "Cryptographic
Message Syntax (CMS) Content Constraints Extension",
RFC 6010, DOI 10.17487/RFC6010, September 2010,
<http://www.rfc-editor.org/info/rfc6010>.
[RFC6031] Turner, S. and R. Housley, "Cryptographic Message Syntax
(CMS) Symmetric Key Package Content Type", RFC 6031, DOI
10.17487/RFC6031, December 2010, <http://www.rfc-
editor.org/info/rfc6031>.
[RFC6032] Turner, S. and R. Housley, "Cryptographic Message Syntax
(CMS) Encrypted Key Package Content Type", RFC 6032, DOI
10.17487/RFC6032, December 2010, <http://www.rfc-
editor.org/info/rfc6032>.
[RFC6033] Turner, S., "Algorithms for Cryptographic Message Syntax
(CMS) Encrypted Key Package Content Type", RFC 6033, DOI
10.17487/RFC6033, December 2010, <http://www.rfc-
editor.org/info/rfc6033>.
[RFC6160] Turner, S., "Algorithms for Cryptographic Message Syntax
(CMS) Protection of Symmetric Key Package Content Types",
RFC 6160, DOI 10.17487/RFC6160, April 2011,
<http://www.rfc-editor.org/info/rfc6160>.
[RFC6161] Turner, S., "Elliptic Curve Algorithms for Cryptographic
Message Syntax (CMS) Encrypted Key Package Content Type",
RFC 6161, DOI 10.17487/RFC6161, April 2011,
<http://www.rfc-editor.org/info/rfc6161>.
[RFC6162] Turner, S., "Elliptic Curve Algorithms for Cryptographic
Message Syntax (CMS) Asymmetric Key Package Content Type",
RFC 6162, DOI 10.17487/RFC6162, April 2011,
<http://www.rfc-editor.org/info/rfc6162>.
[RFC6268] Schaad, J. and S. Turner, "Additional New ASN.1 Modules for
the Cryptographic Message Syntax (CMS) and the Public Key
Infrastructure Using X.509 (PKIX)", RFC 6268, DOI
10.17487/RFC6268, July 2011, <http://www.rfc-
editor.org/info/rfc6268>.
[RFC6402] Schaad, J., "Certificate Management over CMS (CMC)
Updates", RFC 6402, DOI 10.17487/RFC6402, November 2011,
<http://www.rfc-editor.org/info/rfc6402>.
[RFC7303] Thompson, H. and C. Lilley, "XML Media Types", RFC 7303,
DOI 10.17487/RFC7303, July 2014, <http://www.rfc-
editor.org/info/rfc7303>.
Turner Expires April 15, 2018 [Page 43]
Internet-Draft EST Extensions October 12, 2017
[RFC7030] Pritikin, M., Ed., Yee, P., Ed., and D. Harkins, Ed.,
"Enrollment over Secure Transport", RFC 7030, DOI
10.17487/RFC7030, October 2013, <http://www.rfc-
editor.org/info/rfc7030>.
[RFC7159] Bray, T., Ed., "The JavaScript Object Notation (JSON) Data
Interchange Format", RFC 7159, DOI 10.17487/RFC7159, March
2014, <http://www.rfc-editor.org/info/rfc7159>.
[RFC7191] Housley, R., "Cryptographic Message Syntax (CMS) Key
Package Receipt and Error Content Types", RFC 7191, DOI
10.17487/RFC7191, April 2014, <http://www.rfc-
editor.org/info/rfc7191>.
[RFC7192] Turner, S., "Algorithms for Cryptographic Message Syntax
(CMS) Key Package Receipt and Error Content Types",
RFC 7192, DOI 10.17487/RFC7192, April 2014,
<http://www.rfc-editor.org/info/rfc7192>.
[RFC7193] Turner, S., Housley, R., and J. Schaad, "The
application/cms Media Type", RFC 7193, DOI
10.17487/RFC7193, April 2014, <http://www.rfc-
editor.org/info/rfc7193>.
[RFC7231] Fielding, R., Ed., and J. Reschke, Ed., "Hypertext Transfer
Protocol (HTTP/1.1): Semantics and Content", RFC 7231, DOI
10.17487/RFC7231, June 2014, <http://www.rfc-
editor.org/info/rfc7231>.
[RFC7292] Moriarty, K., Ed., Nystrom, M., Parkinson, S., Rusch, A.,
and M. Scott, "PKCS #12: Personal Information Exchange
Syntax v1.1", RFC 7292, DOI 10.17487/RFC7292, July 2014,
<http://www.rfc-editor.org/info/rfc7292>.
[RFC8126] Cotton, M., Leiba, B., and T. Narten, "Guidelines for
Writing an IANA Considerations Section in RFCs", BCP 26,
RFC 8126, DOI 10.17487/RFC8126, June 2017, <http://www.rfc-
editor.org/info/rfc8126>.
[XML] W3C, "Extensible Markup Language (XML) 1.0 (Fifth
Edition)", W3C Recommendation, November 2008,
<http://www.w3.org/TR/2006/REC-xml-20060816/>.
[XMLSCHEMA]
Malhotra, A. and P. Biron, "XML Schema Part 2: Datatypes
Second Edition", World Wide Web Consortium Recommendation
REC-xmlschema-2-20041082, October 2004,
<http://www.w3.org/TR/2004/REC-xmlschema-2-20041028>.
Turner Expires April 15, 2018 [Page 44]
Internet-Draft EST Extensions October 12, 2017
[X.690] ITU-T Recommendation X.690 (2002) | ISO/IEC 8825-1:2002.
Information Technology - ASN.1 encoding rules:
Specification of Basic Encoding Rules (BER), Canonical
Encoding Rules (CER) and Distinguished Encoding Rules
(DER).
13.2. Informative References
[RFC2985] Nystrom, M. and B. Kaliski, "PKCS #9: Selected Object
Classes and Attribute Types Version 2.0", RFC 2985, DOI
10.17487/RFC2985, November 2000, <http://www.rfc-
editor.org/info/rfc2985>.
[RFC4086] Eastlake 3rd, D., Schiller, J., and S. Crocker, "Randomness
Requirements for Security", BCP 106, RFC 4086, DOI
10.17487/RFC4086, June 2005, <http://www.rfc-
editor.org/info/rfc4086>.
[RFC4949] Shirey, R., "Internet Security Glossary, Version 2", FYI
36, RFC 4949, DOI 10.17487/RFC4949, August 2007,
<http://www.rfc-editor.org/info/rfc4949>.
[XMLNS] Hollander, D., Bray, T., and A. Layman, "Namespaces in
XML", World Wide Web Consortium First Edition REC-xml-
names-19990114, January 1999,
<http://www.w3.org/TR/1999/REC-xml-names-19990114>.
Appendix A. Example Use of PAL
This is an informative appendix. It includes examples protocol
flows.
Steps for using a PAL include:
1. Access PAL
2. Process PAL entries
2.1. Get CA Certificates
2.2. Get CRLs
2.3. Get CSR attributes
2.4. Enroll: simple enrollment, re-enrollment, or full CMC
2.5. Get Firmware, TAMP, Symmetric Keys, or EE Certificates
Client Server
---------------------> -+
GET req: | /pal
<--------------------- |
GET res: PAL |
Content-Type: application/xml |
Turner Expires April 15, 2018 [Page 45]
Internet-Draft EST Extensions October 12, 2017
|
---------------------> -+
GET req: | /cacerts
<--------------------- |
GET res: CA Certificates |
Content-Type: application/pkcs7-smime |
smime-type=certs-only |
|
---------------------> -+
GET req: | /crls
<--------------------- |
GET res: CRLs |
Content-Type: application/pkcs7-smime |
smime-type=crls-only |
|
---------------------> -+
GET req: | /csrattrs
<--------------------- |
GET res: attributes |
---------------------> -+
POST req: PKIRequest | /simpleenroll &
Content-Type: application/pkcs10 | /simplereenroll
|
Content-Type: application/pkcs7-mime | /fullcmc
smime-type=CMC-request |
|
<-------------------- |
(success or failure) |
POST res: PKIResponse | /simpleenroll
Content-Type: application/pkcs7-mime | /simplereenroll
smime-type=certs-only | /fullcmc
|
Content-Type: application/pkcs7-mime | /fullcmc
smime-type=CMC-response |
|
--------------------> -+
GET req: | /firmware
<-------------------- | /tamp
GET res: Firmware, TAMP Query | /symmetrickeys
+ Updates, Symmetric Keys |
Content-Type: application/cms |
|
---------------------> -+
POST res: Firmware Receipts or Errors, | /firmware/return
TAMP Response or Confirms or Errors, | /tamp/return
Symmetric Key Receipts or Errors, | /symmetrickeys/
| return
|
Turner Expires April 15, 2018 [Page 46]
Internet-Draft EST Extensions October 12, 2017
Content-Type: application/cms |
<-------------------- |
POST res: empty |
(success or failure) |
--------------------> -+
GET req: | /eecerts
<-------------------- |
GET res: Other EE certificates |
Content-Type: application/pkcs7-mime |
smime-type=certs-only |
The figure above shows /eecerts after /*/return, but this is for
illustrative purposes only.
Appendix B. Additional CSR Attributes
This is an informative appendix.
In some cases, the client is severely limited in its ability to
encode and decode ASN.1 objects. If the client knows a csr template
is being provided during enrollment, then it can peel the returned
csr attribute, generate its keys, place the public key in the
certification request, and then sign the request. To accomplish
this, the server returns a PKCS7PDU attribute [RFC2985] in as part of
the /csrattrs (the following is pseudo ASN.1 and is only meant to
show the fields needed to accomplish returning a template
certification request):
pKCS7PDU ATTRIBUTE ::= {
WITH SYNTAX ContentInfo
ID pkcs-9-at-pkcs7PDU
}
pkcs-9-at-pkcs7PDU OBJECT IDENTIFIER ::= {
iso(1) member-body(2) us(840) rsadsi(113549) pkcs(1) pkcs9(9)
at(25) 5
}
The ContentInfo is a PKIData:
PKIData ::= SEQUENCE {
reqSequence SEQUENCE SIZE(0..MAX) OF TaggedRequest,
}
Where TaggedRequest is a choice between the PKCS #10 or CRMF
requests.
TaggedRequest ::= CHOICE {
Turner Expires April 15, 2018 [Page 47]
Internet-Draft EST Extensions October 12, 2017
tcr [0] TaggedCertificationRequest,
crm [1] CertReqMsg,
}
Or, the Content Info can be a signed data content type that further
encapsulates a PKIData.
Authors' Addresses
Sean Turner
sn3rd
EMail: sean@sn3rd.com
Turner Expires April 15, 2018 [Page 48]
