RFC 8295
EST (Enrollment over Secure Transport) Extensions
Internet Engineering Task Force (IETF) S. Turner Request for Comments: 8295 sn3rd Category: Standards Track January 2018 ISSN: 2070-1721 EST (Enrollment over Secure Transport) ExtensionsAbstract
The EST (Enrollment over Secure Transport) protocol defines the Well- Known URI (Uniform Resource Identifier) -- /.well-known/est -- along with a number of other path components that clients use for PKI (Public Key Infrastructure) services, namely certificate enrollment (e.g., /simpleenroll). This document defines a number of other PKI services as additional path components -- specifically, firmware and trust anchors as well as symmetric, asymmetric, and encrypted keys. This document also specifies the PAL (Package Availability List), which is an XML (Extensible Markup Language) file or JSON (JavaScript Object Notation) object that clients use to retrieve packages available and authorized for them. This document extends the EST server path components to provide these additional services. Status of This Memo This is an Internet Standards Track document. This document is a product of the Internet Engineering Task Force (IETF). It represents the consensus of the IETF community. It has received public review and has been approved for publication by the Internet Engineering Steering Group (IESG). Further information on Internet Standards is available in Section 2 of RFC 7841. Information about the current status of this document, any errata, and how to provide feedback on it may be obtained at https://www.rfc-editor.org/info/rfc8295.
Copyright Notice Copyright (c) 2018 IETF Trust and the persons identified as the document authors. All rights reserved. This document is subject to BCP 78 and the IETF Trust's Legal Provisions Relating to IETF Documents (https://trustee.ietf.org/license-info) in effect on the date of publication of this document. Please review these documents carefully, as they describe your rights and restrictions with respect to this document. Code Components extracted from this document must include Simplified BSD License text as described in Section 4.e of the Trust Legal Provisions and are provided without warranty as described in the Simplified BSD License.Table of Contents
1. Introduction ....................................................4 1.1. Definitions ................................................6 1.2. Authentication and Authorization ...........................7 1.3. TLS Cipher Suites ..........................................7 1.4. URI Configuration ..........................................7 1.5. Message Types ..............................................8 1.6. Key Words .................................................10 2. Locate Available Packages ......................................10 2.1. PAL Format ................................................12 2.1.1. PAL Package Types ..................................14 2.1.2. PAL XML Schema .....................................19 2.1.3. PAL JSON Object ....................................23 2.2. Request PAL ...............................................23 2.3. Provide PAL ...............................................24 3. Distribute EE Certificates .....................................25 3.1. EE Certificate Request ....................................25 3.2. EE Certificate Response ...................................26 4. Distribute CRLs and ARLs .......................................26 4.1. CRL Request ...............................................26 4.2. CRL Response ..............................................26 5. Symmetric Keys, Receipts, and Errors ...........................27 5.1. Symmetric Keys ............................................27 5.1.1. Distribute Symmetric Keys ..........................28 5.1.2. Symmetric Key Response .............................28 5.2. Symmetric Key Receipts and Errors .........................29 5.2.1. Provide Symmetric Key Receipt or Error .............30 5.2.2. Symmetric Key Receipt or Error Response ............31
6. Firmware, Receipts, and Errors .................................31 6.1. Firmware ..................................................31 6.1.1. Distribute Firmware ................................32 6.1.2. Firmware Response ..................................32 6.2. Firmware Receipts and Errors ..............................33 6.2.1. Provide Firmware Receipt or Error ..................33 6.2.2. Firmware Receipt or Error Response .................33 7. Trust Anchor Management Protocol ...............................34 7.1. TAMP Status Query, Trust Anchor Update, Apex Trust Anchor Update, Community Update, and Sequence Number Adjust ................................34 7.1.1. Request TAMP Packages ..............................34 7.1.2. Return TAMP Packages ...............................35 7.2. TAMP Responses, Confirms, and Errors ......................35 7.2.1. Provide TAMP Responses, Confirms, or Errors ........36 7.2.2. TAMP Responses, Confirms, and Error Responses ......36 8. Asymmetric Keys, Receipts, and Errors ..........................36 8.1. Asymmetric Key Encapsulation ..............................37 8.2. Asymmetric Key Package Receipts and Errors ................38 8.3. PKCS #12 ..................................................39 8.3.1. Server-Side Key Generation Request .................39 8.3.2. Server-Side Key Generation Response ................39 9. PAL and Certificate Enrollment .................................40 10. Security Considerations .......................................43 11. IANA Considerations ...........................................44 11.1. PAL Name Space ...........................................44 11.2. PAL XML Schema ...........................................44 11.3. PAL Package Types ........................................44 12. References ....................................................45 12.1. Normative References .....................................45 12.2. Informative References ...................................50 Appendix A. Example Use of PAL ....................................51 Appendix B. Additional CSR Attributes .............................53 Acknowledgements ..................................................54 Author's Address ..................................................54
1. Introduction
The EST (Enrollment over Secure Transport) protocol [RFC7030] defines the Well-Known URI (Uniform Resource Identifier) -- /.well-known/est -- to support selected services related to the PKI (Public Key Infrastructure), with such PCs (path components) as simple enrollment with /simpleenroll, rekey or renew with /simplereenroll, etc. A server that wishes to support additional PKI-related services and other security-related packages could use the same .well-known URI by defining additional PCs. This document defines six such PCs: o /pal - The PAL (Package Availability List) provides a list of all known packages available and authorized for a client. By accessing the service provided by this PC first, the client can walk through the PAL and download all the packages necessary to begin operating securely. The PAL essentially points to other PCs, including the PCs defined in this document as well as those defined in [RFC7030] (e.g., /cacerts, /simpleenroll, /simplereenroll, /fullcmc, /serverkeygen, and /csrattrs). The /pal PC is described in Section 2. o /eecerts - EE (End-Entity) certificates [RFC5280] are needed by the client when they invoke a security protocol for communicating with a peer (i.e., they become operational and do something meaningful as opposed to just communicating with the infrastructure). If the infrastructure knows the certificate(s) needed by the client, then providing the peer's certificate avoids the client having to discover the peer's certificate. This service is not meant to be a general-purpose repository to which clients query a "repository" and then get a response; this is purely a push mechanism. The /eecerts PC is described in Section 3. o /crls - CRLs (Certificate Revocation Lists) and ARLs (Authority Revocation Lists) [RFC5280] are also needed by the client when they validate certificate paths. CRLs (and ARLs) from TAs (Trust Anchors) and intermediate CAs (Certification Authorities) are needed to validate the certificates used to generate the client's certificate or the peer's certificate, which is provided by the /eecerts PC, and providing them saves the client from having to "discover" them and then retrieve them. CRL "discovery" is greatly aided by the inclusion of the CRL Distribution Point certificate extension [RFC5280], but this extension is not always present in certificates and requires another connection to retrieve them. Like the /eecerts PC, this service is not meant to be a general-purpose repository to which clients query a repository and then get a response; this is purely a push mechanism. The /crls PC is described in Section 4.
o /symmetrickeys - In some cases, clients use symmetric keys
[RFC6031] when communicating with their peers. If the client's
peers are known by the server a priori, then providing them saves
the client or an administrator from later having to find,
retrieve, and install them. Like the /eecerts and /crls PCs, this
service is not meant to be a general-purpose repository to which
clients query a repository and then get a response; this is purely
a push mechanism for the keys themselves. However, things do not
always go as planned, and clients need to inform the server about
any errors. If things did go well, then the client, if requested,
needs to provide a receipt [RFC7191]. The /symmetrickeys and
/symmetrickeys/return PCs are described in Section 5.
o /firmware - Some client firmware and software support automatic
update mechanisms, and some do not. For those that do not, the
/firmware PC provides a mechanism for the infrastructure to inform
the client that firmware and software updates [RFC4108] are
available. Because updates do not always go as planned and
because sometimes the server needs to know whether the firmware
was received and processed, this PC also provides a mechanism to
return errors and receipts. The /firmware and /firmware/return
PCs are defined in Section 6.
o /tamp - To control the TAs in client TA databases, servers use the
/tamp PC to request that clients retrieve TAMP (Trust Anchor
Management Protocol) query, update, and adjust packages [RFC5934],
and clients use the /tamp/return PC to return TAMP responses,
confirms, and errors [RFC5934]. The /tamp and /tamp/return PCs
are defined in Section 7.
This document also extends the /est/serverkeygen PC [RFC7030] to
support the following (see Section 8):
o Returning asymmetric key package receipts and errors [RFC7191].
o Encapsulating returned asymmetric keys in additional CMS
(Cryptographic Message Syntax) content types [RFC7193].
o Returning server-generated public key pairs encapsulated in
PKCS #12 (Public Key Cryptography Standard #12) [RFC7292].
While the motivation is to provide packages to clients during
enrollment so that they can perform securely after enrollment, the
services defined in this specification can be used after enrollment.
1.1. Definitions
Familiarity with the following specifications is assumed: o "Using Cryptographic Message Syntax (CMS) to Protect Firmware Packages" [RFC4108] o "Certificate Management over CMS (CMC)" [RFC5272] o "Cryptographic Message Syntax (CMS) Encrypted Key Package Content Type" [RFC6032] o "Cryptographic Message Syntax (CMS)" [RFC5652] o "Additional New ASN.1 Modules for the Cryptographic Message Syntax (CMS) and the Public Key Infrastructure Using X.509 (PKIX)" [RFC6268] o "Trust Anchor Management Protocol (TAMP)" [RFC5934] o "Cryptographic Message Syntax (CMS) Content Constraints Extension" [RFC6010] o "Cryptographic Message Syntax (CMS) Symmetric Key Package Content Type" [RFC6031] o "Enrollment over Secure Transport" [RFC7030] o "Cryptographic Message Syntax (CMS) Key Package Receipt and Error Content Types" [RFC7191] Also, familiarity with the CMS protecting content types signed-data and encrypted-data [RFC5652] is assumed. The CMS encrypted key package is defined in [RFC6032]. In addition to the definitions found in [RFC7030], the following definitions are used in this document: Agent: An entity that performs functions on behalf of a client. Agents can service a) one or more clients on the same network as the server, b) clients on non-IP-based networks, or c) clients that have a non-electronic air gap [RFC4949] between themselves and the server. Interactions between the agent and client in the last two cases are beyond the scope of this document. Before an agent can service clients, the agent must have a trust relationship with the server (i.e., be authorized to act on behalf of clients).
Client: A device that ultimately consumes and uses the packages to
enable communications. In other words, the client is the endpoint
for the packages, and an agent may have one or more clients. To
avoid confusion, this document henceforth uses the term "client"
to refer to both agents and clients.
Package: An object that contains one or more content types. There
are numerous types of packages, e.g., packages for asymmetric
keys, symmetric keys, encrypted keys, CRLs, firmware, and TAMP.
See Section 2.1.1. All of these packages are digitally signed by
their creator and encapsulated in a CMS signed-data [RFC5652]
[RFC6268] (except the public key certificates and CRLs that are
already digitally signed by a CA): firmware receipts and errors;
TAMP responses, confirms, and errors; and "key package" receipts
and errors that can be optionally signed. Certificates and CRLs
are included in a package that uses signed-data, which is often
referred to as a "degenerate CMS", or as a "certs-only" [RFC5751]
[RFC6268] or "crls-only" message (see Section 4.2), but no
signature or content is present -- hence the names "certs-only"
and "crls-only".
Note: As per [RFC7030], the creator may or may not be the EST
server or the EST CA.
1.2. Authentication and Authorization
Client and server authentication as well as client and server
authorization are as defined in [RFC7030]. The requirements for each
are discussed in the "request" and "response" sections (e.g.,
Sections 3.1 and 3.2 of this document) of each of the PCs defined
herein.
The requirements for the TA databases are as specified in [RFC7030]
as well.
1.3. TLS Cipher Suites
TLS (Transport Layer Security) cipher suites and issues associated
with them are as defined in [RFC7030].
1.4. URI Configuration
As specified in Section 3.1 of [RFC7030], the client is configured
with sufficient information to form the server URI [RFC3986]. Like
EST, this configuration mechanism is beyond the scope of this
document.
1.5. Message Types
This document uses existing media types for the messages as specified by "Internet X.509 Public Key Infrastructure Operational Protocols: FTP and HTTP" [RFC2585], "The application/pkcs10 Media Type" [RFC5967], and "Certificate Management over CMS (CMC)" [RFC5272]. For consistency with [RFC5273], each distinct EST message type uses an HTTP Content-Type header with a specific media type. The EST messages, their corresponding media types for each operation, and the sections that provide request and response information are as follows: +-------------------+---------------------------------+---------------+ | Message type | Request media type | Request | | | Response media type(s) | Response | | (per operation) | Source(s) of types | | +===================+=================================+===============+ | Locate Available | N/A | Section 2.2 | | Packages | application/xml or | Section 2.3 | | | application/json | | | | [RFC7303] [RFC8259] | | | /pal | | | +===================+=================================+===============+ | Distribute EE | N/A | Section 3.1 | | Certificates | application/pkcs7-mime | Section 3.2 | | | [RFC5751] | | | /eecerts | | | +===================+=================================+===============+ | Distribute CRLs | N/A | Section 4.1 | | | application/pkcs7-mime | Section 4.2 | | | [RFC5751] | | | /crls | | | +===================+=================================+===============+ | Symmetric Key | N/A | Section 5.1.1 | | Distribution | application/cms | Section 5.1.2 | | | [RFC7193] | | | /symmetrickeys | | | +===================+=================================+===============+ | Return Symmetric | application/cms | Section 5.2.1 | | Key | N/A | Section 5.2.2 | | Receipts/Errors | [RFC7193] | | | | | | | /symmetrickeys/ | | | | return | | |
+===================+=================================+===============+ | Firmware | N/A | Section 6.1.1 | | Distribution | application/cms | Section 6.1.2 | | | [RFC7193] | | | /firmware | | | +===================+=================================+===============+ | Return Firmware | application/cms | Section 6.2.1 | | Receipts/Errors | N/A | Section 6.2.2 | | | [RFC7193] | | | /firmware/return | | | +===================+=================================+===============+ | Trust Anchor | N/A | Section 7.1.1 | | Management | application/ | Section 7.1.2 | | | tamp-status-query | | | | tamp-update | | | | tamp-apex-update | | | | tamp-community-update | | | | tamp-sequence-adjust | | | | [RFC5934] | | | /tamp | | | +===================+=================================+===============+ | Return TAMP | application/ | Section 7.2.1 | | Responses/ | tamp-status-response | | | Confirms/ | tamp-update-confirm | | | Errors | tamp-apex-update-confirm | | | | tamp-community-update-confirm | | | | tamp-sequence-adjust-confirm | | | | tamp-error | | | | N/A | Section 7.2.2 | | | [RFC5934] | | | /tamp/return | | | +===================+=================================+===============+ | Server-Side Key | application/pkcs10 with | Section 8.1 | | Generation | content type attribute | | | | CSR* | | | | application/cms | Section 8.1 | | /serverkeygen | [RFC5967] [RFC7193] [RFC7030] | |
+===================+=================================+===============+ | Return Asymmetric | application/cms | Section 8.2 | | Key | N/A | Section 8.2 | | Receipts/Errors | [RFC7193] | | | | | | | /serverkeygen/ | | | | return | | | +===================+=================================+===============+ | Server-Side Key | application/pkcs10 | Section 8.3.1 | | Generation: | application/pkcs12 | Section 8.3.2 | | PKCS #12 | [RFC5967] [RFC7193] [RFC7030] | | | | | | | /serverkeygen | | | +===================+=================================+===============+ * Certificate Signing Request1.6. Key Words
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in BCP 14 [RFC2119] [RFC8174] when, and only when, they appear in all capitals, as shown here.
(page 10 continued on part 2)
