| < 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/ | ||||