idnits 2.17.1 draft-ietf-lamps-lightweight-cmp-profile-07.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- No issues found here. Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- == There is 1 instance of lines with non-ascii characters in the document. Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- == There are 5 instances of lines with non-RFC6890-compliant IPv4 addresses in the document. If these are example addresses, they should be changed. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust and authors Copyright Line does not match the current year == Using lowercase 'not' together with uppercase 'MUST', 'SHALL', 'SHOULD', or 'RECOMMENDED' is not an accepted usage according to RFC 2119. Please use uppercase 'NOT' together with RFC 2119 keywords (if that is what you mean). Found 'SHOULD not' in this paragraph: When in Section 3, Section 4, and Section 5 a field of the ASN.1 syntax as defined in CMP [RFC4210] and [I-D.ietf-lamps-cmp-updates], CRMF [RFC4211], and CMS [RFC5652] and [RFC8933] is not explicitly specified, it SHOULD not be used by the sending entity. The receiving entity MUST NOT require its absence and if present MUST gracefully handle its presence. == Using lowercase 'not' together with uppercase 'MUST', 'SHALL', 'SHOULD', or 'RECOMMENDED' is not an accepted usage according to RFC 2119. Please use uppercase 'NOT' together with RFC 2119 keywords (if that is what you mean). Found 'SHOULD not' in this paragraph: header pvno REQUIRED -- MUST be 3 to indicate CMP v3 in all cases where EnvelopedData -- is supported and expected to be used in the current -- PKI management operation -- MUST be 3 to indicate CMP v3 in certConf messages when using -- the hashAlg field -- MUST be 2 to indicate CMP v2 in all other cases -- For details on version negotiation see RFC-CMP-Updates sender REQUIRED -- SHOULD contain a name representing the originator of the -- message; otherwise, the NULL-DN (a zero-length -- SEQUENCE OF RelativeDistinguishedNames) MUST be used -- SHOULD be the subject of the CMP protection certificate, i.e., -- the certificate corresponding to the private key used to sign -- the message -- In a multi-hop scenario, the receiving entity SHOULD not rely -- on the correctness of the sender field. recipient REQUIRED -- SHOULD be the name of the intended recipient; otherwise, the -- NULL-DN MUST be used -- In the first message of a PKI management operation: -- SHOULD be the subject DN of the CA the PKI management -- operation is requested from -- In all other messages: -- SHOULD contain the value of the sender field of the previous -- message in the same PKI management operation -- The recipient field SHALL be handled gracefully by the -- receiving entity, because in a multi-hop scenario its -- correctness cannot be guaranteed. messageTime RECOMMENDED -- MUST be the time at which the message was produced, if present protectionAlg REQUIRED -- 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 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 -- 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 -- MUST be omitted in all other messages -- See [RFC-CMP-Updates] CertProfileValue REQUIRED -- MUST contain exactly one UTF8String element -- MUST contain the name of a certificate profile == Using lowercase 'not' together with uppercase 'MUST', 'SHALL', 'SHOULD', or 'RECOMMENDED' is not an accepted usage according to RFC 2119. Please use uppercase 'NOT' together with RFC 2119 keywords (if that is what you mean). Found 'MUST not' in this paragraph: Upstream PKI management entities will not receive any CMP message to learn that the PKI management operation has been terminated. In case they expect a further message from the EE, a connection interruption or timeout will occur. Then they also MUST regard the current PKI management operation as terminated with failure and MUST not attempt to send an error message downstream. == Using lowercase 'not' together with uppercase 'MUST', 'SHALL', 'SHOULD', or 'RECOMMENDED' is not an accepted usage according to RFC 2119. Please use uppercase 'NOT' together with RFC 2119 keywords (if that is what you mean). Found 'MUST not' in this paragraph: If the error condition is on an upstream nested message containing batched requests, it MUST not attempt to respond to the individual requests included in it. == Using lowercase 'not' together with uppercase 'MUST', 'SHALL', 'SHOULD', or 'RECOMMENDED' is not an accepted usage according to RFC 2119. Please use uppercase 'NOT' together with RFC 2119 keywords (if that is what you mean). Found 'SHALL not' in this paragraph: 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. -- The document date (25 October 2021) is 914 days in the past. Is this intentional? Checking references for intended status: Proposed Standard ---------------------------------------------------------------------------- (See RFCs 3967 and 4897 for information about using normative references to lower-maturity documents in RFCs) == Missing Reference: 'RFC-CMP-Alg' is mentioned on line 842, but not defined == Missing Reference: 'RFC-CMP-Updates' is mentioned on line 880, but not defined == Missing Reference: 'RFC8419' is mentioned on line 2193, but not defined -- Looks like a reference, but probably isn't: '3' on line 4032 -- Looks like a reference, but probably isn't: '5' on line 4035 -- Looks like a reference, but probably isn't: '9' on line 4058 -- Looks like a reference, but probably isn't: '2' on line 4063 -- Looks like a reference, but probably isn't: '7' on line 4064 == Outdated reference: A later version (-10) exists of draft-ietf-ace-cmpv2-coap-transport-03 == Outdated reference: A later version (-15) exists of draft-ietf-lamps-cmp-algorithms-07 == Outdated reference: A later version (-23) exists of draft-ietf-lamps-cmp-updates-12 ** Downref: Normative reference to an Informational RFC: RFC 2986 == Outdated reference: A later version (-05) exists of draft-ietf-anima-brski-async-enroll-04 == Outdated reference: A later version (-12) exists of draft-ietf-anima-brski-prm-00 == Outdated reference: A later version (-14) exists of draft-ietf-netconf-sztp-csr-09 -- Obsolete informational reference (is this intentional?): RFC 2510 (Obsoleted by RFC 4210) -- Obsolete informational reference (is this intentional?): RFC 2818 (Obsoleted by RFC 9110) -- Obsolete informational reference (is this intentional?): RFC 5246 (Obsoleted by RFC 8446) Summary: 1 error (**), 0 flaws (~~), 17 warnings (==), 9 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 LAMPS Working Group H. Brockhaus, Ed. 3 Internet-Draft S. Fries 4 Intended status: Standards Track D. von Oheimb 5 Expires: 28 April 2022 Siemens 6 25 October 2021 8 Lightweight Certificate Management Protocol (CMP) Profile 9 draft-ietf-lamps-lightweight-cmp-profile-07 11 Abstract 13 This document aims at simple, interoperable, and automated PKI 14 management operations covering typical use cases of industrial and 15 IoT scenarios. This is achieved by profiling the Certificate 16 Management Protocol (CMP), the related Certificate Request Message 17 Format (CRMF), and HTTP-based or CoAP-based transfer in a succinct 18 but sufficiently detailed and self-contained way. To make secure 19 certificate management for simple scenarios and constrained devices 20 as lightweight as possible, only the most crucial types of operations 21 and options are specified as mandatory. More special and complex use 22 cases are supported as well, by features specified as recommended or 23 optional. 25 Status of This Memo 27 This Internet-Draft is submitted in full conformance with the 28 provisions of BCP 78 and BCP 79. 30 Internet-Drafts are working documents of the Internet Engineering 31 Task Force (IETF). Note that other groups may also distribute 32 working documents as Internet-Drafts. The list of current Internet- 33 Drafts is at https://datatracker.ietf.org/drafts/current/. 35 Internet-Drafts are draft documents valid for a maximum of six months 36 and may be updated, replaced, or obsoleted by other documents at any 37 time. It is inappropriate to use Internet-Drafts as reference 38 material or to cite them other than as "work in progress." 40 This Internet-Draft will expire on 28 April 2022. 42 Copyright Notice 44 Copyright (c) 2021 IETF Trust and the persons identified as the 45 document authors. All rights reserved. 47 This document is subject to BCP 78 and the IETF Trust's Legal 48 Provisions Relating to IETF Documents (https://trustee.ietf.org/ 49 license-info) in effect on the date of publication of this document. 50 Please review these documents carefully, as they describe your rights 51 and restrictions with respect to this document. Code Components 52 extracted from this document must include Simplified BSD License text 53 as described in Section 4.e of the Trust Legal Provisions and are 54 provided without warranty as described in the Simplified BSD License. 56 Table of Contents 58 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 4 59 1.1. How to Read This Document . . . . . . . . . . . . . . . . 4 60 1.2. Motivation for a lightweight profile of CMP . . . . . . . 4 61 1.3. Special requirements of industrial and IoT scenarios . . 5 62 1.4. Existing CMP profiles . . . . . . . . . . . . . . . . . . 6 63 1.5. Use of CMP in SZTP and BRSKI environments . . . . . . . . 7 64 1.6. Compatibility with existing CMP profiles . . . . . . . . 7 65 1.7. Scope of this document . . . . . . . . . . . . . . . . . 9 66 1.8. Structure of this document . . . . . . . . . . . . . . . 9 67 1.9. Convention and Terminology . . . . . . . . . . . . . . . 10 68 2. Architecture and use cases . . . . . . . . . . . . . . . . . 11 69 2.1. Solution architecture . . . . . . . . . . . . . . . . . . 11 70 2.2. Supported PKI management operations . . . . . . . . . . . 13 71 2.2.1. Mandatory PKI management operations . . . . . . . . . 13 72 2.2.2. Recommended PKI management operations . . . . . . . . 14 73 2.2.3. Optional PKI management operations . . . . . . . . . 15 74 2.3. CMP message transfer . . . . . . . . . . . . . . . . . . 16 75 3. Generic aspects of the PKI message . . . . . . . . . . . . . 17 76 3.1. General description of the CMP message header . . . . . . 18 77 3.2. General description of the CMP message protection . . . . 20 78 3.3. General description of CMP message extraCerts . . . . . . 20 79 3.4. Generic PKI management operation prerequisites . . . . . 21 80 3.5. Generic validation of a PKI message . . . . . . . . . . . 22 81 3.6. Error handling . . . . . . . . . . . . . . . . . . . . . 24 82 3.6.1. Reporting error conditions upstream . . . . . . . . . 24 83 3.6.2. Reporting error conditions downstream . . . . . . . . 25 84 3.6.3. Handling error conditions on nested messages used for 85 batching . . . . . . . . . . . . . . . . . . . . . . 25 86 3.6.4. Reporting error conditions . . . . . . . . . . . . . 26 87 4. End Entity PKI management operations . . . . . . . . . . . . 28 88 4.1. Requesting a new certificate from a PKI . . . . . . . . . 31 89 4.1.1. Requesting a certificate from a new PKI with 90 signature-based protection . . . . . . . . . . . . . 32 91 4.1.2. Requesting an additional certificate with 92 signature-based protection . . . . . . . . . . . . . 38 93 4.1.3. Updating an existing certificate with signature 94 protection . . . . . . . . . . . . . . . . . . . . . 39 96 4.1.4. Requesting a certificate from a legacy PKI using a 97 PKCS#10 request . . . . . . . . . . . . . . . . . . . 40 98 4.1.5. Requesting a certificate from a PKI with MAC-based 99 protection . . . . . . . . . . . . . . . . . . . . . 42 100 4.1.6. Adding central key pair generation to a certificate 101 request . . . . . . . . . . . . . . . . . . . . . . . 43 102 4.1.6.1. Using key agreement key management technique . . 48 103 4.1.6.2. Using key transport key management technique . . 50 104 4.1.6.3. Using password-based key management technique . . 50 105 4.2. Revoking a certificate . . . . . . . . . . . . . . . . . 51 106 4.3. Support messages . . . . . . . . . . . . . . . . . . . . 54 107 4.3.1. Get CA certificates . . . . . . . . . . . . . . . . . 56 108 4.3.2. Get root CA certificate update . . . . . . . . . . . 56 109 4.3.3. Get certificate request template . . . . . . . . . . 58 110 4.3.4. CRL update retrieval . . . . . . . . . . . . . . . . 60 111 4.4. Handling delayed delivery . . . . . . . . . . . . . . . . 62 112 5. PKI management entity operations . . . . . . . . . . . . . . 66 113 5.1. Responding to requests . . . . . . . . . . . . . . . . . 66 114 5.1.1. Responding to a certificate request . . . . . . . . . 67 115 5.1.2. Initiating delayed delivery . . . . . . . . . . . . . 68 116 5.1.3. Responding to a confirmation message . . . . . . . . 68 117 5.1.4. Responding to a revocation request . . . . . . . . . 69 118 5.1.5. Responding to a support message . . . . . . . . . . . 69 119 5.2. Forwarding messages . . . . . . . . . . . . . . . . . . . 69 120 5.2.1. Not changing protection . . . . . . . . . . . . . . . 71 121 5.2.2. Adding protection and batching of messages . . . . . 72 122 5.2.2.1. Adding protection to a request message . . . . . 72 123 5.2.2.2. Batching messages . . . . . . . . . . . . . . . . 74 124 5.2.3. Replacing protection . . . . . . . . . . . . . . . . 75 125 5.2.3.1. Not changing any included proof-of-possession . . 76 126 5.2.3.2. Breaking proof-of-possession . . . . . . . . . . 76 127 5.3. Acting on behalf of other PKI entities . . . . . . . . . 77 128 5.3.1. Requesting certificates . . . . . . . . . . . . . . . 77 129 5.3.2. Revoking a certificate . . . . . . . . . . . . . . . 78 130 6. CMP message transfer mechanisms . . . . . . . . . . . . . . . 78 131 6.1. HTTP transfer . . . . . . . . . . . . . . . . . . . . . . 79 132 6.2. CoAP transfer . . . . . . . . . . . . . . . . . . . . . . 81 133 6.3. Piggybacking on other reliable transfer . . . . . . . . . 83 134 6.4. Offline transfer . . . . . . . . . . . . . . . . . . . . 83 135 6.4.1. File-based transfer . . . . . . . . . . . . . . . . . 83 136 6.4.2. Other asynchronous transfer protocols . . . . . . . . 84 137 7. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 84 138 8. Security Considerations . . . . . . . . . . . . . . . . . . . 84 139 9. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 84 140 10. References . . . . . . . . . . . . . . . . . . . . . . . . . 84 141 10.1. Normative References . . . . . . . . . . . . . . . . . . 84 142 10.2. Informative References . . . . . . . . . . . . . . . . . 86 143 Appendix A. Example CertReqTemplate . . . . . . . . . . . . . . 89 144 Appendix B. History of changes . . . . . . . . . . . . . . . . . 91 145 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 95 147 1. Introduction 149 [RFC Editor: please delete]: The labels "RFC-CMP-Updates" and "RFC- 150 CMP-Alg" in ASN.1 Syntax need to be replaced with the RFC numbers of 151 CMP Updates [I-D.ietf-lamps-cmp-updates] and CMP Algorithms 152 [I-D.ietf-lamps-cmp-algorithms], when available. 154 This document specifies PKI management operations supporting machine- 155 to-machine and IoT use cases. Its focus is to maximize automation 156 and interoperability between all involved PKI entities, ranging from 157 end entities (EE) over any number of intermediate PKI management 158 entities such as Registration Authorities (RA) to the CMP endpoints 159 of Certification Authority (CA) systems. This profile makes use of 160 the concepts and syntax specified in CMP [RFC4210], 161 [I-D.ietf-lamps-cmp-updates], and [I-D.ietf-lamps-cmp-algorithms], 162 CRMF [RFC4211] and [RFC9045], CMS [RFC5652] and [RFC8933], HTTP 163 transfer for CMP [RFC6712], and CoAP transfer for CMP 164 [I-D.ietf-ace-cmpv2-coap-transport]. Especially CMP, CRMF, and CMS 165 are very feature-rich standards, while in most application scenarios 166 only a limited subset of the specified functionality is needed. 167 Additionally, the standards are not always precise enough on how to 168 interpret and implement the described concepts. Therefore, this 169 document aims at tailoring the available options and specifying at an 170 adequate detail how to use them to make the implementation of 171 interoperable automated certificate management as straightforward and 172 lightweight as possible. 174 1.1. How to Read This Document 176 This document has become longer than the authors would have liked it 177 to be. Yet apart from studying Section 3, which contains general 178 requirements, the reader does not have to work through the whole 179 document but can use the guidance in Section 1.8, Section 2.2, and 180 Section 2.3 to figure out which parts of Section 4 to Section 6 are 181 relevant, depending on the PKI management operations and options of 182 interest. 184 1.2. Motivation for a lightweight profile of CMP 186 CMP was standardized in 1999 and is implemented in several PKI 187 products. In 2005, a completely reworked and enhanced version 2 of 188 CMP [RFC4210] and CRMF [RFC4211] has been published, followed by a 189 document specifying a transfer mechanism for CMP messages using HTTP 190 [RFC6712] in 2012. 192 Though CMP is a solid and very capable protocol it is so far not used 193 very widely. The most important reason appears to be that the 194 protocol offers a too large set of features and options. On the one 195 hand, this makes CMP applicable to a very wide range of scenarios, 196 but on the other hand, a full implementation supporting all options 197 is not realistic because this would take undue effort. 199 Moreover, many details of the CMP protocol have been left open or 200 have not been specified in full preciseness. The profiles specified 201 in Appendix D and E of [RFC4210] define some more detailed PKI 202 management operations. Yet, the specific needs of highly automated 203 scenarios for a machine-to-machine communication are not covered 204 sufficiently. 206 As also 3GPP and UNISIG already put across, profiling is a way of 207 coping with the challenges mentioned above. To profile means to take 208 advantage of the strengths of the given protocol, while explicitly 209 narrowing down the options it provides to those needed for the 210 purpose(s) at hand and eliminating all identified ambiguities. In 211 this way all the general and applicable aspects of the general 212 protocol are taken over and only the peculiarities of the target 213 scenarios need to be dealt with specifically. 215 Defining a profile for a new target environment takes high effort 216 because the range of available options needs to be well understood 217 and the selected options need to be consistent with each other and 218 suitably cover the intended application scenario. Since most 219 industrial PKI management use cases typically have much in common it 220 is worth sharing this effort, which is the aim of this document. 221 Other standardization bodies can reference this document and do not 222 need to come up with individual profiles from scratch. 224 1.3. Special requirements of industrial and IoT scenarios 226 The profiles specified in Appendix D and E of RFC 4210 [RFC4210] have 227 been developed particularly for managing certificates of human end 228 entities. With the evolution of distributed systems and client- 229 server architectures, certificates for machines and applications on 230 them have become widely used. This trend has strengthened even more 231 in emerging industrial and IoT scenarios. CMP is sufficiently 232 flexible to support them well. 234 Today's IT security architectures for industrial solutions typically 235 use certificates for endpoint authentication within protocols like 236 IPSec, TLS, or SSH. Therefore, the security of these architectures 237 highly relies upon the security and availability of the implemented 238 certificate management operations. 240 Due to increasing security needs in operational networks as well as 241 availability requirements, especially on critical infrastructures and 242 systems with a high number of certificates, a state-of-the-art 243 certificate management system must be constantly available and cost- 244 efficient, which calls for high automation and reliability. 245 Consequently, the NIST Framework for Improving Critical 246 Infrastructure Cybersecurity [NIST.CSWP.04162018] refers to proper 247 processes for issuance, management, verification, revocation, and 248 audit for authorized devices, users, and processes involving identity 249 and credential management. Such PKI management operations according 250 to commonly accepted best practices are also required in 251 IEC 62443-3-3 [IEC.62443-3-3] for security level 2 and higher. 253 Further challenges in many industrial systems are network 254 segmentation and asynchronous communication, while PKI management 255 entities like Certification Authorities (CA) typically are not 256 deployed on-site but in a more protected environment of a data center 257 or trust center. Certificate management must be able to cope with 258 such network architectures. CMP offers the required flexibility and 259 functionality, namely self-contained messages, efficient polling, and 260 support for asynchronous message transfer while retaining end-to-end 261 security. 263 1.4. Existing CMP profiles 265 As already stated, RFC 4210 [RFC4210] contains profiles with 266 mandatory and optional PKI management operations in Appendix D and E. 267 Those profiles focus on management of human user certificates and 268 only partly address the specific needs of certificate management 269 automation for unattended devices or machine-to-machine application 270 scenarios. 272 Both Appendixes D and E focus on EE-to-RA/CA PKI management 273 operations and do not address further profiling of RA-to-CA 274 communication as typically needed for full backend automation. All 275 requirements regarding algorithm support for RFC 4210 Appendix D and 276 E [RFC4210] have been updated by CMP Algorithms Section 7.1 277 [I-D.ietf-lamps-cmp-algorithms]. 279 3GPP makes use of CMP [RFC4210] in its Technical Specification 33.310 280 [ETSI-3GPP.33.310] for automatic management of IPSec certificates in 281 3G, LTE, and 5G backbone networks. Since 2010, a dedicated CMP 282 profile for initial certificate enrollment and certificate update 283 operations between EE and RA/CA is specified in that document. 285 UNISIG has included a CMP profile for enrollment of TLS certificates 286 in the Subset-137 specifying the ETRAM/ETCS on-line key management 287 for train control systems [UNISIG.Subset-137] in 2015. 289 Both standardization bodies tailor CMP [RFC4210], CRMF [RFC4211], and 290 HTTP transfer for CMP [RFC6712] for highly automated and reliable PKI 291 management operations for unattended devices and services. 293 1.5. Use of CMP in SZTP and BRSKI environments 295 In Secure Zero Touch Provisioning (SZTP) [RFC8572] environments, 296 SZTP-CSR [I-D.ietf-netconf-sztp-csr] includes certificate signing 297 requests (CSR) in device bootstrapping to obtain a public-key 298 certificate for a locally generated key pair. One option is using a 299 CMP p10cr message. Such a CSR is of form ietf-sztp-types:cmp-csr 300 from module ietf-sztp-csr. To allow PKI management entities to also 301 comply with this profile, the p10cr message must be formatted by the 302 EE as described in Section 4.1.4 of this profile, and it may be 303 forwarded as specified in Section 5.2. 305 In Bootstrapping Remote Secure Key Infrastructure (BRSKI) [RFC8995] 306 environments, BRSKI Asynchronous Enrollment BRSKI Asynchronous 307 Enrollment [I-D.ietf-anima-brski-async-enroll] describes a 308 generalization regarding the employed enrollment protocols to allow 309 alternatives to EST [RFC7030]. For the use of CMP, it requires 310 adherence to this profile. 312 1.6. Compatibility with existing CMP profiles 314 The profile specified in this document is compatible with RFC 4210 315 Appendixes D and E (PKI Management Message Profiles) [RFC4210], with 316 the following exceptions: 318 * signature-based protection is the default protection; an initial 319 PKI management operation may also use MAC-based protection, 321 * certification of a second key pair within the same PKI management 322 operation is not supported, 324 * proof-of-possession (POPO) with self-signature of the certTemplate 325 according to RFC 4211 Section 4.1 [RFC4211] clause 3 is the 326 recommended default POPO method (deviations are possible for EEs 327 when requesting central key generation, for RAs when using 328 raVerified, and if the newly generated keypair is technically not 329 capable to generate digital signatures), 331 * confirmation of newly enrolled certificates may be omitted, and 333 * all PKI management operations consist of request-response message 334 pairs originating at the EE, i.e., announcement messages 335 (requiring a push model, a CMP server on the EE) are excluded in 336 favor of a lightweight implementation on the EE. 338 The profile specified in this document is compatible with the CMP 339 profile for 3G, LTE, and 5G network domain security and 340 authentication framework [ETSI-3GPP.33.310], except that: 342 * protection of initial PKI management operations may be MAC-based, 344 * the subject field is mandatory in certificate templates, and 346 * confirmation of newly enrolled certificates may be omitted. 348 The profile specified in this document is compatible with the CMP 349 profile for on-line key management in rail networks as specified in 350 UNISIG Subset-137 [UNISIG.Subset-137], except that: 352 * A certificate enrollment request message consists of only one 353 certificate request (CertReqMsg). 355 * RFC 4210 [RFC4210] requires that the messageTime is Greenwich Mean 356 Time coded as generalizedTime. 358 Note: As UNISIG Subset-137 Table 5 [UNISIG.Subset-137] explicitly 359 states that the messageTime in required to be "UTC time", it is 360 not clear if this means a coding as UTCTime or generalizedTime and 361 if other time zones than Greenwich Mean Time shall be allowed. 362 Both time formats are described in RFC 5280 Section 4.1.2.5 363 [RFC5280]. 365 * The same type of protection is required to be used for all 366 messages of one PKI management operation. This means, in case the 367 request message protection is MAC-based, also the response, 368 certConf, and pkiConf messages must have a MAC-based protection. 370 * Use of caPubs is not required but typically allowed in combination 371 with MAC-based protected PKI management operations. On the other 372 hand UNISIG Subset-137 Table 12 [UNISIG.Subset-137] requires using 373 caPubs. 375 Note: It remains unclear from UNISIG Subset-137 for which 376 certificate(s) the caPubs field should be used. For security 377 reasons, it cannot be used for delivering the root CA certificate 378 needed for validating the signature-based protection of the given 379 response message (as stated indirectly also in its UNISIG 380 Subset-137 Section 6.3.1.5.2 b [UNISIG.Subset-137]). 382 * This profile requires that the certConf message has one CertStatus 383 element where the statusInfo field is recommended. 385 Note: In contrast, UNISIG Subset-137 Table 18 [UNISIG.Subset-137] 386 requires that the certConf message has one CertStatus element 387 where the statusInfo field must be absent. This precludes sending 388 a negative certConf message in case the EE rejects the newly 389 enrolled certificate. This results in violating the general rule 390 that a certificate request transaction must include a certConf 391 message (since moreover, using implicitConfirm is not allowed 392 there, neither). 394 1.7. Scope of this document 396 To minimize ambiguity and complexity through needless variety, this 397 document specifies exhaustive requirements on generating PKI 398 management messages on the sender side. On the other hand, it gives 399 only minimal requirements on checks by the receiving side and how to 400 handle error cases. 402 Especially on the EE side this profile aims at a lightweight 403 implementation. This means that the number of PKI management 404 operations implementations are reduced to a reasonable minimum to 405 support typical certificate management use cases in industrial 406 machine-to-machine environments. On the EE side only limited 407 resources are expected, while on the side of the PKI management 408 entities the profile accepts higher requirements. 410 For the sake of interoperability and robustness, implementations 411 should, as far as security is not affected, adhere to Postel's law: 412 "Be conservative in what you do, be liberal in what you accept from 413 others" (often reworded as: "Be conservative in what you send, be 414 liberal in what you receive"). 416 When in Section 3, Section 4, and Section 5 a field of the ASN.1 417 syntax as defined in CMP [RFC4210] and [I-D.ietf-lamps-cmp-updates], 418 CRMF [RFC4211], and CMS [RFC5652] and [RFC8933] is not explicitly 419 specified, it SHOULD not be used by the sending entity. The 420 receiving entity MUST NOT require its absence and if present MUST 421 gracefully handle its presence. 423 1.8. Structure of this document 425 Section 2 introduces the general PKI architecture and approach to 426 certificate management that is assumed in this document. Then it 427 lists the PKI management operations specified in this document, 428 partitioning them into mandatory, recommended, and optional ones. 430 Section 3 profiles the generic aspects of the PKI management 431 operations specified in detail in Section 4 and Section 5 to minimize 432 redundancy in the description and to ease implementation. This 433 covers the general structure and protection of messages, as well as 434 generic prerequisites, validation, and error handling. 436 Section 4 profiles the exchange of CMP messages between an EE and the 437 PKI management entity. There are various flavors of certificate 438 enrollment requests, optionally with polling, central key generation, 439 revocation, and general support PKI management operations. 441 Section 5 profiles responding to requests, exchange between PKI 442 management entities, and operations on behalf of other PKI entities. 443 This may include delayed delivery of messages, which involves polling 444 for responses, and nesting of messages. 446 Section 6 outlines several mechanisms for CMP message transfer, 447 including HTTP-based [RFC6712] transfer optionally using TLS, and 448 [I-D.ietf-ace-cmpv2-coap-transport] transfer optionally using DTLS, 449 and offline file-based transport. 451 1.9. Convention and Terminology 453 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 454 "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and 455 "OPTIONAL" in this document are to be interpreted as described in BCP 456 14 [RFC2119] [RFC8174] when, and only when, they appear in all 457 capitals, as shown here. 459 Technical terminology is used in conformance with RFC 4210 [RFC4210], 460 RFC 4211 [RFC4211], RFC 5280 [RFC5280], and IEEE 802.1AR 461 [IEEE.802.1AR_2018]. The following key words are used: 463 CA: Certification authority, which issues certificates. 465 RA: Registration authority, an optional PKI component to which a CA 466 delegates certificate management functions such as end entity 467 authentication and authorization checks for incoming requests. 468 An RA can also provide conversion between various certificate 469 management protocols and other protocols providing some 470 operations related to certificate management. 472 LRA: Local registration authority, a specific form of RA with 473 proximity to the end entities. 475 Note: For ease of reading, this document uses the term "RA" 476 also for LRAs in all cases where the difference is not 477 relevant. 479 KGA: Key generation authority, an optional system component, 480 typically co-located with an RA or CA, that offers key 481 generation services to end entities. 483 EE: End entity, typically a device or service that holds a public- 484 private key pair for which it manages a public-key certificate. 485 An identifier for the EE is given as the subject of its 486 certificate. 488 The following terminology is reused from RFC 4210 [RFC4210], as 489 follows: 491 PKI management operation: All CMP messages belonging to a single 492 transaction. The transaction is 493 identified by the transactionID field of 494 the message headers. 496 PKI management entity: A non-EE PKI entity, i.e., RA or CA. 498 PKI entity: An EE or PKI management entity. 500 2. Architecture and use cases 502 2.1. Solution architecture 504 To facilitate secure automatic certificate enrollment, the device 505 hosting an EE is typically equipped with a manufacturer-issued device 506 certificate. Such a certificate is typically installed during 507 production and is meant to identify the device throughout its 508 lifetime. This certificate can be used to protect the initial 509 enrollment of operational certificates after installation of the EE 510 in its operational environment. In contrast to the manufacturer- 511 issued device certificate, operational certificates are issued by the 512 owner or operator of the device to identify the device or one of its 513 components for operational use, e.g., in a security protocol like 514 IPSec, TLS, or SSH. In IEEE 802.1AR [IEEE.802.1AR_2018] a 515 manufacturer-issued device certificate is called IDevID certificate 516 and an operational certificate is called LDevID certificate. 518 Note: According to IEEE 802.1AR [IEEE.802.1AR_2018] a DevID comprises 519 the triple of the certificate, the corresponding private key, and the 520 certificate chain. 522 All certificate management operations specified in this document 523 follow the pull model, i.e., are initiated by an EE (or by an RA 524 acting as an EE). The EE creates a CMP request message, protects it 525 using some asymmetric credential or shared secret information and 526 sends it to its locally reachable PKI management entity. This PKI 527 management entity may be a CA or more typically an RA, which checks 528 the request, responds to it itself, or forwards the request upstream 529 to the next PKI management entity. In case an RA changes the CMP 530 request message header or body or wants to demonstrate successful 531 verification or authorization, it can apply a protection of its own. 532 Especially the communication between an LRA and RA can be performed 533 synchronously or asynchronously. Synchronous communication describes 534 a timely uninterrupted communication between two communication 535 partners, while asynchronous communication is not performed in a 536 timely consistent manner, e.g., because of a delayed message 537 delivery. 539 +-----+ +-----+ +-----+ +-----+ 540 | | | | | | | | 541 | EE |<---------->| LRA |<-------------->| RA |<---------->| CA | 542 | | | | | | | | 543 +-----+ +-----+ +-----+ +-----+ 545 synchronous (a)synchronous (a)synchronous 546 +----connection----+------connection------+----connection----+ 548 operators service partner 549 +---------on site--------+----back-end services-----+-trust center-+ 551 Figure 1: Certificate management architecture example 553 In operational environments the certificate management architecture 554 can have multiple LRAs bundling requests from multiple EEs at 555 dedicated locations and one (or more than one) central RA aggregating 556 the requests from the LRAs. Every LRA in this scenario has shared 557 secret information (one per EE) for MAC-based protection or a CMP 558 protection key and certificate allowing it to (re-)protect CMP 559 messages it processes. The figure above shows an architecture 560 example with at least one LRA, RA, and CA. It is also possible not 561 to have an RA or LRA or that there is no CA with a CMP interface. 562 Depending on the network infrastructure, the message transfer between 563 PKI management entities may be based on synchronous online 564 connections, asynchronous connections, or even offline (e.g., file- 565 based) transfer. 567 Note: CMP response messages could also be used proactively to 568 implement the push model towards the EE. In this case the EE acts as 569 receiver, not initiating the interaction with the PKI. Also, when 570 using a commissioning tool or a registrar agent as described in BRSKI 571 with Pledge in Responder Mode (BRSKI-PRM) [I-D.ietf-anima-brski-prm], 572 certificate enrollment in a push model is needed. CMP in general and 573 the messages specified in this profile offer all required 574 capabilities, but the message flow and state machine as described in 575 Section 4 must be adapted to implement a push model. 577 Third-party CAs may implement other variants of CMP, different 578 standardized protocols, or even proprietary interfaces for 579 certificate management. Therefore, the RA may need to adapt the 580 exchanged CMP messages to the flavor of certificate management 581 interaction required by the CA. 583 2.2. Supported PKI management operations 585 Following the scope outlined in Section 1.7, this section gives a 586 brief overview of the base PKI management operations and their 587 variants specified in Section 4 and Section 5 and states whether 588 implementation by compliant EEs or PKI management entities is 589 mandatory, recommended, or optional. Variants amend or change 590 behavior of base PKI management operations and are therefore also 591 listed here. 593 2.2.1. Mandatory PKI management operations 595 The set of mandatory PKI management operations in this document is 596 intentionally lean to help for keeping development effort low and to 597 enable use in memory-constrained devices. 599 +=====================================+=========+ 600 | PKI management operations | Section | 601 +=====================================+=========+ 602 | Requesting a certificate from a new | Section | 603 | PKI with signature-based protection | 4.1.1 | 604 +-------------------------------------+---------+ 605 | Updating an existing certificate | Section | 606 | with signature-based protection | 4.1.3 | 607 +-------------------------------------+---------+ 609 Table 1: Mandatory End Entity PKI management 610 operations 612 +===============================================+=================+ 613 | PKI management operations | Section | 614 +===============================================+=================+ 615 | Responding to a certificate request | Section 5.1 | 616 +-----------------------------------------------+-----------------+ 617 | Responding to a confirmation message | Section 5.1.3 | 618 +-----------------------------------------------+-----------------+ 619 | Forwarding messages - not changing protection | Section 5.2.1 | 620 +-----------------------------------------------+-----------------+ 621 | Adding protection to a request message | Section 5.2.2.1 | 622 +-----------------------------------------------+-----------------+ 624 Table 2: Mandatory PKI management entity operations 626 2.2.2. Recommended PKI management operations 628 Additional recommended PKI management operations support some more 629 complex scenarios, that are considered beneficial for environments 630 with more specific demand or boundary conditions. 632 +=================================+=========+ 633 | PKI management operations | Section | 634 +=================================+=========+ 635 | Requesting a certificate from a | Section | 636 | PKI with MAC-based protection | 4.1.5 | 637 +---------------------------------+---------+ 638 | Revoking a certificate | Section | 639 | | 4.2 | 640 +---------------------------------+---------+ 642 Table 3: Recommended End Entity PKI 643 management operations 645 +====================================+===============+ 646 | PKI management operations | Section | 647 +====================================+===============+ 648 | Responding to a revocation request | Section 5.1.4 | 649 +------------------------------------+---------------+ 650 | Acting on behalf of other PKI | Section 5.3.2 | 651 | entities - revoking a certificate | | 652 +------------------------------------+---------------+ 654 Table 4: Recommended PKI management entity operations 656 2.2.3. Optional PKI management operations 658 The optional PKI management operations support specific scenarios 659 seen only in some environments with specific requirements. 661 +========================================================+=========+ 662 | PKI management operations and variants | Section | 663 +========================================================+=========+ 664 | Requesting an additional certificate with signature- | Section | 665 | based protection | 4.1.2 | 666 +--------------------------------------------------------+---------+ 667 | Requesting a certificate from a legacy PKI using a | Section | 668 | PKCS#10 request | 4.1.4 | 669 +--------------------------------------------------------+---------+ 670 | Adding central key generation to a certificate | Section | 671 | request. (If central key generation is supported, the | 4.1.6 | 672 | key agreement key management technique is REQUIRED to | | 673 | be supported, and the key transport and password-based | | 674 | key management techniques are OPTIONAL.) | | 675 +--------------------------------------------------------+---------+ 676 | Support messages | Section | 677 | | 4.3 | 678 +--------------------------------------------------------+---------+ 679 | Handling delayed delivery | Section | 680 | | 4.4 | 681 +--------------------------------------------------------+---------+ 682 | Acting on behalf of other PKI entities - requesting | Section | 683 | certificates | 5.3.1 | 684 +--------------------------------------------------------+---------+ 686 Table 5: Optional End Entity PKI management operations 688 +===============================================+===============+ 689 | PKI management operations and variants | Section | 690 +===============================================+===============+ 691 | Initiating delayed delivery | Section 5.1.2 | 692 +-----------------------------------------------+---------------+ 693 | Forwarding messages - replacing protection, | Section | 694 | not changing any included proof-of-possession | 5.2.3.1 | 695 +-----------------------------------------------+---------------+ 696 | Forwarding messages - replacing protection, | Section | 697 | breaking proof-of-possession | 5.2.3.2 | 698 +-----------------------------------------------+---------------+ 699 | Batching messages | Section | 700 | | 5.2.2.2 | 701 +-----------------------------------------------+---------------+ 703 Table 6: Optional PKI management entity operations 705 2.3. CMP message transfer 707 On different links between PKI entities, e.g., EE-RA and RA-CA, 708 different transfer mechanisms MAY be used. CMP does not have 709 specific needs regarding message transfer, except that for each 710 request message sent, eventually exactly one response message should 711 be received. Thus, virtually any reliable transfer mechanism can be 712 used, e.g., HTTP, CoAP, and offline file-based transfer. Therefore, 713 this document does not require any specific transfer protocol to be 714 supported by conforming implementations. 716 HTTP transfer is RECOMMENDED to use for all PKI entities, yet full 717 flexibility is retained to choose whatever transfer mechanism is 718 suitable, for instance for devices and system architectures with 719 specific constraints. 721 +===============+=============+ 722 | Transfer | Section | 723 +===============+=============+ 724 | HTTP transfer | Section 6.1 | 725 +---------------+-------------+ 727 Table 7: Recommended 728 transfer mechanisms 730 +=========================================+=============+ 731 | Transfer | Section | 732 +=========================================+=============+ 733 | Offline transfer | Section 6.4 | 734 +-----------------------------------------+-------------+ 735 | CoAP transfer | Section 6.2 | 736 +-----------------------------------------+-------------+ 737 | Piggybacking on other reliable transfer | Section 6.3 | 738 +-----------------------------------------+-------------+ 740 Table 8: Optional transfer mechanisms 742 3. Generic aspects of the PKI message 744 This section covers the generic aspects of the PKI management 745 operations specified in Section 4 and Section 5 as upfront general 746 requirements to minimize redundancy in the description and to ease 747 implementation. 749 As described in Section 5.1 of RFC 4210 [RFC4210], all CMP messages 750 have the following general structure: 752 +--------------------------------------------+ 753 | PKIMessage | 754 | +----------------------------------------+ | 755 | | header | | 756 | +----------------------------------------+ | 757 | +----------------------------------------+ | 758 | | body | | 759 | +----------------------------------------+ | 760 | +----------------------------------------+ | 761 | | protection (OPTIONAL) | | 762 | +----------------------------------------+ | 763 | +----------------------------------------+ | 764 | | extraCerts (OPTIONAL) | | 765 | +----------------------------------------+ | 766 +--------------------------------------------+ 768 Figure 2: CMP message structure 770 The general contents of the message header, protection, and 771 extraCerts fields are specified in the following three subsections. 773 In case a specific PKI management operation needs different contents 774 in the header, protection, or extraCerts fields, the differences are 775 described in the respective subsections. 777 The CMP message body contains the PKI management operation-specific 778 information. It is described in Section 4 and Section 5. 780 The generic prerequisites needed by the PKI entities in order to be 781 able to perform PKI management operations are described in 782 Section 3.4. 784 The generic validation steps to be performed by PKI entities on 785 receiving a CMP message are described in Section 3.5. 787 The generic aspects of handling and reporting errors are described in 788 Section 3.6. 790 3.1. General description of the CMP message header 792 This section describes the generic header fields of all CMP messages 793 with signature-based protection. 795 In case a message has MAC-based protection the changes are described 796 in Section 4.1.5. The variations will affect the fields sender, 797 protectionAlg, and senderKID. 799 Any PKI management operation-specific fields or variations are 800 described in Section 4 and 5. 802 header 803 pvno REQUIRED 804 -- MUST be 3 to indicate CMP v3 in all cases where EnvelopedData 805 -- is supported and expected to be used in the current 806 -- PKI management operation 807 -- MUST be 3 to indicate CMP v3 in certConf messages when using 808 -- the hashAlg field 809 -- MUST be 2 to indicate CMP v2 in all other cases 810 -- For details on version negotiation see RFC-CMP-Updates 811 sender REQUIRED 812 -- SHOULD contain a name representing the originator of the 813 -- message; otherwise, the NULL-DN (a zero-length 814 -- SEQUENCE OF RelativeDistinguishedNames) MUST be used 815 -- SHOULD be the subject of the CMP protection certificate, i.e., 816 -- the certificate corresponding to the private key used to sign 817 -- the message 818 -- In a multi-hop scenario, the receiving entity SHOULD not rely 819 -- on the correctness of the sender field. 820 recipient REQUIRED 821 -- SHOULD be the name of the intended recipient; otherwise, the 822 -- NULL-DN MUST be used 823 -- In the first message of a PKI management operation: 824 -- SHOULD be the subject DN of the CA the PKI management 825 -- operation is requested from 826 -- In all other messages: 827 -- SHOULD contain the value of the sender field of the previous 828 -- message in the same PKI management operation 829 -- The recipient field SHALL be handled gracefully by the 830 -- receiving entity, because in a multi-hop scenario its 831 -- correctness cannot be guaranteed. 832 messageTime RECOMMENDED 833 -- MUST be the time at which the message was produced, if present 834 protectionAlg REQUIRED 835 -- MUST be an algorithm identifier indicating the algorithm 836 -- used for calculating the protection bits 837 -- If it is a signature algorithm its type MUST be a 838 -- MSG_SIG_ALG as specified in [RFC-CMP-Alg] Section 3 and 839 -- MUST be consistent with the subjectPublicKeyInfo field of 840 -- the protection certificate 841 -- If it is a MAC algorithm its type MUST be a MSG_MAC_ALG as 842 -- specified in [RFC-CMP-Alg] Section 6.1 843 senderKID RECOMMENDED 844 -- MUST be the SubjectKeyIdentifier of the CMP protection 845 -- certificate 846 transactionID REQUIRED 847 -- In the first message of a PKI management operation: 848 -- MUST be 128 bits of random data, to minimize the probability 849 -- of having the transactionID already in use at the server 850 -- In all other messages: 851 -- MUST be the value from the previous message in the same 852 -- PKI management operation 853 senderNonce REQUIRED 854 -- MUST be cryptographically secure and fresh 128 random bits 855 recipNonce RECOMMENDED 856 -- If this is the first message of a transaction: SHOULD be 857 -- absent 858 -- If this is a delayed response message: MUST be present and 859 -- contain the value of the senderNonce of the respective request 860 -- message in the same transaction 861 -- In all other messages: MUST be present and contain the value 862 -- of the senderNonce of the previous message in the same 863 -- transaction 864 generalInfo OPTIONAL 865 implicitConfirm OPTIONAL 866 -- The extension is optional in ir/cr/kur/p10cr requests and 867 -- ip/cp/kup response messages and PROHIBTED in other types of 868 -- messages 869 -- Added to request messages to request omission of the certConf 870 -- message 871 -- Added to response messages to grant omission of the certConf 872 -- message 873 -- See [RFC4210] Section 5.1.1.1. 874 ImplicitConfirmValue REQUIRED 875 -- ImplicitConfirmValue MUST be NULL 876 certProfile OPTIONAL 877 -- MAY be present in ir/cr/kur/p10cr and in genm messages of type 878 -- id-it-certReqTemplate 879 -- MUST be omitted in all other messages 880 -- See [RFC-CMP-Updates] 881 CertProfileValue REQUIRED 882 -- MUST contain exactly one UTF8String element 883 -- MUST contain the name of a certificate profile 885 3.2. General description of the CMP message protection 887 This section describes the generic protection field contents of all 888 CMP messages with signature-based protection. The private key used 889 to sign a CMP message is called "protection key" and the related 890 certificate is called "protection certificate". Any included 891 keyUsage extension SHOULD allow digitalSignature. 893 protection RECOMMENDED 894 -- MUST contain the signature calculated using the private key 895 -- of the entity protecting the message. The signature 896 -- algorithm used MUST be given in the protectionAlg field. 898 Generally, CMP message protection is required for CMP messages, but 899 there are cases where protection of error messages specified in 900 Section 3.6 is not possible and therefore MAY be omitted. 902 For MAC-based protection as specified in Section 4.1.5 major 903 differences apply as described there. 905 The CMP message protection provides, if available, message origin 906 authentication and integrity protection for the header and body. The 907 CMP message extraCerts field is not covered by this protection. 909 Note: The extended key usages described in CMP Updates 910 [I-D.ietf-lamps-cmp-updates] can be used for authorization of a 911 sending PKI management entity. 913 3.3. General description of CMP message extraCerts 915 This section describes the generic extraCerts field of all CMP 916 messages with signature-based protection. Any specific requirements 917 on the extraCerts are specified in the respective PKI management 918 operation. 920 extraCerts 921 -- SHOULD contain the CMP protection certificate together with 922 -- its chain, if needed 923 -- If present, the first certificate in this field MUST be 924 -- the CMP protection certificate followed by its chain 925 -- where each element SHOULD directly certify the one 926 -- immediately preceding it. 927 -- Self-signed certificates SHOULD be omitted from extraCerts, 928 -- unless they are the same as the protection certificate and 929 -- MUST NOT be trusted based on their inclusion in any case 931 Note: For maximum compatibility, all implementations SHOULD be 932 prepared to handle potentially additional certificates and arbitrary 933 orderings of the certificates. 935 3.4. Generic PKI management operation prerequisites 937 This subsection describes what is generally needed by the PKI 938 entities to be able to perform PKI management operations. 940 Identification of PKI entities: 942 * Each EE SHOULD know its own identity to fill the sender field. 944 * Each EE SHOULD know the intended recipient of its requests to fill 945 the recipient field, e.g., the name of the addressed CA. 947 Note: This name may be established using an enrollment voucher, 948 e.g., [RFC8366], the issuer field from a CertReqTemplate response 949 message content, or by other configuration means. 951 Routing of CMP messages: 953 * Each PKI entity sending messages upstream MUST know the address 954 needed for transferring messages to the next PKI management 955 entity. 957 Note: This address may depend on the recipient, the certificate 958 profile, and on the used transfer mechanism. 960 Authentication of PKI entities: 962 * Each PKI entity MUST have credentials to authenticate itself. For 963 signature-based protection it MUST have a private key and the 964 corresponding certificate along with its chain. 966 * Each PKI entity MUST be able to establish trust in PKI it receives 967 responses from. When signature-based protection is used, it MUST 968 have the trust anchor(s) and any certificate status information 969 needed to perform path validation of CMP protection certificates 970 used for signature-based protection. 972 Note: A trust anchor usually is a root certificate of the PKI 973 addressed by the requesting EE. It may be established by 974 configuration or in an out-of-band manner. For an EE it may be 975 established using an enrollment voucher [RFC8366] or in-band of 976 CMP by the caPubs field in a certificate response message. 978 Authorization of PKI management operations: 980 * Each EE or RA MUST have sufficient information to be able to 981 authorize the PKI management entity for performing the upstream 982 PKI management operation. 984 Note: This may be achieved for example by using the cmcRA extended 985 key usage in server certificates, by local configuration such as 986 specific name patterns for subject DN or SAN portions that may 987 identify an RA, and/or by having a dedicated PKI Infrastructure 988 root CA usable only for authenticating PKI management entities. 990 * Each PKI management entity MUST have sufficient information to be 991 able to authorize the downstream PKI entity requesting the PKI 992 management operation. 994 Note: For authorizing an RA the same examples apply as above. The 995 authorization of EEs can be very specific to the application 996 domain and may involve information from configuration or inventory 997 database. It may involve, e.g., the issuer information of the EE 998 certificate, specific contents of the CMP protection certificate 999 used by the EE such as name patterns of subject DN or SAN 1000 portions, shared secret information, and other types of 1001 credentials and evidence potentially communicated out-of-band. 1003 3.5. Generic validation of a PKI message 1005 This section describes generic validation steps of each PKI entity 1006 receiving a PKI request or response message before any further 1007 processing or forwarding. If a PKI management entity decides to 1008 terminate a PKI management operation because a check failed, it MUST 1009 send a negative response or an error message as described in 1010 Section 3.6. The PKIFailureInfo bits given below in parentheses MAY 1011 be used in the failInfo field of the PKIStatusInfo as described in 1012 Section 3.6.4, see also RFC 4210 Appendix F [RFC4210]. 1014 All PKI message header fields not mentioned in this section like the 1015 recipient and generalInfo fields SHOULD be handled gracefully on 1016 reception. 1018 The following list describes the basic set of message input 1019 validation steps. Without these checks the protocol becomes 1020 dysfunctional. 1022 * The formal ASN.1 syntax of the whole message MUST be compliant 1023 with the definitions given in CMP [RFC4210] and 1024 [I-D.ietf-lamps-cmp-updates], CRMF [RFC4211], and CMS [RFC5652] 1025 and [RFC8933]. (failInfo: badDataFormat) 1027 * The pvno MUST be cmp2000(2) or cmp2021(3). (failInfo bit: 1028 unsupportedVersion) 1030 * The transactionID MUST be present. (failInfo bit: badDataFormat) 1032 * The PKI message body type MUST be one of the message types 1033 supported by the receiving PKI entity and MUST be allowed in the 1034 current state of the PKI management operation identified by the 1035 given transactionID. (failInfo bit: badRequest) 1037 The following list describes the set of message input validation 1038 steps required to ensure secure protocol operation: 1040 * The senderNonce MUST be present and MUST contain at least 128 bits 1041 of data. (failInfo bit: badSenderNonce) 1043 * Unless the PKI message is the first message of a PKI management 1044 operation, 1046 - the recipNonce MUST be present and MUST equal the senderNonce 1047 of the previous message or equal the senderNonce of the most 1048 recent request message for which the response was delayed, in 1049 case of delayed delivery as specified in Section 4.4. (failInfo 1050 bit: badRecipientNonce) 1052 * The message protection MUST be validated: 1054 - The protection MUST be signature-based except if MAC-based 1055 protection is used as described in Section 4.1.5 and for some 1056 error messages as described in Section 3.6.4. (failInfo bit: 1057 wrongIntegrity) 1059 - The senderKID SHOULD identify the key material used for 1060 verifying the message protection. (failInfo bit: 1061 badMessageCheck) 1063 - The protection, if present, MUST be validated successfully. If 1064 signature-based protection is used, the CMP protection 1065 certificate MUST be successfully validated including path 1066 validation using a trust anchor and MUST be authorized 1067 according to local policies. If the keyUsage extension is 1068 present in the CMP protection certificate the digitalSignature 1069 bit SHOULD be set. (failInfo bit: badAlg, badMessageCheck, or 1070 signerNotTrusted) 1072 - The sender of a request message MUST be authorized for 1073 requesting the operation according to PKI policies. (failInfo 1074 bit: notAuthorized) 1076 Note: The requirements for checking certificates given in RFC 5280 1077 [RFC5280] MUST be followed for signature-based CMP message 1078 protection. Unless the message is a positive ip/cp/kup where the 1079 issuing CA certificate of the newly enrolled certificate is the same 1080 as the CMP protection certificate of that message, certificate status 1081 checking SHOULD be performed on the CMP protection certificates. 1083 Depending on local policies, one or more of the input validation 1084 checks described below need to be implemented: 1086 * If signature-based protection is used, the sender field SHOULD 1087 match the subject of the CMP protection certificate. (failInfo 1088 bit: badMessageCheck) 1090 * If the messageTime is present, it SHOULD be close to the current 1091 time. (failInfo bit: badTime) 1093 3.6. Error handling 1095 This section describes how a PKI entity handles error conditions on 1096 messages it receives. Each error condition SHOULD be logged 1097 appropriately. 1099 3.6.1. Reporting error conditions upstream 1101 An EE SHALL NOT send error messages. PKI management entities SHALL 1102 NOT send error messages in upstream direction, either. 1104 In case an EE rejects a newly issued certificate contained in an ip, 1105 cp, or kup message and implicit confirmation has not been granted, 1106 the EE MUST report this using a certConf message with "rejection" 1107 status and await the pkiConf response as described in Section 4.1.1. 1109 On all other error conditions regarding response messages, the EE or 1110 PKI management entity MUST regard the current PKI management 1111 operation as terminated with failure. The error conditions include 1113 * invalid response message header, body type, protection, or 1114 extraCerts according to the checks described in Section 3.5, 1116 * any issue detected with response message contents, 1118 * receipt of an error message from upstream, 1120 * timeout occurred while waiting for a response, 1122 * rejection of a newly issued certificate while implicit 1123 confirmation has been granted. 1125 Upstream PKI management entities will not receive any CMP message to 1126 learn that the PKI management operation has been terminated. In case 1127 they expect a further message from the EE, a connection interruption 1128 or timeout will occur. Then they also MUST regard the current PKI 1129 management operation as terminated with failure and MUST not attempt 1130 to send an error message downstream. 1132 3.6.2. Reporting error conditions downstream 1134 In case the PKI management entity detects an error condition, e.g., 1135 rejecting the request due to policy decision, in the body of an ir, 1136 cr, p10cr, kur, or rr message received from downstream, it SHOULD 1137 report the error in the specific response message, i.e., an ip, cp, 1138 kup, or rp with "rejection" status, as described in Section 4.1.1 and 1139 Section 4.2. This can also happen in case of polling. 1141 In case the PKI management entity detects any other error condition 1142 on requests, including pollReq, certConf, genm, and nested messages, 1143 received from downstream and on responses received from upstream, 1144 such as invalid message header, body type, protection, or extraCerts 1145 according to the checks described in Section 3.5 it MUST report them 1146 downstream in the form of an error message as described in 1147 Section 3.6.4. 1149 3.6.3. Handling error conditions on nested messages used for batching 1151 Batching of messages using nested messages as described in 1152 Section 5.2.2.2 requires special error handling. 1154 If the error condition is on an upstream nested message containing 1155 batched requests, it MUST not attempt to respond to the individual 1156 requests included in it. 1158 In case a PKI management entity receives an error message in response 1159 to a nested message, it must propagate the error by responding with 1160 an error message to each of the request messages contained in the 1161 nested message. 1163 In case a PKI management entity detects an error condition on the 1164 downstream nested message received in response to a nested message 1165 sent before, it MAY ignore this error condition and handle the 1166 response as described in Section 5.2.2.2. Otherwise, it MUST 1167 propagate the error by responding with an error message to each of 1168 the requests contained in the nested message it sent originally. 1170 3.6.4. Reporting error conditions 1172 When sending any kind of negative response, including error messages, 1173 a PKI entity MUST indicate the error condition in the PKIStatusInfo 1174 structure of the respective message as described below. It then MUST 1175 regard the current PKI management operation as terminated with 1176 failure. 1178 The PKIStatusInfo structure is used to report errors. It may be part 1179 of various message types, in particular: certConf, ip, cp, kup, and 1180 error. The PKIStatusInfo structure consists of the following fields: 1182 * status: Here the PKIStatus value "rejection" MUST be used. 1184 Note: When a PKI management entity indicates delayed delivery of a 1185 CMP response message to the EE with an error message as described 1186 in Section 4.4, the status "waiting" is used there. 1188 * statusString: Here any human-readable valid value for logging or 1189 to display via a user interface SHOULD be added. 1191 * failInfo: Here the PKIFailureInfo bits MAY be used in the way 1192 explained in Appendix F of RFC 4210 [RFC4210]. PKIFailureInfo 1193 bits regarding the validation described in Section 3.5 are 1194 referenced there. The PKIFailureInfo bits referenced in 1195 Section 5.1 and Section 6 are described here: 1197 - badCertId: A kur, certConf, or rr message references an unknown 1198 certificate 1200 - badPOP: An ir/cr/p10cr/kur contains an invalid proof-of- 1201 possession 1203 - certRevoked: Revocation requested for a certificate already 1204 revoked 1206 - badCertTemplate: The contents of a certificate request are not 1207 accepted, e.g., a field is missing or has a non-acceptable 1208 value or the given public key is already in use in some other 1209 certificate (depending on policy). 1211 - transactionIdInUse: This is sent by a PKI management entity in 1212 case the received request contains a transaction ID that has 1213 already been used for another transaction. An EE receiving 1214 such error message SHOULD resend the request in a new 1215 transaction using a different transaction ID. 1217 - notAuthorized: The sender of a request message is not 1218 authorized for requesting the operation. 1220 - systemUnavail: This is sent by a PKI management entity in case 1221 a back-end system is not available. 1223 - systemFailure: This is sent by a PKI management entity in case 1224 a back-end system is currently not functioning correctly. 1226 An EE receiving a systemUnavail or systemFailure failInfo SHOULD 1227 resend the request in a new transaction after some time. 1229 Detailed error message description: 1231 Error Message -- error 1233 Field Value 1235 header 1236 -- As described in Section 3.1 1238 body 1239 -- The message indicating the error that occurred 1240 error REQUIRED 1241 pKIStatusInfo REQUIRED 1242 status REQUIRED 1243 -- MUST have the value "rejection" 1244 statusString RECOMMENDED 1245 -- SHOULD be any human-readable text for debugging, logging 1246 -- or to display in a GUI 1247 failInfo OPTIONAL 1248 -- MAY be present and contain the relevant PKIFailureInfo bits 1250 protection REQUIRED 1251 -- As described in Section 3.2 1253 extraCerts OPTIONAL 1254 -- As described in Section 3.3 1256 4. End Entity PKI management operations 1258 This chapter focuses on the communication of an EE with the PKI 1259 management entity it directly talks to. Depending on the network and 1260 PKI solution, this can be an RA or directly a CA. Handling of a 1261 message by a PKI management entity is described in Section 5. 1263 The PKI management operations specified in this section cover the 1264 following: 1266 * Requesting a certificate with variations like initial enrollment, 1267 certificate updates, central key generation, and MAC-based 1268 protection 1270 * Revoking a certificate 1272 * Support messages 1274 These operations mainly specify the message body of the CMP messages 1275 and utilize the specification of the message header, protection and 1276 extraCerts as specified in Section 3. 1278 The following diagram shows the EE state machine covering all PKI 1279 management operations described in this section, including negative 1280 responses, error messages described in Section 3.6.4, as well as 1281 ip/cp/kup/error messages with status "waiting", pollReq, and pollRep 1282 messages described in Section 4.4. 1284 On receiving messages from upstream, the EE MUST perform the general 1285 validation checks described in Section 3.5. The behavior in case an 1286 error occurs is described in Section 3.6. 1288 State machine: 1289 start 1290 | 1291 | send ir/cr/p10cr/kur/rr/genm 1292 v 1293 waiting for response 1294 | 1295 +--------------------------+--------------------------+ 1296 | | | 1297 | receives ip/cp/kup with | received ip/cp/kup/error | received 1298 | status "accepted" or | with status "waiting" | rp/genp or 1299 | "grantedWithMods" | | ip/cp/kup/ 1300 | v | error 1301 | +-------> polling | with status 1302 | | | | "rejection" 1303 | | received | send | 1304 | | pollRep | pollReq | 1305 | | v | 1306 | | waiting for response | 1307 | | | | 1308 | +------------+--------+ | 1309 | | | | 1310 | received ip/cp/kup | | received | 1311 | with status "accepted" | | rp/genp or | 1312 | or "grantedWithMods" | | ip/cp/kup/error | 1313 | | | with status | 1314 +-----------+--------------+ | "rejection" | 1315 | | | 1316 +-----------+-----+ | | 1317 | | | | 1318 | implicitConfirm | implicitConfirm | | 1319 | granted | not granted | | 1320 | | | | 1321 | | send certConf | | 1322 | v | | 1323 | waiting for pkiConf*) | | 1324 | | | | 1325 | | received | | 1326 | | pkiConf | | 1327 +-----------------+-----------------+-----------------+ 1328 | 1329 v 1330 end 1332 *) in case of a delayed delivery of pkiConf responses the same 1333 polling mechanism is initiated as for rp or genp messages, by sending 1334 an error message with status "waiting". 1336 Note: All CMP messages belonging to the same PKI management operation 1337 MUST have the same transactionID because the message receiver 1338 identifies the elements of the operation in this way. 1340 This section is aligned with CMP [RFC4210], CMP Updates 1341 [I-D.ietf-lamps-cmp-updates], and CMP Algorithms 1342 [I-D.ietf-lamps-cmp-algorithms]. 1344 Guidelines as well as an algorithm use profile for this document are 1345 available in CMP Algorithms [I-D.ietf-lamps-cmp-algorithms]. 1347 4.1. Requesting a new certificate from a PKI 1349 There are various approaches for requesting a certificate from a PKI. 1351 These approaches differ in the way the EE authenticates itself to the 1352 PKI, in the form of the request being used, and how the key pair to 1353 be certified is generated. The authentication mechanisms may be as 1354 follows: 1356 * Using a certificate from an external PKI, e.g., a manufacturer- 1357 issued device certificate, and the corresponding private key 1359 * Using a private key and certificate issued from the same PKI that 1360 is addressed for requesting a certificate 1362 * Using the certificate to be updated and the corresponding private 1363 key 1365 * Using shared secret information known to the EE and the PKI 1366 management entity 1368 An EE requests a certificate indirectly or directly from a CA. When 1369 the PKI management entity handles the request as described in 1370 Section 5.1.1 and responds with a message containing the requested 1371 certificate, the EE MUST reply with a confirmation message unless 1372 implicitConfirm was granted. The PKI management entity then MUST 1373 handle it as described in Section 5.1.3 and respond with a 1374 confirmation, closing the PKI management operation. 1376 The message sequences described in this section allow the EE to 1377 request certification of a locally or centrally generated public- 1378 private key pair. Typically, the EE provides a signature-based 1379 proof-of-possession of the private key associated with the public key 1380 contained in the certificate request as defined by RFC 4211 1381 Section 4.1 [RFC4211] case 3. To this end it is assumed that the 1382 private key can technically be used for signing. This is the case 1383 for the most common algorithms RSA and ECDSA, regardless of 1384 potentially intended restrictions of the key usage. 1386 Note: In conformance with NIST SP 800-57 Part 1 Section 8.1.5.1.1.2 1387 [NIST.SP.800-57p1r5] the newly generated private key MAY be used for 1388 self-signature, if technically possible, even if the keyUsage 1389 extension requested in the certificate request prohibits generation 1390 of digital signatures. 1392 The requesting EE provides the binding of the proof-of-possession to 1393 its identity by signature-based or MAC-based protection of the CMP 1394 request message containing that POP. As detailed in Section 5.1.1 1395 and Section 5.1.2, an upstream PKI management entity should verify 1396 whether this EE is authorized to obtain a certificate with the 1397 requested subject and other fields and extensions. 1399 The EE MAY indicate the certificate profile to use in the certProfile 1400 extension of the generalInfo field in the PKIHeader of the 1401 certificate request message as described in Section 3.1. 1403 In case the EE receives a CA certificate in the caPubs field for 1404 installation as a new trust anchor, it MUST properly authenticate the 1405 message and authorize the sender as trusted source of the new trust 1406 anchor. This authorization is typically indicated using shared 1407 secret information for protecting an initialization response (ir) 1408 message. Authorization can also be signature-based using a 1409 certificate issued by another PKI that is explicitly authorized for 1410 this purpose. A certificate received in caPubs MUST NOT be accepted 1411 as trust anchor if the CMP message has been protected using a 1412 certificate issued by this same CA or one of its subordinate CAs. 1414 4.1.1. Requesting a certificate from a new PKI with signature-based 1415 protection 1417 This PKI management operation should be used by an EE to request a 1418 certificate from a new PKI using an existing certificate from an 1419 external PKI, e.g., a manufacturer-issued IDevID certificate 1420 [IEEE.802.1AR_2018], to authenticate itself to the new PKI. 1422 Note: In Bootstrapping Remote Secure Key Infrastructure (BRSKI) 1423 [RFC8995] environments, BRSKI Asynchronous Enrollment (BRSKI-AE) 1424 [I-D.ietf-anima-brski-async-enroll] describes a generalization 1425 regarding enrollment protocols alternative to EST [RFC7030]. As 1426 replacement of EST simpleenroll, BRSKI-AE uses this PKI management 1427 operation for bootstrapping LDevID certificates. 1429 Specific prerequisites augmenting the prerequisites in Section 3.4: 1431 * The certificate of the EE MUST have been enrolled by an external 1432 PKI, e.g., a manufacturer-issued device certificate. 1434 * The PKI management entity MUST have the trust anchor of the 1435 external PKI. 1437 * When using the generalInfo field certProfile, the EE MUST know the 1438 identifier needed to indicate the requested certificate profile. 1440 Message flow: 1442 Step# EE PKI management entity 1443 1 format ir 1444 2 -> ir -> 1445 3 handle or 1446 forward ir 1447 4 format or receive ip 1448 5 possibly grant 1449 implicitConfirm 1450 6 <- ip <- 1451 7 handle ip 1453 ----------------- if implicitConfirm not granted ----------------- 1455 8 format certConf 1456 9 -> certConf -> 1457 10 handle or 1458 forward certConf 1459 11 format or receive pkiConf 1460 12 <- pkiConf <- 1461 13 handle pkiConf 1463 For this PKI management operation, the EE MUST include exactly one 1464 CertReqMsg in the ir. If more certificates are required, further 1465 requests MUST be sent using separate PKI management operation. If 1466 the EE wants to omit sending a certificate confirmation message after 1467 receiving the ip, e.g., to reduce the number of protocol messages 1468 exchanged in this PKI management operation, it MUST request this by 1469 including the implicitConfirm extension in the header of the ir 1470 message, see Section 3.1. 1472 If the EE did not request implicit confirmation or timplicit 1473 confirmation was not granted by the PKI management entity, 1474 certificate confirmation MUST be performed as follows. If the EE 1475 successfully received the certificate, it MUST send a certConf 1476 message in due time. On receiving a valid certConf message, the PKI 1477 management entity MUST respond with a pkiConf message. If the PKI 1478 management entity does not receive the expected certConf message in 1479 time it MUST handle this like a rejection by the EE. In case of 1480 rejection the PKI management entity SHALL terminate the PKI 1481 management operation, and the PKI MAY revoke the newly issued 1482 certificate. 1484 If the certificate request was rejected by the CA, the PKI management 1485 entity must return an ip message containing the status code 1486 "rejection" as described in Section 3.6 and no certifiedKeyPair 1487 field. The EE MUST NOT react to such an ip message with a certConf 1488 message and the PKI management operation MUST be terminated. 1490 Detailed message description: 1492 Initialization Request -- ir 1494 Field Value 1496 header 1497 -- As described in Section 3.1 1499 body 1500 -- The request of the EE for a new certificate 1501 ir REQUIRED 1502 -- MUST contain exactly one CertReqMsg 1503 -- If more certificates are required, further PKI management 1504 -- operations MUST be initiated 1505 certReq REQUIRED 1506 certReqId REQUIRED 1507 -- MUST be 0 1508 certTemplate REQUIRED 1509 version OPTIONAL 1510 -- MUST be 2 if supplied 1511 subject REQUIRED 1512 -- The EE subject name MUST be carried in the subject field 1513 -- and/or the subjectAltName extension. 1514 -- If subject name is present only in the subjectAltName 1515 -- extension, then the subject field MUST be a NULL-DN 1516 publicKey REQUIRED 1517 algorithm REQUIRED 1518 -- MUST include the subject public key algorithm identifier 1519 subjectPublicKey REQUIRED 1520 -- MUST contain the public key to be certified in case of local 1521 -- key generation 1522 extensions OPTIONAL 1523 -- MAY include end-entity-specific X.509 extensions of the 1524 -- requested certificate like subject alternative name, key 1525 -- usage, and extended key usage 1526 -- The subjectAltName extension MUST be present if the EE subject 1527 -- name includes a subject alternative name. 1528 popo OPTIONAL 1529 -- MUST be present if local key generation is used 1530 -- MUST be absent if central key generation is requested 1531 signature RECOMMENDED 1532 -- MUST be used by an EE if the key can be used for signing and 1533 -- has the type POPOSigningKey 1534 poposkInput PROHIBITED 1535 -- MUST NOT be used; it is not needed because subject and 1536 -- publicKey are both present in the certTemplate 1537 algorithmIdentifier REQUIRED 1538 -- The signature algorithm MUST be consistent with the publicKey 1539 -- algorithm field of the certTemplate 1540 signature REQUIRED 1541 -- MUST contain the signature value computed over the DER-encoded 1542 -- certTemplate 1543 raVerified OPTIONAL 1544 -- MAY be used by an RA after verifying the proof-of-possession 1545 -- provided by the EE 1547 protection REQUIRED 1548 -- As described in Section 3.2 1550 extraCerts REQUIRED 1551 -- As described in Section 3.3 1553 Initialization Response -- ip 1555 Field Value 1557 header 1558 -- As described in Section 3.1 1560 body 1561 -- The response of the CA to the request as appropriate 1562 ip REQUIRED 1563 caPubs OPTIONAL 1564 -- MAY be used if the certifiedKeyPair field is present 1565 -- If used it MUST contain only a trust anchor, e.g. root 1566 -- certificate, of the certificate contained in certOrEncCert 1567 response REQUIRED 1568 -- MUST contain exactly one CertResponse 1569 certReqId REQUIRED 1570 -- MUST be 0 1571 status REQUIRED 1572 -- PKIStatusInfo structure MUST be present 1573 status REQUIRED 1574 -- positive values allowed: "accepted", "grantedWithMods" 1575 -- negative values allowed: "rejection" 1576 -- "waiting" only allowed with polling use case as described in 1577 -- Section 4.4 1578 statusString OPTIONAL 1579 -- MAY be any human-readable text for debugging, logging or to 1580 -- display in a GUI 1581 failInfo OPTIONAL 1582 -- MAY be present if status is "rejection" 1583 -- MUST be absent if status is "accepted" or "grantedWithMods" 1584 certifiedKeyPair OPTIONAL 1585 -- MUST be present if status is "accepted" or "grantedWithMods" 1586 -- MUST be absent if status is "rejection" 1587 certOrEncCert REQUIRED 1588 -- MUST be present if status is "accepted" or "grantedWithMods" 1589 certificate REQUIRED 1590 -- MUST be present when certifiedKeyPair is present 1591 -- MUST contain the newly enrolled X.509 certificate 1592 privateKey OPTIONAL 1593 -- MUST be absent in case of local key generation or "rejection" 1594 -- MUST contain the encrypted private key in an EnvelopedData 1595 -- structure as specified in Section 4.1.6 in case the private 1596 -- key was generated centrally 1598 protection REQUIRED 1599 -- As described in Section 3.2 1601 extraCerts REQUIRED 1602 -- As described in Section 3.3 1603 -- MUST contain the chain of the certificate present in 1604 -- certOrEncCert 1605 -- Self-signed certificates SHOULD be omitted 1606 -- Duplicate certificates MAY be omitted 1608 Certificate Confirmation -- certConf 1610 Field Value 1612 header 1613 -- As described in Section 3.1 1615 body 1616 -- The message of the EE sends as confirmation to the PKI 1617 -- management entity to accept or reject the issued certificates 1618 certConf REQUIRED 1619 -- MUST contain exactly one CertStatus 1620 CertStatus REQUIRED 1621 certHash REQUIRED 1622 -- MUST be the hash of the certificate, using the hash algorithm 1623 -- indicated in hashAlg, see below, or the same one as used to 1624 -- create the certificate signature 1625 certReqId REQUIRED 1626 -- MUST be 0 1627 statusInfo RECOMMENDED 1628 -- PKIStatusInfo structure SHOULD be present 1629 -- Omission indicates acceptance of the indicated certificate 1630 status REQUIRED 1631 -- positive values allowed: "accepted" 1632 -- negative values allowed: "rejection" 1633 statusString OPTIONAL 1634 -- MAY be any human-readable text for debugging, logging, or to 1635 -- display in a GUI 1636 failInfo OPTIONAL 1637 -- MAY be present if status is "rejection" 1638 -- MUST be absent if status is "accepted" 1639 hashAlg OPTIONAL 1640 -- The hash algorithm to use for calculating certHash 1641 -- SHOULD NOT be used in all cases where the AlgorithmIdentifier 1642 -- of the certificate signature specifies a hash algorithm 1643 -- If used, the pvno field in the header MUST be cmp2021 (3) 1645 protection REQUIRED 1646 -- As described in Section 3.2 1647 -- MUST use the same credentials as in the first request message 1648 -- of this PKI management operation 1650 extraCerts RECOMMENDED 1651 -- As described in Section 3.3 1652 -- MAY be omitted if the message size is critical and 1653 -- the PKI management entity caches the extraCerts from the 1654 -- first request message of this PKI management operation 1656 PKI Confirmation -- pkiConf 1658 Field Value 1660 header 1661 -- As described in Section 3.1 1663 body 1664 pkiconf REQUIRED 1665 -- The content of this field MUST be NULL 1667 protection REQUIRED 1668 -- As described in Section 3.2 1669 -- MUST use the same credentials as in the first response 1670 -- message of this PKI management operation 1672 extraCerts RECOMMENDED 1673 -- As described in Section 3.3 1674 -- MAY be omitted if the message size is critical and the EE has 1675 -- cached the extraCerts from the first response message of 1676 -- this PKI management operation 1678 4.1.2. Requesting an additional certificate with signature-based 1679 protection 1681 This PKI management operation should be used by an EE to request an 1682 additional certificate of the same PKI it already has certificates 1683 from. The EE uses one of these existing certificates to authenticate 1684 itself by signing its request messages using the respective private 1685 key. 1687 Specific prerequisites augmenting the prerequisites in Section 3.4: 1689 * The certificate used by the EE MUST have been enrolled by the PKI 1690 it requests another certificate from. 1692 * When using the generalInfo field certProfile, the EE MUST know the 1693 identifier needed to indicate the requested certificate profile. 1695 The message sequence for this PKI management operation is identical 1696 to that given in Section 4.1.1, with the following changes: 1698 1 The body of the first request and response SHOULD be cr and cp, 1699 respectively. 1701 Note: Since the difference between ir/ip and cr/cp is 1702 syntactically not essential, an ir/ip MAY be used in this PKI 1703 management operation. 1705 2 The caPubs field in the certificate response message SHOULD be 1706 absent. 1708 4.1.3. Updating an existing certificate with signature protection 1710 This PKI management operation should be used by an EE to request an 1711 update for one of its certificates that is still valid. The EE uses 1712 the certificate it wishes to update as the protection certificate. 1713 Both for authenticating itself and for proving ownership of the 1714 certificate to be updated, it signs the request messages with the 1715 corresponding private key. 1717 Specific prerequisites augmenting the prerequisites in Section 3.4: 1719 * The certificate the EE wishes to update MUST NOT be expired or 1720 revoked and MUST have been issued by the addressed CA. 1722 * A new public-private key pair SHOULD be used. 1724 * When using the generalInfo field certProfile, the EE MUST know the 1725 identifier needed to indicate the requested certificate profile. 1727 The message sequence for this PKI management operation is identical 1728 to that given in Section 4.1.1, with the following changes: 1730 1 The body of the first request and response MUST be kur and kup, 1731 respectively. 1733 2 Protection of the kur MUST be performed using the certificate to 1734 be updated. 1736 3 The subject field and/or the subjectAltName extension of the 1737 certTemplate MUST contain the EE subject name of the existing 1738 certificate to be updated, without modifications. 1740 4 The certTemplate SHOULD contain the subject and/or subjectAltName 1741 extension and publicKey of the EE only. 1743 5 The oldCertId control MAY be used to make clear which certificate 1744 is to be updated. 1746 6 The caPubs field in the kup message MUST be absent. 1748 As part of the certReq structure of the kur the oldCertId control is 1749 added after the certTemplate field. 1751 controls 1752 type RECOMMENDED 1753 -- MUST be the value id-regCtrl-oldCertID, if present 1754 value 1755 issuer REQUIRED 1756 serialNumber REQUIRED 1757 -- MUST contain the issuer and serialNumber of the certificate 1758 -- to be updated 1760 4.1.4. Requesting a certificate from a legacy PKI using a PKCS#10 1761 request 1763 This PKI management operation can be used by an EE to request a 1764 certificate using a legacy PKCS#10 [RFC2986] request instead of CRMF 1765 [RFC4211]. This offers a variation of the PKI management operations 1766 specified in Section 4.1.2. 1768 In Secure Zero Touch Provisioning (SZTP) [RFC8572] environments, 1769 SZTP-CSR [I-D.ietf-netconf-sztp-csr] describes the use of a CMP p10cr 1770 message as a form of certificate signing request (CSR) to optionally 1771 include in device bootstrapping to obtain an identity certificate as 1772 part of the onboarding information. Such a CSR is of form ietf-sztp- 1773 types:cmp-csr from module ietf-sztp-csr. The requirements given 1774 below on p10cr message MUST be adhered to. 1776 In this PKI management operation, the public key and all further 1777 certificate template data MUST be contained in the subjectPKInfo and 1778 other certificationRequestInfo fields of the PKCS#10 structure. 1780 The prerequisites are the same as given in Section 4.1.2. 1782 The message sequence for this PKI management operation is identical 1783 to that given in Section 4.1.2, with the following changes: 1785 1 The body of the first request and response MUST be p10cr and cp, 1786 respectively. 1788 2 The certReqId in the cp message MUST be -1. 1790 3 The caPubs field in the cp message SHOULD be absent. 1792 Detailed description of the p10cr message: 1794 Certification Request -- p10cr 1796 Field Value 1798 header 1799 -- As described in Section 3.1 1801 body 1802 -- The request of the EE for a new certificate using a PKCS#10 1803 -- certificate request 1804 p10cr REQUIRED 1805 certificationRequestInfo REQUIRED 1806 version REQUIRED 1807 -- MUST be 0 to indicate PKCS#10 V1.7 1808 subject REQUIRED 1809 -- The EE subject name MUST be carried in the subject field 1810 -- and/or the subjectAltName extension. 1811 -- If subject name is present only in the subjectAltName 1812 -- extension, then the subject field MUST be a NULL-DN 1813 subjectPKInfo REQUIRED 1814 algorithm REQUIRED 1815 -- MUST include the subject public key algorithm identifier 1816 subjectPublicKey REQUIRED 1817 -- MUST include the public key to be certified 1818 attributes OPTIONAL 1819 -- MAY include end-entity-specific X.509 extensions of the 1820 -- requested certificate like subject alternative name, 1821 -- key usage, and extended key usage 1822 -- The subjectAltName extension MUST be present if the EE 1823 -- subject name includes a subject alternative name. 1824 signatureAlgorithm REQUIRED 1825 -- The signature algorithm MUST be consistent with the 1826 -- subjectPKInfo field. 1827 signature REQUIRED 1828 -- MUST contain the self-signature for proof-of-possession 1830 protection REQUIRED 1831 -- As described for the underlying PKI management operation 1833 extraCerts REQUIRED 1834 -- As described for the underlying PKI management operation 1836 4.1.5. Requesting a certificate from a PKI with MAC-based protection 1838 This is a variant of the PKI management operations described in 1839 Section 4.1.1 to Section 4.1.4. It should be used by an EE to 1840 request a certificate of a new PKI in case it does not have a 1841 certificate to prove its identity to the target PKI, but has some 1842 secret information shared with the PKI management entity. Therefore, 1843 the request and response messages are MAC-protected using this shared 1844 secret information. The distribution of this shared secret is out of 1845 scope for this document. The PKI management entity checking the MAC- 1846 based protection SHOULD replace this protection according to 1847 Section 5.2.3 in case the next hop does not know the shared secret 1848 information. 1850 Note: The entropy of the shared secret information is crucial for the 1851 level of protection when using MAC-based protection. Further 1852 guidance is available in the security considerations of CMP updated 1853 by [I-D.ietf-lamps-cmp-updates]. 1855 Specific prerequisites augmenting the prerequisites in Section 3.4: 1857 * Rather than using private keys, certificates, and trust anchors, 1858 the EE and the PKI management entity MUST share secret 1859 information. 1861 Note: The shared secret information MUST be established out-of- 1862 band, e.g., by a service technician during initial local 1863 configuration. 1865 * When using the generalInfo field certProfile, the EE MUST know the 1866 identifier needed to indicate the requested certificate profile. 1868 The message sequence for this PKI management operation is identical 1869 to that given in Section 4.1.1, with the following changes: 1871 1 The protection of all messages MUST be MAC-based. 1873 2 The senderKID MUST contain a reference the recipient can use to 1874 identify the shared secret information used for the protection, 1875 e.g., the username of the EE. 1877 3 The extraCerts of all messages does not contain CMP protection 1878 certs and associated chains. 1880 See Section 6 of CMP Algorithms [I-D.ietf-lamps-cmp-algorithms] for 1881 details on message authentication code algorithms (MSG_MAC_ALG) to 1882 use. Typically, parameters are part of the protectionAlg field, 1883 e.g., used for key derivation, like a salt and an iteration count. 1884 Such fields SHOULD remain constant for message protection throughout 1885 this PKI management operation to reduce the computational overhead. 1887 4.1.6. Adding central key pair generation to a certificate request 1889 This is a variant of the PKI management operations described in 1890 Section 4.1.1 to Section 4.1.4 and the variant described in 1891 Section 4.1.5. It needs to be used in case an EE is not able to 1892 generate its new public-private key pair itself or central generation 1893 of the EE key material is preferred. It is a matter of the local 1894 implementation which PKI management entity will act as Key Generation 1895 Authority (KGA) and perform the key generation. This PKI management 1896 entity MUST use a certificate containing the additional extended key 1897 usage extension id-kp-cmKGA in order to be accepted by the EE as a 1898 legitimate key generation authority. 1900 As described in Section 5.3.1, the KGA can use one of the PKI 1901 management operations described in the sections above to request the 1902 certificate for this key pair on behalf of the EE. 1904 Generally speaking, in machine-to-machine scenarios it is strongly 1905 preferable to generate public-private key pairs locally at the EE. 1906 Together with proof-of-possession of the private key in the 1907 certificate request, this is advisable to make sure that the entity 1908 identified in the newly issued certificate is the only entity that 1909 knows the private key. 1911 Reasons for central key generation may include the following: 1913 * Lack of sufficient initial entropy. 1915 Note: Good random numbers are needed not only for key generation 1916 but also for session keys and nonces in any security protocol. 1917 Therefore, a decent security architecture should anyways support 1918 good random number generation on the EE side or provide enough 1919 initial entropy for the RNG seed to guarantee good pseudo-random 1920 number generation. Yet maybe this is not the case at the time of 1921 requesting an initial certificate during manufacturing. 1923 * Lack of computational resources, in particular for RSA key 1924 generation. 1926 Note: Since key generation could be performed in advance to the 1927 certificate enrollment communication, it is often not time 1928 critical. 1930 Note: As mentioned in Section 2.1, central key generation may be 1931 required in a push model, where the certificate response message is 1932 transferred by the PKI management entity to the EE without a previous 1933 request message. 1935 The EE requesting central key generation MUST omit the publicKey 1936 field from the certTemplate or, in case it has a preference on the 1937 key type to be generated, provide it in the algorithm sub-field and 1938 fill the subjectPublicKey sub-field with a zero-length BIT STRING. 1939 Both variants indicate to the PKI management entity that a new key 1940 pair shall be generated centrally on behalf of the EE. 1942 Note: As the protection of centrally generated keys in the response 1943 message has been extended to EncryptedKey by CMP Updates 1944 [I-D.ietf-lamps-cmp-updates], EnvelopedData is the preferred 1945 alternative to EncryptedValue. In CRMF Section 2.1.9 [RFC4211] the 1946 use of EncryptedValue has been deprecated in favor of the 1947 EnvelopedData structure. Therefore, this profile requires using 1948 EnvelopedData as specified in CMS Section 6 [RFC5652]. When 1949 EnvelopedData is to be used in a PKI management operation, CMP v3 1950 MUST be indicated in the message header already for the initial 1951 request message, see Section 7 of CMP Updates 1952 [I-D.ietf-lamps-cmp-updates]. 1954 +----------------------------------+ 1955 | EnvelopedData | 1956 | [RFC5652] section 6 | 1957 | +------------------------------+ | 1958 | | SignedData | | 1959 | | [RFC5652] section 5 | | 1960 | | +--------------------------+ | | 1961 | | | AsymmetricKeyPackage | | | 1962 | | | [RFC5958] | | | 1963 | | | +----------------------+ | | | 1964 | | | | privateKey | | | | 1965 | | | | OCTET STRING | | | | 1966 | | | +----------------------+ | | | 1967 | | +--------------------------+ | | 1968 | +------------------------------+ | 1969 +----------------------------------+ 1971 Figure 3: Encrypted private key container 1973 The PKI management entity delivers the private key in the privateKey 1974 field in the certifiedKeyPair structure of the response message also 1975 containing the newly issued certificate. 1977 The private key MUST be provided as an AsymmetricKeyPackage structure 1978 as defined in RFC 5958 [RFC5958]. 1980 This AsymmetricKeyPackage structure MUST be wrapped in a SignedData 1981 structure, as specified in CMS Section 5 [RFC5652] and [RFC8933], 1982 signed by the KGA generating the key pair. The signature MUST be 1983 performed using a private key related to a certificate asserting the 1984 extended key usage id-kp-cmKGA as described in CMP Updates 1985 [I-D.ietf-lamps-cmp-updates] to demonstrate authorization to generate 1986 key pairs on behalf of an EE. The EE SHOULD verify the presence of 1987 this extended key usage in the SignedData structure. 1989 Note: When using password-based key management technique as described 1990 in Section 4.1.6.3 it may not be possible or meaningful to the EE to 1991 validate the KGA signature in the SignedData structure since shared 1992 secret information is used for initial authentication. In this case 1993 the EE MAY omit this signature validation. 1995 The SignedData structure MUST be wrapped in an EnvelopedData 1996 structure, as specified in CMS Section 6 [RFC5652], encrypting it 1997 using a newly generated symmetric content-encryption key. 1999 This content-encryption key MUST be securely provided as part of the 2000 EnvelopedData structure to the EE using one of three key management 2001 techniques. The choice of the key management technique to be used by 2002 the PKI management entity depends on the authentication mechanism the 2003 EE chose to protect the request message. See CMP Updates section 2.8 2004 [I-D.ietf-lamps-cmp-updates] for more details on which key management 2005 technique to use. 2007 * Signature-based protection of the request message: 2009 - The content-encryption key SHALL be protected using the key 2010 agreement key management technique, see Section 4.1.6.1, if the 2011 certificate used by the EE for protecting the request message 2012 allows the key usage keyAgreement. If the certificate also 2013 allows the key usage keyEncipherment, the key transport key 2014 management technique SHALL NOT be used. 2016 - The content-encryption key SHALL be protected using the key 2017 transport key management technique, see Section 4.1.6.2, if the 2018 certificate used by the EE for protecting the respective 2019 request message allows the key usage keyEncipherment but not 2020 keyAgreement. 2022 * MAC-based protected of the request message: 2024 - The content-encryption key SHALL be protected using the 2025 password-based key management technique, see Section 4.1.6.3, 2026 if and only if the EE used MAC-based protection for the request 2027 message. 2029 If central key generation is supported, support of the key agreement 2030 key management technique is REQUIRED and support of key transport and 2031 password-based key management techniques are OPTION, for two reasons: 2032 The key agreement key management technique is supported by most 2033 asymmetric algorithms, while the key transport key management 2034 technique is supported only by a very few of them. The password- 2035 based key management technique shall only be used in combination with 2036 MAC-based protection, which is a sideline in this document. 2038 Specific prerequisites augmenting those of the respective certificate 2039 enrollment PKI management operations: 2041 * If signature-based protection is used, the EE MUST be able to 2042 authenticate and authorize the KGA, using suitable information, 2043 which includes a trust anchor. 2045 * If MAC-based protection is used, the KGA MUST also know the shared 2046 secret information to protect the encrypted transport of the newly 2047 generated key pair. Consequently, the EE can also authorize the 2048 KGA. 2050 * The PKI management entity MUST have a certificate containing the 2051 additional extended key usage extension id-kp-cmKGA for signing 2052 the SignedData structure containing the private key package. 2054 * For encrypting the SignedData structure a fresh content-encryption 2055 key to be used by the symmetric encryption algorithm MUST be 2056 generated with sufficient entropy. 2058 Note: The security strength of the protection of the generated 2059 private key should be similar or higher than the security strength 2060 of the generated private key. 2062 The detailed description of the privateKey field as follows: 2064 privateKey OPTIONAL 2065 -- MUST be an EnvelopedData structure as specified in CMS 2066 -- Section 6 [RFC5652] 2067 version REQUIRED 2068 -- MUST be 2 for recipientInfo type KeyAgreeRecipientInfo and 2069 -- KeyTransRecipientInfo 2070 -- MUST be 0 for recipientInfo type PasswordRecipientInfo 2071 recipientInfos REQUIRED 2072 -- MUST contain exactly one RecipientInfo, which MUST be 2073 -- kari of type KeyAgreeRecipientInfo (see section 4.1.6.1), 2074 -- ktri of type KeyTransRecipientInfo (see section 4.1.6.2), or 2075 -- pwri of type PasswordRecipientInfo (see section 4.1.6.3) 2076 encryptedContentInfo 2077 REQUIRED 2078 contentType REQUIRED 2079 -- MUST be id-signedData 2080 contentEncryptionAlgorithm 2081 REQUIRED 2082 -- MUST be the algorithm identifier of the algorithm used for 2083 -- content encryption 2084 -- The algorithm type MUST be a PROT_SYM_ALG as specified in 2085 -- RFC-CMP-Alg Section 5 2086 encryptedContent REQUIRED 2087 -- MUST be the SignedData structure as specified in CMS 2088 -- Section 5 [RFC5652] and [RFC8933] in encrypted form 2089 version REQUIRED 2090 -- MUST be 3 2091 digestAlgorithms 2092 REQUIRED 2093 -- MUST contain exactly one AlgorithmIdentifier element 2094 -- MUST be the algorithm identifier of the digest algorithm 2095 -- used for generating the signature and match the signature 2096 -- algorithm specified in signatureAlgorithm, see and [RFC8933] 2097 encapContentInfo 2098 REQUIRED 2099 -- MUST contain the content that is to be signed 2100 eContentType REQUIRED 2101 -- MUST be id-ct-KP-aKeyPackage as specified in [RFC5958] 2102 eContent REQUIRED 2103 -- MUST be of type AsymmetricKeyPackage and 2104 -- MUST contain exactly one OneAsymmetricKey element 2105 version REQUIRED 2106 -- MUST be 1 (indicating v2) 2107 privateKeyAlgorithm 2108 REQUIRED 2109 -- The privateKeyAlgorithm field MUST contain the algorithm 2110 -- identifier of the asymmetric key pair algorithm 2111 privateKey 2112 REQUIRED 2113 publicKey 2114 REQUIRED 2115 -- MUST contain the public key corresponding to the private key 2116 -- for simplicity and consistency with v2 of OneAsymmetricKey 2117 certificates REQUIRED 2119 -- MUST contain the certificate for the private key used to sign 2120 -- the signedData content, together with its chain 2121 -- The first certificate in this field MUST be the KGA 2122 -- certificate used for protecting this content 2123 -- Self-signed certificates SHOULD NOT be included and MUST NOT 2124 -- be trusted based on their inclusion in any case 2125 signerInfos REQUIRED 2126 -- MUST contain exactly one SignerInfo element 2127 version REQUIRED 2128 -- MUST be 3 2129 sid REQUIRED 2130 subjectKeyIdentifier 2131 REQUIRED 2132 -- MUST be the subjectKeyIdentifier of the KGA certificate 2133 digestAlgorithm 2134 REQUIRED 2135 -- MUST be the same as in digestAlgorithms 2136 signedAttrs REQUIRED 2137 -- MUST contain an id-contentType attribute containing the value 2138 -- id-ct-KP-aKeyPackage 2139 -- MUST contain an id-messageDigest attribute containing the 2140 -- message digest of eContent 2141 -- MAY contain an id-signingTime attribute containing the time 2142 -- of signature 2143 -- For details on the signed attributes see CMS Section 5.3 and 2144 -- Section 11 [RFC5652] and [RFC8933] 2145 signatureAlgorithm 2146 REQUIRED 2147 -- MUST be the algorithm identifier of the signature algorithm 2148 -- used for calculation of the signature bits 2149 -- The signature algorithm type MUST be a MSG_SIG_ALG as 2150 -- specified in RFC-CMP-Alg Section 3 and MUST be consistent 2151 -- with the subjectPublicKeyInfo field of the KGA certificate 2152 signature REQUIRED 2153 -- MUST be the digital signature of the encapContentInfo 2155 NOTE: As stated in Section 1.5, all fields of the ASN.1 syntax that 2156 are defined in RFC 5652 [RFC5652] but are not explicitly specified 2157 here SHOULD NOT be used. 2159 4.1.6.1. Using key agreement key management technique 2161 This variant can be applied in combination with the PKI management 2162 operations specified in Section 4.1.1 to Section 4.1.3 using 2163 signature-based protection of CMP messages. The EE certificate used 2164 for the signature-based protection of the request message MUST allow 2165 for the key usage "keyAgreement" and therefore, the related key pair 2166 MUST be used for establishment of the content-encryption key. For 2167 this key management technique the KeyAgreeRecipientInfo structure 2168 MUST be used in the contentInfo field. 2170 The KeyAgreeRecipientInfo structure included into the EnvelopedData 2171 structure is specified in CMS Section 6.2.2 [RFC5652]. 2173 The detailed description of the KeyAgreeRecipientInfo structure looks 2174 like this: 2176 kari REQUIRED 2177 -- MUST be a KeyAgreeRecipientInfo as specified in CMS Section 2178 -- 6.2.2 [RFC5652] 2179 version REQUIRED 2180 -- MUST be 3 2181 originator REQUIRED 2182 -- MUST contain the originatorKey choice 2183 algorithm REQUIRED 2184 -- MUST be the algorithm identifier of the key agreement 2185 -- algorithm 2186 -- The algorithm type MUST be a KM_KA_ALG as specified in 2187 -- RFC-CMP-Alg Section 4.1 2188 publicKey REQUIRED 2189 -- MUST be the ephemeral public key of the sending party 2190 ukm RECOMMENDED 2191 -- MUST be used when 1-pass ECMQV is used 2192 -- SHOULD be present to ensure uniqueness of the key 2193 -- encryption key, see [RFC8419] 2194 keyEncryptionAlgorithm 2195 REQUIRED 2196 -- MUST be the algorithm identifier of the key wrap algorithm 2197 -- The algorithm type MUST be a KM_KW_ALG as specified in 2198 -- RFC-CMP-Alg Section 4.3 2199 recipientEncryptedKeys 2200 REQUIRED 2201 -- MUST contain exactly one RecipientEncryptedKey element 2202 rid REQUIRED 2203 -- MUST contain the rKeyId choice 2204 rKeyId REQUIRED 2205 subjectKeyIdentifier 2206 REQUIRED 2207 -- MUST contain the same value as the senderKID in the 2208 -- respective request message header 2209 encryptedKey 2210 REQUIRED 2211 -- MUST be the encrypted content-encryption key 2213 4.1.6.2. Using key transport key management technique 2215 This variant can be applied in combination with the PKI management 2216 operations specified in Section 4.1.1 to Section 4.1.3 using 2217 signature-based protection of CMP messages. The EE certificate used 2218 for the signature-based protection of the request message MUST allow 2219 for the key usage "keyEncipherment" and not for "keyAgreement". 2220 Therefore, the related key pair MUST be used for encipherment of the 2221 content-encryption key. For this key management technique, the 2222 KeyTransRecipientInfo structure MUST be used in the contentInfo 2223 field. 2225 The KeyTransRecipientInfo structure included into the EnvelopedData 2226 structure is specified in CMS Section 6.2.1 [RFC5652]. 2228 The detailed description of the KeyTransRecipientInfo structure looks 2229 like this: 2231 ktri REQUIRED 2232 -- MUST be a KeyTransRecipientInfo as specified in CMS 2233 -- Section 6.2.1 [RFC5652] 2234 version REQUIRED 2235 -- MUST be 2 2236 rid REQUIRED 2237 -- MUST contain the subjectKeyIdentifier choice 2238 subjectKeyIdentifier 2239 REQUIRED 2240 -- MUST contain the same value as the senderKID in the 2241 -- respective request message header 2242 keyEncryptionAlgorithm 2243 REQUIRED 2244 -- MUST be the algorithm identifier of the key transport 2245 -- algorithm 2246 -- The algorithm type MUST be a KM_KT_ALG as specified in 2247 -- RFC-CMP-Alg Section 4.2 2248 encryptedKey REQUIRED 2249 -- MUST be the encrypted content-encryption key 2251 4.1.6.3. Using password-based key management technique 2253 This variant can be applied in combination with the PKI management 2254 operation specified in Section 4.1.5 using MAC-based protection of 2255 CMP messages. The shared secret information used for the MAC-based 2256 protection MUST also be used for the encryption of the content- 2257 encryption key but with a different salt value applied in the key 2258 derivation algorithm. For this key management technique, the 2259 PasswordRecipientInfo structure MUST be used in the contentInfo 2260 field. 2262 Note: The entropy of the shared secret information is crucial for the 2263 level of protection when using a password-based key management 2264 technique. For centrally generated key pairs, the entropy of the 2265 shared secret information SHALL not be less than the security 2266 strength of the centrally generated key pair. Further guidance is 2267 available in Section 8. 2269 The PasswordRecipientInfo structure included into the EnvelopedData 2270 structure is specified in CMS Section 6.2.4 [RFC5652]. 2272 The detailed description of the PasswordRecipientInfo structure looks 2273 like this: 2275 pwri REQUIRED 2276 -- MUST be a PasswordRecipientInfo as specified in CMS 2277 -- Section 6.2.4 [RFC5652] 2278 version REQUIRED 2279 -- MUST be 0 2280 keyDerivationAlgorithm 2281 REQUIRED 2282 -- MUST be the algorithm identifier of the key derivation 2283 -- algorithm 2284 -- The algorithm type MUST be a KM_KD_ALG as specified in 2285 -- RFC-CMP-Alg Section 4.4 2286 keyEncryptionAlgorithm 2287 REQUIRED 2288 -- MUST be the algorithm identifier of the key wrap algorithm 2289 -- The algorithm type MUST be a KM_KW_ALG as specified in 2290 -- RFC-CMP-Alg Section 4.3 2291 encryptedKey REQUIRED 2292 -- MUST be the encrypted content-encryption key 2294 4.2. Revoking a certificate 2296 This PKI management operation should be used by an entity to request 2297 revocation of a certificate. Here the revocation request is used by 2298 an EE to revoke one of its own certificates. 2300 The revocation request message MUST be signed using the certificate 2301 that is to be revoked to prove the authorization to revoke. The 2302 revocation request message is signature-protected using this 2303 certificate. This requires, that the EE still possesses the private 2304 key. If this is not the case the revocation has to be initiated by 2305 other means, e.g., revocation by the RA as specified in 2306 Section 5.3.2. 2308 An EE requests the revocation of an own certificate at the CA that 2309 issued this certificate. The PKI management entity handles the 2310 request as described in Section 5.1.4 and responds with a message 2311 that contains the status of the revocation from the CA. 2313 Specific prerequisites augmenting the prerequisites in Section 3.4: 2315 * The certificate the EE wishes to revoke is not yet expired or 2316 revoked. 2318 Message flow: 2320 Step# EE PKI management entity 2321 1 format rr 2322 2 -> rr -> 2323 3 handle or forward rr 2324 4 format or receive rp 2325 5 <- rp <- 2326 6 handle rp 2328 For this PKI management operation, the EE MUST include exactly one 2329 RevDetails structure in the rr message body. In case no generic 2330 error occurred the response to the rr MUST be an rp message 2331 containing a single status field. 2333 Detailed message description: 2335 Revocation Request -- rr 2337 Field Value 2339 header 2340 -- As described in Section 3.1 2342 body 2343 -- The request of the EE to revoke its certificate 2344 rr REQUIRED 2345 -- MUST contain exactly one element of type RevDetails 2346 -- If more revocations are desired, further PKI management 2347 -- operations MUST be initiated 2348 certDetails REQUIRED 2349 -- MUST be present and is of type CertTemplate 2350 serialNumber REQUIRED 2351 -- MUST contain the certificate serialNumber attribute of the 2352 -- certificate to be revoked 2353 issuer REQUIRED 2354 -- MUST contain the issuer attribute of the certificate to be 2355 -- revoked 2356 crlEntryDetails REQUIRED 2357 -- MUST contain exactly one reasonCode of type CRLReason (see 2358 -- [RFC5280] section 5.3.1) 2359 -- If the reason for this revocation is not known or shall not 2360 -- be published the reasonCode MUST be 0 = unspecified 2362 protection REQUIRED 2363 -- As described in Section 3.2 and using the private key related 2364 -- to the certificate to be revoked 2366 extraCerts REQUIRED 2367 -- As described in Section 3.3 2369 Revocation Response -- rp 2371 Field Value 2373 header 2374 -- As described in Section 3.1 2376 body 2377 -- The responds of the PKI management entity to the request as 2378 -- appropriate 2379 rp REQUIRED 2380 status REQUIRED 2381 -- MUST contain exactly one element of type PKIStatusInfo 2382 status REQUIRED 2383 -- positive value allowed: "accepted" 2384 -- negative value allowed: "rejection" 2385 statusString OPTIONAL 2386 -- MAY be any human-readable text for debugging, logging or to 2387 -- display in a GUI 2388 failInfo OPTIONAL 2389 -- MAY be present if status is "rejection" 2390 -- MUST be absent if the status is "accepted" 2392 protection REQUIRED 2393 -- As described in section 3.2 2395 extraCerts REQUIRED 2396 -- As described in section 3.3 2398 4.3. Support messages 2400 The following support messages offer on demand in-band delivery of 2401 content relevant to the EE provided by a PKI management entity. CMP 2402 general messages and general response are used for this purpose. 2403 Depending on the environment, these requests may be answered by an RA 2404 or CA (see also Section 5.1.5). 2406 The general messages and general response messages contain 2407 InfoTypeAndValue structures. In addition to those infoType values 2408 defined in RFC 4210 [RFC4210] and CMP Updates 2409 [I-D.ietf-lamps-cmp-updates] further OIDs MAY be used to define new 2410 PKI management operations or new general-purpose support messages as 2411 needed in specific environments. 2413 The following contents are specified in this document: 2415 * Get CA certificates 2417 * Get root CA certificate update 2419 * Get certificate request template 2421 * Get new CRLs 2423 In the following the aspects common to all general messages (genm) 2424 and general response (genp) messages are described. 2426 Message flow: 2428 Step# EE PKI management entity 2429 1 format genm 2430 2 -> genm -> 2431 3 handle or forward genm 2432 4 format or receive genp 2433 5 <- genp <- 2434 6 handle genp 2436 Detailed message description: 2438 General Message -- genm 2440 Field Value 2442 header 2443 -- As described in Section 3.1 2445 body 2446 -- A request by the EE for information 2447 genm REQUIRED 2448 -- MUST contain exactly one element of type InfoTypeAndValue 2449 infoType REQUIRED 2450 -- MUST be the OID identifying one of the specific PKI 2451 -- management operations described below 2452 infoValue OPTIONAL 2453 -- MUST be as specified for the specific PKI management operation 2455 protection REQUIRED 2456 -- As described in Section 3.2 2458 extraCerts REQUIRED 2459 -- As described in Section 3.3 2461 General Response -- genp 2463 Field Value 2465 header 2466 -- As described in Section 3.1 2468 body 2469 -- The response of the PKI management entity providing 2470 -- information 2471 genp REQUIRED 2472 -- MUST contain exactly one element of type InfoTypeAndValue 2473 infoType REQUIRED 2474 -- MUST be the OID identifying the specific PKI management 2475 -- operation described below 2476 infoValue OPTIONAL 2477 -- MUST be as specified for the specific PKI management operation 2479 protection REQUIRED 2480 -- As described in Section 3.2 2482 extraCerts REQUIRED 2483 -- As described in Section 3.3 2485 4.3.1. Get CA certificates 2487 This PKI management operation can be used by an EE to request CA 2488 certificates from the PKI management entity. 2490 An EE requests CA certificates, e.g., for chain construction, from an 2491 PKI management entity by sending a general message with OID id-it- 2492 caCerts as specified in CMP Updates [I-D.ietf-lamps-cmp-updates]. 2493 The PKI management entity responds with a general response with the 2494 same OID that either contains a SEQUENCE of certificates populated 2495 with the available intermediate and issuing CA certificates or with 2496 no content in case no CA certificate is available. 2498 No specific prerequisites apply in addition to those specified in 2499 Section 3.4. 2501 The message sequence for this PKI management operation is as given 2502 above, with the following specific content: 2504 1 the infoType OID to use is id-it-caCerts 2506 2 the infoValue of the request MUST be absent 2508 3 if present, the infoValue of the response MUST contain a sequence 2509 of certificates 2511 The infoValue field of the general response containing the id-it- 2512 caCerts OID looks like this: 2514 infoValue OPTIONAL 2515 -- MUST be absent if no CA certificate is available 2516 -- MUST be present if CA certificates are available 2517 -- MUST be a sequence of CMPCertificate 2519 4.3.2. Get root CA certificate update 2521 This PKI management operation can be used by an EE to request an 2522 updated root CA Certificate as described in Section 4.4 of RFC 4210 2523 [RFC4210]. 2525 An EE requests an update of a root CA certificate from the PKI 2526 management entity by sending a general message with OID id-it- 2527 oldTrustAnchor, which SHOULD include this root CA certificate in the 2528 message body, as specified in CMP Updates 2529 [I-D.ietf-lamps-cmp-updates]. Optionally, the trust anchor MAY be 2530 provided as public key only. The PKI management entity responds with 2531 a general response with the same OID that either contains the update 2532 of the root CA certificate consisting of up to three certificates, or 2533 with no content in case no update is available. 2535 Note: This mechanism can also be used in case the trust anchor to be 2536 updated is not provided as a self-signed certificate, but, e.g., as a 2537 certificate issued by a different CA. 2539 The newWithNew certificate is the new root CA certificate and is 2540 REQUIRED to be present if available. The newWithOld certificate is 2541 REQUIRED to be present in the response message because it is needed 2542 for the receiving entity trusting the old root CA certificate to gain 2543 trust in the new root CA certificate. The oldWithNew certificate is 2544 OPTIONAL because it is only needed in rare scenarios where entities 2545 do not already trust the old root CA. 2547 No specific prerequisites apply in addition to those specified in 2548 Section 3.4. 2550 The message sequence for this PKI management operation is as given 2551 above, with the following specific content: 2553 1 the infoType OID to use is id-it-oldTrustAnchor in the request and 2554 id-it-trustAnchorUpdate in the response 2556 2 the infoValue of the request MUST be an OldTrustAnchor structure 2557 referencing the trust anchor the update is requested for 2559 3 if present, the infoValue of the response MUST be a 2560 TrustAnchorUpdate structure 2562 The infoValue field of the general request containing the id-it- 2563 oldTrustAnchor OID looks like this: 2565 infoValue RECOMMENDED 2566 -- MUST contain an OldTrustAnchor structure referencing the 2567 -- trust anchor to be updated 2568 -- SHOULD be the root CA certificate, if available 2569 -- MAY be the publicKey of the trust anchor otherwise 2571 The infoValue field of the general response containing the id-it- 2572 trustAnchorUpdate OID looks like this: 2574 infoValue OPTIONAL 2575 -- MUST be absent if no update of the root CA certificate is 2576 -- available 2577 -- MUST be present if an update of the root CA certificate 2578 -- is available and MUST be of type TrustAnchorUpdate 2579 newWithNew REQUIRED 2580 -- MUST be present if infoValue is present 2581 -- MUST contain the new root CA certificate 2582 newWithOld REQUIRED 2583 -- MUST be present if infoValue is present 2584 -- MUST contain a certificate containing the new public 2585 -- root CA key signed with the old private root CA key 2586 oldWithNew OPTIONAL 2587 -- MAY be present if infoValue is present 2588 -- MUST contain a certificate containing the old public 2589 -- root CA key signed with the new private root CA key 2591 4.3.3. Get certificate request template 2593 This PKI management operation can be used by an EE to request a 2594 template with parameters for future certificate requests. 2596 An EE requests certificate request parameters from the PKI management 2597 entity by sending a general message with OID id-it-certReqTemplate as 2598 specified in CMP Updates [I-D.ietf-lamps-cmp-updates]. The EE MAY 2599 indicate the certificate profile to use in the id-it-certProfile 2600 extension of the generalInfo field in the PKIHeader of the general 2601 message as described in Section 3.1. The PKI management entity 2602 responds with a general response with the same OID that either 2603 contains requirements on the certificate request template, or with no 2604 content in case no specific requirements are imposed by the PKI. The 2605 CertReqTemplateValue contains requirements on certificate fields and 2606 extensions in a certTemplate. Optionally it contains a keySpec field 2607 containing requirements on algorithms acceptable for key pair 2608 generation. 2610 The EE SHOULD follow the requirements from the received CertTemplate, 2611 by including in the certificate requests all the fields requested, 2612 taking over all the field values provided and filling in any 2613 remaining fields values. The EE SHOULD NOT add further fields, name 2614 components, and extensions or their (sub-)components. 2616 Note: We deliberately do not use "MUST" or "MUST NOT" here in order 2617 to allow more flexibility in case the rules given here are not 2618 sufficient for specific scenarios. The EE can populate the 2619 certificate request as wanted and ignore any of the requirements 2620 contained in the CertReqTemplateValue. On the other hand, a PKI 2621 management entity is free to ignore or replace any parts of the 2622 content of the certificate request provided by the EE. The 2623 CertReqTemplate PKI management operation offers means to ease a joint 2624 understanding which fields and/or which field values should be used. 2625 An example is provided in Appendix A. 2627 In case a field of type Name, e.g., subject, is present in the 2628 CertTemplate but has the value NULL-DN (i.e., has an empty list of 2629 RDN components), the field SHOULD be included in the certificate 2630 request and filled with content provided by the EE. Similarly, in 2631 case an X.509v3 extension is present but its extnValue is empty, this 2632 means that the extension SHOULD be included and filled with content 2633 provided by the EE. In case a Name component, for instance a common 2634 name or serial number, is given but has an empty string value, the EE 2635 SHOULD fill in a value. Similarly, in case an extension has sub- 2636 components (e.g., an IP address in a SubjectAltName field) with empty 2637 value, the EE SHOULD fill in a value. 2639 The EE MUST ignore (i.e., not include and fill in) empty fields, 2640 extensions, and sub-components that it does not understand or does 2641 not know suitable values to be filled in. 2643 The publicKey field of type SubjectPublicKeyInfo in the CertTemplate 2644 of the CertReqTemplateValue MUST be omitted. In case the PKI 2645 management entity wishes to make stipulation on algorithms the EE may 2646 use for key generation, this MUST be specified using the keySpec 2647 field as specified in CMP Updates [I-D.ietf-lamps-cmp-updates]. 2649 The keySpec field, if present, specifies the public key types 2650 optionally with parameters, and/or RSA key lengths for which a 2651 certificate may be requested. 2653 The value of a keySpec element with the OID id-regCtrl-algId, as 2654 specified in CMP Updates [I-D.ietf-lamps-cmp-updates], MUST be of 2655 type AlgorithmIdentifier and give an algorithm other than RSA. For 2656 EC keys the curve information MUST be specified as described in the 2657 respective standard documents. 2659 The value of a keySpec element with the OID id-regCtrl-rsaKeyLen, as 2660 specified in CMP Updates [I-D.ietf-lamps-cmp-updates], MUST be a 2661 positive integer value and give an RSA key length. 2663 In the CertTemplate of the CertReqTemplateValue the serialNumber, 2664 signingAlg, issuerUID, and subjectUID fields MUST be omitted. 2666 Specific prerequisites augmenting the prerequisites in Section 3.4: 2668 * When using the generalInfo field certProfile, the EE MUST know the 2669 identifier needed to indicate the requested certificate profile. 2671 The message sequence for this PKI management operation is as given 2672 above, with the following specific content: 2674 1 the infoType OID to use is id-it-certReqTemplate 2676 2 the id-it-certProfile generalInfo field in the header of the 2677 request MAY contain the name of the requested certificate request 2678 template 2680 3 the infoValue of the request MUST be absent 2682 4 if present, the infoValue of the response MUST be a 2683 CertReqTemplateValue containing a CertTemplate structure and an 2684 optional keySpec field 2686 The infoValue field of the general response containing the id-it- 2687 certReqTemplate OID looks like this: 2689 InfoValue OPTIONAL 2690 -- MUST be absent if no requirements are available 2691 -- MUST be present if the PKI management entity has any 2692 -- requirements on the contents of the certificate template 2693 certTemplate REQUIRED 2694 -- MUST be present if infoValue is present 2695 -- MUST contain the required CertTemplate structure elements 2696 -- The SubjectPublicKeyInfo field MUST be absent 2697 keySpec OPTIONAL 2698 -- MUST be absent if no requirements on the public key are 2699 -- available 2700 -- MUST be present if the PKI management entity has any 2701 -- requirements on the keys generated 2702 -- MUST contain one AttributeTypeAndValue per supported 2703 -- algorithm with attribute id-regCtrl-algId or 2704 -- id-regCtrl-rsaKeyLen 2706 4.3.4. CRL update retrieval 2708 This PKI management operation can be used by an EE to request a new 2709 CRL. If a CA offers methods to access a CRL they are often provided 2710 by the CA through the CRLDP or AuthorityInfoAccess as specified in 2711 [RFC5280] components in the issued certificates. In addition, CMP 2712 offers this functionality as part of the PKI management operation. 2714 An EE requests a CRL update from the PKI management entity by sending 2715 a general message with OID id-it-crlStatusList. This MUST include 2716 the CRL source and, if available, the thisUpdate time of the most 2717 current CRL instance it already has, as specified in CMP Updates 2718 [I-D.ietf-lamps-cmp-updates]. The PKI management entity MUST respond 2719 with a general response with OID id-it-crls. If no thisUpdate value 2720 was given by the EE, it MUST return the latest CRL available. If a 2721 thisUpdate value was given, it MUST return the latest available CRL 2722 in case this CRL is more recent, otherwise the infoValue in the 2723 response message MUST be absent. 2725 In addition to the prerequisites specified in Section 3.4, the EE 2726 MUST know for the requested CRL either its CRL distribution point 2727 name or the name of the CRL issuer. 2729 Note: If the EE does not want to request a specific CRL it MAY use 2730 instead a general message with OID id-it-currentCrl as specified in 2731 RFC 4210 Section 5.3.19.6 [I-D.ietf-lamps-cmp-updates]. 2733 The message sequence for this PKI management operation is as given 2734 above, with the following specific content: 2736 1 the infoType OID to use is id-it-crlStatusList in the request and 2737 id-it-crls in the response 2739 2 the infoValue of the request MUST be present and contain a 2740 CRLStatus structure 2742 3 if present, the infoValue of the response MUST contain a CRL 2744 The infoValue field of the general request containing the id-it- 2745 crlStatusList OID looks like this: 2747 CRLSourceListValue REQUIRED 2748 -- MUST contain a CRLSource structure 2749 -- MUST contain the dpn choice if the CRL distribution point name 2750 -- is available 2751 -- MUST contain the issuer choice otherwise, naming the CA that 2752 -- issues the CRL. 2753 thisUpdate OPTIONAL 2754 -- SHOULD contain the thisUpdate field of the latest CRL form 2755 -- the given dpn or issuer, in case such a CRL is already known 2756 -- by the EE 2758 The infoValue field of the general response containing the id-it-crls 2759 OID looks like this: 2761 infoValue REQUIRED 2762 -- MUST contain a CRL update from the referenced source, if a 2763 -- thisUpdate value was not given or a more recent CRL is 2764 -- available 2766 4.4. Handling delayed delivery 2768 This is a variant of all PKI management operations described in 2769 described in this document. It is initiated in case a PKI management 2770 entity cannot respond to a request message in a timely manner, 2771 typically due to offline or asynchronous upstream communication, or 2772 due to delays in handling the request. The polling mechanism has 2773 been specified in RFC 4210 Section 5.3.22 [RFC4210] and updated by 2774 [I-D.ietf-lamps-cmp-updates]. 2776 Depending on the PKI architecture, the entity initiating delayed 2777 delivery is not necessarily the PKI management entity directly 2778 addressed by the EE. 2780 When initiating delayed delivery of a message received from an EE, 2781 the PKI management entity MUST respond with an ip/cp/kup/error 2782 message including the status "waiting". On receiving this response, 2783 the EE MUST store in its transaction context the senderNonce of the 2784 preceding request message because this value will be needed for 2785 checking the recipNonce of the final response to be received after 2786 polling. It sends a poll request with certReqId 0 if referring to 2787 the CertResponse element contained in the ip/cp/kup message, else -1 2788 to refer to the whole message. In case the final response is not yet 2789 available, the PKI management entity that initiated the delayed 2790 delivery MUST answer with a poll response, with the same certReqId. 2791 The included checkAfter time value indicates the minimum number of 2792 seconds that SHOULD elapse before the EE sends a new pollReq message 2793 to the PKI management entity. This is repeated until a final 2794 response is available or any party involved gives up on the current 2795 PKI management operation, i.e., a timeout occurs. 2797 When the PKI management entity that initiated delayed delivery can 2798 provide the final response for the original request message of the 2799 EE, it MUST send this response to the EE. Using this response, the 2800 EE can continue the current PKI management operation as usual. 2802 No specific prerequisites apply in addition to those of the 2803 respective PKI management operation. 2805 Message flow: 2807 Step# EE PKI management entity 2808 1 format request 2809 message 2810 2 -> request -> 2811 3 handle or forward 2812 request 2813 4 format ip/cp/kup/error 2814 with status "waiting" 2815 response in case no 2816 immediate final response 2817 is available, 2818 5 <- ip/cp/kup/error <- 2819 6 handle 2820 ip/cp/kup/error 2821 with status 2822 "waiting" 2824 -------------------------- start polling -------------------------- 2826 7 format pollReq 2827 8 -> pollReq -> 2828 9 handle or forward pollReq 2829 10 in case the final response 2830 for the original request 2831 is available, continue 2832 with step 14 2833 otherwise, format or 2834 receive pollRep with 2835 checkAfter value 2836 11 <- pollRep <- 2837 12 handle pollRep 2838 13 let checkAfter 2839 time elapse and 2840 continue with 2841 step 7 2843 ----------------- end polling, continue as usual ------------------ 2845 14 format or receive 2846 final response on 2847 original request 2848 15 <- response <- 2849 16 handle final 2850 response 2852 Detailed description of the ip/cp/kup/error response, pollReq, and 2853 pollRep: 2855 Response with status "waiting" -- ip/cp/kup/error 2857 Field Value 2859 header 2860 -- As described in Section 3.1 2862 body 2863 -- as described for the respective PKI management operation, with 2864 -- the following adaptations: 2865 status REQUIRED -- in case of ip/cp/kup 2866 pKIStatusInfo REQUIRED -- in case of error response 2867 -- PKIStatusInfo structure MUST be present 2868 status REQUIRED 2869 -- MUST be status "waiting" 2870 statusString OPTIONAL 2871 -- MAY be any human-readable text for debugging, logging or to 2872 -- display in a GUI 2873 failInfo PROHIBITED 2875 protection REQUIRED 2876 -- As described in Section 3.2 2878 extraCerts OPTIONAL 2879 -- As described in Section 3.3 2881 Polling Request -- pollReq 2883 Field Value 2885 header 2886 -- As described in Section 3.1 2888 body 2889 -- The message of the EE asking for the final response or for a 2890 -- time to check again 2891 pollReq REQUIRED 2892 certReqId REQUIRED 2893 -- MUST be 0 if referring to a CertResponse element, else -1 2895 protection REQUIRED 2896 -- As described in Section 3.2 2897 -- MUST use the same credentials as in the first request message 2898 -- of the PKI management operation 2900 extraCerts RECOMMENDED 2901 -- As described in Section 3.3 2902 -- MAY be omitted if the message size is critical and 2903 -- the PKI management entity caches the extraCerts from the 2904 -- first request message of the PKI management operation 2906 Polling Response -- pollRep 2908 Field Value 2910 header 2911 -- As described in Section 3.1 2913 body 2914 -- The message indicates the delay after which the EE SHOULD 2915 -- send another pollReq message for this transaction 2916 pollRep REQUIRED 2917 certReqId REQUIRED 2918 -- MUST be 0 if referring to a CertResponse element, else -1 2919 checkAfter REQUIRED 2920 -- time in seconds to elapse before a new pollReq SHOULD be sent 2921 reason OPTIONAL 2922 -- MAY be any human-readable text for debugging, logging or to 2923 -- display in a GUI 2925 protection REQUIRED 2926 -- As described in Section 3.2 2927 -- MUST use the same credentials as in the first response 2928 -- message of the PKI management operation 2930 extraCerts RECOMMENDED 2931 -- As described in Section 3.3 2932 -- MAY be omitted if the message size is critical and the EE has 2933 -- cached the extraCerts from the first response message of 2934 -- the PKI management operation 2936 Final response – any type of response message 2938 Field Value 2940 header 2942 -- MUST be the header as described for the response message 2943 -- of the respective PKI management operation 2945 body 2946 -- The response of the PKI management entity to the initial 2947 -- request as described in the respective PKI management 2948 -- operation 2950 protection REQUIRED 2951 -- MUST be as described for the response message of the 2952 -- respective PKI management operation 2954 extraCerts REQUIRED 2955 -- MUST be as described for the response message of the 2956 -- respective PKI management operation 2958 5. PKI management entity operations 2960 This section focuses on request processing by a PKI management 2961 entity. Depending on the network and PKI solution design, this can 2962 be an RA or CA, any of which may include protocol conversion or 2963 central key generation (i.e., acting as a KGA). 2965 A PKI management entity may directly respond to request messages from 2966 downstream and report errors. In case the PKI management entity is 2967 an RA it typically forwards the received request messages upstream 2968 after checking them and forwards respective response messages 2969 downstream. Besides responding to messages or forwarding them, a PKI 2970 management entity may request or revoke certificates on behalf of 2971 EEs. A PKI management entity may also need to manage its own 2972 certificates and thus act as an EE using the PKI management 2973 operations specified in Section 4. 2975 5.1. Responding to requests 2977 The PKI management entity terminating the PKI management operation at 2978 CMP level MUST respond to all received requests by returning a 2979 related CMP response message or an error. Any intermediate PKI 2980 management entity MAY respond depending on the PKI configuration and 2981 policy. 2983 In addition to the checks described in Section 3.5, the responding 2984 PKI management entity SHOULD check that a request that initiates a 2985 new PKI management operation does not use a transactionID that is 2986 currently in useThe failInfo bit value to use on reporting failure as 2987 described in Section 3.6.4 is transactionIdInUse. If any of these 2988 verification steps or any of the essential checks described in the 2989 following subsections fails, the PKI management entity MUST proceed 2990 as described in Section 3.6. 2992 The responding PKI management entity SHOULD copy the sender field of 2993 the request to the recipient field of the response, MUST copy the 2994 senderNonce of the request to the recipNonce of the response, and 2995 MUST use the same transactionID for the response. 2997 5.1.1. Responding to a certificate request 2999 An ir/cr/p10cr/kur message is used to request a certificate as 3000 described in Section 4.1. The responding PKI management entity MUST 3001 proceed as follows unless it initiates delayed delivery as described 3002 in Section 5.1.2. 3004 The PKI management entity SHOULD check the message body according to 3005 the applicable requirements from Section 4.1. Possible failInfo bit 3006 values used for error reporting in case a check failed include 3007 badCertId and badCertTemplate. It MUST verify the presence and value 3008 of the proof-of-possession (failInfo bit: badPOP), unless central key 3009 generation is requested. In case the special POP value "raVerified" 3010 is given, it SHOULD check that the request message was signed using a 3011 certificate containing the cmcRA extended key usage (failInfo bit: 3012 notAuthorized). The PKI management entity SHOULD perform also any 3013 further checks on the certTemplate contents (failInfo: 3014 badCertTemplate) according to any applicable PKI policy and 3015 certificate profile. 3017 If the requested certificate is available, the PKI management entity 3018 MUST respond with a positive ip/cp/kup message as described in 3019 Section 4.1. 3021 Note: If central key generation is performed by the responding PKI 3022 management entity, the responding PKI management entity MUST include 3023 in the response the privateKey field as specified in Section 4.1.6. 3024 It may have issued the certificate for the newly generated key pair 3025 itself if it is a CA, or have requested the certificate on behalf of 3026 the EE as described in Section 5.3.1, or have received it by other 3027 means from a CA. 3029 The prerequisites of the respective PKI management operation as 3030 specified in Section 4.1 apply. 3032 Note: If the EE requested omission of the certConf message, the PKI 3033 management entity SHOULD handle it as described in Section 4.1.1 and 3034 therefore MAY grant this by including the implicitConfirm extension 3035 in the response header. 3037 5.1.2. Initiating delayed delivery 3039 This functional extension can be used by a PKI management entity in 3040 case the response to a request takes longer than usual. In this case 3041 the PKI management entity MUST completely validate the request as 3042 usual and then start preparing the response or forward the request 3043 further upstream as soon as possible. In the meantime, it MUST 3044 respond with an ip/cp/kup/error message including the status 3045 "waiting" and handle subsequent polling as described in Section 4.4. 3047 Note: Typically, as stated in Section 5.2.3, an intermediate PKI 3048 management entity should not change the sender and recipient nonces 3049 even in case it modifies a request or a response message. In the 3050 special case of delayed delivery initiated by an intermediate PKI 3051 management entity, there is an exception. Between the EE and this 3052 PKI management entity, pollReq and pollRep messages are exchanged 3053 handling the nonces as usual. Yet when the final response from 3054 upstream has arrived at the PKI management entity, this response 3055 contains the recipNonce copied (as usual) from the senderNonce in the 3056 original request message. The PKI management entity that initiated 3057 the delayed delivery may replace the recipNonce in the response 3058 message with the senderNonce of the last received pollReq because the 3059 downstream entities, including the EE, might expect it in this way. 3060 Yet the check specified in Section 3.5 allows to alternatively use 3061 the senderNonce of the original request. 3063 No specific prerequisites apply in addition to those of the 3064 respective PKI management operation. 3066 5.1.3. Responding to a confirmation message 3068 A PKI management entity MUST handle a certConf message if it has 3069 responded before with a positive ip/cp/kup message not granting 3070 implicit confirmation. It SHOULD check the message body according to 3071 the requirements given in Section 4.1.1 (failInfo bit: badCertId) and 3072 react as described there. 3074 The prerequisites of the respective PKI management operation as 3075 specified in Section 4.1 apply. 3077 5.1.4. Responding to a revocation request 3079 An rr message is used to request revocation of a certificate. The 3080 responding PKI management entity SHOULD check the message body 3081 according to the requirements in Section 4.2. It MUST make sure that 3082 the referenced certificate exists (failInfo bit: badCertId), has been 3083 issued by the addressed CA, and is not already expired or revoked 3084 (failInfo bit: certRevoked). On success it MUST respond with a 3085 positive rp message as described in Section 4.2. 3087 No specific prerequisites apply in addition to those specified in 3088 Section 3.4. 3090 5.1.5. Responding to a support message 3092 A genm message is used to retrieve extra content. The responding PKI 3093 management entity SHOULD check the message body according to the 3094 applicable requirements in Section 4.3 and perform any further checks 3095 depending on the PKI policy. On success it MUST respond with a genp 3096 message as described there. 3098 Note: The responding PKI management entity may generate the response 3099 from scratch or reuse the contents of previous responses. Therefore, 3100 it may be worth caching the body of the response message as long as 3101 the contained information is still valid, such that further requests 3102 for the same contents can be answered immediately. 3104 No specific prerequisites apply in addition to those specified in 3105 Section 3.4. 3107 5.2. Forwarding messages 3109 In case the PKI solution consists of intermediate PKI management 3110 entities (i.e., LRA or RA), each CMP request message coming from an 3111 EE or any other downstream PKI management entity SHOULD be forwarded 3112 to the next (upstream) PKI management entity as described in this 3113 section and otherwise MUST be answered as described in Section 5.1. 3114 Any received response message or error message MUST be forwarded to 3115 the next (downstream) PKI entity. 3117 In addition to the checks described in Section 3.5, the forwarding 3118 PKI management entity MAY verify the proof-of-possession for 3119 ir/cr/p10cr/kur messages. If one of these verification procedures 3120 fails, the RA proceeds as described in Section 3.6. 3122 A PKI management entity SHOULD NOT change the received message unless 3123 necessary. The PKI management entity SHOULD only update the message 3124 protection and the certificate template in a certificate request 3125 message if this is technically necessary. Concrete PKI system 3126 specifications may define in more detail when to do so. 3128 This is particularly relevant in the upstream communication of a 3129 request message. 3131 Each forwarding PKI management entity has one or more 3132 functionalities. It may 3134 * verify the identities of EEs and make authorization decisions for 3135 certification request processing based on specific knowledge of 3136 the local setup, e.g., by consulting an inventory or asset 3137 management system, 3139 * add or modify fields of certificate request messages, 3141 * store data from a message in a database for later usage or audit 3142 purposes, 3144 * provide traversal of a network boundary, 3146 * replace a MAC-based protection by a signature-based protection 3147 that can be verified also further upstream, 3149 * double-check if the messages transferred back and forth are 3150 properly protected and well-formed, 3152 * provide an authentic indication that it has performed all required 3153 checks, 3155 * initiate a delayed delivery due to delays transferring messages or 3156 handling requests, or 3158 * collect messages from multiple RAs and forward them jointly. 3160 The decision if a message should be forwarded 3162 * unchanged with the original protection, 3164 * unchanged with a new protection, or 3166 * changed with a new protection 3168 depends on the PKI solution design and the associated security policy 3169 (CP/CPS [RFC3647]). 3171 A PKI management entity MUST replace or add a protection of a message 3172 if it 3174 * needs to securely indicate that it has done checks or validations 3175 on the message to one of the next (upstream) PKI management entity 3176 or 3178 * needs to protect the message using a key and certificate from a 3179 different PKI. 3181 A PKI management entity MUST replace a protection of a message if it 3183 * performs changes to the header or the body of the message or 3185 * needs to convert from or to a MAC-based protection. 3187 This is particularly relevant in the upstream communication of 3188 certificate request messages. 3190 Note that the message protection covers only the header and the body 3191 and not the extraCerts. The PKI management entity MAY change the 3192 extraCerts in any of the following message adaptations, e.g., to 3193 sort, add, or delete certificates to support subsequent PKI entities. 3194 This may be particularly helpful to augment upstream messages with 3195 additional certificates or to reduce the number of certificates in 3196 downstream messages when forwarding to constrained devices. 3198 5.2.1. Not changing protection 3200 This variant means that a PKI management entity forwards a CMP 3201 message without changing the header, body, or protection. In this 3202 case the PKI management entity acts more like a proxy, e.g., on a 3203 network boundary, implementing no specific RA-like security 3204 functionality that requires an authentic indication to the PKI. 3205 Still the PKI management entity might implement checks that result in 3206 refusing to forward the request message and instead responding as 3207 specified in Section 3.6. 3209 This variant of forwarding a message or the one described in 3210 Section 5.2.2.1 SHOULD be used for kur messages and for central key 3211 generation. 3213 No specific prerequisites apply in addition to those specified in 3214 Section 3.4. 3216 5.2.2. Adding protection and batching of messages 3218 This variant of forwarding a message means that a PKI management 3219 entity adds another protection to PKI management messages before 3220 forwarding them. 3222 The nested message is a PKI management message containing a 3223 PKIMessages sequence as its body containing one or more CMP messages. 3225 As specified in the updated Section 5.1.3.4 of RFC4210 [RFC4210] (see 3226 CMP Updates [I-D.ietf-lamps-cmp-updates]) there are various use cases 3227 for adding another protection by a PKI management entity. Specific 3228 procedures are described in more detail in the following sections. 3230 Detailed message description: 3232 Nested Message - nested 3234 Field Value 3236 header 3237 -- As described in Section 3.1 3239 body 3240 -- Container to provide additional protection to original 3241 -- messages and to bundle request messages or alternatively 3242 -- response messages 3243 PKIMessages REQUIRED 3244 -- MUST be a sequence of one or more CMP messages 3246 protection REQUIRED 3247 -- As described in Section 3.2 using the CMP protection key of 3248 -- the PKI management entity 3250 extraCerts REQUIRED 3251 -- As described in Section 3.3 3253 5.2.2.1. Adding protection to a request message 3255 A PKI management entity may authentically indicate successful 3256 validation and approval of a request message by adding an extra 3257 signature to the original message. 3259 By adding a protection using its own CMP protecting key the PKI 3260 management entity provides a proof of verifying and approving the 3261 message as described above. Thus, the PKI management entity acts as 3262 an actual Registration Authority (RA), which implements important 3263 security functionality of the PKI. Applying an additional protection 3264 is specifically relevant when forwarding a message that requests a 3265 certificate update or central key generation. This is because the 3266 original protection of the EE must be preserved while adding an 3267 indication of approval by the PKI management entity. 3269 The PKI management entity wrapping the original request message in a 3270 nested message structure MUST take over the recipient, recipNonce, 3271 and transactionID of the original message to the nested message and 3272 apply signature-based protection. The additional signature serves as 3273 proof of verification and authorization by this PKI management 3274 entity. 3276 The PKI management entity receiving such a nested message that 3277 contains a single request message MUST validate the additional 3278 protection signature on the nested message and check the 3279 authorization for the approval it implies. 3281 The PKI management entity responding to the request contained in the 3282 nested message sends the response message as described in 3283 Section 5.1, without wrapping it in a nested message. 3285 Note: This form of nesting messages is characterized by the fact that 3286 the transactionID in the header of the nested message is the same as 3287 the one used in the included message. 3289 Specific prerequisites augmenting the prerequisites in Section 3.4: 3291 * The PKI management entity MUST have the authorization to perform 3292 the validation and approval of the respective request according to 3293 the PKI policies. 3295 Message flow: 3297 Step# PKI management entity PKI management entity 3298 1 format nested 3299 2 -> nested -> 3300 3 handle or forward nested 3301 4 format or receive response 3302 5 <- response <- 3303 6 forward response 3305 5.2.2.2. Batching messages 3307 A PKI management entity MAY bundle any number of PKI management 3308 messages for batch processing or to transfer a bulk of PKI management 3309 messages using the nested message structure. In this use case, 3310 nested messages are used both on the upstream interface towards the 3311 next PKI management entity and on the downstream interface from the 3312 PKI management entity towards the EE. 3314 This PKI management operation is typically used on the interface 3315 between an LRA and an RA to bundle several messages for offline 3316 delivery. In this case the LRA needs to initiate delayed delivery as 3317 described in Section 5.1.2. If the RA needs different routing 3318 information per nested PKI management message a suitable mechanism 3319 may need to be implemented. Since this mechanism strongly depends on 3320 the requirements of the target architecture, it is out of scope of 3321 this document. 3323 A nested message containing requests is generated locally at the PKI 3324 management entity. For the upstream nested message, the PKI 3325 management entity acts as a protocol end point and therefore a fresh 3326 transactionID and a fresh senderNonce MUST be used in the header of 3327 the nested message. An upstream nested message may contain request 3328 messages, e.g., ir, cr, p10cr, kur, pollReq, certConf, rr, or genm. 3329 While building the upstream nested message the PKI management entity 3330 SHOULD store the sender, transactionID, and senderNonce fields of all 3331 bundled messages together with the transactionID of the upstream 3332 nested message. 3334 Such an upstream nested message is sent to the next PKI management 3335 entity. The upstream PKI management entity that unbundles it MUST 3336 handle each of the included request messages as usual. It MUST 3337 answer with a downstream nested message. This downstream nested 3338 message MUST use the transactionID of the upstream nested message and 3339 return the senderNonce of the upstream nested message as the 3340 recipNonce of the downstream nested message. The downstream nested 3341 message SHOULD bundle the individual response messages (e.g., ip, cp, 3342 kup, pollRep, pkiConf, rp, genp, error) for all original request 3343 messages of the upstream nested message. While unbundling the 3344 downstream nested message, the former PKI management entity can 3345 determine lost and unexpected responses based on the previously 3346 stored transactionIDs. When it forwards the unbundled responses, any 3347 extra messages SHOULD be dropped, and any missing response message 3348 (failInfo bit: systemUnavail) MUST be answered with an error message 3349 to inform the respective requester about the failed certificate 3350 management operation. 3352 Note: This form of nesting messages is characterized by the fact that 3353 the transactionID in the header of the nested message is different to 3354 those used in the included messages. 3356 The protection of the nested messages SHOULD NOT be regarded as an 3357 indication of verification or approval of the bundled PKI request 3358 messages. 3360 No specific prerequisites apply in addition to those specified in 3361 Section 3.4. 3363 Message flow: 3365 Step# PKI management entity PKI management entity 3366 1 format nested 3367 2 -> nested -> 3368 3 handle or forward nested 3369 4 format or receive nested 3370 5 <- nested <- 3371 6 handle nested 3373 5.2.3. Replacing protection 3375 The following two alternatives can be used by any PKI management 3376 entity forwarding a CMP message with or without changes while 3377 providing its own protection and in this way asserting approval of 3378 the message. 3380 By replacing the existing protection using its own CMP protecting key 3381 the PKI management entity provides a proof of verifying and approving 3382 the message as described above. Thus, the PKI management entity acts 3383 as an actual Registration Authority (RA), which implements important 3384 security functionality of the PKI. 3386 Before replacing the existing protection by a new protection, the PKI 3387 management entity MUST verify the protection provided and approve its 3388 content, including any modifications that it may perform. It MUST 3389 also check that the sender, as authenticated by the message 3390 protection, is authorized for the given operation. 3392 These message adaptations MUST NOT be applied to kur messages 3393 described in Section 4.1.3 since their original protection using the 3394 key and certificate to be updated needs to be preserved, unless the 3395 regCtrl OldCertId is used to strongly identify the certificate to be 3396 updated. 3398 These message adaptations MUST NOT be applied to certificate request 3399 messages described in for central key generation Section 4.1.6 since 3400 their original protection needs to be preserved up to the Key 3401 Generation Authority, which needs to use it for encrypting the new 3402 private key for the EE. 3404 In both the kur and central key generation cases, if a PKI management 3405 entity needs to state its approval of the original request message it 3406 MUST provide this using a nested message as specified in 3407 Section 5.2.2.1. 3409 When an intermediate PKI management entity modifies a message, it 3410 SHOULD NOT change the transactionID nor the sender and recipient 3411 nonces. 3413 5.2.3.1. Not changing any included proof-of-possession 3415 This variant of forwarding a message means that a PKI management 3416 entity forwards a CMP message with or without modifying the message 3417 header or body while preserving any included proof-of-possession. 3419 In case the PKI management entity breaks an existing proof-of- 3420 possession, the message adaptation described in Section 5.2.3.2 needs 3421 to be applied instead. 3423 Specific prerequisites augmenting the prerequisites in Section 3.4: 3425 * The PKI management entity MUST have the authorization to perform 3426 the validation and approval of the respective request according to 3427 the PKI policies. 3429 5.2.3.2. Breaking proof-of-possession 3431 This variant of forwarding a message needs to be used if a PKI 3432 management entity breaks a signature-based proof-of-possession in a 3433 certificate request message, for instance because it forwards an ir 3434 or cr message with modifications of the certTemplate, i.e., 3435 modification, addition, or removal of fields. 3437 The PKI management entity MUST verify the proof-of-possession 3438 contained in the original message using the included public key. If 3439 successful, the PKI management entity MUST change the popo field 3440 value to raVerified. 3442 Specific prerequisites augmenting the prerequisites in Section 3.4: 3444 * The PKI management entity MUST have the authorization to verify 3445 the proof-of-possession. 3447 * The PKI management entity MUST have the authorization to perform 3448 the validation and approval of the respective request according to 3449 the PKI policies. 3451 The new popo field MUST contain the raVerified choice in the certReq 3452 structure of the modified message as follows: 3454 popo 3455 raVerified REQUIRED 3456 -- MUST have the value NULL and indicates that the PKI 3457 -- management entity verified the popo of the original message 3459 5.3. Acting on behalf of other PKI entities 3461 A PKI management entity may need to request a PKI management 3462 operation on behalf of another PKI entity. In this case the PKI 3463 management entity initiates the respective PKI management operation 3464 as described in Section 4 acting in the role of the EE. 3466 5.3.1. Requesting certificates 3468 A PKI management entity may use on of the PKI management operations 3469 described in Section 4.1 to request a certificate on behalf of 3470 another PKI entity. It either generates the key pair itself and 3471 inserts the new public key in the subjectPublicKey field of the 3472 request certTemplate, or it uses a certificate request received from 3473 downstream, e.g., by means of a different protocol. In the latter 3474 case it SHOULD verify the received proof-of-possession. 3476 No specific prerequisites apply in addition to those specified in 3477 Section 4.1. 3479 Note: An upstream PKI management entity will not be able to 3480 differentiate this PKI management operation from the one described in 3481 Section 5.2.3. 3483 The message sequence for this PKI management operation is identical 3484 to the respective PKI management operation given in Section 4.1, with 3485 the following changes: 3487 1 The request messages MUST be signed using the CMP protection key 3488 of the PKI management entity taking the role of the EE in this 3489 operation. 3491 2 If inclusion of a proper proof-of-possession is not possible the 3492 PKI management entity MUST verify the POP provided from downstream 3493 and use "raVerified" in its upstream request. 3495 5.3.2. Revoking a certificate 3497 A PKI management entity may use the PKI management operation 3498 described in Section 4.2 to revoke a certificate of another PKI 3499 entity. This revocation request message MUST be signed by the PKI 3500 management entity using its own CMP protection key to prove to the 3501 PKI authorization to revoke the certificate on behalf of that PKI 3502 entity. 3504 No specific prerequisites apply in addition to those specified in 3505 Section 4.2. 3507 Note: An upstream PKI management entity will not be able to 3508 differentiate this PKI management operation from the ones described 3509 in Section 5.2.3. 3511 The message sequence for this PKI management operation is identical 3512 to that given in Section 4.2, with the following changes: 3514 1 The rr message MUST be signed using the CMP protection key of the 3515 PKI management entity taking the role of the EE in this operation. 3517 6. CMP message transfer mechanisms 3519 CMP messages are designed to be self-contained, such that in 3520 principle any reliable transfer mechanism can be used. HTTP SHOULD 3521 and CoAP MAY be used for online transfer. CMP messages MAY also be 3522 piggybacked on any other reliable transfer protocol. File-based 3523 transfer MAY be used in case offline transfer is required. 3525 Independently of the means of transfer, it can happen that messages 3526 are lost or that a communication partner does not respond. To 3527 prevent waiting indefinitely, each CMP client component SHOULD use a 3528 configurable per-request timeout, and each CMP server component 3529 SHOULD use a configurable per-response timeout in case a further 3530 Request message is to be expected from the client side within the 3531 same transaction. In this way a hanging transaction can be closed 3532 cleanly with an error as described in Section 3.6 (failInfo bit: 3533 systemUnavail) and related resources (for instance, any cached 3534 extraCerts) can be freed. 3536 Moreover, there are various situations where the delivery of messages 3537 gets delayed. For instance, a serving PKI management entity might 3538 take longer than expected to form a response due to administrative 3539 processes, resource constraints, or upstream message delivery delays. 3540 The transport layer itself may cause delays, for instance due to 3541 offline transport, network segmentation, or intermittent network 3542 connectivity. Part of these issues can be detected and handled at 3543 CMP level using pollReq and pollRep messages as described in 3544 Section 4.4, while others are better handled at transfer level. 3545 Depending on the transfer protocol and system architecture, solutions 3546 for handling delays at transfer level may be present and can be used 3547 for CMP connections, for instance connection re-establishment and 3548 message retransmission. 3550 Note: Long timeout periods are helpful to minimize the need for 3551 polling and maximize chances to handle transfer issues at lower 3552 levels. 3554 Note: When using TCP and similar reliable connection-oriented 3555 transport protocols, which is typical in conjunction with HTTP, there 3556 is the option to keep the connection alive over multiple request- 3557 response message pairs. This may improve efficiency, though is not 3558 required from a security point of view. 3560 When conveying CMP messages in HTTP, CoAP, or MIME-based transfer 3561 protocols, the internet media type "application/pkixcmp" MUST be set 3562 for transfer encoding as specified in Section 5.3 of RFC 2510 3563 [RFC2510], Section 2.4 of CMP over CoAP 3564 [I-D.ietf-ace-cmpv2-coap-transport], and Section 3.4 of CMP over HTTP 3565 [RFC6712]. 3567 6.1. HTTP transfer 3569 This transfer mechanism can be used by a PKI entity to transfer CMP 3570 messages over HTTP. If HTTP transfer is used the specifications as 3571 described in [RFC6712] and updated by CMP Updates 3572 [I-D.ietf-lamps-cmp-updates] MUST be followed. 3574 PKI management operations SHOULD use URI paths consisting of '/.well- 3575 known/cmp/' followed by an operation label depending on the type of 3576 PKI management operation. 3578 +=======================================+=================+=========+ 3579 | PKI management operation | operationLabel | Details | 3580 +=======================================+=================+=========+ 3581 | Enroll client to new PKI | /initialization | Section | 3582 | | | 4.1.1 | 3583 +---------------------------------------+-----------------+---------+ 3584 | Enroll client to existing | /certification | Section | 3585 | PKI | | 4.1.2 | 3586 +---------------------------------------+-----------------+---------+ 3587 | Update client certificate | /keyupdate | Section | 3588 | | | 4.1.3 | 3589 +---------------------------------------+-----------------+---------+ 3590 | Enroll client using | /p10 | Section | 3591 | PKCS#10 | | 4.1.4 | 3592 +---------------------------------------+-----------------+---------+ 3593 | Revoke client certificate | /revocation | Section | 3594 | | | 4.2 | 3595 +---------------------------------------+-----------------+---------+ 3596 | Get CA certificates | /getcacerts | Section | 3597 | | | 4.3.1 | 3598 +---------------------------------------+-----------------+---------+ 3599 | Get root CA certificate | /getrootupdate | Section | 3600 | update | | 4.3.2 | 3601 +---------------------------------------+-----------------+---------+ 3602 | Get certificate request | /getcacerts | Section | 3603 | template | | 4.3.1 | 3604 +---------------------------------------+-----------------+---------+ 3605 | Get CRL updates | /getcrls | Section | 3606 | | | 4.3.4 | 3607 +---------------------------------------+-----------------+---------+ 3608 | Batching messages | /nested | Section | 3609 | | | 5.2.2.2 | 3610 | Note: This path element is | | | 3611 | applicable only between | | | 3612 | PKI management entities. | | | 3613 +---------------------------------------+-----------------+---------+ 3615 Table 9: HTTP endpoints 3617 Independently of any variants used (see Section 4.1.5, Section 4.1.6, 3618 and Section 4.4) the operation label corresponding to the PKI 3619 management operation SHALL be used. 3621 Any certConf or pollReq messages are sent to the same endpoint as 3622 determined by the PKI management operation. 3624 When a single request message is nested as described in 3625 Section 5.2.2.1, the label to use is the same as for the underlying 3626 PKI management operation. 3628 By sending a request to its preferred endpoint, the PKI entity will 3629 recognize via the HTTP response status code whether a configured URI 3630 is supported by the PKI management entity. 3632 In case a PKI management entity receives an unexpected HTTP status 3633 code from upstream, it MUST respond downstream with an error message 3634 as described in Section 3.6 using a failInfo bit corresponding to the 3635 status code, e.g., systemFailure. 3637 For certificate management the major security goal is integrity and 3638 data origin authentication. For delivery of centrally generated 3639 keys, also confidentiality is a must. These goals are sufficiently 3640 achieved by CMP itself, also in an end-to-end fashion. If a second 3641 line of defense is required or general privacy concerns exist, TLS 3642 can be used to provide confidentiality on a hop-by-hop basis. 3644 TLS SHOULD be used with certificate-based authentication to further 3645 protect the HTTP transfer as described in [RFC2818]. The CMP 3646 transfer via HTTPS MUST use TLS server authentication and SHOULD use 3647 TLS client authentication. 3649 Note: The requirements for checking certificates given in [RFC5280], 3650 [RFC5246], and [RFC8446] MUST be followed for the TLS layer. 3651 Certificate status checking SHOULD be used for the TLS certificates 3652 of all communication partners. 3654 TLS with mutual authentication based on shared secret information MAY 3655 be used in case no suitable certificates for certificate-based 3656 authentication are available, e.g., a PKI management operation with 3657 MAC-based protection is used. 3659 Note: The entropy of the shared secret information is crucial for the 3660 level of protection available using shard secret information-based 3661 TLS authentication. A pre-shared key (PSK) mechanism is acceptable 3662 using shared secret information with an entropy of at least 128 bits. 3663 Otherwise, a password-authenticated key exchange (PAKE) protocol is 3664 RECOMMENDED. 3666 6.2. CoAP transfer 3668 This transfer mechanism can be used by a PKI entity to transfer CMP 3669 messages over CoAP [RFC7252], e.g., in constrained environments. If 3670 CoAP transfer is used the specifications as described in CMP over 3671 CoAP [I-D.ietf-ace-cmpv2-coap-transport] MUST be followed. 3673 PKI management operations SHOULD use URI paths consisting of '/.well- 3674 known/cmp/' followed by an operation label depending on the type of 3675 PKI management operation. 3677 +=======================================+================+=========+ 3678 | PKI management operation | operationLabel | Details | 3679 +=======================================+================+=========+ 3680 | Enroll client to new PKI | /ir | Section | 3681 | | | 4.1.1 | 3682 +---------------------------------------+----------------+---------+ 3683 | Enroll client to existing PKI | /cr | Section | 3684 | | | 4.1.2 | 3685 +---------------------------------------+----------------+---------+ 3686 | Update client certificate | /kur | Section | 3687 | | | 4.1.3 | 3688 +---------------------------------------+----------------+---------+ 3689 | Enroll client using PKCS#10 | /p10 | Section | 3690 | | | 4.1.4 | 3691 +---------------------------------------+----------------+---------+ 3692 | Revoke client certificate | /rr | Section | 3693 | | | 4.2 | 3694 +---------------------------------------+----------------+---------+ 3695 | Get CA certificates | /crts | Section | 3696 | | | 4.3.1 | 3697 +---------------------------------------+----------------+---------+ 3698 | Get root CA certificate update | /rcu | Section | 3699 | | | 4.3.2 | 3700 +---------------------------------------+----------------+---------+ 3701 | Get certificate request template | /att | Section | 3702 | | | 4.3.3 | 3703 +---------------------------------------+----------------+---------+ 3704 | Get CRL updates | /crls | Section | 3705 | | | 4.3.4 | 3706 +---------------------------------------+----------------+---------+ 3707 | Batching messages | /nest | Section | 3708 | | | 5.2.2.2 | 3709 | Note: This path element is applicable | | | 3710 | only between PKI management entities. | | | 3711 +---------------------------------------+----------------+---------+ 3713 Table 10: CoAP endpoints 3715 Independently of any variants used (see Section 4.1.5, Section 4.1.6, 3716 and Section 4.4) the operation label corresponding to the PKI 3717 management operation SHALL be used. 3719 Any certConf or pollReq messages are sent to the same endpoint as 3720 determined by the PKI management operation. 3722 When a single request message is nested as described in 3723 Section 5.2.2.1, the label to use is the same as for the underlying 3724 PKI management operation. 3726 By sending a request to its preferred endpoint, the PKI entity will 3727 recognize via the CoAP response status code whether a configured URI 3728 is supported by the PKI management entity. The CoAP-inherent 3729 discovery mechanisms MAY also be used. 3731 In case a PKI management entity receives an unexpected CoAP status 3732 code from upstream, it MUST respond downstream with an error message 3733 as described in Section 3.6 using a failInfo bit corresponding to the 3734 status code, e.g., systemFailure. 3736 Like for HTTP transfer , to offer a second line of defense or to 3737 provide hop-by-hop privacy protection, DTLS MAY be utilized as 3738 described in CMP over CoAP [I-D.ietf-ace-cmpv2-coap-transport]. 3740 6.3. Piggybacking on other reliable transfer 3742 CMP messages MAY also be transfer on some other reliable protocol. 3743 Connection, delay, and error handling mechanisms similar to those 3744 specified for HTTP in Section 6.1 need to be implemented. 3746 A more detailed specification is out of scope of this document and 3747 would need to be given for instance in the scope of the transfer 3748 protocol used. 3750 6.4. Offline transfer 3752 For transferring CMP messages between PKI entities, any mechanism can 3753 be used that is able to store and forward binary objects of 3754 sufficient length and with sufficient reliability while preserving 3755 the order of messages for each transaction. 3757 The transfer mechanism SHOULD be able to indicate message loss, 3758 excessive delay, and possibly other transmission errors. In such 3759 cases the PKI entities SHOULD report an error as specified in 3760 Section 3.6 as far as possible. 3762 6.4.1. File-based transfer 3764 CMP messages MAY be transferred between PKI entities using file-based 3765 mechanisms, for instance when an offline EE or a PKI management 3766 entity performs delayed delivery. Each file MUST contain the ASN.1 3767 DER encoding of one CMP message only, where the message may be 3768 nested. There MUST be no extraneous header or trailer information in 3769 the file. The file name extension ".pki" MUST be used. 3771 6.4.2. Other asynchronous transfer protocols 3773 Other asynchronous transfer protocols, e.g., email or website 3774 up-/download, MAY transfer CMP messages between PKI entities. A MIME 3775 wrapping is defined for those environments that are MIME-native. The 3776 MIME wrapping in this section is specified in RFC 8551 Section 3.1 3777 [RFC8551]. 3779 The ASN.1 DER encoding of the CMP messages MUST be transferred using 3780 the "application/pkixcmp" content type and base64-encoded content 3781 transfer encoding as specified in [RFC2510], section 5.3. A filename 3782 MUST be included either in a "content-type" or a "content- 3783 disposition" statement. The file name extension ".pki" MUST be used. 3785 7. IANA Considerations 3787 8. Security Considerations 3789 The security considerations as laid out in CMP [RFC4210] updated by 3790 CMP Updates [I-D.ietf-lamps-cmp-updates] and CMP Algorithms 3791 [I-D.ietf-lamps-cmp-algorithms], CRMF [RFC4211] updated by Algorithm 3792 Requirements Update [RFC9045], CMP over HTTP [RFC6712], and CMP over 3793 CoAP [I-D.ietf-ace-cmpv2-coap-transport] apply. 3795 For TLS using shared secret information-based authentication, both 3796 PSK and PAKE provide the same amount of protection against a real- 3797 time authentication attack which is directly the amount of entropy in 3798 the shared secret. The difference between a pre-shared key (PSK) and 3799 a password-authenticated key exchange (PAKE) protocols is in the 3800 level of long-term confidentiality of the TLS messages against brute- 3801 force decryption, where a PSK-based cipher suite only provides 3802 security according to the entropy of the shared secret, while a PAKE- 3803 based cipher suite provides full security independent of the entropy 3804 of the shared secret. 3806 9. Acknowledgements 3808 We thank the various reviewers of this document. 3810 10. References 3812 10.1. Normative References 3814 [I-D.ietf-ace-cmpv2-coap-transport] 3815 Sahni, M. and S. Tripathi, "CoAP Transfer for the 3816 Certificate Management Protocol", Work in Progress, 3817 Internet-Draft, draft-ietf-ace-cmpv2-coap-transport-03, 1 3818 October 2021, . 3821 [I-D.ietf-lamps-cmp-algorithms] 3822 Brockhaus, H., Aschauer, H., Ounsworth, M., and J. Gray, 3823 "Certificate Management Protocol (CMP) Algorithms", Work 3824 in Progress, Internet-Draft, draft-ietf-lamps-cmp- 3825 algorithms-07, 22 August 2021, 3826 . 3829 [I-D.ietf-lamps-cmp-updates] 3830 Brockhaus, H. and D. V. Oheimb, "Certificate Management 3831 Protocol (CMP) Updates", Work in Progress, Internet-Draft, 3832 draft-ietf-lamps-cmp-updates-12, 9 July 2021, 3833 . 3836 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 3837 Requirement Levels", BCP 14, RFC 2119, 3838 DOI 10.17487/RFC2119, March 1997, 3839 . 3841 [RFC2986] Nystrom, M. and B. Kaliski, "PKCS #10: Certification 3842 Request Syntax Specification Version 1.7", RFC 2986, 3843 DOI 10.17487/RFC2986, November 2000, 3844 . 3846 [RFC4210] Adams, C., Farrell, S., Kause, T., and T. Mononen, 3847 "Internet X.509 Public Key Infrastructure Certificate 3848 Management Protocol (CMP)", RFC 4210, 3849 DOI 10.17487/RFC4210, September 2005, 3850 . 3852 [RFC4211] Schaad, J., "Internet X.509 Public Key Infrastructure 3853 Certificate Request Message Format (CRMF)", RFC 4211, 3854 DOI 10.17487/RFC4211, September 2005, 3855 . 3857 [RFC5280] Cooper, D., Santesson, S., Farrell, S., Boeyen, S., 3858 Housley, R., and W. Polk, "Internet X.509 Public Key 3859 Infrastructure Certificate and Certificate Revocation List 3860 (CRL) Profile", RFC 5280, DOI 10.17487/RFC5280, May 2008, 3861 . 3863 [RFC5652] Housley, R., "Cryptographic Message Syntax (CMS)", STD 70, 3864 RFC 5652, DOI 10.17487/RFC5652, September 2009, 3865 . 3867 [RFC5958] Turner, S., "Asymmetric Key Packages", RFC 5958, 3868 DOI 10.17487/RFC5958, August 2010, 3869 . 3871 [RFC6712] Kause, T. and M. Peylo, "Internet X.509 Public Key 3872 Infrastructure -- HTTP Transfer for the Certificate 3873 Management Protocol (CMP)", RFC 6712, 3874 DOI 10.17487/RFC6712, September 2012, 3875 . 3877 [RFC8174] Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC 3878 2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174, 3879 May 2017, . 3881 [RFC8933] Housley, R., "Update to the Cryptographic Message Syntax 3882 (CMS) for Algorithm Identifier Protection", RFC 8933, 3883 DOI 10.17487/RFC8933, October 2020, 3884 . 3886 [RFC9045] Housley, R., "Algorithm Requirements Update to the 3887 Internet X.509 Public Key Infrastructure Certificate 3888 Request Message Format (CRMF)", RFC 9045, 3889 DOI 10.17487/RFC9045, June 2021, 3890 . 3892 10.2. Informative References 3894 [ETSI-3GPP.33.310] 3895 3GPP, "Network Domain Security (NDS); Authentication 3896 Framework (AF)", 3GPP TS 33.310 16.6.0, 16 December 2020. 3898 [I-D.ietf-anima-brski-async-enroll] 3899 Fries, S., Brockhaus, H., Oheimb, D. V., and E. Lear, 3900 "Support of Asynchronous Enrollment in BRSKI (BRSKI-AE)", 3901 Work in Progress, Internet-Draft, draft-ietf-anima-brski- 3902 async-enroll-04, 25 October 2021, 3903 . 3906 [I-D.ietf-anima-brski-prm] 3907 Fries, S., Werner, T., Lear, E., and M. Richardson, "BRSKI 3908 with Pledge in Responder Mode (BRSKI-PRM)", Work in 3909 Progress, Internet-Draft, draft-ietf-anima-brski-prm-00, 3910 25 October 2021, . 3913 [I-D.ietf-netconf-sztp-csr] 3914 Watsen, K., Housley, R., and S. Turner, "Conveying a 3915 Certificate Signing Request (CSR) in a Secure Zero Touch 3916 Provisioning (SZTP) Bootstrapping Request", Work in 3917 Progress, Internet-Draft, draft-ietf-netconf-sztp-csr-09, 3918 22 October 2021, . 3921 [IEC.62443-3-3] 3922 IEC, "Industrial communication networks - Network and 3923 system security - Part 3-3: System security requirements 3924 and security levels", IEC 62443-3-3, August 2013, 3925 . 3927 [IEEE.802.1AR_2018] 3928 IEEE, "IEEE Standard for Local and metropolitan area 3929 networks - Secure Device Identity", IEEE 802.1AR-2018, 3930 DOI 10.1109/IEEESTD.2018.8423794, 2 August 2018, 3931 . 3933 [NIST.CSWP.04162018] 3934 National Institute of Standards and Technology (NIST), 3935 "Framework for Improving Critical Infrastructure 3936 Cybersecurity, Version 1.1", NIST NIST.CSWP.04162018, 3937 DOI 10.6028/NIST.CSWP.04162018, April 2018, 3938 . 3941 [NIST.SP.800-57p1r5] 3942 Barker, E B., "Recommendation for key management, part 1 3943 :general", NIST NIST.SP.800-57pt1r5, 3944 DOI 10.6028/NIST.SP.800-57pt1r5, 2020, 3945 . 3947 [RFC2510] Adams, C. and S. Farrell, "Internet X.509 Public Key 3948 Infrastructure Certificate Management Protocols", 3949 RFC 2510, DOI 10.17487/RFC2510, March 1999, 3950 . 3952 [RFC2818] Rescorla, E., "HTTP Over TLS", RFC 2818, 3953 DOI 10.17487/RFC2818, May 2000, 3954 . 3956 [RFC3647] Chokhani, S., Ford, W., Sabett, R., Merrill, C., and S. 3957 Wu, "Internet X.509 Public Key Infrastructure Certificate 3958 Policy and Certification Practices Framework", RFC 3647, 3959 DOI 10.17487/RFC3647, November 2003, 3960 . 3962 [RFC5246] Dierks, T. and E. Rescorla, "The Transport Layer Security 3963 (TLS) Protocol Version 1.2", RFC 5246, 3964 DOI 10.17487/RFC5246, August 2008, 3965 . 3967 [RFC7030] Pritikin, M., Ed., Yee, P., Ed., and D. Harkins, Ed., 3968 "Enrollment over Secure Transport", RFC 7030, 3969 DOI 10.17487/RFC7030, October 2013, 3970 . 3972 [RFC7252] Shelby, Z., Hartke, K., and C. Bormann, "The Constrained 3973 Application Protocol (CoAP)", RFC 7252, 3974 DOI 10.17487/RFC7252, June 2014, 3975 . 3977 [RFC8366] Watsen, K., Richardson, M., Pritikin, M., and T. Eckert, 3978 "A Voucher Artifact for Bootstrapping Protocols", 3979 RFC 8366, DOI 10.17487/RFC8366, May 2018, 3980 . 3982 [RFC8446] Rescorla, E., "The Transport Layer Security (TLS) Protocol 3983 Version 1.3", RFC 8446, DOI 10.17487/RFC8446, August 2018, 3984 . 3986 [RFC8551] Schaad, J., Ramsdell, B., and S. Turner, "Secure/ 3987 Multipurpose Internet Mail Extensions (S/MIME) Version 4.0 3988 Message Specification", RFC 8551, DOI 10.17487/RFC8551, 3989 April 2019, . 3991 [RFC8572] Watsen, K., Farrer, I., and M. Abrahamsson, "Secure Zero 3992 Touch Provisioning (SZTP)", RFC 8572, 3993 DOI 10.17487/RFC8572, April 2019, 3994 . 3996 [RFC8995] Pritikin, M., Richardson, M., Eckert, T., Behringer, M., 3997 and K. Watsen, "Bootstrapping Remote Secure Key 3998 Infrastructure (BRSKI)", RFC 8995, DOI 10.17487/RFC8995, 3999 May 2021, . 4001 [UNISIG.Subset-137] 4002 UNISIG, "Subset-137; ERTMS/ETCS On-line Key Management 4003 FFFIS; V1.0.0", December 2015, 4004 . 4006 Appendix A. Example CertReqTemplate 4008 Suppose the server requires that the certTemplate contains 4010 * the issuer field with a value to be filled in by the EE, 4012 * the subject field with a common name to be filled in by the EE and 4013 two organizational unit fields with given values "myDept" and 4014 "myGroup", 4016 * the publicKey field contains an ECC key on curve secp256r1 or an 4017 RSA public key of length 2048, 4019 * the subjectAltName extension with DNS name "www.myServer.com" and 4020 an IP address to be filled in, 4022 * the keyUsage extension marked critical with the value 4023 digitalSignature and keyAgreement, and 4025 * the extKeyUsage extension with values to be filled in by the EE. 4027 Then the infoValue with certTemplate and keySpec fields returned to 4028 the EE will be encoded as follows: 4030 SEQUENCE { 4031 SEQUENCE { 4032 [3] { 4033 SEQUENCE {} 4034 } 4035 [5] { 4036 SEQUENCE { 4037 SET { 4038 SEQUENCE { 4039 OBJECT IDENTIFIER commonName (2 5 4 3) 4040 UTF8String "" 4041 } 4042 } 4043 SET { 4044 SEQUENCE { 4045 OBJECT IDENTIFIER organizationalUnitName (2 5 4 11) 4046 UTF8String "myDept" 4047 } 4049 } 4050 SET { 4051 SEQUENCE { 4052 OBJECT IDENTIFIER organizationalUnitName (2 5 4 11) 4053 UTF8String "myGroup" 4054 } 4055 } 4056 } 4057 } 4058 [9] { 4059 SEQUENCE { 4060 OBJECT IDENTIFIER subjectAltName (2 5 29 17) 4061 OCTET STRING, encapsulates { 4062 SEQUENCE { 4063 [2] "www.myServer.com" 4064 [7] "" 4065 } 4066 } 4067 } 4068 SEQUENCE { 4069 OBJECT IDENTIFIER keyUsage (2 5 29 15) 4070 BOOLEAN TRUE 4071 OCTET STRING, encapsulates { 4072 BIT STRING 3 unused bits 4073 "10001"B 4074 } 4075 } 4076 SEQUENCE { 4077 OBJECT IDENTIFIER extKeyUsage (2 5 29 37) 4078 OCTET STRING, encapsulates { 4079 SEQUENCE {} 4080 } 4081 } 4082 } 4083 } 4084 SEQUENCE { 4085 SEQUENCE { 4086 OBJECT IDENTIFIER aldId (1 3 6 1 5 5 7 5 1 11) 4087 SEQUENCE { 4088 OBJECT IDENTIFIER ecPublicKey (1 2 840 10045 2 1) 4089 OBJECT IDENTIFIER secp256r1 (1 2 840 10045 3 1 7) 4090 } 4091 } 4092 SEQUENCE { 4093 OBJECT IDENTIFIER rsaKeyLen (1 3 6 1 5 5 7 5 1 12) 4094 INTEGER 2048 4095 } 4096 } 4098 } 4100 Appendix B. History of changes 4102 Note: This appendix will be deleted in the final version of the 4103 document. 4105 From version 06 -> 07: 4107 * Added references to [draft-ietf-netconf-sztp-csr] in new 4108 Section 1.5 and Section 4.1.4 4109 * Added reference to [I-D.ietf-anima-brski-async-enroll] in new 4110 Section 1.5 and Section 4.1.1 4111 * Changed reference in Section 2 to [I-D.ietf-anima-brski-prm] as 4112 the PUSH use case is continued to be discussed in this draft after 4113 the split of BRSKI-AE 4114 * Improved note regarding UNISIG Subset-137 in Section 1.6 4115 * Removed "rootCaCert" in Section 3.1 and updated the structure of 4116 the genm request for root CA certificate updates in Section 4.3.2. 4117 * Simplified handling of sender and recipient nonces in case of 4118 delayed delivery in Sections 3.1, 3.5, 4.4, and 5.1.2 4119 * Changed the order of Sections 4.1.4 and 4.1.5 4120 * Added reference on RFC 8933 regarding CMS signedAttrs to 4121 Section 4.1.6 4122 * Added Section 4.3.4 on CRL update retrieval 4123 * Generalized delayed enrollment to delayed delivery in Section 4.4 4124 and 5.1.2, updated the state machine in the introduction of 4125 Section 4 4126 * Updated Section 6 regarding delayed message transfer 4127 * Changed file name extension from ".PKI" to ".pki", deleted 4128 operational path for central key generation, and added an 4129 operational path for CRL update retrieval in Sections 6.1 and 6.2 4130 * Shifted many security considerations to CMP Updates 4131 * Replaced the term "transport" by "transfer" where appropriate to 4132 prevent confusion regarding TCP vs. HTTP and CoAP 4133 * Various editorial changes and language corrections 4135 From version 05 -> 06: 4137 * Changed in Section 2.3 the normative requirement in of adding 4138 protection to a single message to mandatory and replacing 4139 protection to optional 4140 * Added Section 3.4 specifying generic prerequisites to PKI 4141 management operations 4142 * Added Section 3.5 specifying generic message validation 4143 * Added Section 3.6 on generic error reporting. This section 4144 replaces the former error handling section from Section 4 and 5. 4145 * Added reference to using hashAlg 4146 * Updates Section 4.3.2 and Section 4.3.3 to align with CMP Updates 4147 * Added Section 5.1 specifying the behavior of PKI management 4148 entities when responding to requests 4149 * Reworked Section 5.2.3. on usage of nested messages 4150 * Updates Section 5.3 on performing PKI management operation on 4151 behalf of another entity 4152 * Updates Section 6.2 on HTTPS transport of CMP messages as 4153 discusses at IETF 110 and email thread "I-D Action: draft-ietf- 4154 lamps-lightweight-cmp-profile-05.txt" 4155 * Added CoAP endpoints to Section 6.4 4156 * Added security considerations on usage of shared secret 4157 information 4158 * Updated the example in Appendix A 4159 * Added newly registered OIDs to the example in Appendix A 4160 * Updated new RFC numbers for I-D.ietf-lamps-crmf-update-algs 4161 * Multiple language corrections, clarifications, and changes in 4162 wording 4164 From version 04 -> 05: 4166 * Changed to XML V3 4167 * Added algorithm names introduced in CMP Algorithms Section 7.3 to 4168 Section 4 of this document 4169 * Updates Syntax in Section 4.4.3 due to changes made in CMP Updates 4170 * Deleted the text on HTTP-based discovery as discussed in 4171 Section 6.1 4172 * Updates Appendix A due to change syntax in Section 4.4.3 4173 * Many clarifications and changes in wording thanks to David's 4174 extensive review 4176 From version 03 -> 04: 4178 * Deleted normative text sections on algorithms and refer to CMP 4179 Algorithms and CRMF Algorithm Requirements Update instead 4180 * Some clarifications and changes in wording 4182 From version 02 -> 03: 4184 * Updated the interoperability with [UNISIG.Subset-137] in 4185 Section 1.4. 4186 * Changed Section 2.3 to a tabular layout to enhanced readability 4187 * Added a ToDo to section 3.1 on aligning with the CMP Algorithms 4188 draft that will be set up as decided in IETF 108 4189 * Updated section 4.1.6 to add the AsymmetricKey Package structure 4190 to transport a newly generated private key as decided in IETF 108 4191 * Added a ToDo to section 4.1.7 on required review of the nonce 4192 handling in case an offline LRA responds and not forwards the 4193 pollReq messages 4195 * Updated Section 4 due to the definition of the new ITAV OIDs in 4196 CMP Updates 4197 * Updated Section 4.4.4 to utilize controls instead of rsaKeyLen 4198 (see thread "dtaft-ietf-lamps-cmp-updates and rsaKeyLen") 4199 * Deleted the section on definition and discovery of HTTP URIs and 4200 copied the text to the HTTP transport section and to CMP Updates 4201 section 3.2 4202 * Added some explanation to Section 5.1.2 and Section 5.1.3 on using 4203 nested messages when a protection by the RA is required. 4204 * Deleted the section on HTTP URI definition and discovery as some 4205 content was moved to CMP Updates. The rest of the content was 4206 moved back to the HTTP transport section 4207 * Deleted the ASN.1 module after moving the new OIDs id-it-caCerts, 4208 id-it-rootCaKeyUpdate, and id-it-certReqTemplate to CMP Updates 4209 * Minor changes in wording and addition of some open ToDos 4211 From version 01 -> 02: 4213 * Extend Section 1.6 with regard to conflicts with UNISIG Subset- 4214 137. 4215 * Minor clarifications on extraCerts in Section 3.3 and 4216 Section 4.1.1. 4217 * Complete specification of requesting a certificate from a trusted 4218 PKI with signature protection in Section 4.1.2. 4219 * Changed from symmetric key-encryption to password-based key 4220 management technique in section Section 4.1.6.3 as discussed on 4221 the mailing list (see thread "draft-ietf-lamps-lightweight-cmp- 4222 profile-01, section 5.1.6.1") 4223 * Changed delayed enrollment described in Section 4.4 from 4224 recommended to optional as decided at IETF 107 4225 * Introduced the new RootCAKeyUpdate structure for root CA 4226 certificate update in Section 4.3.2 as decided at IETF 107 (also 4227 see email thread "draft-ietf-lamps-lightweight-cmp-profile-01, 4228 section 5.4.3") 4229 * Extend the description of the CertReqTemplate PKI management 4230 operation, including an example added in the Appendix. Keep 4231 rsaKeyLen as a single integer value in Section 4.3.3 as discussed 4232 on the mailing list (see thread "draft-ietf-lamps-lightweight-cmp- 4233 profile-01, section 5.4.4") 4234 * Deleted Sections "Get certificate management configuration" and 4235 "Get enrollment voucher" as decided at IETF 107 4236 * Complete specification of adding an additional protection by an 4237 PKI management entity in Section 5.2.2. 4238 * Added a section on HTTP URI definition and discovery and extended 4239 Section 6.1 on definition and discovery of supported HTTP URIs and 4240 content types, add a path for nested messages as specified in 4241 Section 5.2.2 and delete the paths for /getCertMgtConfig and 4242 /getVoucher 4244 * Changed Section 6.4 to address offline transport and added more 4245 detailed specification file-based transport of CMP 4246 * Added a reference to the new I-D of Mohit Sahni on "CoAP Transport 4247 for CMPV2" in Section 6.2; thanks to Mohit supporting the effort 4248 to ease utilization of CMP 4249 * Moved the change history to the Appendix 4250 * Minor changes in wording 4252 From version 00 -> 01: 4254 * Harmonize terminology with CMP [RFC4210], e.g., 4255 - transaction, message sequence, exchange, use case -> PKI 4256 management operation 4257 - PKI component, (L)RA/CA -> PKI management entity 4258 * Minor changes in wording 4260 From draft-brockhaus-lamps-lightweight-cmp-profile-03 -> draft-ietf- 4261 lamps-lightweight-cmp-profile-00: 4263 * Changes required to reflect WG adoption 4264 * Minor changes in wording 4266 From version 02 -> 03: 4268 * Added a short summary of [RFC4210] Appendix D and E in 4269 Section 1.4. 4270 * Clarified some references to different sections and added some 4271 clarification in response to feedback from Michael Richardson and 4272 Tomas Gustavsson. 4273 * Added an additional label to the operational path to address 4274 multiple CAs or certificate profiles in Section 6.1. 4276 From version 01 -> 02: 4278 * Added some clarification on the key management techniques for 4279 protection of centrally generated keys in Section 4.1.6. 4280 * Added some clarifications on the certificates for root CA 4281 certificate update in Section 4.3.2. 4282 * Added a section to specify the usage of nested messages for RAs to 4283 add an additional protection for further discussion, see 4284 Section 5.2.2. 4285 * Added a table containing endpoints for HTTP transport in 4286 Section 6.1 to simplify addressing PKI management entities. 4287 * Added some ToDos resulting from discussion with Tomas Gustavsson. 4288 * Minor clarifications and changes in wording. 4290 From version 00 -> 01: 4292 * Added a section to specify the enrollment with an already trusted 4293 PKI for further discussion, see Section 4.1.2. 4294 * Complete specification of requesting a certificate from a legacy 4295 PKI using a PKCS#10 [RFC2986] request in Section 4.1.4. 4296 * Complete specification of adding central generation of a key pair 4297 on behalf of an end entity in Section 4.1.6. 4298 * Complete specification of handling delayed enrollment due to 4299 asynchronous message delivery in Section 4.4. 4300 * Complete specification of additional support messages, e.g., to 4301 update a Root CA certificate or to request an RFC 8366 [RFC8366] 4302 voucher, in Section 4.3. 4303 * Minor changes in wording. 4305 From draft-brockhaus-lamps-industrial-cmp-profile-00 -> draft- 4306 brockhaus-lamps-lightweight-cmp-profile-00: 4308 * Change focus from industrial to more multi-purpose use cases and 4309 lightweight CMP profile. 4310 * Incorporate the omitted confirmation into the header specified in 4311 Section 3.1 and described in the standard enrollment use case in 4312 Section 4.1.1 due to discussion with Tomas Gustavsson. 4313 * Change from OPTIONAL to RECOMMENDED for use case 'Revoke another's 4314 entities certificate' in Section 5.3.2, because it is regarded as 4315 important functionality in many environments to enable the 4316 management station to revoke EE certificates. 4317 * Complete the specification of the revocation message flow in 4318 Section 4.2 and Section 5.3.2. 4319 * The CoAP based transport mechanism and piggybacking of CMP 4320 messages on top of other reliable transport protocols is out of 4321 scope of this document and would need to be specified in another 4322 document. 4323 * Further minor changes in wording. 4325 Authors' Addresses 4327 Hendrik Brockhaus (editor) 4328 Siemens AG 4330 Email: hendrik.brockhaus@siemens.com 4332 Steffen Fries 4333 Siemens AG 4335 Email: steffen.fries@siemens.com 4336 David von Oheimb 4337 Siemens AG 4339 Email: david.von.oheimb@siemens.com