idnits 2.17.1 draft-ietf-lamps-lightweight-cmp-profile-10.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: ---------------------------------------------------------------------------- No issues found here. Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- == There are 2 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 -- The document date (1 February 2022) is 813 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 705, but not defined == Missing Reference: 'RFC-CMP-Updates' is mentioned on line 743, but not defined -- Looks like a reference, but probably isn't: '3' on line 4102 -- Looks like a reference, but probably isn't: '5' on line 4105 -- Looks like a reference, but probably isn't: '9' on line 4128 -- Looks like a reference, but probably isn't: '2' on line 4133 -- Looks like a reference, but probably isn't: '7' on line 4134 == 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-09 == Outdated reference: A later version (-23) exists of draft-ietf-lamps-cmp-updates-17 ** 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-13 -- 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 (~~), 10 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: 5 August 2022 Siemens 6 1 February 2022 8 Lightweight Certificate Management Protocol (CMP) Profile 9 draft-ietf-lamps-lightweight-cmp-profile-10 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 5 August 2022. 42 Copyright Notice 44 Copyright (c) 2022 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 . . . . . . . 5 61 1.3. Special requirements of industrial and IoT scenarios . . 6 62 1.4. Existing CMP profiles . . . . . . . . . . . . . . . . . . 7 63 1.5. Use of CMP in SZTP and BRSKI environments . . . . . . . . 7 64 1.6. Compatibility with existing CMP profiles . . . . . . . . 8 65 1.7. Scope of this document . . . . . . . . . . . . . . . . . 10 66 1.8. Structure of this document . . . . . . . . . . . . . . . 10 67 1.9. Convention and Terminology . . . . . . . . . . . . . . . 11 68 2. Solution architecture . . . . . . . . . . . . . . . . . . . . 12 69 3. Generic aspects of the PKI message . . . . . . . . . . . . . 14 70 3.1. General description of the CMP message header . . . . . . 15 71 3.2. General description of the CMP message protection . . . . 17 72 3.3. General description of CMP message extraCerts . . . . . . 17 73 3.4. Generic PKI management operation prerequisites . . . . . 18 74 3.5. Generic validation of a PKI message . . . . . . . . . . . 19 75 3.6. Error handling . . . . . . . . . . . . . . . . . . . . . 21 76 3.6.1. Reporting error conditions upstream . . . . . . . . . 21 77 3.6.2. Reporting error conditions downstream . . . . . . . . 22 78 3.6.3. Handling error conditions on nested messages used for 79 batching . . . . . . . . . . . . . . . . . . . . . . 22 80 3.6.4. Reporting error conditions . . . . . . . . . . . . . 23 81 4. End Entity PKI management operations . . . . . . . . . . . . 24 82 4.1. Requesting a new certificate from a PKI . . . . . . . . . 27 83 4.1.1. Requesting a certificate from a new PKI with 84 signature-based protection . . . . . . . . . . . . . 28 85 4.1.2. Requesting an additional certificate with 86 signature-based protection . . . . . . . . . . . . . 34 87 4.1.3. Updating an existing certificate with signature 88 protection . . . . . . . . . . . . . . . . . . . . . 35 89 4.1.4. Requesting a certificate from a legacy PKI using a 90 PKCS#10 request . . . . . . . . . . . . . . . . . . . 36 91 4.1.5. Requesting a certificate from a PKI with MAC-based 92 protection . . . . . . . . . . . . . . . . . . . . . 38 93 4.1.6. Adding central key pair generation to a certificate 94 request . . . . . . . . . . . . . . . . . . . . . . . 39 96 4.1.6.1. Using key agreement key management technique . . 45 97 4.1.6.2. Using key transport key management technique . . 46 98 4.1.6.3. Using password-based key management technique . . 47 99 4.2. Revoking a certificate . . . . . . . . . . . . . . . . . 48 100 4.3. Support messages . . . . . . . . . . . . . . . . . . . . 50 101 4.3.1. Get CA certificates . . . . . . . . . . . . . . . . . 53 102 4.3.2. Get root CA certificate update . . . . . . . . . . . 53 103 4.3.3. Get certificate request template . . . . . . . . . . 55 104 4.3.4. CRL update retrieval . . . . . . . . . . . . . . . . 57 105 4.4. Handling delayed delivery . . . . . . . . . . . . . . . . 59 106 5. PKI management entity operations . . . . . . . . . . . . . . 64 107 5.1. Responding to requests . . . . . . . . . . . . . . . . . 64 108 5.1.1. Responding to a certificate request . . . . . . . . . 65 109 5.1.2. Initiating delayed delivery . . . . . . . . . . . . . 65 110 5.1.3. Responding to a confirmation message . . . . . . . . 66 111 5.1.4. Responding to a revocation request . . . . . . . . . 66 112 5.1.5. Responding to a support message . . . . . . . . . . . 67 113 5.2. Forwarding messages . . . . . . . . . . . . . . . . . . . 67 114 5.2.1. Not changing protection . . . . . . . . . . . . . . . 69 115 5.2.2. Adding protection and batching of messages . . . . . 69 116 5.2.2.1. Adding protection to a request message . . . . . 70 117 5.2.2.2. Batching messages . . . . . . . . . . . . . . . . 71 118 5.2.3. Replacing protection . . . . . . . . . . . . . . . . 73 119 5.2.3.1. Not changing any included proof-of-possession . . 73 120 5.2.3.2. Breaking proof-of-possession . . . . . . . . . . 74 121 5.3. Acting on behalf of other PKI entities . . . . . . . . . 74 122 5.3.1. Requesting certificates . . . . . . . . . . . . . . . 75 123 5.3.2. Revoking a certificate . . . . . . . . . . . . . . . 75 124 6. CMP message transfer mechanisms . . . . . . . . . . . . . . . 76 125 6.1. HTTP transfer . . . . . . . . . . . . . . . . . . . . . . 77 126 6.2. CoAP transfer . . . . . . . . . . . . . . . . . . . . . . 79 127 6.3. Piggybacking on other reliable transfer . . . . . . . . . 81 128 6.4. Offline transfer . . . . . . . . . . . . . . . . . . . . 81 129 6.4.1. File-based transfer . . . . . . . . . . . . . . . . . 82 130 6.4.2. Other asynchronous transfer protocols . . . . . . . . 82 131 7. Conformance requirements . . . . . . . . . . . . . . . . . . 82 132 7.1. PKI management operations . . . . . . . . . . . . . . . . 82 133 7.2. Message transfer . . . . . . . . . . . . . . . . . . . . 85 134 8. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 86 135 9. Security Considerations . . . . . . . . . . . . . . . . . . . 86 136 10. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 86 137 11. References . . . . . . . . . . . . . . . . . . . . . . . . . 86 138 11.1. Normative References . . . . . . . . . . . . . . . . . . 87 139 11.2. Informative References . . . . . . . . . . . . . . . . . 88 140 Appendix A. Example CertReqTemplate . . . . . . . . . . . . . . 91 141 Appendix B. History of changes . . . . . . . . . . . . . . . . . 93 142 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 98 144 1. Introduction 146 [RFC Editor: please delete]: The labels "RFC-CMP-Updates" and "RFC- 147 CMP-Alg" in ASN.1 Syntax need to be replaced with the RFC numbers of 148 CMP Updates [I-D.ietf-lamps-cmp-updates] and CMP Algorithms 149 [I-D.ietf-lamps-cmp-algorithms], when available. 151 This document specifies PKI management operations supporting machine- 152 to-machine and IoT use cases. Its focus is to maximize automation 153 and interoperability between all involved PKI entities, ranging from 154 end entities (EE) over any number of intermediate PKI management 155 entities such as Registration Authorities (RA) to the CMP endpoints 156 of Certification Authority (CA) systems. This profile makes use of 157 the concepts and syntax specified in CMP [RFC4210], 158 [I-D.ietf-lamps-cmp-updates], and [I-D.ietf-lamps-cmp-algorithms], 159 CRMF [RFC4211] and [RFC9045], CMS [RFC5652] and [RFC8933], HTTP 160 transfer for CMP [RFC6712], and CoAP transfer for CMP 161 [I-D.ietf-ace-cmpv2-coap-transport]. Especially CMP, CRMF, and CMS 162 are very feature-rich standards, while in most application scenarios 163 only a limited subset of the specified functionality is needed. 164 Additionally, the standards are not always precise enough on how to 165 interpret and implement the described concepts. Therefore, this 166 document aims at tailoring the available options and specifying at an 167 adequate detail how to use them to make the implementation of 168 interoperable automated certificate management as straightforward and 169 lightweight as possible. 171 1.1. How to Read This Document 173 This document has become longer than the authors would have liked it 174 to be. Yet apart from studying Section 3, which contains general 175 requirements, the reader does not have to work through the whole 176 document. The guidance in Section 1.8 and Section 7 should be used 177 to figure out which parts of Section 4 to Section 6 are relevant for 178 the target certificate management solution depending on the PKI 179 management operations, their variants, and types of message transfer 180 needed. 182 Since conformity to this document can be achieved by implementing 183 only the functionality declared mandatory in Section 7, the profile 184 can still be called lightweight because in particular for end 185 entities the mandatory-to-implement set of features is rather 186 limited. 188 1.2. Motivation for a lightweight profile of CMP 190 CMP was standardized in 1999 and is implemented in several PKI 191 products. In 2005, a completely reworked and enhanced version 2 of 192 CMP [RFC4210] and CRMF [RFC4211] has been published, followed by a 193 document specifying a transfer mechanism for CMP messages using HTTP 194 [RFC6712] in 2012. 196 Though CMP is a solid and very capable protocol it is so far not used 197 very widely. The most important reason appears to be that the 198 protocol offers a too large set of features and options. On the one 199 hand, this makes CMP applicable to a very wide range of scenarios, 200 but on the other hand, a full implementation supporting all options 201 is not realistic because this would take undue effort. 203 In order to reduce complexity, the set of mandatory PKI management 204 operations and variants required by this specification has been kept 205 lean. This limits development effort and minimizes resource needs, 206 which is particularly important for memory-constrained devices. To 207 this end, when there was a choice to have necessary complexity more 208 on the EE or PKI management entity side, it has been pushed towards 209 PKI management entities, where typically more computational resources 210 are available and the development can be consolidated better. 211 Additional recommended PKI management operations and variants support 212 some more complex scenarios that are considered beneficial for 213 environments with more specific demands or boundary conditions. The 214 optional PKI management operations support less common scenarios and 215 requirements. 217 Moreover, many details of the CMP protocol have been left open or 218 have not been specified in full preciseness. The profiles specified 219 in Appendix D and E of [RFC4210] define some more detailed PKI 220 management operations. Yet, the specific needs of highly automated 221 scenarios for a machine-to-machine communication are not covered 222 sufficiently. 224 As also 3GPP and UNISIG already put across, profiling is a way of 225 coping with the challenges mentioned above. To profile means to take 226 advantage of the strengths of the given protocol, while explicitly 227 narrowing down the options it provides to those needed for the 228 purpose(s) at hand and eliminating all identified ambiguities. In 229 this way all the general and applicable aspects of the general 230 protocol are taken over and only the peculiarities of the target 231 scenarios need to be dealt with specifically. 233 Defining a profile for a new target environment takes high effort 234 because the range of available options needs to be well understood 235 and the selected options need to be consistent with each other and 236 suitably cover the intended application scenario. Since most 237 industrial PKI management use cases typically have much in common it 238 is worth sharing this effort, which is the aim of this document. 239 Other standardization bodies can reference this document and do not 240 need to come up with individual profiles from scratch. 242 1.3. Special requirements of industrial and IoT scenarios 244 The profiles specified in Appendix D and E of RFC 4210 [RFC4210] have 245 been developed particularly for managing certificates of human end 246 entities. With the evolution of distributed systems and client- 247 server architectures, certificates for machines and applications on 248 them have become widely used. This trend has strengthened even more 249 in emerging industrial and IoT scenarios. CMP is sufficiently 250 flexible to support them well. 252 Today's IT security architectures for industrial solutions typically 253 use certificates for endpoint authentication within protocols like 254 IPsec, TLS, or SSH. Therefore, the security of these architectures 255 highly relies upon the security and availability of the implemented 256 certificate management operations. 258 Due to increasing security needs in operational networks as well as 259 availability requirements, especially on critical infrastructures and 260 systems with a high number of certificates, a state-of-the-art 261 certificate management system must be constantly available and cost- 262 efficient, which calls for high automation and reliability. 263 Consequently, the NIST Framework for Improving Critical 264 Infrastructure Cybersecurity [NIST.CSWP.04162018] refers to proper 265 processes for issuance, management, verification, revocation, and 266 audit for authorized devices, users, and processes involving identity 267 and credential management. Such PKI management operations according 268 to commonly accepted best practices are also required in 269 IEC 62443-3-3 [IEC.62443-3-3] for security level 2 and higher. 271 Further challenges in many industrial systems are network 272 segmentation and asynchronous communication, while PKI management 273 entities like Certification Authorities (CA) typically are not 274 deployed on-site but in a more protected environment of a data center 275 or trust center. Certificate management must be able to cope with 276 such network architectures. CMP offers the required flexibility and 277 functionality, namely self-contained messages, efficient polling, and 278 support for asynchronous message transfer while retaining end-to-end 279 security. 281 1.4. Existing CMP profiles 283 As already stated, RFC 4210 [RFC4210] contains profiles with 284 mandatory and optional PKI management operations in Appendix D and E. 285 Those profiles focus on management of human user certificates and 286 only partly address the specific needs of certificate management 287 automation for unattended devices or machine-to-machine application 288 scenarios. 290 Both Appendixes D and E focus on EE-to-RA/CA PKI management 291 operations and do not address further profiling of RA-to-CA 292 communication as typically needed for full backend automation. All 293 requirements regarding algorithm support for RFC 4210 Appendix D and 294 E [RFC4210] have been updated by CMP Algorithms Section 7.1 295 [I-D.ietf-lamps-cmp-algorithms]. 297 3GPP makes use of CMP [RFC4210] in its Technical Specification 33.310 298 [ETSI-3GPP.33.310] for automatic management of IPsec certificates in 299 3G, LTE, and 5G backbone networks. Since 2010, a dedicated CMP 300 profile for initial certificate enrollment and certificate update 301 operations between EE and RA/CA is specified in that document. 303 UNISIG has included a CMP profile for enrollment of TLS certificates 304 in the Subset-137 specifying the ETRAM/ETCS on-line key management 305 for train control systems [UNISIG.Subset-137] in 2015. 307 Both standardization bodies tailor CMP [RFC4210], CRMF [RFC4211], and 308 HTTP transfer for CMP [RFC6712] for highly automated and reliable PKI 309 management operations for unattended devices and services. 311 1.5. Use of CMP in SZTP and BRSKI environments 313 In Secure Zero Touch Provisioning (SZTP) [RFC8572] and other 314 environments using NETCONF/YANG modules, SZTP-CSR 315 [I-D.ietf-netconf-sztp-csr] offers a YANG module that includes 316 different types of certificate requests to obtain a public-key 317 certificate for a locally generated key pair. One option is using a 318 CMP p10cr message. Such a message is of the form ietf-ztp-types:cmp- 319 csr from module ietf-ztp-csr and offers both proof-of-possession and 320 proof-of-identity. To allow PKI management entities to also comply 321 with this profile, the p10cr message must be formatted by the EE as 322 described in Section 4.1.4 of this profile, and it may be forwarded 323 as specified in Section 5.2. 325 In Bootstrapping Remote Secure Key Infrastructure (BRSKI) [RFC8995] 326 environments, BRSKI Asynchronous Enrollment BRSKI Asynchronous 327 Enrollment [I-D.ietf-anima-brski-async-enroll] describes a 328 generalization regarding the employed enrollment protocols to allow 329 alternatives to EST [RFC7030]. For the use of CMP, it requires 330 adherence to this profile. 332 1.6. Compatibility with existing CMP profiles 334 The profile specified in this document is compatible with RFC 4210 335 Appendixes D and E (PKI Management Message Profiles) [RFC4210], with 336 the following exceptions: 338 * signature-based protection is the default protection; an initial 339 PKI management operation may also use MAC-based protection, 341 * certification of a second key pair within the same PKI management 342 operation is not supported, 344 * proof-of-possession (POPO) with self-signature of the certTemplate 345 according to RFC 4211 Section 4.1 [RFC4211] clause 3 is the 346 recommended default POPO method (deviations are possible for EEs 347 when requesting central key generation, for RAs when using 348 raVerified, and if the newly generated keypair is technically not 349 capable to generate digital signatures), 351 * confirmation of newly enrolled certificates may be omitted, and 353 * all PKI management operations consist of request-response message 354 pairs originating at the EE, i.e., announcement messages 355 (requiring a push model, a CMP server on the EE) are excluded in 356 favor of a lightweight implementation on the EE. 358 The profile specified in this document is compatible with the CMP 359 profile for 3G, LTE, and 5G network domain security and 360 authentication framework [ETSI-3GPP.33.310], except that: 362 * protection of initial PKI management operations may be MAC-based, 364 * the subject field is mandatory in certificate templates, and 366 * confirmation of newly enrolled certificates may be omitted. 368 The profile specified in this document is compatible with the CMP 369 profile for on-line key management in rail networks as specified in 370 UNISIG Subset-137 [UNISIG.Subset-137], except that: 372 * A certificate enrollment request message consists of only one 373 certificate request (CertReqMsg). 375 * RFC 4210 [RFC4210] requires that the messageTime is Greenwich Mean 376 Time coded as generalizedTime. 378 Note: As UNISIG Subset-137 Table 5 [UNISIG.Subset-137] explicitly 379 states that the messageTime in required to be "UTC time", it is 380 not clear if this means a coding as UTCTime or generalizedTime and 381 if other time zones than Greenwich Mean Time shall be allowed. 382 Both time formats are described in RFC 5280 Section 4.1.2.5 383 [RFC5280]. 385 * The same type of protection is required to be used for all 386 messages of one PKI management operation. This means, in case the 387 request message protection is MAC-based, also the response, 388 certConf, and pkiConf messages must have a MAC-based protection. 390 * Use of caPubs is not required but typically allowed in combination 391 with MAC-based protected PKI management operations. On the other 392 hand UNISIG Subset-137 Table 12 [UNISIG.Subset-137] requires using 393 caPubs. 395 Note: It remains unclear from UNISIG Subset-137 for which 396 certificate(s) the caPubs field should be used. For security 397 reasons, it cannot be used for delivering the root CA certificate 398 needed for validating the signature-based protection of the given 399 response message (as stated indirectly also in its UNISIG 400 Subset-137 Section 6.3.1.5.2 b [UNISIG.Subset-137]). 402 * This profile requires that the certConf message has one CertStatus 403 element where the statusInfo field is recommended. 405 Note: In contrast, UNISIG Subset-137 Table 18 [UNISIG.Subset-137] 406 requires that the certConf message has one CertStatus element 407 where the statusInfo field must be absent. This precludes sending 408 a negative certConf message in case the EE rejects the newly 409 enrolled certificate. This results in violating the general rule 410 that a certificate request transaction must include a certConf 411 message (since moreover, using implicitConfirm is not allowed 412 there, neither). 414 1.7. Scope of this document 416 To minimize ambiguity and complexity through needless variety, this 417 document specifies exhaustive requirements on generating PKI 418 management messages on the sender side. On the other hand, it gives 419 only minimal requirements on checks by the receiving side and how to 420 handle error cases. 422 Especially on the EE side this profile aims at a lightweight 423 implementation. This means that the number of PKI management 424 operations implementations are reduced to a reasonable minimum to 425 support typical certificate management use cases in industrial 426 machine-to-machine environments. On the EE side only limited 427 resources are expected, while on the side of the PKI management 428 entities the profile accepts higher requirements. 430 For the sake of interoperability and robustness, implementations 431 should, as far as security is not affected, adhere to Postel's law: 432 "Be conservative in what you do, be liberal in what you accept from 433 others" (often reworded as: "Be conservative in what you send, be 434 liberal in what you receive"). 436 When in Section 3, Section 4, and Section 5 a field of the ASN.1 437 syntax as defined in CMP [RFC4210] and [I-D.ietf-lamps-cmp-updates], 438 CRMF [RFC4211], and CMS [RFC5652] and [RFC8933] is not explicitly 439 specified, it SHOULD NOT be used by the sending entity. The 440 receiving entity MUST NOT require its absence and if present MUST 441 gracefully handle its presence. 443 1.8. Structure of this document 445 Section 2 introduces the general PKI architecture and approach to 446 certificate management that is assumed in this document. Then it 447 lists the PKI management operations specified in this document, 448 partitioning them into mandatory, recommended, and optional ones. 450 Section 3 profiles the generic aspects of the PKI management 451 operations specified in detail in Section 4 and Section 5 to minimize 452 redundancy in the description and to ease implementation. This 453 covers the general structure and protection of messages, as well as 454 generic prerequisites, validation, and error handling. 456 Section 4 profiles the exchange of CMP messages between an EE and the 457 PKI management entity. There are various flavors of certificate 458 enrollment requests, optionally with polling, central key generation, 459 revocation, and general support PKI management operations. 461 Section 5 profiles responding to requests, exchange between PKI 462 management entities, and operations on behalf of other PKI entities. 463 This may include delayed delivery of messages, which involves polling 464 for responses, and nesting of messages. 466 Section 6 outlines several mechanisms for CMP message transfer, 467 including HTTP-based [RFC6712] transfer optionally using TLS, and 468 [I-D.ietf-ace-cmpv2-coap-transport] transfer optionally using DTLS, 469 and offline file-based transport. 471 Section 7 defines which parts of the profile are mandatory, 472 recommended, optional, or not relevant to implement for which type of 473 entity. 475 1.9. Convention and Terminology 477 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 478 "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and 479 "OPTIONAL" in this document are to be interpreted as described in BCP 480 14 [RFC2119] [RFC8174] when, and only when, they appear in all 481 capitals, as shown here. 483 Technical terminology is used in conformance with RFC 4210 [RFC4210], 484 RFC 4211 [RFC4211], RFC 5280 [RFC5280], and IEEE 802.1AR 485 [IEEE.802.1AR_2018]. The following key words are used: 487 CA: Certification authority, which issues certificates. 489 RA: Registration authority, an optional PKI component to which a CA 490 delegates certificate management functions such as end entity 491 authentication and authorization checks for incoming requests. 492 An RA can also provide conversion between various certificate 493 management protocols and other protocols providing some 494 operations related to certificate management. 496 LRA: Local registration authority, a specific form of RA with 497 proximity to the end entities. 499 Note: For ease of reading, this document uses the term "RA" 500 also for LRAs in all cases where the difference is not 501 relevant. 503 KGA: Key generation authority, an optional system component, 504 typically co-located with an RA or CA, that offers key 505 generation services to end entities. 507 EE: End entity, typically a device or service that holds a public- 508 private key pair for which it manages a public-key certificate. 509 An identifier for the EE is given as the subject of its 510 certificate. 512 The following terminology is reused from RFC 4210 [RFC4210], as 513 follows: 515 PKI management operation: All CMP messages belonging to a single 516 transaction. The transaction is 517 identified by the transactionID field of 518 the message headers. 520 PKI management entity: A non-EE PKI entity, i.e., RA or CA. 522 PKI entity: An EE or PKI management entity. 524 2. Solution architecture 526 To facilitate secure automatic certificate enrollment, the device 527 hosting an EE is typically equipped with a manufacturer-issued device 528 certificate. Such a certificate is typically installed during 529 production and is meant to identify the device throughout its 530 lifetime. This certificate can be used to protect the initial 531 enrollment of operational certificates after installation of the EE 532 in its operational environment. In contrast to the manufacturer- 533 issued device certificate, operational certificates are issued by the 534 owner or operator of the device to identify the device or one of its 535 components for operational use, e.g., in a security protocol like 536 IPsec, TLS, or SSH. In IEEE 802.1AR [IEEE.802.1AR_2018] a 537 manufacturer-issued device certificate is called IDevID certificate 538 and an operational certificate is called LDevID certificate. 540 Note: According to IEEE 802.1AR [IEEE.802.1AR_2018] a DevID comprises 541 the triple of the certificate, the corresponding private key, and the 542 certificate chain. 544 All certificate management operations specified in this document 545 follow the pull model, i.e., are initiated by an EE (or by an RA 546 acting as an EE). The EE creates a CMP request message, protects it 547 using some asymmetric credential or shared secret information and 548 sends it to its locally reachable PKI management entity. This PKI 549 management entity may be a CA or more typically an RA, which checks 550 the request, responds to it itself, or forwards the request upstream 551 to the next PKI management entity. In case an RA changes the CMP 552 request message header or body or wants to demonstrate successful 553 verification or authorization, it can apply a protection of its own. 554 Especially the communication between an LRA and RA can be performed 555 synchronously or asynchronously. Synchronous communication describes 556 a timely uninterrupted communication between two communication 557 partners, while asynchronous communication is not performed in a 558 timely consistent manner, e.g., because of a delayed message 559 delivery. 561 +-----+ +-----+ +-----+ +-----+ 562 | | | | | | | | 563 | EE |<---------->| LRA |<-------------->| RA |<---------->| CA | 564 | | | | | | | | 565 +-----+ +-----+ +-----+ +-----+ 567 synchronous (a)synchronous (a)synchronous 568 +----connection----+------connection------+----connection----+ 570 operators service partner 571 +---------on site--------+----back-end services-----+-trust center-+ 573 Figure 1: Certificate management architecture example 575 In operational environments the certificate management architecture 576 can have multiple LRAs bundling requests from multiple EEs at 577 dedicated locations and one (or more than one) central RA aggregating 578 the requests from the LRAs. Every LRA in this scenario has shared 579 secret information (one per EE) for MAC-based protection or a CMP 580 protection key and certificate allowing it to (re-)protect CMP 581 messages it processes. The figure above shows an architecture 582 example with at least one LRA, RA, and CA. It is also possible not 583 to have an RA or LRA or that there is no CA with a CMP interface. 584 Depending on the network infrastructure, the message transfer between 585 PKI management entities may be based on synchronous online 586 connections, asynchronous connections, or even offline (e.g., file- 587 based) transfer. 589 Note: CMP response messages could also be used proactively to 590 implement the push model towards the EE. In this case the EE acts as 591 receiver, not initiating the interaction with the PKI. Also, when 592 using a commissioning tool or a registrar agent as described in BRSKI 593 with Pledge in Responder Mode (BRSKI-PRM) [I-D.ietf-anima-brski-prm], 594 certificate enrollment in a push model is needed. CMP in general and 595 the messages specified in this profile offer all required 596 capabilities, but the message flow and state machine as described in 597 Section 4 must be adapted to implement a push model. 599 Third-party CAs may implement other variants of CMP, different 600 standardized protocols, or even proprietary interfaces for 601 certificate management. Therefore, the RA may need to adapt the 602 exchanged CMP messages to the flavor of certificate management 603 interaction required by the CA. 605 3. Generic aspects of the PKI message 607 This section covers the generic aspects of the PKI management 608 operations specified in Section 4 and Section 5 as upfront general 609 requirements to minimize redundancy in the description and to ease 610 implementation. 612 As described in Section 5.1 of RFC 4210 [RFC4210], all CMP messages 613 have the following general structure: 615 +--------------------------------------------+ 616 | PKIMessage | 617 | +----------------------------------------+ | 618 | | header | | 619 | +----------------------------------------+ | 620 | +----------------------------------------+ | 621 | | body | | 622 | +----------------------------------------+ | 623 | +----------------------------------------+ | 624 | | protection (OPTIONAL) | | 625 | +----------------------------------------+ | 626 | +----------------------------------------+ | 627 | | extraCerts (OPTIONAL) | | 628 | +----------------------------------------+ | 629 +--------------------------------------------+ 631 Figure 2: CMP message structure 633 The general contents of the message header, protection, and 634 extraCerts fields are specified in the following three subsections. 636 In case a specific PKI management operation needs different contents 637 in the header, protection, or extraCerts fields, the differences are 638 described in the respective subsections. 640 The CMP message body contains the PKI management operation-specific 641 information. It is described in Section 4 and Section 5. 643 The generic prerequisites needed by the PKI entities in order to be 644 able to perform PKI management operations are described in 645 Section 3.4. 647 The generic validation steps to be performed by PKI entities on 648 receiving a CMP message are described in Section 3.5. 650 The generic aspects of handling and reporting errors are described in 651 Section 3.6. 653 3.1. General description of the CMP message header 655 This section describes the generic header fields of all CMP messages 656 with signature-based protection. 658 In case a message has MAC-based protection the changes are described 659 in Section 4.1.5. The variations will affect the fields sender, 660 protectionAlg, and senderKID. 662 Any PKI management operation-specific fields or variations are 663 described in Section 4 and 5. 665 header 666 pvno REQUIRED 667 -- MUST be 3 to indicate CMP v3 in all cases where EnvelopedData 668 -- is supported and expected to be used in the current 669 -- PKI management operation 670 -- MUST be 3 to indicate CMP v3 in certConf messages when using 671 -- the hashAlg field 672 -- MUST be 2 to indicate CMP v2 in all other cases 673 -- For details on version negotiation see RFC-CMP-Updates 674 sender REQUIRED 675 -- SHOULD contain a name representing the originator of the 676 -- message; otherwise, the NULL-DN (a zero-length 677 -- SEQUENCE OF RelativeDistinguishedNames) MUST be used 678 -- SHOULD be the subject of the CMP protection certificate, i.e., 679 -- the certificate corresponding to the private key used to sign 680 -- the message 681 -- In a multi-hop scenario, the receiving entity SHOULD NOT rely 682 -- on the correctness of the sender field. 683 recipient REQUIRED 684 -- SHOULD be the name of the intended recipient; otherwise, the 685 -- NULL-DN MUST be used 686 -- In the first message of a PKI management operation: 687 -- SHOULD be the subject DN of the CA the PKI management 688 -- operation is requested from 689 -- In all other messages: 690 -- SHOULD contain the value of the sender field of the previous 691 -- message in the same PKI management operation 692 -- The recipient field SHALL be handled gracefully by the 693 -- receiving entity, because in a multi-hop scenario its 694 -- correctness cannot be guaranteed. 695 messageTime RECOMMENDED 696 -- MUST be the time at which the message was produced, if present 697 protectionAlg REQUIRED 698 -- MUST be an algorithm identifier indicating the algorithm 699 -- used for calculating the protection bits 700 -- If it is a signature algorithm its type MUST be a 701 -- MSG_SIG_ALG as specified in [RFC-CMP-Alg] Section 3 and 702 -- MUST be consistent with the subjectPublicKeyInfo field of 703 -- the protection certificate 704 -- If it is a MAC algorithm its type MUST be a MSG_MAC_ALG as 705 -- specified in [RFC-CMP-Alg] Section 6.1 706 senderKID RECOMMENDED 707 -- MUST be the SubjectKeyIdentifier of the CMP protection 708 -- certificate in case of signature-based protection 709 transactionID REQUIRED 710 -- In the first message of a PKI management operation: 711 -- MUST be 128 bits of random data, to minimize the probability 712 -- of having the transactionID already in use at the server 713 -- In all other messages: 714 -- MUST be the value from the previous message in the same 715 -- PKI management operation 716 senderNonce REQUIRED 717 -- MUST be cryptographically secure and fresh 128 random bits 718 recipNonce RECOMMENDED 719 -- If this is the first message of a transaction: SHOULD be 720 -- absent 721 -- If this is a delayed response message: MUST be present and 722 -- contain the value of the senderNonce of the respective request 723 -- message in the same transaction 724 -- In all other messages: MUST be present and contain the value 725 -- of the senderNonce of the previous message in the same 726 -- transaction 727 generalInfo OPTIONAL 728 implicitConfirm OPTIONAL 729 -- RECOMENDED in ir/cr/kur/p10cr messages, 730 -- OPTIONAL in ip/cp/kup response messages, and 731 -- PROHIBITED in other types of messages 732 -- Added to request messages to request omission of the certConf 733 -- message 734 -- Added to response messages to grant omission of the certConf 735 -- message 736 -- See [RFC4210] Section 5.1.1.1. 737 ImplicitConfirmValue REQUIRED 738 -- ImplicitConfirmValue MUST be NULL 739 certProfile OPTIONAL 740 -- MAY be present in ir/cr/kur/p10cr and in genm messages of type 741 -- id-it-certReqTemplate 742 -- MUST be omitted in all other messages 743 -- See [RFC-CMP-Updates] 744 CertProfileValue REQUIRED 745 -- MUST contain exactly one UTF8String element 746 -- MUST contain the name of a certificate profile 748 3.2. General description of the CMP message protection 750 This section describes the generic protection field contents of all 751 CMP messages with signature-based protection. The private key used 752 to sign a CMP message is called "protection key" and the related 753 certificate is called "protection certificate". Any included 754 keyUsage extension SHOULD allow digitalSignature. 756 protection RECOMMENDED 757 -- MUST contain the signature calculated using the private key 758 -- of the entity protecting the message. The signature 759 -- algorithm used MUST be given in the protectionAlg field. 761 Generally, CMP message protection is required for CMP messages, but 762 there are cases where protection of error messages specified in 763 Section 3.6 is not possible and therefore MAY be omitted. 765 For MAC-based protection as specified in Section 4.1.5 major 766 differences apply as described there. 768 The CMP message protection provides, if available, message origin 769 authentication and integrity protection for the header and body. The 770 CMP message extraCerts field is not covered by this protection. 772 Note: The extended key usages described in CMP Updates Section 2.2 773 [I-D.ietf-lamps-cmp-updates] can be used for authorization of a 774 sending PKI management entity. 776 3.3. General description of CMP message extraCerts 778 This section describes the generic extraCerts field of all CMP 779 messages with signature-based protection. Any specific requirements 780 on the extraCerts are specified in the respective PKI management 781 operation. 783 extraCerts 784 -- SHOULD contain the CMP protection certificate together with 785 -- its chain, if needed 786 -- If present, the first certificate in this field MUST be 787 -- the CMP protection certificate followed by its chain 788 -- where each element SHOULD directly certify the one 789 -- immediately preceding it. 790 -- Self-signed certificates SHOULD be omitted from extraCerts, 791 -- unless they are the same as the protection certificate and 792 -- MUST NOT be trusted based on their inclusion in any case 794 Note: For maximum compatibility, all implementations SHOULD be 795 prepared to handle potentially additional certificates and arbitrary 796 orderings of the certificates. 798 3.4. Generic PKI management operation prerequisites 800 This subsection describes what is generally needed by the PKI 801 entities to be able to perform PKI management operations. 803 Identification of PKI entities: 805 * Each EE SHOULD know its own identity to fill the sender field. 807 * Each EE SHOULD know the intended recipient of its requests to fill 808 the recipient field, e.g., the name of the addressed CA. 810 Note: This name may be established using an enrollment voucher, 811 e.g., [RFC8366], the issuer field from a CertReqTemplate response 812 message content, or by other configuration means. 814 Routing of CMP messages: 816 * Each PKI entity sending messages upstream MUST know the address 817 needed for transferring messages to the next PKI management 818 entity. 820 Note: This address may depend on the recipient, the certificate 821 profile, and on the used transfer mechanism. 823 Authentication of PKI entities: 825 * Each PKI entity MUST have credentials to authenticate itself. For 826 signature-based protection it MUST have a private key and the 827 corresponding certificate along with its chain. 829 * Each PKI entity MUST be able to establish trust in PKI it receives 830 responses from. When signature-based protection is used, it MUST 831 have the trust anchor(s) and any certificate status information 832 needed to perform path validation of CMP protection certificates 833 used for signature-based protection. 835 Note: A trust anchor usually is a root certificate of the PKI 836 addressed by the requesting EE. It may be established by 837 configuration or in an out-of-band manner. For an EE it may be 838 established using an enrollment voucher [RFC8366] or in-band of 839 CMP by the caPubs field in a certificate response message. 841 Authorization of PKI management operations: 843 * Each EE or RA MUST have sufficient information to be able to 844 authorize the PKI management entity for performing the upstream 845 PKI management operation. 847 Note: This may be achieved for example by using the cmcRA extended 848 key usage in server certificates, by local configuration such as 849 specific name patterns for subject DN or SAN portions that may 850 identify an RA, and/or by having a dedicated root CA usable only 851 for authenticating PKI management entities. 853 * Each PKI management entity MUST have sufficient information to be 854 able to authorize the downstream PKI entity requesting the PKI 855 management operation. 857 Note: For authorizing an RA the same examples apply as above. The 858 authorization of EEs can be very specific to the application 859 domain based on local PKI policy. 861 3.5. Generic validation of a PKI message 863 This section describes generic validation steps of each PKI entity 864 receiving a PKI request or response message before any further 865 processing or forwarding. If a PKI management entity decides to 866 terminate a PKI management operation because a check failed, it MUST 867 send a negative response or an error message as described in 868 Section 3.6. The PKIFailureInfo bits given below in parentheses MAY 869 be used in the failInfo field of the PKIStatusInfo as described in 870 Section 3.6.4, see also RFC 4210 Appendix F [RFC4210]. 872 All PKI message header fields not mentioned in this section like the 873 recipient and generalInfo fields SHOULD be handled gracefully on 874 reception. 876 The following list describes the basic set of message input 877 validation steps. Without these checks the protocol becomes 878 dysfunctional. 880 * The formal ASN.1 syntax of the whole message MUST be compliant 881 with the definitions given in CMP [RFC4210] and 882 [I-D.ietf-lamps-cmp-updates], CRMF [RFC4211], and CMS [RFC5652] 883 and [RFC8933]. (failInfo: badDataFormat) 885 * The pvno MUST be cmp2000(2) or cmp2021(3). (failInfo bit: 886 unsupportedVersion) 888 * The transactionID MUST be present. (failInfo bit: badDataFormat) 889 * The PKI message body type MUST be one of the message types 890 supported by the receiving PKI entity and MUST be allowed in the 891 current state of the PKI management operation identified by the 892 given transactionID. (failInfo bit: badRequest) 894 The following list describes the set of message input validation 895 steps required to ensure secure protocol operation: 897 * The senderNonce MUST be present and MUST contain at least 128 bits 898 of data. (failInfo bit: badSenderNonce) 900 * Unless the PKI message is the first message of a PKI management 901 operation, 903 - the recipNonce MUST be present and MUST equal the senderNonce 904 of the previous message or equal the senderNonce of the most 905 recent request message for which the response was delayed, in 906 case of delayed delivery as specified in Section 4.4. (failInfo 907 bit: badRecipientNonce) 909 * The message protection MUST be validated: 911 - The protection MUST be signature-based except if MAC-based 912 protection is used as described in Section 4.1.5 and for some 913 error messages as described in Section 3.6.4. (failInfo bit: 914 wrongIntegrity) 916 - The senderKID SHOULD identify the key material used for 917 verifying the message protection. (failInfo bit: 918 badMessageCheck) 920 - The protection, if present, MUST be validated successfully. If 921 signature-based protection is used, the CMP protection 922 certificate MUST be successfully validated including path 923 validation using a trust anchor and MUST be authorized 924 according to local policies. If the keyUsage extension is 925 present in the CMP protection certificate the digitalSignature 926 bit SHOULD be set. (failInfo bit: badAlg, badMessageCheck, or 927 signerNotTrusted) 929 - The sender of a request message MUST be authorized for 930 requesting the operation according to PKI policies. (failInfo 931 bit: notAuthorized) 933 Note: The requirements for checking certificates given in RFC 5280 934 [RFC5280] MUST be followed for signature-based CMP message 935 protection. Unless the message is a positive ip/cp/kup where the 936 issuing CA certificate of the newly enrolled certificate is the same 937 as the CMP protection certificate of that message, certificate status 938 checking SHOULD be performed on the CMP protection certificates. 940 Depending on local policies, one or more of the input validation 941 checks described below need to be implemented: 943 * If signature-based protection is used, the sender field SHOULD 944 match the subject of the CMP protection certificate. (failInfo 945 bit: badMessageCheck) 947 * If the messageTime is present, it SHOULD be close to the current 948 time. (failInfo bit: badTime) 950 3.6. Error handling 952 This section describes how a PKI entity handles error conditions on 953 messages it receives. Each error condition SHOULD be logged 954 appropriately. 956 3.6.1. Reporting error conditions upstream 958 An EE SHALL NOT send error messages. PKI management entities SHALL 959 NOT send error messages in upstream direction, either. 961 In case an EE rejects a newly issued certificate contained in an ip, 962 cp, or kup message and implicit confirmation has not been granted, 963 the EE MUST report this using a certConf message with "rejection" 964 status and await the pkiConf response as described in Section 4.1.1. 966 On all other error conditions regarding response messages, the EE or 967 PKI management entity MUST regard the current PKI management 968 operation as terminated with failure. The error conditions include 970 * invalid response message header, body type, protection, or 971 extraCerts according to the checks described in Section 3.5, 973 * any issue detected with response message contents, 975 * receipt of an error message from upstream, 977 * timeout occurred while waiting for a response, 979 * rejection of a newly issued certificate while implicit 980 confirmation has been granted. 982 Upstream PKI management entities will not receive any CMP message to 983 learn that the PKI management operation has been terminated. In case 984 they expect a further message from the EE, a connection interruption 985 or timeout will occur. Then they also MUST regard the current PKI 986 management operation as terminated with failure and MUST NOT attempt 987 to send an error message downstream. 989 3.6.2. Reporting error conditions downstream 991 In case the PKI management entity detects an error condition, e.g., 992 rejecting the request due to policy decision, in the body of an ir, 993 cr, p10cr, kur, or rr message received from downstream, it SHOULD 994 report the error in the specific response message, i.e., an ip, cp, 995 kup, or rp with "rejection" status, as described in Section 4.1.1 and 996 Section 4.2. This can also happen in case of polling. 998 In case the PKI management entity detects any other error condition 999 on requests, including pollReq, certConf, genm, and nested messages, 1000 received from downstream and on responses received from upstream, 1001 such as invalid message header, body type, protection, or extraCerts 1002 according to the checks described in Section 3.5 it MUST report them 1003 downstream in the form of an error message as described in 1004 Section 3.6.4. 1006 3.6.3. Handling error conditions on nested messages used for batching 1008 Batching of messages using nested messages as described in 1009 Section 5.2.2.2 requires special error handling. 1011 If the error condition is on an upstream nested message containing 1012 batched requests, it MUST NOT attempt to respond to the individual 1013 requests included in it. 1015 In case a PKI management entity receives an error message in response 1016 to a nested message, it must propagate the error by responding with 1017 an error message to each of the request messages contained in the 1018 nested message. 1020 In case a PKI management entity detects an error condition on the 1021 downstream nested message received in response to a nested message 1022 sent before, it MAY ignore this error condition and handle the 1023 response as described in Section 5.2.2.2. Otherwise, it MUST 1024 propagate the error by responding with an error message to each of 1025 the requests contained in the nested message it sent originally. 1027 3.6.4. Reporting error conditions 1029 When sending any kind of negative response, including error messages, 1030 a PKI entity MUST indicate the error condition in the PKIStatusInfo 1031 structure of the respective message as described below. It then MUST 1032 regard the current PKI management operation as terminated with 1033 failure. 1035 The PKIStatusInfo structure is used to report errors. It may be part 1036 of various message types, in particular: certConf, ip, cp, kup, and 1037 error. The PKIStatusInfo structure consists of the following fields: 1039 * status: Here the PKIStatus value "rejection" MUST be used. 1041 Note: When a PKI management entity indicates delayed delivery of a 1042 CMP response message to the EE with an error message as described 1043 in Section 4.4, the status "waiting" is used there. 1045 * statusString: Here any human-readable valid value for logging or 1046 to display via a user interface SHOULD be added. 1048 * failInfo: Here the PKIFailureInfo bits MAY be used in the way 1049 explained in Appendix F of RFC 4210 [RFC4210]. PKIFailureInfo 1050 bits regarding the validation described in Section 3.5 are 1051 referenced there. The PKIFailureInfo bits referenced in 1052 Section 5.1 and Section 6 are described here: 1054 - badCertId: A kur, certConf, or rr message references an unknown 1055 certificate 1057 - badPOP: An ir/cr/p10cr/kur contains an invalid proof-of- 1058 possession 1060 - certRevoked: Revocation requested for a certificate already 1061 revoked 1063 - badCertTemplate: The contents of a certificate request are not 1064 accepted, e.g., a field is missing or has a non-acceptable 1065 value or the given public key is already in use in some other 1066 certificate (depending on policy). 1068 - transactionIdInUse: This is sent by a PKI management entity in 1069 case the received request contains a transactionID that has 1070 already been used for another transaction. An EE receiving 1071 such error message SHOULD resend the request in a new 1072 transaction using a different transactionID. 1074 - notAuthorized: The sender of a request message is not 1075 authorized for requesting the operation. 1077 - systemUnavail: This is sent by a PKI management entity in case 1078 a back-end system is not available. 1080 - systemFailure: This is sent by a PKI management entity in case 1081 a back-end system is currently not functioning correctly. 1083 An EE receiving a systemUnavail or systemFailure failInfo SHOULD 1084 resend the request in a new transaction after some time. 1086 Detailed error message description: 1088 Error Message -- error 1090 Field Value 1092 header 1093 -- As described in Section 3.1 1095 body 1096 -- The message indicating the error that occurred 1097 error REQUIRED 1098 pKIStatusInfo REQUIRED 1099 status REQUIRED 1100 -- MUST have the value "rejection" 1101 statusString RECOMMENDED 1102 -- SHOULD be any human-readable text for debugging, logging 1103 -- or to display in a GUI 1104 failInfo OPTIONAL 1105 -- MAY be present and contain the relevant PKIFailureInfo bits 1107 protection REQUIRED 1108 -- As described in Section 3.2 1110 extraCerts OPTIONAL 1111 -- As described in Section 3.3 1113 4. End Entity PKI management operations 1115 This chapter focuses on the communication of an EE with the PKI 1116 management entity it directly talks to. Depending on the network and 1117 PKI solution, this can be an RA or directly a CA. Handling of a 1118 message by a PKI management entity is described in Section 5. 1120 The PKI management operations specified in this section cover the 1121 following: 1123 * Requesting a certificate with variations like initial enrollment, 1124 certificate updates, central key generation, and MAC-based 1125 protection 1127 * Revoking a certificate 1129 * Support messages 1131 These operations mainly specify the message body of the CMP messages 1132 and utilize the specification of the message header, protection and 1133 extraCerts as specified in Section 3. The messages are named by the 1134 respective field names in PKIBody like ir, ip, cr, cp, etc., see 1135 RFC 4210 Section 5.1.2 [RFC4210]. 1137 The following diagram shows the EE state machine covering all PKI 1138 management operations described in this section, including negative 1139 responses, error messages described in Section 3.6.4, as well as 1140 ip/cp/kup/error messages with status "waiting", pollReq, and pollRep 1141 messages described in Section 4.4. 1143 On receiving messages from upstream, the EE MUST perform the general 1144 validation checks described in Section 3.5. The behavior in case an 1145 error occurs is described in Section 3.6. 1147 State machine: 1148 start 1149 | 1150 | send ir/cr/p10cr/kur/rr/genm 1151 v 1152 waiting for response 1153 | 1154 +--------------------------+--------------------------+ 1155 | | | 1156 | receives ip/cp/kup with | received ip/cp/kup/error | received 1157 | status "accepted" or | with status "waiting" | rp/genp or 1158 | "grantedWithMods" | | ip/cp/kup/ 1159 | v | error 1160 | +-------> polling | with status 1161 | | | | "rejection" 1162 | | received | send | 1163 | | pollRep | pollReq | 1164 | | v | 1165 | | waiting for response | 1166 | | | | 1167 | +------------+--------+ | 1168 | | | | 1169 | received ip/cp/kup | | received | 1170 | with status "accepted" | | rp/genp or | 1171 | or "grantedWithMods" | | ip/cp/kup/error | 1172 | | | with status | 1173 +---------->+<-------------+ | "rejection" | 1174 | | | 1175 +-----------+-----+ | | 1176 | | | | 1177 | implicitConfirm | implicitConfirm | | 1178 | granted | not granted | | 1179 | | | | 1180 | | send certConf | | 1181 | v | | 1182 | waiting for pkiConf*) | | 1183 | | | | 1184 | | received | | 1185 | | pkiConf | | 1186 +-----------------+------->+<-------+-----------------+ 1187 | 1188 v 1189 end 1191 *) in case of a delayed delivery of pkiConf responses the same 1192 polling mechanism is initiated as for rp or genp messages, by 1193 sending an error message with status "waiting". 1195 Note: All CMP messages belonging to the same PKI management operation 1196 MUST have the same transactionID because the message receiver 1197 identifies the elements of the operation in this way. 1199 This section is aligned with CMP [RFC4210], CMP Updates 1200 [I-D.ietf-lamps-cmp-updates], and CMP Algorithms 1201 [I-D.ietf-lamps-cmp-algorithms]. 1203 Guidelines as well as an algorithm use profile for this document are 1204 available in CMP Algorithms [I-D.ietf-lamps-cmp-algorithms]. 1206 4.1. Requesting a new certificate from a PKI 1208 There are various approaches for requesting a certificate from a PKI. 1210 These approaches differ in the way the EE authenticates itself to the 1211 PKI, in the form of the request being used, and how the key pair to 1212 be certified is generated. The authentication mechanisms may be as 1213 follows: 1215 * Using a certificate from an external PKI, e.g., a manufacturer- 1216 issued device certificate, and the corresponding private key 1218 * Using a private key and certificate issued from the same PKI that 1219 is addressed for requesting a certificate 1221 * Using the certificate to be updated and the corresponding private 1222 key 1224 * Using shared secret information known to the EE and the PKI 1225 management entity 1227 An EE requests a certificate indirectly or directly from a CA. When 1228 the PKI management entity handles the request as described in 1229 Section 5.1.1 and responds with a message containing the requested 1230 certificate, the EE MUST reply with a confirmation message unless 1231 implicitConfirm was granted. The PKI management entity then MUST 1232 handle it as described in Section 5.1.3 and respond with a 1233 confirmation, closing the PKI management operation. 1235 The message sequences described in this section allow the EE to 1236 request certification of a locally or centrally generated public- 1237 private key pair. Typically, the EE provides a signature-based 1238 proof-of-possession of the private key associated with the public key 1239 contained in the certificate request as defined by RFC 4211 1240 Section 4.1 [RFC4211] case 3. To this end it is assumed that the 1241 private key can technically be used for signing. This is the case 1242 for the most common algorithms RSA and ECDSA, regardless of 1243 potentially intended restrictions of the key usage. 1245 Note: In conformance with NIST SP 800-57 Part 1 Section 8.1.5.1.1.2 1246 [NIST.SP.800-57p1r5] the newly generated private key MAY be used for 1247 self-signature, if technically possible, even if the keyUsage 1248 extension requested in the certificate request prohibits generation 1249 of digital signatures. 1251 The requesting EE provides the binding of the proof-of-possession to 1252 its identity by signature-based or MAC-based protection of the CMP 1253 request message containing that POP. An upstream PKI management 1254 entity should verify whether this EE is authorized to obtain a 1255 certificate with the requested subject and other fields and 1256 extensions. 1258 The EE MAY indicate the certificate profile to use in the certProfile 1259 extension of the generalInfo field in the PKIHeader of the 1260 certificate request message as described in Section 3.1. 1262 In case the EE receives a CA certificate in the caPubs field for 1263 installation as a new trust anchor, it MUST properly authenticate the 1264 message and authorize the sender as trusted source of the new trust 1265 anchor. This authorization is typically indicated using shared 1266 secret information for protecting an initialization response (ir) 1267 message. Authorization can also be signature-based using a 1268 certificate issued by another PKI that is explicitly authorized for 1269 this purpose. A certificate received in caPubs MUST NOT be accepted 1270 as a trust anchor if it is the root CA certificate of the certificate 1271 used for protecting the message. 1273 4.1.1. Requesting a certificate from a new PKI with signature-based 1274 protection 1276 This PKI management operation should be used by an EE to request a 1277 certificate from a new PKI using an existing certificate from an 1278 external PKI, e.g., a manufacturer-issued IDevID certificate 1279 [IEEE.802.1AR_2018], to authenticate itself to the new PKI. 1281 Note: In Bootstrapping Remote Secure Key Infrastructure (BRSKI) 1282 [RFC8995] environments, BRSKI Asynchronous Enrollment (BRSKI-AE) 1283 [I-D.ietf-anima-brski-async-enroll] describes a generalization 1284 regarding enrollment protocols alternative to EST [RFC7030]. As 1285 replacement of EST simpleenroll, BRSKI-AE uses this PKI management 1286 operation for bootstrapping LDevID certificates. 1288 Specific prerequisites augmenting the prerequisites in Section 3.4: 1290 * The certificate of the EE MUST have been enrolled by an external 1291 PKI, e.g., a manufacturer-issued device certificate. 1293 * The PKI management entity MUST have the trust anchor of the 1294 external PKI. 1296 * When using the generalInfo field certProfile, the EE MUST know the 1297 identifier needed to indicate the requested certificate profile. 1299 Message flow: 1301 Step# EE PKI management entity 1302 1 format ir 1303 2 -> ir -> 1304 3 handle or 1305 forward ir 1306 4 format or receive ip 1307 5 possibly grant 1308 implicitConfirm 1309 6 <- ip <- 1310 7 handle ip 1312 ----------------- if implicitConfirm not granted ----------------- 1314 8 format certConf 1315 9 -> certConf -> 1316 10 handle or 1317 forward certConf 1318 11 format or receive pkiConf 1319 12 <- pkiConf <- 1320 13 handle pkiConf 1322 For this PKI management operation, the EE MUST include exactly one 1323 CertReqMsg in the ir. If more certificates are required, further 1324 requests MUST be sent using separate PKI management operation. 1326 The EE SHOULD include the implicitConfirm extension in the header of 1327 the ir message as described in Section 3.1, unless it knows that 1328 certificate confirmation is needed. This leaves the choice to the 1329 PKI management entities whether the EE must send a certConf message 1330 on receiving a new certificate. Depending on the PKI policy and 1331 requirements for managing EE certificates, it can be important for 1332 PKI management entities to learn if the EE accepted the new 1333 certificate. In such cases, when responding with an ip message, the 1334 PKI management entity MUST NOT include the implicitConfirm extension. 1335 In case the PKI management entity does not need any explicit 1336 confirmation from the EE, it MUST include the extension as described 1337 in Section 3.1. This prevents explicit certificate confirmation and 1338 saves the overhead of a further message round-trip. 1340 If the EE did not request implicit confirmation or implicit 1341 confirmation was not granted by the PKI management entity, 1342 certificate confirmation MUST be performed as follows. If the EE 1343 successfully received the certificate, it MUST send a certConf 1344 message in due time. On receiving a valid certConf message, the PKI 1345 management entity MUST respond with a pkiConf message. If the PKI 1346 management entity does not receive the expected certConf message in 1347 time it MUST handle this like a rejection by the EE. In case of 1348 rejection, depending on its policy the PKI management entity MAY 1349 revoke the newly issued certificate, notify a monitoring system, or 1350 log the event internally. 1352 Note: Depending on PKI policy, a new certificate may be published by 1353 a PKI management entity, and explicit confirmation may be required. 1354 In this case it is advisable not to do the publication until a 1355 positive certificate confirmation has been received. This way the 1356 need to revoke the certificate on negative confirmation is avoided. 1358 If the certificate request was rejected by the CA, the PKI management 1359 entity must return an ip message containing the status code 1360 "rejection" as described in Section 3.6 and no certifiedKeyPair 1361 field. The EE MUST NOT react to such an ip message with a certConf 1362 message and the PKI management operation MUST be terminated. 1364 Detailed message description: 1366 Initialization Request -- ir 1368 Field Value 1370 header 1371 -- As described in Section 3.1 1373 body 1374 -- The request of the EE for a new certificate 1375 ir REQUIRED 1376 -- MUST contain exactly one CertReqMsg 1377 -- If more certificates are required, further PKI management 1378 -- operations MUST be initiated 1379 certReq REQUIRED 1380 certReqId REQUIRED 1381 -- MUST be 0 1382 certTemplate REQUIRED 1383 version OPTIONAL 1384 -- MUST be 2 if supplied 1385 subject REQUIRED 1386 -- The EE subject name MUST be carried in the subject field 1387 -- and/or the subjectAltName extension. 1388 -- If subject name is present only in the subjectAltName 1389 -- extension, then the subject field MUST be a NULL-DN 1390 publicKey REQUIRED 1391 algorithm REQUIRED 1392 -- MUST include the subject public key algorithm identifier 1393 subjectPublicKey REQUIRED 1394 -- MUST contain the public key to be certified in case of local 1395 -- key generation 1396 extensions OPTIONAL 1397 -- MAY include end-entity-specific X.509 extensions of the 1398 -- requested certificate like subject alternative name, key 1399 -- usage, and extended key usage 1400 -- The subjectAltName extension MUST be present if the EE subject 1401 -- name includes a subject alternative name. 1402 popo OPTIONAL 1403 -- MUST be present if local key generation is used 1404 -- MUST be absent if central key generation is requested 1405 signature RECOMMENDED 1406 -- MUST be used by an EE if the key can be used for signing and 1407 -- has the type POPOSigningKey 1408 poposkInput PROHIBITED 1409 -- MUST NOT be used; it is not needed because subject and 1410 -- publicKey are both present in the certTemplate 1411 algorithmIdentifier REQUIRED 1412 -- The signature algorithm MUST be consistent with the publicKey 1413 -- algorithm field of the certTemplate 1414 signature REQUIRED 1415 -- MUST contain the signature value computed over the DER-encoded 1416 -- certTemplate 1417 raVerified OPTIONAL 1418 -- MAY be used by an RA after verifying the proof-of-possession 1419 -- provided by the EE 1421 protection REQUIRED 1422 -- As described in Section 3.2 1424 extraCerts REQUIRED 1425 -- As described in Section 3.3 1427 Initialization Response -- ip 1429 Field Value 1431 header 1432 -- As described in Section 3.1 1434 body 1435 -- The response of the CA to the request as appropriate 1436 ip REQUIRED 1437 caPubs OPTIONAL 1438 -- MAY be used if the certifiedKeyPair field is present 1439 -- If used it MUST contain only a trust anchor, e.g. root 1440 -- certificate, of the certificate contained in certOrEncCert 1441 response REQUIRED 1442 -- MUST contain exactly one CertResponse 1443 certReqId REQUIRED 1444 -- MUST be 0 1445 status REQUIRED 1446 -- PKIStatusInfo structure MUST be present 1447 status REQUIRED 1448 -- positive values allowed: "accepted", "grantedWithMods" 1449 -- negative values allowed: "rejection" 1450 -- "waiting" only allowed with polling use case as described in 1451 -- Section 4.4 1452 statusString OPTIONAL 1453 -- MAY be any human-readable text for debugging, logging or to 1454 -- display in a GUI 1455 failInfo OPTIONAL 1456 -- MAY be present if status is "rejection" 1457 -- MUST be absent if status is "accepted" or "grantedWithMods" 1458 certifiedKeyPair OPTIONAL 1459 -- MUST be present if status is "accepted" or "grantedWithMods" 1460 -- MUST be absent if status is "rejection" 1461 certOrEncCert REQUIRED 1462 -- MUST be present if status is "accepted" or "grantedWithMods" 1463 certificate REQUIRED 1464 -- MUST be present when certifiedKeyPair is present 1465 -- MUST contain the newly enrolled X.509 certificate 1466 privateKey OPTIONAL 1467 -- MUST be absent in case of local key generation or "rejection" 1468 -- MUST contain the encrypted private key in an EnvelopedData 1469 -- structure as specified in Section 4.1.6 in case the private 1470 -- key was generated centrally 1472 protection REQUIRED 1473 -- As described in Section 3.2 1475 extraCerts REQUIRED 1476 -- As described in Section 3.3 1477 -- MUST contain the chain of the certificate present in 1478 -- certOrEncCert 1479 -- Self-signed certificates SHOULD be omitted 1480 -- Duplicate certificates MAY be omitted 1482 Certificate Confirmation -- certConf 1484 Field Value 1486 header 1487 -- As described in Section 3.1 1489 body 1490 -- The message of the EE sends as confirmation to the PKI 1491 -- management entity to accept or reject the issued certificates 1492 certConf REQUIRED 1493 -- MUST contain exactly one CertStatus 1494 CertStatus REQUIRED 1495 certHash REQUIRED 1496 -- MUST be the hash of the certificate, using the hash algorithm 1497 -- indicated in hashAlg, see below, or the same one as used to 1498 -- create the certificate signature 1499 certReqId REQUIRED 1500 -- MUST be 0 1501 statusInfo RECOMMENDED 1502 -- PKIStatusInfo structure SHOULD be present 1503 -- Omission indicates acceptance of the indicated certificate 1504 status REQUIRED 1505 -- positive values allowed: "accepted" 1506 -- negative values allowed: "rejection" 1507 statusString OPTIONAL 1508 -- MAY be any human-readable text for debugging, logging, or to 1509 -- display in a GUI 1510 failInfo OPTIONAL 1511 -- MAY be present if status is "rejection" 1512 -- MUST be absent if status is "accepted" 1513 hashAlg OPTIONAL 1514 -- The hash algorithm to use for calculating certHash 1515 -- SHOULD NOT be used in all cases where the AlgorithmIdentifier 1516 -- of the certificate signature specifies a hash algorithm 1517 -- If used, the pvno field in the header MUST be cmp2021 (3) 1519 protection REQUIRED 1520 -- As described in Section 3.2 1521 -- MUST use the same credentials as in the first request message 1522 -- of this PKI management operation 1524 extraCerts RECOMMENDED 1525 -- As described in Section 3.3 1526 -- MAY be omitted if the message size is critical and 1527 -- the PKI management entity caches the extraCerts from the 1528 -- first request message of this PKI management operation 1530 PKI Confirmation -- pkiConf 1532 Field Value 1534 header 1535 -- As described in Section 3.1 1537 body 1538 pkiconf REQUIRED 1539 -- The content of this field MUST be NULL 1541 protection REQUIRED 1542 -- As described in Section 3.2 1543 -- MUST use the same credentials as in the first response 1544 -- message of this PKI management operation 1546 extraCerts RECOMMENDED 1547 -- As described in Section 3.3 1548 -- MAY be omitted if the message size is critical and the EE has 1549 -- cached the extraCerts from the first response message of 1550 -- this PKI management operation 1552 4.1.2. Requesting an additional certificate with signature-based 1553 protection 1555 This PKI management operation should be used by an EE to request an 1556 additional certificate of the same PKI it already has certificates 1557 from. The EE uses one of these existing certificates to authenticate 1558 itself by signing its request messages using the respective private 1559 key. 1561 Specific prerequisites augmenting the prerequisites in Section 3.4: 1563 * The certificate used by the EE MUST have been enrolled by the PKI 1564 it requests another certificate from. 1566 * When using the generalInfo field certProfile, the EE MUST know the 1567 identifier needed to indicate the requested certificate profile. 1569 The message sequence for this PKI management operation is identical 1570 to that given in Section 4.1.1, with the following changes: 1572 1 The body of the first request and response SHOULD be cr and cp, 1573 respectively. 1575 Note: Since the difference between ir/ip and cr/cp is 1576 syntactically not essential, an ir/ip MAY be used in this PKI 1577 management operation. 1579 2 The caPubs field in the certificate response message SHOULD be 1580 absent. 1582 4.1.3. Updating an existing certificate with signature protection 1584 This PKI management operation should be used by an EE to request an 1585 update for one of its certificates that is still valid. The EE uses 1586 the certificate it wishes to update as the protection certificate. 1587 Both for authenticating itself and for proving ownership of the 1588 certificate to be updated, it signs the request messages with the 1589 corresponding private key. 1591 Specific prerequisites augmenting the prerequisites in Section 3.4: 1593 * The certificate the EE wishes to update MUST NOT be expired or 1594 revoked and MUST have been issued by the addressed CA. 1596 * A new public-private key pair SHOULD be used. 1598 * When using the generalInfo field certProfile, the EE MUST know the 1599 identifier needed to indicate the requested certificate profile. 1601 The message sequence for this PKI management operation is identical 1602 to that given in Section 4.1.1, with the following changes: 1604 1 The body of the first request and response MUST be kur and kup, 1605 respectively. 1607 2 Protection of the kur MUST be performed using the certificate to 1608 be updated. 1610 3 The subject field and/or the subjectAltName extension of the 1611 certTemplate MUST contain the EE subject name of the existing 1612 certificate to be updated, without modifications. 1614 4 The certTemplate SHOULD contain the subject and/or subjectAltName 1615 extension and publicKey of the EE only. 1617 5 The oldCertId control MAY be used to make clear which certificate 1618 is to be updated. 1620 6 The caPubs field in the kup message MUST be absent. 1622 As part of the certReq structure of the kur the oldCertId control is 1623 added after the certTemplate field. 1625 controls 1626 type RECOMMENDED 1627 -- MUST be the value id-regCtrl-oldCertID, if present 1628 value 1629 issuer REQUIRED 1630 serialNumber REQUIRED 1631 -- MUST contain the issuer and serialNumber of the certificate 1632 -- to be updated 1634 4.1.4. Requesting a certificate from a legacy PKI using a PKCS#10 1635 request 1637 This PKI management operation can be used by an EE to request a 1638 certificate using a legacy PKCS#10 [RFC2986] request instead of CRMF 1639 [RFC4211]. This offers a variation of the PKI management operations 1640 specified in Section 4.1.2. 1642 In Secure Zero Touch Provisioning (SZTP) [RFC8572] environments, 1643 SZTP-CSR [I-D.ietf-netconf-sztp-csr] describes the use of a CMP p10cr 1644 message as a form of certificate signing request (CSR) to optionally 1645 include in device bootstrapping to obtain an identity certificate as 1646 part of the onboarding information. Such a CSR is of form ietf-sztp- 1647 types:cmp-csr from module ietf-sztp-csr. The requirements given 1648 below on p10cr message MUST be adhered to. 1650 In this PKI management operation, the public key and all further 1651 certificate template data MUST be contained in the subjectPKInfo and 1652 other certificationRequestInfo fields of the PKCS#10 structure. 1654 The prerequisites are the same as given in Section 4.1.2. 1656 The message sequence for this PKI management operation is identical 1657 to that given in Section 4.1.2, with the following changes: 1659 1 The body of the first request and response MUST be p10cr and cp, 1660 respectively. 1662 2 The certReqId in the cp message MUST be -1. 1664 3 The caPubs field in the cp message SHOULD be absent. 1666 Detailed description of the p10cr message: 1668 Certification Request -- p10cr 1670 Field Value 1672 header 1673 -- As described in Section 3.1 1675 body 1676 -- The request of the EE for a new certificate using a PKCS#10 1677 -- certificate request 1678 p10cr REQUIRED 1679 certificationRequestInfo REQUIRED 1680 version REQUIRED 1681 -- MUST be 0 to indicate PKCS#10 V1.7 1682 subject REQUIRED 1683 -- The EE subject name MUST be carried in the subject field 1684 -- and/or the subjectAltName extension. 1685 -- If subject name is present only in the subjectAltName 1686 -- extension, then the subject field MUST be a NULL-DN 1687 subjectPKInfo REQUIRED 1688 algorithm REQUIRED 1689 -- MUST include the subject public key algorithm identifier 1690 subjectPublicKey REQUIRED 1691 -- MUST include the public key to be certified 1692 attributes OPTIONAL 1693 -- MAY include end-entity-specific X.509 extensions of the 1694 -- requested certificate like subject alternative name, 1695 -- key usage, and extended key usage 1696 -- The subjectAltName extension MUST be present if the EE 1697 -- subject name includes a subject alternative name. 1698 signatureAlgorithm REQUIRED 1699 -- The signature algorithm MUST be consistent with the 1700 -- subjectPKInfo field. 1701 signature REQUIRED 1702 -- MUST contain the self-signature for proof-of-possession 1704 protection REQUIRED 1705 -- As described for the underlying PKI management operation 1707 extraCerts REQUIRED 1708 -- As described for the underlying PKI management operation 1710 4.1.5. Requesting a certificate from a PKI with MAC-based protection 1712 This is a variant of the PKI management operations described in 1713 Section 4.1.1 to Section 4.1.4. It should be used by an EE to 1714 request a certificate of a new PKI in case it does not have a 1715 certificate to prove its identity to the target PKI, but has some 1716 secret information shared with the PKI management entity. Therefore, 1717 the request and response messages are MAC-protected using this shared 1718 secret information. The distribution of this shared secret is out of 1719 scope for this document. The PKI management entity checking the MAC- 1720 based protection SHOULD replace this protection according to 1721 Section 5.2.3 in case the next hop does not know the shared secret 1722 information. 1724 Note: The entropy of the shared secret information is crucial for the 1725 level of protection when using MAC-based protection. Further 1726 guidance is available in the security considerations of CMP updated 1727 by [I-D.ietf-lamps-cmp-updates]. 1729 Specific prerequisites augmenting the prerequisites in Section 3.4: 1731 * Rather than using private keys, certificates, and trust anchors, 1732 the EE and the PKI management entity MUST share secret 1733 information. 1735 Note: The shared secret information MUST be established out-of- 1736 band, e.g., by a service technician during initial local 1737 configuration. 1739 * When using the generalInfo field certProfile, the EE MUST know the 1740 identifier needed to indicate the requested certificate profile. 1742 The message sequence for this PKI management operation is identical 1743 to that given in Section 4.1.1, with the following changes: 1745 1 The protection of all messages MUST be MAC-based. 1747 2 The senderKID MUST contain a reference the recipient can use to 1748 identify the shared secret information used for the protection, 1749 e.g., the username of the EE. 1751 3 The extraCerts of all messages does not contain CMP protection 1752 certs and associated chains. 1754 See Section 6 of CMP Algorithms [I-D.ietf-lamps-cmp-algorithms] for 1755 details on message authentication code algorithms (MSG_MAC_ALG) to 1756 use. Typically, parameters are part of the protectionAlg field, 1757 e.g., used for key derivation, like a salt and an iteration count. 1758 Such fields SHOULD remain constant for message protection throughout 1759 this PKI management operation to reduce the computational overhead. 1761 4.1.6. Adding central key pair generation to a certificate request 1763 This is a variant of the PKI management operations described in 1764 Section 4.1.1 to Section 4.1.4 and the variant described in 1765 Section 4.1.5. It needs to be used in case an EE is not able to 1766 generate its new public-private key pair itself or central generation 1767 of the EE key material is preferred. It is a matter of the local 1768 implementation which PKI management entity will act as Key Generation 1769 Authority (KGA) and perform the key generation. This PKI management 1770 entity MUST use a certificate containing the additional extended key 1771 usage extension id-kp-cmKGA in order to be accepted by the EE as a 1772 legitimate key generation authority. 1774 As described in Section 5.3.1, the KGA can use one of the PKI 1775 management operations described in the sections above to request the 1776 certificate for this key pair on behalf of the EE. 1778 Generally speaking, in machine-to-machine scenarios it is strongly 1779 preferable to generate public-private key pairs locally at the EE. 1780 Together with proof-of-possession of the private key in the 1781 certificate request, this is advisable to make sure that the entity 1782 identified in the newly issued certificate is the only entity that 1783 knows the private key. 1785 Reasons for central key generation may include the following: 1787 * Lack of sufficient initial entropy. 1789 Note: Good random numbers are needed not only for key generation 1790 but also for session keys and nonces in any security protocol. 1791 Therefore, a decent security architecture should anyways support 1792 good random number generation on the EE side or provide enough 1793 initial entropy for the RNG seed to guarantee good pseudo-random 1794 number generation. Yet maybe this is not the case at the time of 1795 requesting an initial certificate during manufacturing. 1797 * Lack of computational resources, in particular for RSA key 1798 generation. 1800 Note: Since key generation could be performed in advance to the 1801 certificate enrollment communication, it is often not time 1802 critical. 1804 Note: As mentioned in Section 2, central key generation may be 1805 required in a push model, where the certificate response message is 1806 transferred by the PKI management entity to the EE without a previous 1807 request message. 1809 The EE requesting central key generation MUST omit the publicKey 1810 field from the certTemplate or, in case it has a preference on the 1811 key type to be generated, provide it in the algorithm sub-field and 1812 fill the subjectPublicKey sub-field with a zero-length BIT STRING. 1813 Both variants indicate to the PKI management entity that a new key 1814 pair shall be generated centrally on behalf of the EE. 1816 Note: As the protection of centrally generated keys in the response 1817 message has been extended to EncryptedKey by CMP Updates Section 2.7 1818 [I-D.ietf-lamps-cmp-updates], EnvelopedData is the preferred 1819 alternative to EncryptedValue. In CRMF Section 2.1.9 [RFC4211] the 1820 use of EncryptedValue has been deprecated in favor of the 1821 EnvelopedData structure. Therefore, this profile requires using 1822 EnvelopedData as specified in CMS Section 6 [RFC5652]. When 1823 EnvelopedData is to be used in a PKI management operation, CMP v3 1824 MUST be indicated in the message header already for the initial 1825 request message, see CMP Updates Section 2.19 and Section 2.20 1826 [I-D.ietf-lamps-cmp-updates]. 1828 +----------------------------------+ 1829 | EnvelopedData | 1830 | [RFC5652] section 6 | 1831 | +------------------------------+ | 1832 | | SignedData | | 1833 | | [RFC5652] section 5 | | 1834 | | +--------------------------+ | | 1835 | | | AsymmetricKeyPackage | | | 1836 | | | [RFC5958] | | | 1837 | | | +----------------------+ | | | 1838 | | | | privateKey | | | | 1839 | | | | OCTET STRING | | | | 1840 | | | +----------------------+ | | | 1841 | | +--------------------------+ | | 1842 | +------------------------------+ | 1843 +----------------------------------+ 1845 Figure 3: Encrypted private key container 1847 The PKI management entity delivers the private key in the privateKey 1848 field in the certifiedKeyPair structure of the response message also 1849 containing the newly issued certificate. 1851 The private key MUST be provided as an AsymmetricKeyPackage structure 1852 as defined in RFC 5958 [RFC5958]. 1854 This AsymmetricKeyPackage structure MUST be wrapped in a SignedData 1855 structure, as specified in CMS Section 5 [RFC5652] and [RFC8933], 1856 signed by the KGA generating the key pair. The signature MUST be 1857 performed using a private key related to a certificate asserting the 1858 extended key usage id-kp-cmKGA as described in CMP Updates 1859 Section 2.2 [I-D.ietf-lamps-cmp-updates] to demonstrate authorization 1860 to generate key pairs on behalf of an EE. The EE SHOULD validate the 1861 signer certificate contained in the SignedData structure and verify 1862 the presence of this extended key usage in the signer certificate. 1864 Note: When using password-based key management technique as described 1865 in Section 4.1.6.3 it may not be possible or meaningful to the EE to 1866 validate the KGA signature and the related certificate in the 1867 SignedData structure since shared secret information is used for 1868 initial authentication. In this case the EE MAY omit this 1869 validation. 1871 The SignedData structure MUST be wrapped in an EnvelopedData 1872 structure, as specified in CMS Section 6 [RFC5652], encrypting it 1873 using a newly generated symmetric content-encryption key. 1875 This content-encryption key MUST be securely provided as part of the 1876 EnvelopedData structure to the EE using one of three key management 1877 techniques. The choice of the key management technique to be used by 1878 the PKI management entity depends on the authentication mechanism the 1879 EE chose to protect the request message. See CMP Updates Section 2.7 1880 [I-D.ietf-lamps-cmp-updates] for more details on which key management 1881 technique to use. 1883 * Signature-based protection of the request message: 1885 - The content-encryption key SHALL be protected using the key 1886 agreement key management technique, see Section 4.1.6.1, if the 1887 certificate used by the EE for protecting the request message 1888 allows the key usage keyAgreement. If the certificate also 1889 allows the key usage keyEncipherment, the key transport key 1890 management technique SHALL NOT be used. 1892 - The content-encryption key SHALL be protected using the key 1893 transport key management technique, see Section 4.1.6.2, if the 1894 certificate used by the EE for protecting the respective 1895 request message allows the key usage keyEncipherment but not 1896 keyAgreement. 1898 * MAC-based protected of the request message: 1900 - The content-encryption key SHALL be protected using the 1901 password-based key management technique, see Section 4.1.6.3, 1902 if and only if the EE used MAC-based protection for the request 1903 message. 1905 If central key generation is supported, support of the key agreement 1906 key management technique is REQUIRED and support of key transport and 1907 password-based key management techniques are OPTION, for two reasons: 1908 The key agreement key management technique is supported by most 1909 asymmetric algorithms, while the key transport key management 1910 technique is supported only by a very few of them. The password- 1911 based key management technique shall only be used in combination with 1912 MAC-based protection, which is a sideline in this document. 1914 Specific prerequisites augmenting those of the respective certificate 1915 enrollment PKI management operations: 1917 * If signature-based protection is used, the EE MUST be able to 1918 authenticate and authorize the KGA, using suitable information, 1919 which includes a trust anchor. 1921 * If MAC-based protection is used, the KGA MUST also know the shared 1922 secret information to protect the encrypted transport of the newly 1923 generated key pair. Consequently, the EE can also authorize the 1924 KGA. 1926 * The PKI management entity MUST have a certificate containing the 1927 additional extended key usage extension id-kp-cmKGA for signing 1928 the SignedData structure containing the private key package. 1930 * For encrypting the SignedData structure a fresh content-encryption 1931 key to be used by the symmetric encryption algorithm MUST be 1932 generated with sufficient entropy. 1934 Note: The security strength of the protection of the generated 1935 private key should be similar or higher than the security strength 1936 of the generated private key. 1938 The detailed description of the privateKey field as follows: 1940 privateKey OPTIONAL 1941 -- MUST be an EnvelopedData structure as specified in CMS 1942 -- Section 6 [RFC5652] 1943 version REQUIRED 1944 -- MUST be 2 for recipientInfo type KeyAgreeRecipientInfo and 1945 -- KeyTransRecipientInfo 1946 -- MUST be 0 for recipientInfo type PasswordRecipientInfo 1947 recipientInfos REQUIRED 1948 -- MUST contain exactly one RecipientInfo, which MUST be 1949 -- kari of type KeyAgreeRecipientInfo (see section 4.1.6.1), 1950 -- ktri of type KeyTransRecipientInfo (see section 4.1.6.2), or 1951 -- pwri of type PasswordRecipientInfo (see section 4.1.6.3) 1952 encryptedContentInfo 1953 REQUIRED 1954 contentType REQUIRED 1955 -- MUST be id-signedData 1956 contentEncryptionAlgorithm 1957 REQUIRED 1958 -- MUST be the algorithm identifier of the algorithm used for 1959 -- content encryption 1960 -- The algorithm type MUST be a PROT_SYM_ALG as specified in 1961 -- RFC-CMP-Alg Section 5 1962 encryptedContent REQUIRED 1963 -- MUST be the SignedData structure as specified in CMS 1964 -- Section 5 [RFC5652] and [RFC8933] in encrypted form 1965 version REQUIRED 1966 -- MUST be 3 1967 digestAlgorithms 1968 REQUIRED 1969 -- MUST contain exactly one AlgorithmIdentifier element 1970 -- MUST be the algorithm identifier of the digest algorithm 1971 -- used for generating the signature and match the signature 1972 -- algorithm specified in signatureAlgorithm, see and [RFC8933] 1973 encapContentInfo 1974 REQUIRED 1975 -- MUST contain the content that is to be signed 1976 eContentType REQUIRED 1977 -- MUST be id-ct-KP-aKeyPackage as specified in [RFC5958] 1978 eContent REQUIRED 1979 -- MUST be of type AsymmetricKeyPackage and 1980 -- MUST contain exactly one OneAsymmetricKey element 1981 version REQUIRED 1982 -- MUST be 1 (indicating v2) 1983 privateKeyAlgorithm 1984 REQUIRED 1985 -- The privateKeyAlgorithm field MUST contain the algorithm 1986 -- identifier of the asymmetric key pair algorithm 1987 privateKey 1988 REQUIRED 1989 publicKey 1990 REQUIRED 1991 -- MUST contain the public key corresponding to the private key 1992 -- for simplicity and consistency with v2 of OneAsymmetricKey 1993 certificates REQUIRED 1994 -- MUST contain the certificate for the private key used to sign 1995 -- the signedData content, together with its chain 1996 -- The first certificate in this field MUST be the KGA 1997 -- certificate used for protecting this content 1998 -- Self-signed certificates SHOULD NOT be included and MUST NOT 1999 -- be trusted based on their inclusion in any case 2000 signerInfos REQUIRED 2001 -- MUST contain exactly one SignerInfo element 2002 version REQUIRED 2003 -- MUST be 3 2004 sid REQUIRED 2005 subjectKeyIdentifier 2006 REQUIRED 2007 -- MUST be the subjectKeyIdentifier of the KGA certificate 2008 digestAlgorithm 2009 REQUIRED 2010 -- MUST be the same as in digestAlgorithms 2011 signedAttrs REQUIRED 2012 -- MUST contain an id-contentType attribute containing the value 2013 -- id-ct-KP-aKeyPackage 2014 -- MUST contain an id-messageDigest attribute containing the 2015 -- message digest of eContent 2016 -- MAY contain an id-signingTime attribute containing the time 2017 -- of signature 2018 -- For details on the signed attributes see CMS Section 5.3 and 2019 -- Section 11 [RFC5652] and [RFC8933] 2020 signatureAlgorithm 2021 REQUIRED 2022 -- MUST be the algorithm identifier of the signature algorithm 2023 -- used for calculation of the signature bits 2024 -- The signature algorithm type MUST be a MSG_SIG_ALG as 2025 -- specified in RFC-CMP-Alg Section 3 and MUST be consistent 2026 -- with the subjectPublicKeyInfo field of the KGA certificate 2027 signature REQUIRED 2028 -- MUST be the digital signature of the encapContentInfo 2030 NOTE: As stated in Section 1.5, all fields of the ASN.1 syntax that 2031 are defined in RFC 5652 [RFC5652] but are not explicitly specified 2032 here SHOULD NOT be used. 2034 4.1.6.1. Using key agreement key management technique 2036 This variant can be applied in combination with the PKI management 2037 operations specified in Section 4.1.1 to Section 4.1.3 using 2038 signature-based protection of CMP messages. The EE certificate used 2039 for the signature-based protection of the request message MUST allow 2040 for the key usage "keyAgreement" and therefore, the related key pair 2041 MUST be used for establishment of the content-encryption key. For 2042 this key management technique the KeyAgreeRecipientInfo structure 2043 MUST be used in the contentInfo field. 2045 The KeyAgreeRecipientInfo structure included into the EnvelopedData 2046 structure is specified in CMS Section 6.2.2 [RFC5652]. 2048 The detailed description of the KeyAgreeRecipientInfo structure looks 2049 like this: 2051 kari REQUIRED 2052 -- MUST be a KeyAgreeRecipientInfo as specified in CMS Section 2053 -- 6.2.2 [RFC5652] 2054 version REQUIRED 2055 -- MUST be 3 2056 originator REQUIRED 2057 -- MUST contain the subjectKeyIdentifier of the certificate, 2058 -- and thereby identifies the sender's public key. 2059 -- MUST contain the same value as the senderKID in the 2060 -- message header 2061 ukm RECOMMENDED 2062 -- MUST be used when 1-pass ECMQV is used 2063 -- SHOULD be present to ensure uniqueness of the key 2064 -- encryption key 2065 keyEncryptionAlgorithm 2066 REQUIRED 2067 -- MUST be the algorithm identifier of the key agreement 2068 -- algorithm 2069 -- The algorithm type MUST be a KM_KA_ALG as specified in 2070 -- RFC-CMP-Alg Section 4.1 2071 -- The parameters field of the key agreement algorithm MUST 2072 -- contains the key wrap algorithm 2073 -- The algorithm type MUST be a KM_KW_ALG as specified in 2074 -- RFC-CMP-Alg Section 4.3 2075 recipientEncryptedKeys 2076 REQUIRED 2077 -- MUST contain exactly one RecipientEncryptedKey element 2078 rid REQUIRED 2079 -- MUST contain the rKeyId choice 2080 rKeyId REQUIRED 2081 subjectKeyIdentifier 2082 REQUIRED 2083 -- MUST contain the same value as the senderKID in the 2084 -- respective request message header 2085 encryptedKey 2086 REQUIRED 2087 -- MUST be the encrypted content-encryption key 2089 4.1.6.2. Using key transport key management technique 2091 This variant can be applied in combination with the PKI management 2092 operations specified in Section 4.1.1 to Section 4.1.3 using 2093 signature-based protection of CMP messages. The EE certificate used 2094 for the signature-based protection of the request message MUST allow 2095 for the key usage "keyEncipherment" and not for "keyAgreement". 2096 Therefore, the related key pair MUST be used for encipherment of the 2097 content-encryption key. For this key management technique, the 2098 KeyTransRecipientInfo structure MUST be used in the contentInfo 2099 field. 2101 The KeyTransRecipientInfo structure included into the EnvelopedData 2102 structure is specified in CMS Section 6.2.1 [RFC5652]. 2104 The detailed description of the KeyTransRecipientInfo structure looks 2105 like this: 2107 ktri REQUIRED 2108 -- MUST be a KeyTransRecipientInfo as specified in CMS 2109 -- Section 6.2.1 [RFC5652] 2110 version REQUIRED 2111 -- MUST be 2 2112 rid REQUIRED 2113 -- MUST contain the subjectKeyIdentifier choice 2114 subjectKeyIdentifier 2115 REQUIRED 2116 -- MUST contain the same value as the senderKID in the 2117 -- respective request message header 2118 keyEncryptionAlgorithm 2119 REQUIRED 2120 -- MUST be the algorithm identifier of the key transport 2121 -- algorithm 2122 -- The algorithm type MUST be a KM_KT_ALG as specified in 2123 -- RFC-CMP-Alg Section 4.2 2124 encryptedKey REQUIRED 2125 -- MUST be the encrypted content-encryption key 2127 4.1.6.3. Using password-based key management technique 2129 This variant can be applied in combination with the PKI management 2130 operation specified in Section 4.1.5 using MAC-based protection of 2131 CMP messages. The shared secret information used for the MAC-based 2132 protection MUST also be used for the encryption of the content- 2133 encryption key but with a different salt value applied in the key 2134 derivation algorithm. For this key management technique, the 2135 PasswordRecipientInfo structure MUST be used in the contentInfo 2136 field. 2138 Note: The entropy of the shared secret information is crucial for the 2139 level of protection when using a password-based key management 2140 technique. For centrally generated key pairs, the entropy of the 2141 shared secret information SHALL NOT be less than the security 2142 strength of the centrally generated key pair. Further guidance is 2143 available in Section 9. 2145 The PasswordRecipientInfo structure included into the EnvelopedData 2146 structure is specified in CMS Section 6.2.4 [RFC5652]. 2148 The detailed description of the PasswordRecipientInfo structure looks 2149 like this: 2151 pwri REQUIRED 2152 -- MUST be a PasswordRecipientInfo as specified in CMS 2153 -- Section 6.2.4 [RFC5652] 2154 version REQUIRED 2155 -- MUST be 0 2156 keyDerivationAlgorithm 2157 REQUIRED 2158 -- MUST be the algorithm identifier of the key derivation 2159 -- algorithm 2160 -- The algorithm type MUST be a KM_KD_ALG as specified in 2161 -- RFC-CMP-Alg Section 4.4 2162 keyEncryptionAlgorithm 2163 REQUIRED 2164 -- MUST be the algorithm identifier of the key wrap algorithm 2165 -- The algorithm type MUST be a KM_KW_ALG as specified in 2166 -- RFC-CMP-Alg Section 4.3 2167 encryptedKey REQUIRED 2168 -- MUST be the encrypted content-encryption key 2170 4.2. Revoking a certificate 2172 This PKI management operation should be used by an entity to request 2173 revocation of a certificate. Here the revocation request is used by 2174 an EE to revoke one of its own certificates. 2176 The revocation request message MUST be signed using the certificate 2177 that is to be revoked to prove the authorization to revoke. The 2178 revocation request message is signature-protected using this 2179 certificate. This requires, that the EE still possesses the private 2180 key. If this is not the case the revocation has to be initiated by 2181 other means, e.g., revocation by the RA as specified in 2182 Section 5.3.2. 2184 An EE requests the revocation of an own certificate at the CA that 2185 issued this certificate. The PKI management entity handles the 2186 request as described in Section 5.1.4 and responds with a message 2187 that contains the status of the revocation from the CA. 2189 Specific prerequisites augmenting the prerequisites in Section 3.4: 2191 * The certificate the EE wishes to revoke is not yet expired or 2192 revoked. 2194 Message flow: 2196 Step# EE PKI management entity 2197 1 format rr 2198 2 -> rr -> 2199 3 handle or forward rr 2200 4 format or receive rp 2201 5 <- rp <- 2202 6 handle rp 2204 For this PKI management operation, the EE MUST include exactly one 2205 RevDetails structure in the rr message body. In case no generic 2206 error occurred the response to the rr MUST be an rp message 2207 containing a single status field. 2209 Detailed message description: 2211 Revocation Request -- rr 2213 Field Value 2215 header 2216 -- As described in Section 3.1 2218 body 2219 -- The request of the EE to revoke its certificate 2220 rr REQUIRED 2221 -- MUST contain exactly one element of type RevDetails 2222 -- If more revocations are desired, further PKI management 2223 -- operations MUST be initiated 2224 certDetails REQUIRED 2225 -- MUST be present and is of type CertTemplate 2226 serialNumber REQUIRED 2227 -- MUST contain the certificate serialNumber attribute of the 2228 -- certificate to be revoked 2229 issuer REQUIRED 2230 -- MUST contain the issuer attribute of the certificate to be 2231 -- revoked 2232 crlEntryDetails REQUIRED 2233 -- MUST contain exactly one reasonCode of type CRLReason (see 2234 -- [RFC5280] section 5.3.1) 2235 -- If the reason for this revocation is not known or shall not 2236 -- be published the reasonCode MUST be 0 = unspecified 2238 protection REQUIRED 2239 -- As described in Section 3.2 and using the private key related 2240 -- to the certificate to be revoked 2242 extraCerts REQUIRED 2243 -- As described in Section 3.3 2245 Revocation Response -- rp 2247 Field Value 2249 header 2250 -- As described in Section 3.1 2252 body 2253 -- The responds of the PKI management entity to the request as 2254 -- appropriate 2255 rp REQUIRED 2256 status REQUIRED 2257 -- MUST contain exactly one element of type PKIStatusInfo 2258 status REQUIRED 2259 -- positive value allowed: "accepted" 2260 -- negative value allowed: "rejection" 2261 statusString OPTIONAL 2262 -- MAY be any human-readable text for debugging, logging or to 2263 -- display in a GUI 2264 failInfo OPTIONAL 2265 -- MAY be present if status is "rejection" 2266 -- MUST be absent if the status is "accepted" 2268 protection REQUIRED 2269 -- As described in section 3.2 2271 extraCerts REQUIRED 2272 -- As described in section 3.3 2274 4.3. Support messages 2276 The following support messages offer on demand in-band delivery of 2277 content relevant to the EE provided by a PKI management entity. CMP 2278 general messages and general response are used for this purpose. 2279 Depending on the environment, these requests may be answered by an RA 2280 or CA (see also Section 5.1.5). 2282 The general messages and general response messages contain 2283 InfoTypeAndValue structures. In addition to those infoType values 2284 defined in RFC 4210 [RFC4210] and CMP Updates 2285 [I-D.ietf-lamps-cmp-updates] further OIDs MAY be used to define new 2286 PKI management operations or new general-purpose support messages as 2287 needed in specific environments. 2289 The following contents are specified in this document: 2291 * Get CA certificates 2292 * Get root CA certificate update 2294 * Get certificate request template 2296 * Get new CRLs 2298 In the following the aspects common to all general messages (genm) 2299 and general response (genp) messages are described. 2301 Message flow: 2303 Step# EE PKI management entity 2304 1 format genm 2305 2 -> genm -> 2306 3 handle or forward genm 2307 4 format or receive genp 2308 5 <- genp <- 2309 6 handle genp 2311 Detailed message description: 2313 General Message -- genm 2315 Field Value 2317 header 2318 -- As described in Section 3.1 2320 body 2321 -- A request by the EE for information 2322 genm REQUIRED 2323 -- MUST contain exactly one element of type InfoTypeAndValue 2324 infoType REQUIRED 2325 -- MUST be the OID identifying one of the specific PKI 2326 -- management operations described below 2327 infoValue OPTIONAL 2328 -- MUST be as specified for the specific PKI management operation 2330 protection REQUIRED 2331 -- As described in Section 3.2 2333 extraCerts REQUIRED 2334 -- As described in Section 3.3 2336 General Response -- genp 2338 Field Value 2340 header 2341 -- As described in Section 3.1 2343 body 2344 -- The response of the PKI management entity providing 2345 -- information 2346 genp REQUIRED 2347 -- MUST contain exactly one element of type InfoTypeAndValue 2348 infoType REQUIRED 2349 -- MUST be the OID identifying the specific PKI management 2350 -- operation described below 2351 infoValue OPTIONAL 2352 -- MUST be as specified for the specific PKI management operation 2354 protection REQUIRED 2355 -- As described in Section 3.2 2357 extraCerts REQUIRED 2358 -- As described in Section 3.3 2360 4.3.1. Get CA certificates 2362 This PKI management operation can be used by an EE to request CA 2363 certificates from the PKI management entity. 2365 An EE requests CA certificates, e.g., for chain construction, from an 2366 PKI management entity by sending a general message with OID id-it- 2367 caCerts as specified in CMP Updates Section 2.13 2368 [I-D.ietf-lamps-cmp-updates]. The PKI management entity responds 2369 with a general response with the same OID that either contains a 2370 SEQUENCE of certificates populated with the available intermediate 2371 and issuing CA certificates or with no content in case no CA 2372 certificate is available. 2374 No specific prerequisites apply in addition to those specified in 2375 Section 3.4. 2377 The message sequence for this PKI management operation is as given 2378 above, with the following specific content: 2380 1 the infoType OID to use is id-it-caCerts 2382 2 the infoValue of the request MUST be absent 2384 3 if present, the infoValue of the response MUST contain a sequence 2385 of certificates 2387 The infoValue field of the general response containing the id-it- 2388 caCerts OID looks like this: 2390 infoValue OPTIONAL 2391 -- MUST be absent if no CA certificate is available 2392 -- MUST be present if CA certificates are available 2393 -- MUST be a sequence of CMPCertificate 2395 4.3.2. Get root CA certificate update 2397 This PKI management operation can be used by an EE to request an 2398 updated root CA Certificate as described in Section 4.4 of RFC 4210 2399 [RFC4210]. 2401 An EE requests an update of a root CA certificate from the PKI 2402 management entity by sending a general message with OID id-it- 2403 rootCaCert, which SHOULD include the old root CA certificate in the 2404 message body, as specified in CMP Updates Section 2.14 2405 [I-D.ietf-lamps-cmp-updates]. The PKI management entity responds 2406 with a general response with OID id-it-rootCaKeyUpdate that either 2407 contains the update of the root CA certificate consisting of up to 2408 three certificates, or with no content in case no update is 2409 available. 2411 Note: This mechanism may also be used to update trusted non-root 2412 certificates, i.e., trusted intermediate CA or issuing CA 2413 certificates. 2415 The newWithNew certificate is the new root CA certificate and is 2416 REQUIRED to be present if available. The newWithOld certificate is 2417 REQUIRED to be present in the response message because it is needed 2418 for the receiving entity trusting the old root CA certificate to gain 2419 trust in the new root CA certificate. The oldWithNew certificate is 2420 OPTIONAL because it is only needed in rare scenarios where entities 2421 do not already trust the old root CA. 2423 No specific prerequisites apply in addition to those specified in 2424 Section 3.4. 2426 The message sequence for this PKI management operation is as given 2427 above, with the following specific content: 2429 1 the infoType OID to use is id-it-rootCaCert in the request and id- 2430 it-rootCaKeyUpdate in the response 2432 2 the infoValue of the request SHOULD contain the root CA 2433 certificate the update is requested for 2435 3 if present, the infoValue of the response MUST be a 2436 RootCaKeyUpdateContent structure 2438 The infoValue field of the general request containing the id-it- 2439 rootCaCert OID looks like this: 2441 infoValue RECOMMENDED 2442 -- MUST contain the root CA certificate to be updated, if 2443 -- available 2445 The infoValue field of the general response containing the id-it- 2446 rootCaKeyUpdate OID looks like this: 2448 infoValue OPTIONAL 2449 -- MUST be absent if no update of the root CA certificate is 2450 -- available 2451 -- MUST be present if an update of the root CA certificate 2452 -- is available and MUST be of type RootCaKeyUpdateContent 2453 newWithNew REQUIRED 2454 -- MUST be present if infoValue is present 2455 -- MUST contain the new root CA certificate 2456 newWithOld REQUIRED 2457 -- MUST be present if infoValue is present 2458 -- MUST contain a certificate containing the new public 2459 -- root CA key signed with the old private root CA key 2460 oldWithNew OPTIONAL 2461 -- MAY be present if infoValue is present 2462 -- MUST contain a certificate containing the old public 2463 -- root CA key signed with the new private root CA key 2465 4.3.3. Get certificate request template 2467 This PKI management operation can be used by an EE to request a 2468 template with parameters for future certificate requests. 2470 An EE requests certificate request parameters from the PKI management 2471 entity by sending a general message with OID id-it-certReqTemplate as 2472 specified in CMP Updates Section 2.15 [I-D.ietf-lamps-cmp-updates]. 2473 The EE MAY indicate the certificate profile to use in the id-it- 2474 certProfile extension of the generalInfo field in the PKIHeader of 2475 the general message as described in Section 3.1. The PKI management 2476 entity responds with a general response with the same OID that either 2477 contains requirements on the certificate request template, or with no 2478 content in case no specific requirements are imposed by the PKI. The 2479 CertReqTemplateValue contains requirements on certificate fields and 2480 extensions in a certTemplate. Optionally it contains a keySpec field 2481 containing requirements on algorithms acceptable for key pair 2482 generation. 2484 The EE SHOULD follow the requirements from the received CertTemplate, 2485 by including in the certificate requests all the fields requested, 2486 taking over all the field values provided and filling in any 2487 remaining fields values. The EE SHOULD NOT add further fields, name 2488 components, and extensions or their (sub-)components. 2490 Note: We deliberately do not use "MUST" or "MUST NOT" here in order 2491 to allow more flexibility in case the rules given here are not 2492 sufficient for specific scenarios. The EE can populate the 2493 certificate request as wanted and ignore any of the requirements 2494 contained in the CertReqTemplateValue. On the other hand, a PKI 2495 management entity is free to ignore or replace any parts of the 2496 content of the certificate request provided by the EE. The 2497 CertReqTemplate PKI management operation offers means to ease a joint 2498 understanding which fields and/or which field values should be used. 2499 An example is provided in Appendix A. 2501 In case a field of type Name, e.g., subject, is present in the 2502 CertTemplate but has the value NULL-DN (i.e., has an empty list of 2503 RDN components), the field SHOULD be included in the certificate 2504 request and filled with content provided by the EE. Similarly, in 2505 case an X.509v3 extension is present but its extnValue is empty, this 2506 means that the extension SHOULD be included and filled with content 2507 provided by the EE. In case a Name component, for instance a common 2508 name or serial number, is given but has an empty string value, the EE 2509 SHOULD fill in a value. Similarly, in case an extension has sub- 2510 components (e.g., an IP address in a SubjectAltName field) with empty 2511 value, the EE SHOULD fill in a value. 2513 The EE MUST ignore (i.e., not include and fill in) empty fields, 2514 extensions, and sub-components that it does not understand or does 2515 not know suitable values to be filled in. 2517 The publicKey field of type SubjectPublicKeyInfo in the CertTemplate 2518 of the CertReqTemplateValue MUST be omitted. In case the PKI 2519 management entity wishes to make stipulation on algorithms the EE may 2520 use for key generation, this MUST be specified using the keySpec 2521 field as specified in CMP Updates Section 2.15 2522 [I-D.ietf-lamps-cmp-updates]. 2524 The keySpec field, if present, specifies the public key types 2525 optionally with parameters, and/or RSA key lengths for which a 2526 certificate may be requested. 2528 The value of a keySpec element with the OID id-regCtrl-algId, as 2529 specified in CMP Updates Section 2.15 [I-D.ietf-lamps-cmp-updates], 2530 MUST be of type AlgorithmIdentifier and give an algorithm other than 2531 RSA. For EC keys the curve information MUST be specified as 2532 described in the respective standard documents. 2534 The value of a keySpec element with the OID id-regCtrl-rsaKeyLen, as 2535 specified in CMP Updates Section 2.15 [I-D.ietf-lamps-cmp-updates], 2536 MUST be a positive integer value and give an RSA key length. 2538 In the CertTemplate of the CertReqTemplateValue the serialNumber, 2539 signingAlg, issuerUID, and subjectUID fields MUST be omitted. 2541 Specific prerequisites augmenting the prerequisites in Section 3.4: 2543 * When using the generalInfo field certProfile, the EE MUST know the 2544 identifier needed to indicate the requested certificate profile. 2546 The message sequence for this PKI management operation is as given 2547 above, with the following specific content: 2549 1 the infoType OID to use is id-it-certReqTemplate 2551 2 the id-it-certProfile generalInfo field in the header of the 2552 request MAY contain the name of the requested certificate request 2553 template 2555 3 the infoValue of the request MUST be absent 2557 4 if present, the infoValue of the response MUST be a 2558 CertReqTemplateValue containing a CertTemplate structure and an 2559 optional keySpec field 2561 The infoValue field of the general response containing the id-it- 2562 certReqTemplate OID looks like this: 2564 InfoValue OPTIONAL 2565 -- MUST be absent if no requirements are available 2566 -- MUST be present if the PKI management entity has any 2567 -- requirements on the contents of the certificate template 2568 certTemplate REQUIRED 2569 -- MUST be present if infoValue is present 2570 -- MUST contain the required CertTemplate structure elements 2571 -- The SubjectPublicKeyInfo field MUST be absent 2572 keySpec OPTIONAL 2573 -- MUST be absent if no requirements on the public key are 2574 -- available 2575 -- MUST be present if the PKI management entity has any 2576 -- requirements on the keys generated 2577 -- MUST contain one AttributeTypeAndValue per supported 2578 -- algorithm with attribute id-regCtrl-algId or 2579 -- id-regCtrl-rsaKeyLen 2581 4.3.4. CRL update retrieval 2583 This PKI management operation can be used by an EE to request a new 2584 CRL. If a CA offers methods to access a CRL, it may include CRL 2585 distribution points or authority information access extensions as 2586 specified in RFC 5280 [RFC5280] into the issued certificates. In 2587 addition, CMP offers CRL provisioning functionality as part of the 2588 PKI management operation. 2590 An EE requests a CRL update from the PKI management entity by sending 2591 a general message with OID id-it-crlStatusList. The EE MUST include 2592 the CRL source identifying the requested CRL and, if available, the 2593 thisUpdate time of the most current CRL instance it already has, as 2594 specified in CMP Updates Section 2.16 [I-D.ietf-lamps-cmp-updates]. 2595 The PKI management entity MUST respond with a general response with 2596 OID id-it-crls. If no thisUpdate value was given by the EE, the PKI 2597 management entity MUST return the latest CRL available. If a 2598 thisUpdate value was given, the PKI management entity MUST return the 2599 latest available CRL in case this CRL is more recent, otherwise the 2600 infoValue in the response message MUST be absent. 2602 The EE MUST identify the requested CRL either by its CRL distribution 2603 point name or issuer name. The CRL distribution point name can 2604 either be provided form the CRL distribution points extension of the 2605 certificate to be validated or from the issuing distribution point 2606 extension from the CRL to be updated. If no CRL distribution name is 2607 available to identify the CRL, the EE can use the issuer name either 2608 from the certificate to be validated or from the CRL to be updated. 2610 The PKI management entity SHOULD treat a CRL distribution point name 2611 as an internal pointer to identify a CRL for which is available at 2612 the PKI management entity directly. It is not intended as a way to 2613 fetch an arbitrary CRL from an external location. 2615 In addition to the prerequisites specified in Section 3.4, the EE 2616 MUST know which CRL to request. 2618 Note: If the EE does not want to request a specific CRL it MAY use 2619 instead a general message with OID id-it-currentCrl as specified in 2620 RFC 4210 Section 5.3.19.6 [RFC4210]. 2622 The message sequence for this PKI management operation is as given 2623 above, with the following specific content: 2625 1 the infoType OID to use is id-it-crlStatusList in the request and 2626 id-it-crls in the response 2628 2 the infoValue of the request MUST be present and contain a 2629 CRLStatus structure 2631 3 if present, the infoValue of the response MUST contain a CRL 2633 The infoValue field of the general request containing the id-it- 2634 crlStatusList OID looks like this: 2636 CRLSource REQUIRED 2637 -- MUST contain exactly one CRLSource structure 2638 -- MUST contain the dpn choice of type DistributionPointName if 2639 -- the CRL distribution point name is available 2640 -- Otherwise, MUST contain the issuer choice identifying the CA 2641 -- that issues the CRL. It MUST contain the issuer DN in the 2642 -- directoryName field of a GeneralName element. 2643 thisUpdate OPTIONAL 2644 -- SHOULD contain the thisUpdate field of the latest CRL form 2645 -- the issuer specified in the given dpn or issuer field, 2646 -- in case such a CRL is already known by the EE 2648 The infoValue field of the general response containing the id-it-crls 2649 OID looks like this: 2651 infoValue OPTIONAL 2652 -- MUST be absent if no CRL to be returned is available 2653 -- MUST contain one CRL update from the referenced source, if a 2654 -- thisUpdate value was not given or a more recent CRL is 2655 -- available 2657 4.4. Handling delayed delivery 2659 This is a variant of all PKI management operations described in this 2660 document. It is initiated in case a PKI management entity cannot 2661 respond to a request message in a timely manner, typically due to 2662 offline or asynchronous upstream communication, or due to delays in 2663 handling the request. The polling mechanism has been specified in 2664 RFC 4210 Section 5.3.22 [RFC4210] and updated by 2665 [I-D.ietf-lamps-cmp-updates]. 2667 Depending on the PKI architecture, the entity initiating delayed 2668 delivery is not necessarily the PKI management entity directly 2669 addressed by the EE. 2671 When initiating delayed delivery of a message received from an EE, 2672 the PKI management entity MUST respond with an ip/cp/kup/error 2673 message including the status "waiting". On receiving this response, 2674 the EE MUST store in its transaction context the senderNonce of the 2675 preceding request message because this value will be needed for 2676 checking the recipNonce of the final response to be received after 2677 polling. It sends a poll request with certReqId 0 if referring to 2678 the CertResponse element contained in the ip/cp/kup message, else -1 2679 to refer to the whole message. In case the final response is not yet 2680 available, the PKI management entity that initiated the delayed 2681 delivery MUST answer with a poll response, with the same certReqId. 2682 The included checkAfter time value indicates the minimum number of 2683 seconds that SHOULD elapse before the EE sends a new pollReq message 2684 to the PKI management entity. This is repeated until a final 2685 response is available or any party involved gives up on the current 2686 PKI management operation, i.e., a timeout occurs. 2688 When the PKI management entity that initiated delayed delivery can 2689 provide the final response for the original request message of the 2690 EE, it MUST send this response to the EE. Using this response, the 2691 EE can continue the current PKI management operation as usual. 2693 No specific prerequisites apply in addition to those of the 2694 respective PKI management operation. 2696 Message flow: 2698 Step# EE PKI management entity 2699 1 format request 2700 message 2701 2 -> request -> 2702 3 handle or forward 2703 request 2704 4 format ip/cp/kup/error 2705 with status "waiting" 2706 response in case no 2707 immediate final response 2708 is available, 2709 5 <- ip/cp/kup/error <- 2710 6 handle 2711 ip/cp/kup/error 2712 with status 2713 "waiting" 2715 -------------------------- start polling -------------------------- 2717 7 format pollReq 2718 8 -> pollReq -> 2719 9 handle or forward pollReq 2720 10 in case the final response 2721 for the original request 2722 is available, continue 2723 with step 14 2724 otherwise, format or 2725 receive pollRep with 2726 checkAfter value 2727 11 <- pollRep <- 2728 12 handle pollRep 2729 13 let checkAfter 2730 time elapse and 2731 continue with 2732 step 7 2734 ----------------- end polling, continue as usual ------------------ 2736 14 format or receive 2737 final response on 2738 original request 2739 15 <- response <- 2740 16 handle final 2741 response 2743 Detailed description of the ip/cp/kup/error response, pollReq, and 2744 pollRep: 2746 Response with status "waiting" -- ip/cp/kup/error 2748 Field Value 2750 header 2751 -- As described in Section 3.1 2753 body 2754 -- as described for the respective PKI management operation, with 2755 -- the following adaptations: 2756 status REQUIRED -- in case of ip/cp/kup 2757 pKIStatusInfo REQUIRED -- in case of error response 2758 -- PKIStatusInfo structure MUST be present 2759 status REQUIRED 2760 -- MUST be status "waiting" 2761 statusString OPTIONAL 2762 -- MAY be any human-readable text for debugging, logging or to 2763 -- display in a GUI 2764 failInfo PROHIBITED 2766 protection REQUIRED 2767 -- As described in Section 3.2 2769 extraCerts OPTIONAL 2770 -- As described in Section 3.3 2772 Polling Request -- pollReq 2774 Field Value 2776 header 2777 -- As described in Section 3.1 2779 body 2780 -- The message of the EE asking for the final response or for a 2781 -- time to check again 2782 pollReq REQUIRED 2783 certReqId REQUIRED 2784 -- MUST be 0 if referring to a CertResponse element, else -1 2786 protection REQUIRED 2787 -- As described in Section 3.2 2788 -- MUST use the same credentials as in the first request message 2789 -- of the PKI management operation 2791 extraCerts RECOMMENDED 2792 -- As described in Section 3.3 2793 -- MAY be omitted if the message size is critical and 2794 -- the PKI management entity caches the extraCerts from the 2795 -- first request message of the PKI management operation 2797 Polling Response -- pollRep 2799 Field Value 2801 header 2802 -- As described in Section 3.1 2804 body 2805 -- The message indicates the delay after which the EE SHOULD 2806 -- send another pollReq message for this transaction 2807 pollRep REQUIRED 2808 certReqId REQUIRED 2809 -- MUST be 0 if referring to a CertResponse element, else -1 2810 checkAfter REQUIRED 2811 -- time in seconds to elapse before a new pollReq SHOULD be sent 2812 reason OPTIONAL 2813 -- MAY be any human-readable text for debugging, logging or to 2814 -- display in a GUI 2816 protection REQUIRED 2817 -- As described in Section 3.2 2818 -- MUST use the same credentials as in the first response 2819 -- message of the PKI management operation 2821 extraCerts RECOMMENDED 2822 -- As described in Section 3.3 2823 -- MAY be omitted if the message size is critical and the EE has 2824 -- cached the extraCerts from the first response message of 2825 -- the PKI management operation 2827 Final response - any type of response message 2829 Field Value 2831 header 2833 -- MUST be the header as described for the response message 2834 -- of the respective PKI management operation 2836 body 2837 -- The response of the PKI management entity to the initial 2838 -- request as described in the respective PKI management 2839 -- operation 2841 protection REQUIRED 2842 -- MUST be as described for the response message of the 2843 -- respective PKI management operation 2845 extraCerts REQUIRED 2846 -- MUST be as described for the response message of the 2847 -- respective PKI management operation 2849 5. PKI management entity operations 2851 This section focuses on request processing by a PKI management 2852 entity. Depending on the network and PKI solution design, this can 2853 be an RA or CA, any of which may include protocol conversion or 2854 central key generation (i.e., acting as a KGA). 2856 A PKI management entity may directly respond to request messages from 2857 downstream and report errors. In case the PKI management entity is 2858 an RA it typically forwards the received request messages upstream 2859 after checking them and forwards respective response messages 2860 downstream. Besides responding to messages or forwarding them, a PKI 2861 management entity may request or revoke certificates on behalf of 2862 EEs. A PKI management entity may also need to manage its own 2863 certificates and thus act as an EE using the PKI management 2864 operations specified in Section 4. 2866 5.1. Responding to requests 2868 The PKI management entity terminating the PKI management operation at 2869 CMP level MUST respond to all received requests by returning a 2870 related CMP response message or an error. Any intermediate PKI 2871 management entity MAY respond depending on the PKI configuration and 2872 policy. 2874 In addition to the checks described in Section 3.5, the responding 2875 PKI management entity SHOULD check that a request that initiates a 2876 new PKI management operation does not use a transactionID that is 2877 currently in use. The failInfo bit value to use on reporting failure 2878 as described in Section 3.6.4 is transactionIdInUse. If any of these 2879 verification steps or any of the essential checks described in the 2880 following subsections fails, the PKI management entity MUST proceed 2881 as described in Section 3.6. 2883 The responding PKI management entity SHOULD copy the sender field of 2884 the request to the recipient field of the response, MUST copy the 2885 senderNonce of the request to the recipNonce of the response, and 2886 MUST use the same transactionID for the response. 2888 5.1.1. Responding to a certificate request 2890 An ir/cr/p10cr/kur message is used to request a certificate as 2891 described in Section 4.1. The responding PKI management entity MUST 2892 proceed as follows unless it initiates delayed delivery as described 2893 in Section 5.1.2. 2895 The PKI management entity SHOULD check the message body according to 2896 the applicable requirements from Section 4.1. Possible failInfo bit 2897 values used for error reporting in case a check failed include 2898 badCertId and badCertTemplate. It MUST verify the presence and value 2899 of the proof-of-possession (failInfo bit: badPOP), unless central key 2900 generation is requested. In case the special POP value "raVerified" 2901 is given, it SHOULD check that the request message was signed using a 2902 certificate containing the cmcRA extended key usage (failInfo bit: 2903 notAuthorized). The PKI management entity SHOULD perform also any 2904 further checks on the certTemplate contents (failInfo: 2905 badCertTemplate) according to any applicable PKI policy and 2906 certificate profile. 2908 If the requested certificate is available, the PKI management entity 2909 MUST respond with a positive ip/cp/kup message as described in 2910 Section 4.1. 2912 Note: If central key generation is performed by the responding PKI 2913 management entity, the responding PKI management entity MUST include 2914 in the response the privateKey field as specified in Section 4.1.6. 2915 It may have issued the certificate for the newly generated key pair 2916 itself if it is a CA, or have requested the certificate on behalf of 2917 the EE as described in Section 5.3.1, or have received it by other 2918 means from a CA. 2920 The prerequisites of the respective PKI management operation as 2921 specified in Section 4.1 apply. 2923 Note: If the EE requested omission of the certConf message, the PKI 2924 management entity SHOULD handle it as described in Section 4.1.1 and 2925 therefore MAY grant this by including the implicitConfirm extension 2926 in the response header. 2928 5.1.2. Initiating delayed delivery 2930 This functional extension can be used by a PKI management entity in 2931 case the response to a request takes longer than usual. In this case 2932 the PKI management entity MUST completely validate the request as 2933 usual and then start preparing the response or forward the request 2934 further upstream as soon as possible. In the meantime, it MUST 2935 respond with an ip/cp/kup/error message including the status 2936 "waiting" and handle subsequent polling as described in Section 4.4. 2938 Note: Typically, as stated in Section 5.2.3, an intermediate PKI 2939 management entity should not change the sender and recipient nonces 2940 even in case it modifies a request or a response message. In the 2941 special case of delayed delivery initiated by an intermediate PKI 2942 management entity, there is an exception. Between the EE and this 2943 PKI management entity, pollReq and pollRep messages are exchanged 2944 handling the nonces as usual. Yet when the final response from 2945 upstream has arrived at the PKI management entity, this response 2946 contains the recipNonce copied (as usual) from the senderNonce in the 2947 original request message. The PKI management entity that initiated 2948 the delayed delivery may replace the recipNonce in the response 2949 message with the senderNonce of the last received pollReq because the 2950 downstream entities, including the EE, might expect it in this way. 2951 Yet the check specified in Section 3.5 allows to alternatively use 2952 the senderNonce of the original request. 2954 No specific prerequisites apply in addition to those of the 2955 respective PKI management operation. 2957 5.1.3. Responding to a confirmation message 2959 A PKI management entity MUST handle a certConf message if it has 2960 responded before with a positive ip/cp/kup message not granting 2961 implicit confirmation. It SHOULD check the message body according to 2962 the requirements given in Section 4.1.1 (failInfo bit: badCertId) and 2963 react as described there. 2965 The prerequisites of the respective PKI management operation as 2966 specified in Section 4.1 apply. 2968 5.1.4. Responding to a revocation request 2970 An rr message is used to request revocation of a certificate. The 2971 responding PKI management entity SHOULD check the message body 2972 according to the requirements in Section 4.2. It MUST make sure that 2973 the referenced certificate exists (failInfo bit: badCertId), has been 2974 issued by the addressed CA, and is not already expired or revoked 2975 (failInfo bit: certRevoked). On success it MUST respond with a 2976 positive rp message as described in Section 4.2. 2978 No specific prerequisites apply in addition to those specified in 2979 Section 3.4. 2981 5.1.5. Responding to a support message 2983 A genm message is used to retrieve extra content. The responding PKI 2984 management entity SHOULD check the message body according to the 2985 applicable requirements in Section 4.3 and perform any further checks 2986 depending on the PKI policy. On success it MUST respond with a genp 2987 message as described there. 2989 Note: The responding PKI management entity may generate the response 2990 from scratch or reuse the contents of previous responses. Therefore, 2991 it may be worth caching the body of the response message as long as 2992 the contained information is still valid, such that further requests 2993 for the same contents can be answered immediately. 2995 No specific prerequisites apply in addition to those specified in 2996 Section 3.4. 2998 5.2. Forwarding messages 3000 In case the PKI solution consists of intermediate PKI management 3001 entities (i.e., LRA or RA), each CMP request message coming from an 3002 EE or any other downstream PKI management entity SHOULD be forwarded 3003 to the next (upstream) PKI management entity as described in this 3004 section and otherwise MUST be answered as described in Section 5.1. 3005 Any received response message or error message MUST be forwarded to 3006 the next (downstream) PKI entity. 3008 In addition to the checks described in Section 3.5, the forwarding 3009 PKI management entity MAY verify the proof-of-possession for 3010 ir/cr/p10cr/kur messages. If one of these verification procedures 3011 fails, the RA proceeds as described in Section 3.6. 3013 A PKI management entity SHOULD NOT change the received message unless 3014 necessary. The PKI management entity SHOULD only update the message 3015 protection and the certificate template in a certificate request 3016 message if this is technically necessary. Concrete PKI system 3017 specifications may define in more detail when to do so. 3019 This is particularly relevant in the upstream communication of a 3020 request message. 3022 Each forwarding PKI management entity has one or more 3023 functionalities. It may 3025 * verify the identities of EEs and make authorization decisions for 3026 certification request processing based on local PKI policy, 3028 * add or modify fields of certificate request messages, 3029 * store data from a message in a database for later usage or audit 3030 purposes, 3032 * provide traversal of a network boundary, 3034 * replace a MAC-based protection by a signature-based protection 3035 that can be verified also further upstream, 3037 * double-check if the messages transferred back and forth are 3038 properly protected and well-formed, 3040 * provide an authentic indication that it has performed all required 3041 checks, 3043 * initiate a delayed delivery due to delays transferring messages or 3044 handling requests, or 3046 * collect messages from multiple RAs and forward them jointly. 3048 The decision if a message should be forwarded 3050 * unchanged with the original protection, 3052 * unchanged with a new protection, or 3054 * changed with a new protection 3056 depends on the PKI solution design and the associated security policy 3057 (CP/CPS [RFC3647]). 3059 A PKI management entity MUST replace or add a protection of a message 3060 if it 3062 * needs to securely indicate that it has done checks or validations 3063 on the message to one of the next (upstream) PKI management entity 3064 or 3066 * needs to protect the message using a key and certificate from a 3067 different PKI. 3069 A PKI management entity MUST replace a protection of a message if it 3071 * performs changes to the header or the body of the message or 3073 * needs to convert from or to a MAC-based protection. 3075 This is particularly relevant in the upstream communication of 3076 certificate request messages. 3078 Note that the message protection covers only the header and the body 3079 and not the extraCerts. The PKI management entity MAY change the 3080 extraCerts in any of the following message adaptations, e.g., to 3081 sort, add, or delete certificates to support subsequent PKI entities. 3082 This may be particularly helpful to augment upstream messages with 3083 additional certificates or to reduce the number of certificates in 3084 downstream messages when forwarding to constrained devices. 3086 5.2.1. Not changing protection 3088 This variant means that a PKI management entity forwards a CMP 3089 message without changing the header, body, or protection. In this 3090 case the PKI management entity acts more like a proxy, e.g., on a 3091 network boundary, implementing no specific RA-like security 3092 functionality that requires an authentic indication to the PKI. 3093 Still the PKI management entity might implement checks that result in 3094 refusing to forward the request message and instead responding as 3095 specified in Section 3.6. 3097 This variant of forwarding a message or the one described in 3098 Section 5.2.2.1 SHOULD be used for kur messages and for central key 3099 generation. 3101 No specific prerequisites apply in addition to those specified in 3102 Section 3.4. 3104 5.2.2. Adding protection and batching of messages 3106 This variant of forwarding a message means that a PKI management 3107 entity adds another protection to PKI management messages before 3108 forwarding them. 3110 The nested message is a PKI management message containing a 3111 PKIMessages sequence as its body containing one or more CMP messages. 3113 As specified in the updated Section 5.1.3.4 of RFC 4210 [RFC4210] 3114 (see also CMP Updates Section 2.6 [I-D.ietf-lamps-cmp-updates]) there 3115 are various use cases for adding another protection by a PKI 3116 management entity. Specific procedures are described in more detail 3117 in the following sections. 3119 Detailed message description: 3121 Nested Message - nested 3123 Field Value 3125 header 3126 -- As described in Section 3.1 3128 body 3129 -- Container to provide additional protection to original 3130 -- messages and to bundle request messages or alternatively 3131 -- response messages 3132 PKIMessages REQUIRED 3133 -- MUST be a sequence of one or more CMP messages 3135 protection REQUIRED 3136 -- As described in Section 3.2 using the CMP protection key of 3137 -- the PKI management entity 3139 extraCerts REQUIRED 3140 -- As described in Section 3.3 3142 5.2.2.1. Adding protection to a request message 3144 A PKI management entity may authentically indicate successful 3145 validation and approval of a request message by adding an extra 3146 signature to the original message. 3148 By adding a protection using its own CMP protecting key the PKI 3149 management entity provides a proof of verifying and approving the 3150 message as described above. Thus, the PKI management entity acts as 3151 an actual Registration Authority (RA), which implements important 3152 security functionality of the PKI. Applying an additional protection 3153 is specifically relevant when forwarding a message that requests a 3154 certificate update or central key generation. This is because the 3155 original protection of the EE must be preserved while adding an 3156 indication of approval by the PKI management entity. 3158 The PKI management entity wrapping the original request message in a 3159 nested message structure MUST take over the recipient, recipNonce, 3160 and transactionID of the original message to the nested message and 3161 apply signature-based protection. The additional signature serves as 3162 proof of verification and authorization by this PKI management 3163 entity. 3165 The PKI management entity receiving such a nested message that 3166 contains a single request message MUST validate the additional 3167 protection signature on the nested message and check the 3168 authorization for the approval it implies. 3170 The PKI management entity responding to the request contained in the 3171 nested message sends the response message as described in 3172 Section 5.1, without wrapping it in a nested message. 3174 Note: This form of nesting messages is characterized by the fact that 3175 the transactionID in the header of the nested message is the same as 3176 the one used in the included message. 3178 Specific prerequisites augmenting the prerequisites in Section 3.4: 3180 * The PKI management entity MUST be able to validate the respective 3181 request and have the authorization to perform approval of the 3182 request according to the PKI policies. 3184 Message flow: 3186 Step# PKI management entity PKI management entity 3187 1 format nested 3188 2 -> nested -> 3189 3 handle or forward nested 3190 4 format or receive response 3191 5 <- response <- 3192 6 forward response 3194 5.2.2.2. Batching messages 3196 A PKI management entity MAY bundle any number of PKI management 3197 messages for batch processing or to transfer a bulk of PKI management 3198 messages using the nested message structure. In this use case, 3199 nested messages are used both on the upstream interface towards the 3200 next PKI management entity and on the downstream interface from the 3201 PKI management entity towards the EE. 3203 This PKI management operation is typically used on the interface 3204 between an LRA and an RA to bundle several messages for offline 3205 delivery. In this case the LRA needs to initiate delayed delivery as 3206 described in Section 5.1.2. If the RA needs different routing 3207 information per nested PKI management message a suitable mechanism 3208 may need to be implemented. Since this mechanism strongly depends on 3209 the requirements of the target architecture, it is out of scope of 3210 this document. 3212 A nested message containing requests is generated locally at the PKI 3213 management entity. For the upstream nested message, the PKI 3214 management entity acts as a protocol end point and therefore a fresh 3215 transactionID and a fresh senderNonce MUST be used in the header of 3216 the nested message. An upstream nested message may contain request 3217 messages, e.g., ir, cr, p10cr, kur, pollReq, certConf, rr, or genm. 3219 While building the upstream nested message the PKI management entity 3220 SHOULD store the sender, transactionID, and senderNonce fields of all 3221 bundled messages together with the transactionID of the upstream 3222 nested message. 3224 Such an upstream nested message is sent to the next PKI management 3225 entity. The upstream PKI management entity that unbundles it MUST 3226 handle each of the included request messages as usual. It MUST 3227 answer with a downstream nested message. This downstream nested 3228 message MUST use the transactionID of the upstream nested message and 3229 return the senderNonce of the upstream nested message as the 3230 recipNonce of the downstream nested message. The downstream nested 3231 message SHOULD bundle the individual response messages (e.g., ip, cp, 3232 kup, pollRep, pkiConf, rp, genp, error) for all original request 3233 messages of the upstream nested message. While unbundling the 3234 downstream nested message, the former PKI management entity can 3235 determine lost and unexpected responses based on the previously 3236 stored transactionIDs. When it forwards the unbundled responses, any 3237 extra messages SHOULD be dropped, and any missing response message 3238 (failInfo bit: systemUnavail) MUST be answered with an error message 3239 to inform the respective requester about the failed certificate 3240 management operation. 3242 Note: This form of nesting messages is characterized by the fact that 3243 the transactionID in the header of the nested message is different to 3244 those used in the included messages. 3246 The protection of the nested messages SHOULD NOT be regarded as an 3247 indication of verification or approval of the bundled PKI request 3248 messages. 3250 No specific prerequisites apply in addition to those specified in 3251 Section 3.4. 3253 Message flow: 3255 Step# PKI management entity PKI management entity 3256 1 format nested 3257 2 -> nested -> 3258 3 handle or forward nested 3259 4 format or receive nested 3260 5 <- nested <- 3261 6 handle nested 3263 5.2.3. Replacing protection 3265 The following two alternatives can be used by any PKI management 3266 entity forwarding a CMP message with or without changes while 3267 providing its own protection and in this way asserting approval of 3268 the message. 3270 By replacing the existing protection using its own CMP protecting key 3271 the PKI management entity provides a proof of verifying and approving 3272 the message as described above. Thus, the PKI management entity acts 3273 as an actual Registration Authority (RA), which implements important 3274 security functionality of the PKI. 3276 Before replacing the existing protection by a new protection, the PKI 3277 management entity MUST verify the protection provided and approve its 3278 content, including any modifications that it may perform. It MUST 3279 also check that the sender, as authenticated by the message 3280 protection, is authorized for the given operation. 3282 These message adaptations MUST NOT be applied to kur messages 3283 described in Section 4.1.3 since their original protection using the 3284 key and certificate to be updated needs to be preserved, unless the 3285 regCtrl OldCertId is used to strongly identify the certificate to be 3286 updated. 3288 These message adaptations MUST NOT be applied to certificate request 3289 messages described in for central key generation Section 4.1.6 since 3290 their original protection needs to be preserved up to the Key 3291 Generation Authority, which needs to use it for encrypting the new 3292 private key for the EE. 3294 In both the kur and central key generation cases, if a PKI management 3295 entity needs to state its approval of the original request message it 3296 MUST provide this using a nested message as specified in 3297 Section 5.2.2.1. 3299 When an intermediate PKI management entity modifies a message, it 3300 SHOULD NOT change the transactionID nor the sender and recipient 3301 nonces. 3303 5.2.3.1. Not changing any included proof-of-possession 3305 This variant of forwarding a message means that a PKI management 3306 entity forwards a CMP message with or without modifying the message 3307 header or body while preserving any included proof-of-possession. 3309 In case the PKI management entity breaks an existing proof-of- 3310 possession, the message adaptation described in Section 5.2.3.2 needs 3311 to be applied instead. 3313 Specific prerequisites augmenting the prerequisites in Section 3.4: 3315 * The PKI management entity MUST be able to validate the respective 3316 request and have the authorization to perform approval of the 3317 request according to the PKI policies. 3319 5.2.3.2. Breaking proof-of-possession 3321 This variant of forwarding a message needs to be used if a PKI 3322 management entity breaks a signature-based proof-of-possession in a 3323 certificate request message, for instance because it forwards an ir 3324 or cr message with modifications of the certTemplate, i.e., 3325 modification, addition, or removal of fields. 3327 The PKI management entity MUST verify the proof-of-possession 3328 contained in the original message using the included public key. If 3329 successful, the PKI management entity MUST change the popo field 3330 value to raVerified. 3332 Specific prerequisites augmenting the prerequisites in Section 3.4: 3334 * The PKI management entity MUST be authorized to replace the proof- 3335 of-possession (after verifying it) with raVerified. 3337 * The PKI management entity MUST be able to validate the respective 3338 request and have the authorization to perform approval of the 3339 request according to the PKI policies. 3341 The new popo field MUST contain the raVerified choice in the certReq 3342 structure of the modified message as follows: 3344 popo 3345 raVerified REQUIRED 3346 -- MUST have the value NULL and indicates that the PKI 3347 -- management entity verified the popo of the original message 3349 5.3. Acting on behalf of other PKI entities 3351 A PKI management entity may need to request a PKI management 3352 operation on behalf of another PKI entity. In this case the PKI 3353 management entity initiates the respective PKI management operation 3354 as described in Section 4 acting in the role of the EE. 3356 5.3.1. Requesting certificates 3358 A PKI management entity may use on of the PKI management operations 3359 described in Section 4.1 to request a certificate on behalf of 3360 another PKI entity. It either generates the key pair itself and 3361 inserts the new public key in the subjectPublicKey field of the 3362 request certTemplate, or it uses a certificate request received from 3363 downstream, e.g., by means of a different protocol. In the latter 3364 case it SHOULD verify the received proof-of-possession. 3366 No specific prerequisites apply in addition to those specified in 3367 Section 4.1. 3369 Note: An upstream PKI management entity will not be able to 3370 differentiate this PKI management operation from the one described in 3371 Section 5.2.3 because in both cases the message is protected by the 3372 PKI management entity. 3374 The message sequence for this PKI management operation is identical 3375 to the respective PKI management operation given in Section 4.1, with 3376 the following changes: 3378 1 The request messages MUST be signed using the CMP protection key 3379 of the PKI management entity taking the role of the EE in this 3380 operation. 3382 2 If inclusion of a proper proof-of-possession is not possible the 3383 PKI management entity MUST verify the POP provided from downstream 3384 and use "raVerified" in its upstream request. 3386 5.3.2. Revoking a certificate 3388 A PKI management entity may use the PKI management operation 3389 described in Section 4.2 to revoke a certificate of another PKI 3390 entity. This revocation request message MUST be signed by the PKI 3391 management entity using its own CMP protection key to prove to the 3392 PKI authorization to revoke the certificate on behalf of that PKI 3393 entity. 3395 No specific prerequisites apply in addition to those specified in 3396 Section 4.2. 3398 Note: An upstream PKI management entity will not be able to 3399 differentiate this PKI management operation from the ones described 3400 in Section 5.2.3. 3402 The message sequence for this PKI management operation is identical 3403 to that given in Section 4.2, with the following changes: 3405 1 The rr message MUST be signed using the CMP protection key of the 3406 PKI management entity taking the role of the EE in this operation. 3408 6. CMP message transfer mechanisms 3410 CMP messages are designed to be self-contained, such that in 3411 principle any reliable transfer mechanism can be used. HTTP SHOULD 3412 and CoAP MAY be used for online transfer. CMP messages MAY also be 3413 piggybacked on any other reliable transfer protocol. File-based 3414 transfer MAY be used in case offline transfer is required. 3416 Independently of the means of transfer, it can happen that messages 3417 are lost or that a communication partner does not respond. To 3418 prevent waiting indefinitely, each CMP client component SHOULD use a 3419 configurable per-request timeout, and each CMP server component 3420 SHOULD use a configurable per-response timeout in case a further 3421 Request message is to be expected from the client side within the 3422 same transaction. In this way a hanging transaction can be closed 3423 cleanly with an error as described in Section 3.6 (failInfo bit: 3424 systemUnavail) and related resources (for instance, any cached 3425 extraCerts) can be freed. 3427 Moreover, there are various situations where the delivery of messages 3428 gets delayed. For instance, a serving PKI management entity might 3429 take longer than expected to form a response due to administrative 3430 processes, resource constraints, or upstream message delivery delays. 3431 The transport layer itself may cause delays, for instance due to 3432 offline transport, network segmentation, or intermittent network 3433 connectivity. Part of these issues can be detected and handled at 3434 CMP level using pollReq and pollRep messages as described in 3435 Section 4.4, while others are better handled at transfer level. 3436 Depending on the transfer protocol and system architecture, solutions 3437 for handling delays at transfer level may be present and can be used 3438 for CMP connections, for instance connection re-establishment and 3439 message retransmission. 3441 Note: Long timeout periods are helpful to minimize the need for 3442 polling and maximize chances to handle transfer issues at lower 3443 levels. 3445 Note: When using TCP and similar reliable connection-oriented 3446 transport protocols, which is typical in conjunction with HTTP, there 3447 is the option to keep the connection alive over multiple request- 3448 response message pairs. This may improve efficiency, though is not 3449 required from a security point of view. 3451 When conveying CMP messages in HTTP, CoAP, or MIME-based transfer 3452 protocols, the internet media type "application/pkixcmp" MUST be set 3453 for transfer encoding as specified in Section 5.3 of RFC 2510 3454 [RFC2510], Section 2.4 of CMP over CoAP 3455 [I-D.ietf-ace-cmpv2-coap-transport], and Section 3.4 of CMP over HTTP 3456 [RFC6712]. 3458 6.1. HTTP transfer 3460 This transfer mechanism can be used by a PKI entity to transfer CMP 3461 messages over HTTP. If HTTP transfer is used the specifications as 3462 described in [RFC6712] and updated by CMP Updates 3463 [I-D.ietf-lamps-cmp-updates] MUST be followed. 3465 PKI management operations SHOULD use URI paths consisting of '/.well- 3466 known/cmp/' followed by an operation label depending on the type of 3467 PKI management operation. 3469 +============================+=====================+=========+ 3470 | PKI management operation | operation label | Details | 3471 +============================+=====================+=========+ 3472 | Enroll client to new PKI | /initialization | Section | 3473 | | | 4.1.1 | 3474 +----------------------------+---------------------+---------+ 3475 | Enroll client to existing | /certification | Section | 3476 | PKI | | 4.1.2 | 3477 +----------------------------+---------------------+---------+ 3478 | Update client certificate | /keyupdate | Section | 3479 | | | 4.1.3 | 3480 +----------------------------+---------------------+---------+ 3481 | Enroll client using | /p10 | Section | 3482 | PKCS#10 | | 4.1.4 | 3483 +----------------------------+---------------------+---------+ 3484 | Revoke client certificate | /revocation | Section | 3485 | | | 4.2 | 3486 +----------------------------+---------------------+---------+ 3487 | Get CA certificates | /getcacerts | Section | 3488 | | | 4.3.1 | 3489 +----------------------------+---------------------+---------+ 3490 | Get root CA certificate | /getrootupdate | Section | 3491 | update | | 4.3.2 | 3492 +----------------------------+---------------------+---------+ 3493 | Get certificate request | /getcertreqtemplate | Section | 3494 | template | | 4.3.1 | 3495 +----------------------------+---------------------+---------+ 3496 | Get CRL updates | /getcrls | Section | 3497 | | | 4.3.4 | 3498 +----------------------------+---------------------+---------+ 3499 | Batching messages | /nested | Section | 3500 | | | 5.2.2.2 | 3501 | Note: This path element is | | | 3502 | applicable only between | | | 3503 | PKI management entities. | | | 3504 +----------------------------+---------------------+---------+ 3506 Table 1: HTTP endpoints 3508 Independently of any variants used (see Section 4.1.5, Section 4.1.6, 3509 and Section 4.4) the operation label corresponding to the PKI 3510 management operation SHALL be used. 3512 Any certConf or pollReq messages are sent to the same endpoint as 3513 determined by the PKI management operation. 3515 When a single request message is nested as described in 3516 Section 5.2.2.1, the label to use is the same as for the underlying 3517 PKI management operation. 3519 By sending a request to its preferred endpoint, the PKI entity will 3520 recognize via the HTTP response status code whether a configured URI 3521 is supported by the PKI management entity. 3523 In case a PKI management entity receives an unexpected HTTP status 3524 code from upstream, it MUST respond downstream with an error message 3525 as described in Section 3.6 using a failInfo bit corresponding to the 3526 status code, e.g., systemFailure. 3528 For certificate management the major security goal is integrity and 3529 data origin authentication. For delivery of centrally generated 3530 keys, also confidentiality is a must. These goals are sufficiently 3531 achieved by CMP itself, also in an end-to-end fashion. If a second 3532 line of defense is required or general privacy concerns exist, TLS 3533 can be used to provide confidentiality on a hop-by-hop basis. 3535 TLS SHOULD be used with certificate-based authentication to further 3536 protect the HTTP transfer as described in [RFC2818]. The CMP 3537 transfer via HTTPS MUST use TLS server authentication and SHOULD use 3538 TLS client authentication. 3540 Note: The requirements for checking certificates given in [RFC5280] 3541 and either [RFC5246] or [RFC8446] MUST be followed for the TLS layer. 3542 Certificate status checking SHOULD be used for the TLS certificates 3543 of all communication partners. 3545 TLS with mutual authentication based on shared secret information MAY 3546 be used in case no suitable certificates for certificate-based 3547 authentication are available, e.g., a PKI management operation with 3548 MAC-based protection is used. 3550 Note: The entropy of the shared secret information is crucial for the 3551 level of protection available using shard secret information-based 3552 TLS authentication. A pre-shared key (PSK) mechanism is acceptable 3553 using shared secret information with an entropy of at least 128 bits. 3554 Otherwise, a password-authenticated key exchange (PAKE) protocol is 3555 RECOMMENDED. 3557 6.2. CoAP transfer 3559 This transfer mechanism can be used by a PKI entity to transfer CMP 3560 messages over CoAP [RFC7252], e.g., in constrained environments. If 3561 CoAP transfer is used the specifications as described in CMP over 3562 CoAP [I-D.ietf-ace-cmpv2-coap-transport] MUST be followed. 3564 PKI management operations SHOULD use URI paths consisting of '/.well- 3565 known/cmp/' followed by an operation label depending on the type of 3566 PKI management operation. 3568 +=======================================+===========+=========+ 3569 | PKI management operation | operation | Details | 3570 | | label | | 3571 +=======================================+===========+=========+ 3572 | Enroll client to new PKI | /ir | Section | 3573 | | | 4.1.1 | 3574 +---------------------------------------+-----------+---------+ 3575 | Enroll client to existing PKI | /cr | Section | 3576 | | | 4.1.2 | 3577 +---------------------------------------+-----------+---------+ 3578 | Update client certificate | /kur | Section | 3579 | | | 4.1.3 | 3580 +---------------------------------------+-----------+---------+ 3581 | Enroll client using PKCS#10 | /p10 | Section | 3582 | | | 4.1.4 | 3583 +---------------------------------------+-----------+---------+ 3584 | Revoke client certificate | /rr | Section | 3585 | | | 4.2 | 3586 +---------------------------------------+-----------+---------+ 3587 | Get CA certificates | /crts | Section | 3588 | | | 4.3.1 | 3589 +---------------------------------------+-----------+---------+ 3590 | Get root CA certificate update | /rcu | Section | 3591 | | | 4.3.2 | 3592 +---------------------------------------+-----------+---------+ 3593 | Get certificate request template | /att | Section | 3594 | | | 4.3.3 | 3595 +---------------------------------------+-----------+---------+ 3596 | Get CRL updates | /crls | Section | 3597 | | | 4.3.4 | 3598 +---------------------------------------+-----------+---------+ 3599 | Batching messages | /nest | Section | 3600 | | | 5.2.2.2 | 3601 | Note: This path element is applicable | | | 3602 | only between PKI management entities. | | | 3603 +---------------------------------------+-----------+---------+ 3605 Table 2: CoAP endpoints 3607 Independently of any variants used (see Section 4.1.5, Section 4.1.6, 3608 and Section 4.4) the operation label corresponding to the PKI 3609 management operation SHALL be used. 3611 Any certConf or pollReq messages are sent to the same endpoint as 3612 determined by the PKI management operation. 3614 When a single request message is nested as described in 3615 Section 5.2.2.1, the label to use is the same as for the underlying 3616 PKI management operation. 3618 By sending a request to its preferred endpoint, the PKI entity will 3619 recognize via the CoAP response status code whether a configured URI 3620 is supported by the PKI management entity. The CoAP-inherent 3621 discovery mechanisms MAY also be used. 3623 In case a PKI management entity receives an unexpected CoAP status 3624 code from upstream, it MUST respond downstream with an error message 3625 as described in Section 3.6 using a failInfo bit corresponding to the 3626 status code, e.g., systemFailure. 3628 Like for HTTP transfer , to offer a second line of defense or to 3629 provide hop-by-hop privacy protection, DTLS MAY be utilized as 3630 described in CMP over CoAP [I-D.ietf-ace-cmpv2-coap-transport]. 3632 6.3. Piggybacking on other reliable transfer 3634 CMP messages MAY also be transfer on some other reliable protocol. 3635 Connection, delay, and error handling mechanisms similar to those 3636 specified for HTTP in Section 6.1 need to be implemented. 3638 A more detailed specification is out of scope of this document and 3639 would need to be given for instance in the scope of the transfer 3640 protocol used. 3642 6.4. Offline transfer 3644 For transferring CMP messages between PKI entities, any mechanism can 3645 be used that is able to store and forward binary objects of 3646 sufficient length and with sufficient reliability while preserving 3647 the order of messages for each transaction. 3649 The transfer mechanism SHOULD be able to indicate message loss, 3650 excessive delay, and possibly other transmission errors. In such 3651 cases the PKI entities SHOULD report an error as specified in 3652 Section 3.6 as far as possible. 3654 6.4.1. File-based transfer 3656 CMP messages MAY be transferred between PKI entities using file-based 3657 mechanisms, for instance when an offline EE or a PKI management 3658 entity performs delayed delivery. Each file MUST contain the ASN.1 3659 DER encoding of one CMP message only, where the message may be 3660 nested. There MUST be no extraneous header or trailer information in 3661 the file. The file name extension ".pki" MUST be used. 3663 6.4.2. Other asynchronous transfer protocols 3665 Other asynchronous transfer protocols, e.g., email or website 3666 up-/download, MAY transfer CMP messages between PKI entities. A MIME 3667 wrapping is defined for those environments that are MIME-native. The 3668 MIME wrapping in this section is specified in RFC 8551 Section 3.1 3669 [RFC8551]. 3671 The ASN.1 DER encoding of the CMP messages MUST be transferred using 3672 the "application/pkixcmp" content type and base64-encoded content 3673 transfer encoding as specified in [RFC2510], section 5.3. A filename 3674 MUST be included either in a "content-type" or a "content- 3675 disposition" statement. The file name extension ".pki" MUST be used. 3677 7. Conformance requirements 3679 This section defines which level of support for the various features 3680 specified in this profile is required for which type of PKI entity. 3682 7.1. PKI management operations 3684 The following table provides an overview of the PKI management 3685 operations specified in Section 4 and Section 5 and states whether 3686 support by conforming EE, RA, and CA implementations is mandatory, 3687 recommended, optional, or not applicable. Variants amend or change 3688 behavior of base PKI management operations and are therefore also 3689 included. 3691 +==========+=============================+========+========+========+ 3692 | ID | PKI management operations | EE | RA | CA | 3693 | | and variants | | | | 3694 +==========+=============================+========+========+========+ 3695 | Generic | generic aspects of PKI | MUST | MUST | MUST | 3696 | | management operations, | | | | 3697 | | Section 3 | | | | 3698 +----------+-----------------------------+--------+--------+--------+ 3699 | IR | Requesting a certificate | MUST | MUST | MUST | 3700 | | from a new PKI with | | | | 3701 | | signature-based | | | | 3702 | | protection, Section 4.1.1 | | | | 3703 +----------+-----------------------------+--------+--------+--------+ 3704 | CR | Requesting an additional | MAY | MAY | MAY | 3705 | | certificate with | | | | 3706 | | signature-based | | | | 3707 | | protection, Section 4.1.2 | | | | 3708 +----------+-----------------------------+--------+--------+--------+ 3709 | KUR | Updating an existing | MUST | MUST | MUST | 3710 | | certificate with | | | | 3711 | | signature-based | | | | 3712 | | protection, Section 4.1.3 | | | | 3713 +----------+-----------------------------+--------+--------+--------+ 3714 | P10CR | Requesting a certificate | MAY | MAY | MAY | 3715 | | from a legacy PKI using a | | | | 3716 | | PKCS#10 request, | | | | 3717 | | Section 4.1.4 | | | | 3718 +----------+-----------------------------+--------+--------+--------+ 3719 | MAC | Requesting a certificate | SHOULD | SHOULD | SHOULD | 3720 | | from a PKI with MAC-based | | | | 3721 | | protection (IR, CR, KUR, | | | | 3722 | | and P10CR if supported), | | | | 3723 | | Section 4.1.5 | | | | 3724 +----------+-----------------------------+--------+--------+--------+ 3725 | CKeyGen | Adding central key | MAY | MAY | MAY | 3726 | | generation to a | | | | 3727 | | certificate request (IR, | | | | 3728 | | CR, KUR, and P10CR if | | | | 3729 | | supported). (If | | | | 3730 | | supported, key agreement | | | | 3731 | | key management technique | | | | 3732 | | is REQUIRED, and key | | | | 3733 | | transport and password- | | | | 3734 | | based key management | | | | 3735 | | techniques are | | | | 3736 | | OPTIONAL.), Section 4.1.6 | | | | 3737 +----------+-----------------------------+--------+--------+--------+ 3738 | RR | Revoking a certificate, | SHOULD | SHOULD | SHOULD | 3739 | | Section 4.2 | | | | 3740 +----------+-----------------------------+--------+--------+--------+ 3741 | CACerts | Get CA certificates, | MAY | MAY | MAY | 3742 | | Section 4.3.1 | | | | 3743 +----------+-----------------------------+--------+--------+--------+ 3744 | RootUpd | Get root CA certificate | MAY | MAY | MAY | 3745 | | update, Section 4.3.2 | | | | 3746 +----------+-----------------------------+--------+--------+--------+ 3747 | ReqTempl | Get certificate request | MAY | MAY | MAY | 3748 | | template, Section 4.3.3 | | | | 3749 +----------+-----------------------------+--------+--------+--------+ 3750 | CRLUpd | CRL update retrieval, | MAY | MAY | MAY | 3751 | | Section 4.3.4 | | | | 3752 +----------+-----------------------------+--------+--------+--------+ 3753 | Polling | Handling delayed | MAY | MAY | MAY | 3754 | | delivery, Section 4.4 | | | | 3755 +----------+-----------------------------+--------+--------+--------+ 3756 | CertResp | Responding to a | N/A | MAY | MUST | 3757 | | certificate request (IR, | | | | 3758 | | CR, KUR, and P10CR if | | | | 3759 | | supported), Section 5.1.1 | | | | 3760 +----------+-----------------------------+--------+--------+--------+ 3761 | InitPoll | Initiating delayed | N/A | MAY | MAY | 3762 | | delivery, Section 5.1.2 | | | | 3763 +----------+-----------------------------+--------+--------+--------+ 3764 | CertConf | Responding to a | MUST | MAY | MUST | 3765 | | confirmation message, | | | | 3766 | | Section 5.1.3 | | | | 3767 +----------+-----------------------------+--------+--------+--------+ 3768 | RevResp | Responding to a | N/A | MAY | SHOULD | 3769 | | revocation request, | | | | 3770 | | Section 5.1.4 | | | | 3771 +----------+-----------------------------+--------+--------+--------+ 3772 | GenResp | Responding to a support | N/A | MAY | MAY | 3773 | | message (CACerts, | | | | 3774 | | RootUpd, ReqTempl, CRLUpd | | | | 3775 | | if supported), | | | | 3776 | | Section 5.1.5 | | | | 3777 +----------+-----------------------------+--------+--------+--------+ 3778 | FwdKeep | Forwarding messages - not | N/A | MUST | N/A | 3779 | | changing protection, | | | | 3780 | | Section 5.2.1 | | | | 3781 +----------+-----------------------------+--------+--------+--------+ 3782 | FwdAddS | Adding protection to a | N/A | MUST | MUST | 3783 | | request message, | | | | 3784 | | Section 5.2.2.1 | | | | 3785 +----------+-----------------------------+--------+--------+--------+ 3786 | FwdAddB | Batching messages, | N/A | MAY | MAY | 3787 | | Section 5.2.2.2 | | | | 3788 +----------+-----------------------------+--------+--------+--------+ 3789 | FwdRepKP | Forwarding messages - | N/A | MAY | N/A | 3790 | | replacing protection, not | | | | 3791 | | changing any included | | | | 3792 | | proof-of-possession, | | | | 3793 | | Section 5.2.3.1 | | | | 3794 +----------+-----------------------------+--------+--------+--------+ 3795 | FwdRepBP | Forwarding messages - | N/A | MAY | MAY | 3796 | | replacing protection, | | | | 3797 | | breaking proof-of- | | | | 3798 | | possession, | | | | 3799 | | Section 5.2.3.2 | | | | 3800 +----------+-----------------------------+--------+--------+--------+ 3801 | CertOnB | Acting on behalf of other | N/A | MAY | N/A | 3802 | | PKI entities - requesting | | | | 3803 | | certificates, | | | | 3804 | | Section 5.3.1 | | | | 3805 +----------+-----------------------------+--------+--------+--------+ 3806 | RevROnB | Acting on behalf of other | N/A | SHOULD | SHOULD | 3807 | | PKI entities - revoking a | | | | 3808 | | certificate, | | | | 3809 | | Section 5.3.2 | | | | 3810 +----------+-----------------------------+--------+--------+--------+ 3812 Table 3: Level of support for PKI management operations and variants 3814 7.2. Message transfer 3816 CMP does not have specific needs regarding message transfer, except 3817 that for each request message sent, eventually exactly one response 3818 message should be received. Therefore, virtually any reliable 3819 transfer mechanism can be used, such as HTTP, CoAP, and file-based 3820 offline transfer. Thus, this document does not require any specific 3821 transfer protocol to be supported by conforming implementations. 3823 On different links between PKI entities, e.g., EE-RA and RA-CA, 3824 different transfer mechanisms as specified in Section 6 may be used. 3826 HTTP transfer is RECOMMENDED to use for all PKI entities for 3827 maximizing general interoperability at transfer level, yet full 3828 flexibility is retained to choose whatever transfer mechanism is 3829 suitable, for instance for devices and system architectures with 3830 specific constraints. 3832 The following table lists the name and level of support specified for 3833 each transfer mechanism. 3835 +=========+=======================+========+========+========+ 3836 | ID | Message transfer type | EE | RA | CA | 3837 +=========+=======================+========+========+========+ 3838 | HTTP | HTTP transfer, | SHOULD | SHOULD | SHOULD | 3839 | | Section 6.1 | | | | 3840 +---------+-----------------------+--------+--------+--------+ 3841 | CoAP | CoAP transfer, | MAY | MAY | MAY | 3842 | | Section 6.2 | | | | 3843 +---------+-----------------------+--------+--------+--------+ 3844 | Piggyb | Piggybacking on other | MAY | MAY | MAY | 3845 | | reliable transfer, | | | | 3846 | | Section 6.3 | | | | 3847 +---------+-----------------------+--------+--------+--------+ 3848 | Offline | Offline transfer, | MAY | MAY | MAY | 3849 | | Section 6.4 | | | | 3850 +---------+-----------------------+--------+--------+--------+ 3852 Table 4: Level of support for message transfer types 3854 8. IANA Considerations 3856 This document does not request changes to the IANA registry. 3858 9. Security Considerations 3860 The security considerations as laid out in CMP [RFC4210] updated by 3861 CMP Updates [I-D.ietf-lamps-cmp-updates] and CMP Algorithms 3862 [I-D.ietf-lamps-cmp-algorithms], CRMF [RFC4211] updated by Algorithm 3863 Requirements Update [RFC9045], CMP over HTTP [RFC6712], and CMP over 3864 CoAP [I-D.ietf-ace-cmpv2-coap-transport] apply. 3866 For TLS using shared secret information-based authentication, both 3867 PSK and PAKE provide the same amount of protection against a real- 3868 time authentication attack which is directly the amount of entropy in 3869 the shared secret. The difference between a pre-shared key (PSK) and 3870 a password-authenticated key exchange (PAKE) protocol is in the level 3871 of long-term confidentiality of the TLS messages against brute-force 3872 decryption, where a PSK-based cipher suite only provides security 3873 according to the entropy of the shared secret, while a PAKE-based 3874 cipher suite provides full security independent of the entropy of the 3875 shared secret. 3877 10. Acknowledgements 3879 We thank the various reviewers of this document. 3881 11. References 3882 11.1. Normative References 3884 [I-D.ietf-ace-cmpv2-coap-transport] 3885 Sahni, M. and S. Tripathi, "CoAP Transfer for the 3886 Certificate Management Protocol", Work in Progress, 3887 Internet-Draft, draft-ietf-ace-cmpv2-coap-transport-04, 8 3888 November 2021, . 3891 [I-D.ietf-lamps-cmp-algorithms] 3892 Brockhaus, H., Aschauer, H., Ounsworth, M., and J. Gray, 3893 "Certificate Management Protocol (CMP) Algorithms", Work 3894 in Progress, Internet-Draft, draft-ietf-lamps-cmp- 3895 algorithms-09, 22 December 2021, 3896 . 3899 [I-D.ietf-lamps-cmp-updates] 3900 Brockhaus, H., Oheimb, D. V., and J. Gray, "Certificate 3901 Management Protocol (CMP) Updates", Work in Progress, 3902 Internet-Draft, draft-ietf-lamps-cmp-updates-17, 12 3903 January 2022, . 3906 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 3907 Requirement Levels", BCP 14, RFC 2119, 3908 DOI 10.17487/RFC2119, March 1997, 3909 . 3911 [RFC2986] Nystrom, M. and B. Kaliski, "PKCS #10: Certification 3912 Request Syntax Specification Version 1.7", RFC 2986, 3913 DOI 10.17487/RFC2986, November 2000, 3914 . 3916 [RFC4210] Adams, C., Farrell, S., Kause, T., and T. Mononen, 3917 "Internet X.509 Public Key Infrastructure Certificate 3918 Management Protocol (CMP)", RFC 4210, 3919 DOI 10.17487/RFC4210, September 2005, 3920 . 3922 [RFC4211] Schaad, J., "Internet X.509 Public Key Infrastructure 3923 Certificate Request Message Format (CRMF)", RFC 4211, 3924 DOI 10.17487/RFC4211, September 2005, 3925 . 3927 [RFC5280] Cooper, D., Santesson, S., Farrell, S., Boeyen, S., 3928 Housley, R., and W. Polk, "Internet X.509 Public Key 3929 Infrastructure Certificate and Certificate Revocation List 3930 (CRL) Profile", RFC 5280, DOI 10.17487/RFC5280, May 2008, 3931 . 3933 [RFC5652] Housley, R., "Cryptographic Message Syntax (CMS)", STD 70, 3934 RFC 5652, DOI 10.17487/RFC5652, September 2009, 3935 . 3937 [RFC5958] Turner, S., "Asymmetric Key Packages", RFC 5958, 3938 DOI 10.17487/RFC5958, August 2010, 3939 . 3941 [RFC6712] Kause, T. and M. Peylo, "Internet X.509 Public Key 3942 Infrastructure -- HTTP Transfer for the Certificate 3943 Management Protocol (CMP)", RFC 6712, 3944 DOI 10.17487/RFC6712, September 2012, 3945 . 3947 [RFC8174] Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC 3948 2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174, 3949 May 2017, . 3951 [RFC8933] Housley, R., "Update to the Cryptographic Message Syntax 3952 (CMS) for Algorithm Identifier Protection", RFC 8933, 3953 DOI 10.17487/RFC8933, October 2020, 3954 . 3956 [RFC9045] Housley, R., "Algorithm Requirements Update to the 3957 Internet X.509 Public Key Infrastructure Certificate 3958 Request Message Format (CRMF)", RFC 9045, 3959 DOI 10.17487/RFC9045, June 2021, 3960 . 3962 11.2. Informative References 3964 [ETSI-3GPP.33.310] 3965 3GPP, "Network Domain Security (NDS); Authentication 3966 Framework (AF)", 3GPP TS 33.310 16.6.0, 16 December 2020. 3968 [I-D.ietf-anima-brski-async-enroll] 3969 Fries, S., Brockhaus, H., Oheimb, D. V., and E. Lear, 3970 "Support of Asynchronous Enrollment in BRSKI (BRSKI-AE)", 3971 Work in Progress, Internet-Draft, draft-ietf-anima-brski- 3972 async-enroll-04, 25 October 2021, 3973 . 3976 [I-D.ietf-anima-brski-prm] 3977 Fries, S., Werner, T., Lear, E., and M. Richardson, "BRSKI 3978 with Pledge in Responder Mode (BRSKI-PRM)", Work in 3979 Progress, Internet-Draft, draft-ietf-anima-brski-prm-00, 3980 25 October 2021, . 3983 [I-D.ietf-netconf-sztp-csr] 3984 Watsen, K., Housley, R., and S. Turner, "Conveying a 3985 Certificate Signing Request (CSR) in a Secure Zero Touch 3986 Provisioning (SZTP) Bootstrapping Request", Work in 3987 Progress, Internet-Draft, draft-ietf-netconf-sztp-csr-13, 3988 31 January 2022, . 3991 [IEC.62443-3-3] 3992 IEC, "Industrial communication networks - Network and 3993 system security - Part 3-3: System security requirements 3994 and security levels", IEC 62443-3-3, August 2013, 3995 . 3997 [IEEE.802.1AR_2018] 3998 IEEE, "IEEE Standard for Local and metropolitan area 3999 networks - Secure Device Identity", IEEE 802.1AR-2018, 4000 DOI 10.1109/IEEESTD.2018.8423794, 2 August 2018, 4001 . 4003 [NIST.CSWP.04162018] 4004 National Institute of Standards and Technology (NIST), 4005 "Framework for Improving Critical Infrastructure 4006 Cybersecurity, Version 1.1", NIST NIST.CSWP.04162018, 4007 DOI 10.6028/NIST.CSWP.04162018, April 2018, 4008 . 4011 [NIST.SP.800-57p1r5] 4012 Barker, E B., "Recommendation for key management, part 1 4013 :general", NIST NIST.SP.800-57pt1r5, 4014 DOI 10.6028/NIST.SP.800-57pt1r5, 2020, 4015 . 4017 [RFC2510] Adams, C. and S. Farrell, "Internet X.509 Public Key 4018 Infrastructure Certificate Management Protocols", 4019 RFC 2510, DOI 10.17487/RFC2510, March 1999, 4020 . 4022 [RFC2818] Rescorla, E., "HTTP Over TLS", RFC 2818, 4023 DOI 10.17487/RFC2818, May 2000, 4024 . 4026 [RFC3647] Chokhani, S., Ford, W., Sabett, R., Merrill, C., and S. 4027 Wu, "Internet X.509 Public Key Infrastructure Certificate 4028 Policy and Certification Practices Framework", RFC 3647, 4029 DOI 10.17487/RFC3647, November 2003, 4030 . 4032 [RFC5246] Dierks, T. and E. Rescorla, "The Transport Layer Security 4033 (TLS) Protocol Version 1.2", RFC 5246, 4034 DOI 10.17487/RFC5246, August 2008, 4035 . 4037 [RFC7030] Pritikin, M., Ed., Yee, P., Ed., and D. Harkins, Ed., 4038 "Enrollment over Secure Transport", RFC 7030, 4039 DOI 10.17487/RFC7030, October 2013, 4040 . 4042 [RFC7252] Shelby, Z., Hartke, K., and C. Bormann, "The Constrained 4043 Application Protocol (CoAP)", RFC 7252, 4044 DOI 10.17487/RFC7252, June 2014, 4045 . 4047 [RFC8366] Watsen, K., Richardson, M., Pritikin, M., and T. Eckert, 4048 "A Voucher Artifact for Bootstrapping Protocols", 4049 RFC 8366, DOI 10.17487/RFC8366, May 2018, 4050 . 4052 [RFC8446] Rescorla, E., "The Transport Layer Security (TLS) Protocol 4053 Version 1.3", RFC 8446, DOI 10.17487/RFC8446, August 2018, 4054 . 4056 [RFC8551] Schaad, J., Ramsdell, B., and S. Turner, "Secure/ 4057 Multipurpose Internet Mail Extensions (S/MIME) Version 4.0 4058 Message Specification", RFC 8551, DOI 10.17487/RFC8551, 4059 April 2019, . 4061 [RFC8572] Watsen, K., Farrer, I., and M. Abrahamsson, "Secure Zero 4062 Touch Provisioning (SZTP)", RFC 8572, 4063 DOI 10.17487/RFC8572, April 2019, 4064 . 4066 [RFC8995] Pritikin, M., Richardson, M., Eckert, T., Behringer, M., 4067 and K. Watsen, "Bootstrapping Remote Secure Key 4068 Infrastructure (BRSKI)", RFC 8995, DOI 10.17487/RFC8995, 4069 May 2021, . 4071 [UNISIG.Subset-137] 4072 UNISIG, "Subset-137; ERTMS/ETCS On-line Key Management 4073 FFFIS; V1.0.0", December 2015, 4074 . 4076 Appendix A. Example CertReqTemplate 4078 Suppose the server requires that the certTemplate contains 4080 * the issuer field with a value to be filled in by the EE, 4082 * the subject field with a common name to be filled in by the EE and 4083 two organizational unit fields with given values "myDept" and 4084 "myGroup", 4086 * the publicKey field contains an ECC key on curve secp256r1 or an 4087 RSA public key of length 2048, 4089 * the subjectAltName extension with DNS name "www.myServer.com" and 4090 an IP address to be filled in, 4092 * the keyUsage extension marked critical with the value 4093 digitalSignature and keyAgreement, and 4095 * the extKeyUsage extension with values to be filled in by the EE. 4097 Then the infoValue with certTemplate and keySpec fields returned to 4098 the EE will be encoded as follows: 4100 SEQUENCE { 4101 SEQUENCE { 4102 [3] { 4103 SEQUENCE {} 4104 } 4105 [5] { 4106 SEQUENCE { 4107 SET { 4108 SEQUENCE { 4109 OBJECT IDENTIFIER commonName (2 5 4 3) 4110 UTF8String "" 4111 } 4112 } 4113 SET { 4114 SEQUENCE { 4115 OBJECT IDENTIFIER organizationalUnitName (2 5 4 11) 4116 UTF8String "myDept" 4117 } 4119 } 4120 SET { 4121 SEQUENCE { 4122 OBJECT IDENTIFIER organizationalUnitName (2 5 4 11) 4123 UTF8String "myGroup" 4124 } 4125 } 4126 } 4127 } 4128 [9] { 4129 SEQUENCE { 4130 OBJECT IDENTIFIER subjectAltName (2 5 29 17) 4131 OCTET STRING, encapsulates { 4132 SEQUENCE { 4133 [2] "www.myServer.com" 4134 [7] "" 4135 } 4136 } 4137 } 4138 SEQUENCE { 4139 OBJECT IDENTIFIER keyUsage (2 5 29 15) 4140 BOOLEAN TRUE 4141 OCTET STRING, encapsulates { 4142 BIT STRING 3 unused bits 4143 "10001"B 4144 } 4145 } 4146 SEQUENCE { 4147 OBJECT IDENTIFIER extKeyUsage (2 5 29 37) 4148 OCTET STRING, encapsulates { 4149 SEQUENCE {} 4150 } 4151 } 4152 } 4153 } 4154 SEQUENCE { 4155 SEQUENCE { 4156 OBJECT IDENTIFIER algId (1 3 6 1 5 5 7 5 1 11) 4157 SEQUENCE { 4158 OBJECT IDENTIFIER ecPublicKey (1 2 840 10045 2 1) 4159 OBJECT IDENTIFIER secp256r1 (1 2 840 10045 3 1 7) 4160 } 4161 } 4162 SEQUENCE { 4163 OBJECT IDENTIFIER rsaKeyLen (1 3 6 1 5 5 7 5 1 12) 4164 INTEGER 2048 4165 } 4166 } 4168 } 4170 Appendix B. History of changes 4172 Note: This appendix will be deleted in the final version of the 4173 document. 4175 From version 09 -> 10: 4177 * Resolved some nits reported by I-D nit checker tool 4178 * Resolve some wording issues 4180 From version 08 -> 09: 4182 * Updated Section 1.1 and 1.2 and converted Section 2.2 and 2.3 into 4183 more detailed tables in Section 7 (see thread "WG Last Call for 4184 draft-ietf-lamps-cmp-updates-14 and draft-ietf-lamps-lightweight- 4185 cmp-profile-08") 4186 * Updated Section 3.1 and 4.1.1 making implicitConfirm recommended 4187 for ir/cr/p10cr/kur and providing further recommendations on its 4188 use (see thread "certConf - WG Last Call for draft-ietf-lamps-cmp- 4189 updates-14 and draft-ietf-lamps-lightweight-cmp-profile-08") 4190 * Updated Section 4.1.6 adding some clarifications regarding 4191 validating the authorization of centrally generated keys 4192 * Updated Section 4.3.4 adding some clarifications on CRL update 4193 retrieval (see thread "CRL update retrieval - WG Last Call for 4194 draft-ietf-lamps-cmp-updates-14 and draft-ietf-lamps-lightweight- 4195 cmp-profile-08") 4196 * Updated references to CMP Updates pointing to concrete sections 4197 (see thread "CRL update retrieval - WG Last Call for draft-ietf- 4198 lamps-cmp-updates-14 and draft-ietf-lamps-lightweight-cmp-profile- 4199 08")) 4200 * Corrected a couple of nits elsewhere 4202 From version 07 -> 08: 4204 * Updates Section 4.1.6.1. regarding content of the originator and 4205 keyEncryptionAlgorithm fields (see thread "AD review of draft- 4206 ietf-lamps-cmp-algorithms-07") 4207 * Rolled back part of the changes on root CA certificate updates in 4208 Section 4.3.2 (see thread "Allocation of OIDs for CRL update 4209 retrieval (draft-ietf-lamps-cmp-updates-13)") 4211 From version 06 -> 07: 4213 * Added references to [draft-ietf-netconf-sztp-csr] in new 4214 Section 1.5 and Section 4.1.4 4216 * Added reference to [I-D.ietf-anima-brski-async-enroll] in new 4217 Section 1.5 and Section 4.1.1 4218 * Changed reference in Section 2 to [I-D.ietf-anima-brski-prm] as 4219 the PUSH use case is continued to be discussed in this draft after 4220 the split of BRSKI-AE 4221 * Improved note regarding UNISIG Subset-137 in Section 1.6 4222 * Removed "rootCaCert" in Section 3.1 and updated the structure of 4223 the genm request for root CA certificate updates in Section 4.3.2. 4224 * Simplified handling of sender and recipient nonces in case of 4225 delayed delivery in Sections 3.1, 3.5, 4.4, and 5.1.2 4226 * Changed the order of Sections 4.1.4 and 4.1.5 4227 * Added reference on RFC 8933 regarding CMS signedAttrs to 4228 Section 4.1.6 4229 * Added Section 4.3.4 on CRL update retrieval 4230 * Generalized delayed enrollment to delayed delivery in Section 4.4 4231 and 5.1.2, updated the state machine in the introduction of 4232 Section 4 4233 * Updated Section 6 regarding delayed message transfer 4234 * Changed file name extension from ".PKI" to ".pki", deleted 4235 operational path for central key generation, and added an 4236 operational path for CRL update retrieval in Sections 6.1 and 6.2 4237 * Shifted many security considerations to CMP Updates 4238 * Replaced the term "transport" by "transfer" where appropriate to 4239 prevent confusion regarding TCP vs. HTTP and CoAP 4240 * Various editorial changes and language corrections 4242 From version 05 -> 06: 4244 * Changed in Section 2.3 the normative requirement in of adding 4245 protection to a single message to mandatory and replacing 4246 protection to optional 4247 * Added Section 3.4 specifying generic prerequisites to PKI 4248 management operations 4249 * Added Section 3.5 specifying generic message validation 4250 * Added Section 3.6 on generic error reporting. This section 4251 replaces the former error handling section from Section 4 and 5. 4252 * Added reference to using hashAlg 4253 * Updates Section 4.3.2 and Section 4.3.3 to align with CMP Updates 4254 * Added Section 5.1 specifying the behavior of PKI management 4255 entities when responding to requests 4256 * Reworked Section 5.2.3. on usage of nested messages 4257 * Updates Section 5.3 on performing PKI management operation on 4258 behalf of another entity 4259 * Updates Section 6.2 on HTTPS transport of CMP messages as 4260 discusses at IETF 110 and email thread "I-D Action: draft-ietf- 4261 lamps-lightweight-cmp-profile-05.txt" 4262 * Added CoAP endpoints to Section 6.4 4263 * Added security considerations on usage of shared secret 4264 information 4265 * Updated the example in Appendix A 4266 * Added newly registered OIDs to the example in Appendix A 4267 * Updated new RFC numbers for I-D.ietf-lamps-crmf-update-algs 4268 * Multiple language corrections, clarifications, and changes in 4269 wording 4271 From version 04 -> 05: 4273 * Changed to XML V3 4274 * Added algorithm names introduced in CMP Algorithms Section 7.3 to 4275 Section 4 of this document 4276 * Updates Syntax in Section 4.4.3 due to changes made in CMP Updates 4277 * Deleted the text on HTTP-based discovery as discussed in 4278 Section 6.1 4279 * Updates Appendix A due to change syntax in Section 4.4.3 4280 * Many clarifications and changes in wording thanks to David's 4281 extensive review 4283 From version 03 -> 04: 4285 * Deleted normative text sections on algorithms and refer to CMP 4286 Algorithms and CRMF Algorithm Requirements Update instead 4287 * Some clarifications and changes in wording 4289 From version 02 -> 03: 4291 * Updated the interoperability with [UNISIG.Subset-137] in 4292 Section 1.4. 4293 * Changed Section 2.3 to a tabular layout to enhanced readability 4294 * Added a ToDo to section 3.1 on aligning with the CMP Algorithms 4295 draft that will be set up as decided in IETF 108 4296 * Updated section 4.1.6 to add the AsymmetricKey Package structure 4297 to transport a newly generated private key as decided in IETF 108 4298 * Added a ToDo to section 4.1.7 on required review of the nonce 4299 handling in case an offline LRA responds and not forwards the 4300 pollReq messages 4301 * Updated Section 4 due to the definition of the new ITAV OIDs in 4302 CMP Updates 4303 * Updated Section 4.4.4 to utilize controls instead of rsaKeyLen 4304 (see thread "dtaft-ietf-lamps-cmp-updates and rsaKeyLen") 4305 * Deleted the section on definition and discovery of HTTP URIs and 4306 copied the text to the HTTP transport section and to CMP Updates 4307 section 3.2 4308 * Added some explanation to Section 5.1.2 and Section 5.1.3 on using 4309 nested messages when a protection by the RA is required. 4311 * Deleted the section on HTTP URI definition and discovery as some 4312 content was moved to CMP Updates. The rest of the content was 4313 moved back to the HTTP transport section 4314 * Deleted the ASN.1 module after moving the new OIDs id-it-caCerts, 4315 id-it-rootCaKeyUpdate, and id-it-certReqTemplate to CMP Updates 4316 * Minor changes in wording and addition of some open ToDos 4318 From version 01 -> 02: 4320 * Extend Section 1.6 with regard to conflicts with UNISIG Subset- 4321 137. 4322 * Minor clarifications on extraCerts in Section 3.3 and 4323 Section 4.1.1. 4324 * Complete specification of requesting a certificate from a trusted 4325 PKI with signature protection in Section 4.1.2. 4326 * Changed from symmetric key-encryption to password-based key 4327 management technique in Section 4.1.6.3 as discussed on the 4328 mailing list (see thread "draft-ietf-lamps-lightweight-cmp- 4329 profile-01, section 5.1.6.1") 4330 * Changed delayed enrollment described in Section 4.4 from 4331 recommended to optional as decided at IETF 107 4332 * Introduced the new RootCAKeyUpdate structure for root CA 4333 certificate update in Section 4.3.2 as decided at IETF 107 (also 4334 see email thread "draft-ietf-lamps-lightweight-cmp-profile-01, 4335 section 5.4.3") 4336 * Extend the description of the CertReqTemplate PKI management 4337 operation, including an example added in the Appendix. Keep 4338 rsaKeyLen as a single integer value in Section 4.3.3 as discussed 4339 on the mailing list (see thread "draft-ietf-lamps-lightweight-cmp- 4340 profile-01, section 5.4.4") 4341 * Deleted Sections "Get certificate management configuration" and 4342 "Get enrollment voucher" as decided at IETF 107 4343 * Complete specification of adding an additional protection by an 4344 PKI management entity in Section 5.2.2. 4345 * Added a section on HTTP URI definition and discovery and extended 4346 Section 6.1 on definition and discovery of supported HTTP URIs and 4347 content types, add a path for nested messages as specified in 4348 Section 5.2.2 and delete the paths for /getCertMgtConfig and 4349 /getVoucher 4350 * Changed Section 6.4 to address offline transport and added more 4351 detailed specification file-based transport of CMP 4352 * Added a reference to the new I-D of Mohit Sahni on "CoAP Transport 4353 for CMPV2" in Section 6.2; thanks to Mohit supporting the effort 4354 to ease utilization of CMP 4355 * Moved the change history to the Appendix 4356 * Minor changes in wording 4358 From version 00 -> 01: 4360 * Harmonize terminology with CMP [RFC4210], e.g., 4361 - transaction, message sequence, exchange, use case -> PKI 4362 management operation 4363 - PKI component, (L)RA/CA -> PKI management entity 4364 * Minor changes in wording 4366 From draft-brockhaus-lamps-lightweight-cmp-profile-03 -> draft-ietf- 4367 lamps-lightweight-cmp-profile-00: 4369 * Changes required to reflect WG adoption 4370 * Minor changes in wording 4372 From version 02 -> 03: 4374 * Added a short summary of [RFC4210] Appendix D and E in 4375 Section 1.4. 4376 * Clarified some references to different sections and added some 4377 clarification in response to feedback from Michael Richardson and 4378 Tomas Gustavsson. 4379 * Added an additional label to the operational path to address 4380 multiple CAs or certificate profiles in Section 6.1. 4382 From version 01 -> 02: 4384 * Added some clarification on the key management techniques for 4385 protection of centrally generated keys in Section 4.1.6. 4386 * Added some clarifications on the certificates for root CA 4387 certificate update in Section 4.3.2. 4388 * Added a section to specify the usage of nested messages for RAs to 4389 add an additional protection for further discussion, see 4390 Section 5.2.2. 4391 * Added a table containing endpoints for HTTP transport in 4392 Section 6.1 to simplify addressing PKI management entities. 4393 * Added some ToDos resulting from discussion with Tomas Gustavsson. 4394 * Minor clarifications and changes in wording. 4396 From version 00 -> 01: 4398 * Added a section to specify the enrollment with an already trusted 4399 PKI for further discussion, see Section 4.1.2. 4400 * Complete specification of requesting a certificate from a legacy 4401 PKI using a PKCS#10 [RFC2986] request in Section 4.1.4. 4402 * Complete specification of adding central generation of a key pair 4403 on behalf of an end entity in Section 4.1.6. 4404 * Complete specification of handling delayed enrollment due to 4405 asynchronous message delivery in Section 4.4. 4407 * Complete specification of additional support messages, e.g., to 4408 update a Root CA certificate or to request an RFC 8366 [RFC8366] 4409 voucher, in Section 4.3. 4410 * Minor changes in wording. 4412 From draft-brockhaus-lamps-industrial-cmp-profile-00 -> draft- 4413 brockhaus-lamps-lightweight-cmp-profile-00: 4415 * Change focus from industrial to more multi-purpose use cases and 4416 lightweight CMP profile. 4417 * Incorporate the omitted confirmation into the header specified in 4418 Section 3.1 and described in the standard enrollment use case in 4419 Section 4.1.1 due to discussion with Tomas Gustavsson. 4420 * Change from OPTIONAL to RECOMMENDED for use case 'Revoke another's 4421 entities certificate' in Section 5.3.2, because it is regarded as 4422 important functionality in many environments to enable the 4423 management station to revoke EE certificates. 4424 * Complete the specification of the revocation message flow in 4425 Section 4.2 and Section 5.3.2. 4426 * The CoAP based transport mechanism and piggybacking of CMP 4427 messages on top of other reliable transport protocols is out of 4428 scope of this document and would need to be specified in another 4429 document. 4430 * Further minor changes in wording. 4432 Authors' Addresses 4434 Hendrik Brockhaus (editor) 4435 Siemens AG 4437 Email: hendrik.brockhaus@siemens.com 4439 David von Oheimb 4440 Siemens AG 4442 Email: david.von.oheimb@siemens.com 4444 Steffen Fries 4445 Siemens AG 4447 Email: steffen.fries@siemens.com