idnits 2.17.1 draft-ietf-lamps-lightweight-cmp-profile-08.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 '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. -- The document date (19 November 2021) is 883 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 -- 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-04 == Outdated reference: A later version (-15) exists of draft-ietf-lamps-cmp-algorithms-08 == Outdated reference: A later version (-23) exists of draft-ietf-lamps-cmp-updates-13 ** 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-11 -- 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 (~~), 12 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 D. von Oheimb 4 Intended status: Standards Track S. Fries 5 Expires: 23 May 2022 Siemens 6 19 November 2021 8 Lightweight Certificate Management Protocol (CMP) Profile 9 draft-ietf-lamps-lightweight-cmp-profile-08 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 23 May 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 Revised BSD License text as 53 described in Section 4.e of the Trust Legal Provisions and are 54 provided without warranty as described in the Revised 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 . . . . . . . . . . . . . 67 116 5.1.3. Responding to a confirmation message . . . . . . . . 68 117 5.1.4. Responding to a revocation request . . . . . . . . . 68 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 . . . . . 71 122 5.2.2.1. Adding protection to a request message . . . . . 72 123 5.2.2.2. Batching messages . . . . . . . . . . . . . . . . 73 124 5.2.3. Replacing protection . . . . . . . . . . . . . . . . 75 125 5.2.3.1. Not changing any included proof-of-possession . . 75 126 5.2.3.2. Breaking proof-of-possession . . . . . . . . . . 76 127 5.3. Acting on behalf of other PKI entities . . . . . . . . . 76 128 5.3.1. Requesting certificates . . . . . . . . . . . . . . . 77 129 5.3.2. Revoking a certificate . . . . . . . . . . . . . . . 77 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 . . . . . . . . . . . . . . . . . . . . . . . 96 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 root CA usable only 988 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 1334 sending 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 a trust anchor if it is the root CA certificate of the certificate 1412 used for protecting the message. 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 implicit 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 subjectKeyIdentifier of the certificate, 2183 -- and thereby identifies the sender's public key. 2184 -- MUST contain the same value as the senderKID in the 2185 -- message header 2186 ukm RECOMMENDED 2187 -- MUST be used when 1-pass ECMQV is used 2188 -- SHOULD be present to ensure uniqueness of the key 2189 -- encryption key 2190 keyEncryptionAlgorithm 2191 REQUIRED 2192 -- MUST be the algorithm identifier of the key agreement 2193 -- algorithm 2194 -- The algorithm type MUST be a KM_KA_ALG as specified in 2195 -- RFC-CMP-Alg Section 4.1 2196 -- The parameters field of the key agreement algorithm MUST 2197 -- contains the key wrap algorithm 2198 -- The algorithm type MUST be a KM_KW_ALG as specified in 2199 -- RFC-CMP-Alg Section 4.3 2200 recipientEncryptedKeys 2201 REQUIRED 2202 -- MUST contain exactly one RecipientEncryptedKey element 2203 rid REQUIRED 2204 -- MUST contain the rKeyId choice 2205 rKeyId REQUIRED 2206 subjectKeyIdentifier 2207 REQUIRED 2208 -- MUST contain the same value as the senderKID in the 2209 -- respective request message header 2210 encryptedKey 2211 REQUIRED 2212 -- MUST be the encrypted content-encryption key 2214 4.1.6.2. Using key transport key management technique 2216 This variant can be applied in combination with the PKI management 2217 operations specified in Section 4.1.1 to Section 4.1.3 using 2218 signature-based protection of CMP messages. The EE certificate used 2219 for the signature-based protection of the request message MUST allow 2220 for the key usage "keyEncipherment" and not for "keyAgreement". 2221 Therefore, the related key pair MUST be used for encipherment of the 2222 content-encryption key. For this key management technique, the 2223 KeyTransRecipientInfo structure MUST be used in the contentInfo 2224 field. 2226 The KeyTransRecipientInfo structure included into the EnvelopedData 2227 structure is specified in CMS Section 6.2.1 [RFC5652]. 2229 The detailed description of the KeyTransRecipientInfo structure looks 2230 like this: 2232 ktri REQUIRED 2233 -- MUST be a KeyTransRecipientInfo as specified in CMS 2234 -- Section 6.2.1 [RFC5652] 2235 version REQUIRED 2236 -- MUST be 2 2237 rid REQUIRED 2238 -- MUST contain the subjectKeyIdentifier choice 2239 subjectKeyIdentifier 2240 REQUIRED 2241 -- MUST contain the same value as the senderKID in the 2242 -- respective request message header 2243 keyEncryptionAlgorithm 2244 REQUIRED 2245 -- MUST be the algorithm identifier of the key transport 2246 -- algorithm 2247 -- The algorithm type MUST be a KM_KT_ALG as specified in 2248 -- RFC-CMP-Alg Section 4.2 2249 encryptedKey REQUIRED 2250 -- MUST be the encrypted content-encryption key 2252 4.1.6.3. Using password-based key management technique 2254 This variant can be applied in combination with the PKI management 2255 operation specified in Section 4.1.5 using MAC-based protection of 2256 CMP messages. The shared secret information used for the MAC-based 2257 protection MUST also be used for the encryption of the content- 2258 encryption key but with a different salt value applied in the key 2259 derivation algorithm. For this key management technique, the 2260 PasswordRecipientInfo structure MUST be used in the contentInfo 2261 field. 2263 Note: The entropy of the shared secret information is crucial for the 2264 level of protection when using a password-based key management 2265 technique. For centrally generated key pairs, the entropy of the 2266 shared secret information SHALL NOT be less than the security 2267 strength of the centrally generated key pair. Further guidance is 2268 available in Section 8. 2270 The PasswordRecipientInfo structure included into the EnvelopedData 2271 structure is specified in CMS Section 6.2.4 [RFC5652]. 2273 The detailed description of the PasswordRecipientInfo structure looks 2274 like this: 2276 pwri REQUIRED 2277 -- MUST be a PasswordRecipientInfo as specified in CMS 2278 -- Section 6.2.4 [RFC5652] 2279 version REQUIRED 2280 -- MUST be 0 2281 keyDerivationAlgorithm 2282 REQUIRED 2283 -- MUST be the algorithm identifier of the key derivation 2284 -- algorithm 2285 -- The algorithm type MUST be a KM_KD_ALG as specified in 2286 -- RFC-CMP-Alg Section 4.4 2287 keyEncryptionAlgorithm 2288 REQUIRED 2289 -- MUST be the algorithm identifier of the key wrap algorithm 2290 -- The algorithm type MUST be a KM_KW_ALG as specified in 2291 -- RFC-CMP-Alg Section 4.3 2292 encryptedKey REQUIRED 2293 -- MUST be the encrypted content-encryption key 2295 4.2. Revoking a certificate 2297 This PKI management operation should be used by an entity to request 2298 revocation of a certificate. Here the revocation request is used by 2299 an EE to revoke one of its own certificates. 2301 The revocation request message MUST be signed using the certificate 2302 that is to be revoked to prove the authorization to revoke. The 2303 revocation request message is signature-protected using this 2304 certificate. This requires, that the EE still possesses the private 2305 key. If this is not the case the revocation has to be initiated by 2306 other means, e.g., revocation by the RA as specified in 2307 Section 5.3.2. 2309 An EE requests the revocation of an own certificate at the CA that 2310 issued this certificate. The PKI management entity handles the 2311 request as described in Section 5.1.4 and responds with a message 2312 that contains the status of the revocation from the CA. 2314 Specific prerequisites augmenting the prerequisites in Section 3.4: 2316 * The certificate the EE wishes to revoke is not yet expired or 2317 revoked. 2319 Message flow: 2321 Step# EE PKI management entity 2322 1 format rr 2323 2 -> rr -> 2324 3 handle or forward rr 2325 4 format or receive rp 2326 5 <- rp <- 2327 6 handle rp 2329 For this PKI management operation, the EE MUST include exactly one 2330 RevDetails structure in the rr message body. In case no generic 2331 error occurred the response to the rr MUST be an rp message 2332 containing a single status field. 2334 Detailed message description: 2336 Revocation Request -- rr 2338 Field Value 2340 header 2341 -- As described in Section 3.1 2343 body 2344 -- The request of the EE to revoke its certificate 2345 rr REQUIRED 2346 -- MUST contain exactly one element of type RevDetails 2347 -- If more revocations are desired, further PKI management 2348 -- operations MUST be initiated 2349 certDetails REQUIRED 2350 -- MUST be present and is of type CertTemplate 2351 serialNumber REQUIRED 2352 -- MUST contain the certificate serialNumber attribute of the 2353 -- certificate to be revoked 2354 issuer REQUIRED 2355 -- MUST contain the issuer attribute of the certificate to be 2356 -- revoked 2357 crlEntryDetails REQUIRED 2358 -- MUST contain exactly one reasonCode of type CRLReason (see 2359 -- [RFC5280] section 5.3.1) 2360 -- If the reason for this revocation is not known or shall not 2361 -- be published the reasonCode MUST be 0 = unspecified 2363 protection REQUIRED 2364 -- As described in Section 3.2 and using the private key related 2365 -- to the certificate to be revoked 2367 extraCerts REQUIRED 2368 -- As described in Section 3.3 2370 Revocation Response -- rp 2372 Field Value 2374 header 2375 -- As described in Section 3.1 2377 body 2378 -- The responds of the PKI management entity to the request as 2379 -- appropriate 2380 rp REQUIRED 2381 status REQUIRED 2382 -- MUST contain exactly one element of type PKIStatusInfo 2383 status REQUIRED 2384 -- positive value allowed: "accepted" 2385 -- negative value allowed: "rejection" 2386 statusString OPTIONAL 2387 -- MAY be any human-readable text for debugging, logging or to 2388 -- display in a GUI 2389 failInfo OPTIONAL 2390 -- MAY be present if status is "rejection" 2391 -- MUST be absent if the status is "accepted" 2393 protection REQUIRED 2394 -- As described in section 3.2 2396 extraCerts REQUIRED 2397 -- As described in section 3.3 2399 4.3. Support messages 2401 The following support messages offer on demand in-band delivery of 2402 content relevant to the EE provided by a PKI management entity. CMP 2403 general messages and general response are used for this purpose. 2404 Depending on the environment, these requests may be answered by an RA 2405 or CA (see also Section 5.1.5). 2407 The general messages and general response messages contain 2408 InfoTypeAndValue structures. In addition to those infoType values 2409 defined in RFC 4210 [RFC4210] and CMP Updates 2410 [I-D.ietf-lamps-cmp-updates] further OIDs MAY be used to define new 2411 PKI management operations or new general-purpose support messages as 2412 needed in specific environments. 2414 The following contents are specified in this document: 2416 * Get CA certificates 2418 * Get root CA certificate update 2420 * Get certificate request template 2422 * Get new CRLs 2424 In the following the aspects common to all general messages (genm) 2425 and general response (genp) messages are described. 2427 Message flow: 2429 Step# EE PKI management entity 2430 1 format genm 2431 2 -> genm -> 2432 3 handle or forward genm 2433 4 format or receive genp 2434 5 <- genp <- 2435 6 handle genp 2437 Detailed message description: 2439 General Message -- genm 2441 Field Value 2443 header 2444 -- As described in Section 3.1 2446 body 2447 -- A request by the EE for information 2448 genm REQUIRED 2449 -- MUST contain exactly one element of type InfoTypeAndValue 2450 infoType REQUIRED 2451 -- MUST be the OID identifying one of the specific PKI 2452 -- management operations described below 2453 infoValue OPTIONAL 2454 -- MUST be as specified for the specific PKI management operation 2456 protection REQUIRED 2457 -- As described in Section 3.2 2459 extraCerts REQUIRED 2460 -- As described in Section 3.3 2462 General Response -- genp 2464 Field Value 2466 header 2467 -- As described in Section 3.1 2469 body 2470 -- The response of the PKI management entity providing 2471 -- information 2472 genp REQUIRED 2473 -- MUST contain exactly one element of type InfoTypeAndValue 2474 infoType REQUIRED 2475 -- MUST be the OID identifying the specific PKI management 2476 -- operation described below 2477 infoValue OPTIONAL 2478 -- MUST be as specified for the specific PKI management operation 2480 protection REQUIRED 2481 -- As described in Section 3.2 2483 extraCerts REQUIRED 2484 -- As described in Section 3.3 2486 4.3.1. Get CA certificates 2488 This PKI management operation can be used by an EE to request CA 2489 certificates from the PKI management entity. 2491 An EE requests CA certificates, e.g., for chain construction, from an 2492 PKI management entity by sending a general message with OID id-it- 2493 caCerts as specified in CMP Updates [I-D.ietf-lamps-cmp-updates]. 2494 The PKI management entity responds with a general response with the 2495 same OID that either contains a SEQUENCE of certificates populated 2496 with the available intermediate and issuing CA certificates or with 2497 no content in case no CA certificate is available. 2499 No specific prerequisites apply in addition to those specified in 2500 Section 3.4. 2502 The message sequence for this PKI management operation is as given 2503 above, with the following specific content: 2505 1 the infoType OID to use is id-it-caCerts 2507 2 the infoValue of the request MUST be absent 2509 3 if present, the infoValue of the response MUST contain a sequence 2510 of certificates 2512 The infoValue field of the general response containing the id-it- 2513 caCerts OID looks like this: 2515 infoValue OPTIONAL 2516 -- MUST be absent if no CA certificate is available 2517 -- MUST be present if CA certificates are available 2518 -- MUST be a sequence of CMPCertificate 2520 4.3.2. Get root CA certificate update 2522 This PKI management operation can be used by an EE to request an 2523 updated root CA Certificate as described in Section 4.4 of RFC 4210 2524 [RFC4210]. 2526 An EE requests an update of a root CA certificate from the PKI 2527 management entity by sending a general message with OID id-it- 2528 rootCaCert, which SHOULD include the old root CA certificate in the 2529 message body, as specified in CMP Updates 2530 [I-D.ietf-lamps-cmp-updates]. The PKI management entity responds 2531 with a general response with OID id-it-rootCaKeyUpdate that either 2532 contains the update of the root CA certificate consisting of up to 2533 three certificates, or with no content in case no update is 2534 available. 2536 Note: This mechanism may also be used to update trusted non-root 2537 certificates, i.e., trusted intermediate CA or issuing CA 2538 certificates. 2540 The newWithNew certificate is the new root CA certificate and is 2541 REQUIRED to be present if available. The newWithOld certificate is 2542 REQUIRED to be present in the response message because it is needed 2543 for the receiving entity trusting the old root CA certificate to gain 2544 trust in the new root CA certificate. The oldWithNew certificate is 2545 OPTIONAL because it is only needed in rare scenarios where entities 2546 do not already trust the old root CA. 2548 No specific prerequisites apply in addition to those specified in 2549 Section 3.4. 2551 The message sequence for this PKI management operation is as given 2552 above, with the following specific content: 2554 1 the infoType OID to use is id-it-rootCaCert in the request and id- 2555 it-rootCaKeyUpdate in the response 2557 2 the infoValue of the request SHOULD contain the root CA 2558 certificate the update is requested for 2560 3 if present, the infoValue of the response MUST be a 2561 RootCaKeyUpdateContent structure 2563 The infoValue field of the general request containing the id-it- 2564 rootCaCert OID looks like this: 2566 infoValue RECOMMENDED 2567 -- MUST contain the root CA certificate to be updated, if 2568 -- available 2570 The infoValue field of the general response containing the id-it- 2571 rootCaKeyUpdate OID looks like this: 2573 infoValue OPTIONAL 2574 -- MUST be absent if no update of the root CA certificate is 2575 -- available 2576 -- MUST be present if an update of the root CA certificate 2577 -- is available and MUST be of type RootCaKeyUpdateContent 2578 newWithNew REQUIRED 2579 -- MUST be present if infoValue is present 2580 -- MUST contain the new root CA certificate 2581 newWithOld REQUIRED 2582 -- MUST be present if infoValue is present 2583 -- MUST contain a certificate containing the new public 2584 -- root CA key signed with the old private root CA key 2585 oldWithNew OPTIONAL 2586 -- MAY be present if infoValue is present 2587 -- MUST contain a certificate containing the old public 2588 -- root CA key signed with the new private root CA key 2590 4.3.3. Get certificate request template 2592 This PKI management operation can be used by an EE to request a 2593 template with parameters for future certificate requests. 2595 An EE requests certificate request parameters from the PKI management 2596 entity by sending a general message with OID id-it-certReqTemplate as 2597 specified in CMP Updates [I-D.ietf-lamps-cmp-updates]. The EE MAY 2598 indicate the certificate profile to use in the id-it-certProfile 2599 extension of the generalInfo field in the PKIHeader of the general 2600 message as described in Section 3.1. The PKI management entity 2601 responds with a general response with the same OID that either 2602 contains requirements on the certificate request template, or with no 2603 content in case no specific requirements are imposed by the PKI. The 2604 CertReqTemplateValue contains requirements on certificate fields and 2605 extensions in a certTemplate. Optionally it contains a keySpec field 2606 containing requirements on algorithms acceptable for key pair 2607 generation. 2609 The EE SHOULD follow the requirements from the received CertTemplate, 2610 by including in the certificate requests all the fields requested, 2611 taking over all the field values provided and filling in any 2612 remaining fields values. The EE SHOULD NOT add further fields, name 2613 components, and extensions or their (sub-)components. 2615 Note: We deliberately do not use "MUST" or "MUST NOT" here in order 2616 to allow more flexibility in case the rules given here are not 2617 sufficient for specific scenarios. The EE can populate the 2618 certificate request as wanted and ignore any of the requirements 2619 contained in the CertReqTemplateValue. On the other hand, a PKI 2620 management entity is free to ignore or replace any parts of the 2621 content of the certificate request provided by the EE. The 2622 CertReqTemplate PKI management operation offers means to ease a joint 2623 understanding which fields and/or which field values should be used. 2624 An example is provided in Appendix A. 2626 In case a field of type Name, e.g., subject, is present in the 2627 CertTemplate but has the value NULL-DN (i.e., has an empty list of 2628 RDN components), the field SHOULD be included in the certificate 2629 request and filled with content provided by the EE. Similarly, in 2630 case an X.509v3 extension is present but its extnValue is empty, this 2631 means that the extension SHOULD be included and filled with content 2632 provided by the EE. In case a Name component, for instance a common 2633 name or serial number, is given but has an empty string value, the EE 2634 SHOULD fill in a value. Similarly, in case an extension has sub- 2635 components (e.g., an IP address in a SubjectAltName field) with empty 2636 value, the EE SHOULD fill in a value. 2638 The EE MUST ignore (i.e., not include and fill in) empty fields, 2639 extensions, and sub-components that it does not understand or does 2640 not know suitable values to be filled in. 2642 The publicKey field of type SubjectPublicKeyInfo in the CertTemplate 2643 of the CertReqTemplateValue MUST be omitted. In case the PKI 2644 management entity wishes to make stipulation on algorithms the EE may 2645 use for key generation, this MUST be specified using the keySpec 2646 field as specified in CMP Updates [I-D.ietf-lamps-cmp-updates]. 2648 The keySpec field, if present, specifies the public key types 2649 optionally with parameters, and/or RSA key lengths for which a 2650 certificate may be requested. 2652 The value of a keySpec element with the OID id-regCtrl-algId, as 2653 specified in CMP Updates [I-D.ietf-lamps-cmp-updates], MUST be of 2654 type AlgorithmIdentifier and give an algorithm other than RSA. For 2655 EC keys the curve information MUST be specified as described in the 2656 respective standard documents. 2658 The value of a keySpec element with the OID id-regCtrl-rsaKeyLen, as 2659 specified in CMP Updates [I-D.ietf-lamps-cmp-updates], MUST be a 2660 positive integer value and give an RSA key length. 2662 In the CertTemplate of the CertReqTemplateValue the serialNumber, 2663 signingAlg, issuerUID, and subjectUID fields MUST be omitted. 2665 Specific prerequisites augmenting the prerequisites in Section 3.4: 2667 * When using the generalInfo field certProfile, the EE MUST know the 2668 identifier needed to indicate the requested certificate profile. 2670 The message sequence for this PKI management operation is as given 2671 above, with the following specific content: 2673 1 the infoType OID to use is id-it-certReqTemplate 2675 2 the id-it-certProfile generalInfo field in the header of the 2676 request MAY contain the name of the requested certificate request 2677 template 2679 3 the infoValue of the request MUST be absent 2681 4 if present, the infoValue of the response MUST be a 2682 CertReqTemplateValue containing a CertTemplate structure and an 2683 optional keySpec field 2685 The infoValue field of the general response containing the id-it- 2686 certReqTemplate OID looks like this: 2688 InfoValue OPTIONAL 2689 -- MUST be absent if no requirements are available 2690 -- MUST be present if the PKI management entity has any 2691 -- requirements on the contents of the certificate template 2692 certTemplate REQUIRED 2693 -- MUST be present if infoValue is present 2694 -- MUST contain the required CertTemplate structure elements 2695 -- The SubjectPublicKeyInfo field MUST be absent 2696 keySpec OPTIONAL 2697 -- MUST be absent if no requirements on the public key are 2698 -- available 2699 -- MUST be present if the PKI management entity has any 2700 -- requirements on the keys generated 2701 -- MUST contain one AttributeTypeAndValue per supported 2702 -- algorithm with attribute id-regCtrl-algId or 2703 -- id-regCtrl-rsaKeyLen 2705 4.3.4. CRL update retrieval 2707 This PKI management operation can be used by an EE to request a new 2708 CRL. If a CA offers methods to access a CRL they are often provided 2709 by the CA through the CRLDP or AuthorityInfoAccess as specified in 2710 [RFC5280] components in the issued certificates. In addition, CMP 2711 offers this functionality as part of the PKI management operation. 2713 An EE requests a CRL update from the PKI management entity by sending 2714 a general message with OID id-it-crlStatusList. This MUST include 2715 the CRL source and, if available, the thisUpdate time of the most 2716 current CRL instance it already has, as specified in CMP Updates 2717 [I-D.ietf-lamps-cmp-updates]. The PKI management entity MUST respond 2718 with a general response with OID id-it-crls. If no thisUpdate value 2719 was given by the EE, it MUST return the latest CRL available. If a 2720 thisUpdate value was given, it MUST return the latest available CRL 2721 in case this CRL is more recent, otherwise the infoValue in the 2722 response message MUST be absent. 2724 In addition to the prerequisites specified in Section 3.4, the EE 2725 MUST know for the requested CRL either its CRL distribution point 2726 name or the name of the CRL issuer. 2728 Note: If the EE does not want to request a specific CRL it MAY use 2729 instead a general message with OID id-it-currentCrl as specified in 2730 RFC 4210 Section 5.3.19.6 [I-D.ietf-lamps-cmp-updates]. 2732 The message sequence for this PKI management operation is as given 2733 above, with the following specific content: 2735 1 the infoType OID to use is id-it-crlStatusList in the request and 2736 id-it-crls in the response 2738 2 the infoValue of the request MUST be present and contain a 2739 CRLStatus structure 2741 3 if present, the infoValue of the response MUST contain a CRL 2743 The infoValue field of the general request containing the id-it- 2744 crlStatusList OID looks like this: 2746 CRLSourceListValue REQUIRED 2747 -- MUST contain a CRLSource structure 2748 -- MUST contain the dpn choice if the CRL distribution point name 2749 -- is available 2750 -- MUST contain the issuer choice otherwise, naming the CA that 2751 -- issues the CRL. 2752 thisUpdate OPTIONAL 2753 -- SHOULD contain the thisUpdate field of the latest CRL form 2754 -- the given dpn or issuer, in case such a CRL is already known 2755 -- by the EE 2757 The infoValue field of the general response containing the id-it-crls 2758 OID looks like this: 2760 infoValue REQUIRED 2761 -- MUST contain a CRL update from the referenced source, if a 2762 -- thisUpdate value was not given or a more recent CRL is 2763 -- available 2765 4.4. Handling delayed delivery 2767 This is a variant of all PKI management operations described in 2768 described in this document. It is initiated in case a PKI management 2769 entity cannot respond to a request message in a timely manner, 2770 typically due to offline or asynchronous upstream communication, or 2771 due to delays in handling the request. The polling mechanism has 2772 been specified in RFC 4210 Section 5.3.22 [RFC4210] and updated by 2773 [I-D.ietf-lamps-cmp-updates]. 2775 Depending on the PKI architecture, the entity initiating delayed 2776 delivery is not necessarily the PKI management entity directly 2777 addressed by the EE. 2779 When initiating delayed delivery of a message received from an EE, 2780 the PKI management entity MUST respond with an ip/cp/kup/error 2781 message including the status "waiting". On receiving this response, 2782 the EE MUST store in its transaction context the senderNonce of the 2783 preceding request message because this value will be needed for 2784 checking the recipNonce of the final response to be received after 2785 polling. It sends a poll request with certReqId 0 if referring to 2786 the CertResponse element contained in the ip/cp/kup message, else -1 2787 to refer to the whole message. In case the final response is not yet 2788 available, the PKI management entity that initiated the delayed 2789 delivery MUST answer with a poll response, with the same certReqId. 2790 The included checkAfter time value indicates the minimum number of 2791 seconds that SHOULD elapse before the EE sends a new pollReq message 2792 to the PKI management entity. This is repeated until a final 2793 response is available or any party involved gives up on the current 2794 PKI management operation, i.e., a timeout occurs. 2796 When the PKI management entity that initiated delayed delivery can 2797 provide the final response for the original request message of the 2798 EE, it MUST send this response to the EE. Using this response, the 2799 EE can continue the current PKI management operation as usual. 2801 No specific prerequisites apply in addition to those of the 2802 respective PKI management operation. 2804 Message flow: 2806 Step# EE PKI management entity 2807 1 format request 2808 message 2809 2 -> request -> 2810 3 handle or forward 2811 request 2812 4 format ip/cp/kup/error 2813 with status "waiting" 2814 response in case no 2815 immediate final response 2816 is available, 2817 5 <- ip/cp/kup/error <- 2818 6 handle 2819 ip/cp/kup/error 2820 with status 2821 "waiting" 2823 -------------------------- start polling -------------------------- 2825 7 format pollReq 2826 8 -> pollReq -> 2827 9 handle or forward pollReq 2828 10 in case the final response 2829 for the original request 2830 is available, continue 2831 with step 14 2832 otherwise, format or 2833 receive pollRep with 2834 checkAfter value 2835 11 <- pollRep <- 2836 12 handle pollRep 2837 13 let checkAfter 2838 time elapse and 2839 continue with 2840 step 7 2842 ----------------- end polling, continue as usual ------------------ 2844 14 format or receive 2845 final response on 2846 original request 2847 15 <- response <- 2848 16 handle final 2849 response 2851 Detailed description of the ip/cp/kup/error response, pollReq, and 2852 pollRep: 2854 Response with status "waiting" -- ip/cp/kup/error 2856 Field Value 2858 header 2859 -- As described in Section 3.1 2861 body 2862 -- as described for the respective PKI management operation, with 2863 -- the following adaptations: 2864 status REQUIRED -- in case of ip/cp/kup 2865 pKIStatusInfo REQUIRED -- in case of error response 2866 -- PKIStatusInfo structure MUST be present 2867 status REQUIRED 2868 -- MUST be status "waiting" 2869 statusString OPTIONAL 2870 -- MAY be any human-readable text for debugging, logging or to 2871 -- display in a GUI 2872 failInfo PROHIBITED 2874 protection REQUIRED 2875 -- As described in Section 3.2 2877 extraCerts OPTIONAL 2878 -- As described in Section 3.3 2880 Polling Request -- pollReq 2882 Field Value 2884 header 2885 -- As described in Section 3.1 2887 body 2888 -- The message of the EE asking for the final response or for a 2889 -- time to check again 2890 pollReq REQUIRED 2891 certReqId REQUIRED 2892 -- MUST be 0 if referring to a CertResponse element, else -1 2894 protection REQUIRED 2895 -- As described in Section 3.2 2896 -- MUST use the same credentials as in the first request message 2897 -- of the PKI management operation 2899 extraCerts RECOMMENDED 2900 -- As described in Section 3.3 2901 -- MAY be omitted if the message size is critical and 2902 -- the PKI management entity caches the extraCerts from the 2903 -- first request message of the PKI management operation 2905 Polling Response -- pollRep 2907 Field Value 2909 header 2910 -- As described in Section 3.1 2912 body 2913 -- The message indicates the delay after which the EE SHOULD 2914 -- send another pollReq message for this transaction 2915 pollRep REQUIRED 2916 certReqId REQUIRED 2917 -- MUST be 0 if referring to a CertResponse element, else -1 2918 checkAfter REQUIRED 2919 -- time in seconds to elapse before a new pollReq SHOULD be sent 2920 reason OPTIONAL 2921 -- MAY be any human-readable text for debugging, logging or to 2922 -- display in a GUI 2924 protection REQUIRED 2925 -- As described in Section 3.2 2926 -- MUST use the same credentials as in the first response 2927 -- message of the PKI management operation 2929 extraCerts RECOMMENDED 2930 -- As described in Section 3.3 2931 -- MAY be omitted if the message size is critical and the EE has 2932 -- cached the extraCerts from the first response message of 2933 -- the PKI management operation 2935 Final response – any type of response message 2937 Field Value 2939 header 2941 -- MUST be the header as described for the response message 2942 -- of the respective PKI management operation 2944 body 2945 -- The response of the PKI management entity to the initial 2946 -- request as described in the respective PKI management 2947 -- operation 2949 protection REQUIRED 2950 -- MUST be as described for the response message of the 2951 -- respective PKI management operation 2953 extraCerts REQUIRED 2954 -- MUST be as described for the response message of the 2955 -- respective PKI management operation 2957 5. PKI management entity operations 2959 This section focuses on request processing by a PKI management 2960 entity. Depending on the network and PKI solution design, this can 2961 be an RA or CA, any of which may include protocol conversion or 2962 central key generation (i.e., acting as a KGA). 2964 A PKI management entity may directly respond to request messages from 2965 downstream and report errors. In case the PKI management entity is 2966 an RA it typically forwards the received request messages upstream 2967 after checking them and forwards respective response messages 2968 downstream. Besides responding to messages or forwarding them, a PKI 2969 management entity may request or revoke certificates on behalf of 2970 EEs. A PKI management entity may also need to manage its own 2971 certificates and thus act as an EE using the PKI management 2972 operations specified in Section 4. 2974 5.1. Responding to requests 2976 The PKI management entity terminating the PKI management operation at 2977 CMP level MUST respond to all received requests by returning a 2978 related CMP response message or an error. Any intermediate PKI 2979 management entity MAY respond depending on the PKI configuration and 2980 policy. 2982 In addition to the checks described in Section 3.5, the responding 2983 PKI management entity SHOULD check that a request that initiates a 2984 new PKI management operation does not use a transactionID that is 2985 currently in useThe failInfo bit value to use on reporting failure as 2986 described in Section 3.6.4 is transactionIdInUse. If any of these 2987 verification steps or any of the essential checks described in the 2988 following subsections fails, the PKI management entity MUST proceed 2989 as described in Section 3.6. 2991 The responding PKI management entity SHOULD copy the sender field of 2992 the request to the recipient field of the response, MUST copy the 2993 senderNonce of the request to the recipNonce of the response, and 2994 MUST use the same transactionID for the response. 2996 5.1.1. Responding to a certificate request 2998 An ir/cr/p10cr/kur message is used to request a certificate as 2999 described in Section 4.1. The responding PKI management entity MUST 3000 proceed as follows unless it initiates delayed delivery as described 3001 in Section 5.1.2. 3003 The PKI management entity SHOULD check the message body according to 3004 the applicable requirements from Section 4.1. Possible failInfo bit 3005 values used for error reporting in case a check failed include 3006 badCertId and badCertTemplate. It MUST verify the presence and value 3007 of the proof-of-possession (failInfo bit: badPOP), unless central key 3008 generation is requested. In case the special POP value "raVerified" 3009 is given, it SHOULD check that the request message was signed using a 3010 certificate containing the cmcRA extended key usage (failInfo bit: 3011 notAuthorized). The PKI management entity SHOULD perform also any 3012 further checks on the certTemplate contents (failInfo: 3013 badCertTemplate) according to any applicable PKI policy and 3014 certificate profile. 3016 If the requested certificate is available, the PKI management entity 3017 MUST respond with a positive ip/cp/kup message as described in 3018 Section 4.1. 3020 Note: If central key generation is performed by the responding PKI 3021 management entity, the responding PKI management entity MUST include 3022 in the response the privateKey field as specified in Section 4.1.6. 3023 It may have issued the certificate for the newly generated key pair 3024 itself if it is a CA, or have requested the certificate on behalf of 3025 the EE as described in Section 5.3.1, or have received it by other 3026 means from a CA. 3028 The prerequisites of the respective PKI management operation as 3029 specified in Section 4.1 apply. 3031 Note: If the EE requested omission of the certConf message, the PKI 3032 management entity SHOULD handle it as described in Section 4.1.1 and 3033 therefore MAY grant this by including the implicitConfirm extension 3034 in the response header. 3036 5.1.2. Initiating delayed delivery 3038 This functional extension can be used by a PKI management entity in 3039 case the response to a request takes longer than usual. In this case 3040 the PKI management entity MUST completely validate the request as 3041 usual and then start preparing the response or forward the request 3042 further upstream as soon as possible. In the meantime, it MUST 3043 respond with an ip/cp/kup/error message including the status 3044 "waiting" and handle subsequent polling as described in Section 4.4. 3046 Note: Typically, as stated in Section 5.2.3, an intermediate PKI 3047 management entity should not change the sender and recipient nonces 3048 even in case it modifies a request or a response message. In the 3049 special case of delayed delivery initiated by an intermediate PKI 3050 management entity, there is an exception. Between the EE and this 3051 PKI management entity, pollReq and pollRep messages are exchanged 3052 handling the nonces as usual. Yet when the final response from 3053 upstream has arrived at the PKI management entity, this response 3054 contains the recipNonce copied (as usual) from the senderNonce in the 3055 original request message. The PKI management entity that initiated 3056 the delayed delivery may replace the recipNonce in the response 3057 message with the senderNonce of the last received pollReq because the 3058 downstream entities, including the EE, might expect it in this way. 3059 Yet the check specified in Section 3.5 allows to alternatively use 3060 the senderNonce of the original request. 3062 No specific prerequisites apply in addition to those of the 3063 respective PKI management operation. 3065 5.1.3. Responding to a confirmation message 3067 A PKI management entity MUST handle a certConf message if it has 3068 responded before with a positive ip/cp/kup message not granting 3069 implicit confirmation. It SHOULD check the message body according to 3070 the requirements given in Section 4.1.1 (failInfo bit: badCertId) and 3071 react as described there. 3073 The prerequisites of the respective PKI management operation as 3074 specified in Section 4.1 apply. 3076 5.1.4. Responding to a revocation request 3078 An rr message is used to request revocation of a certificate. The 3079 responding PKI management entity SHOULD check the message body 3080 according to the requirements in Section 4.2. It MUST make sure that 3081 the referenced certificate exists (failInfo bit: badCertId), has been 3082 issued by the addressed CA, and is not already expired or revoked 3083 (failInfo bit: certRevoked). On success it MUST respond with a 3084 positive rp message as described in Section 4.2. 3086 No specific prerequisites apply in addition to those specified in 3087 Section 3.4. 3089 5.1.5. Responding to a support message 3091 A genm message is used to retrieve extra content. The responding PKI 3092 management entity SHOULD check the message body according to the 3093 applicable requirements in Section 4.3 and perform any further checks 3094 depending on the PKI policy. On success it MUST respond with a genp 3095 message as described there. 3097 Note: The responding PKI management entity may generate the response 3098 from scratch or reuse the contents of previous responses. Therefore, 3099 it may be worth caching the body of the response message as long as 3100 the contained information is still valid, such that further requests 3101 for the same contents can be answered immediately. 3103 No specific prerequisites apply in addition to those specified in 3104 Section 3.4. 3106 5.2. Forwarding messages 3108 In case the PKI solution consists of intermediate PKI management 3109 entities (i.e., LRA or RA), each CMP request message coming from an 3110 EE or any other downstream PKI management entity SHOULD be forwarded 3111 to the next (upstream) PKI management entity as described in this 3112 section and otherwise MUST be answered as described in Section 5.1. 3113 Any received response message or error message MUST be forwarded to 3114 the next (downstream) PKI entity. 3116 In addition to the checks described in Section 3.5, the forwarding 3117 PKI management entity MAY verify the proof-of-possession for 3118 ir/cr/p10cr/kur messages. If one of these verification procedures 3119 fails, the RA proceeds as described in Section 3.6. 3121 A PKI management entity SHOULD NOT change the received message unless 3122 necessary. The PKI management entity SHOULD only update the message 3123 protection and the certificate template in a certificate request 3124 message if this is technically necessary. Concrete PKI system 3125 specifications may define in more detail when to do so. 3127 This is particularly relevant in the upstream communication of a 3128 request message. 3130 Each forwarding PKI management entity has one or more 3131 functionalities. It may 3133 * verify the identities of EEs and make authorization decisions for 3134 certification request processing based on specific knowledge of 3135 the local setup, e.g., by consulting an inventory or asset 3136 management system, 3138 * add or modify fields of certificate request messages, 3140 * store data from a message in a database for later usage or audit 3141 purposes, 3143 * provide traversal of a network boundary, 3145 * replace a MAC-based protection by a signature-based protection 3146 that can be verified also further upstream, 3148 * double-check if the messages transferred back and forth are 3149 properly protected and well-formed, 3151 * provide an authentic indication that it has performed all required 3152 checks, 3154 * initiate a delayed delivery due to delays transferring messages or 3155 handling requests, or 3157 * collect messages from multiple RAs and forward them jointly. 3159 The decision if a message should be forwarded 3161 * unchanged with the original protection, 3163 * unchanged with a new protection, or 3165 * changed with a new protection 3167 depends on the PKI solution design and the associated security policy 3168 (CP/CPS [RFC3647]). 3170 A PKI management entity MUST replace or add a protection of a message 3171 if it 3173 * needs to securely indicate that it has done checks or validations 3174 on the message to one of the next (upstream) PKI management entity 3175 or 3177 * needs to protect the message using a key and certificate from a 3178 different PKI. 3180 A PKI management entity MUST replace a protection of a message if it 3182 * performs changes to the header or the body of the message or 3184 * needs to convert from or to a MAC-based protection. 3186 This is particularly relevant in the upstream communication of 3187 certificate request messages. 3189 Note that the message protection covers only the header and the body 3190 and not the extraCerts. The PKI management entity MAY change the 3191 extraCerts in any of the following message adaptations, e.g., to 3192 sort, add, or delete certificates to support subsequent PKI entities. 3193 This may be particularly helpful to augment upstream messages with 3194 additional certificates or to reduce the number of certificates in 3195 downstream messages when forwarding to constrained devices. 3197 5.2.1. Not changing protection 3199 This variant means that a PKI management entity forwards a CMP 3200 message without changing the header, body, or protection. In this 3201 case the PKI management entity acts more like a proxy, e.g., on a 3202 network boundary, implementing no specific RA-like security 3203 functionality that requires an authentic indication to the PKI. 3204 Still the PKI management entity might implement checks that result in 3205 refusing to forward the request message and instead responding as 3206 specified in Section 3.6. 3208 This variant of forwarding a message or the one described in 3209 Section 5.2.2.1 SHOULD be used for kur messages and for central key 3210 generation. 3212 No specific prerequisites apply in addition to those specified in 3213 Section 3.4. 3215 5.2.2. Adding protection and batching of messages 3217 This variant of forwarding a message means that a PKI management 3218 entity adds another protection to PKI management messages before 3219 forwarding them. 3221 The nested message is a PKI management message containing a 3222 PKIMessages sequence as its body containing one or more CMP messages. 3224 As specified in the updated Section 5.1.3.4 of RFC4210 [RFC4210] (see 3225 CMP Updates [I-D.ietf-lamps-cmp-updates]) there are various use cases 3226 for adding another protection by a PKI management entity. Specific 3227 procedures are described in more detail in the following sections. 3229 Detailed message description: 3231 Nested Message - nested 3233 Field Value 3235 header 3236 -- As described in Section 3.1 3238 body 3239 -- Container to provide additional protection to original 3240 -- messages and to bundle request messages or alternatively 3241 -- response messages 3242 PKIMessages REQUIRED 3243 -- MUST be a sequence of one or more CMP messages 3245 protection REQUIRED 3246 -- As described in Section 3.2 using the CMP protection key of 3247 -- the PKI management entity 3249 extraCerts REQUIRED 3250 -- As described in Section 3.3 3252 5.2.2.1. Adding protection to a request message 3254 A PKI management entity may authentically indicate successful 3255 validation and approval of a request message by adding an extra 3256 signature to the original message. 3258 By adding a protection using its own CMP protecting key the PKI 3259 management entity provides a proof of verifying and approving the 3260 message as described above. Thus, the PKI management entity acts as 3261 an actual Registration Authority (RA), which implements important 3262 security functionality of the PKI. Applying an additional protection 3263 is specifically relevant when forwarding a message that requests a 3264 certificate update or central key generation. This is because the 3265 original protection of the EE must be preserved while adding an 3266 indication of approval by the PKI management entity. 3268 The PKI management entity wrapping the original request message in a 3269 nested message structure MUST take over the recipient, recipNonce, 3270 and transactionID of the original message to the nested message and 3271 apply signature-based protection. The additional signature serves as 3272 proof of verification and authorization by this PKI management 3273 entity. 3275 The PKI management entity receiving such a nested message that 3276 contains a single request message MUST validate the additional 3277 protection signature on the nested message and check the 3278 authorization for the approval it implies. 3280 The PKI management entity responding to the request contained in the 3281 nested message sends the response message as described in 3282 Section 5.1, without wrapping it in a nested message. 3284 Note: This form of nesting messages is characterized by the fact that 3285 the transactionID in the header of the nested message is the same as 3286 the one used in the included message. 3288 Specific prerequisites augmenting the prerequisites in Section 3.4: 3290 * The PKI management entity MUST have the authorization to perform 3291 the validation and approval of the respective request according to 3292 the PKI policies. 3294 Message flow: 3296 Step# PKI management entity PKI management entity 3297 1 format nested 3298 2 -> nested -> 3299 3 handle or forward nested 3300 4 format or receive response 3301 5 <- response <- 3302 6 forward response 3304 5.2.2.2. Batching messages 3306 A PKI management entity MAY bundle any number of PKI management 3307 messages for batch processing or to transfer a bulk of PKI management 3308 messages using the nested message structure. In this use case, 3309 nested messages are used both on the upstream interface towards the 3310 next PKI management entity and on the downstream interface from the 3311 PKI management entity towards the EE. 3313 This PKI management operation is typically used on the interface 3314 between an LRA and an RA to bundle several messages for offline 3315 delivery. In this case the LRA needs to initiate delayed delivery as 3316 described in Section 5.1.2. If the RA needs different routing 3317 information per nested PKI management message a suitable mechanism 3318 may need to be implemented. Since this mechanism strongly depends on 3319 the requirements of the target architecture, it is out of scope of 3320 this document. 3322 A nested message containing requests is generated locally at the PKI 3323 management entity. For the upstream nested message, the PKI 3324 management entity acts as a protocol end point and therefore a fresh 3325 transactionID and a fresh senderNonce MUST be used in the header of 3326 the nested message. An upstream nested message may contain request 3327 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-04, 8 3818 November 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-08, 17 November 2021, 3826 . 3829 [I-D.ietf-lamps-cmp-updates] 3830 Brockhaus, H., Oheimb, D. V., and J. Gray, "Certificate 3831 Management Protocol (CMP) Updates", Work in Progress, 3832 Internet-Draft, draft-ietf-lamps-cmp-updates-13, 25 3833 October 2021, . 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-11, 3918 8 November 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 07 -> 08: 4107 * Updates Section 4.1.6.1. regarding content of the originator and 4108 keyEncryptionAlgorithm fields (see thread "AD review of draft- 4109 ietf-lamps-cmp-algorithms-07") 4110 * Rolled back part of the changes on root CA certificate updates in 4111 Section 4.3.2 (see thread "Allocation of OIDs for CRL update 4112 retrieval (draft-ietf-lamps-cmp-updates-13)") 4114 From version 06 -> 07: 4116 * Added references to [draft-ietf-netconf-sztp-csr] in new 4117 Section 1.5 and Section 4.1.4 4118 * Added reference to [I-D.ietf-anima-brski-async-enroll] in new 4119 Section 1.5 and Section 4.1.1 4120 * Changed reference in Section 2 to [I-D.ietf-anima-brski-prm] as 4121 the PUSH use case is continued to be discussed in this draft after 4122 the split of BRSKI-AE 4123 * Improved note regarding UNISIG Subset-137 in Section 1.6 4124 * Removed "rootCaCert" in Section 3.1 and updated the structure of 4125 the genm request for root CA certificate updates in Section 4.3.2. 4126 * Simplified handling of sender and recipient nonces in case of 4127 delayed delivery in Sections 3.1, 3.5, 4.4, and 5.1.2 4128 * Changed the order of Sections 4.1.4 and 4.1.5 4129 * Added reference on RFC 8933 regarding CMS signedAttrs to 4130 Section 4.1.6 4131 * Added Section 4.3.4 on CRL update retrieval 4132 * Generalized delayed enrollment to delayed delivery in Section 4.4 4133 and 5.1.2, updated the state machine in the introduction of 4134 Section 4 4135 * Updated Section 6 regarding delayed message transfer 4136 * Changed file name extension from ".PKI" to ".pki", deleted 4137 operational path for central key generation, and added an 4138 operational path for CRL update retrieval in Sections 6.1 and 6.2 4139 * Shifted many security considerations to CMP Updates 4140 * Replaced the term "transport" by "transfer" where appropriate to 4141 prevent confusion regarding TCP vs. HTTP and CoAP 4142 * Various editorial changes and language corrections 4144 From version 05 -> 06: 4146 * Changed in Section 2.3 the normative requirement in of adding 4147 protection to a single message to mandatory and replacing 4148 protection to optional 4149 * Added Section 3.4 specifying generic prerequisites to PKI 4150 management operations 4151 * Added Section 3.5 specifying generic message validation 4152 * Added Section 3.6 on generic error reporting. This section 4153 replaces the former error handling section from Section 4 and 5. 4154 * Added reference to using hashAlg 4155 * Updates Section 4.3.2 and Section 4.3.3 to align with CMP Updates 4156 * Added Section 5.1 specifying the behavior of PKI management 4157 entities when responding to requests 4158 * Reworked Section 5.2.3. on usage of nested messages 4159 * Updates Section 5.3 on performing PKI management operation on 4160 behalf of another entity 4161 * Updates Section 6.2 on HTTPS transport of CMP messages as 4162 discusses at IETF 110 and email thread "I-D Action: draft-ietf- 4163 lamps-lightweight-cmp-profile-05.txt" 4164 * Added CoAP endpoints to Section 6.4 4165 * Added security considerations on usage of shared secret 4166 information 4167 * Updated the example in Appendix A 4168 * Added newly registered OIDs to the example in Appendix A 4169 * Updated new RFC numbers for I-D.ietf-lamps-crmf-update-algs 4170 * Multiple language corrections, clarifications, and changes in 4171 wording 4173 From version 04 -> 05: 4175 * Changed to XML V3 4176 * Added algorithm names introduced in CMP Algorithms Section 7.3 to 4177 Section 4 of this document 4178 * Updates Syntax in Section 4.4.3 due to changes made in CMP Updates 4179 * Deleted the text on HTTP-based discovery as discussed in 4180 Section 6.1 4181 * Updates Appendix A due to change syntax in Section 4.4.3 4182 * Many clarifications and changes in wording thanks to David's 4183 extensive review 4185 From version 03 -> 04: 4187 * Deleted normative text sections on algorithms and refer to CMP 4188 Algorithms and CRMF Algorithm Requirements Update instead 4189 * Some clarifications and changes in wording 4191 From version 02 -> 03: 4193 * Updated the interoperability with [UNISIG.Subset-137] in 4194 Section 1.4. 4195 * Changed Section 2.3 to a tabular layout to enhanced readability 4196 * Added a ToDo to section 3.1 on aligning with the CMP Algorithms 4197 draft that will be set up as decided in IETF 108 4198 * Updated section 4.1.6 to add the AsymmetricKey Package structure 4199 to transport a newly generated private key as decided in IETF 108 4200 * Added a ToDo to section 4.1.7 on required review of the nonce 4201 handling in case an offline LRA responds and not forwards the 4202 pollReq messages 4203 * Updated Section 4 due to the definition of the new ITAV OIDs in 4204 CMP Updates 4205 * Updated Section 4.4.4 to utilize controls instead of rsaKeyLen 4206 (see thread "dtaft-ietf-lamps-cmp-updates and rsaKeyLen") 4207 * Deleted the section on definition and discovery of HTTP URIs and 4208 copied the text to the HTTP transport section and to CMP Updates 4209 section 3.2 4210 * Added some explanation to Section 5.1.2 and Section 5.1.3 on using 4211 nested messages when a protection by the RA is required. 4212 * Deleted the section on HTTP URI definition and discovery as some 4213 content was moved to CMP Updates. The rest of the content was 4214 moved back to the HTTP transport section 4215 * Deleted the ASN.1 module after moving the new OIDs id-it-caCerts, 4216 id-it-rootCaKeyUpdate, and id-it-certReqTemplate to CMP Updates 4217 * Minor changes in wording and addition of some open ToDos 4219 From version 01 -> 02: 4221 * Extend Section 1.6 with regard to conflicts with UNISIG Subset- 4222 137. 4223 * Minor clarifications on extraCerts in Section 3.3 and 4224 Section 4.1.1. 4225 * Complete specification of requesting a certificate from a trusted 4226 PKI with signature protection in Section 4.1.2. 4227 * Changed from symmetric key-encryption to password-based key 4228 management technique in section Section 4.1.6.3 as discussed on 4229 the mailing list (see thread "draft-ietf-lamps-lightweight-cmp- 4230 profile-01, section 5.1.6.1") 4231 * Changed delayed enrollment described in Section 4.4 from 4232 recommended to optional as decided at IETF 107 4233 * Introduced the new RootCAKeyUpdate structure for root CA 4234 certificate update in Section 4.3.2 as decided at IETF 107 (also 4235 see email thread "draft-ietf-lamps-lightweight-cmp-profile-01, 4236 section 5.4.3") 4238 * Extend the description of the CertReqTemplate PKI management 4239 operation, including an example added in the Appendix. Keep 4240 rsaKeyLen as a single integer value in Section 4.3.3 as discussed 4241 on the mailing list (see thread "draft-ietf-lamps-lightweight-cmp- 4242 profile-01, section 5.4.4") 4243 * Deleted Sections "Get certificate management configuration" and 4244 "Get enrollment voucher" as decided at IETF 107 4245 * Complete specification of adding an additional protection by an 4246 PKI management entity in Section 5.2.2. 4247 * Added a section on HTTP URI definition and discovery and extended 4248 Section 6.1 on definition and discovery of supported HTTP URIs and 4249 content types, add a path for nested messages as specified in 4250 Section 5.2.2 and delete the paths for /getCertMgtConfig and 4251 /getVoucher 4252 * Changed Section 6.4 to address offline transport and added more 4253 detailed specification file-based transport of CMP 4254 * Added a reference to the new I-D of Mohit Sahni on "CoAP Transport 4255 for CMPV2" in Section 6.2; thanks to Mohit supporting the effort 4256 to ease utilization of CMP 4257 * Moved the change history to the Appendix 4258 * Minor changes in wording 4260 From version 00 -> 01: 4262 * Harmonize terminology with CMP [RFC4210], e.g., 4263 - transaction, message sequence, exchange, use case -> PKI 4264 management operation 4265 - PKI component, (L)RA/CA -> PKI management entity 4266 * Minor changes in wording 4268 From draft-brockhaus-lamps-lightweight-cmp-profile-03 -> draft-ietf- 4269 lamps-lightweight-cmp-profile-00: 4271 * Changes required to reflect WG adoption 4272 * Minor changes in wording 4274 From version 02 -> 03: 4276 * Added a short summary of [RFC4210] Appendix D and E in 4277 Section 1.4. 4278 * Clarified some references to different sections and added some 4279 clarification in response to feedback from Michael Richardson and 4280 Tomas Gustavsson. 4281 * Added an additional label to the operational path to address 4282 multiple CAs or certificate profiles in Section 6.1. 4284 From version 01 -> 02: 4286 * Added some clarification on the key management techniques for 4287 protection of centrally generated keys in Section 4.1.6. 4288 * Added some clarifications on the certificates for root CA 4289 certificate update in Section 4.3.2. 4290 * Added a section to specify the usage of nested messages for RAs to 4291 add an additional protection for further discussion, see 4292 Section 5.2.2. 4293 * Added a table containing endpoints for HTTP transport in 4294 Section 6.1 to simplify addressing PKI management entities. 4295 * Added some ToDos resulting from discussion with Tomas Gustavsson. 4296 * Minor clarifications and changes in wording. 4298 From version 00 -> 01: 4300 * Added a section to specify the enrollment with an already trusted 4301 PKI for further discussion, see Section 4.1.2. 4302 * Complete specification of requesting a certificate from a legacy 4303 PKI using a PKCS#10 [RFC2986] request in Section 4.1.4. 4304 * Complete specification of adding central generation of a key pair 4305 on behalf of an end entity in Section 4.1.6. 4306 * Complete specification of handling delayed enrollment due to 4307 asynchronous message delivery in Section 4.4. 4308 * Complete specification of additional support messages, e.g., to 4309 update a Root CA certificate or to request an RFC 8366 [RFC8366] 4310 voucher, in Section 4.3. 4311 * Minor changes in wording. 4313 From draft-brockhaus-lamps-industrial-cmp-profile-00 -> draft- 4314 brockhaus-lamps-lightweight-cmp-profile-00: 4316 * Change focus from industrial to more multi-purpose use cases and 4317 lightweight CMP profile. 4318 * Incorporate the omitted confirmation into the header specified in 4319 Section 3.1 and described in the standard enrollment use case in 4320 Section 4.1.1 due to discussion with Tomas Gustavsson. 4321 * Change from OPTIONAL to RECOMMENDED for use case 'Revoke another's 4322 entities certificate' in Section 5.3.2, because it is regarded as 4323 important functionality in many environments to enable the 4324 management station to revoke EE certificates. 4325 * Complete the specification of the revocation message flow in 4326 Section 4.2 and Section 5.3.2. 4327 * The CoAP based transport mechanism and piggybacking of CMP 4328 messages on top of other reliable transport protocols is out of 4329 scope of this document and would need to be specified in another 4330 document. 4331 * Further minor changes in wording. 4333 Authors' Addresses 4335 Hendrik Brockhaus (editor) 4336 Siemens AG 4338 Email: hendrik.brockhaus@siemens.com 4340 David von Oheimb 4341 Siemens AG 4343 Email: david.von.oheimb@siemens.com 4345 Steffen Fries 4346 Siemens AG 4348 Email: steffen.fries@siemens.com