< draft-turner-est-extensions-08.txt   draft-turner-est-extensions-11.txt >
Network Working Group Sean Turner Network Working Group Sean Turner
Internet Draft sn3rd Internet Draft sn3rd
Intended Status: Standards Track January 22, 2017 Intended Status: Standards Track October 12, 2017
Expires: July 26, 2017 Expires: April 15, 2018
EST Extensions EST (Enrollment over Secure Transport) Extensions
draft-turner-est-extensions-08.txt draft-turner-est-extensions-11.txt
Abstract Abstract
The EST (Enrollment over Secure Transport) protocol defined a Well- The EST (Enrollment over Secure Transport) protocol defined a Well-
Known URI (Uniform Resource Identifier): /.well-known/est. EST also Known URI (Uniform Resource Identifier): /.well-known/est along with
defined several path components that clients use for PKI (Public Key a number of other path components that clients use for PKI (Public
Infrastructure) services, namely certificate enrollment (e.g., Key Infrastructure) services, namely certificate enrollment (e.g.,
/simpleenroll). In some sense, the services provided by the path /simpleenroll). This document defines a number of other PKI services
components can be thought of as PKI management-related packages. as additional path components, specifically firmware and trust
There are additional PKI-related packages a client might need as well anchors as well as symmetric, asymmetric, and encrypted keys. This
as other security-related packages, such as firmware, trust anchors, document also specifies the PAL (Package Availability List), which is
and symmetric, asymmetric, and encrypted keys. This document also an XML (Extensible Markup Language) file or JSON (JavaScript Object
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 Notation) object that clients use to retrieve packages available and
authorized for them. This document extends the EST server path authorized for them. This document extends the EST server path
components to provide these additional services. components to provide these additional services.
Status of this Memo Status of this Memo
This Internet-Draft is submitted in full conformance with the This Internet-Draft is submitted in full conformance with the
provisions of BCP 78 and BCP 79. provisions of BCP 78 and BCP 79.
Internet-Drafts are working documents of the Internet Engineering Internet-Drafts are working documents of the Internet Engineering
skipping to change at page 2, line 18 skipping to change at page 2, line 16
the Trust Legal Provisions and are provided without warranty as the Trust Legal Provisions and are provided without warranty as
described in the Simplified BSD License. described in the Simplified BSD License.
Table of Contents Table of Contents
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3
1.1. Definitions . . . . . . . . . . . . . . . . . . . . . . . 5 1.1. Definitions . . . . . . . . . . . . . . . . . . . . . . . 5
1.2. Authentication and Authorization . . . . . . . . . . . . . 6 1.2. Authentication and Authorization . . . . . . . . . . . . . 6
1.3. TLS Cipher Suites . . . . . . . . . . . . . . . . . . . . 6 1.3. TLS Cipher Suites . . . . . . . . . . . . . . . . . . . . 6
1.4. URI Configuration . . . . . . . . . . . . . . . . . . . . 6 1.4. URI Configuration . . . . . . . . . . . . . . . . . . . . 6
1.5. Content-Transfer-Encoding . . . . . . . . . . . . . . . . 6 1.5. Message Types . . . . . . . . . . . . . . . . . . . . . . 6
1.6. Message Types . . . . . . . . . . . . . . . . . . . . . . 7 1.6. Key Words . . . . . . . . . . . . . . . . . . . . . . . . 8
1.7. Key Words . . . . . . . . . . . . . . . . . . . . . . . . 9
2. Locate Available Packages . . . . . . . . . . . . . . . . . . 9 2. Locate Available Packages . . . . . . . . . . . . . . . . . . 9
2.1. PAL Format . . . . . . . . . . . . . . . . . . . . . . . . 10 2.1. PAL Format . . . . . . . . . . . . . . . . . . . . . . . . 11
2.1.1. PAL Package Types . . . . . . . . . . . . . . . . . . 11 2.1.1. PAL Package Types . . . . . . . . . . . . . . . . . . 12
2.1.2. PAL XML Schema . . . . . . . . . . . . . . . . . . . . 16 2.1.2. PAL XML Schema . . . . . . . . . . . . . . . . . . . . 17
2.1.3. PAL JSON Object . . . . . . . . . . . . . . . . . . . 19 2.1.3. PAL JSON Object . . . . . . . . . . . . . . . . . . . 20
2.2. Request PAL . . . . . . . . . . . . . . . . . . . . . . . 20 2.2. Request PAL . . . . . . . . . . . . . . . . . . . . . . . 21
2.3. Provide PAL . . . . . . . . . . . . . . . . . . . . . . . 20 2.3. Provide PAL . . . . . . . . . . . . . . . . . . . . . . . 21
3. Distribute EE Certificates . . . . . . . . . . . . . . . . . . 21 3. Distribute EE Certificates . . . . . . . . . . . . . . . . . . 22
3.1. EE Certificate Request . . . . . . . . . . . . . . . . . . 22 3.1. EE Certificate Request . . . . . . . . . . . . . . . . . . 23
3.2. EE Certificate Response . . . . . . . . . . . . . . . . . 22 3.2. EE Certificate Response . . . . . . . . . . . . . . . . . 23
4. Distribute CRLs and ARLs . . . . . . . . . . . . . . . . . . . 22 4. Distribute CRLs and ARLs . . . . . . . . . . . . . . . . . . . 23
4.1. CRL Request . . . . . . . . . . . . . . . . . . . . . . . 23 4.1. CRL Request . . . . . . . . . . . . . . . . . . . . . . . 23
4.2. CRL Response . . . . . . . . . . . . . . . . . . . . . . . 23 4.2. CRL Response . . . . . . . . . . . . . . . . . . . . . . . 24
5. Symmetric Keys, Receipts, and Errors . . . . . . . . . . . . . 23 5. Symmetric Keys, Receipts, and Errors . . . . . . . . . . . . . 24
5.1. Symmetric Keys . . . . . . . . . . . . . . . . . . . . . . 23 5.1. Symmetric Keys . . . . . . . . . . . . . . . . . . . . . . 24
5.1.1. Distribute Symmetric Keys . . . . . . . . . . . . . . 24 5.1.1. Distribute Symmetric Keys . . . . . . . . . . . . . . 25
5.1.2. Symmetric Key Response . . . . . . . . . . . . . . . . 24 5.1.2. Symmetric Key Response . . . . . . . . . . . . . . . . 25
5.2. Symmetric Key Receipts and Errors . . . . . . . . . . . . 25 5.2. Symmetric Key Receipts and Errors . . . . . . . . . . . . 26
5.2.1. Provide Symmetric Key Receipt or Error . . . . . . . . 26 5.2.1. Provide Symmetric Key Receipt or Error . . . . . . . . 27
5.2.2. Symmetric Key Receipt or Error Response . . . . . . . 27 5.2.2. Symmetric Key Receipt or Error Response . . . . . . . 28
6. Firmware, Receipts, and Errors . . . . . . . . . . . . . . . . 27 6. Firmware, Receipts, and Errors . . . . . . . . . . . . . . . . 28
6.1. Firmware . . . . . . . . . . . . . . . . . . . . . . . . . 27 6.1. Firmware . . . . . . . . . . . . . . . . . . . . . . . . . 28
6.1.1. Distribute Firmware . . . . . . . . . . . . . . . . . 27 6.1.1. Distribute Firmware . . . . . . . . . . . . . . . . . 28
6.1.2. Firmware Response . . . . . . . . . . . . . . . . . . 28 6.1.2. Firmware Response . . . . . . . . . . . . . . . . . . 29
6.2. Firmware Receipts and Errors . . . . . . . . . . . . . . . 28 6.2. Firmware Receipts and Errors . . . . . . . . . . . . . . . 29
6.2.1. Provide Firmware Receipt or Error . . . . . . . . . . 29 6.2.1. Provide Firmware Receipt or Error . . . . . . . . . . 30
6.2.2. Firmware Receipt or Error Response . . . . . . . . . . 29 6.2.2. Firmware Receipt or Error Response . . . . . . . . . . 30
7. Trust Anchor Management Protocol . . . . . . . . . . . . . . . 29 7. Trust Anchor Management Protocol . . . . . . . . . . . . . . . 30
7.1. TAMP Status Query, Trust Anchor Update, Apex Trust 7.1. TAMP Status Query, Trust Anchor Update, Apex Trust
Anchor Update, . . . . . . . . . . . . . . . . . . . . . . 30 Anchor Update, . . . . . . . . . . . . . . . . . . . . . . 31
Community Update, and Sequence Number Adjust . . . . . . . . 31
7.1.1. Request TAMP Packages . . . . . . . . . . . . . . . . 31
7.1.2. Return TAMP Packages . . . . . . . . . . . . . . . . . 31
Community Update, and Sequence Number Adjust . . . . . . . . 30 7.2. TAMP Response, Confirm, and Errors . . . . . . . . . . . . 32
7.1.1. Request TAMP Packages . . . . . . . . . . . . . . . . 30 7.2.1. Provide TAMP Response, Confirm, or Error . . . . . . . 32
7.1.2. Return TAMP Packages . . . . . . . . . . . . . . . . . 30 7.2.2. TAMP Response, Confirm, and Error Response . . . . . . 32
7.2. TAMP Response, Confirm, and Errors . . . . . . . . . . . . 31 8. Asymmetric Keys, Receipts, and Errors . . . . . . . . . . . . 33
7.2.1. Provide TAMP Response, Confirm, or Error . . . . . . . 31 8.1. Asymmetric Key Encapsulation . . . . . . . . . . . . . . . 33
7.2.2. TAMP Response, Confirm, and Error Response . . . . . . 31 8.2. Asymmetric Key Package Receipts and Errors . . . . . . . . 34
8. Asymmetric Keys, Receipts, and Errors . . . . . . . . . . . . 32 8.3. PKCS#12 . . . . . . . . . . . . . . . . . . . . . . . . . 35
8.1. Asymmetric Key Encapsulation . . . . . . . . . . . . . . . 32 8.3.1. Server-Side Key Generation Request . . . . . . . . . . 35
8.2. Asymmetric Key Package Receipts and Errors . . . . . . . . 33 8.3.2. Server-Side Key Generation Response . . . . . . . . . 35
8.3. PKCS#12 . . . . . . . . . . . . . . . . . . . . . . . . . 34 9. PAL & Certificate Enrollment . . . . . . . . . . . . . . . . . 36
8.3.1. Server-Side Key Generation Request . . . . . . . . . . 34 10. Security Considerations . . . . . . . . . . . . . . . . . . . 38
8.3.2. Server-Side Key Generation Response . . . . . . . . . 34 11. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 39
9. PAL & Certificate Enrollment . . . . . . . . . . . . . . . . . 34 11.1. PAL Name Space . . . . . . . . . . . . . . . . . . . . . 39
10. Security Considerations . . . . . . . . . . . . . . . . . . . 37 11.2. PAL XML Schema . . . . . . . . . . . . . . . . . . . . . 39
11. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 38 11.3. PAL Package Types . . . . . . . . . . . . . . . . . . . . 40
11.1. PAL Name Space . . . . . . . . . . . . . . . . . . . . . 38 12. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 40
11.2. PAL Schema . . . . . . . . . . . . . . . . . . . . . . . 38 13. References . . . . . . . . . . . . . . . . . . . . . . . . . 40
11.3. PAL Package Types . . . . . . . . . . . . . . . . . . . . 38 13.1. Normative References . . . . . . . . . . . . . . . . . . 40
12. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 39 13.2. Informative References . . . . . . . . . . . . . . . . . 45
13. References . . . . . . . . . . . . . . . . . . . . . . . . . 39 Appendix A. Example Use of PAL . . . . . . . . . . . . . . . . . 45
13.1. Normative References . . . . . . . . . . . . . . . . . . 39 Appendix B. Additional CSR Attributes . . . . . . . . . . . . . . 47
13.2. Informative References . . . . . . . . . . . . . . . . . 44 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 48
Appendix A. Example Use of PAL . . . . . . . . . . . . . . . . . 44
Appendix B. Additional CSR Attributes . . . . . . . . . . . . . . 46
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 47
1. Introduction 1. Introduction
The EST (Enrollment over Secure Transport) protocol [RFC7030] defines The EST (Enrollment over Secure Transport) protocol [RFC7030] defines
the Well-Known URI (Uniform Resource Identifier) /.well-known/est to the Well-Known URI (Uniform Resource Identifier) /.well-known/est to
support selected PKI (Public Key Infrastructure) related services support selected PKI (Public Key Infrastructure) related services
with path components (PCs) such as simple enrollment with with path components (PCs) such as simple enrollment with
/simpleenroll, rekey/renew with /simplereenroll, etc. A server that /simpleenroll, rekey or renew with /simplereenroll, etc. A server
wishes to support additional PKI-related services and other security- that wishes to support additional PKI-related services and other
related packages could use the same .well-known URI by defining security-related packages could use the same .well-known URI by
additional PCs. This document defines six such PCs: defining additional PCs. This document defines six such PCs:
o /pal - The PAL (Package Availability List) provides a list of all o /pal - The PAL (Package Availability List) provides a list of all
known packages available and authorized for a client. By known packages available and authorized for a client. By
accessing the service provided by this PC first, the client can accessing the service provided by this PC first, the client can
walk through the PAL and download all the packages necessary to walk through the PAL and download all the packages necessary to
begin operating securely. The PAL essentially points to other begin operating securely. The PAL essentially points to other
PCs including the ones defined in this document as well as those PCs including the ones defined in this document as well as those
defined in [RFC7030], which include /cacerts, /simpleenroll, defined in [RFC7030], which include /cacerts, /simpleenroll,
/simplereenroll, /fullcmc, /serverkeygen, and /csrattrs. The /simplereenroll, /fullcmc, /serverkeygen, and /csrattrs. The
/pal PC is described in Section 2. /pal PC is described in Section 2.
o /eecerts - EE (End-Entity) certificates are needed by the client o /eecerts - EE (End-Entity) certificates [RFC5280] are needed by
when they invoke a security protocol for communicating with a the client when they invoke a security protocol for communicating
peer (i.e., they become operational and do something meaningful with a peer (i.e., they become operational and do something
as opposed to just communicating with the infrastructure). If meaningful as opposed to just communicating with the
the infrastructure knows the certificate(s) needed by the client, infrastructure). If the infrastructure knows the certificate(s)
then providing the peer's certificate avoids the client having to needed by the client, then providing the peer's certificate
discover the peer's certificate. This service is not meant to be avoids the client having to discover the peer's certificate.
a general purpose repository to which clients query a This service is not meant to be a general purpose repository to
"repository" and then get a response; this is purely a push which clients query a "repository" and then get a response; this
mechanism. The /eecerts PC is described in Section 3. is purely a push mechanism. The /eecerts PC is described in
Section 3.
o /crls - CRLs (Certificate Revocation Lists) and Authority o /crls - CRLs (Certificate Revocation Lists) and Authority
Revocation Lists (ARLs) are also needed by the client when they Revocation Lists (ARLs) [RFC5280] are also needed by the client
validate certificate paths. CRLs (and ARLs) from TAs (Trust when they validate certificate paths. CRLs (and ARLs) from TAs
Anchors) and intermediate CAs (Certification Authorities) are (Trust Anchors) and intermediate CAs (Certification Authorities)
needed to validate the certificates used to generate the client's are needed to validate the certificates used to generate the
certificate or the peer's certificate, which is provided by the client's certificate or the peer's certificate, which is provided
/eecerts PC, and providing them saves the client from having to by the /eecerts PC, and providing them saves the client from
"discover" them and then retrieve them. CRL "discovery" is having to "discover" them and then retrieve them. CRL
greatly aided by the inclusion of the CRL Distribution Point "discovery" is greatly aided by the inclusion of the CRL
certificate extension [RFC5280], but this extension is not always Distribution Point certificate extension [RFC5280], but this
present in certificates and requires another connection to extension is not always present in certificates and requires
retrieve them. Like the /eecerts PC, this service is not meant another connection to retrieve them. Like the /eecerts PC, this
to be a general purpose repository to which clients query a service is not meant to be a general purpose repository to which
repository and then get a response; this is purely a push clients query a repository and then get a response; this is
mechanism. The /crls PC is described in Section 4. purely a push mechanism. The /crls PC is described in Section 4.
o /symmetrickeys - In some cases, clients use symmetric keys when o /symmetrickeys - In some cases, clients use symmetric keys
communicating with their peers. If the client's peers are known [RFC6031] when communicating with their peers. If the client's
by the server a priori, then providing them saves the client or peers are known by the server a priori, then providing them saves
an administrator from later having to find, retrieve and install the client or an administrator from later having to find,
them. Like the /eecerts and /crls PCs, this service is not meant retrieve and install them. Like the /eecerts and /crls PCs, this
to be a general purpose repository to which clients query a service is not meant to be a general purpose repository to which
repository and then get a response; this is purely a push clients query a repository and then get a response; this is
mechanism for the keys themselves. However, things do not always purely a push mechanism for the keys themselves. However, things
go as planned and clients need to inform the server about any do not always go as planned and clients need to inform the server
errors. If things did go well, then the client, if requested, about any errors. If things did go well, then the client, if
needs to provide a receipt. The /symmetrickeys and requested, needs to provide a receipt [RFC7191]. The
/symmetrickeys/return PCs are described in Section 5. /symmetrickeys and /symmetrickeys/return PCs are described in
Section 5.
o /firmware - Some client firmware and software support automatic o /firmware - Some client firmware and software support automatic
updates mechanism and some do not. For those that do not, the update mechanisms and some do not. For those that do not, the
/firmware PC provides a mechanism for the infrastructure to /firmware PC provides a mechanism for the infrastructure to
inform the client that a firmware and software updates are inform the client that firmware and software updates [RFC4108]
available. Because updates do not always go as planned and are available. Because updates do not always go as planned and
because sometimes the server needs to know whether the firmware because sometimes the server needs to know whether the firmware
was received and processed, this PC also provides a mechanism to was received and processed, this PC also provides a mechanism to
return errors and receipts. The /firmware and /firmware/return return errors and receipts. The /firmware and /firmware/return
PCs are defined in Section 6. PCs are defined in Section 6.
o /tamp - To control the TAs in client TA databases, servers use o /tamp - To control the TAs in client TA databases, servers use
the /tamp PC to request that clients retrieve a TAMP query, the /tamp PC to request that clients retrieve a TAMP (Trust
update, and adjust packages and clients use the /tamp/return PC Anchor Management Protocol) query, update, and adjust packages
to return response, confirm, and error. The /tamp and [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. /tamp/return PCs are defined in Section 7.
This document also extends the /est/serverkeygen PC [RFC7030] to This document also extends the /est/serverkeygen PC [RFC7030] to
support (see Section 8): support (see Section 8):
o Returning asymmetric key package receipts and errors. o Returning asymmetric key package receipts and errors [RFC7191].
o Encapsulating returned asymmetric keys in additional CMS content o Encapsulating returned asymmetric keys in additional CMS content
types. types [RFC7193].
o Returning server-generated public key pairs encapsulated in o Returning server-generated public key pairs encapsulated in
PKCS#12 [RFC7292]. PKCS#12 [RFC7292].
While the motivation is to provide packages to clients during While the motivation is to provide packages to clients during
enrollment so that they can perform securely after enrollment, the enrollment so that they can perform securely after enrollment, the
services defined in this specification can be used after enrollment. services defined in this specification can be used after enrollment.
1.1. Definitions 1.1. Definitions
Familiarity with Using Cryptographic Message Syntax (CMS) to Protect Familiarity with Using Cryptographic Message Syntax (CMS) to Protect
Firmware Packages [RFC4108], Certificate Management over CMS (CMC) Firmware Packages [RFC4108], Certificate Management over CMS (CMC)
[RFC5272], Cryptographic Message Syntax (CMS) Encrypted Key Package [RFC5272], Cryptographic Message Syntax (CMS) Encrypted Key Package
[RFC6032], Cryptographic Message Syntax (CMS) [RFC5652][RFC6268], [RFC6032], Cryptographic Message Syntax (CMS) [RFC5652][RFC6268],
Trust Anchor Management Protocol (TAMP) [RFC5934], Cryptographic Trust Anchor Management Protocol (TAMP) [RFC5934], Cryptographic
Message Syntax (CMS) Content Constraints Extension [RFC6010], CMS Message Syntax (CMS) Content Constraints Extension [RFC6010], CMS
Symmetric Key Package Content Type [RFC6031], Enrollment over Secure Symmetric Key Package Content Type [RFC6031], Enrollment over Secure
Transport protocol [RFC7030], CMS Key Package Receipt and Error Transport protocol [RFC7030], CMS Key Package Receipt and Error
Content Types [RFC7191] is assumed. Also, familiarity with the CMS Content Types [RFC7191] is assumed. Also, familiarity with the CMS
protecting content types signed data and encrypted data is assumed; protecting content types signed data and encrypted data is assumed;
CMS signed data and encrypted data are defined in [RFC5652] and CMS signed data and encrypted data are defined in [RFC5652] and CMS
encrypted key package is defined in [RFC6032]. encrypted key package is defined in [RFC6032].
In addition to the definitions found in [RFC7030], the following In addition to the definitions found in [RFC7030], the following
definitions are used in this document: definitions are used in this document:
Agent: An entity that performs functions on behalf of a client. 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 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 server, b) clients on non-IP based networks, or c) clients that have
an air gap [RFC4949] between themselves and the server; interactions a non-electronic air gap [RFC4949] between themselves and the server.
between the agent and client in the last two cases are beyond the Interactions between the agent and client in the last two cases are
scope of this document. Before an agent can service clients, the beyond the scope of this document. Before an agent can service
agent must have a trust relationship with the server, be authorized clients, the agent must have a trust relationship with the server, be
to act on behalf of clients. authorized to act on behalf of clients.
Client: A device that ultimately consumes and uses the packages to Client: A device that ultimately consumes and uses the packages to
enable communications. In other words, the client is the end-point 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 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 confusion, this document henceforth uses the term client to refer to
both agents and clients. both agents and clients.
Package: An object that contains one or more content types. There Package: An object that contains one or more content types. There
are numerous types of packages: Asymmetric Keys, Symmetric Keys, are numerous types of packages: Asymmetric Keys, Symmetric Keys,
Encrypted Keys, CRLs, Public Key Certificate Management, Firmware, Encrypted Keys, CRLs, Public Key Certificate Management, Firmware,
Public Key Certificates, and TAMP packages. All of these packages Public Key Certificates, and TAMP packages. All of these packages
are digitally signed and encapsulated in a CMS signed data are digitally signed by their creator and encapsulated in a CMS
[RFC5652][RFC6268] (except the public key certificates and CRLs that signed data [RFC5652][RFC6268] (except the public key certificates
are already digitally signed); Firmware receipts and errors, TAMP and CRLs that are already digitally signed by a CA); Firmware
responses, confirms, and errors, as well as Key Package receipts and receipts and errors, TAMP responses, confirms, and errors, as well as
errors can be optionally signed. Certificate and CRLs are included Key Package receipts and errors that can be optionally signed.
in a package that uses signed data, which is often referred to as a Certificate and CRLs are included in a package that uses signed data,
degenerate CMS or "certs-only" or "crls-only" message which is often referred to as a degenerate CMS or "certs-only" or
[RFC5751][RFC6268], but no signature or content is present; hence the "crls-only" message [RFC5751][RFC6268], but no signature or content
name certs-only and crls-only. 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 1.2. Authentication and Authorization
Client and server authentication as well as client and server Client and server authentication as well as client and server
authorization are as defined in [RFC7030]. The requirements for each authorization are as defined in [RFC7030]. The requirements for each
are discussed in the request and response sections of each of the PCs are discussed in the request and response sections of each of the PCs
defined by this document. defined by this document.
The requirements for the TA databases are as specified in [RFC7030] The requirements for the TA databases are as specified in [RFC7030]
as well. as well.
skipping to change at page 6, line 48 skipping to change at page 6, line 50
TLS cipher suite and issues associated with them are as defined in TLS cipher suite and issues associated with them are as defined in
[RFC7030]. [RFC7030].
1.4. URI Configuration 1.4. URI Configuration
As specified in Section 3.1 of [RFC7030], the client is configured As specified in Section 3.1 of [RFC7030], the client is configured
with sufficient information to form the server URI [RFC3986]. Like with sufficient information to form the server URI [RFC3986]. Like
EST, this configuration mechanism is beyond the scope of this EST, this configuration mechanism is beyond the scope of this
document. document.
1.5. Content-Transfer-Encoding 1.5. Message Types
A Content-Transfer encoding of "base64" [RFC2045] is used for all
client server interactions.
1.6. Message Types
This document uses existing media types for the messages as specified This document uses existing media types for the messages as specified
by FTP and HTTP [RFC2585], application/pkcs10 [RFC5967], and CMC by "Internet X.509 Public Key Infrastructure Protocol: FTP and HTTP"
[RFC2585], "The application/pkcs10 Media Type" [RFC5967], and CMC
[RFC5272]. [RFC5272].
For consistency with [RFC5273], each distinct EST message type uses For consistency with [RFC5273], each distinct EST message type uses
an HTTP Content-Type header with a specific media type. an HTTP Content-Type header with a specific media type.
The EST messages and their corresponding media types for each The EST messages and their corresponding media types for each
operation are: operation are:
+--------------------+--------------------------+-------------------+ +--------------------+--------------------------+-------------------+
| Message type | Request media type | Request section(s)| | Message type | Request media type | Request section(s)|
| | Response media type(s) | Response section | | | Response media type(s) | Response section |
| (per operation) | Source(s) of types | | | (per operation) | Source(s) of types | |
+====================+==========================+===================+ +====================+==========================+===================+
| Locate Available | N/A | Section 2.2 | | Locate Available | N/A | Section 2.2 |
| Packages | application/xml or | Section 2.3 | | Packages | application/xml or | Section 2.3 |
| | application/json | | | | application/json | |
| | [RFC7303][RFC4627] | | | | [RFC7303][RFC7159] | |
| /pal | | | | /pal | | |
+====================+==========================+===================+ +====================+==========================+===================+
| Distribute EE | N/A | Section 3.1 | | Distribute EE | N/A | Section 3.1 |
| Certificates | application/pkcs7-mime | Section 3.2 | | Certificates | application/pkcs7-mime | Section 3.2 |
| | [RFC5751] | | | | [RFC5751] | |
| /eecerts | | | | /eecerts | | |
+====================+==========================+===================+ +====================+==========================+===================+
| Distribute CRLs | N/A | Section 4.1 | | Distribute CRLs | N/A | Section 4.1 |
| | application/pkcs7-mime | Section 4.2 | | | application/pkcs7-mime | Section 4.2 |
| | [RFC5751] | | | | [RFC5751] | |
skipping to change at page 9, line 5 skipping to change at page 8, line 50
| /serverkeygen/ | | | | /serverkeygen/ | | |
| return | | | | return | | |
+====================+==========================+===================+ +====================+==========================+===================+
| Server-Side Key | application/pkcs10 | Section 8.3.1 | | Server-Side Key | application/pkcs10 | Section 8.3.1 |
| Generation: | application/pkcs12 | Section 8.3.2 | | Generation: | application/pkcs12 | Section 8.3.2 |
| PKCS#12 | | | | PKCS#12 | | |
| | | | | | | |
| /serverkeygen | [RFC7193] | | | /serverkeygen | [RFC7193] | |
+====================+==========================+===================+ +====================+==========================+===================+
1.7. Key Words 1.6. Key Words
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
"SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and
"OPTIONAL" in this document are to be interpreted as described in "OPTIONAL" in this document are to be interpreted as described in
[RFC2119]. [RFC2119].
2. Locate Available Packages 2. Locate Available Packages
The PAL (Package Availability List) is either an XML (Extensible The PAL (Package Availability List) is either an XML (Extensible
Markup Language) file [XML] or JSON (Javascript Object Notation) Markup Language) [XML] or JSON (JavasScript Object Notation)
[RFC7159] object that furnishes information for packages that are [RFC7159] object available through the /pal PC that furnishes the
currently available and authorized for retrieval by a client. It following information to clients:
provides client specific:
o Advertisements for available packages that can be retrieved from o Advertisements for available packages that can be retrieved from
the server; the server;
o Notifications to begin public key certificate management or to o Notifications to begin public key certificate management or to
return package receipts and errors; and return package receipts and errors; and
o Advertisement for another PAL.
A client can use this service to determine all of the security- o Advertisement for another PAL.
related products for bootstrapping or to periodically poll the server
in order to determine if there are updated packages available for it.
To get the /pal PC, the client and server need to mutually After being configured (see Section 1.4), the client can use this
authenticate each other with TLS and authorize each other. Clients service to retrieve their PAL (see Section 2.1) that, if properly
retrieve their PAL and processes it to determine the packages constructed (see Section 2.3), allows the client to determine some or
available for it. Clients include the HTTP Accept header [RFC2616] all of the security-related packages needed for bootstrapping. Each
to indicate whether they support XML or JSON. 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 Client | Establish TLS | Server
| Session | | Session |
|<-------------------->| |<-------------------->|
| | | |
| Request PAL | | Request PAL |
| (HTTP GET Request) | | (HTTP GET Request) |
|--------------------->| |--------------------->|
|<---------------------| |<---------------------|
skipping to change at page 10, line 15 skipping to change at page 10, line 20
| Deliver requested | | Deliver requested |
| CMS package product | | CMS package product |
| (HTTP GET or POST | | (HTTP GET or POST |
| Response) | | Response) |
| | | |
repeat as necessary repeat as necessary
Figure 1 - /pal Message Sequence 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 authenticate the server as specified in [RFC7030] and
the client MUST verify server's authorization as specified in the client MUST check the server's authorization as specified in
[RFC7030]. [RFC7030].
The server MUST authenticate the client as specified in [RFC7030] and The server MUST authenticate the client as specified in [RFC7030] and
the server MUST verify client authorization as specified in the server MUST check the client's authorization as specified in
[RFC7030]. [RFC7030].
PAL support is OPTIONAL. It is shown in figures throughout this PAL support is OPTIONAL. It is shown in figures throughout this
document but clients need not support the PAL to access services document but clients need not support the PAL to access services
offered by the server. offered by the server.
2.1. PAL Format 2.1. PAL Format
Each PAL is composed of zero (i.e., minOccurs=0) or more entries (an Each PAL is composed of zero or more entries. Each entry is composed
array in JSON), each of which is composed of the following four of four fields, type, date, size, and info, whose semantics follow:
elements all of which MUST be present (i.e., minOccurs=1):
o The <type> element uniquely identifies each package that a client Note: Both XML elements and JSON values are described below. XML
may retrieve from the server with a 4-digit field (a number in elements are enclosed in angle brackets <> and JSON values are
JSON). The PAL Package Types are defined in Section 2.1.1. enclosed in single quotes ''. When described together they are
enclosed in brackets [] separated by |.
o The <date> element is a 20-character field (a string in JSON) o [<type> | 'type'] uniquely identifies each package that a client
that contains either: 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.
* The date and time (expressed as Generalized Time: YYYY-MM- o [<date> | 'date'] either indicates:
DDTHH:MM:SSZ) that the client last successfully downloaded the
identified package from the server, or
* 0001-01-01T00:00:00Z (i.e., 0), if: * 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 - There is no indication the client has successfully downloaded
the identified package, or the identified package, or
- The PAL entry corresponds to a pointer to the next PAL or the - The PAL entry corresponds to a pointer to the next PAL or the
server is requesting a package from the client (e.g., server is requesting a package from the client (e.g.,
certification request, receipt, error). certification request, receipt, error).
o The <size> element indicates the size in bytes of the package (a o [<size> | 'size'] indicates the size in bytes of the package;
number in JSON). A package size of zero (i.e., "0" without the <size> is a nonNegativeInteger and 'size' is a number. A package
quotes) indicates that the client needs to begin a transaction or size of zero (i.e., "0" without the quotes) indicates that the
return an error or receipt. client needs to begin a transaction or return an error or
receipt. [<size> | 'size'] MUST be present.
o The <info> element provides either an SKI (Subject Key o [<info> | 'info'] provides either an SKI (Subject Key
Identifier), DN (Distinguished Name), Issuer and Serial Number Identifier), a DN (Distinguished Name), an Issuer and Serial
tuple or a URI (a string in JSON). When a URI [RFC3986] is Number tuple or a URI, i.e., it is a choice between these four
included it indicates the location where the identified package all of which are defined in [RFC5280]. When a URI [RFC3986] is
can be retrieved. When a DN, SKI, or Issuer Name and Serial included, [<uri> | 'uri'] indicates the location where the
Number tuple is included it points to a certificate that is the identified package can be retrieved. When a DN, an SKI, or an
subject of the notification (i.e., the certificate to be Issuer Name and Serial Number tuple is included it points to a
rekeyed/renewed). 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, 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 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 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 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. 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
When the <date> element is not zero (i.e., 0001-01-01T00:00:00Z) it scope of the document; one possible solution is through provisioned
MUST be represented in a form that matches the dateTime production in information.
"canonical representation" [XMLSCHEMA]. Implementations SHOULD NOT
rely on time resolution finer than seconds and MUST NOT generate time
instants that specify leap seconds.
2.1.1. PAL Package Types 2.1.1. PAL Package Types
Table 1 lists the PAL package types that are defined by this Table 1 lists the PAL package types that are defined by this
document: document:
NOTE: DS is Digital Signature and KE is Key Establishment. NOTE: CSR is Certificate Signing Request, DS is Digital Signature and
KE is Key Establishment.
Package Package Description Package Package Description
Number Number
-------- --------------------------------------------------- -------- ---------------------------------------------------
0000: Reserved 0000: Reserved
0001: Additional PAL value present 0001: Additional PAL value present
0002: X.509 CA certificate 0002: X.509 CA certificate
0003: X.509 EE certificate 0003: X.509 EE certificate
0004: X.509 ARL 0004: X.509 ARL
0005: X.509 CRL 0005: X.509 CRL
skipping to change at page 13, line 6 skipping to change at page 13, line 50
The PAL package types have the following meaning: The PAL package types have the following meaning:
NOTE: The semantics behind Codes 0002 and 0006-0021 are defined in NOTE: The semantics behind Codes 0002 and 0006-0021 are defined in
[RFC7030]. [RFC7030].
0000 Reserved: Reserved for future use. 0000 Reserved: Reserved for future use.
0001 Additional PAL value present: Indicates that this PAL entry 0001 Additional PAL value present: Indicates that this PAL entry
refers to another PAL by referring to another /pal URI, which refers to another PAL by referring to another /pal URI, which
is defined in this section. This PAL package type limits the is defined in this section. This PAL package type limits the
size of PALs to a more manageable size for clients. 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.
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 0002 X.509 CA certificate: Indicates that one or more CA certificates
[RFC5280] are available for the client by pointing to a [RFC5280] are available for the client by pointing to a
/cacerts URI, which is defined in [RFC7030]. /cacerts URI, which is defined in [RFC7030].
0003 X.509 EE certificate: Indicates that one or more EE certificate 0003 X.509 EE certificate: Indicates that one or more EE certificate
[RFC5280] is available for the client by pointing to an [RFC5280] is available for the client by pointing to an
/eecerts URI, which is defined in Section 3. /eecerts URI, which is defined in Section 3.
0004 X.509 ARL: Indicates that one or more ARL (Authority Revocation 0004 X.509 ARL: Indicates that one or more ARL (Authority Revocation
skipping to change at page 13, line 51 skipping to change at page 14, line 51
0008 DS certificate enrollment (success): Indicates that the client 0008 DS certificate enrollment (success): Indicates that the client
retrieve a successful certification response. The PAL entry retrieve a successful certification response. The PAL entry
points to a /simpleenroll or a /fullcmc URI, which are both points to a /simpleenroll or a /fullcmc URI, which are both
defined in [RFC7030]. defined in [RFC7030].
0009 DS certificate enrollment (failure): Indicates that the client 0009 DS certificate enrollment (failure): Indicates that the client
retrieve a failed certification response for a DS certificate. retrieve a failed certification response for a DS certificate.
This PAL entry points to a /simpleenroll or a /fullcmc URI. This PAL entry points to a /simpleenroll or a /fullcmc URI.
0010 Start DS certificate re-enrollment: Indicates that the client 0010 Start DS certificate re-enrollment: Indicates that the client
rekey/renew a DS certificate. The PAL entry points to a rekey or renew a DS certificate. The PAL entry points to a
/simplereenroll or a /fullcmc URI. /simplereenroll or a /fullcmc URI.
0011 DS certificate re-enrollment (success): See PAL package type 0011 DS certificate re-enrollment (success): See PAL package type
0008. 0008.
0012 DS certificate re-enrollment (failure): See PAL package type 0012 DS certificate re-enrollment (failure): See PAL package type
0009. 0009.
NOTE: The KE (Key Establishment) responses that follow use the same NOTE: The KE (Key Establishment) responses that follow use the same
URIs as DS certificates except in the requested certificates the key URIs as DS certificates except in the requested certificates the key
skipping to change at page 14, line 29 skipping to change at page 15, line 28
0014 Start KE certificate enrollment: See PAL package type 0007. 0014 Start KE certificate enrollment: See PAL package type 0007.
0015 KE certificate enrollment (success): See PAL package type 0008. 0015 KE certificate enrollment (success): See PAL package type 0008.
0016 KE certificate enrollment (failure): See PAL package type 0009. 0016 KE certificate enrollment (failure): See PAL package type 0009.
0017 Start KE certificate re-enrollment: See PAL package type 0010. 0017 Start KE certificate re-enrollment: See PAL package type 0010.
0018 KE certificate re-enrollment (success): See PAL package type 0018 KE certificate re-enrollment (success): See PAL package type
0011. 0008.
0019 KE certificate re-enrollment (failure): See PAL package type 0019 KE certificate re-enrollment (failure): See PAL package type
0012. 0009.
NOTE: The variations on the asymmetric key packages is due to the NOTE: The variations on the asymmetric key packages is due to the
number of CMS content types that can be used to protect 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 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 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). ASN.1 needs to be a CMS content type not the private key info type).
See Section 8 of this document for additional information. See Section 8 of this document for additional information.
0020 Asymmetric Key Package (PKCS#8): Indicates that an asymmetric 0020 Asymmetric Key Package (PKCS#8): Indicates that an asymmetric
key generated by the server is available for the client; the key generated by the server is available for the client; the
skipping to change at page 17, line 6 skipping to change at page 18, line 4
<!-- ===== Element Declarations ===== --> <!-- ===== Element Declarations ===== -->
<xsd:element name="pal" type="pal:PAL" /> <xsd:element name="pal" type="pal:PAL" />
<!-- ===== Complex Data Element Type Definitions ===== --> <!-- ===== Complex Data Element Type Definitions ===== -->
<xsd:complexType name="PAL"> <xsd:complexType name="PAL">
<xsd:annotation> <xsd:annotation>
<xsd:documentation> <xsd:documentation>
This type defines the Package Availability List (PAL). This type defines the Package Availability List (PAL).
</xsd:documentation> </xsd:documentation>
</xsd:annotation> </xsd:annotation>
<xsd:sequence> <xsd:sequence>
<xsd:element name="message" type="pal:PALEntry" minOccurs="0"> <xsd:element name="message" type="pal:PALEntry"
minOccurs="0" maxOccurs="unbounded">
<xsd:annotation> <xsd:annotation>
<xsd:documentation> <xsd:documentation>
Contains information about the package and a link that Contains information about the package and a link that
the client uses to download or post the package. the client uses to download or post the package.
</xsd:documentation> </xsd:documentation>
</xsd:annotation> </xsd:annotation>
</xsd:element> </xsd:element>
</xsd:sequence> </xsd:sequence>
</xsd:complexType> </xsd:complexType>
<xsd:complexType name="PALEntry"> <xsd:complexType name="PALEntry">
<xsd:annotation> <xsd:annotation>
<xsd:documentation> <xsd:documentation>
This type defines a product in the PAL. This type defines a product in the PAL.
</xsd:documentation> </xsd:documentation>
</xsd:annotation> </xsd:annotation>
<xsd:sequence> <xsd:sequence>
<xsd:element name="type" type="pal:PackageType" <xsd:element name="type" type="pal:PackageType" />
minOccurs="1" maxOccurs="1">
</xsd:element>
<xsd:element name="date" type="pal:GeneralizedTimeType" <xsd:element name="date" type="pal:GeneralizedTimeType"
minOccurs="1" maxOccurs="1"> minOccurs="0" />
</xsd:element> <xsd:element name="size" type="xsd:nonNegativeInteger">
<xsd:element name="size" type="pal:PackageSizeType" <xsd:annotation>
minOccurs="1" maxOccurs="1"> <xsd:documentation>
</xsd:element> Indicates the package's size.
<xsd:element name="info" type="pal:PackageInfoType" </xsd:documentation>
minOccurs="1" maxOccurs="1"> </xsd:annotation>
</xsd:element> <xsd:element name="info" type="pal:PackageInfoType" />
</xsd:sequence> </xsd:sequence>
</xsd:complexType> </xsd:complexType>
<xsd:complexType name="PackageInfoType"> <xsd:complexType name="PackageInfoType">
<xsd:annotation> <xsd:annotation>
<xsd:documentation> <xsd:documentation>
This type allows a choice of X.500 Distinguished Name, This type allows a choice of X.500 Distinguished Name,
Subject Key Identifier, Issuer and Serial Number tuple, Subject Key Identifier, Issuer and Serial Number tuple,
or URI. or URI.
</xsd:documentation> </xsd:documentation>
skipping to change at page 18, line 7 skipping to change at page 19, line 4
This type allows a choice of X.500 Distinguished Name, This type allows a choice of X.500 Distinguished Name,
Subject Key Identifier, Issuer and Serial Number tuple, Subject Key Identifier, Issuer and Serial Number tuple,
or URI. or URI.
</xsd:documentation> </xsd:documentation>
</xsd:annotation> </xsd:annotation>
<xsd:choice> <xsd:choice>
<xsd:element name="dn" type="pal:DistinguishedName" /> <xsd:element name="dn" type="pal:DistinguishedName" />
<xsd:element name="ski" type="pal:SubjectKeyIdentifier" /> <xsd:element name="ski" type="pal:SubjectKeyIdentifier" />
<xsd:element name="iasn" type="pal:IssuerAndSerialNumber" /> <xsd:element name="iasn" type="pal:IssuerAndSerialNumber" />
<xsd:element name="uri" type="pal:ThisURI" /> <xsd:element name="uri" type="pal:ThisURI" />
</xsd:choice> </xsd:choice>
</xsd:complexType> </xsd:complexType>
<xsd:complexType name="IssuerAndSerialNumber"> <xsd:complexType name="IssuerAndSerialNumber">
<xsd:annotation> <xsd:annotation>
<xsd:documentation> <xsd:documentation>
This type holds the issuer Distinguished Name and This type holds the issuer Distinguished Name and
serial number of a referenced certificate. serial number of a referenced certificate.
</xsd:documentation> </xsd:documentation>
</xsd:annotation> </xsd:annotation>
<xsd:sequence> <xsd:sequence>
<xsd:element name="issuer" type="pal:DistinguishedName" /> <xsd:element name="issuer" type="pal:DistinguishedName" />
<xsd:element name="serial" type="xsd:integer" /> <xsd:element name="serial" type="xsd:positiveInteger" />
</xsd:sequence> </xsd:sequence>
</xsd:complexType> </xsd:complexType>
<!-- =====Simple Data Element Type Definitions ===== --> <!-- =====Simple Data Element Type Definitions ===== -->
<xsd:simpleType name="PackageType"> <xsd:simpleType name="PackageType">
<xsd:annotation> <xsd:annotation>
<xsd:documentation> <xsd:documentation>
Identifies each package that a client may retrieve from Identifies each package that a client may retrieve from
the server with a 4-digit field. the server with a 4-digit string.
</xsd:documentation> </xsd:documentation>
</xsd:annotation> </xsd:annotation>
<xsd:restriction base="xsd:string"> <xsd:restriction base="xsd:string">
<xsd:maxLength value="4" /> <xsd:pattern value="d{4}" />
</xsd:restriction> </xsd:restriction>
</xsd:simpleType> </xsd:simpleType>
<xsd:simpleType name="GeneralizedTimeType"> <xsd:simpleType name="GeneralizedTimeType">
<xsd:annotation> <xsd:annotation>
<xsd:documentation> <xsd:documentation>
Indicates the date and time (YYYY-MM-DDTHH:MM:SSZ) the Indicates the date and time (YYYY-MM-DDTHH:MM:SSZ) the
client last acknowledged successful receipt of the client last acknowledged successful receipt of the
package or 0001-01-01T00:00:00Z if there is no indication package or is absent if a) there is no indication
the package has been downloaded or the PAL entry the package has been downloaded or b) the PAL entry
corresponds to a pointer to the next PAL. corresponds to a pointer to the next PAL.
</xsd:documentation> </xsd:documentation>
</xsd:annotation> </xsd:annotation>
<xsd:restriction base="xsd:dateTime"> <xsd:restriction base="xsd:dateTime">
<xsd:pattern value= <xsd:pattern value=".*:d{2}Z" />
"((000[1-9])|(00[1-9][0-9])|(0[1-9][0-9]{2})|
([1-9][0-9]{3}))-((0[1-9])|(1[012]))-((0[1-9])|
([12][0-9])|(3[01]))T(([01][0-9])|(2[0-3]))
((:[0-5][0-9])(:[0-5][0-9])Z" />
<xsd:minInclusive value="2013-05-23T00:00:00Z" /> <xsd:minInclusive value="2013-05-23T00:00:00Z" />
</xsd:restriction> </xsd:restriction>
</xsd:simpleType> </xsd:simpleType>
<xsd:simpleType name="PackageSizeType">
<xsd:annotation>
<xsd:documentation>
Indicates the package's size.
</xsd:documentation>
</xsd:annotation>
<xsd:pattern value="[0-9]+" />
</xsd:simpleType>
<xsd:simpleType name="DistinguishedName"> <xsd:simpleType name="DistinguishedName">
<xsd:annotation> <xsd:annotation>
<xsd:documentation> <xsd:documentation>
This type holds an X.500 Distinguished Name. This type holds an X.500 Distinguished Name.
</xsd:documentation> </xsd:documentation>
</xsd:annotation> </xsd:annotation>
<xsd:restriction base="xsd:string" /> <xsd:restriction base="xsd:string">
<xsd:maxLength value="1024" /> <xsd:maxLength value="1024" />
</xsd:restriction>
</xsd:simpleType> </xsd:simpleType>
<xsd:simpleType name="SubjectKeyIdentifier"> <xsd:simpleType name="SubjectKeyIdentifier">
<xsd:annotation> <xsd:annotation>
<xsd:documentation> <xsd:documentation>
This type holds a hex string representing the value of a This type holds a hex string representing the value of a
certificate's SubjectKeyIdentifier. certificate's SubjectKeyIdentifier.
</xsd:documentation> </xsd:documentation>
</xsd:annotation> </xsd:annotation>
<xsd:restriction base="xsd:hexBinary" /> <xsd:restriction base="xsd:hexBinary">
<xsd:maxLength value="1024" /> <xsd:maxLength value="1024" />
</xsd:restriction>
</xsd:simpleType> </xsd:simpleType>
<xsd:simpleType name="ThisURI"> <xsd:simpleType name="ThisURI">
<xsd:annotation> <xsd:annotation>
<xsd:documentation> <xsd:documentation>
This type holds a URI, but is length limited. This type holds a URI, but is length limited.
</xsd:documentation> </xsd:documentation>
</xsd:annotation> </xsd:annotation>
<xsd:restriction base="xsd:anyURI" /> <xsd:restriction base="xsd:anyURI" />
<xsd:maxLength value="1024" /> <xsd:maxLength value="1024" />
skipping to change at page 20, line 4 skipping to change at page 20, line 38
This type holds a URI, but is length limited. This type holds a URI, but is length limited.
</xsd:documentation> </xsd:documentation>
</xsd:annotation> </xsd:annotation>
<xsd:restriction base="xsd:anyURI" /> <xsd:restriction base="xsd:anyURI" />
<xsd:maxLength value="1024" /> <xsd:maxLength value="1024" />
</xsd:simpleType> </xsd:simpleType>
</xsd:schema> </xsd:schema>
2.1.3. PAL JSON Object 2.1.3. PAL JSON Object
The following is an example PAL JSON object. The fields in the The following is an example PAL JSON object. The fields in the
object were discussed earlier in Sections 2.1 and 2.1.1. object were discussed earlier in Sections 2.1 and 2.1.1.
[ [
{ {
"Type": 0003, "type": "0003",
"Date": "2016-12-29T09:28:00Z", "date": "2016-12-29T09:28:00Z",
"Size": 1234, "size": 1234,
"Info": "https://www.example.com/.well-known/est/eecerts/1234" "info":
} {
"uri": "https://www.example.com/.well-known/est/eecerts/1234"
}
},
{ {
"Type": 0003, "type": "0006",
"Date": "2016-12-29T09:28:00Z", "date": "2016-12-29T09:28:00Z",
"Size": 1234, "size": 1234,
"Info": "https://www.example.com/.well-known/est/eecerts/9876" "info":
{
"iasn":
{
"issuer": "CN=Sean Turner,O=sn3rd,C=US",
"serial": 0
}
}
} }
] ]
2.2. Request PAL 2.2. Request PAL
Clients request their PAL with an HTTP GET [RFC7231] using an Clients request their PAL with an HTTP GET [RFC7231] using an
operation path of "/pal". Clients indicate whether they would prefer operation path of "/pal". Clients indicate whether they would prefer
XML or JSON by including the HTTP Accept header [RFC2616] with either XML or JSON by including the HTTP Accept header [RFC7231] with either
"application/xml" or "application/json", respectively. "application/xml" or "application/json", respectively.
2.3. Provide PAL 2.3. Provide PAL
If the server has a PAL for the client, the server response MUST If the server has a PAL for the client, the server response MUST
contain an HTTP 200 response code with a content-type of contain an HTTP 200 response code with a content-type of
"application/xml" [RFC7303] or "application/json" [RFC4627] and a "application/xml" [RFC7303] or "application/json" [RFC7159].
Content-Transfer-Encoding of "base64".
When the server constructs a PAL, an order of precedence for PAL When the server constructs a PAL, an order of precedence for PAL
offerings is based on the following rationale: offerings is based on the following rationale:
o /cacerts and /crls packages are the most important because they o /cacerts and /crls packages are the most important because they
support validation decisions on certificates used to sign and support validation decisions on certificates used to sign and
encrypt other listed PAL items. encrypt other listed PAL items.
o /csrattrs are the next in importance, since they provide o /csrattrs are the next in importance, since they provide
information that the server would like the client to include in information that the server would like the client to include in
skipping to change at page 21, line 16 skipping to change at page 22, line 12
process CA-provided transactions as soon as possible to avoid process CA-provided transactions as soon as possible to avoid
undue delays that might lead to protocol failure. undue delays that might lead to protocol failure.
o /symmetrickeys, /firmware, /tamp, and /eecerts packages o /symmetrickeys, /firmware, /tamp, and /eecerts packages
containing keys and other types of products are last. Precedence containing keys and other types of products are last. Precedence
SHOULD be given to packages that the client has not previously SHOULD be given to packages that the client has not previously
downloaded. The items listed in a PAL may not identify all of 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 the packages available for a device. This can be for any of the
following reasons: following reasons:
The server may temporarily withhold some outstanding PAL items to * The server may temporarily withhold some outstanding PAL items
simplify client processing. to simplify client processing.
If a CA has more than one certificate ready to begin a certificate * If a CA has more than one certificate ready for the client, the
management protocol with a client, the server will provide a notice server will provide a notice for one at a time. Pending
for one at a time. Pending notices will be serviced in order of the notices will be serviced in order of the earliest date when the
earliest date when the certificate will be used. certificate will be used.
When rejecting a request the server specifies either an HTTP 4xx When rejecting a request the server specifies either an HTTP 4xx
error, or an HTTP 5xx error. error, or an HTTP 5xx error.
All other return codes are handled as specified in Section 4.2.3 of 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). [RFC7030] (i.e., 202 handling and all other HTTP response codes).
3. Distribute EE Certificates 3. Distribute EE Certificates
Numerous mechanisms exist for clients to query repositories for Numerous mechanisms exist for clients to query repositories for
skipping to change at page 21, line 44 skipping to change at page 22, line 40
in that it is not a general purpose query for client certificates in that it is not a general purpose query for client certificates
instead it allows the server to provide peer certificates to a client instead it allows the server to provide peer certificates to a client
that the server knows through an out-of-band mechanism that the that the server knows through an out-of-band mechanism that the
client will be communicating with. For example, a router being client will be communicating with. For example, a router being
provisioned that connects to two peers can be provisioned with not provisioned that connects to two peers can be provisioned with not
only its certificate but also with the peers' certificates. only its certificate but also with the peers' certificates.
The server need not authenticate or authorize the client for The server need not authenticate or authorize the client for
distributing an EE certificate because the package contents are distributing an EE certificate because the package contents are
already signed by a CA (i.e., the certificate(s) in a certs-only already signed by a CA (i.e., the certificate(s) in a certs-only
message are already signed by a CA). The message flow is similar to message have already been signed by a CA). The message flow is
Figure 1 except that the connection need not be HTTPS: similar to Figure 1 except that the connection need not be HTTPS:
| | | |
Client | Establish TLS | Server Client | Establish TLS | Server
| Session | | Session |
|<-------------------->| |<-------------------->|
| | | |
| Request PAL | | Request PAL |
| (HTTP GET Request) | | (HTTP GET Request) |
|--------------------->| |--------------------->|
|<---------------------| |<---------------------|
skipping to change at page 22, line 29 skipping to change at page 23, line 25
3.1. EE Certificate Request 3.1. EE Certificate Request
Clients request EE certificates with an HTTP GET [RFC7231] using an Clients request EE certificates with an HTTP GET [RFC7231] using an
operation path of "/eecerts". operation path of "/eecerts".
3.2. EE Certificate Response 3.2. EE Certificate Response
The response and processing of the returned error codes is identical The response and processing of the returned error codes is identical
to that in Section 4.1.3 of [RFC7030] except that the certificate to that in Section 4.1.3 of [RFC7030] except that the certificate
provided is not the one issued to the client but is instead one of provided is not the one issued to the client but instead one or more
more client's peer certificates is returned in the certs-only client's peer certificates is returned in the certs-only message.
message.
Clients MUST reject EE certificates that do not validate to an Clients MUST reject EE certificates that do not validate to an
authorized TA. authorized TA.
4. Distribute CRLs and ARLs 4. Distribute CRLs and ARLs
CRLs (and ARLs) are needed in many instances to perform certificate CRLs (and ARLs) are needed in many instances to perform certificate
path validation [RFC5280]. They can be obtained from repositories if path validation [RFC5280]. They can be obtained from repositories if
their location is provided in the certificate. However, the client their location is provided in the certificate. However, the client
needs to parse the certificate and perform an additional round trip needs to parse the certificate and perform an additional round trip
to retrieve them. Providing CRLs at the time of bootstrap would to retrieve them. Providing CRLs at the time of bootstrap obviates
obviate the need for the client to parse certificate and aid those the need for the client to parse certificate and aid those clients
clients who might be unable to retrieve the CRL. Clients are free to who might be unable to retrieve the CRL. Clients are free to obtain
obtain CRLs on which they rely from sources other than the server CRLs on which they rely from sources other than the server (e.g., a
(e.g., a local directory). The /crls PC allows servers to distribute local directory). The /crls PC allows servers to distribute CRLs at
CRLs at the same time clients retrieve their certificate(s) and CA the same time clients retrieve their certificate(s) and CA
certificate(s) as well as peer certificates. certificate(s) as well as peer certificates.
The server need not authenticate or authorize the client for The server need not authenticate or authorize the client for
distributing a CRL because the package is already signed by a CA distributing a CRL because the package content is already signed by a
(i.e., the CRLs in a crls-only message are already signed by a CA). CA (i.e., the CRLs in a crls-only message have already been signed by
The message flow is as depicted in Figure 2 but with "CRL(s)" instead a CA). The message flow is as depicted in Figure 2 but with "CRL(s)"
of "EE Cert(s)". instead of "EE Cert(s)".
4.1. CRL Request 4.1. CRL Request
Clients request CRLs with an HTTP GET [RFC7231] using an operation Clients request CRLs with an HTTP GET [RFC7231] using an operation
path of "/crls". path of "/crls".
4.2. CRL Response 4.2. CRL Response
The response and processing of the response is identical to that in The response and processing of the response is identical to that in
Section 4.1.3 of [RFC7030] except that instead of providing the Section 4.1.3 of [RFC7030] except that instead of providing the
issued certificate one of more CRLs are returned in the crls-only issued certificate one of more CRLs are returned in the crls-only
message. message.
skipping to change at page 23, line 34 skipping to change at page 24, line 28
In addition to public keys, clients often need one or more symmetric In addition to public keys, clients often need one or more symmetric
keys to communicate with their peers. The /symmetrickeys PC allows keys to communicate with their peers. The /symmetrickeys PC allows
the server to distribute symmetric keys to clients. the server to distribute symmetric keys to clients.
Distribution of keys does not always work as planned and clients need 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 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 need a way to inform the server, if asked, that the distribution
process has successfully completed. The /symmetrickeys/return PC process has successfully completed. The /symmetrickeys/return PC
allows client to provide errors and receipts. allows client to provide errors and receipts.
Clients MUST authenticate the server and clients MUST check server's Clients MUST authenticate the server and clients MUST check the
authorization. server's authorization.
The server MUST authenticate clients and the server MUST check the The server MUST authenticate clients and the server MUST check the
client's authorization. client's authorization.
HTTP GET [RFC7231] is used when the server provides the key to the HTTP GET [RFC7231] is used when the server provides the key to the
client (see Section 5.1) using the /symmetrickeys PC; HTTP POST client (see Section 5.1) using the /symmetrickeys PC; HTTP POST
[RFC7231] is used when the client provides a receipt (see Section [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 5.2) or an error (see Section 5.2) to the server with the
/symmetrickeys/return PC. /symmetrickeys/return PC.
skipping to change at page 24, line 11 skipping to change at page 25, line 5
symmetric key package is defined in [RFC6031]. symmetric key package is defined in [RFC6031].
As with the /serverkeygen PC defined in [RFC7030], the default As with the /serverkeygen PC defined in [RFC7030], the default
distribution method of the symmetric key uses the encryption mode of distribution method of the symmetric key uses the encryption mode of
the negotiated TLS cipher suite. Keys are not protected by preferred the negotiated TLS cipher suite. Keys are not protected by preferred
key wrapping methods such as AES Key Wrap [RFC3394] or AES Key Wrap key wrapping methods such as AES Key Wrap [RFC3394] or AES Key Wrap
with Padding [RFC5649] because encryption of the symmetric key beyond with Padding [RFC5649] because encryption of the symmetric key beyond
that provided by TLS is OPTIONAL. Therefore, the cipher suite used that provided by TLS is OPTIONAL. Therefore, the cipher suite used
to return the symmetric key MUST offer commensurate cryptographic to return the symmetric key MUST offer commensurate cryptographic
strength with the symmetric key being delivered to the client. The strength with the symmetric key being delivered to the client. The
cipher suite use MUST NOT have NULL encryption algorithm as this will cipher suite used MUST NOT have NULL encryption algorithm as this
disclose the unprotected symmetric key. It is strongly RECOMMENDED will disclose the unprotected symmetric key. It is strongly
that servers always return encrypted symmetric keys. RECOMMENDED that servers always return encrypted symmetric keys.
The following depicts the protocol flow: The following depicts the protocol flow:
| | | |
Client | Establish TLS | Server Client | Establish TLS | Server
| Session | | Session |
|<-------------------->| |<-------------------->|
| | | |
| Request PAL | | Request PAL |
| (HTTP GET Request) | | (HTTP GET Request) |
skipping to change at page 24, line 47 skipping to change at page 25, line 41
Figure 3 - /symmetrickeys Message Sequence Figure 3 - /symmetrickeys Message Sequence
5.1.1. Distribute Symmetric Keys 5.1.1. Distribute Symmetric Keys
Clients request the symmetric key from the server with an HTTP GET Clients request the symmetric key from the server with an HTTP GET
[RFC7231] using an operation path of "/symmetrickeys". [RFC7231] using an operation path of "/symmetrickeys".
5.1.2. Symmetric Key Response 5.1.2. Symmetric Key Response
If the request is successful, the server response MUST have an HTTP If the request is successful, the server response MUST have an HTTP
200 response code with a Content-Type of application/cms [RFC7193] 200 response code with a Content-Type of application/cms [RFC7193].
and a Content-Transfer-Encoding of "base64". The optional The optional application/cms encapsulatingContent and innerContent
application/cms encapsulatingContent and innerContent parameters parameters SHOULD be included with the Content-Type to indicate the
SHOULD be included with the Content-Type to indicate the protection protection afforded to the returned symmetric key. The returned
afforded to the returned symmetric key. The returned content varies: content varies:
o If additional encryption is not being employed, the content o If additional encryption is not being employed, the content
associated with application/cms is a DER-encoded [X.690] associated with application/cms is a DER-encoded [X.690]
symmetric key package. symmetric key package.
o If additional encryption is employed, the content associated with o If additional encryption is employed, the content associated with
application/cms is DER-encoded enveloped data that encapsulates a application/cms is DER-encoded enveloped data that encapsulates a
signed data that further encapsulates a symmetric key package. signed data that further encapsulates a symmetric key package.
o If additional encryption and origin authentication is employed, o If additional encryption and origin authentication are employed,
the content associated with application/cms is a DER-encoded the content associated with application/cms is a DER-encoded
signed data that encapsulates an enveloped data that encapsulates signed data that encapsulates an enveloped data that encapsulates
a signed data that further encapsulates a symmetric key package. a signed data that further encapsulates a symmetric key package.
o If CCC (CMS Content Constraints) [RFC6010] is supported the o If CCC (CMS Content Constraints) [RFC6010] is supported the
content associated with application/cms is a DER-encoded content associated with application/cms is a DER-encoded
encrypted key package [RFC6032]. Encrypted key package provides encrypted key package [RFC6032]. Encrypted key package provides
three choices to encapsulate keys: encrypted data, enveloped three choices to encapsulate keys: encrypted data, enveloped
data, and authenticated enveloped data. Prior to employing one data, and authenticated enveloped data. Prior to employing one
of these three encryption choices the key package can be of these three encryption choices the key package can be
skipping to change at page 25, line 37 skipping to change at page 26, line 31
package is beyond the scope of this document. package is beyond the scope of this document.
When rejecting a request, the server specifies either an HTTP 4xx When rejecting a request, the server specifies either an HTTP 4xx
error, or an HTTP 5xx error. error, or an HTTP 5xx error.
If a symmetric key package (which might be signed) or an encrypted If a symmetric key package (which might be signed) or an encrypted
key package (which might be signed before and after encryption) is key package (which might be signed before and after encryption) is
digitally signed, the client MUST reject it if the digital signature digitally signed, the client MUST reject it if the digital signature
does not validate back to an authorized TA. 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] [RFC3370], [RFC5753], [RFC5754], [RFC6033], [RFC6160], and [RFC6161]
provide algorithm details for use when protecting the symmetric key provide algorithm details for use when protecting the symmetric key
package and encrypted key package. package and encrypted key package.
5.2. Symmetric Key Receipts and Errors 5.2. Symmetric Key Receipts and Errors
Clients use /symmetrickeys/return to provide symmetric key package Clients use /symmetrickeys/return to provide symmetric key package
receipts; the key package receipt content type is defined in receipts; the key package receipt content type is defined in
[RFC7191]. Clients can be configured to automatically return [RFC7191]. Clients can be configured to automatically return
receipts after processing a symmetric key package, return receipts receipts after processing a symmetric key package, return receipts
skipping to change at page 26, line 40 skipping to change at page 27, line 40
| status code only | | status code only |
| no content | | no content |
| | | |
Figure 4 - /symmetrickeys/return Message Sequence Figure 4 - /symmetrickeys/return Message Sequence
5.2.1. Provide Symmetric Key Receipt or Error 5.2.1. Provide Symmetric Key Receipt or Error
Clients return symmetric key receipts and errors to the server with Clients return symmetric key receipts and errors to the server with
an HTTP POST [RFC7231] using an operation path of an HTTP POST [RFC7231] using an operation path of
"/symmetrickeys/return" and a Content-Transfer-Encoding of "base64". "/symmetrickeys/return". The returned content varies:
The returned content varies:
o The key package receipt is digitally signed [RFC7191], the o The key package receipt is digitally signed [RFC7191], the
Content-Type is application/cms [RFC7193] and the associated Content-Type is application/cms [RFC7193] and the associated
content is signed data, which encapsulates a key package receipt. content is signed data, which encapsulates a key package receipt.
o If the key package error is not digitally signed, the Content- o If the key package error is not digitally signed, the Content-
Type is application/cms and the associated content is key package Type is application/cms and the associated content is key package
error. If the key package error is digitally signed, the error. If the key package error is digitally signed, the
Content-Type is application/cms and the associated content is Content-Type is application/cms and the associated content is
signed data, which encapsulates a key package error. signed data, which encapsulates a key package error.
skipping to change at page 27, line 16 skipping to change at page 28, line 16
parameters SHOULD be included with the Content-Type to indicate the parameters SHOULD be included with the Content-Type to indicate the
protection afforded to the receipt or error. protection afforded to the receipt or error.
[RFC3370], [RFC5753], [RFC5754], and [RFC7192] provide algorithm [RFC3370], [RFC5753], [RFC5754], and [RFC7192] provide algorithm
details for use when protecting the key package receipt or key details for use when protecting the key package receipt or key
package error. package error.
5.2.2. Symmetric Key Receipt or Error Response 5.2.2. Symmetric Key Receipt or Error Response
If the client successfully provides a receipt or error, the server If the client successfully provides a receipt or error, the server
response has an HTTP 200 response code with no content. response has an HTTP 204 response code (i.e., no content is
returned).
When rejecting a request, the server specifies either an HTTP 4xx When rejecting a request, the server specifies either an HTTP 4xx
error, or an HTTP 5xx error. error, or an HTTP 5xx error.
If a key package receipt or key package error is digitally signed, If a key package receipt or key package error is digitally signed,
the server MUST reject it if the digital signature does not validate the server MUST reject it if the digital signature does not validate
back to an authorized TA. back to an authorized TA.
6. Firmware, Receipts, and Errors 6. Firmware, Receipts, and Errors
Servers can distribute object code for cryptographic algorithms and Servers can distribute object code for cryptographic algorithms and
software with the firmware package [RFC4108]. software with the firmware package [RFC4108].
Clients MUST authenticate the server and clients MUST check server's Clients MUST authenticate the server and clients MUST check the
authorization. server's authorization.
Server MUST authenticate the client and the server MUST check the The server MUST authenticate the client and the server MUST check the
client's authorization. client's authorization.
The /firmware PC uses an HTTP GET [RFC7231] and the /firmware/return The /firmware PC uses an HTTP GET [RFC7231] and the /firmware/return
PC uses an HTTP POST [RFC7231]. GET is used when the client PC uses an HTTP POST [RFC7231]. GET is used when the client
retrieves firmware from the server (see Section 6.1); POST is used 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 when the client provides a receipt (see Section 6.2) or an error (see
Section 6.2). Section 6.2).
6.1. Firmware 6.1. Firmware
skipping to change at page 27, line 51 skipping to change at page 29, line 4
6.1. Firmware 6.1. Firmware
The /firmware URI is used by servers to provide firmware packages to The /firmware URI is used by servers to provide firmware packages to
clients. clients.
The message flow is as depicted in Figure 3 modulo replacing The message flow is as depicted in Figure 3 modulo replacing
"Symmetric Key" with "Firmware Package". "Symmetric Key" with "Firmware Package".
6.1.1. Distribute Firmware 6.1.1. Distribute Firmware
Clients request firmware from the server with an HTTP GET [RFC7231] Clients request firmware from the server with an HTTP GET [RFC7231]
using an operation path of "/firmware". using an operation path of "/firmware".
6.1.2. Firmware Response 6.1.2. Firmware Response
If the request is successful, the server response MUST have an HTTP If the request is successful, the server response MUST have an HTTP
200 response code with a Content-Type of "application/cms" [RFC7193] 200 response code with a Content-Type of "application/cms" [RFC7193].
and a Content-Transfer-Encoding of "base64". The optional The optional encapsulatingContent and innerContent parameters SHOULD
encapsulatingContent and innerContent parameters SHOULD be included be included with Content-Type to indicate the protection afforded to
with Content-Type to indicate the protection afforded to the returned the returned firmware. The returned content varies:
firmware. The returned content varies:
o If the firmware is unprotected, then the Content-Type is o If the firmware is unprotected, then the Content-Type is
application/cms and the content is the DER-encoded [X.690] application/cms and the content is the DER-encoded [X.690]
firmware package. firmware package.
o If the firmware is compressed, then the Content-Type is o If the firmware is compressed, then the Content-Type is
application/cms and the content is the DER-encoded [X.690] application/cms and the content is the DER-encoded [X.690]
compressed data that encapsulates the firmware package. compressed data that encapsulates the firmware package.
o If the firmware is encrypted, then the Content-Type is o If the firmware is encrypted, then the Content-Type is
skipping to change at page 29, line 12 skipping to change at page 30, line 12
receipts and errors [RFC4108]. Clients can be configured to receipts and errors [RFC4108]. Clients can be configured to
automatically return receipts and errors after processing a firmware automatically return receipts and errors after processing a firmware
package or based on a PAL entry. package or based on a PAL entry.
The message flow is as depicted in Figure 4 modulo the receipt or The message flow is as depicted in Figure 4 modulo the receipt or
error is for a firmware package. error is for a firmware package.
6.2.1. Provide Firmware Receipt or Error 6.2.1. Provide Firmware Receipt or Error
Clients return firmware receipts and errors to the server with an Clients return firmware receipts and errors to the server with an
HTTP POST [RFC7231] using an operation path of "/firmware/return" and HTTP POST [RFC7231] using an operation path of "/firmware/return".
a Content-Transfer-Encoding of "base64". The optional The optional encapsulatingContent and innerContent parameters SHOULD
encapsulatingContent and innerContent parameters SHOULD be included be included with Content-Type to indicate the protection afforded to
with Content-Type to indicate the protection afforded to the returned the returned firmware receipt or error. The returned content varies:
firmware receipt or error. The returned content varies:
o If the firmware receipt is not digitally signed, the Content-Type o If the firmware receipt is not digitally signed, the Content-Type
is application/cms [RFC7193] and the content is the DER-encoded is application/cms [RFC7193] and the content is the DER-encoded
firmware receipt. firmware receipt.
o If the firmware receipt is digitally signed, the Content-Type is o If the firmware receipt is digitally signed, the Content-Type is
application/cms and the content is the DER-encoded signed data application/cms and the content is the DER-encoded signed data
encapsulating the firmware receipt. encapsulating the firmware receipt.
o If the firmware error is not digitally signed, the Content-Type o If the firmware error is not digitally signed, the Content-Type
skipping to change at page 29, line 40 skipping to change at page 30, line 39
o If the firmware error is digitally signed, the Content-Type is o If the firmware error is digitally signed, the Content-Type is
application/cms and the content is the DER-encoded signed data application/cms and the content is the DER-encoded signed data
encapsulating the firmware error. encapsulating the firmware error.
[RFC3370], [RFC5753], and [RFC5754] provide algorithm details for use [RFC3370], [RFC5753], and [RFC5754] provide algorithm details for use
when protecting the firmware receipt or firmware error. when protecting the firmware receipt or firmware error.
6.2.2. Firmware Receipt or Error Response 6.2.2. Firmware Receipt or Error Response
If the request is successful, the server response MUST have an HTTP If the request is successful, the server response MUST have an HTTP
200 response code with no content. 204 response code (i.e., no content is returned).
When rejecting a request, the server MUST specify either an HTTP 4xx When rejecting a request, the server MUST specify either an HTTP 4xx
error, or an HTTP 5xx error. error, or an HTTP 5xx error.
If a firmware receipt or firmware error is digitally signed, the If a firmware receipt or firmware error is digitally signed, the
server MUST reject it if the digital signature does not validate back server MUST reject it if the digital signature does not validate back
to an authorized TA. to an authorized TA.
7. Trust Anchor Management Protocol 7. Trust Anchor Management Protocol
Servers distribute TAMP packages to manage TAs in a client's trust Servers distribute TAMP packages to manage TAs in a client's trust
anchor databases; TAMP packages are defined in [RFC5934]. TAMP will anchor databases; TAMP packages are defined in [RFC5934]. TAMP will
allow the flexibility for a device to load authorities while allow the flexibility for a device to load authorities while
maintaining an operational state. Unlike other systems that require maintaining an operational state. Unlike other systems that require
new software loads when new PKI Roots are authorized for use, TAMP new software loads when new PKI Roots are authorized for use, TAMP
allows for automated management of roots for provisioning or allows for automated management of roots for provisioning or
replacement as needed. replacement as needed.
Clients MUST authenticate the server and clients MUST check server's Clients MUST authenticate the server and clients MUST check the
authorization. server's authorization.
Server MUST authenticate the client and the server MUST check the The server MUST authenticate the client and the server MUST check the
client's authorization. client's authorization.
The /tamp PC uses an HTTP GET [RFC7231] and the tamp/return PC uses 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 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 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 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) response (see Section 7.2), or provides an error (see Section 7.2)
for the TAMP package. for the TAMP package.
7.1. TAMP Status Query, Trust Anchor Update, Apex Trust Anchor Update, 7.1. TAMP Status Query, Trust Anchor Update, Apex Trust Anchor Update,
skipping to change at page 30, line 44 skipping to change at page 31, line 43
"Symmetric Key" with the appropriate TAMP message. "Symmetric Key" with the appropriate TAMP message.
7.1.1. Request TAMP Packages 7.1.1. Request TAMP Packages
Clients request the TAMP packages from the server with an HTTP GET Clients request the TAMP packages from the server with an HTTP GET
[RFC7231] using an operation path of "/tamp". [RFC7231] using an operation path of "/tamp".
7.1.2. Return TAMP Packages 7.1.2. Return TAMP Packages
If the request is successful, the server response MUST have an HTTP If the request is successful, the server response MUST have an HTTP
200 response code with Content-Transfer-Encoding of "base64" and a 200 response code and a Content-Type of:
Content-Type of:
o application/tamp-status-query for TAMP Status Query o application/tamp-status-query for TAMP Status Query
o application/tamp-update for Trust Anchor Update o application/tamp-update for Trust Anchor Update
o application/tamp-apex-update for Apex Trust Anchor Update o application/tamp-apex-update for Apex Trust Anchor Update
o application/tamp-community-update for Community Update o application/tamp-community-update for Community Update
o application/tamp-sequence-adjust for Sequence Number Adjust o application/tamp-sequence-adjust for Sequence Number Adjust
As specified in [RFC5934], these content types are digitally signed As specified in [RFC5934], these content types are digitally signed
and clients must support validating the packages directly signed by and clients must support validating the packages directly signed by
TAs. For this specification, client MUST support validation with a TAs. For this specification, clients MUST support validation with a
certificate and clients MUST reject it if the digital signature does certificate and clients MUST reject it if the digital signature does
not validate back to an authorized TA. not validate back to an authorized TA.
[RFC3370], [RFC5753], and [RFC5754] provide algorithm details for use [RFC3370], [RFC5753], and [RFC5754] provide algorithm details for use
when protecting the TAMP packages. when protecting the TAMP packages.
7.2. TAMP Response, Confirm, and Errors 7.2. TAMP Response, Confirm, and Errors
Clients return the TAMP Status Query Response, Trust Anchor Update Clients return the TAMP Status Query Response, Trust Anchor Update
Confirm, Apex Trust Anchor Update Confirm, Community Update Confirm, Confirm, Apex Trust Anchor Update Confirm, Community Update Confirm,
skipping to change at page 31, line 31 skipping to change at page 32, line 28
based on a PAL entry. based on a PAL entry.
The message flow is as depicted in Figure 4 modulo replacing The message flow is as depicted in Figure 4 modulo replacing
"Receipt/Error" with the appropriate TAMP response, confirm, or "Receipt/Error" with the appropriate TAMP response, confirm, or
error. error.
7.2.1. Provide TAMP Response, Confirm, or Error 7.2.1. Provide TAMP Response, Confirm, or Error
Clients provide the TAMP responses, confirms, and errors to the Clients provide the TAMP responses, confirms, and errors to the
server with an HTTP POST using an operation path of "/tamp/return". server with an HTTP POST using an operation path of "/tamp/return".
The Content-Transfer-Encoding is "base64" and the Content-Type is: Content-Type is:
o application/tamp-status-query-response for TAMP Status Query o application/tamp-status-query-response for TAMP Status Query
Response Response
o application/tamp-update-confirm for Trust Anchor Update Confirm o application/tamp-update-confirm for Trust Anchor Update Confirm
o application/tamp-apex-update-confirm for Apex Trust Anchor Update o application/tamp-apex-update-confirm for Apex Trust Anchor Update
Confirm Confirm
o application/tamp-community-update-confirm for Community Update o application/tamp-community-update-confirm for Community Update
Confirm Confirm
o application/tamp-sequence-adjust-confirm for Sequence Number o application/tamp-sequence-adjust-confirm for Sequence Number
Adjust Confirm Adjust Confirm
skipping to change at page 32, line 4 skipping to change at page 32, line 50
As specified in [RFC5934], these content types should be signed. If As specified in [RFC5934], these content types should be signed. If
signed, a signed data encapsulates the TAMP content. signed, a signed data encapsulates the TAMP content.
[RFC3370], [RFC5753], and [RFC5754] provide algorithm details for use [RFC3370], [RFC5753], and [RFC5754] provide algorithm details for use
when protecting the TAMP packages. when protecting the TAMP packages.
7.2.2. TAMP Response, Confirm, and Error Response 7.2.2. TAMP Response, Confirm, and Error Response
If the request is successful, the server response MUST have an HTTP If the request is successful, the server response MUST have an HTTP
200 response code with no content. 204 response code (i.e., no content is returned).
When rejecting a request, the server MUST specify either an HTTP 4xx When rejecting a request, the server MUST specify either an HTTP 4xx
error, or an HTTP 5xx error. error, or an HTTP 5xx error.
If the package is digitally signed, the server MUST reject it if If the package is digitally signed, the server MUST reject it if
digital signature does not validate back to an authorized TA. digital signature does not validate back to an authorized TA.
8. Asymmetric Keys, Receipts, and Errors 8. Asymmetric Keys, Receipts, and Errors
[RFC7030] defines the /serverkeygen PC to support server-side [RFC7030] defines the /serverkeygen PC to support server-side
skipping to change at page 32, line 49 skipping to change at page 33, line 48
CMS supports a number of content types to encapsulate other CMS CMS supports a number of content types to encapsulate other CMS
content types; [RFC7030] includes one such possibility; note that content types; [RFC7030] includes one such possibility; note that
when only relying on TLS the returned key is not a CMS content type. 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. This document extends the CMS content types that can be returned.
If the client supports CCC [RFC6010], then the client can indicate If the client supports CCC [RFC6010], then the client can indicate
that it supports encapsulated asymmetric keys in the encrypted key that it supports encapsulated asymmetric keys in the encrypted key
package [RFC5958] by including the encrypted key package's OID in a package [RFC5958] by including the encrypted key package's OID in a
content type attribute [RFC2985] in the CSR (Certificate Signing content type attribute [RFC2985] in the CSR (Certificate Signing
Request), aka the certification request, it provides to the server. Request), aka the certification request, it provides to the server.
If the server knows a prior that the client supports the encrypted If the client knows a priori that the server supports the encrypted
key package content type, then the client need not include the key package content type, then the client need not include the
content type attribute in the CSR. content type attribute in the CSR.
In all instances defined herein, the Content-Type is In all instances defined herein, the Content-Type is
"application/cms" [RFC7193] the Content-Transfer-Encoding is "application/cms" [RFC7193]. The optional encapsulatingContent and
"base64". The optional encapsulatingContent and innerContent innerContent parameters SHOULD be included with Content-Type to
parameters SHOULD be included with Content-Type to indicate the indicate the protection afforded to the returned asymmetric key
protection afforded to the returned asymmetric key package. package.
If additional encryption and origin authentication is employed, the If additional encryption and origin authentication is employed, the
content associated with application/cms is a DER-encoded signed data content associated with application/cms is a DER-encoded signed data
that encapsulates an enveloped data that encapsulates a signed data that encapsulates an enveloped data that encapsulates a signed data
that further encapsulates an asymmetric key package. that further encapsulates an asymmetric key package.
If CCC (CMS Content Constraints) is supported and additional If CCC (CMS Content Constraints) is supported and additional
encryption is employed, the content associated with application/cms encryption is employed, the content associated with application/cms
is a DER-encoded encrypted key package [RFC6032] content type that is a DER-encoded encrypted key package [RFC6032] content type that
encapsulates a signed data that further encapsulates an asymmetric encapsulates a signed data that further encapsulates an asymmetric
skipping to change at page 33, line 35 skipping to change at page 34, line 33
encrypted key package content type that encapsulates a signed data encrypted key package content type that encapsulates a signed data
that further encapsulates an asymmetric key package. that further encapsulates an asymmetric key package.
Encrypted key package [RFC6032] provides three choices to encapsulate Encrypted key package [RFC6032] provides three choices to encapsulate
keys, encrypted data, enveloped data, and authenticated data, with keys, encrypted data, enveloped data, and authenticated data, with
enveloped data being the mandatory to implement choice. enveloped data being the mandatory to implement choice.
When rejecting a request, the server specifies either an HTTP 4xx When rejecting a request, the server specifies either an HTTP 4xx
error, or an HTTP 5xx error. error, or an HTTP 5xx error.
If a asymmetric key package or an encrypted key package is digitally If an asymmetric key package or an encrypted key package is digitally
signed, the client MUST reject it if the digital signature does not signed, the client MUST reject it if the digital signature does not
validate back to an authorized TA. 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] [RFC3370], [RFC5753], [RFC5754], [RFC6033], [RFC6161], and [RFC6162]
provide algorithm details for use when protecting the asymmetric key provide algorithm details for use when protecting the asymmetric key
package and encrypted key package. package and encrypted key package.
8.2. Asymmetric Key Package Receipts and Errors 8.2. Asymmetric Key Package Receipts and Errors
Clients can be configured to automatically return receipts after Clients can be configured to automatically return receipts after
processing an asymmetric key package, return receipts based on processing an asymmetric key package, return receipts based on
processing of the key-package-identifier-and-receipt-request processing of the key-package-identifier-and-receipt-request
attribute [RFC7191], or return receipts when prompted by a PAL entry. attribute [RFC7191], or return receipts when prompted by a PAL entry.
skipping to change at page 34, line 33 skipping to change at page 35, line 37
for the "/simpleenroll" and "/simplereenroll" path extensions for the "/simpleenroll" and "/simplereenroll" path extensions
with the same content-type and transfer encoding. with the same content-type and transfer encoding.
o In all respects, the server SHOULD treat the CSR as it would any 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 enroll or re-enroll CSR; the only distinction here is that the
server MUST ignore the public key values and signature in 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 CSR. These are included in the request only to allow re-use of
existing codebases for generating and parsing such requests. existing codebases for generating and parsing such requests.
PBE (password based encryption) shrouding of PKCS#12 is supported and PBE (password based encryption) shrouding of PKCS#12 is supported and
this specification makes no attempt to alter this defacto standard. this specification makes no attempt to alter this de facto standard.
As such, there is no support of the DecryptKeyIdentifier specified in As such, there is no support of the DecryptKeyIdentifier specified in
[RFC7030] for use with PKCS#12 (i.e., "enveloping" is not supported). [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 8.3.2. Server-Side Key Generation Response
If the request is successful, the server response MUST have an HTTP If the request is successful, the server response MUST have an HTTP
200 response code with a content-type of "application/pkcs12" that 200 response code with a content-type of "application/pkcs12" that
consists of a base64-encoded DER-encoded [X.690] PFX [RFC7292] with a consists of a base64-encoded DER-encoded [X.690] PFX [RFC7292].
Content-Transfer-Encoding of "base64".
Note that this response is different than the response returned in Note that this response is different than the response returned in
Section 4.4.2 of [RFC7030] because here the private key and the Section 4.4.2 of [RFC7030] because here the private key and the
certificate are included in the same PFX. certificate are included in the same PFX.
When rejecting a request, the server MUST specify either an HTTP 4xx 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 error or an HTTP 5xx error. The response data's content-type MAY be
response data MUST be a plaintext human-readable error message. "text/plain" [RFC2046] to convey human-readable error messages.
9. PAL & Certificate Enrollment 9. PAL & Certificate Enrollment
The /fullcmc PC is defined in [RFC7030]; the CMC (Certificate The /fullcmc PC is defined in [RFC7030]; the CMC (Certificate
Management over Cryptographic Message Syntax) requirements and Management over Cryptographic Message Syntax) requirements and
packages are defined in [RFC5272], [RFC5273], [RFC5274], and packages are defined in [RFC5272], [RFC5273], [RFC5274], and
[RFC6402]. This section describes PAL interactions. [RFC6402]. This section describes PAL interactions.
Under normal circumstances the client-server interactions for PKI Under normal circumstances the client-server interactions for PKI
enrollment are as follows: enrollment are as follows:
Client Server Client Server
---------------------> --------------------->
skipping to change at page 37, line 25 skipping to change at page 38, line 30
prematurely closes the connection, then the procedures in Section prematurely closes the connection, then the procedures in Section
8.2.4 of [RFC7231] apply. But, this might leave the client and 8.2.4 of [RFC7231] apply. But, this might leave the client and
server in a different state. The client could merely resubmit the server in a different state. The client could merely resubmit the
request but another option, documented herein, is for the client to request but another option, documented herein, is for the client to
instead download the PAL to see if the server has processed the instead download the PAL to see if the server has processed the
request. Clients might also use this process when they are unable to request. Clients might also use this process when they are unable to
remain connected to the server for the entire enrollment process; if 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 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 status of pending, then the client will not know whether the request
was received. If a client uses the PAL and reconnects to determine was received. If a client uses the PAL and reconnects to determine
if the certification or rekey/renew request was processed: if the certification or rekey or renew request was processed:
o Clients MUST authenticate the server and clients MUST check o Clients MUST authenticate the server and clients MUST check the
server's authorization. server's authorization.
o Server MUST authenticate the client and the server MUST check the o Server MUST authenticate the client and the server MUST check the
client's authorization. client's authorization.
o Clients retrieve the PAL using the /pal URI. o Clients retrieve the PAL using the /pal URI.
o Clients and servers use the operation path of "/simpleenroll", o Clients and servers use the operation path of "/simpleenroll",
"simplereenroll", or "/fullcmc", based on the PAL entry, with an "simplereenroll", or "/fullcmc", based on the PAL entry, with an
HTTP GET [RFC7231] to get the success or failure response. HTTP GET [RFC7231] to get the success or failure response.
Responses are as specified in [RFC7030]. Responses are as specified in [RFC7030].
10. Security Considerations 10. Security Considerations
This document relies on many other specifications. For HTTP, HTTPS, This document relies on many other specifications; however, all of
and TLS security considerations see [RFC7231], [RFC2818], and the security considerations [RFC7030] apply. For HTTP, HTTPS, and
[RFC5246]; for URI security considerations see [RFC3986]; for content TLS security considerations see [RFC7231], [RFC2818], and [RFC5246];
type security considerations see [RFC4073], [RFC4108], [RFC5272], for URI security considerations see [RFC3986]; for content type
security considerations see [RFC4073], [RFC4108], [RFC5272],
[RFC5652], [RFC5751], [RFC5934], [RFC5958] [RFC6031], [RFC6032], [RFC5652], [RFC5751], [RFC5934], [RFC5958] [RFC6031], [RFC6032],
[RFC6268], [RFC6402], [RFC7191], and [RFC7292]; for algorithms used [RFC6268], [RFC6402], [RFC7191], and [RFC7292]; for algorithms used
to protect packages see [RFC3370], [RFC5649], [RFC5753], [RFC5754], to protect packages see [RFC3370], [RFC5649], [RFC5753], [RFC5754],
[RFC5959], [RFC6033], [RFC6160], [RFC6161], [RFC6162] and [RFC7192]; [RFC5959], [RFC6033], [RFC6160], [RFC6161], [RFC6162] and [RFC7192];
for random numbers see [RFC4086]; for server-generated asymmetric key for random numbers see [RFC4086]; for server-generated asymmetric key
pairs see [RFC7030]. pairs see [RFC7030].
11. IANA Considerations 11. IANA Considerations
IANA is requested to perform three registrations: PAL Name Space, PAL IANA is requested to create the PAL Package Type registry and perform
XML Schema, and PAL Package Types. three registrations: PAL Name Space, PAL XML Schema, and PAL Package
Types.
11.1. PAL Name Space 11.1. PAL Name Space
This section registers a new XML namespace [XMLNS], This section registers a new XML namespace [XMLNS],
"urn:ietf:params:xml:ns:TBD" per the guidelines in [RFC3688]: "urn:ietf:params:xml:ns:pal" per the guidelines in [RFC3688]:
URI: urn:ietf:params:xml:ns:TBD URI: urn:ietf:params:xml:ns:pal
Registrant Contact: Sean Turner (turners@ieca.com) Registrant Contact: Sean Turner (sean@sn3rd.com)
XML: XML:
BEGIN BEGIN
<?xml version="1.0"?> <?xml version="1.0"?>
<!DOCTYPE html PUBLIC "-//W3C//DTD XHTML 1.0 Strict//EN" <!DOCTYPE html PUBLIC "-//W3C//DTD XHTML 1.0 Strict//EN"
"http://www.w3.org/TR/xhtml1/DTD/xhtml1-strict.dtd"> "http://www.w3.org/TR/xhtml1/DTD/xhtml1-strict.dtd">
<html xmlns="http://www.w3.org/1999/xhtml" xml:lang="en"> <html xmlns="http://www.w3.org/1999/xhtml" xml:lang="en">
<head> <head>
<title>Package Availability List</title> <title>Package Availability List</title>
</head> </head>
<body> <body>
<h1>Namespace for Package Availability List</h1> <h1>Namespace for Package Availability List</h1>
<h2>urn:ietf:params:xml:ns:TBD</h2> <h2>urn:ietf:params:xml:ns:pal</h2>
<p>See RFC TBD</p> <p>See RFC TBD</p>
</body> </body>
</html> </html>
END END
11.2. PAL Schema 11.2. PAL XML Schema
This section registers an XML schema as per the guidelines in This section registers an XML schema as per the guidelines in
[RFC3688]. [RFC3688].
URI: urn:ietf:params:xml:schema:pal URI: urn:ietf:params:xml:schema:pal
Registrant Contact: Sean Turner sean@sn3rd.com Registrant Contact: Sean Turner sean@sn3rd.com
XML: See Section 2.1.2. XML: See Section 2.1.2.
11.3. PAL Package Types 11.3. PAL Package Types
This section registers the PAL Package Types. Future PAL Package IANA is kindly requested to create a new registry named: PAL Package
Types registrations are to be subject to Expert Review, as defined in Type. This registry is for PAL Package Types whose initial values
RFC 5226 [RFC5226]. Package types MUST be paired with a media type. 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].
The initial registry values are found in Section 2.1.1. 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 12. Acknowledgements
Thanks in no particular order go to Alexey Melnikov, Paul Hoffman, Thanks in no particular order go to Alexey Melnikov, Paul Hoffman,
Brad McInnis, Max Pritikin, Francois Rousseau, Chris Bonatti, and Brad McInnis, Max Pritikin, Francois Rousseau, Chris Bonatti, and
Russ Housley for taking time to provide comments. Russ Housley for taking time to provide comments.
13. References 13. References
13.1. Normative References 13.1. Normative References
[RFC2045] Freed, N. and N. Borenstein, "Multipurpose Internet Mail [RFC2045] Freed, N. and N. Borenstein, "Multipurpose Internet Mail
Extensions (MIME) Part One: Format of Internet Message Extensions (MIME) Part One: Format of Internet Message
Bodies", RFC 2045, DOI 10.17487/RFC2045, November 1996, Bodies", RFC 2045, DOI 10.17487/RFC2045, November 1996,
<http://www.rfc-editor.org/info/rfc2045>. <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 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
Requirement Levels", BCP 14, RFC 2119, DOI Requirement Levels", BCP 14, RFC 2119, DOI
10.17487/RFC2119, March 1997, <http://www.rfc- 10.17487/RFC2119, March 1997, <http://www.rfc-
editor.org/info/rfc2119>. editor.org/info/rfc2119>.
[RFC2585] Housley, R. and P. Hoffman, "Internet X.509 Public Key [RFC2585] Housley, R. and P. Hoffman, "Internet X.509 Public Key
Infrastructure Operational Protocols: FTP and HTTP", Infrastructure Operational Protocols: FTP and HTTP",
RFC 2585, DOI 10.17487/RFC2585, May 1999, <http://www.rfc- RFC 2585, DOI 10.17487/RFC2585, May 1999, <http://www.rfc-
editor.org/info/rfc2585>. editor.org/info/rfc2585>.
[RFC2616] Fielding, R., Gettys, J., Mogul, J., Frystyk, H., Masinter,
L., Leach, P., and T. Berners-Lee, "Hypertext Transfer
Protocol -- HTTP/1.1", RFC 2616, DOI 10.17487/RFC2616, June
1999, <http://www.rfc-editor.org/info/rfc2616>. Obsoleted
by RFC7230, RFC7231, RFC7232, RFC7233, RFC7234, RFC7235.
[RFC2818] Rescorla, E., "HTTP Over TLS", RFC 2818, DOI [RFC2818] Rescorla, E., "HTTP Over TLS", RFC 2818, DOI
10.17487/RFC2818, May 2000, <http://www.rfc- 10.17487/RFC2818, May 2000, <http://www.rfc-
editor.org/info/rfc2818>. editor.org/info/rfc2818>.
[RFC2985] Nystrom, M. and B. Kaliski, "PKCS #9: Selected Object [RFC2985] Nystrom, M. and B. Kaliski, "PKCS #9: Selected Object
Classes and Attribute Types Version 2.0", RFC 2985, DOI Classes and Attribute Types Version 2.0", RFC 2985, DOI
10.17487/RFC2985, November 2000, <http://www.rfc- 10.17487/RFC2985, November 2000, <http://www.rfc-
editor.org/info/rfc2985>. editor.org/info/rfc2985>.
[RFC3370] Housley, R., "Cryptographic Message Syntax (CMS) [RFC3370] Housley, R., "Cryptographic Message Syntax (CMS)
skipping to change at page 40, line 24 skipping to change at page 41, line 31
[RFC4073] Housley, R., "Protecting Multiple Contents with the [RFC4073] Housley, R., "Protecting Multiple Contents with the
Cryptographic Message Syntax (CMS)", RFC 4073, DOI Cryptographic Message Syntax (CMS)", RFC 4073, DOI
10.17487/RFC4073, May 2005, <http://www.rfc- 10.17487/RFC4073, May 2005, <http://www.rfc-
editor.org/info/rfc4073>. editor.org/info/rfc4073>.
[RFC4108] Housley, R., "Using Cryptographic Message Syntax (CMS) to [RFC4108] Housley, R., "Using Cryptographic Message Syntax (CMS) to
Protect Firmware Packages", RFC 4108, DOI 10.17487/RFC4108, Protect Firmware Packages", RFC 4108, DOI 10.17487/RFC4108,
August 2005, <http://www.rfc-editor.org/info/rfc4108>. August 2005, <http://www.rfc-editor.org/info/rfc4108>.
[RFC4627] Crockford, D., "The application/json Media Type for [RFC4514] Zeilenga, K., Ed., "Lightweight Directory Access Protocol
JavaScript Object Notation (JSON)", RFC 4627, DOI (LDAP): String Representation of Distinguished Names",
10.17487/RFC4627, July 2006, <http://www.rfc- RFC 4514, DOI 10.17487/RFC4514, June 2006, <http://www.rfc-
editor.org/info/rfc4627>. Obsoleted by RFC7159. editor.org/info/rfc4514>.
[RFC5226] Narten, T. and H. Alvestrand, "Guidelines for Writing an
IANA Considerations Section in RFCs", BCP 26, RFC 5226, DOI
10.17487/RFC5226, May 2008, <http://www.rfc-
editor.org/info/rfc5226>.
[RFC5246] Dierks, T. and E. Rescorla, "The Transport Layer Security [RFC5246] Dierks, T. and E. Rescorla, "The Transport Layer Security
(TLS) Protocol Version 1.2", RFC 5246, DOI (TLS) Protocol Version 1.2", RFC 5246, DOI
10.17487/RFC5246, August 2008, <http://www.rfc- 10.17487/RFC5246, August 2008, <http://www.rfc-
editor.org/info/rfc5246>. editor.org/info/rfc5246>.
[RFC5272] Schaad, J. and M. Myers, "Certificate Management over CMS [RFC5272] Schaad, J. and M. Myers, "Certificate Management over CMS
(CMC)", RFC 5272, DOI 10.17487/RFC5272, June 2008, (CMC)", RFC 5272, DOI 10.17487/RFC5272, June 2008,
<http://www.rfc-editor.org/info/rfc5272>. <http://www.rfc-editor.org/info/rfc5272>.
skipping to change at page 43, line 37 skipping to change at page 44, line 39
[RFC7231] Fielding, R., Ed., and J. Reschke, Ed., "Hypertext Transfer [RFC7231] Fielding, R., Ed., and J. Reschke, Ed., "Hypertext Transfer
Protocol (HTTP/1.1): Semantics and Content", RFC 7231, DOI Protocol (HTTP/1.1): Semantics and Content", RFC 7231, DOI
10.17487/RFC7231, June 2014, <http://www.rfc- 10.17487/RFC7231, June 2014, <http://www.rfc-
editor.org/info/rfc7231>. editor.org/info/rfc7231>.
[RFC7292] Moriarty, K., Ed., Nystrom, M., Parkinson, S., Rusch, A., [RFC7292] Moriarty, K., Ed., Nystrom, M., Parkinson, S., Rusch, A.,
and M. Scott, "PKCS #12: Personal Information Exchange and M. Scott, "PKCS #12: Personal Information Exchange
Syntax v1.1", RFC 7292, DOI 10.17487/RFC7292, July 2014, Syntax v1.1", RFC 7292, DOI 10.17487/RFC7292, July 2014,
<http://www.rfc-editor.org/info/rfc7292>. <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 [XML] W3C, "Extensible Markup Language (XML) 1.0 (Fifth
Edition)", W3C Recommendation, November 2008, Edition)", W3C Recommendation, November 2008,
<http://www.w3.org/TR/2006/REC-xml-20060816/>. <http://www.w3.org/TR/2006/REC-xml-20060816/>.
[XMLSCHEMA] [XMLSCHEMA]
Malhotra, A. and P. Biron, "XML Schema Part 2: Datatypes Malhotra, A. and P. Biron, "XML Schema Part 2: Datatypes
Second Edition", World Wide Web Consortium Recommendation Second Edition", World Wide Web Consortium Recommendation
REC-xmlschema-2-20041082, October 2004, REC-xmlschema-2-20041082, October 2004,
<http://www.w3.org/TR/2004/REC-xmlschema-2-20041028>. <http://www.w3.org/TR/2004/REC-xmlschema-2-20041028>.
skipping to change at page 45, line 31 skipping to change at page 46, line 37
Content-Type: application/pkcs7-mime | /fullcmc Content-Type: application/pkcs7-mime | /fullcmc
smime-type=CMC-request | smime-type=CMC-request |
| |
<-------------------- | <-------------------- |
(success or failure) | (success or failure) |
POST res: PKIResponse | /simpleenroll POST res: PKIResponse | /simpleenroll
Content-Type: application/pkcs7-mime | /simplereenroll Content-Type: application/pkcs7-mime | /simplereenroll
smime-type=certs-only | /fullcmc smime-type=certs-only | /fullcmc
| |
Content-Type: application/pkcs7-mime | /fullcmc Content-Type: application/pkcs7-mime | /fullcmc
smime-type=CMC-response | smime-type=CMC-response |
| |
--------------------> -+ --------------------> -+
GET req: | /firmware GET req: | /firmware
<-------------------- | /tamp <-------------------- | /tamp
GET res: Firmware, TAMP Query | /symmetrickeys GET res: Firmware, TAMP Query | /symmetrickeys
+ Updates, Symmetric Keys | + Updates, Symmetric Keys |
Content-Type: application/cms | Content-Type: application/cms |
| |
---------------------> -+ ---------------------> -+
POST res: Firmware Receipts or Errors, | /firmware/return POST res: Firmware Receipts or Errors, | /firmware/return
 End of changes. 112 change blocks. 
344 lines changed or deleted 401 lines changed or added

This html diff was produced by rfcdiff 1.48. The latest version is available from http://tools.ietf.org/tools/rfcdiff/