--- 1/draft-ietf-lamps-lightweight-cmp-profile-08.txt 2021-12-17 08:13:45.299183683 -0800 +++ 2/draft-ietf-lamps-lightweight-cmp-profile-09.txt 2021-12-17 08:13:45.483188288 -0800 @@ -1,19 +1,19 @@ LAMPS Working Group H. Brockhaus, Ed. Internet-Draft D. von Oheimb Intended status: Standards Track S. Fries -Expires: 23 May 2022 Siemens - 19 November 2021 +Expires: 20 June 2022 Siemens + 17 December 2021 Lightweight Certificate Management Protocol (CMP) Profile - draft-ietf-lamps-lightweight-cmp-profile-08 + draft-ietf-lamps-lightweight-cmp-profile-09 Abstract This document aims at simple, interoperable, and automated PKI management operations covering typical use cases of industrial and IoT scenarios. This is achieved by profiling the Certificate Management Protocol (CMP), the related Certificate Request Message Format (CRMF), and HTTP-based or CoAP-based transfer in a succinct but sufficiently detailed and self-contained way. To make secure certificate management for simple scenarios and constrained devices @@ -30,126 +30,123 @@ 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 23 May 2022. + This Internet-Draft will expire on 20 June 2022. Copyright Notice Copyright (c) 2021 IETF Trust and the persons identified as the document authors. All rights reserved. This document is subject to BCP 78 and the IETF Trust's Legal Provisions Relating to IETF Documents (https://trustee.ietf.org/ license-info) in effect on the date of publication of this document. Please review these documents carefully, as they describe your rights and restrictions with respect to this document. Code Components extracted from this document must include Revised BSD License text as described in Section 4.e of the Trust Legal Provisions and are provided without warranty as described in the Revised BSD License. Table of Contents 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 4 1.1. How to Read This Document . . . . . . . . . . . . . . . . 4 - 1.2. Motivation for a lightweight profile of CMP . . . . . . . 4 - 1.3. Special requirements of industrial and IoT scenarios . . 5 - 1.4. Existing CMP profiles . . . . . . . . . . . . . . . . . . 6 + 1.2. Motivation for a lightweight profile of CMP . . . . . . . 5 + 1.3. Special requirements of industrial and IoT scenarios . . 6 + 1.4. Existing CMP profiles . . . . . . . . . . . . . . . . . . 7 1.5. Use of CMP in SZTP and BRSKI environments . . . . . . . . 7 - 1.6. Compatibility with existing CMP profiles . . . . . . . . 7 + 1.6. Compatibility with existing CMP profiles . . . . . . . . 8 1.7. Scope of this document . . . . . . . . . . . . . . . . . 9 - 1.8. Structure of this document . . . . . . . . . . . . . . . 9 - 1.9. Convention and Terminology . . . . . . . . . . . . . . . 10 - 2. Architecture and use cases . . . . . . . . . . . . . . . . . 11 - 2.1. Solution architecture . . . . . . . . . . . . . . . . . . 11 - 2.2. Supported PKI management operations . . . . . . . . . . . 13 - 2.2.1. Mandatory PKI management operations . . . . . . . . . 13 - 2.2.2. Recommended PKI management operations . . . . . . . . 14 - 2.2.3. Optional PKI management operations . . . . . . . . . 15 - 2.3. CMP message transfer . . . . . . . . . . . . . . . . . . 16 - 3. Generic aspects of the PKI message . . . . . . . . . . . . . 17 - 3.1. General description of the CMP message header . . . . . . 18 - 3.2. General description of the CMP message protection . . . . 20 - 3.3. General description of CMP message extraCerts . . . . . . 20 - 3.4. Generic PKI management operation prerequisites . . . . . 21 - 3.5. Generic validation of a PKI message . . . . . . . . . . . 22 - 3.6. Error handling . . . . . . . . . . . . . . . . . . . . . 24 - 3.6.1. Reporting error conditions upstream . . . . . . . . . 24 - 3.6.2. Reporting error conditions downstream . . . . . . . . 25 + 1.8. Structure of this document . . . . . . . . . . . . . . . 10 + 1.9. Convention and Terminology . . . . . . . . . . . . . . . 11 + 2. Solution architecture . . . . . . . . . . . . . . . . . . . . 12 + 3. Generic aspects of the PKI message . . . . . . . . . . . . . 13 + 3.1. General description of the CMP message header . . . . . . 14 + 3.2. General description of the CMP message protection . . . . 16 + 3.3. General description of CMP message extraCerts . . . . . . 17 + 3.4. Generic PKI management operation prerequisites . . . . . 17 + 3.5. Generic validation of a PKI message . . . . . . . . . . . 19 + 3.6. Error handling . . . . . . . . . . . . . . . . . . . . . 21 + 3.6.1. Reporting error conditions upstream . . . . . . . . . 21 + 3.6.2. Reporting error conditions downstream . . . . . . . . 22 3.6.3. Handling error conditions on nested messages used for - batching . . . . . . . . . . . . . . . . . . . . . . 25 - 3.6.4. Reporting error conditions . . . . . . . . . . . . . 26 - 4. End Entity PKI management operations . . . . . . . . . . . . 28 - 4.1. Requesting a new certificate from a PKI . . . . . . . . . 31 + batching . . . . . . . . . . . . . . . . . . . . . . 22 + 3.6.4. Reporting error conditions . . . . . . . . . . . . . 22 + 4. End Entity PKI management operations . . . . . . . . . . . . 24 + 4.1. Requesting a new certificate from a PKI . . . . . . . . . 27 4.1.1. Requesting a certificate from a new PKI with - signature-based protection . . . . . . . . . . . . . 32 + signature-based protection . . . . . . . . . . . . . 28 4.1.2. Requesting an additional certificate with - signature-based protection . . . . . . . . . . . . . 38 + signature-based protection . . . . . . . . . . . . . 34 4.1.3. Updating an existing certificate with signature - protection . . . . . . . . . . . . . . . . . . . . . 39 - + protection . . . . . . . . . . . . . . . . . . . . . 35 4.1.4. Requesting a certificate from a legacy PKI using a - PKCS#10 request . . . . . . . . . . . . . . . . . . . 40 + PKCS#10 request . . . . . . . . . . . . . . . . . . . 36 4.1.5. Requesting a certificate from a PKI with MAC-based - protection . . . . . . . . . . . . . . . . . . . . . 42 + protection . . . . . . . . . . . . . . . . . . . . . 38 4.1.6. Adding central key pair generation to a certificate - request . . . . . . . . . . . . . . . . . . . . . . . 43 - 4.1.6.1. Using key agreement key management technique . . 48 - 4.1.6.2. Using key transport key management technique . . 50 - 4.1.6.3. Using password-based key management technique . . 50 - 4.2. Revoking a certificate . . . . . . . . . . . . . . . . . 51 - 4.3. Support messages . . . . . . . . . . . . . . . . . . . . 54 - 4.3.1. Get CA certificates . . . . . . . . . . . . . . . . . 56 - 4.3.2. Get root CA certificate update . . . . . . . . . . . 56 - 4.3.3. Get certificate request template . . . . . . . . . . 58 - 4.3.4. CRL update retrieval . . . . . . . . . . . . . . . . 60 - 4.4. Handling delayed delivery . . . . . . . . . . . . . . . . 62 - 5. PKI management entity operations . . . . . . . . . . . . . . 66 - 5.1. Responding to requests . . . . . . . . . . . . . . . . . 66 - 5.1.1. Responding to a certificate request . . . . . . . . . 67 - 5.1.2. Initiating delayed delivery . . . . . . . . . . . . . 67 - 5.1.3. Responding to a confirmation message . . . . . . . . 68 - 5.1.4. Responding to a revocation request . . . . . . . . . 68 - 5.1.5. Responding to a support message . . . . . . . . . . . 69 - 5.2. Forwarding messages . . . . . . . . . . . . . . . . . . . 69 - 5.2.1. Not changing protection . . . . . . . . . . . . . . . 71 - 5.2.2. Adding protection and batching of messages . . . . . 71 - 5.2.2.1. Adding protection to a request message . . . . . 72 - 5.2.2.2. Batching messages . . . . . . . . . . . . . . . . 73 - 5.2.3. Replacing protection . . . . . . . . . . . . . . . . 75 - 5.2.3.1. Not changing any included proof-of-possession . . 75 - 5.2.3.2. Breaking proof-of-possession . . . . . . . . . . 76 - 5.3. Acting on behalf of other PKI entities . . . . . . . . . 76 - 5.3.1. Requesting certificates . . . . . . . . . . . . . . . 77 - 5.3.2. Revoking a certificate . . . . . . . . . . . . . . . 77 - 6. CMP message transfer mechanisms . . . . . . . . . . . . . . . 78 - 6.1. HTTP transfer . . . . . . . . . . . . . . . . . . . . . . 79 - 6.2. CoAP transfer . . . . . . . . . . . . . . . . . . . . . . 81 - 6.3. Piggybacking on other reliable transfer . . . . . . . . . 83 - 6.4. Offline transfer . . . . . . . . . . . . . . . . . . . . 83 - 6.4.1. File-based transfer . . . . . . . . . . . . . . . . . 83 - 6.4.2. Other asynchronous transfer protocols . . . . . . . . 84 - 7. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 84 - 8. Security Considerations . . . . . . . . . . . . . . . . . . . 84 - 9. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 84 - 10. References . . . . . . . . . . . . . . . . . . . . . . . . . 84 - 10.1. Normative References . . . . . . . . . . . . . . . . . . 84 - 10.2. Informative References . . . . . . . . . . . . . . . . . 86 - Appendix A. Example CertReqTemplate . . . . . . . . . . . . . . 89 - Appendix B. History of changes . . . . . . . . . . . . . . . . . 91 - Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 96 + request . . . . . . . . . . . . . . . . . . . . . . . 39 + + 4.1.6.1. Using key agreement key management technique . . 45 + 4.1.6.2. Using key transport key management technique . . 46 + 4.1.6.3. Using password-based key management technique . . 47 + 4.2. Revoking a certificate . . . . . . . . . . . . . . . . . 48 + 4.3. Support messages . . . . . . . . . . . . . . . . . . . . 50 + 4.3.1. Get CA certificates . . . . . . . . . . . . . . . . . 53 + 4.3.2. Get root CA certificate update . . . . . . . . . . . 53 + 4.3.3. Get certificate request template . . . . . . . . . . 55 + 4.3.4. CRL update retrieval . . . . . . . . . . . . . . . . 57 + 4.4. Handling delayed delivery . . . . . . . . . . . . . . . . 59 + 5. PKI management entity operations . . . . . . . . . . . . . . 64 + 5.1. Responding to requests . . . . . . . . . . . . . . . . . 64 + 5.1.1. Responding to a certificate request . . . . . . . . . 65 + 5.1.2. Initiating delayed delivery . . . . . . . . . . . . . 65 + 5.1.3. Responding to a confirmation message . . . . . . . . 66 + 5.1.4. Responding to a revocation request . . . . . . . . . 66 + 5.1.5. Responding to a support message . . . . . . . . . . . 67 + 5.2. Forwarding messages . . . . . . . . . . . . . . . . . . . 67 + 5.2.1. Not changing protection . . . . . . . . . . . . . . . 69 + 5.2.2. Adding protection and batching of messages . . . . . 69 + 5.2.2.1. Adding protection to a request message . . . . . 70 + 5.2.2.2. Batching messages . . . . . . . . . . . . . . . . 71 + 5.2.3. Replacing protection . . . . . . . . . . . . . . . . 73 + 5.2.3.1. Not changing any included proof-of-possession . . 73 + 5.2.3.2. Breaking proof-of-possession . . . . . . . . . . 74 + 5.3. Acting on behalf of other PKI entities . . . . . . . . . 74 + 5.3.1. Requesting certificates . . . . . . . . . . . . . . . 75 + 5.3.2. Revoking a certificate . . . . . . . . . . . . . . . 75 + 6. CMP message transfer mechanisms . . . . . . . . . . . . . . . 76 + 6.1. HTTP transfer . . . . . . . . . . . . . . . . . . . . . . 77 + 6.2. CoAP transfer . . . . . . . . . . . . . . . . . . . . . . 79 + 6.3. Piggybacking on other reliable transfer . . . . . . . . . 81 + 6.4. Offline transfer . . . . . . . . . . . . . . . . . . . . 81 + 6.4.1. File-based transfer . . . . . . . . . . . . . . . . . 82 + 6.4.2. Other asynchronous transfer protocols . . . . . . . . 82 + 7. Conformance requirements . . . . . . . . . . . . . . . . . . 82 + 7.1. PKI management operations . . . . . . . . . . . . . . . . 82 + 7.2. Message transfer . . . . . . . . . . . . . . . . . . . . 85 + 8. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 86 + 9. Security Considerations . . . . . . . . . . . . . . . . . . . 86 + 10. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 86 + 11. References . . . . . . . . . . . . . . . . . . . . . . . . . 86 + 11.1. Normative References . . . . . . . . . . . . . . . . . . 87 + 11.2. Informative References . . . . . . . . . . . . . . . . . 88 + Appendix A. Example CertReqTemplate . . . . . . . . . . . . . . 91 + Appendix B. History of changes . . . . . . . . . . . . . . . . . 93 + Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 98 1. Introduction [RFC Editor: please delete]: The labels "RFC-CMP-Updates" and "RFC- CMP-Alg" in ASN.1 Syntax need to be replaced with the RFC numbers of CMP Updates [I-D.ietf-lamps-cmp-updates] and CMP Algorithms [I-D.ietf-lamps-cmp-algorithms], when available. This document specifies PKI management operations supporting machine- to-machine and IoT use cases. Its focus is to maximize automation @@ -169,40 +166,61 @@ document aims at tailoring the available options and specifying at an adequate detail how to use them to make the implementation of interoperable automated certificate management as straightforward and lightweight as possible. 1.1. How to Read This Document This document has become longer than the authors would have liked it to be. Yet apart from studying Section 3, which contains general requirements, the reader does not have to work through the whole - document but can use the guidance in Section 1.8, Section 2.2, and - Section 2.3 to figure out which parts of Section 4 to Section 6 are - relevant, depending on the PKI management operations and options of - interest. + document. The guidance in Section 1.8 and Section 7 should be used + to figure out which parts of Section 4 to Section 6 are relevant for + the target certificate management solution depending on the PKI + management operations, their variants, and types of message transfer + needed. + + Since conformity to this document can be achieved by implementing + only the functionality declared mandatory in Section 7, the profile + can still be called lightweight because in particular for end + entities the mandatory-to-implement set of features is rather + limited. 1.2. Motivation for a lightweight profile of CMP CMP was standardized in 1999 and is implemented in several PKI products. In 2005, a completely reworked and enhanced version 2 of CMP [RFC4210] and CRMF [RFC4211] has been published, followed by a document specifying a transfer mechanism for CMP messages using HTTP [RFC6712] in 2012. Though CMP is a solid and very capable protocol it is so far not used very widely. The most important reason appears to be that the protocol offers a too large set of features and options. On the one hand, this makes CMP applicable to a very wide range of scenarios, but on the other hand, a full implementation supporting all options is not realistic because this would take undue effort. + In order to reduce complexity, the set of mandatory PKI management + operations and variants required by this specification has been kept + lean. This limits development effort and minimizes resource needs, + which is particularly important for memory-constrained devices. To + this end, when there was a choice to have necessary complexity more + on the EE or PKI management entity side, it has been pushed towards + PKI management entities, where typically more computational resources + are available and the development can be consolidated better. + Additional recommended PKI management operations and variants support + some more complex scenarios that are considered beneficial for + environments with more specific demands or boundary conditions. The + optional PKI management operations support less common scenarios and + requirements. + 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] define some more detailed PKI management operations. Yet, 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 coping with the challenges mentioned above. To profile means to take advantage of the strengths of the given protocol, while explicitly @@ -226,21 +244,21 @@ The profiles specified in Appendix D and E of RFC 4210 [RFC4210] have been developed particularly for managing certificates of human end entities. With the evolution of distributed systems and client- server architectures, certificates for machines and applications on them have become widely used. This trend has strengthened even more in emerging industrial and IoT scenarios. CMP is sufficiently flexible to support them well. Today's IT security architectures for industrial solutions typically use certificates for endpoint authentication within protocols like - IPSec, TLS, or SSH. Therefore, the security of these architectures + IPsec, TLS, or SSH. Therefore, the security of these architectures highly relies upon the security and availability of the implemented certificate management operations. Due to increasing security needs in operational networks as well as availability requirements, especially on critical infrastructures and systems with a high number of certificates, a state-of-the-art certificate management system must be constantly available and cost- efficient, which calls for high automation and reliability. Consequently, the NIST Framework for Improving Critical Infrastructure Cybersecurity [NIST.CSWP.04162018] refers to proper @@ -270,21 +288,21 @@ scenarios. Both Appendixes D and E focus on EE-to-RA/CA PKI management operations and do not address further profiling of RA-to-CA communication as typically needed for full backend automation. All requirements regarding algorithm support for RFC 4210 Appendix D and E [RFC4210] have been updated by CMP Algorithms Section 7.1 [I-D.ietf-lamps-cmp-algorithms]. 3GPP makes use of CMP [RFC4210] in its Technical Specification 33.310 - [ETSI-3GPP.33.310] for automatic management of IPSec certificates in + [ETSI-3GPP.33.310] for automatic management of IPsec certificates in 3G, LTE, and 5G backbone networks. Since 2010, a dedicated CMP profile for initial certificate enrollment and certificate update operations between EE and RA/CA is specified in that document. UNISIG has included a CMP profile for enrollment of TLS certificates in the Subset-137 specifying the ETRAM/ETCS on-line key management for train control systems [UNISIG.Subset-137] in 2015. Both standardization bodies tailor CMP [RFC4210], CRMF [RFC4211], and HTTP transfer for CMP [RFC6712] for highly automated and reliable PKI @@ -441,20 +459,24 @@ Section 5 profiles responding to requests, exchange between PKI management entities, and operations on behalf of other PKI entities. This may include delayed delivery of messages, which involves polling for responses, and nesting of messages. Section 6 outlines several mechanisms for CMP message transfer, including HTTP-based [RFC6712] transfer optionally using TLS, and [I-D.ietf-ace-cmpv2-coap-transport] transfer optionally using DTLS, and offline file-based transport. + Section 7 defines which parts of the profile are mandatory, + recommended, optional, or not relevant to implement for which type of + entity. + 1.9. Convention and Terminology The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in BCP 14 [RFC2119] [RFC8174] when, and only when, they appear in all capitals, as shown here. Technical terminology is used in conformance with RFC 4210 [RFC4210], RFC 4211 [RFC4211], RFC 5280 [RFC5280], and IEEE 802.1AR @@ -490,35 +512,33 @@ PKI management operation: All CMP messages belonging to a single transaction. The transaction is identified by the transactionID field of the message headers. PKI management entity: A non-EE PKI entity, i.e., RA or CA. PKI entity: An EE or PKI management entity. -2. Architecture and use cases - -2.1. Solution architecture +2. Solution architecture To facilitate secure automatic certificate enrollment, the device hosting an EE is typically equipped with a manufacturer-issued device certificate. Such a certificate is typically installed during production and is meant to identify the device throughout its lifetime. This certificate can be used to protect the initial enrollment of operational certificates after installation of the EE in its operational environment. In contrast to the manufacturer- issued device certificate, operational certificates are issued by the owner or operator of the device to identify the device or one of its components for operational use, e.g., in a security protocol like - IPSec, TLS, or SSH. In IEEE 802.1AR [IEEE.802.1AR_2018] a + IPsec, TLS, or SSH. In IEEE 802.1AR [IEEE.802.1AR_2018] a manufacturer-issued device certificate is called IDevID certificate and an operational certificate is called LDevID certificate. Note: According to IEEE 802.1AR [IEEE.802.1AR_2018] a DevID comprises the triple of the certificate, the corresponding private key, and the certificate chain. All certificate management operations specified in this document follow the pull model, i.e., are initiated by an EE (or by an RA acting as an EE). The EE creates a CMP request message, protects it @@ -573,179 +592,20 @@ the messages specified in this profile offer all required capabilities, but the message flow and state machine as described in Section 4 must be adapted to implement a push model. Third-party CAs may implement other variants of CMP, different standardized protocols, or even proprietary interfaces for certificate management. Therefore, the RA may need to adapt the exchanged CMP messages to the flavor of certificate management interaction required by the CA. -2.2. Supported PKI management operations - - Following the scope outlined in Section 1.7, this section gives a - brief overview of the base PKI management operations and their - variants specified in Section 4 and Section 5 and states whether - implementation by compliant EEs or PKI management entities is - mandatory, recommended, or optional. Variants amend or change - behavior of base PKI management operations and are therefore also - listed here. - -2.2.1. Mandatory PKI management operations - - The set of mandatory PKI management operations in this document is - intentionally lean to help for keeping development effort low and to - enable use in memory-constrained devices. - - +=====================================+=========+ - | PKI management operations | Section | - +=====================================+=========+ - | Requesting a certificate from a new | Section | - | PKI with signature-based protection | 4.1.1 | - +-------------------------------------+---------+ - | Updating an existing certificate | Section | - | with signature-based protection | 4.1.3 | - +-------------------------------------+---------+ - - Table 1: Mandatory End Entity PKI management - operations - - +===============================================+=================+ - | PKI management operations | Section | - +===============================================+=================+ - | Responding to a certificate request | Section 5.1 | - +-----------------------------------------------+-----------------+ - | Responding to a confirmation message | Section 5.1.3 | - +-----------------------------------------------+-----------------+ - | Forwarding messages - not changing protection | Section 5.2.1 | - +-----------------------------------------------+-----------------+ - | Adding protection to a request message | Section 5.2.2.1 | - +-----------------------------------------------+-----------------+ - - Table 2: Mandatory PKI management entity operations - -2.2.2. Recommended PKI management operations - - Additional recommended PKI management operations support some more - complex scenarios, that are considered beneficial for environments - with more specific demand or boundary conditions. - - +=================================+=========+ - | PKI management operations | Section | - +=================================+=========+ - | Requesting a certificate from a | Section | - | PKI with MAC-based protection | 4.1.5 | - +---------------------------------+---------+ - | Revoking a certificate | Section | - | | 4.2 | - +---------------------------------+---------+ - - Table 3: Recommended End Entity PKI - management operations - - +====================================+===============+ - | PKI management operations | Section | - +====================================+===============+ - | Responding to a revocation request | Section 5.1.4 | - +------------------------------------+---------------+ - | Acting on behalf of other PKI | Section 5.3.2 | - | entities - revoking a certificate | | - +------------------------------------+---------------+ - - Table 4: Recommended PKI management entity operations - -2.2.3. Optional PKI management operations - - The optional PKI management operations support specific scenarios - seen only in some environments with specific requirements. - - +========================================================+=========+ - | PKI management operations and variants | Section | - +========================================================+=========+ - | Requesting an additional certificate with signature- | Section | - | based protection | 4.1.2 | - +--------------------------------------------------------+---------+ - | Requesting a certificate from a legacy PKI using a | Section | - | PKCS#10 request | 4.1.4 | - +--------------------------------------------------------+---------+ - | Adding central key generation 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.) | | - +--------------------------------------------------------+---------+ - | Support messages | Section | - | | 4.3 | - +--------------------------------------------------------+---------+ - | Handling delayed delivery | Section | - | | 4.4 | - +--------------------------------------------------------+---------+ - | Acting on behalf of other PKI entities - requesting | Section | - | certificates | 5.3.1 | - +--------------------------------------------------------+---------+ - - Table 5: Optional End Entity PKI management operations - - +===============================================+===============+ - | PKI management operations and variants | Section | - +===============================================+===============+ - | Initiating delayed delivery | Section 5.1.2 | - +-----------------------------------------------+---------------+ - | Forwarding messages - replacing protection, | Section | - | not changing any included proof-of-possession | 5.2.3.1 | - +-----------------------------------------------+---------------+ - | Forwarding messages - replacing protection, | Section | - | breaking proof-of-possession | 5.2.3.2 | - +-----------------------------------------------+---------------+ - | Batching messages | Section | - | | 5.2.2.2 | - +-----------------------------------------------+---------------+ - - Table 6: Optional PKI management entity operations - -2.3. CMP message transfer - - On different links between PKI entities, e.g., EE-RA and RA-CA, - different transfer mechanisms MAY be used. CMP does not have - specific needs regarding message transfer, except that for each - request message sent, eventually exactly one response message should - be received. Thus, virtually any reliable transfer mechanism can be - used, e.g., HTTP, CoAP, and offline file-based transfer. Therefore, - this document does not require any specific transfer protocol to be - supported by conforming implementations. - - HTTP transfer is RECOMMENDED to use for all PKI entities, yet full - flexibility is retained to choose whatever transfer mechanism is - suitable, for instance for devices and system architectures with - specific constraints. - - +===============+=============+ - | Transfer | Section | - +===============+=============+ - | HTTP transfer | Section 6.1 | - +---------------+-------------+ - - Table 7: Recommended - transfer mechanisms - - +=========================================+=============+ - | Transfer | Section | - +=========================================+=============+ - | Offline transfer | Section 6.4 | - +-----------------------------------------+-------------+ - | CoAP transfer | Section 6.2 | - +-----------------------------------------+-------------+ - | Piggybacking on other reliable transfer | Section 6.3 | - +-----------------------------------------+-------------+ - - Table 8: Optional transfer mechanisms - 3. Generic aspects of the PKI message This section covers the generic aspects of the PKI management operations specified in Section 4 and Section 5 as upfront general requirements to minimize redundancy in the description and to ease implementation. As described in Section 5.1 of RFC 4210 [RFC4210], all CMP messages have the following general structure: @@ -835,44 +695,44 @@ -- MUST be an algorithm identifier indicating the algorithm -- used for calculating the protection bits -- If it is a signature algorithm its type MUST be a -- MSG_SIG_ALG as specified in [RFC-CMP-Alg] Section 3 and -- MUST be consistent with the subjectPublicKeyInfo field of -- the protection certificate -- If it is a MAC algorithm its type MUST be a MSG_MAC_ALG as -- specified in [RFC-CMP-Alg] Section 6.1 senderKID RECOMMENDED -- MUST be the SubjectKeyIdentifier of the CMP protection - -- certificate + -- certificate in case of signature-based protection transactionID REQUIRED -- In the first message of a PKI management operation: -- MUST be 128 bits of random data, to minimize 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 -- PKI management operation senderNonce REQUIRED -- MUST be cryptographically secure and fresh 128 random bits recipNonce RECOMMENDED -- If this is the first message of a transaction: SHOULD be -- absent -- If this is a delayed response message: MUST be present and -- contain the value of the senderNonce of the respective request -- message in the same transaction -- In all other messages: MUST be present and contain the value -- of the senderNonce of the previous message in the same -- transaction generalInfo OPTIONAL implicitConfirm OPTIONAL - -- The extension is optional in ir/cr/kur/p10cr requests and - -- ip/cp/kup response messages and PROHIBTED in other types of - -- messages + -- RECOMENDED in ir/cr/kur/p10cr messages, + -- OPTIONAL in ip/cp/kup response messages, and + -- PROHIBITED in other types of messages -- Added to request messages to request omission of the certConf -- message -- Added to response messages to grant omission of the certConf -- message -- See [RFC4210] Section 5.1.1.1. ImplicitConfirmValue REQUIRED -- ImplicitConfirmValue MUST be NULL certProfile OPTIONAL -- MAY be present in ir/cr/kur/p10cr and in genm messages of type -- id-it-certReqTemplate @@ -899,21 +759,21 @@ there are cases where protection of error messages specified in Section 3.6 is not possible and therefore MAY be omitted. For MAC-based protection as specified in Section 4.1.5 major differences apply as described there. The CMP message protection provides, if available, message origin authentication and integrity protection for the header and body. The CMP message extraCerts field is not covered by this protection. - Note: The extended key usages described in CMP Updates + Note: The extended key usages described in CMP Updates Section 2.2 [I-D.ietf-lamps-cmp-updates] can be used for authorization of a sending PKI management entity. 3.3. General description of CMP message extraCerts This section describes the generic extraCerts field of all CMP messages with signature-based protection. Any specific requirements on the extraCerts are specified in the respective PKI management operation. @@ -1263,24 +1123,25 @@ The PKI management operations specified in this section cover the following: * Requesting a certificate with variations like initial enrollment, certificate updates, central key generation, and MAC-based protection * Revoking a certificate * Support messages - These operations mainly specify the message body of the CMP messages and utilize the specification of the message header, protection and - extraCerts as specified in Section 3. + extraCerts as specified in Section 3. The messages are named by the + respective field names in PKIBody like ir, ip, cr, cp, etc., see + RFC 4210 Section 5.1.2 [RFC4210]. The following diagram shows the EE state machine covering all PKI management operations described in this section, including negative responses, error messages described in Section 3.6.4, as well as ip/cp/kup/error messages with status "waiting", pollReq, and pollRep messages described in Section 4.4. On receiving messages from upstream, the EE MUST perform the general validation checks described in Section 3.5. The behavior in case an error occurs is described in Section 3.6. @@ -1304,34 +1165,34 @@ | | pollRep | pollReq | | | v | | | waiting for response | | | | | | +------------+--------+ | | | | | | received ip/cp/kup | | received | | with status "accepted" | | rp/genp or | | or "grantedWithMods" | | ip/cp/kup/error | | | | with status | - +-----------+--------------+ | "rejection" | + +---------->+<-------------+ | "rejection" | | | | +-----------+-----+ | | | | | | | implicitConfirm | implicitConfirm | | | granted | not granted | | | | | | | | send certConf | | | v | | | waiting for pkiConf*) | | | | | | | | received | | | | pkiConf | | - +-----------------+-----------------+-----------------+ + +-----------------+------->+<-------+-----------------+ | v end *) in case of a delayed delivery of pkiConf responses the same polling mechanism is initiated as for rp or genp messages, by sending an error message with status "waiting". Note: All CMP messages belonging to the same PKI management operation MUST have the same transactionID because the message receiver @@ -1455,38 +1316,53 @@ 8 format certConf 9 -> certConf -> 10 handle or forward certConf 11 format or receive pkiConf 12 <- pkiConf <- 13 handle pkiConf For this PKI management operation, the EE MUST include exactly one CertReqMsg in the ir. If more certificates are required, further - requests MUST be sent using separate PKI management operation. If - the EE wants to omit sending a certificate confirmation message after - receiving the ip, e.g., to reduce the number of protocol messages - exchanged in this PKI management operation, it MUST request this by - including the implicitConfirm extension in the header of the ir - message, see Section 3.1. + requests MUST be sent using separate PKI management operation. + + The EE SHOULD include the implicitConfirm extension in the header of + the ir message as described in Section 3.1, unless it knows that + certificate confirmation is needed. This leaves the choice to the + PKI management entities whether the EE must send a certConf message + on receiving a new certificate. Depending on the PKI policy and + requirements for managing EE certificates, it can be important for + PKI management entities to learn if the EE accepted the new + certificate. In such cases, when responding with an ip message, the + PKI management entity MUST NOT include the implicitConfirm extension. + In case the PKI management entity does not need any explicit + confirmation from the EE, it MUST include the extension as described + in Section 3.1. This prevents explicit certificate confirmation and + saves the overhead of a further message round-trip. If the EE did not request implicit confirmation or implicit confirmation was not granted by the PKI management entity, certificate confirmation MUST be performed as follows. If the EE successfully received the certificate, it MUST send a certConf message in due time. On receiving a valid certConf message, the PKI management entity MUST respond with a pkiConf message. If the PKI management entity does not receive the expected certConf message in time it MUST handle this like a rejection by the EE. In case of - rejection the PKI management entity SHALL terminate the PKI - management operation, and the PKI MAY revoke the newly issued - certificate. + rejection, depending on its policy the PKI management entity MAY + revoke the newly issued certificate, notify a monitoring system, or + log the event internally. + + Note: Depending on PKI policy, a new certificate may be published by + a PKI management entity, and explicit confirmation may be required. + In this case it is advisable not to do the publication until a + positive certificate confirmation has been received. This way the + need to revoke the certificate on negative confirmation is avoided. If the certificate request was rejected by the CA, the PKI management entity must return an ip message containing the status code "rejection" as described in Section 3.6 and no certifiedKeyPair field. The EE MUST NOT react to such an ip message with a certConf message and the PKI management operation MUST be terminated. Detailed message description: Initialization Request -- ir @@ -1920,42 +1796,42 @@ number generation. Yet maybe this is not the case at the time of requesting an initial certificate during manufacturing. * Lack of computational resources, in particular for RSA key generation. Note: Since 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 + Note: As mentioned in Section 2, 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 a previous request message. The EE requesting central key generation MUST omit the publicKey field from the certTemplate or, in case it has a preference on the key type to be generated, provide it in the algorithm sub-field and fill the subjectPublicKey sub-field with a zero-length BIT STRING. Both variants indicate 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 has been extended to EncryptedKey by CMP Updates + message has been extended to EncryptedKey by CMP Updates Section 2.7 [I-D.ietf-lamps-cmp-updates], EnvelopedData is the preferred alternative to EncryptedValue. In CRMF Section 2.1.9 [RFC4211] the use of EncryptedValue has been deprecated in favor of the EnvelopedData structure. Therefore, this profile requires using EnvelopedData as specified in CMS Section 6 [RFC5652]. When EnvelopedData is to be used in a PKI management operation, CMP v3 MUST be indicated in the message header already for the initial - request message, see Section 7 of CMP Updates + request message, see CMP Updates Section 2.19 and Section 2.20 [I-D.ietf-lamps-cmp-updates]. +----------------------------------+ | EnvelopedData | | [RFC5652] section 6 | | +------------------------------+ | | | SignedData | | | | [RFC5652] section 5 | | | | +--------------------------+ | | | | | AsymmetricKeyPackage | | | @@ -1975,39 +1851,41 @@ containing the newly issued certificate. 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] and [RFC8933], signed by the KGA generating the key pair. The signature MUST be performed using a private key related to a certificate asserting the extended key usage id-kp-cmKGA as described in CMP Updates - [I-D.ietf-lamps-cmp-updates] to demonstrate authorization to generate - key pairs on behalf of an EE. The EE SHOULD verify the presence of - this extended key usage in the SignedData structure. + Section 2.2 [I-D.ietf-lamps-cmp-updates] to demonstrate authorization + to generate key pairs on behalf of an EE. The EE SHOULD validate the + signer certificate contained in the SignedData structure and verify + the presence of this extended key usage in the signer certificate. Note: When 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 since shared - secret information is used for initial authentication. In this case - the EE MAY omit this signature validation. + validate the KGA signature and the related certificate in the + SignedData structure since shared secret information is used for + initial authentication. In this case the EE MAY omit this + validation. The 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. This content-encryption key MUST be securely provided as part of the EnvelopedData structure 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 chose to protect the request message. See CMP Updates section 2.8 + EE chose to protect the request message. See CMP Updates Section 2.7 [I-D.ietf-lamps-cmp-updates] for more details on which key management technique to use. * Signature-based protection of the request message: - 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 protecting the request message allows the key usage keyAgreement. If the certificate also allows the key usage keyEncipherment, the key transport key @@ -2258,21 +2135,21 @@ encryption key but with a different salt value applied in the key derivation algorithm. For this key management technique, the PasswordRecipientInfo structure MUST be used in the contentInfo field. Note: The entropy of the shared secret information is crucial for the level of protection when using a password-based key management technique. For centrally generated key pairs, the entropy of the shared secret information SHALL NOT be less than the security strength of the centrally generated key pair. Further guidance is - available in Section 8. + available in Section 9. The PasswordRecipientInfo structure included into the EnvelopedData structure is specified in CMS Section 6.2.4 [RFC5652]. The detailed description of the PasswordRecipientInfo structure looks like this: pwri REQUIRED -- MUST be a PasswordRecipientInfo as specified in CMS -- Section 6.2.4 [RFC5652] @@ -2483,25 +2359,26 @@ extraCerts REQUIRED -- As described in Section 3.3 4.3.1. 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, e.g., for chain construction, from an PKI management entity by 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 intermediate and issuing CA certificates or with - no content in case no CA certificate is available. + caCerts as specified in CMP Updates Section 2.13 + [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 intermediate + and issuing CA certificates or with no content in case no CA + certificate is available. No specific prerequisites apply in addition to those specified in Section 3.4. The message sequence for this PKI management operation is as given above, with the following specific content: 1 the infoType OID to use is id-it-caCerts 2 the infoValue of the request MUST be absent @@ -2519,21 +2396,21 @@ 4.3.2. Get root CA certificate update This PKI management operation can be used by an EE to request an updated root CA Certificate as described in Section 4.4 of RFC 4210 [RFC4210]. An EE requests an update of a root CA certificate from the PKI management entity by sending a general message with OID id-it- rootCaCert, which SHOULD include the old root CA certificate in the - message body, as specified in CMP Updates + message body, as specified in CMP Updates Section 2.14 [I-D.ietf-lamps-cmp-updates]. The PKI management entity responds with a general response with OID id-it-rootCaKeyUpdate 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. Note: This mechanism may also be used to update trusted non-root certificates, i.e., trusted intermediate CA or issuing CA certificates. @@ -2587,25 +2464,25 @@ -- MUST contain a certificate containing the old public -- root CA key signed with the new private root CA key 4.3.3. Get certificate request template This PKI management operation can be used by an EE to request a template with parameters for future certificate requests. An EE requests certificate request parameters 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 EE MAY - indicate the certificate profile to use in the id-it-certProfile - extension of the generalInfo field in the PKIHeader of the general - message as described in Section 3.1. The PKI management entity - responds with a general response with the same OID that either + specified in CMP Updates Section 2.15 [I-D.ietf-lamps-cmp-updates]. + The EE MAY indicate the certificate profile to use in the id-it- + certProfile extension of the generalInfo field in the PKIHeader of + the general message as described in Section 3.1. The PKI management + entity responds with a general response with the same OID that either contains requirements on the certificate request template, or with no content in case no specific requirements are imposed by the PKI. The CertReqTemplateValue contains requirements on certificate fields and extensions in a certTemplate. Optionally it contains a keySpec field containing requirements on algorithms acceptable for key pair generation. The EE SHOULD follow the requirements from the received CertTemplate, by including in the certificate requests all the fields requested, taking over all the field values provided and filling in any @@ -2636,35 +2513,36 @@ 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 understand or does not know suitable values to be filled in. The publicKey field of type SubjectPublicKeyInfo in the CertTemplate of the CertReqTemplateValue MUST be omitted. In case the PKI management entity wishes to make stipulation on algorithms the EE may use for key generation, this MUST be specified using the keySpec - field as specified in CMP Updates [I-D.ietf-lamps-cmp-updates]. + field as specified in CMP Updates Section 2.15 + [I-D.ietf-lamps-cmp-updates]. The keySpec field, if present, specifies the public key types optionally with parameters, and/or RSA key lengths for which a certificate may be requested. The value of a keySpec element with the OID id-regCtrl-algId, as - specified in CMP Updates [I-D.ietf-lamps-cmp-updates], MUST be of - type AlgorithmIdentifier and give an algorithm other than RSA. For - EC keys the curve information MUST be specified as described in the - respective standard documents. + specified in CMP Updates Section 2.15 [I-D.ietf-lamps-cmp-updates], + MUST be of type AlgorithmIdentifier and give an algorithm other than + RSA. For EC keys the curve information MUST be specified as + described in the respective standard documents. The value of a keySpec element with the OID id-regCtrl-rsaKeyLen, as - specified in CMP Updates [I-D.ietf-lamps-cmp-updates], MUST be a - positive integer value and give an RSA key length. + specified in CMP Updates Section 2.15 [I-D.ietf-lamps-cmp-updates], + MUST be a positive integer value and give an RSA key length. In the CertTemplate of the CertReqTemplateValue the serialNumber, signingAlg, issuerUID, and subjectUID fields MUST be omitted. Specific prerequisites augmenting the prerequisites in Section 3.4: * When using the generalInfo field certProfile, the EE MUST know the identifier needed to indicate the requested certificate profile. The message sequence for this PKI management operation is as given @@ -2698,85 +2576,101 @@ -- available -- MUST be present if the PKI management entity has any -- requirements on the keys generated -- MUST contain one AttributeTypeAndValue per supported -- algorithm with attribute id-regCtrl-algId or -- id-regCtrl-rsaKeyLen 4.3.4. CRL update retrieval This PKI management operation can be used by an EE to request a new - CRL. If a CA offers methods to access a CRL they are often provided - by the CA through the CRLDP or AuthorityInfoAccess as specified in - [RFC5280] components in the issued certificates. In addition, CMP - offers this functionality as part of the PKI management operation. + CRL. If a CA offers methods to access a CRL, it may include CRL + distribution points or authority information access extensions as + specified in RFC 5280 [RFC5280] into the issued certificates. In + addition, CMP offers CRL provisioning functionality as part of the + PKI management operation. An EE requests a CRL update from the PKI management entity by sending - a general message with OID id-it-crlStatusList. This MUST include - the CRL source and, if available, the thisUpdate time of the most - current CRL instance it already has, as specified in CMP Updates - [I-D.ietf-lamps-cmp-updates]. The PKI management entity MUST respond - with a general response with OID id-it-crls. If no thisUpdate value - was given by the EE, it MUST return the latest CRL available. If a - thisUpdate value was given, it MUST return the latest available CRL - in case this CRL is more recent, otherwise the infoValue in the - response message MUST be absent. + a general message with OID id-it-crlStatusList. The EE MUST include + the CRL source identifying the requested CRL and, if available, the + thisUpdate time of the most current CRL instance it already has, as + specified in CMP Updates Section 2.16 [I-D.ietf-lamps-cmp-updates]. + The PKI management entity MUST respond with a general response with + OID id-it-crls. If no thisUpdate value was given by the EE, the PKI + management entity MUST return the latest CRL available. If a + thisUpdate value was given, the PKI management entity MUST return the + latest available CRL in case this CRL is more recent, otherwise the + infoValue in the response message MUST be absent. + + The EE MUST identify the requested CRL either by its CRL distribution + point name or issuer name. The CRL distribution point name can + either be provided form the CRL distribution points extension of the + certificate to be validated or from the issuing distribution point + extension from the CRL to be updated. If no CRL distribution name is + available to identify the CRL, the EE can use the issuer name either + from the certificate to be validated or from the CRL to be updated. + + The PKI management entity SHOULD treat a CRL distribution point name + as an internal pointer to identify a CRL for which is available at + the PKI management entity directly. It is not intended as a way to + fetch an arbitrary CRL from an external location. In addition to the prerequisites specified in Section 3.4, the EE - MUST know for the requested CRL either its CRL distribution point - name or the name of the CRL issuer. + MUST know which CRL to request. Note: If the EE does not want to request a specific CRL it MAY use instead a general message with OID id-it-currentCrl as specified in - RFC 4210 Section 5.3.19.6 [I-D.ietf-lamps-cmp-updates]. + RFC 4210 Section 5.3.19.6 [RFC4210]. The message sequence for this PKI management operation is as given above, with the following specific content: 1 the infoType OID to use is id-it-crlStatusList in the request and id-it-crls in the response 2 the infoValue of the request MUST be present and contain a CRLStatus structure 3 if present, the infoValue of the response MUST contain a CRL The infoValue field of the general request containing the id-it- crlStatusList OID looks like this: - CRLSourceListValue REQUIRED - -- MUST contain a CRLSource structure - -- MUST contain the dpn choice if the CRL distribution point name - -- is available - -- MUST contain the issuer choice otherwise, naming the CA that - -- issues the CRL. + CRLSource REQUIRED + -- MUST contain exactly one CRLSource structure + -- MUST contain the dpn choice of type DistributionPointName if + -- the CRL distribution point name is available + -- Otherwise, MUST contain the issuer choice identifying the CA + -- that issues the CRL. It MUST contain the issuer DN in the + -- directoryName field of a GeneralName element. thisUpdate OPTIONAL -- SHOULD contain the thisUpdate field of the latest CRL form - -- the given dpn or issuer, in case such a CRL is already known - -- by the EE + -- the issuer specified in the given dpn or issuer field, + -- in case such a CRL is already known by the EE The infoValue field of the general response containing the id-it-crls OID looks like this: - infoValue REQUIRED - -- MUST contain a CRL update from the referenced source, if a + infoValue OPTIONAL + -- MUST be absent if no CRL to be returned is available + -- MUST contain one CRL update from the referenced source, if a -- thisUpdate value was not given or a more recent CRL is -- available 4.4. Handling delayed delivery - This is a variant of all PKI management operations described in - described in this document. It is initiated in case a PKI management - entity cannot respond to a request message in a timely manner, - typically due to offline or asynchronous upstream communication, or - due to delays in handling the request. The polling mechanism has - been specified in RFC 4210 Section 5.3.22 [RFC4210] and updated by + This is a variant of all PKI management operations described in this + document. It is initiated in case a PKI management entity cannot + respond to a request message in a timely manner, typically due to + offline or asynchronous upstream communication, or due to delays in + handling the request. The polling mechanism has been specified in + RFC 4210 Section 5.3.22 [RFC4210] and updated by [I-D.ietf-lamps-cmp-updates]. Depending on the PKI architecture, the entity initiating delayed delivery is not necessarily the PKI management entity directly addressed by the EE. When initiating delayed delivery of a message received from an EE, the PKI management entity MUST respond with an ip/cp/kup/error message including the status "waiting". On receiving this response, the EE MUST store in its transaction context the senderNonce of the @@ -2975,22 +2869,22 @@ The PKI management entity terminating the PKI management operation at CMP level MUST respond to all received requests by returning a related CMP response message or an error. Any intermediate PKI management entity MAY respond depending on the PKI configuration and policy. In addition to the checks described in Section 3.5, the responding PKI management entity SHOULD check that a request that initiates a new PKI management operation does not use a transactionID that is - currently in useThe failInfo bit value to use on reporting failure as - described in Section 3.6.4 is transactionIdInUse. If any of these + currently in use. The failInfo bit value to use on reporting failure + as described in Section 3.6.4 is transactionIdInUse. If any of these verification steps or any of the essential checks described in the following subsections fails, the PKI management entity MUST proceed as described in Section 3.6. The responding PKI management entity SHOULD copy the sender field of the request to the recipient field of the response, MUST copy the senderNonce of the request to the recipNonce of the response, and MUST use the same transactionID for the response. 5.1.1. Responding to a certificate request @@ -3214,24 +3108,25 @@ 5.2.2. Adding protection and batching of messages This variant of forwarding a message means that a PKI management entity adds another protection to PKI management messages before forwarding them. 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 - CMP Updates [I-D.ietf-lamps-cmp-updates]) there are various use cases - for adding another protection by a PKI management entity. Specific - procedures are described in more detail in the following sections. + As specified in the updated Section 5.1.3.4 of RFC 4210 [RFC4210] + (see also CMP Updates Section 2.6 [I-D.ietf-lamps-cmp-updates]) there + are various use cases for adding another protection by a PKI + management entity. Specific procedures are described in more detail + in the following sections. Detailed message description: Nested Message - nested Field Value header -- As described in Section 3.1 @@ -3471,21 +3366,22 @@ inserts the new public key in the subjectPublicKey field of the request certTemplate, or it uses a certificate request received from downstream, e.g., by means of a different protocol. In the latter case it SHOULD verify the received proof-of-possession. No specific prerequisites apply in addition to those specified in Section 4.1. Note: An upstream PKI management entity will not be able to differentiate this PKI management operation from the one described in - Section 5.2.3. + Section 5.2.3 because in both cases the message is protected by the + PKI management entity. The message sequence for this PKI management operation is identical to the respective PKI management operation given in Section 4.1, with the following changes: 1 The request messages MUST be signed using the CMP protection key of the PKI management entity taking the role of the EE in this operation. 2 If inclusion of a proper proof-of-possession is not possible the @@ -3568,58 +3464,58 @@ This transfer mechanism can be used by a PKI entity to transfer CMP messages over HTTP. If HTTP transfer 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 URI paths consisting of '/.well- known/cmp/' followed by an operation label depending on the type of PKI management operation. - +=======================================+=================+=========+ - | PKI management operation | operationLabel | Details | - +=======================================+=================+=========+ + +============================+=====================+=========+ + | PKI management operation | operation label | Details | + +============================+=====================+=========+ | Enroll client to new PKI | /initialization | Section | | | | 4.1.1 | - +---------------------------------------+-----------------+---------+ + +----------------------------+---------------------+---------+ | Enroll client to existing | /certification | Section | | PKI | | 4.1.2 | - +---------------------------------------+-----------------+---------+ + +----------------------------+---------------------+---------+ | Update client certificate | /keyupdate | Section | | | | 4.1.3 | - +---------------------------------------+-----------------+---------+ + +----------------------------+---------------------+---------+ | Enroll client using | /p10 | Section | | PKCS#10 | | 4.1.4 | - +---------------------------------------+-----------------+---------+ + +----------------------------+---------------------+---------+ | Revoke client certificate | /revocation | Section | | | | 4.2 | - +---------------------------------------+-----------------+---------+ + +----------------------------+---------------------+---------+ | Get CA certificates | /getcacerts | Section | | | | 4.3.1 | - +---------------------------------------+-----------------+---------+ + +----------------------------+---------------------+---------+ | Get root CA certificate | /getrootupdate | Section | | update | | 4.3.2 | - +---------------------------------------+-----------------+---------+ - | Get certificate request | /getcacerts | Section | + +----------------------------+---------------------+---------+ + | Get certificate request | /getcertreqtemplate | Section | | template | | 4.3.1 | - +---------------------------------------+-----------------+---------+ + +----------------------------+---------------------+---------+ | Get CRL updates | /getcrls | Section | | | | 4.3.4 | - +---------------------------------------+-----------------+---------+ + +----------------------------+---------------------+---------+ | Batching messages | /nested | Section | | | | 5.2.2.2 | | Note: This path element is | | | | applicable only between | | | | PKI management entities. | | | - +---------------------------------------+-----------------+---------+ + +----------------------------+---------------------+---------+ - Table 9: HTTP endpoints + Table 1: HTTP endpoints Independently of any variants used (see Section 4.1.5, Section 4.1.6, and Section 4.4) the operation label corresponding to the PKI management operation SHALL be used. Any certConf or pollReq messages are sent to the same endpoint as determined by the PKI management operation. When a single request message is nested as described in Section 5.2.2.1, the label to use is the same as for the underlying @@ -3667,57 +3563,58 @@ This transfer mechanism can be used by a PKI entity to transfer CMP messages over CoAP [RFC7252], e.g., in constrained environments. If CoAP transfer is used the specifications as described in CMP over CoAP [I-D.ietf-ace-cmpv2-coap-transport] MUST be followed. PKI management operations SHOULD use URI paths consisting of '/.well- known/cmp/' followed by an operation label depending on the type of PKI management operation. - +=======================================+================+=========+ - | PKI management operation | operationLabel | Details | - +=======================================+================+=========+ + +=======================================+===========+=========+ + | PKI management operation | operation | Details | + | | label | | + +=======================================+===========+=========+ | Enroll client to new PKI | /ir | Section | | | | 4.1.1 | - +---------------------------------------+----------------+---------+ + +---------------------------------------+-----------+---------+ | Enroll client to existing PKI | /cr | Section | | | | 4.1.2 | - +---------------------------------------+----------------+---------+ + +---------------------------------------+-----------+---------+ | Update client certificate | /kur | Section | | | | 4.1.3 | - +---------------------------------------+----------------+---------+ + +---------------------------------------+-----------+---------+ | Enroll client using PKCS#10 | /p10 | Section | | | | 4.1.4 | - +---------------------------------------+----------------+---------+ + +---------------------------------------+-----------+---------+ | Revoke client certificate | /rr | Section | | | | 4.2 | - +---------------------------------------+----------------+---------+ + +---------------------------------------+-----------+---------+ | Get CA certificates | /crts | Section | | | | 4.3.1 | - +---------------------------------------+----------------+---------+ + +---------------------------------------+-----------+---------+ | Get root CA certificate update | /rcu | Section | | | | 4.3.2 | - +---------------------------------------+----------------+---------+ + +---------------------------------------+-----------+---------+ | Get certificate request template | /att | Section | | | | 4.3.3 | - +---------------------------------------+----------------+---------+ + +---------------------------------------+-----------+---------+ | Get CRL updates | /crls | Section | | | | 4.3.4 | - +---------------------------------------+----------------+---------+ + +---------------------------------------+-----------+---------+ | Batching messages | /nest | Section | | | | 5.2.2.2 | | Note: This path element is applicable | | | | only between PKI management entities. | | | - +---------------------------------------+----------------+---------+ + +---------------------------------------+-----------+---------+ - Table 10: CoAP endpoints + Table 2: CoAP endpoints Independently of any variants used (see Section 4.1.5, Section 4.1.6, and Section 4.4) the operation label corresponding to the PKI management operation SHALL be used. Any certConf or pollReq messages are sent to the same endpoint as determined by the PKI management operation. When a single request message is nested as described in Section 5.2.2.1, the label to use is the same as for the underlying @@ -3775,70 +3672,248 @@ wrapping is defined for those environments that are MIME-native. The MIME wrapping in this section is specified in RFC 8551 Section 3.1 [RFC8551]. 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 file name extension ".pki" MUST be used. -7. IANA Considerations +7. Conformance requirements -8. Security Considerations + This section defines which level of support for the various features + specified in this profile is required for which type of PKI entity. + +7.1. PKI management operations + + The following table provides an overview of the PKI management + operations specified in Section 4 and Section 5 and states whether + support by conforming EE, RA, and CA implementations is mandatory, + recommended, optional, or not applicable. Variants amend or change + behavior of base PKI management operations and are therefore also + included. + + +==========+=============================+========+========+========+ + | ID | PKI management operations | EE | RA | CA | + | | and variants | | | | + +==========+=============================+========+========+========+ + | Generic | generic aspects of PKI | MUST | MUST | MUST | + | | management operations, | | | | + | | Section 3 | | | | + +----------+-----------------------------+--------+--------+--------+ + | IR | Requesting a certificate | MUST | MUST | MUST | + | | from a new PKI with | | | | + | | signature-based | | | | + | | protection, Section 4.1.1 | | | | + +----------+-----------------------------+--------+--------+--------+ + | CR | Requesting an additional | MAY | MAY | MAY | + | | certificate with | | | | + | | signature-based | | | | + | | protection, Section 4.1.2 | | | | + +----------+-----------------------------+--------+--------+--------+ + | KUR | Updating an existing | MUST | MUST | MUST | + | | certificate with | | | | + | | signature-based | | | | + | | protection, Section 4.1.3 | | | | + +----------+-----------------------------+--------+--------+--------+ + | P10CR | Requesting a certificate | MAY | MAY | MAY | + | | from a legacy PKI using a | | | | + | | PKCS#10 request, | | | | + | | Section 4.1.4 | | | | + +----------+-----------------------------+--------+--------+--------+ + | MAC | Requesting a certificate | SHOULD | SHOULD | SHOULD | + | | from a PKI with MAC-based | | | | + | | protection (IR, CR, KUR, | | | | + | | and P10CR if supported), | | | | + | | Section 4.1.5 | | | | + +----------+-----------------------------+--------+--------+--------+ + | CKeyGen | Adding central key | MAY | MAY | MAY | + | | generation to a | | | | + | | certificate request (IR, | | | | + | | CR, KUR, and P10CR if | | | | + | | supported). (If | | | | + | | supported, key agreement | | | | + | | key management technique | | | | + | | is REQUIRED, and key | | | | + | | transport and password- | | | | + | | based key management | | | | + | | techniques are | | | | + | | OPTIONAL.), Section 4.1.6 | | | | + +----------+-----------------------------+--------+--------+--------+ + | RR | Revoking a certificate, | SHOULD | SHOULD | SHOULD | + | | Section 4.2 | | | | + +----------+-----------------------------+--------+--------+--------+ + | CACerts | Get CA certificates, | MAY | MAY | MAY | + | | Section 4.3.1 | | | | + +----------+-----------------------------+--------+--------+--------+ + | RootUpd | Get root CA certificate | MAY | MAY | MAY | + | | update, Section 4.3.2 | | | | + +----------+-----------------------------+--------+--------+--------+ + | ReqTempl | Get certificate request | MAY | MAY | MAY | + | | template, Section 4.3.3 | | | | + +----------+-----------------------------+--------+--------+--------+ + | CRLUpd | CRL update retrieval, | MAY | MAY | MAY | + | | Section 4.3.4 | | | | + +----------+-----------------------------+--------+--------+--------+ + | Polling | Handling delayed | MAY | MAY | MAY | + | | delivery, Section 4.4 | | | | + +----------+-----------------------------+--------+--------+--------+ + | CertResp | Responding to a | N/A | MAY | MUST | + | | certificate request (IR, | | | | + | | CR, KUR, and P10CR if | | | | + | | supported), Section 5.1.1 | | | | + +----------+-----------------------------+--------+--------+--------+ + | InitPoll | Initiating delayed | N/A | MAY | MAY | + | | delivery, Section 5.1.2 | | | | + +----------+-----------------------------+--------+--------+--------+ + | CertConf | Responding to a | MUST | MAY | MUST | + | | confirmation message, | | | | + | | Section 5.1.3 | | | | + +----------+-----------------------------+--------+--------+--------+ + | RevResp | Responding to a | N/A | MAY | SHOULD | + | | revocation request, | | | | + | | Section 5.1.4 | | | | + +----------+-----------------------------+--------+--------+--------+ + | GenResp | Responding to a support | N/A | MAY | MAY | + | | message (CACerts, | | | | + | | RootUpd, ReqTempl, CRLUpd | | | | + | | if supported), | | | | + | | Section 5.1.5 | | | | + +----------+-----------------------------+--------+--------+--------+ + | FwdKeep | Forwarding messages - not | N/A | MUST | N/A | + | | changing protection, | | | | + | | Section 5.2.1 | | | | + +----------+-----------------------------+--------+--------+--------+ + | FwdAddS | Adding protection to a | N/A | MUST | MUST | + | | request message, | | | | + | | Section 5.2.2.1 | | | | + +----------+-----------------------------+--------+--------+--------+ + | FwdAddB | Batching messages, | N/A | MAY | MAY | + | | Section 5.2.2.2 | | | | + +----------+-----------------------------+--------+--------+--------+ + | FwdRepKP | Forwarding messages - | N/A | MAY | N/A | + | | replacing protection, not | | | | + | | changing any included | | | | + | | proof-of-possession, | | | | + | | Section 5.2.3.1 | | | | + +----------+-----------------------------+--------+--------+--------+ + | FwdRepBP | Forwarding messages - | N/A | MAY | MAY | + | | replacing protection, | | | | + | | breaking proof-of- | | | | + | | possession, | | | | + | | Section 5.2.3.2 | | | | + +----------+-----------------------------+--------+--------+--------+ + | CertOnB | Acting on behalf of other | N/A | MAY | N/A | + | | PKI entities - requesting | | | | + | | certificates, | | | | + | | Section 5.3.1 | | | | + +----------+-----------------------------+--------+--------+--------+ + | RevROnB | Acting on behalf of other | N/A | SHOULD | SHOULD | + | | PKI entities - revoking a | | | | + | | certificate, | | | | + | | Section 5.3.2 | | | | + +----------+-----------------------------+--------+--------+--------+ + + Table 3: Level of support for PKI management operations and variants + +7.2. Message transfer + + CMP does not have specific needs regarding message transfer, except + that for each request message sent, eventually exactly one response + message should be received. Therefore, virtually any reliable + transfer mechanism can be used, such as HTTP, CoAP, and file-based + offline transfer. Thus, this document does not require any specific + transfer protocol to be supported by conforming implementations. + + On different links between PKI entities, e.g., EE-RA and RA-CA, + different transfer mechanisms as specified in Section 6 may be used. + + HTTP transfer is RECOMMENDED to use for all PKI entities for + maximizing general interoperability at transfer level, yet full + flexibility is retained to choose whatever transfer mechanism is + suitable, for instance for devices and system architectures with + specific constraints. + + The following table lists the name and level of support specified for + each transfer mechanism. + + +=========+=======================+========+========+========+ + | ID | Message transfer type | EE | RA | CA | + +=========+=======================+========+========+========+ + | HTTP | HTTP transfer, | SHOULD | SHOULD | SHOULD | + | | Section 6.1 | | | | + +---------+-----------------------+--------+--------+--------+ + | CoAP | CoAP transfer, | MAY | MAY | MAY | + | | Section 6.2 | | | | + +---------+-----------------------+--------+--------+--------+ + | Piggyb | Piggybacking on other | MAY | MAY | MAY | + | | reliable transfer, | | | | + | | Section 6.3 | | | | + +---------+-----------------------+--------+--------+--------+ + | Offline | Offline transfer, | MAY | MAY | MAY | + | | Section 6.4 | | | | + +---------+-----------------------+--------+--------+--------+ + + Table 4: Level of support for message transfer types + +8. IANA Considerations + + This document does not request changes to the IANA registry. + +9. Security Considerations The security considerations as laid out in CMP [RFC4210] updated by CMP Updates [I-D.ietf-lamps-cmp-updates] and CMP Algorithms [I-D.ietf-lamps-cmp-algorithms], CRMF [RFC4211] updated by Algorithm Requirements Update [RFC9045], CMP over HTTP [RFC6712], and CMP over CoAP [I-D.ietf-ace-cmpv2-coap-transport] apply. For TLS using shared secret information-based authentication, both PSK and PAKE provide the same amount of protection against a real- time authentication attack which is directly the amount of entropy in the shared secret. The difference between a pre-shared key (PSK) and - a password-authenticated key exchange (PAKE) protocols is in the - level of long-term confidentiality of the TLS messages against brute- - force decryption, where a PSK-based cipher suite only provides - security according to the entropy of the shared secret, while a PAKE- - based cipher suite provides full security independent of the entropy - of the shared secret. + a password-authenticated key exchange (PAKE) protocol is in the level + of long-term confidentiality of the TLS messages against brute-force + decryption, where a PSK-based cipher suite only provides security + according to the entropy of the shared secret, while a PAKE-based + cipher suite provides full security independent of the entropy of the + shared secret. -9. Acknowledgements +10. Acknowledgements We thank the various reviewers of this document. -10. References - -10.1. Normative References +11. References +11.1. Normative References [I-D.ietf-ace-cmpv2-coap-transport] Sahni, M. and S. Tripathi, "CoAP Transfer for the Certificate Management Protocol", Work in Progress, Internet-Draft, draft-ietf-ace-cmpv2-coap-transport-04, 8 November 2021, . [I-D.ietf-lamps-cmp-algorithms] Brockhaus, H., Aschauer, H., Ounsworth, M., and J. Gray, "Certificate Management Protocol (CMP) Algorithms", Work in Progress, Internet-Draft, draft-ietf-lamps-cmp- algorithms-08, 17 November 2021, . [I-D.ietf-lamps-cmp-updates] Brockhaus, H., Oheimb, D. V., and J. Gray, "Certificate Management Protocol (CMP) Updates", Work in Progress, - Internet-Draft, draft-ietf-lamps-cmp-updates-13, 25 - October 2021, . + Internet-Draft, draft-ietf-lamps-cmp-updates-15, 17 + December 2021, . [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, . @@ -3882,21 +3957,21 @@ (CMS) for Algorithm Identifier Protection", RFC 8933, DOI 10.17487/RFC8933, October 2020, . [RFC9045] Housley, R., "Algorithm Requirements Update to the Internet X.509 Public Key Infrastructure Certificate Request Message Format (CRMF)", RFC 9045, DOI 10.17487/RFC9045, June 2021, . -10.2. Informative References +11.2. Informative References [ETSI-3GPP.33.310] 3GPP, "Network Domain Security (NDS); Authentication Framework (AF)", 3GPP TS 33.310 16.6.0, 16 December 2020. [I-D.ietf-anima-brski-async-enroll] Fries, S., Brockhaus, H., Oheimb, D. V., and E. Lear, "Support of Asynchronous Enrollment in BRSKI (BRSKI-AE)", Work in Progress, Internet-Draft, draft-ietf-anima-brski- async-enroll-04, 25 October 2021, @@ -3907,23 +3982,23 @@ Fries, S., Werner, T., Lear, E., and M. Richardson, "BRSKI with Pledge in Responder Mode (BRSKI-PRM)", Work in Progress, Internet-Draft, draft-ietf-anima-brski-prm-00, 25 October 2021, . [I-D.ietf-netconf-sztp-csr] Watsen, K., Housley, R., and S. Turner, "Conveying a Certificate Signing Request (CSR) in a Secure Zero Touch Provisioning (SZTP) Bootstrapping Request", Work in - Progress, Internet-Draft, draft-ietf-netconf-sztp-csr-11, - 8 November 2021, . + Progress, Internet-Draft, draft-ietf-netconf-sztp-csr-12, + 3 December 2021, . [IEC.62443-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, . [IEEE.802.1AR_2018] IEEE, "IEEE Standard for Local and metropolitan area networks - Secure Device Identity", IEEE 802.1AR-2018, @@ -4076,39 +4151,61 @@ SEQUENCE { OBJECT IDENTIFIER extKeyUsage (2 5 29 37) OCTET STRING, encapsulates { SEQUENCE {} } } } } SEQUENCE { SEQUENCE { - OBJECT IDENTIFIER aldId (1 3 6 1 5 5 7 5 1 11) + OBJECT IDENTIFIER algId (1 3 6 1 5 5 7 5 1 11) SEQUENCE { OBJECT IDENTIFIER ecPublicKey (1 2 840 10045 2 1) OBJECT IDENTIFIER secp256r1 (1 2 840 10045 3 1 7) } } SEQUENCE { OBJECT IDENTIFIER rsaKeyLen (1 3 6 1 5 5 7 5 1 12) INTEGER 2048 } } } Appendix B. History of changes Note: This appendix will be deleted in the final version of the document. + From version 08 -> 09: + + * Updated Section 1.1 and 1.2 and converted Section 2.2 and 2.3 into + more detailed tables in Section 7 (see thread "WG Last Call for + draft-ietf-lamps-cmp-updates-14 and draft-ietf-lamps-lightweight- + cmp-profile-08") + * Updated Section 3.1 and 4.1.1 making implicitConfirm recommended + for ir/cr/p10cr/kur and providing further recommendations on its + use (see thread "certConf - WG Last Call for draft-ietf-lamps-cmp- + updates-14 and draft-ietf-lamps-lightweight-cmp-profile-08") + * Updated Section 4.1.6 adding some clarifications regarding + validating the authorization of centrally generated keys + * Updated Section 4.3.4 adding some clarifications on CRL update + retrieval (see thread "CRL update retrieval - WG Last Call for + draft-ietf-lamps-cmp-updates-14 and draft-ietf-lamps-lightweight- + cmp-profile-08") + * Updated references to CMP Updates pointing to concrete sections + (see thread "CRL update retrieval - WG Last Call for draft-ietf- + lamps-cmp-updates-14 and draft-ietf-lamps-lightweight-cmp-profile- + 08")) + * Corrected a couple of nits elsewhere + From version 07 -> 08: * Updates Section 4.1.6.1. regarding content of the originator and keyEncryptionAlgorithm fields (see thread "AD review of draft- ietf-lamps-cmp-algorithms-07") * Rolled back part of the changes on root CA certificate updates in Section 4.3.2 (see thread "Allocation of OIDs for CRL update retrieval (draft-ietf-lamps-cmp-updates-13)") From version 06 -> 07: