--- 1/draft-ietf-lamps-lightweight-cmp-profile-02.txt 2020-10-02 09:13:12.938839762 -0700 +++ 2/draft-ietf-lamps-lightweight-cmp-profile-03.txt 2020-10-02 09:13:13.094843693 -0700 @@ -1,19 +1,19 @@ LAMPS Working Group H. Brockhaus Internet-Draft S. Fries Intended status: Standards Track D. von Oheimb -Expires: January 12, 2021 Siemens - July 11, 2020 +Expires: April 5, 2021 Siemens + October 2, 2020 Lightweight CMP Profile - draft-ietf-lamps-lightweight-cmp-profile-02 + draft-ietf-lamps-lightweight-cmp-profile-03 Abstract The goal of this document is to facilitate interoperability and automation by profiling the Certificate Management Protocol (CMP) version 2, the related Certificate Request Message Format (CRMF) version 2, and the HTTP Transfer for the Certificate Management Protocol. It specifies a subset of CMP and CRMF focusing on typical uses cases relevant for managing certificates of devices in many industrial and IoT scenarios. To limit the overhead of certificate @@ -30,21 +30,21 @@ Internet-Drafts are working documents of the Internet Engineering Task Force (IETF). Note that other groups may also distribute working documents as Internet-Drafts. The list of current Internet- Drafts is at https://datatracker.ietf.org/drafts/current/. Internet-Drafts are draft documents valid for a maximum of six months and may be updated, replaced, or obsoleted by other documents at any time. It is inappropriate to use Internet-Drafts as reference material or to cite them other than as "work in progress." - This Internet-Draft will expire on January 12, 2021. + This Internet-Draft will expire on April 5, 2021. Copyright Notice Copyright (c) 2020 IETF Trust and the persons identified as the document authors. All rights reserved. This document is subject to BCP 78 and the IETF Trust's Legal Provisions Relating to IETF Documents (https://trustee.ietf.org/license-info) in effect on the date of publication of this document. Please review these documents @@ -60,97 +60,96 @@ 1.1. Motivation for profiling CMP . . . . . . . . . . . . . . 4 1.2. Motivation for a lightweight profile for CMP . . . . . . 5 1.3. Existing CMP profiles . . . . . . . . . . . . . . . . . . 5 1.4. Compatibility with existing CMP profiles . . . . . . . . 7 1.5. Scope of this document . . . . . . . . . . . . . . . . . 9 1.6. Structure of this document . . . . . . . . . . . . . . . 9 1.7. Convention and Terminology . . . . . . . . . . . . . . . 10 2. Architecture and use cases . . . . . . . . . . . . . . . . . 11 2.1. Solution architecture . . . . . . . . . . . . . . . . . . 11 2.2. Basic generic CMP message content . . . . . . . . . . . . 12 - 2.3. Supported PKI management operations . . . . . . . . . . . 12 + 2.3. Supported PKI management operations . . . . . . . . . . . 13 2.3.1. Mandatory PKI management operations . . . . . . . . . 13 - 2.3.2. Recommended PKI management operations . . . . . . . . 13 + 2.3.2. Recommended PKI management operations . . . . . . . . 14 2.3.3. Optional PKI management operations . . . . . . . . . 14 - 2.4. CMP message transport . . . . . . . . . . . . . . . . . . 14 - 3. Generic parts of the PKI message . . . . . . . . . . . . . . 15 - 3.1. General description of the CMP message header . . . . . . 16 - 3.2. General description of the CMP message protection . . . . 17 - 3.3. General description of CMP message extraCerts . . . . . . 18 - 4. End Entity focused PKI management operations . . . . . . . . 19 - 4.1. Requesting a new certificate from a PKI . . . . . . . . . 19 + 2.4. CMP message transport . . . . . . . . . . . . . . . . . . 15 + 3. Generic parts of the PKI message . . . . . . . . . . . . . . 16 + 3.1. General description of the CMP message header . . . . . . 17 + 3.2. General description of the CMP message protection . . . . 19 + 3.3. General description of CMP message extraCerts . . . . . . 20 + 4. End Entity focused PKI management operations . . . . . . . . 20 + 4.1. Requesting a new certificate from a PKI . . . . . . . . . 21 4.1.1. Request a certificate from a new PKI with signature - protection . . . . . . . . . . . . . . . . . . . . . 20 + protection . . . . . . . . . . . . . . . . . . . . . 22 4.1.2. Request a certificate from a trusted PKI with - signature protection . . . . . . . . . . . . . . . . 27 + signature protection . . . . . . . . . . . . . . . . 28 4.1.3. Update an existing certificate with signature - protection . . . . . . . . . . . . . . . . . . . . . 28 - 4.1.4. Request a certificate from a PKI with MAC protection 29 + protection . . . . . . . . . . . . . . . . . . . . . 29 + 4.1.4. Request a certificate from a PKI with MAC protection 30 4.1.5. Request a certificate from a legacy PKI using PKCS#10 - request . . . . . . . . . . . . . . . . . . . . . . . 31 + request . . . . . . . . . . . . . . . . . . . . . . . 32 4.1.6. Generate the key pair centrally at the PKI management - entity . . . . . . . . . . . . . . . . . . . . . . . 32 - 4.1.6.1. Using key agreement key management technique . . 37 - 4.1.6.2. Using key transport key management technique . . 38 - 4.1.6.3. Using password-based key management technique . . 39 - 4.1.7. Delayed enrollment . . . . . . . . . . . . . . . . . 40 - 4.2. Revoking a certificate . . . . . . . . . . . . . . . . . 45 - 4.3. Error reporting . . . . . . . . . . . . . . . . . . . . . 47 - 4.4. Support messages . . . . . . . . . . . . . . . . . . . . 49 - 4.4.1. General message and response . . . . . . . . . . . . 50 - 4.4.2. Get CA certificates . . . . . . . . . . . . . . . . . 51 - 4.4.3. Get root CA certificate update . . . . . . . . . . . 52 - 4.4.4. Get certificate request template . . . . . . . . . . 53 - 5. LRA and RA focused PKI management operations . . . . . . . . 55 - 5.1. Forwarding of messages . . . . . . . . . . . . . . . . . 55 - 5.1.1. Not changing protection . . . . . . . . . . . . . . . 57 - 5.1.2. Replacing protection . . . . . . . . . . . . . . . . 57 - 5.1.2.1. Keeping proof-of-possession . . . . . . . . . . . 58 - 5.1.2.2. Breaking proof-of-possession . . . . . . . . . . 58 - 5.1.3. Adding Protection . . . . . . . . . . . . . . . . . . 59 - 5.1.3.1. Handling a single PKI management message . . . . 60 - 5.1.3.2. Handling a batch of PKI management messages . . . 60 - 5.1.4. Initiating delayed enrollment . . . . . . . . . . . . 61 - 5.2. Revoking certificates on behalf of another's entities . . 62 - 5.3. Error reporting . . . . . . . . . . . . . . . . . . . . . 62 - 6. CMP message transport variants . . . . . . . . . . . . . . . 63 - 6.1. Definition and discovery of HTTP URIs . . . . . . . . . . 63 - 6.2. HTTP transport . . . . . . . . . . . . . . . . . . . . . 66 - 6.3. HTTPS transport using certificates . . . . . . . . . . . 66 - 6.4. HTTPS transport using shared secrets . . . . . . . . . . 67 - 6.5. Offline transport . . . . . . . . . . . . . . . . . . . . 67 - 6.5.1. File-based transport . . . . . . . . . . . . . . . . 68 - 6.5.2. Other asynchronous transport protocols . . . . . . . 68 - 6.6. CoAP transport . . . . . . . . . . . . . . . . . . . . . 68 - 6.7. Piggybacking on other reliable transport . . . . . . . . 68 - 7. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 69 - 8. Security Considerations . . . . . . . . . . . . . . . . . . . 69 - 9. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 69 - 10. References . . . . . . . . . . . . . . . . . . . . . . . . . 69 - 10.1. Normative References . . . . . . . . . . . . . . . . . . 69 - 10.2. Informative References . . . . . . . . . . . . . . . . . 70 - Appendix A. ASN.1 Syntax . . . . . . . . . . . . . . . . . . . . 72 - Appendix B. Example for CertReqTemplate . . . . . . . . . . . . 72 - Appendix C. History of changes . . . . . . . . . . . . . . . . . 74 - Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 77 + entity . . . . . . . . . . . . . . . . . . . . . . . 34 + 4.1.6.1. Using key agreement key management technique . . 40 + 4.1.6.2. Using key transport key management technique . . 41 + 4.1.6.3. Using password-based key management technique . . 42 + 4.1.7. Delayed enrollment . . . . . . . . . . . . . . . . . 43 + 4.2. Revoking a certificate . . . . . . . . . . . . . . . . . 48 + 4.3. Error reporting . . . . . . . . . . . . . . . . . . . . . 50 + 4.4. Support messages . . . . . . . . . . . . . . . . . . . . 52 + 4.4.1. General message and response . . . . . . . . . . . . 53 + 4.4.2. Get CA certificates . . . . . . . . . . . . . . . . . 54 + 4.4.3. Get root CA certificate update . . . . . . . . . . . 55 + 4.4.4. Get certificate request template . . . . . . . . . . 56 + 5. LRA and RA focused PKI management operations . . . . . . . . 58 + 5.1. Forwarding of messages . . . . . . . . . . . . . . . . . 59 + 5.1.1. Not changing protection . . . . . . . . . . . . . . . 61 + 5.1.2. Replacing protection . . . . . . . . . . . . . . . . 61 + 5.1.2.1. Keeping proof-of-possession . . . . . . . . . . . 62 + 5.1.2.2. Breaking proof-of-possession . . . . . . . . . . 62 + 5.1.3. Adding Protection . . . . . . . . . . . . . . . . . . 63 + 5.1.3.1. Handling a single PKI management message . . . . 64 + 5.1.3.2. Handling a batch of PKI management messages . . . 64 + 5.1.4. Initiating delayed enrollment . . . . . . . . . . . . 65 + 5.2. Revoking certificates on behalf of another's entities . . 66 + 5.3. Error reporting . . . . . . . . . . . . . . . . . . . . . 66 + 6. CMP message transport variants . . . . . . . . . . . . . . . 67 + 6.1. HTTP transport . . . . . . . . . . . . . . . . . . . . . 67 + 6.2. HTTPS transport using certificates . . . . . . . . . . . 69 + 6.3. HTTPS transport using shared secrets . . . . . . . . . . 70 + 6.4. Offline transport . . . . . . . . . . . . . . . . . . . . 71 + 6.4.1. File-based transport . . . . . . . . . . . . . . . . 71 + 6.4.2. Other asynchronous transport protocols . . . . . . . 71 + 6.5. CoAP transport . . . . . . . . . . . . . . . . . . . . . 71 + 6.6. Piggybacking on other reliable transport . . . . . . . . 71 + 7. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 72 + 8. Security Considerations . . . . . . . . . . . . . . . . . . . 72 + 9. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 72 + 10. References . . . . . . . . . . . . . . . . . . . . . . . . . 72 + 10.1. Normative References . . . . . . . . . . . . . . . . . . 72 + 10.2. Informative References . . . . . . . . . . . . . . . . . 73 + Appendix A. Example for CertReqTemplate . . . . . . . . . . . . 75 + Appendix B. History of changes . . . . . . . . . . . . . . . . . 76 + Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 80 1. Introduction - !!! The change history was moved to Appendix C !!! + !!! The change history was moved to Appendix B !!! This document specifies PKI management operations supporting machine- to-machine and IoT use cases. The focus lies on maximum automation and interoperable implementation of all involved PKI entities from end entities (EE) through an optional Local Registration Authority (LRA) and the RA up to the CA. The profile makes use of the concepts and syntax specified in CMP [RFC4210], CRMF [RFC4211], HTTP transfer for CMP [RFC6712], and CMP Updates [I-D.ietf-lamps-cmp-updates]. + Especially CMP and CRMF are very feature-rich standards, while only a limited subset of the specified functionality is needed in many environments. Additionally, the standards are not always precise enough on how to interpret and implement the described concepts. Therefore, this document aims at tailoring and specifying in more detail how to use these concepts to implement lightweight automated certificate management. 1.1. Motivation for profiling CMP @@ -169,21 +168,21 @@ implementation of all options is unrealistic because this would take enormous effort. Moreover, many details of the CMP protocol have been left open or have not been specified in full preciseness. The profiles specified in Appendix D and E of [RFC4210] offer some more detailed PKI management operations. But the specific needs of highly automated scenarios for a machine-to-machine communication are not covered sufficiently. - As also 3GPP and UNISIG already put across, profiling is a way of + As also ETSI and UNISIG already put across, profiling is a way of coping with the challenges mentioned above. To profile means to take advantage of the strengths of the given protocol, while explicitly narrowing down the options it provides to exactly those needed for the purpose(s) at hand and eliminating all identified ambiguities. In this way all the general and applicable aspects of the protocol can be taken over and only the peculiarities of the target scenario need to be dealt with specifically. Doing such a profiling for a new target environment can be a high effort because the range of available options needs to be well @@ -302,29 +301,29 @@ by CA-X. Furthermore, some mechanism must already have been established within the Personal Security Environment (PSE) of the EE that would allow it to authenticate and verify PKIMessages signed by CA-1. The content is similar to the PKI management operation specified in Section 4.1.1 of this document. Both Appendixes focus on EE to CA/RA PKI management operations and do not address further profiling of RA to CA communication as typically used for full backend automation. - 3GPP makes use of CMP [RFC4210] in its Technical Specification 133 - 310 [ETSI-3GPP] for automatic management of IPSec certificates in + ETSI makes use of CMP [RFC4210] in its Technical Specification 133 + 310 [ETSI-TS133310] for automatic management of IPSec certificates in UMTS, LTE, and 5G backbone networks. Since 2010 a dedicated CMP profile for initial certificate enrollment and update operations between EE and RA/CA is specified in that document. UNISIG has included a CMP profile for certificate enrollment in the subset 137 specifying the ETRAM/ECTS on-line key management for train - control systems [UNISIG] in 2015. + control systems [UNISIG-Subset137] in 2015. Both standardization bodies use CMP [RFC4210], CRMF [RFC4211], and HTTP transfer for CMP [RFC6712] to add tailored means for automated PKI management operations for unattended machine or application- oriented end entities. 1.4. Compatibility with existing CMP profiles The profile specified in this document is compatible with CMP [RFC4210] Appendixes D and E (PKI Management Message Profiles), with @@ -343,50 +342,68 @@ raVerified), o confirmation of newly enrolled certificates may be omitted, and o all PKI management operations consist of request-response message pairs originating at the EE, i.e., announcement messages are omitted. The profile specified in this document is compatible with the CMP profile for UMTS, LTE, and 5G network domain security and - authentication framework [ETSI-3GPP], except that: + authentication framework [ETSI-TS133310], except that: o protection of initial PKI management operations may be HMAC-based, - o the subject name is mandatory in certificate templates, and + o the subject field is mandatory in certificate templates, and o confirmation of newly enrolled certificates may be omitted. The profile specified in this document is compatible with the CMP profile for on-line key management in rail networks as specified in - UNISIG subset-137 [UNISIG], except that: + UNISIG Subset-137 [UNISIG-Subset137], except that: o As stated in Section 4.1.1 a CMP message SHALL only consist of one - certificate request (CertReqMsg). Therefore, UNISIG is in - conflict with this document as subset-137 allows to transport more - than one certificate request. + certificate request (CertReqMsg). As UNISIG Subset-137 Table 6 + [UNISIG-Subset137] allows to transport more than one certificate + request message, this conflicts with this document. - o as of RFC 4210 [RFC4210] the messageTime is required to be - Greenwich Mean Time coded as generalizedTime (Note: While UNISIG - explicitly states that the messageTime in required to be 'UTC - time', it is not clear if this means a coding as UTCTime or - generalizedTime and if other time zones than Greenwich Mean Time - shall be allowed. Therefore, UNISG may be in conflict with - RFC 4210 [RFC4210]. Both time formats are described in RFC 5280 - [RFC5280] section 4.1.2.5.), and + o There is no automatic revocation specified in this document. As + UNISIG Subset-137 Section 6.3.2.1.2 [UNISIG-Subset137] request an + automatic certificate revocation by the CA in case of TCP + disconnection during certificate distribution, this conflicts with + this document. - o in case the request message is MAC protected, also the response, - certConf, and pkiConf messages have a MAC-based protection (Note: - if changing to signature protection of the response the caPubs - field cannot be used securely anymore.). + o As of RFC 4210 [RFC4210] the messageTime is required to be + Greenwich Mean Time coded as generalizedTime As UNISIG Subset-137 + Table 5 [UNISIG-Subset137] explicitly states that the messageTime + in required to be 'UTC time', it is not clear if this means a + coding as UTCTime or generalizedTime and if other time zones than + Greenwich Mean Time shall be allowed. Therefore, UNISIG + Subset-137 [UNISIG-Subset137] conflicts with RFC 4210 [RFC4210]. + Both time formats are described in RFC 5280 Section 4.1.2.5 + [RFC5280]. + + o This profile requires usage of the same type of protection for all + messages of one PKI management operation. This means, in case the + request message is MAC protected, also the response, certConf, and + pkiConf messages have a MAC-based protection. As UNISIG + Subset-137 Table 5 [UNISIG-Subset137] specifies for the first + certificate request MAC protection for all messages send by the + client and signature protection for all messages send by the + server, this conflicts with this document. + + o The usage of caPubs is mainly allowed in combination with MAC + protected PKI management operations. UNISIG Subset-137 Table 12 + [UNISIG-Subset137] requires to use caPubs. When changing to + signature protection of the response using a certificate issued + under the root CA that is to be transported in the caPubs field, + this is not a secure delivery of this root CA certificate. 1.5. Scope of this document This document specifies requirements on generating PKI management messages on the sender side. It does not specify strictness of verification on the receiving side and how in detail to handle error cases. Especially on the EE side this profile aims at a lightweight protocol that can be implemented on more constrained devices. On the side of @@ -567,117 +584,162 @@ Section 4 and Section 5 and points out whether an implementation by compliant EE or PKI management entities is mandatory, recommended or optional. 2.3.1. Mandatory PKI management operations The mandatory PKI management operations in this document shall limit the overhead of certificate management for more constrained devices to the most crucial types of operations. - Section 4 - End Entity focused PKI management operations - - o Request a certificate from a new PKI with signature protection; - see Section 4.1.1. - - o Request to update an existing certificate with signature - protection; see Section 4.1.3. - - o Error reporting; see Section 4.3. - - Section 5 - LRA and RA focused PKI management operations - - o Forward messages without changes; see Section 5.1.1. + +--------------------------------------------------------+----------+ + | PKI management operations | Section | + +--------------------------------------------------------+----------+ + | Request a certificate from a new PKI with signature | Section | + | protection | 4.1.1 | + +--------------------------------------------------------+----------+ + | Request to update an existing certificate with | Section | + | signature protection | 4.1.3 | + +--------------------------------------------------------+----------+ + | Error reporting | Section | + | | 4.3 | + +--------------------------------------------------------+----------+ - o Forward messages with replaced protection and keeping the original - proof-of-possession; see Section 5.1.2.1. + Table 1: Mandatory End Entity focused PKI management operations - o Forward messages with replaced protection and raVerified as proof- - of-possession; see Section 5.1.2.2. + +--------------------------------------------------------+----------+ + | PKI management operations | Section | + +--------------------------------------------------------+----------+ + | Forward messages without changes | Section | + | | 5.1.1 | + +--------------------------------------------------------+----------+ + | Forward messages with replaced protection and keeping | Section | + | the original proof-of-possession | 5.1.2.1 | + +--------------------------------------------------------+----------+ + | Forward messages with replaced protection and | Section | + | raVerified as proof-of-possession | 5.1.2.2 | + +--------------------------------------------------------+----------+ + | Error reporting | Section | + | | 5.3 | + +--------------------------------------------------------+----------+ - o Error reporting; see Section 5.3. + Table 2: Mandatory LRA and RA focused PKI management operations 2.3.2. Recommended PKI management operations Additional recommended PKI management operations shall support some more complex scenarios, that are considered as beneficial for environments with more specific boundary conditions. - Section 4 - End Entity focused PKI management operations - - o Request a certificate from a PKI with MAC protection; see - Section 4.1.4. + +--------------------------------------------------------+----------+ + | PKI management operations | Section | + +--------------------------------------------------------+----------+ + | Request a certificate from a PKI with MAC protection | Section | + | | 4.1.4 | + +--------------------------------------------------------+----------+ + | Revoke an own certificate | Section | + | | 4.2 | + +--------------------------------------------------------+----------+ - o Revoke an own certificate. + Table 3: Recommended End Entity focused PKI management operations - Section 5 - LRA and RA focused PKI management operations + +--------------------------------------------------------+----------+ + | PKI management operations | Section | + +--------------------------------------------------------+----------+ + | Revoke another's entities certificate | Section | + | | 5.2 | + +--------------------------------------------------------+----------+ - o Revoke another's entities certificate. + Table 4: Recommended LRA and RA focused PKI management operations 2.3.3. Optional PKI management operations The optional PKI management operations support specific requirements seen only in a subset of environments. - Section 4 - End Entity focused PKI management operations - - o Request a certificate from a trusted PKI with signature - protection; see Section 4.1.2. - - o Request a certificate from a legacy PKI using a PKCS#10 [RFC2986] - request; see Section 4.1.5. - - o Add central generation of a key pair to a certificate request; see - Section 4.1.6. If central key generation is supported, the key - agreement key management technique is REQUIRED to be supported, - and the key transport and symmetric key-encryption key management - techniques are OPTIONAL. - - o Handle delayed enrollment due to asynchronous message delivery; - see Section 4.1.7. - - o Additional support messages, e.g., to update a root CA certificate - or to request an RFC 8366 [RFC8366] voucher; see Section 4.4. + +---------------------------------------------------------+---------+ + | PKI management operations | Section | + +---------------------------------------------------------+---------+ + | Request a certificate from a trusted PKI with signature | Section | + | protection | 4.1.2 | + +---------------------------------------------------------+---------+ + | Request a certificate from a legacy PKI using a PKCS#10 | Section | + | [RFC2986] request | 4.1.5 | + +---------------------------------------------------------+---------+ + | Add central generation of a key pair to a certificate | Section | + | request. (If central key generation is supported, the | 4.1.6 | + | key agreement key management technique is REQUIRED to | | + | be supported, and the key transport and password-based | | + | key management techniques are OPTIONAL.) | | + +---------------------------------------------------------+---------+ + | Handle delayed enrollment due to asynchronous message | Section | + | delivery | 4.1.7 | + +---------------------------------------------------------+---------+ + | Additional support messages - distribution of CA | Section | + | certificates, update of a root CA certificate and | 4.4 | + | provisioning of certificate request template | | + +---------------------------------------------------------+---------+ - Section 5 - LRA and RA focused PKI management operations + Table 5: Optional End Entity focused PKI management operations - o Forward messages with additional protection; see Section 5.1.3 + +--------------------------------------------------------+----------+ + | PKI management operations | Section | + +--------------------------------------------------------+----------+ + | Forward messages with additional protection | Section | + | | 5.1.3 | + +--------------------------------------------------------+----------+ + | Initiate delayed enrollment due to asynchronous | Section | + | message delivery | 5.1.4 | + +--------------------------------------------------------+----------+ - o Initiate delayed enrollment due to asynchronous message delivery; - see Section 5.1.4. + Table 6: Optional LRA and RA focused PKI management operations 2.4. CMP message transport On different links between PKI entities, e.g., EE<->RA and RA<->CA, different transport MAY be used. As CMP has only very limited requirement regarding the mechanisms used for message transport and in different environments different transport mechanisms are - supported, e.g. HTTP, CoAP, or even offline files based, this + supported, e.g., HTTP, CoAP, or even offline files based, this document requires no specific transport protocol to be supported by all conforming implementations. HTTP transfer is RECOMMENDED to use for all PKI entities, but there is no transport specified as mandatory to be flexible for devices with special constraints to choose whatever transport is suitable. - Recommended transport - o Transfer CMP messages using HTTP; see Section 6.2. - - Optional transport + +--------------------------------------------------------+----------+ + | Transport | Section | + +--------------------------------------------------------+----------+ + | Transfer CMP messages using HTTP | Section | + | | 6.1 | + +--------------------------------------------------------+----------+ - o Transfer CMP messages using HTTPS with certificate-based - authentication; see Section 6.3. + Table 7: Recommended transport operations - o Transfer CMP messages using HTTPS with shared-secret based - protection; see Section 6.4. + +--------------------------------------------------------+----------+ + | Transport | Section | + +--------------------------------------------------------+----------+ + | Transfer CMP messages using HTTPS with certificate- | Section | + | based authentication | 6.2 | + +--------------------------------------------------------+----------+ + | Transfer CMP messages using HTTPS with shared-secret | Section | + | based protection | 6.3 | + +--------------------------------------------------------+----------+ + | Offline CMP message transport | Section | + | | 6.4 | + +--------------------------------------------------------+----------+ + | Transfer CMP messages using CoAP | Section | + | | 6.5 | + +--------------------------------------------------------+----------+ - o File-based CMP message transport. + Table 8: Optional transport operations 3. Generic parts of the PKI message To reduce redundancy in the text and to ease implementation, the contents of the header, protection, and extraCerts fields of the CMP messages used in the transactions specified in Section 4 and Section 5 are standardized to the maximum extent possible. Therefore, the generic parts of a CMP message are described centrally in this section. @@ -727,26 +789,28 @@ sender, protectionAlg, and senderKID. For requirements about proper random number generation please refer to [RFC4086]. Any message-specific fields or variations are described in the respective sections of this chapter. header pvno REQUIRED -- MUST be set to 2 to indicate CMP V2 sender REQUIRED - -- MUST be the subject of the protection certificate used for, + -- MUST contain a name representing the originator of the message + -- SHOULD be the subject of the protection certificate, -- the certificate for the private key used to sign the message recipient REQUIRED -- SHOULD be the name of the intended recipient and - -- MAY be a NULL_DN if the sender does not know the DN of - -- the recipient + -- MAY be a NULL-DN, i.e., has a zero-length SEQUENCE OF + -- RelativeDistinguishedNames, if the sender does not know the + -- DN of the recipient -- If this is the first message of a transaction: SHOULD be the -- subject of the issuing CA certificate -- In all other messages: SHOULD be the same name as in the -- sender field of the previous message in this transaction messageTime RECOMMENDED -- MUST be the time at which the message was produced, if -- present protectionAlg REQUIRED -- MUST be the algorithm identifier of the signature algorithm or -- id-PasswordBasedMac algorithm used for calculation of the @@ -763,41 +827,46 @@ -- protection certificate transactionID REQUIRED -- If this is the first message of a transaction: -- MUST be 128 bits of random data for the start of a -- transaction to reduce the probability of having the -- transactionID already in use at the server -- In all other messages: -- MUST be the value from the previous message in the same -- transaction senderNonce REQUIRED - -- MUST be fresh 128 random bits + -- MUST be cryptographically secure and fresh 128 random bits recipNonce RECOMMENDED -- If this is the first message of a transaction: SHOULD be -- absent -- In all other messages: MUST be present and contain the value -- from senderNonce of the previous message in the same -- transaction generalInfo OPTIONAL implicitConfirm OPTIONAL -- The field is optional though it only applies to -- ir/cr/kur/p10cr requests and ip/cp/kup response messages -- Add to request messages to request omit sending certConf -- message + -- See [RFC4210] Section 5.1.1.1. -- Add to response messages to confirm omit sending certConf -- message ImplicitConfirmValue REQUIRED -- ImplicitConfirmValue of the request message MUST be NULL if -- the EE wants to request not to send a confirmation message -- ImplicitConfirmValue MUST be set to NULL if the (L)RA/CA -- wants to grant not sending a confirmation message + < TBD: As discussed at IETF 108, the normative naming of specific + algorithms, e.g., like SHA-256 in the protectionAlg field should be + moved to a CMP Algorithms Draft. > + 3.2. General description of the CMP message protection This section describes the generic protection field of all CMP messages with signature-based protection. The certificate for the private key used to sign a CMP message is called 'protection certificate'. protection RECOMMENDED -- MUST contain the signature calculated using the signature -- algorithm specified in protectionAlg @@ -870,24 +938,24 @@ and utilize the specification of the message header, protection and extraCerts as specified in Section 4. The behavior in case an error occurs is described in Section 4.3. This chapter is aligned to Appendix D and Appendix E of [RFC4210]. The general rules for interpretation stated in Appendix D.1 in [RFC4210] need to be applied here, too. This document does not mandate any specific supported algorithms like - Appendix D.2 of [RFC4210], [ETSI-3GPP], and [UNISIG] do. Using the - message sequences described here require agreement upon the - algorithms to support and thus the algorithm identifiers for the - specific target environment. + Appendix D.2 of [RFC4210], [ETSI-TS133310], and [UNISIG-Subset137] + do. Using the message sequences described here require agreement + upon the algorithms to support and thus the algorithm identifiers for + the specific target environment. 4.1. Requesting a new certificate from a PKI There are different approaches to request a certificate from a PKI. These approaches differ on the one hand in the way the EE can authenticate itself to the PKI it wishes to get a new certificate from and on the other hand in its capabilities to generate a proper new key pair. The authentication means may be as follows: @@ -937,39 +1005,40 @@ root CA certificate is performed using the caPubs field, the certificate response message MUST be properly authenticated, and the sender of this message MUST be authorized to install new root CA certificates on the EE. This authorization can be indicated by using pre-shared keys for the CMP message protection. 4.1.1. Request a certificate from a new PKI with signature protection This PKI management operation should be used by an EE to request a certificate of a new PKI using an existing certificate from an - external PKI, e.g., a manufacturer certificate, to prove its identity - to the new PKI. The EE already has established trust in this new PKI - it is about to enroll to, e.g., by voucher exchange or configuration - means. The initialization request message is signature-protected - using the existing certificate. + external PKI, e.g., a manufacturer issued IDevID certificate + [IEEE802.1AR], to prove its identity to the new PKI. The EE already + has established trust in this new PKI it is about to enroll to, e.g., + by voucher exchange or configuration means. The certificate request + message is signature-protected using the existing certificate from + the external PKI. Preconditions: 1 The EE MUST have a certificate enrolled by an external PKI in advance to this PKI management operation to authenticate itself to the PKI management entity using signature-based protection, e.g., using a manufacturer issued certificate. 2 The EE SHOULD know the subject name of the new CA it requests a certificate from; this name MAY be established using an enrollment - voucher, the issuer field from a the CertReqTemplate response - message, or other configuration means. If the EE does not know - the name of the CA, the PKI management entity MUST know where to - route this request to. + voucher, the issuer field from a CertReqTemplate response message, + or other configuration means. If the EE does not know the name of + the CA, the PKI management entity MUST know where to route this + request to. 3 The EE MUST authenticate responses from the PKI management entity; trust MAY be established using an enrollment voucher or other configuration means. 4 The PKI management entity MUST trust the external PKI the EE uses to authenticate itself; trust MAY be established using some configuration means. This PKI management operation is like that given in [RFC4210] @@ -1042,38 +1111,42 @@ -- MUST be exactly one CertReqMsg -- If more certificates are required, further requests MUST be -- packaged in separate PKI Messages certReq REQUIRED certReqId REQUIRED -- MUST be set to 0 certTemplate REQUIRED version OPTIONAL -- MUST be 2 if supplied. subject REQUIRED - -- MUST contain the suggested subject name of the EE - -- certificate + -- The EE subject name MUST be carried in the subject field + -- and/or the subjectAltName extension. + -- If subject name is present only in the subjectAltName + -- extension, then the subject field MUST be a NULL-DN publicKey REQUIRED algorithm REQUIRED + -- MUST include the subject public key algorithm ID and value -- In case a central key generation is requested, this field -- contains the algorithm and parameter preferences of the -- requesting entity regarding the to-be-generated key pair subjectPublicKey REQUIRED -- MUST contain the public key to be included into the requested -- certificate in case of local key-generation -- MUST contain a zero-length BIT STRING in case a central key -- generation is requested - -- MUST include the subject public key algorithm ID and value extensions OPTIONAL -- MAY include end-entity-specific X.509 extensions of the -- requested certificate like subject alternative name, -- key usage, and extended key usage + -- The subjectAltName extension MUST be present if the EE + -- subject name includes a subject alternative name. Popo REQUIRED POPOSigningKey OPTIONAL -- MUST be used in case subjectPublicKey contains a public key -- MUST be absent in case subjectPublicKey contains a -- zero-length BIT STRING poposkInput PROHIBITED -- MUST NOT be used because subject and publicKey are both -- present in the certTemplate algorithmIdentifier REQUIRED -- The signature algorithm MUST be consistent with the @@ -1232,24 +1304,24 @@ Preconditions: 1 The EE MUST have a certificate enrolled by the PKI it requests another certificate from in advance to this PKI management operation to authenticate itself to the PKI management entity using signature-based protection. 2 The EE SHOULD know the subject name of the CA it requests a certificate from; this name MAY be established using an enrollment - voucher, the issuer field from a the CertReqTemplate response - message, or other configuration means. If the EE does not know - the name of the CA, the PKI management entity MUST know where to - route this request to. + voucher, the issuer field from a CertReqTemplate response message, + or other configuration means. If the EE does not know the name of + the CA, the PKI management entity MUST know where to route this + request to. 3 The EE MUST authenticate responses from the PKI management entity; trust MUST be established using an enrollment voucher or other configuration means. 4 The PKI management entity MUST trust the current PKI; trust MAY be established using some configuration means. The message sequence for this PKI management operation is like that given in [RFC4210] Appendix D.5. @@ -1260,23 +1332,22 @@ 1 The body of the first request and response MUST be cr and cp, respectively. 2 The caPubs field in the cp message SHOULD be absent. 4.1.3. Update an existing certificate with signature protection This PKI management operation should be used by an EE to request an update of one of the certificates it already has and that is still valid. The EE uses the certificate it wishes to update to prove its - identity and possession of the private key for the certificate to be - updated to the PKI. Therefore, the key update request message is - signed using the certificate that is to be updated. + identity. The certificate request message is signature-protected + using this certificate. The general message flow for this PKI management operation is the same as given in Section 4.1.1. Preconditions: 1 The certificate the EE wishes to update MUST NOT be expired or revoked. 2 A new public-private key pair SHOULD be used. @@ -1286,30 +1357,29 @@ The message sequence for this PKI management operation is identical to that given in Section 4.1.1, with the following changes: 1 The body of the first request and response MUST be kur and kup, respectively. 2 Protection of the kur MUST be performed using the certificate to be updated. - 3 The subject field of the CertTemplate MUST contain the subject - name of the existing certificate to be updated, without - modifications. + 3 The subject field and/or the subjectAltName extension of the + CertTemplate MUST contain the EE subject name of the existing + certificate to be updated, without modifications. - 4 The CertTemplate MUST contain the subject, issuer and publicKey - fields only. + 4 The CertTemplate SHOULD contain the subject and publicKey of the + EE only. - 5 The oldCertId control SHOULD be used to make clear, even in case - an (L)RA changes the message protection, which certificate is to - be updated. + 5 The oldCertId control SHOULD be used to make clear which + certificate is to be updated. 6 The caPubs field in the kup message MUST be absent. As part of the certReq structure of the kur the control is added right after the certTemplate. controls type RECOMMENDED -- MUST be the value id-regCtrl-oldCertID, if present value @@ -1336,24 +1406,24 @@ same as given in Section 4.1.1. Preconditions: 1 The EE and the PKI management entity MUST share a symmetric key, this MAY be established by a service technician during initial local configuration. 2 The EE SHOULD know the subject name of the new CA it requests a certificate from; this name MAY be established using an enrollment - voucher, the issuer field from a the CertReqTemplate response - message, or other configuration means. If the EE does not know - the name of the CA, the PKI management entity MUST know where to - route this request to. + voucher, the issuer field from a CertReqTemplate response message, + or other configuration means. If the EE does not know the name of + the CA, the PKI management entity MUST know where to route this + request to. 3 The EE MUST authenticate responses from the PKI management entity; trust MAY be established using the shared symmetric key. The message sequence for this PKI management operation is like that given in [RFC4210] Appendix D.4. The message sequence for this PKI management operation is identical to that given in Section 4.1.1, with the following changes: @@ -1420,24 +1490,23 @@ the subjectPKInfo of the PKCS#10 certificate request. Preconditions: 1 The EE MUST either have a certificate enrolled from this or any other accepted PKI, or a shared secret known to the PKI and the EE to authenticate itself to the RA. 2 The EE SHOULD know the subject name of the CA it requests a certificate from; this name MAY be established using an enrollment - voucher, the issuer field from a the CertReqTemplate response - message, or other configuration means. If the EE does not know - the name of the CA, the RA MUST know where to route this request - to. + voucher, the issuer field from a CertReqTemplate response message, + or other configuration means. If the EE does not know the name of + the CA, the RA MUST know where to route this request to. 3 The EE MUST authenticate responses from the RA; trust MAY be established by an available root certificate, using an enrollment voucher, or other configuration means. 4 The RA MUST trust the current or the PKI the EE uses to authenticate itself; trust MAY be established by a corresponding available root certificate or using some configuration means. The message sequence for this PKI management operation is identical @@ -1485,107 +1554,116 @@ protection REQUIRED -- As described in section 3.2 extraCerts REQUIRED -- As described in section 3.3 4.1.6. Generate the key pair centrally at the PKI management entity This functional extension can be applied in combination with - certificate enrollment as described in Section 4.1.1 and - Section 4.1.4. The functional extension can be used in case an EE is - not able or is not willing to generate its new public-private key - pair itself. It is a matter of the local implementation which PKI - management entity will perform the key generation. This entity MUST - have a certificate containing the additional extended key usage - extension id-kp-cmcKGA to be identified by the EE as a legitimate - key-generation authority. In case the PKI management entity - generated the new key pair for the EE, it can use Section 4.1.1 to - Section 4.1.4 to request the certificate for this key pair as usual. + certificate enrollment as described in Section 4.1.1, Section 4.1.2, + and Section 4.1.4. The functional extension can be used in case an + EE is not able or is not willing to generate its new public-private + key pair itself. It is a matter of the local implementation which + PKI management entity will act as Key Generation Authority (KGA) and + perform the key generation. This PKI management entity MUST have a + certificate containing the additional extended key usage extension + id-kp-cmKGA to be identified by the EE as a legitimate key-generation + authority. In case the KGA generated the new key pair on behalf of + the EE, it can use Section 4.1.1, Section 4.1.2, or Section 4.1.4 to + request the certificate for this key pair as usual. Generally speaking, in a machine-to-machine scenario it is strongly preferable to generate public-private key pairs locally at the EE. Together with proof-of-possession of the private key in the certification request, this is to make sure that only the entity identified in the newly issued certificate is the only entity who - ever hold the private key. + ever holt the private key. There are some cases where an EE is not able or not willing to locally generate the new key pair. Reasons for this may be the following: o Lack of sufficient initial entropy. Note: Good random numbers are not only needed for key generation, but also for session keys and nonces in any security protocol. - Therefore, we believe that a decent security architecture should - anyways support good random number generation on the EE side or - provide enough entropy for the RNG seed during manufacturing to - guarantee good initial pseudo-random number generation. + Therefore, a decent security architecture should anyways support good + random number generation on the EE side or provide enough entropy for + the RNG seed to guarantee good initial pseudo-random number + generation. May be this is not the case at the time of requesting a + certificate during manufacturing. o Due to lack of computational resources, e.g., in case of RSA keys. - Note: As key generation can be performed in advance to the - certificate enrollment communication, it is typical not time - critical. - - Note: Besides the initial enrollment right after the very first - bootup of the device, where entropy available on the device may be - insufficient, we do not see any good reason for central key - generation. + Note: As key generation could be performed in advance to the + certificate enrollment communication, it is often not time critical. Note: As mentioned in Section 2.1 central key generation may be required in a push model, where the certificate response message is transferred by the PKI management entity to the EE without receiving a previous request message. If the EE wishes to request central key generation, it MUST fill the subjectPublicKey field in the certTemplate structure of the request message with a zero-length BIT STRING. This indicates to the PKI management entity that a new key pair shall be generated centrally on behalf of the EE. Note: As the protection of centrally generated keys in the response message is being extended from EncryptedValue to EncryptedKey by CMP - Updates [I-D.ietf-lamps-cmp-updates] also the alternative + Updates [I-D.ietf-lamps-cmp-updates], also the alternative EnvelopedData can be used. In CRMF Section 2.1.9 [RFC4211] the use of EncryptedValue has been deprecated in favor of the EnvelopedData structure. Therefore, this profile specifies using EnvelopedData as - specified in CMS Section 6 [RFC5652] to offer more crypto agility. + specified in CMS Section 6 [RFC5652]. - +------------------------------+ + +----------------------------------+ | EnvelopedData | | [RFC5652] section 6 | - | +--------------------------+ | + | +------------------------------+ | | | SignedData | | | | [RFC5652] section 5 | | - | | +----------------------+ | | - | | | privateKey | | | - | | | OCTET STRING | | | - | | +----------------------+ | | - | +--------------------------+ | - +------------------------------+ + | | +--------------------------+ | | + | | | AsymmetricKeyPackage | | | + | | | [RFC5958] | | | + | | | +----------------------+ | | | + | | | | privateKey | | | | + | | | | OCTET STRING | | | | + | | | +----------------------+ | | | + | | +--------------------------+ | | + | +------------------------------+ | + +----------------------------------+ Figure 3: Encrypted private key container The PKI management entity delivers the private key in the privateKey field in the certifiedKeyPair structure of the response message also containing the newly issued certificate. - The private key MUST be wrapped in a SignedData structure, as - specified in CMS Section 5 [RFC5652], signed by the KGA generating - the key pair. The signature MUST be performed using a CMP signer - certificate asserting the extended key usage kp-id-cmpKGA as + The private key MUST be provided as an AsymmetricKeyPackage structure + as defined in RFC 5958 [RFC5958]. + + This AsymmetricKeyPackage structure MUST be wrapped in a SignedData + structure, as specified in CMS Section 5 [RFC5652], signed by the KGA + generating the key pair. The signature MUST be performed using a CMP + signer certificate asserting the extended key usage kp-id-cmKGA as described in CMP Updates [I-D.ietf-lamps-cmp-updates] to show the authorization to generate key pairs on behalf of an EE. + Note: In case of using password-based key management technique as + described in Section 4.1.6.3 it may not be possible or meaningful to + the EE to validate the KGA signature in the SignedData structure as + shares secrets are used for initial authentication. In this case the + EE MAY omit this signature validation. + This SignedData structure MUST be wrapped in an EnvelopedData structure, as specified in CMS Section 6 [RFC5652], encrypting it using a newly generated symmetric content-encryption key. Note: Instead of the specification in CMP Appendix D 4.4 [RFC4210] this content-encryption key is not generated on the EE side. As we just mentioned, central key generation should only be used in this profile in case of lack of randomness on the EE. As part of the EnvelopedData structure this content-encryption key @@ -1586,45 +1664,46 @@ Note: Instead of the specification in CMP Appendix D 4.4 [RFC4210] this content-encryption key is not generated on the EE side. As we just mentioned, central key generation should only be used in this profile in case of lack of randomness on the EE. As part of the EnvelopedData structure this content-encryption key MUST be securely provided to the EE using one of three key management techniques. The choice of the key management technique to be used by the PKI management entity depends on the authentication mechanism the EE choose to protect the request message, see CMP Updates section 3.4 - [I-D.ietf-lamps-cmp-updates] for more details on which key management technique to use. + o Signature protected request message: + + * Using a certificate that contains a key usage extension + asserting keyAgreement: The content-encryption key SHALL be + protected using the key agreement key management technique, see + Section 4.1.6.1, if the certificate used by the EE for signing + the respective request message contains the key usage + keyAgreement. If the certificate also contains the key usage + keyEncipherment, the key transport key management technique + SHALL NOT be used. + + * Using a certificate that contains a key usage extension + asserting keyEncipherment: The content-encryption key SHALL be + protected using the key transport key management technique, see + Section 4.1.6.2, if the certificate used by the EE for signing + the respective request message contains the key usage + keyEncipherment and not keyAgreement. + o MAC protected request message: The content-encryption key SHALL be protected using the password-based key management technique, see Section 4.1.6.3, only if the EE used MAC protection for the respected request message. - o Signature protected request message using a certificate that - contains a key usage extension asserting keyAgreement: The - content-encryption key SHALL be protected using the key agreement - key management technique, see Section 4.1.6.1, if the certificate - used by the EE for signing the respective request message contains - the key usage keyAgreement. If the certificate also contains the - key usage keyEncipherment, the key transport key management - technique SHALL NOT be used. - - o Signature protected request message using a certificate that - contains a key usage extension asserting keyEncipherment: The - content-encryption key SHALL be protected using the key transport - key management technique, see Section 4.1.6.2, if the certificate - used by the EE for signing the respective request message contains - the key usage keyEncipherment and not keyAgreement. - The key agreement key management technique can be supported by most signature algorithms, as key transport key management technique can only be supported by a very limited number of algorithms. The password-based key management technique shall only be used in combination with MAC protection, which is a side-line in this document. Therefore, if central key generation is supported, the support of the key agreement key management technique is REQUIRED and the support of key transport and password-based key management techniques are OPTIONAL. @@ -1673,23 +1752,43 @@ -- MUST be exactly one digestAlgorithm identifier digestAlgorithmIdentifier REQUIRED -- MUST be the OID of the digest algorithm used for generating -- the signature -- The hash algorithm used SHOULD be SHA-256 encapContentInfo REQUIRED -- MUST be the content that is to be signed contentType REQUIRED - -- MUST be id-data + + -- MUST be id-ct-KP-aKeyPackage as specified in [RFC5958] content REQUIRED - -- MUST be the privateKey as OCTET STRING + AsymmetricKeyPackage + REQUIRED + OneAsymmetricKey + REQUIRED + -- MUST be exactly one asymmetric key package + version REQUIRED + -- The version MUST be v2 + privateKeyAlgorithm + REQUIRED + -- The privateKeyAlgorithm field MUST contain + -- the OID of the asymmetric key pair algorithm + privateKey + REQUIRED + -- The privateKey MUST be in the privateKey field + Attributes + OPTIONAL + -- The attributes field SHOULD not be used + publicKey + REQUIRED + -- The publicKey MUST be in the publicKey field certificates REQUIRED -- SHOULD contain the certificate, for the private key used -- to sign the content, together with its chain -- If present, the first certificate in this field MUST -- be the certificate used for signing this content -- Self-signed certificates SHOULD NOT be included -- and MUST NOT be trusted based on the listing in any case crls OPTIONAL -- MAY be present to provide status information on the signer or -- its CA certificates @@ -1800,21 +1899,21 @@ This key management technique can be applied in combination with the PKI management operation specified in Section 4.1.4 using MAC protected CMP messages. The shared secret used for the MAC protection MUST also be used for the encryption of the content- encryption key but with a different salt. To use this key management technique the PasswordRecipientInfo structure MUST be used in the contentInfo field. The PasswordRecipientInfo structure included into the EnvelopedData - structure is specified in CMS Section 6.2.3 [RFC5652]. + structure is specified in CMS Section 6.2.4 [RFC5652]. The detailed description of the PasswordRecipientInfo structure looks like this: recipientInfo REQUIRED -- MUST be PasswordRecipientInfo as specified in -- CMS section 6.2.4 [RFC5652] version REQUIRED -- MUST be set to 0 keyDerivationAlgorithm @@ -1877,20 +1976,23 @@ special case of polling between EE and LRA with offline transport between an LRA and RA, see Section 5.1.4, an exception occurs. The EE and LRA exchange pollReq and pollRep messages handle the nonce words as described. When, after pollRep, the final response from the CA arrives at the LRA, the next response will contain the recipNonce set to the value of the senderNonce in the original request message (copied by the CA). The LRA needs to replace the recipNonce in this case with the senderNonce of the last pollReq because the EE will validate it in this way. + < TBD: I would appreciate any feedback specifically addressing the + nonce handling in case an offline LRA responding and not forwarding + the pollReq messages. > Message flow: Step# EE PKI management entity 1 format ir/cr/p10cr/kur As described in the respective section in this document 2 ->ir/cr/p10cr/kur-> 3 handle request as described in the respective section @@ -1988,21 +2090,21 @@ -- certConf message of the respective PKI management operation Polling Response -- pollRep Field Value header -- MUST contain a header as described for the pkiConf message -- of the respective PKI management operation - body pollRep + body -- The message indicated the time to after which the EE may -- send another pollReq messaged for this transaction pollRep REQUIRED -- MUST be exactly one set of the following values certReqId REQUIRED -- MUST be set to 0 checkAfter REQUIRED -- time in seconds to elapse before a new pollReq may be sent by -- the EE @@ -2308,28 +2410,32 @@ infoValue OPTIONAL -- MUST be as described in the specific PKI -- management operation described below protection REQUIRED -- As described in section 3.2 extraCerts REQUIRED -- As described in section 3.3 + < TBD: May be we should not restrict the number of ITAV elements in + the response message to one. > + 4.4.2. Get CA certificates This PKI management operation can be used by an EE to request CA certificates from the PKI management entity. An EE requests CA certificates from the PKI management entity by - sending a general message with OID id-it-caCerts. The PKI management - entity responds with a general response with the same OID that either + sending a general message with OID id-it-caCerts as specified in CMP + Updates [I-D.ietf-lamps-cmp-updates]. The PKI management entity + responds with a general response with the same OID that either contains a SEQUENCE of certificates populated with the available CA intermediate and issuing CA certificates or with no content in case no CA certificate is available. The message sequence for this PKI management operation is as given in Section 4.4.1, with the following specific content: 1 the body MUST contain as infoType the OID id-it-caCerts 2 the infoValue of the request MUST be absent @@ -2343,36 +2449,35 @@ -- MUST be present if CA certificates are available -- MUST be a sequence of CMPCertificate 4.4.3. Get root CA certificate update This PKI management operation can be used by an EE to request an update of an existing root CA Certificate by the EE. An EE requests a root CA certificate update from the PKI management entity by sending a general message with OID id-it-rootCaKeyUpdate as - infoType and no infoValue. The PKI management entity responds with a - general response with the same OID that either contains the update of - the root CA certificate consisting of up to three certificates, or - with no content in case no update is available. + specified in CMP Updates [I-D.ietf-lamps-cmp-updates]. The PKI + management entity responds with a general response with the same OID + that either contains the update of the root CA certificate consisting + of up to three certificates, or with no content in case no update is + available. - These three certificates are described in more detail in section - 4.4.1, section 6.2, and Appendix E.3 of [RFC4210]. The newWithNew - certificate is the new root CA certificates and is REQUIRED to be - present in the response message. The newWithOld certificate is - RECOMMENDED to be present in the response message though it is - REQUIRED for those cases where the receiving entity trusts the old - root CA certificate and wishes to gain trust in the new root CA - certificate. The oldWithNew certificate is OPTIONAL though it is - only needed in a scenario where the requesting entity already trusts - the new root CA certificate and wants to gain trust in the old root - certificate. + The newWithNew certificate is the new root CA certificates and is + REQUIRED to be present in the response message. The newWithOld + certificate is RECOMMENDED to be present in the response message + though it is REQUIRED for those cases where the receiving entity + trusts the old root CA certificate and wishes to gain trust in the + new root CA certificate. The oldWithNew certificate is OPTIONAL + though it is only needed in a scenario where the requesting entity + already trusts the new root CA certificate and wants to gain trust in + the old root certificate. The message sequence for this PKI management operation is as given in Section 4.4.1, with the following specific content: 1 the body MUST contain as infoType the OID id-it-rootCaKeyUpdate 2 the infoValue of the request MUST be absent 3 if present, the infoValue of the response MUST be a RootCaKeyUpdate structure @@ -2390,105 +2495,130 @@ -- MUST contain the new root CA certificate newWithOld RECOMMENDED -- SHOULD be present if infoValue is present -- MUST contain an X.509 certificate containing the new public -- root CA key signed with the old private root CA key oldWithNew OPTIONAL -- MAY be present if infoValue is present -- MUST contain an X.509 certificate containing the old public -- root CA key signed with the new private root CA key + < TBD: In case the PKI management entity serves for different Root + CAs. There are three different options to handle this: - The EE + specifies by means of an respective lable in the http endpoint for + which Root CA certificate the update is requested. - The EE transfers + the oldWithOld certificate in the InfoValue of the request. - The PKI + management entity provides RootCaKeyUpdate element all Root CAs an + update is available. > + 4.4.4. Get certificate request template This PKI management operation can be used by an EE to request a template with parameters for a future certificate request operation. - An EE requests certificate request parameters from the PKI management - entity by sending a general message with OID id-it-certReqTemplate. - The PKI management entity responds with a general response with the - same OID that either contains a certificate template with the - required fields and optionally a rsaKeyLen field containing - requirements on, e.g., algorithm identifier for key pair generation - or certificate fields and extensions, or with no content in case no + An EE requests certificate request parameter from the PKI management + entity by sending a general message with OID id-it-certReqTemplate as + specified in CMP Updates [I-D.ietf-lamps-cmp-updates]. The PKI + management entity responds with a general response with the same OID + that either contains a certificate template containing requirements + on certificate fields and extensions and optionally a sequence of + control fields containing requirements on algorithm identifier or RSA + key lengths for key pair generation, or with no content in case no specific requirements are made by the PKI. The EE SHOULD follow the requirements from the received CertTemplate - and the optional rsaKeyLen fields, by filling in all the fields + and the optional control fields, by filling in all the fields requested and taking over all the field values provided. The EE SHOULD NOT add further CertTemplate fields, Name components, and extensions or their (sub-)components. Note: We deliberately do not use 'MUST' or 'MUST NOT' here in order to allow more flexibility in case the rules given here are not sufficient for specific scenarios. The EE can populate the certificate request as wanted and ignore any of the requirements contained in the CertReqTemplate response message. On the other hand, a PKI management entity is free to ignore or replace the content of the certificate request provided by the EE. The CertReqTemplate PKI management operation offers means to ease a joint understanding which fields should be used. - In case a field of type Name, e.g., issuer or subject name, is - present but has the value NULL-DN (i.e., has an empty list of RDN - components) the field SHOULD be included with content provided by the - EE. Similarly, in case an X.509v3 extension is present but its - extnValue is empty this means that the extension SHOULD be included - with content provided by the EE. In case a Name component, for - instance a common name or serial number, is given but has an empty - string value the EE SHOULD fill in a value. Similarly, in case an - extension has sub-components (e.g., an IP address in a SubjectAltName - field) with empty value, the EE SHOULD fill in a value. + In case a field of type Name, e.g., issuer or subject, is present in + the CertTemplate but has the value NULL-DN (i.e., has an empty list + of RDN components) the field SHOULD be included with content provided + by the EE. Similarly, in case an X.509v3 extension is present but + its extnValue is empty this means that the extension SHOULD be + included with content provided by the EE. In case a Name component, + for instance a common name or serial number, is given but has an + empty string value the EE SHOULD fill in a value. Similarly, in case + an extension has sub-components (e.g., an IP address in a + SubjectAltName field) with empty value, the EE SHOULD fill in a + value. The EE MUST ignore (i.e., not include and fill in) empty fields, extensions, and sub-components that it does not know. - If the publicKey field of type SubjectPublicKeyInfo is present its - algorithm field specifies the type of the public key to request a - certificate for. The algorithm field contains the key type OID of - the public key. For EC keys the full curve information MUST be - specified as described in the respective standard documents. For RSA - keys the key length MUST be specified in the rsaKeyLen field of the - outer infoValue field. The algorithm field MUST be followed by a - zero-length BIT STRING for the subjectPublicKey. If the publicKey - field is not present the EE is free to choose the public key type and - parameters. + The publicKey field of type SubjectPublicKeyInfo in the CertTemplate + MUST no algorithm ID in the algorithm field and a zero-length BIT + STRING in the subjectPublicKey field. In case the PKI management + entity whishes to make stipulation on supported algorithms the EE may + use for key generation, this MUST be specified using the control + fields. + + The control with the OID id-regCtrl-algId, as specified in CMP + Updates [I-D.ietf-lamps-cmp-updates], specifies algorithms other that + RSA. The algorithm field in SubjectPublicKeyInfo specifies the type + of the public key to request a certificate for. The algorithm field + contains the key type OID of the public key. For EC keys the full + curve information MUST be specified as described in the respective + standard documents. The algorithm field MUST be followed by a zero- + length BIT STRING for the subjectPublicKey. + + The control with the OID id-regCtrl-rsaKeyLen, as specified in CMP + Updates [I-D.ietf-lamps-cmp-updates], specifies RSA keys of the + specified key length. In case several control fields are present the + EE is free to choose one of the specified algorithms for key pair + generation. In case no control field is not present the EE is free + to choose the public key type and parameters. In the certTemplate structure the serialNumber, signingAlg, issuerUID, and subjectUID fields MUST be omitted. The message sequence for this PKI management operation is as given in Section 4.4.1, with the following specific content: 1 the body MUST contain as infoType the OID id-it-certReqTemplate 2 the infoValue of the request MUST be absent - 3 if present, the infoValue of the response MUST be a SEQUENCE of a - certTemplate structure and an rsaKeyLen field of type INTEGER + 3 if present, the infoValue of the response MUST be a certTemplate + structure and an optional SEQUENCE of AttributeTypeAndValue of + type id-regCtrl-algId or id-regCtrl-rsaKeyLen The infoValue field of the general response containing the id-it- certReqTemplate OID looks like this: InfoValue OPTIONAL -- MUST be absent if no requirements are available -- MUST be present if the PKI management entity has any -- requirements on the content of the certificates template - -- is available and MUST be of type CertReqTemplateValue certTemplate REQUIRED -- MUST be present if infoValue is present -- MUST contain the prefilled certTemplate structure elements - rsaKeyLen OPTIONAL - -- This field is of type INTEGER. Any reasonable RSA key length - -- MUST be specified if the algorithm in the - -- subjectPublicKeyInfo field of the certTemplate has the OID - -- rsaEncryption. - -- MUST be omitted in otherwise. + -- The SubjectPublicKeyInfo MUST contain no algorithm ID in the + -- algorithm field and a zero-length BIT STRING in the + -- subjectPublicKey field + controls OPTIONAL + -- MUST be absent if no requirements on algorithms are available + -- MUST be present if the PKI management entity has any + -- requirements on the algorithms to be used for key generation + -- MUST contain one AttributeTypeAndValue per supported algorithm + -- MAY be of type id-regCtrl-algId or id-regCtrl-rsaKeyLen 5. LRA and RA focused PKI management operations This chapter focuses on the communication among different PKI management entities. Depending on the network and PKI solution design, these will either be an LRA, RA or CA. Typically, a PKI management entity forwards messages from downstream, but it may also reply to them itself. Besides forwarding of received messages a PKI management entity could also need to revoke @@ -2605,42 +2734,54 @@ The following two alternatives to forward a message can be used by any PKI management entity to forward a CMP message with or without changes, but providing its own protection using its CMP signer key to assert approval of this message. In this case the PKI management entity acts as an actual Registration Authority (RA), which implements important security functionality of the PKI. Before replacing the existing protection by a new protection, the PKI management entity MUST verify the protection provided by the EE or by - the previous PKI component and approve its content including any own - modifications. For certificate requests the PKI management entity - MUST verify in particular the included proof-of-possession self- - signature of the certTemplate using the public key of the requested - certificate and MUST check that the EE, as authenticated by the - message protection, is authorized to request a certificate with the - subject as specified in the certTemplate. + the previous PKI management entity and approve its content including + any own modifications. For certificate requests the PKI management + entity MUST verify in particular the included proof-of-possession + self-signature of the certTemplate using the public key of the + requested certificate and MUST check that the EE, as authenticated by + the message protection, is authorized to request a certificate with + the subject as specified in the certTemplate. In case the received message has been protected by a CA or another PKI management entity, the current PKI management entity MUST verify its protection and approve its content including any own modifications. For certificate requests the PKI management entity MUST check that the other PKI management entity, as authenticated by the protection of the incoming message, was authorized to issue or forward the request. These message adaptations MUST NOT be applied to kur request messages as described in Section 4.1.3 since their original protection using the key and certificate to be updated needs to be preserved, unless the regCtrl OldCertId is used to clearly identify the certificate to be updated. + These message adaptations MUST NOT be applied to certificate request + messages as described in Section 4.1.6requesting key generation by a + Key Generation Authority since their original protection using the + key and certificate for signature protection or the shared secret for + MAC-protection needs to be preserved up to the Key Generation + Authority. + + In both cases, kur and central key generation, an additional + signature of a PKI management entity to the original certificate + request message MUST be provided using nested messages as specified + in Section 5.1.3. + 5.1.2.1. Keeping proof-of-possession This alternative to forward a message can be used by any PKI management entity to forward a CMP message with or without modifying the message header or body while preserving any included proof-of- possession. By replacing the existing protection using its own CMP signer key the PKI management entity provides a proof of verifying and approving of the message as described above. @@ -2672,29 +2813,32 @@ popo raVerified REQUIRED -- MUST have the value NULL and indicates that the PKI -- management entity verified the popo of the original -- message 5.1.3. Adding Protection This PKI management operation can be used by a PKI management entity to add another protection to one or several PKI management messages. + Applying an additional protection is specifically important when + forwarding certificate request messages requesting a key update or a + central key generation to preserve the original protection of the EE. The nested message is a PKI management message containing a PKIMessages sequence as its body containing one or more CMP messages. As specified in the updated Section 5.1.3.4 of RFC4210 [RFC4210] (see - Section 3.3 of CMP Updates [I-D.ietf-lamps-cmp-updates]) there are - different use case for adding another protection by a PKI management - entity. Specific procedures are described in more detail in the - following sections. + CMP Updates [I-D.ietf-lamps-cmp-updates]) there are different use + case for adding another protection by a PKI management entity. + Specific procedures are described in more detail in the following + sections. The behavior in case an error occurs is described in Section 4.3. Message flow: Step# PKI management entity PKI management entity 1 format nested 2 -> nested -> 3 handle, re-protect or forward nested @@ -2704,21 +2848,21 @@ Detailed message description: Nested Message - nested Field Value header -- As described in section 3.1 - body nested + body -- Container to provide additional protection to original -- messages and to bundle request or response messages PKIMessages REQUIRED -- MUST be a sequence of one or more CMP messages protection REQUIRED -- As described in section 3.2 using the CMP signer key of -- the PKI management entity extraCerts REQUIRED @@ -2860,42 +3004,26 @@ SHOULD use a configurable per-response timeout in case a further message is to be expected from the client side. In this way a hanging transaction can be closed cleanly with an error and related resources (for instance, any cached extraCerts) can be freed. When conveying a CMP messages in HTTP or MIME-based transport protocols the internet media type "application/pkixcmp" MUST be set for transport encoding as specified in RFC2510 in Section 5.3 [RFC2510] and RFC6712 in Section 3.4 [RFC7712]. -6.1. Definition and discovery of HTTP URIs - - Each PKI management entity supporting HTTP or HTTPS transport MUST - support the use of the path-prefix of '/.well-known/' as defined in - [RFC5785] and the registered name of 'cmp' to ease interworking in a - multi-vendor environment. - - The CMP client MUST be configured with sufficient information to form - the CMP server URI. This MUST be at least the authority portion of - the URI, e.g., 'www.example.com:80', or the full operational path of - the PKI management entity. An additional arbitrary label, e.g., - 'arbitraryLabel', MAY be configured as a separate component or as - part of the full operational path to provide further information to - address multiple CAs or certificate profiles. A valid full - operational path can look like this: - - 1 http://www.example.com/.well-known/cmp - - 2 http://www.example.com/.well-known/cmp/keyupdate +6.1. HTTP transport - 3 http://www.example.com/.well-known/cmp/arbitraryLabel - 4 http://www.example.com/.well-known/cmp/arbitraryLabel/keyupdate + This transport mechanism can be used by a PKI entity to transfer CMP + messages over HTTP. If HTTP transport is used the specifications as + described in [RFC6712] and updated by CMP Updates + [I-D.ietf-lamps-cmp-updates] MUST be followed. PKI management operations SHOULD use the following URI path: +----------------------------------+---------------------+----------+ | PKI management operation | Path | Details | +----------------------------------+---------------------+----------+ | Enroll client to new PKI | /initialization | Section | | (REQUIRED) | | 4.1.1 | +----------------------------------+---------------------+----------+ | Enroll client to existing PKI | /certification | Section | @@ -2919,56 +3047,29 @@ | Get root CA certificate update | /getrootupdate | Section | | (OPTIONAL) | | 4.4.3 | +----------------------------------+---------------------+----------+ | Get certificate request template | /getcertreqtemplate | Section | | (OPTIONAL) | | 4.4.4 | +----------------------------------+---------------------+----------+ | Additional protection (OPTIONAL) | /nested | Section | | | | 5.1.3 | +----------------------------------+---------------------+----------+ - Table 1: HTTP endpoints + Table 9: HTTP endpoints Subsequent certConf, error, and pollReq messages are sent to the URI of the respective PKI management operation. - The discovery of supported endpoints as defined above will provide - the information to the EE, how to contact the PKI management entity - and, if available, how to request enrolment for a specific - certificate profile or revoke a certificate at a specific CA. - - Querying the PKI management entity, the EE will get a list of - potential endpoints supported by the PKI management entity. - - Performing a GET on "/.well-known/cmp" to the default port returns a - set of links to endpoints available from the server or RA. In - addition to the link also the expected format of the data object is - provided as content type (ct). - - The following provides an illustrative example for a PKI management - entity supporting different PKI management operations for a single - certificate profile or a single CA. - - Detailed message description: - - REQ: GET /.well-known/cmp - - RES: Content - ;ct=pkixcmp - ;ct=pkixcmp - ;ct=pkixcmp - ;ct=pkixcmp - ;ct=pkixcmp - ;ct=pkixcmp - ;ct=pkixcmp - ;ct=pkixcmp - ;ct=pkixcmp + The discovery mechanism as described in CMP Updates + [I-D.ietf-lamps-cmp-updates] SHOULD be used to query information on + the supported PKI management operations, certificate profiles and + CAs. As it is very likely, that a CA supports different certification profiles or that the RA offers PKI management operations for different issuing CAs, the discovery can also be used to provide the information about these options. The second example listing contains the supported PKI management operations for three different certificate profiles. The supported CA hierarchy consists of one root CA and two issuing CAs. Detailed message description: @@ -2994,30 +3095,24 @@ ;ct=pkixcmp ;ct=pkixcmp ;ct=pkixcmp ;ct=pkixcmp There are different options in the handling of the naming. The PKI management entity either needs to offer the certprofile or CA labels the EE expects. Alternatively, a mechanism is required to configure this information to the EE beforehand. -6.2. HTTP transport - - This transport mechanism can be used by a PKI entity to transfer CMP - messages over HTTP. If HTTP transport is used the specifications as - described in [RFC6712] MUST be followed. - -6.3. HTTPS transport using certificates +6.2. HTTPS transport using certificates This transport mechanism can be used by a PKI entity to further - protect the HTTP transport as described in Section 6.2 using TLS 1.2 + protect the HTTP transport as described in Section 6.1 using TLS 1.2 [RFC5246] or TLS 1.3 [RFC8446] as described in [RFC2818] with certificate-based authentication. Using this transport mechanism, the CMP transport via HTTPS MUST use TLS server authentication and SHOULD use TLS client authentication. EE: o The EE SHOULD use a TLS client certificate as far as available. If no dedicated TLS certificate is available, the EE SHOULD use an already existing certificate identifying the EE (e.g., a @@ -3038,109 +3133,107 @@ its downstream (server) interface. o Each PKI management entity MUST validate the TLS certificate of its communication partners. NOTE: The requirements for checking certificates given in [RFC5280], [RFC5246] and [RFC8446] MUST be followed for the TLS layer. Certificate status checking SHOULD be used for the TLS certificates of communication partners. -6.4. HTTPS transport using shared secrets +6.3. HTTPS transport using shared secrets This transport mechanism can be used by a PKI entity to further - protect the HTTP transport as described in Section 6.2 using TLS 1.2 + protect the HTTP transport as described in Section 6.1 using TLS 1.2 [RFC5246] or TLS 1.3 [RFC8446] as described in [RFC2818] with mutual authentication based on shared secrets as described in [RFC5054]. EE: o The EE MUST use the shared symmetric key for authentication. PKI management entity: o The PKI management entity MUST use the shared symmetric key for authentication. -6.5. Offline transport + < TBD: It needs to be clarified which cipher suite shall be + recommended as there seems to be no support for TLS-SRP un JavaSE. > + +6.4. Offline transport For transporting CMP messages between PKI entities any mechanism can be used that is able to store and forward binary objects of sufficient length and with sufficient reliability while preserving the order of messages. The transport mechanism SHOULD be able to indicate message loss, excessive delay, and possibly other transmission errors. In such cases the PKI entities using this mechanism SHOULD report an error as specified in Section 4.3. -6.5.1. File-based transport +6.4.1. File-based transport CMP messages MAY be transferred between PKI entities using file- system-based mechanisms, for instance when an off-line end entity or a PKI management entity performs delayed enrollment. Each file MUST contain the ASN.1 DER encoding of one CMP message only. There MUST be no extraneous header or trailer information in the file. The file type extensions ".PKI" SHOULD be used. -6.5.2. Other asynchronous transport protocols +6.4.2. Other asynchronous transport protocols Other asynchronous transport protocols, e.g., email or website up-/download, MAY transfer CMP messages between PKI entities. A MIME wrapping is defined for those environments that are MIME native. The MIME wrapping in this section is specified in [RFC8551], section 3.1. The ASN.1 DER encoding of the CMP messages MUST be transferred using the "application/pkixcmp" content type and base64-encoded content- transfer-encoding as specified in [RFC2510], section 5.3. A filename MUST be included either in a content-type or a content-disposition statement. The extension for the file MUST be ".PKI". -6.6. CoAP transport +6.5. CoAP transport In constrained environments where no HTTP transport is desired or possible, CoAP [RFC7252] as specified in [I-D.msahni-tbd-cmpv2-coap-transport] MAY be used instead. -6.7. Piggybacking on other reliable transport +6.6. Piggybacking on other reliable transport For online transfer where no HTTP transport is desired or possible CMP messages MAY also be transported on some other reliable protocol. Connection and error handling mechanisms like those specified for HTTP in [RFC6712] need to be implemented. Such specification is out of scope of this document and would need to be specifies in a separate document, e.g., in the scope of the respective transport protocol used. 7. IANA Considerations - < TBD: The OID id-it-caCerts, id-it-rootCaKeyUpdate, and id-it- - certReqTemplate are not yet defined and should be registered in the - tree 1.3.6.1.5.5.7.4 (id-it) like other infoType OIDs, see CMP - Appendix F [RFC4210] on page 92. > - 8. Security Considerations < TBD: Add any security considerations > 9. Acknowledgements We would like to thank the various reviewers of this document. 10. References 10.1. Normative References [I-D.ietf-lamps-cmp-updates] Brockhaus, H., "CMP Updates", draft-ietf-lamps-cmp- - updates-02 (work in progress), July 2020. + updates-05 (work in progress), September 2020. [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, DOI 10.17487/RFC2119, March 1997, . [RFC2986] Nystrom, M. and B. Kaliski, "PKCS #10: Certification Request Syntax Specification Version 1.7", RFC 2986, DOI 10.17487/RFC2986, November 2000, . @@ -3164,38 +3257,37 @@ [RFC5280] Cooper, D., Santesson, S., Farrell, S., Boeyen, S., Housley, R., and W. Polk, "Internet X.509 Public Key Infrastructure Certificate and Certificate Revocation List (CRL) Profile", RFC 5280, DOI 10.17487/RFC5280, May 2008, . [RFC5652] Housley, R., "Cryptographic Message Syntax (CMS)", STD 70, RFC 5652, DOI 10.17487/RFC5652, September 2009, . - [RFC5785] Nottingham, M. and E. Hammer-Lahav, "Defining Well-Known - Uniform Resource Identifiers (URIs)", RFC 5785, - DOI 10.17487/RFC5785, April 2010, - . + [RFC5958] Turner, S., "Asymmetric Key Packages", RFC 5958, + DOI 10.17487/RFC5958, August 2010, + . [RFC6712] Kause, T. and M. Peylo, "Internet X.509 Public Key Infrastructure -- HTTP Transfer for the Certificate Management Protocol (CMP)", RFC 6712, DOI 10.17487/RFC6712, September 2012, . 10.2. Informative References - [ETSI-3GPP] - 3GPP, "TS33.310; Network Domain Security (NDS); - Authentication Framework (AF); Release 16; V16.1.0", - December 2018, - . + [ETSI-TS133310] + ETSI, "TS 133 310; Network Domain Security (NDS); + Authentication Framework (AF); Release 16; V16.4.0", + August 2020, . [I-D.msahni-tbd-cmpv2-coap-transport] Sahni, M., "CoAP Transport for CMPV2", draft-msahni-tbd- cmpv2-coap-transport-00 (work in progress), June 2020. [IEC62443-3-3] IEC, "Industrial communication networks - Network and system security - Part 3-3: System security requirements and security levels", IEC 62443-3-3, August 2013, . @@ -3253,47 +3345,29 @@ [RFC8446] Rescorla, E., "The Transport Layer Security (TLS) Protocol Version 1.3", RFC 8446, DOI 10.17487/RFC8446, August 2018, . [RFC8551] Schaad, J., Ramsdell, B., and S. Turner, "Secure/ Multipurpose Internet Mail Extensions (S/MIME) Version 4.0 Message Specification", RFC 8551, DOI 10.17487/RFC8551, April 2019, . - [UNISIG] UNISIG, "Subset-137; ERTMS/ETCS On-line Key Management + [UNISIG-Subset137] + UNISIG, "Subset-137; ERTMS/ETCS On-line Key Management FFFIS; V1.0.0", December 2015, . -Appendix A. ASN.1 Syntax - - id-it-caCerts OBJECT IDENTIFIER ::= {1 3 6 1 5 5 7 4 xxx} - CaCerts ::= SEQUENCE OF CMPCertificate - } - - id-it-rootCaKeyUpdate OBJECT IDENTIFIER ::= {1 3 6 1 5 5 7 4 xxx} - RootCaKeyUpdate ::= SEQUENCE { - newWithNew CMPCertificate - newWithOld [0] CMPCertificate OPTIONAL, - oldWithNew [1] CMPCertificate OPTIONAL, - } - - id-it-certReqTemplate OBJECT IDENTIFIER ::= {1 3 6 1 5 5 7 4 xxx} - CertReqTemplateValue ::= SEQUENCE { - certTemplate CertTemplate, - rsaKeyLen INTEGER OPTIONAL, - } - - < TBD: The OID id-it-caCerts, id-it-rootCaKeyUpdate, and id-it- - certReqTemplate must be defined by IANA > +Appendix A. Example for CertReqTemplate -Appendix B. Example for CertReqTemplate + < TBD: This Appendix must be updated to reflect the change from using + rsaKeyLen to controles. > This Section provides a concrete example for the content of an infoValue used of type id-it-certReqTemplate as described in Section 4.4.4. Suppose the server requires that the certTemplate contains the issuer field with a value to be filled in by the EE, the subject field with a common name to be filled in by the EE and two organizational unit fields with given values "myDept" and "myGroup", the publicKey field with an RSA public key of length 2048, the subjectAltName extension @@ -3362,25 +3435,64 @@ OBJECT IDENTIFIER extKeyUsage (2 5 29 37) OCTET STRING, encapsulates { SEQUENCE {} } } } } INTEGER 2048 } -Appendix C. History of changes +Appendix B. History of changes - Note: This section will be deleted in the final version of the + Note: This appendix will be deleted in the final version of the document. + From version 02 -> 03: + + o Updated the interoperability with [UNISIG-Subset137] in + Section 1.4. + + o Changed Section 2.3 to a tabular layout to enhanced readability + + o Added a ToDo to section 3.1 on aligning with the CMP Algorithms + draft that will be set up as decided in IETF 108 + + o Updated section 4.1.6 to add the AsymmetricKey Package structure + to transport a newly generated private key as decided in IETF 108 + + o Added a ToDo to section 4.1.7 on required review of the nonce + handling in case an offline LRA responds and not forwards the + pollReq messages + + o Updated Section 4 due to the definition of the new ITAV OIDs in + CMP Updates + + o Updated Section 4.4.4 to utilize controls instead of rsaKeyLen + (see thread "dtaft-ietf-lamps-cmp-updates and rsaKeyLen") + + o Deleted the section on definition and discovery of HTTP URIs and + copied the text to the HTTP transport section and to CMP Updates + section 3.2 + + o Added some explanation to Section 5.1.2 and Section 5.1.3 on using + nested messages when a protection by the RA is required. + + o Deleted the section on HTTP URI definition and discovery as some + content was moved to CMP Updates. The rest of the content was + moved back to the HTTP transport section + + o Deleted the ASN.1 module after moving the new OIDs id-it-caCerts, + id-it-rootCaKeyUpdate, and id-it-certReqTemplate to CMP Updates + + o Minor changes in wording and addition of some open ToDos + From version 01 -> 02: o Extend Section 1.4 with regard to conflicts with UNISIG Subset- 137. o Minor clarifications on extraCerts in Section 3.3 and Section 4.1.1. o Complete specification of requesting a certificate from a trusted PKI with signature protection in Section 4.1.2. @@ -3403,30 +3515,31 @@ rsaKeyLen as a single integer value in Section 4.4.4 as discussed on the mailing list (see thread "draft-ietf-lamps-lightweight-cmp- profile-01, section 5.4.4") o Deleted Sections "Get certificate management configuration" and "Get enrollment voucher" as decided at IETF 107 o Complete specification of adding an additional protection by an PKI management entity in Section 5.1.3. - o Added Section 6.1 and extended Section 6.2 on definition and - discovery of supported HTTP URIs and content types, add a path for - nested messages as specified in Section 5.1.3 and delete the paths - for /getCertMgtConfig and /getVoucher + o Added a section on HTTP URI definition and discovery and extended + Section 6.1 on definition and discovery of supported HTTP URIs and + content types, add a path for nested messages as specified in + Section 5.1.3 and delete the paths for /getCertMgtConfig and + /getVoucher - o Changed Section 6.5 to address offline transport and added more + o Changed Section 6.4 to address offline transport and added more detailed specification file-based transport of CMP o Added a reference to the new I-D of Mohit Sahni on "CoAP Transport - for CMPV2" in Section 6.6; thanks to Mohit supporting the effort + for CMPV2" in Section 6.5; thanks to Mohit supporting the effort to ease utilization of CMP o Moved the change history to the Appendix o Minor changes in wording From version 00 -> 01: o Harmonize terminology with CMP [RFC4210], e.g., @@ -3446,36 +3560,36 @@ From version 02 -> 03: o Added a short summary of [RFC4210] Appendix D and E in Section 1.3. o Clarified some references to different sections and added some clarification in response to feedback from Michael Richardson and Tomas Gustavsson. o Added an additional label to the operational path to address - multiple CAs or certificate profiles in Section 6.2. + multiple CAs or certificate profiles in Section 6.1. From version 01 -> 02: o Added some clarification on the key management techniques for protection of centrally generated keys in Section 4.1.6. o Added some clarifications on the certificates for root CA certificate update in Section 4.4.3. o Added a section to specify the usage of nested messages for RAs to add an additional protection for further discussion, see Section 5.1.3. o Added a table containing endpoints for HTTP transport in - Section 6.2 to simplify addressing PKI management entities. + Section 6.1 to simplify addressing PKI management entities. o Added some ToDos resulting from discussion with Tomas Gustavsson. o Minor clarifications and changes in wording. From version 00 -> 01: o Added a section to specify the enrollment with an already trusted PKI for further discussion, see Section 4.1.2.