idnits 2.17.1 draft-ietf-lamps-lightweight-cmp-profile-09.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- No issues found here. Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- == There is 1 instance of lines with non-ascii characters in the document. Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- == There are 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 == Using lowercase 'not' together with uppercase 'MUST', 'SHALL', 'SHOULD', or 'RECOMMENDED' is not an accepted usage according to RFC 2119. Please use uppercase 'NOT' together with RFC 2119 keywords (if that is what you mean). Found 'MUST not' in this paragraph: If the error condition is on an upstream nested message containing batched requests, it MUST not attempt to respond to the individual requests included in it. -- The document date (17 December 2021) is 859 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 702, but not defined == Missing Reference: 'RFC-CMP-Updates' is mentioned on line 740, but not defined -- Looks like a reference, but probably isn't: '3' on line 4107 -- Looks like a reference, but probably isn't: '5' on line 4110 -- Looks like a reference, but probably isn't: '9' on line 4133 -- Looks like a reference, but probably isn't: '2' on line 4138 -- Looks like a reference, but probably isn't: '7' on line 4139 == Outdated reference: A later version (-10) exists of draft-ietf-ace-cmpv2-coap-transport-04 == Outdated reference: A later version (-15) exists of draft-ietf-lamps-cmp-algorithms-08 == Outdated reference: A later version (-23) exists of draft-ietf-lamps-cmp-updates-15 ** 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-12 -- Obsolete informational reference (is this intentional?): RFC 2510 (Obsoleted by RFC 4210) -- Obsolete informational reference (is this intentional?): RFC 2818 (Obsoleted by RFC 9110) -- Obsolete informational reference (is this intentional?): RFC 5246 (Obsoleted by RFC 8446) Summary: 1 error (**), 0 flaws (~~), 12 warnings (==), 9 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 LAMPS Working Group H. Brockhaus, Ed. 3 Internet-Draft D. von Oheimb 4 Intended status: Standards Track S. Fries 5 Expires: 20 June 2022 Siemens 6 17 December 2021 8 Lightweight Certificate Management Protocol (CMP) Profile 9 draft-ietf-lamps-lightweight-cmp-profile-09 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 20 June 2022. 42 Copyright Notice 44 Copyright (c) 2021 IETF Trust and the persons identified as the 45 document authors. All rights reserved. 47 This document is subject to BCP 78 and the IETF Trust's Legal 48 Provisions Relating to IETF Documents (https://trustee.ietf.org/ 49 license-info) in effect on the date of publication of this document. 50 Please review these documents carefully, as they describe your rights 51 and restrictions with respect to this document. Code Components 52 extracted from this document must include Revised BSD License text as 53 described in Section 4.e of the Trust Legal Provisions and are 54 provided without warranty as described in the Revised BSD License. 56 Table of Contents 58 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 4 59 1.1. How to Read This Document . . . . . . . . . . . . . . . . 4 60 1.2. Motivation for a lightweight profile of CMP . . . . . . . 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 . . . . . . . . . . . . . . . . . 9 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 . . . . . . . . . . . . . 13 70 3.1. General description of the CMP message header . . . . . . 14 71 3.2. General description of the CMP message protection . . . . 16 72 3.3. General description of CMP message extraCerts . . . . . . 17 73 3.4. Generic PKI management operation prerequisites . . . . . 17 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 . . . . . . . . . . . . . 22 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] environments, 314 SZTP-CSR [I-D.ietf-netconf-sztp-csr] includes certificate signing 315 requests (CSR) in device bootstrapping to obtain a public-key 316 certificate for a locally generated key pair. One option is using a 317 CMP p10cr message. Such a CSR is of form ietf-sztp-types:cmp-csr 318 from module ietf-sztp-csr. To allow PKI management entities to also 319 comply with this profile, the p10cr message must be formatted by the 320 EE as described in Section 4.1.4 of this profile, and it may be 321 forwarded as specified in Section 5.2. 323 In Bootstrapping Remote Secure Key Infrastructure (BRSKI) [RFC8995] 324 environments, BRSKI Asynchronous Enrollment BRSKI Asynchronous 325 Enrollment [I-D.ietf-anima-brski-async-enroll] describes a 326 generalization regarding the employed enrollment protocols to allow 327 alternatives to EST [RFC7030]. For the use of CMP, it requires 328 adherence to this profile. 330 1.6. Compatibility with existing CMP profiles 332 The profile specified in this document is compatible with RFC 4210 333 Appendixes D and E (PKI Management Message Profiles) [RFC4210], with 334 the following exceptions: 336 * signature-based protection is the default protection; an initial 337 PKI management operation may also use MAC-based protection, 339 * certification of a second key pair within the same PKI management 340 operation is not supported, 342 * proof-of-possession (POPO) with self-signature of the certTemplate 343 according to RFC 4211 Section 4.1 [RFC4211] clause 3 is the 344 recommended default POPO method (deviations are possible for EEs 345 when requesting central key generation, for RAs when using 346 raVerified, and if the newly generated keypair is technically not 347 capable to generate digital signatures), 349 * confirmation of newly enrolled certificates may be omitted, and 351 * all PKI management operations consist of request-response message 352 pairs originating at the EE, i.e., announcement messages 353 (requiring a push model, a CMP server on the EE) are excluded in 354 favor of a lightweight implementation on the EE. 356 The profile specified in this document is compatible with the CMP 357 profile for 3G, LTE, and 5G network domain security and 358 authentication framework [ETSI-3GPP.33.310], except that: 360 * protection of initial PKI management operations may be MAC-based, 362 * the subject field is mandatory in certificate templates, and 364 * confirmation of newly enrolled certificates may be omitted. 366 The profile specified in this document is compatible with the CMP 367 profile for on-line key management in rail networks as specified in 368 UNISIG Subset-137 [UNISIG.Subset-137], except that: 370 * A certificate enrollment request message consists of only one 371 certificate request (CertReqMsg). 373 * RFC 4210 [RFC4210] requires that the messageTime is Greenwich Mean 374 Time coded as generalizedTime. 376 Note: As UNISIG Subset-137 Table 5 [UNISIG.Subset-137] explicitly 377 states that the messageTime in required to be "UTC time", it is 378 not clear if this means a coding as UTCTime or generalizedTime and 379 if other time zones than Greenwich Mean Time shall be allowed. 380 Both time formats are described in RFC 5280 Section 4.1.2.5 381 [RFC5280]. 383 * The same type of protection is required to be used for all 384 messages of one PKI management operation. This means, in case the 385 request message protection is MAC-based, also the response, 386 certConf, and pkiConf messages must have a MAC-based protection. 388 * Use of caPubs is not required but typically allowed in combination 389 with MAC-based protected PKI management operations. On the other 390 hand UNISIG Subset-137 Table 12 [UNISIG.Subset-137] requires using 391 caPubs. 393 Note: It remains unclear from UNISIG Subset-137 for which 394 certificate(s) the caPubs field should be used. For security 395 reasons, it cannot be used for delivering the root CA certificate 396 needed for validating the signature-based protection of the given 397 response message (as stated indirectly also in its UNISIG 398 Subset-137 Section 6.3.1.5.2 b [UNISIG.Subset-137]). 400 * This profile requires that the certConf message has one CertStatus 401 element where the statusInfo field is recommended. 403 Note: In contrast, UNISIG Subset-137 Table 18 [UNISIG.Subset-137] 404 requires that the certConf message has one CertStatus element 405 where the statusInfo field must be absent. This precludes sending 406 a negative certConf message in case the EE rejects the newly 407 enrolled certificate. This results in violating the general rule 408 that a certificate request transaction must include a certConf 409 message (since moreover, using implicitConfirm is not allowed 410 there, neither). 412 1.7. Scope of this document 414 To minimize ambiguity and complexity through needless variety, this 415 document specifies exhaustive requirements on generating PKI 416 management messages on the sender side. On the other hand, it gives 417 only minimal requirements on checks by the receiving side and how to 418 handle error cases. 420 Especially on the EE side this profile aims at a lightweight 421 implementation. This means that the number of PKI management 422 operations implementations are reduced to a reasonable minimum to 423 support typical certificate management use cases in industrial 424 machine-to-machine environments. On the EE side only limited 425 resources are expected, while on the side of the PKI management 426 entities the profile accepts higher requirements. 428 For the sake of interoperability and robustness, implementations 429 should, as far as security is not affected, adhere to Postel's law: 430 "Be conservative in what you do, be liberal in what you accept from 431 others" (often reworded as: "Be conservative in what you send, be 432 liberal in what you receive"). 434 When in Section 3, Section 4, and Section 5 a field of the ASN.1 435 syntax as defined in CMP [RFC4210] and [I-D.ietf-lamps-cmp-updates], 436 CRMF [RFC4211], and CMS [RFC5652] and [RFC8933] is not explicitly 437 specified, it SHOULD NOT be used by the sending entity. The 438 receiving entity MUST NOT require its absence and if present MUST 439 gracefully handle its presence. 441 1.8. Structure of this document 443 Section 2 introduces the general PKI architecture and approach to 444 certificate management that is assumed in this document. Then it 445 lists the PKI management operations specified in this document, 446 partitioning them into mandatory, recommended, and optional ones. 448 Section 3 profiles the generic aspects of the PKI management 449 operations specified in detail in Section 4 and Section 5 to minimize 450 redundancy in the description and to ease implementation. This 451 covers the general structure and protection of messages, as well as 452 generic prerequisites, validation, and error handling. 454 Section 4 profiles the exchange of CMP messages between an EE and the 455 PKI management entity. There are various flavors of certificate 456 enrollment requests, optionally with polling, central key generation, 457 revocation, and general support PKI management operations. 459 Section 5 profiles responding to requests, exchange between PKI 460 management entities, and operations on behalf of other PKI entities. 461 This may include delayed delivery of messages, which involves polling 462 for responses, and nesting of messages. 464 Section 6 outlines several mechanisms for CMP message transfer, 465 including HTTP-based [RFC6712] transfer optionally using TLS, and 466 [I-D.ietf-ace-cmpv2-coap-transport] transfer optionally using DTLS, 467 and offline file-based transport. 469 Section 7 defines which parts of the profile are mandatory, 470 recommended, optional, or not relevant to implement for which type of 471 entity. 473 1.9. Convention and Terminology 475 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 476 "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and 477 "OPTIONAL" in this document are to be interpreted as described in BCP 478 14 [RFC2119] [RFC8174] when, and only when, they appear in all 479 capitals, as shown here. 481 Technical terminology is used in conformance with RFC 4210 [RFC4210], 482 RFC 4211 [RFC4211], RFC 5280 [RFC5280], and IEEE 802.1AR 483 [IEEE.802.1AR_2018]. The following key words are used: 485 CA: Certification authority, which issues certificates. 487 RA: Registration authority, an optional PKI component to which a CA 488 delegates certificate management functions such as end entity 489 authentication and authorization checks for incoming requests. 490 An RA can also provide conversion between various certificate 491 management protocols and other protocols providing some 492 operations related to certificate management. 494 LRA: Local registration authority, a specific form of RA with 495 proximity to the end entities. 497 Note: For ease of reading, this document uses the term "RA" 498 also for LRAs in all cases where the difference is not 499 relevant. 501 KGA: Key generation authority, an optional system component, 502 typically co-located with an RA or CA, that offers key 503 generation services to end entities. 505 EE: End entity, typically a device or service that holds a public- 506 private key pair for which it manages a public-key certificate. 507 An identifier for the EE is given as the subject of its 508 certificate. 510 The following terminology is reused from RFC 4210 [RFC4210], as 511 follows: 513 PKI management operation: All CMP messages belonging to a single 514 transaction. The transaction is 515 identified by the transactionID field of 516 the message headers. 518 PKI management entity: A non-EE PKI entity, i.e., RA or CA. 520 PKI entity: An EE or PKI management entity. 522 2. Solution architecture 524 To facilitate secure automatic certificate enrollment, the device 525 hosting an EE is typically equipped with a manufacturer-issued device 526 certificate. Such a certificate is typically installed during 527 production and is meant to identify the device throughout its 528 lifetime. This certificate can be used to protect the initial 529 enrollment of operational certificates after installation of the EE 530 in its operational environment. In contrast to the manufacturer- 531 issued device certificate, operational certificates are issued by the 532 owner or operator of the device to identify the device or one of its 533 components for operational use, e.g., in a security protocol like 534 IPsec, TLS, or SSH. In IEEE 802.1AR [IEEE.802.1AR_2018] a 535 manufacturer-issued device certificate is called IDevID certificate 536 and an operational certificate is called LDevID certificate. 538 Note: According to IEEE 802.1AR [IEEE.802.1AR_2018] a DevID comprises 539 the triple of the certificate, the corresponding private key, and the 540 certificate chain. 542 All certificate management operations specified in this document 543 follow the pull model, i.e., are initiated by an EE (or by an RA 544 acting as an EE). The EE creates a CMP request message, protects it 545 using some asymmetric credential or shared secret information and 546 sends it to its locally reachable PKI management entity. This PKI 547 management entity may be a CA or more typically an RA, which checks 548 the request, responds to it itself, or forwards the request upstream 549 to the next PKI management entity. In case an RA changes the CMP 550 request message header or body or wants to demonstrate successful 551 verification or authorization, it can apply a protection of its own. 552 Especially the communication between an LRA and RA can be performed 553 synchronously or asynchronously. Synchronous communication describes 554 a timely uninterrupted communication between two communication 555 partners, while asynchronous communication is not performed in a 556 timely consistent manner, e.g., because of a delayed message 557 delivery. 559 +-----+ +-----+ +-----+ +-----+ 560 | | | | | | | | 561 | EE |<---------->| LRA |<-------------->| RA |<---------->| CA | 562 | | | | | | | | 563 +-----+ +-----+ +-----+ +-----+ 565 synchronous (a)synchronous (a)synchronous 566 +----connection----+------connection------+----connection----+ 568 operators service partner 569 +---------on site--------+----back-end services-----+-trust center-+ 570 Figure 1: Certificate management architecture example 572 In operational environments the certificate management architecture 573 can have multiple LRAs bundling requests from multiple EEs at 574 dedicated locations and one (or more than one) central RA aggregating 575 the requests from the LRAs. Every LRA in this scenario has shared 576 secret information (one per EE) for MAC-based protection or a CMP 577 protection key and certificate allowing it to (re-)protect CMP 578 messages it processes. The figure above shows an architecture 579 example with at least one LRA, RA, and CA. It is also possible not 580 to have an RA or LRA or that there is no CA with a CMP interface. 581 Depending on the network infrastructure, the message transfer between 582 PKI management entities may be based on synchronous online 583 connections, asynchronous connections, or even offline (e.g., file- 584 based) transfer. 586 Note: CMP response messages could also be used proactively to 587 implement the push model towards the EE. In this case the EE acts as 588 receiver, not initiating the interaction with the PKI. Also, when 589 using a commissioning tool or a registrar agent as described in BRSKI 590 with Pledge in Responder Mode (BRSKI-PRM) [I-D.ietf-anima-brski-prm], 591 certificate enrollment in a push model is needed. CMP in general and 592 the messages specified in this profile offer all required 593 capabilities, but the message flow and state machine as described in 594 Section 4 must be adapted to implement a push model. 596 Third-party CAs may implement other variants of CMP, different 597 standardized protocols, or even proprietary interfaces for 598 certificate management. Therefore, the RA may need to adapt the 599 exchanged CMP messages to the flavor of certificate management 600 interaction required by the CA. 602 3. Generic aspects of the PKI message 604 This section covers the generic aspects of the PKI management 605 operations specified in Section 4 and Section 5 as upfront general 606 requirements to minimize redundancy in the description and to ease 607 implementation. 609 As described in Section 5.1 of RFC 4210 [RFC4210], all CMP messages 610 have the following general structure: 612 +--------------------------------------------+ 613 | PKIMessage | 614 | +----------------------------------------+ | 615 | | header | | 616 | +----------------------------------------+ | 617 | +----------------------------------------+ | 618 | | body | | 619 | +----------------------------------------+ | 620 | +----------------------------------------+ | 621 | | protection (OPTIONAL) | | 622 | +----------------------------------------+ | 623 | +----------------------------------------+ | 624 | | extraCerts (OPTIONAL) | | 625 | +----------------------------------------+ | 626 +--------------------------------------------+ 628 Figure 2: CMP message structure 630 The general contents of the message header, protection, and 631 extraCerts fields are specified in the following three subsections. 633 In case a specific PKI management operation needs different contents 634 in the header, protection, or extraCerts fields, the differences are 635 described in the respective subsections. 637 The CMP message body contains the PKI management operation-specific 638 information. It is described in Section 4 and Section 5. 640 The generic prerequisites needed by the PKI entities in order to be 641 able to perform PKI management operations are described in 642 Section 3.4. 644 The generic validation steps to be performed by PKI entities on 645 receiving a CMP message are described in Section 3.5. 647 The generic aspects of handling and reporting errors are described in 648 Section 3.6. 650 3.1. General description of the CMP message header 652 This section describes the generic header fields of all CMP messages 653 with signature-based protection. 655 In case a message has MAC-based protection the changes are described 656 in Section 4.1.5. The variations will affect the fields sender, 657 protectionAlg, and senderKID. 659 Any PKI management operation-specific fields or variations are 660 described in Section 4 and 5. 662 header 663 pvno REQUIRED 664 -- MUST be 3 to indicate CMP v3 in all cases where EnvelopedData 665 -- is supported and expected to be used in the current 666 -- PKI management operation 667 -- MUST be 3 to indicate CMP v3 in certConf messages when using 668 -- the hashAlg field 669 -- MUST be 2 to indicate CMP v2 in all other cases 670 -- For details on version negotiation see RFC-CMP-Updates 671 sender REQUIRED 672 -- SHOULD contain a name representing the originator of the 673 -- message; otherwise, the NULL-DN (a zero-length 674 -- SEQUENCE OF RelativeDistinguishedNames) MUST be used 675 -- SHOULD be the subject of the CMP protection certificate, i.e., 676 -- the certificate corresponding to the private key used to sign 677 -- the message 678 -- In a multi-hop scenario, the receiving entity SHOULD NOT rely 679 -- on the correctness of the sender field. 680 recipient REQUIRED 681 -- SHOULD be the name of the intended recipient; otherwise, the 682 -- NULL-DN MUST be used 683 -- In the first message of a PKI management operation: 684 -- SHOULD be the subject DN of the CA the PKI management 685 -- operation is requested from 686 -- In all other messages: 687 -- SHOULD contain the value of the sender field of the previous 688 -- message in the same PKI management operation 689 -- The recipient field SHALL be handled gracefully by the 690 -- receiving entity, because in a multi-hop scenario its 691 -- correctness cannot be guaranteed. 692 messageTime RECOMMENDED 693 -- MUST be the time at which the message was produced, if present 694 protectionAlg REQUIRED 695 -- MUST be an algorithm identifier indicating the algorithm 696 -- used for calculating the protection bits 697 -- If it is a signature algorithm its type MUST be a 698 -- MSG_SIG_ALG as specified in [RFC-CMP-Alg] Section 3 and 699 -- MUST be consistent with the subjectPublicKeyInfo field of 700 -- the protection certificate 701 -- If it is a MAC algorithm its type MUST be a MSG_MAC_ALG as 702 -- specified in [RFC-CMP-Alg] Section 6.1 703 senderKID RECOMMENDED 704 -- MUST be the SubjectKeyIdentifier of the CMP protection 705 -- certificate in case of signature-based protection 706 transactionID REQUIRED 707 -- In the first message of a PKI management operation: 708 -- MUST be 128 bits of random data, to minimize the probability 709 -- of having the transactionID already in use at the server 710 -- In all other messages: 711 -- MUST be the value from the previous message in the same 712 -- PKI management operation 713 senderNonce REQUIRED 714 -- MUST be cryptographically secure and fresh 128 random bits 715 recipNonce RECOMMENDED 716 -- If this is the first message of a transaction: SHOULD be 717 -- absent 718 -- If this is a delayed response message: MUST be present and 719 -- contain the value of the senderNonce of the respective request 720 -- message in the same transaction 721 -- In all other messages: MUST be present and contain the value 722 -- of the senderNonce of the previous message in the same 723 -- transaction 724 generalInfo OPTIONAL 725 implicitConfirm OPTIONAL 726 -- RECOMENDED in ir/cr/kur/p10cr messages, 727 -- OPTIONAL in ip/cp/kup response messages, and 728 -- PROHIBITED in other types of messages 729 -- Added to request messages to request omission of the certConf 730 -- message 731 -- Added to response messages to grant omission of the certConf 732 -- message 733 -- See [RFC4210] Section 5.1.1.1. 734 ImplicitConfirmValue REQUIRED 735 -- ImplicitConfirmValue MUST be NULL 736 certProfile OPTIONAL 737 -- MAY be present in ir/cr/kur/p10cr and in genm messages of type 738 -- id-it-certReqTemplate 739 -- MUST be omitted in all other messages 740 -- See [RFC-CMP-Updates] 741 CertProfileValue REQUIRED 742 -- MUST contain exactly one UTF8String element 743 -- MUST contain the name of a certificate profile 745 3.2. General description of the CMP message protection 747 This section describes the generic protection field contents of all 748 CMP messages with signature-based protection. The private key used 749 to sign a CMP message is called "protection key" and the related 750 certificate is called "protection certificate". Any included 751 keyUsage extension SHOULD allow digitalSignature. 753 protection RECOMMENDED 754 -- MUST contain the signature calculated using the private key 755 -- of the entity protecting the message. The signature 756 -- algorithm used MUST be given in the protectionAlg field. 758 Generally, CMP message protection is required for CMP messages, but 759 there are cases where protection of error messages specified in 760 Section 3.6 is not possible and therefore MAY be omitted. 762 For MAC-based protection as specified in Section 4.1.5 major 763 differences apply as described there. 765 The CMP message protection provides, if available, message origin 766 authentication and integrity protection for the header and body. The 767 CMP message extraCerts field is not covered by this protection. 769 Note: The extended key usages described in CMP Updates Section 2.2 770 [I-D.ietf-lamps-cmp-updates] can be used for authorization of a 771 sending PKI management entity. 773 3.3. General description of CMP message extraCerts 775 This section describes the generic extraCerts field of all CMP 776 messages with signature-based protection. Any specific requirements 777 on the extraCerts are specified in the respective PKI management 778 operation. 780 extraCerts 781 -- SHOULD contain the CMP protection certificate together with 782 -- its chain, if needed 783 -- If present, the first certificate in this field MUST be 784 -- the CMP protection certificate followed by its chain 785 -- where each element SHOULD directly certify the one 786 -- immediately preceding it. 787 -- Self-signed certificates SHOULD be omitted from extraCerts, 788 -- unless they are the same as the protection certificate and 789 -- MUST NOT be trusted based on their inclusion in any case 791 Note: For maximum compatibility, all implementations SHOULD be 792 prepared to handle potentially additional certificates and arbitrary 793 orderings of the certificates. 795 3.4. Generic PKI management operation prerequisites 797 This subsection describes what is generally needed by the PKI 798 entities to be able to perform PKI management operations. 800 Identification of PKI entities: 802 * Each EE SHOULD know its own identity to fill the sender field. 804 * Each EE SHOULD know the intended recipient of its requests to fill 805 the recipient field, e.g., the name of the addressed CA. 807 Note: This name may be established using an enrollment voucher, 808 e.g., [RFC8366], the issuer field from a CertReqTemplate response 809 message content, or by other configuration means. 811 Routing of CMP messages: 813 * Each PKI entity sending messages upstream MUST know the address 814 needed for transferring messages to the next PKI management 815 entity. 817 Note: This address may depend on the recipient, the certificate 818 profile, and on the used transfer mechanism. 820 Authentication of PKI entities: 822 * Each PKI entity MUST have credentials to authenticate itself. For 823 signature-based protection it MUST have a private key and the 824 corresponding certificate along with its chain. 826 * Each PKI entity MUST be able to establish trust in PKI it receives 827 responses from. When signature-based protection is used, it MUST 828 have the trust anchor(s) and any certificate status information 829 needed to perform path validation of CMP protection certificates 830 used for signature-based protection. 832 Note: A trust anchor usually is a root certificate of the PKI 833 addressed by the requesting EE. It may be established by 834 configuration or in an out-of-band manner. For an EE it may be 835 established using an enrollment voucher [RFC8366] or in-band of 836 CMP by the caPubs field in a certificate response message. 838 Authorization of PKI management operations: 840 * Each EE or RA MUST have sufficient information to be able to 841 authorize the PKI management entity for performing the upstream 842 PKI management operation. 844 Note: This may be achieved for example by using the cmcRA extended 845 key usage in server certificates, by local configuration such as 846 specific name patterns for subject DN or SAN portions that may 847 identify an RA, and/or by having a dedicated root CA usable only 848 for authenticating PKI management entities. 850 * Each PKI management entity MUST have sufficient information to be 851 able to authorize the downstream PKI entity requesting the PKI 852 management operation. 854 Note: For authorizing an RA the same examples apply as above. The 855 authorization of EEs can be very specific to the application 856 domain and may involve information from configuration or inventory 857 database. It may involve, e.g., the issuer information of the EE 858 certificate, specific contents of the CMP protection certificate 859 used by the EE such as name patterns of subject DN or SAN 860 portions, shared secret information, and other types of 861 credentials and evidence potentially communicated out-of-band. 863 3.5. Generic validation of a PKI message 865 This section describes generic validation steps of each PKI entity 866 receiving a PKI request or response message before any further 867 processing or forwarding. If a PKI management entity decides to 868 terminate a PKI management operation because a check failed, it MUST 869 send a negative response or an error message as described in 870 Section 3.6. The PKIFailureInfo bits given below in parentheses MAY 871 be used in the failInfo field of the PKIStatusInfo as described in 872 Section 3.6.4, see also RFC 4210 Appendix F [RFC4210]. 874 All PKI message header fields not mentioned in this section like the 875 recipient and generalInfo fields SHOULD be handled gracefully on 876 reception. 878 The following list describes the basic set of message input 879 validation steps. Without these checks the protocol becomes 880 dysfunctional. 882 * The formal ASN.1 syntax of the whole message MUST be compliant 883 with the definitions given in CMP [RFC4210] and 884 [I-D.ietf-lamps-cmp-updates], CRMF [RFC4211], and CMS [RFC5652] 885 and [RFC8933]. (failInfo: badDataFormat) 887 * The pvno MUST be cmp2000(2) or cmp2021(3). (failInfo bit: 888 unsupportedVersion) 890 * The transactionID MUST be present. (failInfo bit: badDataFormat) 892 * The PKI message body type MUST be one of the message types 893 supported by the receiving PKI entity and MUST be allowed in the 894 current state of the PKI management operation identified by the 895 given transactionID. (failInfo bit: badRequest) 897 The following list describes the set of message input validation 898 steps required to ensure secure protocol operation: 900 * The senderNonce MUST be present and MUST contain at least 128 bits 901 of data. (failInfo bit: badSenderNonce) 903 * Unless the PKI message is the first message of a PKI management 904 operation, 906 - the recipNonce MUST be present and MUST equal the senderNonce 907 of the previous message or equal the senderNonce of the most 908 recent request message for which the response was delayed, in 909 case of delayed delivery as specified in Section 4.4. (failInfo 910 bit: badRecipientNonce) 912 * The message protection MUST be validated: 914 - The protection MUST be signature-based except if MAC-based 915 protection is used as described in Section 4.1.5 and for some 916 error messages as described in Section 3.6.4. (failInfo bit: 917 wrongIntegrity) 919 - The senderKID SHOULD identify the key material used for 920 verifying the message protection. (failInfo bit: 921 badMessageCheck) 923 - The protection, if present, MUST be validated successfully. If 924 signature-based protection is used, the CMP protection 925 certificate MUST be successfully validated including path 926 validation using a trust anchor and MUST be authorized 927 according to local policies. If the keyUsage extension is 928 present in the CMP protection certificate the digitalSignature 929 bit SHOULD be set. (failInfo bit: badAlg, badMessageCheck, or 930 signerNotTrusted) 932 - The sender of a request message MUST be authorized for 933 requesting the operation according to PKI policies. (failInfo 934 bit: notAuthorized) 936 Note: The requirements for checking certificates given in RFC 5280 937 [RFC5280] MUST be followed for signature-based CMP message 938 protection. Unless the message is a positive ip/cp/kup where the 939 issuing CA certificate of the newly enrolled certificate is the same 940 as the CMP protection certificate of that message, certificate status 941 checking SHOULD be performed on the CMP protection certificates. 943 Depending on local policies, one or more of the input validation 944 checks described below need to be implemented: 946 * If signature-based protection is used, the sender field SHOULD 947 match the subject of the CMP protection certificate. (failInfo 948 bit: badMessageCheck) 950 * If the messageTime is present, it SHOULD be close to the current 951 time. (failInfo bit: badTime) 953 3.6. Error handling 955 This section describes how a PKI entity handles error conditions on 956 messages it receives. Each error condition SHOULD be logged 957 appropriately. 959 3.6.1. Reporting error conditions upstream 961 An EE SHALL NOT send error messages. PKI management entities SHALL 962 NOT send error messages in upstream direction, either. 964 In case an EE rejects a newly issued certificate contained in an ip, 965 cp, or kup message and implicit confirmation has not been granted, 966 the EE MUST report this using a certConf message with "rejection" 967 status and await the pkiConf response as described in Section 4.1.1. 969 On all other error conditions regarding response messages, the EE or 970 PKI management entity MUST regard the current PKI management 971 operation as terminated with failure. The error conditions include 973 * invalid response message header, body type, protection, or 974 extraCerts according to the checks described in Section 3.5, 976 * any issue detected with response message contents, 978 * receipt of an error message from upstream, 980 * timeout occurred while waiting for a response, 982 * rejection of a newly issued certificate while implicit 983 confirmation has been granted. 985 Upstream PKI management entities will not receive any CMP message to 986 learn that the PKI management operation has been terminated. In case 987 they expect a further message from the EE, a connection interruption 988 or timeout will occur. Then they also MUST regard the current PKI 989 management operation as terminated with failure and MUST NOT attempt 990 to send an error message downstream. 992 3.6.2. Reporting error conditions downstream 994 In case the PKI management entity detects an error condition, e.g., 995 rejecting the request due to policy decision, in the body of an ir, 996 cr, p10cr, kur, or rr message received from downstream, it SHOULD 997 report the error in the specific response message, i.e., an ip, cp, 998 kup, or rp with "rejection" status, as described in Section 4.1.1 and 999 Section 4.2. This can also happen in case of polling. 1001 In case the PKI management entity detects any other error condition 1002 on requests, including pollReq, certConf, genm, and nested messages, 1003 received from downstream and on responses received from upstream, 1004 such as invalid message header, body type, protection, or extraCerts 1005 according to the checks described in Section 3.5 it MUST report them 1006 downstream in the form of an error message as described in 1007 Section 3.6.4. 1009 3.6.3. Handling error conditions on nested messages used for batching 1011 Batching of messages using nested messages as described in 1012 Section 5.2.2.2 requires special error handling. 1014 If the error condition is on an upstream nested message containing 1015 batched requests, it MUST not attempt to respond to the individual 1016 requests included in it. 1018 In case a PKI management entity receives an error message in response 1019 to a nested message, it must propagate the error by responding with 1020 an error message to each of the request messages contained in the 1021 nested message. 1023 In case a PKI management entity detects an error condition on the 1024 downstream nested message received in response to a nested message 1025 sent before, it MAY ignore this error condition and handle the 1026 response as described in Section 5.2.2.2. Otherwise, it MUST 1027 propagate the error by responding with an error message to each of 1028 the requests contained in the nested message it sent originally. 1030 3.6.4. Reporting error conditions 1032 When sending any kind of negative response, including error messages, 1033 a PKI entity MUST indicate the error condition in the PKIStatusInfo 1034 structure of the respective message as described below. It then MUST 1035 regard the current PKI management operation as terminated with 1036 failure. 1038 The PKIStatusInfo structure is used to report errors. It may be part 1039 of various message types, in particular: certConf, ip, cp, kup, and 1040 error. The PKIStatusInfo structure consists of the following fields: 1042 * status: Here the PKIStatus value "rejection" MUST be used. 1044 Note: When a PKI management entity indicates delayed delivery of a 1045 CMP response message to the EE with an error message as described 1046 in Section 4.4, the status "waiting" is used there. 1048 * statusString: Here any human-readable valid value for logging or 1049 to display via a user interface SHOULD be added. 1051 * failInfo: Here the PKIFailureInfo bits MAY be used in the way 1052 explained in Appendix F of RFC 4210 [RFC4210]. PKIFailureInfo 1053 bits regarding the validation described in Section 3.5 are 1054 referenced there. The PKIFailureInfo bits referenced in 1055 Section 5.1 and Section 6 are described here: 1057 - badCertId: A kur, certConf, or rr message references an unknown 1058 certificate 1060 - badPOP: An ir/cr/p10cr/kur contains an invalid proof-of- 1061 possession 1063 - certRevoked: Revocation requested for a certificate already 1064 revoked 1066 - badCertTemplate: The contents of a certificate request are not 1067 accepted, e.g., a field is missing or has a non-acceptable 1068 value or the given public key is already in use in some other 1069 certificate (depending on policy). 1071 - transactionIdInUse: This is sent by a PKI management entity in 1072 case the received request contains a transaction ID that has 1073 already been used for another transaction. An EE receiving 1074 such error message SHOULD resend the request in a new 1075 transaction using a different transaction ID. 1077 - notAuthorized: The sender of a request message is not 1078 authorized for requesting the operation. 1080 - systemUnavail: This is sent by a PKI management entity in case 1081 a back-end system is not available. 1083 - systemFailure: This is sent by a PKI management entity in case 1084 a back-end system is currently not functioning correctly. 1086 An EE receiving a systemUnavail or systemFailure failInfo SHOULD 1087 resend the request in a new transaction after some time. 1089 Detailed error message description: 1091 Error Message -- error 1093 Field Value 1095 header 1096 -- As described in Section 3.1 1098 body 1099 -- The message indicating the error that occurred 1100 error REQUIRED 1101 pKIStatusInfo REQUIRED 1102 status REQUIRED 1103 -- MUST have the value "rejection" 1104 statusString RECOMMENDED 1105 -- SHOULD be any human-readable text for debugging, logging 1106 -- or to display in a GUI 1107 failInfo OPTIONAL 1108 -- MAY be present and contain the relevant PKIFailureInfo bits 1110 protection REQUIRED 1111 -- As described in Section 3.2 1113 extraCerts OPTIONAL 1114 -- As described in Section 3.3 1116 4. End Entity PKI management operations 1118 This chapter focuses on the communication of an EE with the PKI 1119 management entity it directly talks to. Depending on the network and 1120 PKI solution, this can be an RA or directly a CA. Handling of a 1121 message by a PKI management entity is described in Section 5. 1123 The PKI management operations specified in this section cover the 1124 following: 1126 * Requesting a certificate with variations like initial enrollment, 1127 certificate updates, central key generation, and MAC-based 1128 protection 1130 * Revoking a certificate 1132 * Support messages 1133 These operations mainly specify the message body of the CMP messages 1134 and utilize the specification of the message header, protection and 1135 extraCerts as specified in Section 3. The messages are named by the 1136 respective field names in PKIBody like ir, ip, cr, cp, etc., see 1137 RFC 4210 Section 5.1.2 [RFC4210]. 1139 The following diagram shows the EE state machine covering all PKI 1140 management operations described in this section, including negative 1141 responses, error messages described in Section 3.6.4, as well as 1142 ip/cp/kup/error messages with status "waiting", pollReq, and pollRep 1143 messages described in Section 4.4. 1145 On receiving messages from upstream, the EE MUST perform the general 1146 validation checks described in Section 3.5. The behavior in case an 1147 error occurs is described in Section 3.6. 1149 State machine: 1150 start 1151 | 1152 | send ir/cr/p10cr/kur/rr/genm 1153 v 1154 waiting for response 1155 | 1156 +--------------------------+--------------------------+ 1157 | | | 1158 | receives ip/cp/kup with | received ip/cp/kup/error | received 1159 | status "accepted" or | with status "waiting" | rp/genp or 1160 | "grantedWithMods" | | ip/cp/kup/ 1161 | v | error 1162 | +-------> polling | with status 1163 | | | | "rejection" 1164 | | received | send | 1165 | | pollRep | pollReq | 1166 | | v | 1167 | | waiting for response | 1168 | | | | 1169 | +------------+--------+ | 1170 | | | | 1171 | received ip/cp/kup | | received | 1172 | with status "accepted" | | rp/genp or | 1173 | or "grantedWithMods" | | ip/cp/kup/error | 1174 | | | with status | 1175 +---------->+<-------------+ | "rejection" | 1176 | | | 1177 +-----------+-----+ | | 1178 | | | | 1179 | implicitConfirm | implicitConfirm | | 1180 | granted | not granted | | 1181 | | | | 1182 | | send certConf | | 1183 | v | | 1184 | waiting for pkiConf*) | | 1185 | | | | 1186 | | received | | 1187 | | pkiConf | | 1188 +-----------------+------->+<-------+-----------------+ 1189 | 1190 v 1191 end 1193 *) in case of a delayed delivery of pkiConf responses the same 1194 polling mechanism is initiated as for rp or genp messages, by 1195 sending an error message with status "waiting". 1197 Note: All CMP messages belonging to the same PKI management operation 1198 MUST have the same transactionID because the message receiver 1199 identifies the elements of the operation in this way. 1201 This section is aligned with CMP [RFC4210], CMP Updates 1202 [I-D.ietf-lamps-cmp-updates], and CMP Algorithms 1203 [I-D.ietf-lamps-cmp-algorithms]. 1205 Guidelines as well as an algorithm use profile for this document are 1206 available in CMP Algorithms [I-D.ietf-lamps-cmp-algorithms]. 1208 4.1. Requesting a new certificate from a PKI 1210 There are various approaches for requesting a certificate from a PKI. 1212 These approaches differ in the way the EE authenticates itself to the 1213 PKI, in the form of the request being used, and how the key pair to 1214 be certified is generated. The authentication mechanisms may be as 1215 follows: 1217 * Using a certificate from an external PKI, e.g., a manufacturer- 1218 issued device certificate, and the corresponding private key 1220 * Using a private key and certificate issued from the same PKI that 1221 is addressed for requesting a certificate 1223 * Using the certificate to be updated and the corresponding private 1224 key 1226 * Using shared secret information known to the EE and the PKI 1227 management entity 1229 An EE requests a certificate indirectly or directly from a CA. When 1230 the PKI management entity handles the request as described in 1231 Section 5.1.1 and responds with a message containing the requested 1232 certificate, the EE MUST reply with a confirmation message unless 1233 implicitConfirm was granted. The PKI management entity then MUST 1234 handle it as described in Section 5.1.3 and respond with a 1235 confirmation, closing the PKI management operation. 1237 The message sequences described in this section allow the EE to 1238 request certification of a locally or centrally generated public- 1239 private key pair. Typically, the EE provides a signature-based 1240 proof-of-possession of the private key associated with the public key 1241 contained in the certificate request as defined by RFC 4211 1242 Section 4.1 [RFC4211] case 3. To this end it is assumed that the 1243 private key can technically be used for signing. This is the case 1244 for the most common algorithms RSA and ECDSA, regardless of 1245 potentially intended restrictions of the key usage. 1247 Note: In conformance with NIST SP 800-57 Part 1 Section 8.1.5.1.1.2 1248 [NIST.SP.800-57p1r5] the newly generated private key MAY be used for 1249 self-signature, if technically possible, even if the keyUsage 1250 extension requested in the certificate request prohibits generation 1251 of digital signatures. 1253 The requesting EE provides the binding of the proof-of-possession to 1254 its identity by signature-based or MAC-based protection of the CMP 1255 request message containing that POP. As detailed in Section 5.1.1 1256 and Section 5.1.2, an upstream PKI management entity should verify 1257 whether this EE is authorized to obtain a certificate with the 1258 requested subject and other fields and extensions. 1260 The EE MAY indicate the certificate profile to use in the certProfile 1261 extension of the generalInfo field in the PKIHeader of the 1262 certificate request message as described in Section 3.1. 1264 In case the EE receives a CA certificate in the caPubs field for 1265 installation as a new trust anchor, it MUST properly authenticate the 1266 message and authorize the sender as trusted source of the new trust 1267 anchor. This authorization is typically indicated using shared 1268 secret information for protecting an initialization response (ir) 1269 message. Authorization can also be signature-based using a 1270 certificate issued by another PKI that is explicitly authorized for 1271 this purpose. A certificate received in caPubs MUST NOT be accepted 1272 as a trust anchor if it is the root CA certificate of the certificate 1273 used for protecting the message. 1275 4.1.1. Requesting a certificate from a new PKI with signature-based 1276 protection 1278 This PKI management operation should be used by an EE to request a 1279 certificate from a new PKI using an existing certificate from an 1280 external PKI, e.g., a manufacturer-issued IDevID certificate 1281 [IEEE.802.1AR_2018], to authenticate itself to the new PKI. 1283 Note: In Bootstrapping Remote Secure Key Infrastructure (BRSKI) 1284 [RFC8995] environments, BRSKI Asynchronous Enrollment (BRSKI-AE) 1285 [I-D.ietf-anima-brski-async-enroll] describes a generalization 1286 regarding enrollment protocols alternative to EST [RFC7030]. As 1287 replacement of EST simpleenroll, BRSKI-AE uses this PKI management 1288 operation for bootstrapping LDevID certificates. 1290 Specific prerequisites augmenting the prerequisites in Section 3.4: 1292 * The certificate of the EE MUST have been enrolled by an external 1293 PKI, e.g., a manufacturer-issued device certificate. 1295 * The PKI management entity MUST have the trust anchor of the 1296 external PKI. 1298 * When using the generalInfo field certProfile, the EE MUST know the 1299 identifier needed to indicate the requested certificate profile. 1301 Message flow: 1303 Step# EE PKI management entity 1304 1 format ir 1305 2 -> ir -> 1306 3 handle or 1307 forward ir 1308 4 format or receive ip 1309 5 possibly grant 1310 implicitConfirm 1311 6 <- ip <- 1312 7 handle ip 1314 ----------------- if implicitConfirm not granted ----------------- 1316 8 format certConf 1317 9 -> certConf -> 1318 10 handle or 1319 forward certConf 1320 11 format or receive pkiConf 1321 12 <- pkiConf <- 1322 13 handle pkiConf 1324 For this PKI management operation, the EE MUST include exactly one 1325 CertReqMsg in the ir. If more certificates are required, further 1326 requests MUST be sent using separate PKI management operation. 1328 The EE SHOULD include the implicitConfirm extension in the header of 1329 the ir message as described in Section 3.1, unless it knows that 1330 certificate confirmation is needed. This leaves the choice to the 1331 PKI management entities whether the EE must send a certConf message 1332 on receiving a new certificate. Depending on the PKI policy and 1333 requirements for managing EE certificates, it can be important for 1334 PKI management entities to learn if the EE accepted the new 1335 certificate. In such cases, when responding with an ip message, the 1336 PKI management entity MUST NOT include the implicitConfirm extension. 1337 In case the PKI management entity does not need any explicit 1338 confirmation from the EE, it MUST include the extension as described 1339 in Section 3.1. This prevents explicit certificate confirmation and 1340 saves the overhead of a further message round-trip. 1342 If the EE did not request implicit confirmation or implicit 1343 confirmation was not granted by the PKI management entity, 1344 certificate confirmation MUST be performed as follows. If the EE 1345 successfully received the certificate, it MUST send a certConf 1346 message in due time. On receiving a valid certConf message, the PKI 1347 management entity MUST respond with a pkiConf message. If the PKI 1348 management entity does not receive the expected certConf message in 1349 time it MUST handle this like a rejection by the EE. In case of 1350 rejection, depending on its policy the PKI management entity MAY 1351 revoke the newly issued certificate, notify a monitoring system, or 1352 log the event internally. 1354 Note: Depending on PKI policy, a new certificate may be published by 1355 a PKI management entity, and explicit confirmation may be required. 1356 In this case it is advisable not to do the publication until a 1357 positive certificate confirmation has been received. This way the 1358 need to revoke the certificate on negative confirmation is avoided. 1360 If the certificate request was rejected by the CA, the PKI management 1361 entity must return an ip message containing the status code 1362 "rejection" as described in Section 3.6 and no certifiedKeyPair 1363 field. The EE MUST NOT react to such an ip message with a certConf 1364 message and the PKI management operation MUST be terminated. 1366 Detailed message description: 1368 Initialization Request -- ir 1370 Field Value 1372 header 1373 -- As described in Section 3.1 1375 body 1376 -- The request of the EE for a new certificate 1377 ir REQUIRED 1378 -- MUST contain exactly one CertReqMsg 1379 -- If more certificates are required, further PKI management 1380 -- operations MUST be initiated 1381 certReq REQUIRED 1382 certReqId REQUIRED 1383 -- MUST be 0 1384 certTemplate REQUIRED 1385 version OPTIONAL 1386 -- MUST be 2 if supplied 1387 subject REQUIRED 1388 -- The EE subject name MUST be carried in the subject field 1389 -- and/or the subjectAltName extension. 1390 -- If subject name is present only in the subjectAltName 1391 -- extension, then the subject field MUST be a NULL-DN 1392 publicKey REQUIRED 1393 algorithm REQUIRED 1394 -- MUST include the subject public key algorithm identifier 1395 subjectPublicKey REQUIRED 1396 -- MUST contain the public key to be certified in case of local 1397 -- key generation 1398 extensions OPTIONAL 1399 -- MAY include end-entity-specific X.509 extensions of the 1400 -- requested certificate like subject alternative name, key 1401 -- usage, and extended key usage 1402 -- The subjectAltName extension MUST be present if the EE subject 1403 -- name includes a subject alternative name. 1404 popo OPTIONAL 1405 -- MUST be present if local key generation is used 1406 -- MUST be absent if central key generation is requested 1407 signature RECOMMENDED 1408 -- MUST be used by an EE if the key can be used for signing and 1409 -- has the type POPOSigningKey 1410 poposkInput PROHIBITED 1411 -- MUST NOT be used; it is not needed because subject and 1412 -- publicKey are both present in the certTemplate 1413 algorithmIdentifier REQUIRED 1414 -- The signature algorithm MUST be consistent with the publicKey 1415 -- algorithm field of the certTemplate 1416 signature REQUIRED 1417 -- MUST contain the signature value computed over the DER-encoded 1418 -- certTemplate 1419 raVerified OPTIONAL 1420 -- MAY be used by an RA after verifying the proof-of-possession 1421 -- provided by the EE 1423 protection REQUIRED 1424 -- As described in Section 3.2 1426 extraCerts REQUIRED 1427 -- As described in Section 3.3 1429 Initialization Response -- ip 1431 Field Value 1433 header 1434 -- As described in Section 3.1 1436 body 1437 -- The response of the CA to the request as appropriate 1438 ip REQUIRED 1439 caPubs OPTIONAL 1440 -- MAY be used if the certifiedKeyPair field is present 1441 -- If used it MUST contain only a trust anchor, e.g. root 1442 -- certificate, of the certificate contained in certOrEncCert 1443 response REQUIRED 1444 -- MUST contain exactly one CertResponse 1445 certReqId REQUIRED 1446 -- MUST be 0 1447 status REQUIRED 1448 -- PKIStatusInfo structure MUST be present 1449 status REQUIRED 1450 -- positive values allowed: "accepted", "grantedWithMods" 1451 -- negative values allowed: "rejection" 1452 -- "waiting" only allowed with polling use case as described in 1453 -- Section 4.4 1454 statusString OPTIONAL 1455 -- MAY be any human-readable text for debugging, logging or to 1456 -- display in a GUI 1457 failInfo OPTIONAL 1458 -- MAY be present if status is "rejection" 1459 -- MUST be absent if status is "accepted" or "grantedWithMods" 1460 certifiedKeyPair OPTIONAL 1461 -- MUST be present if status is "accepted" or "grantedWithMods" 1462 -- MUST be absent if status is "rejection" 1463 certOrEncCert REQUIRED 1464 -- MUST be present if status is "accepted" or "grantedWithMods" 1465 certificate REQUIRED 1466 -- MUST be present when certifiedKeyPair is present 1467 -- MUST contain the newly enrolled X.509 certificate 1468 privateKey OPTIONAL 1469 -- MUST be absent in case of local key generation or "rejection" 1470 -- MUST contain the encrypted private key in an EnvelopedData 1471 -- structure as specified in Section 4.1.6 in case the private 1472 -- key was generated centrally 1474 protection REQUIRED 1475 -- As described in Section 3.2 1477 extraCerts REQUIRED 1478 -- As described in Section 3.3 1479 -- MUST contain the chain of the certificate present in 1480 -- certOrEncCert 1481 -- Self-signed certificates SHOULD be omitted 1482 -- Duplicate certificates MAY be omitted 1484 Certificate Confirmation -- certConf 1486 Field Value 1488 header 1489 -- As described in Section 3.1 1491 body 1492 -- The message of the EE sends as confirmation to the PKI 1493 -- management entity to accept or reject the issued certificates 1494 certConf REQUIRED 1495 -- MUST contain exactly one CertStatus 1496 CertStatus REQUIRED 1497 certHash REQUIRED 1498 -- MUST be the hash of the certificate, using the hash algorithm 1499 -- indicated in hashAlg, see below, or the same one as used to 1500 -- create the certificate signature 1501 certReqId REQUIRED 1502 -- MUST be 0 1503 statusInfo RECOMMENDED 1504 -- PKIStatusInfo structure SHOULD be present 1505 -- Omission indicates acceptance of the indicated certificate 1506 status REQUIRED 1507 -- positive values allowed: "accepted" 1508 -- negative values allowed: "rejection" 1509 statusString OPTIONAL 1510 -- MAY be any human-readable text for debugging, logging, or to 1511 -- display in a GUI 1512 failInfo OPTIONAL 1513 -- MAY be present if status is "rejection" 1514 -- MUST be absent if status is "accepted" 1515 hashAlg OPTIONAL 1516 -- The hash algorithm to use for calculating certHash 1517 -- SHOULD NOT be used in all cases where the AlgorithmIdentifier 1518 -- of the certificate signature specifies a hash algorithm 1519 -- If used, the pvno field in the header MUST be cmp2021 (3) 1521 protection REQUIRED 1522 -- As described in Section 3.2 1523 -- MUST use the same credentials as in the first request message 1524 -- of this PKI management operation 1526 extraCerts RECOMMENDED 1527 -- As described in Section 3.3 1528 -- MAY be omitted if the message size is critical and 1529 -- the PKI management entity caches the extraCerts from the 1530 -- first request message of this PKI management operation 1532 PKI Confirmation -- pkiConf 1534 Field Value 1536 header 1537 -- As described in Section 3.1 1539 body 1540 pkiconf REQUIRED 1541 -- The content of this field MUST be NULL 1543 protection REQUIRED 1544 -- As described in Section 3.2 1545 -- MUST use the same credentials as in the first response 1546 -- message of this PKI management operation 1548 extraCerts RECOMMENDED 1549 -- As described in Section 3.3 1550 -- MAY be omitted if the message size is critical and the EE has 1551 -- cached the extraCerts from the first response message of 1552 -- this PKI management operation 1554 4.1.2. Requesting an additional certificate with signature-based 1555 protection 1557 This PKI management operation should be used by an EE to request an 1558 additional certificate of the same PKI it already has certificates 1559 from. The EE uses one of these existing certificates to authenticate 1560 itself by signing its request messages using the respective private 1561 key. 1563 Specific prerequisites augmenting the prerequisites in Section 3.4: 1565 * The certificate used by the EE MUST have been enrolled by the PKI 1566 it requests another certificate from. 1568 * When using the generalInfo field certProfile, the EE MUST know the 1569 identifier needed to indicate the requested certificate profile. 1571 The message sequence for this PKI management operation is identical 1572 to that given in Section 4.1.1, with the following changes: 1574 1 The body of the first request and response SHOULD be cr and cp, 1575 respectively. 1577 Note: Since the difference between ir/ip and cr/cp is 1578 syntactically not essential, an ir/ip MAY be used in this PKI 1579 management operation. 1581 2 The caPubs field in the certificate response message SHOULD be 1582 absent. 1584 4.1.3. Updating an existing certificate with signature protection 1586 This PKI management operation should be used by an EE to request an 1587 update for one of its certificates that is still valid. The EE uses 1588 the certificate it wishes to update as the protection certificate. 1589 Both for authenticating itself and for proving ownership of the 1590 certificate to be updated, it signs the request messages with the 1591 corresponding private key. 1593 Specific prerequisites augmenting the prerequisites in Section 3.4: 1595 * The certificate the EE wishes to update MUST NOT be expired or 1596 revoked and MUST have been issued by the addressed CA. 1598 * A new public-private key pair SHOULD be used. 1600 * When using the generalInfo field certProfile, the EE MUST know the 1601 identifier needed to indicate the requested certificate profile. 1603 The message sequence for this PKI management operation is identical 1604 to that given in Section 4.1.1, with the following changes: 1606 1 The body of the first request and response MUST be kur and kup, 1607 respectively. 1609 2 Protection of the kur MUST be performed using the certificate to 1610 be updated. 1612 3 The subject field and/or the subjectAltName extension of the 1613 certTemplate MUST contain the EE subject name of the existing 1614 certificate to be updated, without modifications. 1616 4 The certTemplate SHOULD contain the subject and/or subjectAltName 1617 extension and publicKey of the EE only. 1619 5 The oldCertId control MAY be used to make clear which certificate 1620 is to be updated. 1622 6 The caPubs field in the kup message MUST be absent. 1624 As part of the certReq structure of the kur the oldCertId control is 1625 added after the certTemplate field. 1627 controls 1628 type RECOMMENDED 1629 -- MUST be the value id-regCtrl-oldCertID, if present 1630 value 1631 issuer REQUIRED 1632 serialNumber REQUIRED 1633 -- MUST contain the issuer and serialNumber of the certificate 1634 -- to be updated 1636 4.1.4. Requesting a certificate from a legacy PKI using a PKCS#10 1637 request 1639 This PKI management operation can be used by an EE to request a 1640 certificate using a legacy PKCS#10 [RFC2986] request instead of CRMF 1641 [RFC4211]. This offers a variation of the PKI management operations 1642 specified in Section 4.1.2. 1644 In Secure Zero Touch Provisioning (SZTP) [RFC8572] environments, 1645 SZTP-CSR [I-D.ietf-netconf-sztp-csr] describes the use of a CMP p10cr 1646 message as a form of certificate signing request (CSR) to optionally 1647 include in device bootstrapping to obtain an identity certificate as 1648 part of the onboarding information. Such a CSR is of form ietf-sztp- 1649 types:cmp-csr from module ietf-sztp-csr. The requirements given 1650 below on p10cr message MUST be adhered to. 1652 In this PKI management operation, the public key and all further 1653 certificate template data MUST be contained in the subjectPKInfo and 1654 other certificationRequestInfo fields of the PKCS#10 structure. 1656 The prerequisites are the same as given in Section 4.1.2. 1658 The message sequence for this PKI management operation is identical 1659 to that given in Section 4.1.2, with the following changes: 1661 1 The body of the first request and response MUST be p10cr and cp, 1662 respectively. 1664 2 The certReqId in the cp message MUST be -1. 1666 3 The caPubs field in the cp message SHOULD be absent. 1668 Detailed description of the p10cr message: 1670 Certification Request -- p10cr 1672 Field Value 1674 header 1675 -- As described in Section 3.1 1677 body 1678 -- The request of the EE for a new certificate using a PKCS#10 1679 -- certificate request 1680 p10cr REQUIRED 1681 certificationRequestInfo REQUIRED 1682 version REQUIRED 1683 -- MUST be 0 to indicate PKCS#10 V1.7 1684 subject REQUIRED 1685 -- The EE subject name MUST be carried in the subject field 1686 -- and/or the subjectAltName extension. 1687 -- If subject name is present only in the subjectAltName 1688 -- extension, then the subject field MUST be a NULL-DN 1689 subjectPKInfo REQUIRED 1690 algorithm REQUIRED 1691 -- MUST include the subject public key algorithm identifier 1692 subjectPublicKey REQUIRED 1693 -- MUST include the public key to be certified 1694 attributes OPTIONAL 1695 -- MAY include end-entity-specific X.509 extensions of the 1696 -- requested certificate like subject alternative name, 1697 -- key usage, and extended key usage 1698 -- The subjectAltName extension MUST be present if the EE 1699 -- subject name includes a subject alternative name. 1700 signatureAlgorithm REQUIRED 1701 -- The signature algorithm MUST be consistent with the 1702 -- subjectPKInfo field. 1703 signature REQUIRED 1704 -- MUST contain the self-signature for proof-of-possession 1706 protection REQUIRED 1707 -- As described for the underlying PKI management operation 1709 extraCerts REQUIRED 1710 -- As described for the underlying PKI management operation 1712 4.1.5. Requesting a certificate from a PKI with MAC-based protection 1714 This is a variant of the PKI management operations described in 1715 Section 4.1.1 to Section 4.1.4. It should be used by an EE to 1716 request a certificate of a new PKI in case it does not have a 1717 certificate to prove its identity to the target PKI, but has some 1718 secret information shared with the PKI management entity. Therefore, 1719 the request and response messages are MAC-protected using this shared 1720 secret information. The distribution of this shared secret is out of 1721 scope for this document. The PKI management entity checking the MAC- 1722 based protection SHOULD replace this protection according to 1723 Section 5.2.3 in case the next hop does not know the shared secret 1724 information. 1726 Note: The entropy of the shared secret information is crucial for the 1727 level of protection when using MAC-based protection. Further 1728 guidance is available in the security considerations of CMP updated 1729 by [I-D.ietf-lamps-cmp-updates]. 1731 Specific prerequisites augmenting the prerequisites in Section 3.4: 1733 * Rather than using private keys, certificates, and trust anchors, 1734 the EE and the PKI management entity MUST share secret 1735 information. 1737 Note: The shared secret information MUST be established out-of- 1738 band, e.g., by a service technician during initial local 1739 configuration. 1741 * When using the generalInfo field certProfile, the EE MUST know the 1742 identifier needed to indicate the requested certificate profile. 1744 The message sequence for this PKI management operation is identical 1745 to that given in Section 4.1.1, with the following changes: 1747 1 The protection of all messages MUST be MAC-based. 1749 2 The senderKID MUST contain a reference the recipient can use to 1750 identify the shared secret information used for the protection, 1751 e.g., the username of the EE. 1753 3 The extraCerts of all messages does not contain CMP protection 1754 certs and associated chains. 1756 See Section 6 of CMP Algorithms [I-D.ietf-lamps-cmp-algorithms] for 1757 details on message authentication code algorithms (MSG_MAC_ALG) to 1758 use. Typically, parameters are part of the protectionAlg field, 1759 e.g., used for key derivation, like a salt and an iteration count. 1760 Such fields SHOULD remain constant for message protection throughout 1761 this PKI management operation to reduce the computational overhead. 1763 4.1.6. Adding central key pair generation to a certificate request 1765 This is a variant of the PKI management operations described in 1766 Section 4.1.1 to Section 4.1.4 and the variant described in 1767 Section 4.1.5. It needs to be used in case an EE is not able to 1768 generate its new public-private key pair itself or central generation 1769 of the EE key material is preferred. It is a matter of the local 1770 implementation which PKI management entity will act as Key Generation 1771 Authority (KGA) and perform the key generation. This PKI management 1772 entity MUST use a certificate containing the additional extended key 1773 usage extension id-kp-cmKGA in order to be accepted by the EE as a 1774 legitimate key generation authority. 1776 As described in Section 5.3.1, the KGA can use one of the PKI 1777 management operations described in the sections above to request the 1778 certificate for this key pair on behalf of the EE. 1780 Generally speaking, in machine-to-machine scenarios it is strongly 1781 preferable to generate public-private key pairs locally at the EE. 1782 Together with proof-of-possession of the private key in the 1783 certificate request, this is advisable to make sure that the entity 1784 identified in the newly issued certificate is the only entity that 1785 knows the private key. 1787 Reasons for central key generation may include the following: 1789 * Lack of sufficient initial entropy. 1791 Note: Good random numbers are needed not only for key generation 1792 but also for session keys and nonces in any security protocol. 1793 Therefore, a decent security architecture should anyways support 1794 good random number generation on the EE side or provide enough 1795 initial entropy for the RNG seed to guarantee good pseudo-random 1796 number generation. Yet maybe this is not the case at the time of 1797 requesting an initial certificate during manufacturing. 1799 * Lack of computational resources, in particular for RSA key 1800 generation. 1802 Note: Since key generation could be performed in advance to the 1803 certificate enrollment communication, it is often not time 1804 critical. 1806 Note: As mentioned in Section 2, central key generation may be 1807 required in a push model, where the certificate response message is 1808 transferred by the PKI management entity to the EE without a previous 1809 request message. 1811 The EE requesting central key generation MUST omit the publicKey 1812 field from the certTemplate or, in case it has a preference on the 1813 key type to be generated, provide it in the algorithm sub-field and 1814 fill the subjectPublicKey sub-field with a zero-length BIT STRING. 1815 Both variants indicate to the PKI management entity that a new key 1816 pair shall be generated centrally on behalf of the EE. 1818 Note: As the protection of centrally generated keys in the response 1819 message has been extended to EncryptedKey by CMP Updates Section 2.7 1820 [I-D.ietf-lamps-cmp-updates], EnvelopedData is the preferred 1821 alternative to EncryptedValue. In CRMF Section 2.1.9 [RFC4211] the 1822 use of EncryptedValue has been deprecated in favor of the 1823 EnvelopedData structure. Therefore, this profile requires using 1824 EnvelopedData as specified in CMS Section 6 [RFC5652]. When 1825 EnvelopedData is to be used in a PKI management operation, CMP v3 1826 MUST be indicated in the message header already for the initial 1827 request message, see CMP Updates Section 2.19 and Section 2.20 1828 [I-D.ietf-lamps-cmp-updates]. 1830 +----------------------------------+ 1831 | EnvelopedData | 1832 | [RFC5652] section 6 | 1833 | +------------------------------+ | 1834 | | SignedData | | 1835 | | [RFC5652] section 5 | | 1836 | | +--------------------------+ | | 1837 | | | AsymmetricKeyPackage | | | 1838 | | | [RFC5958] | | | 1839 | | | +----------------------+ | | | 1840 | | | | privateKey | | | | 1841 | | | | OCTET STRING | | | | 1842 | | | +----------------------+ | | | 1843 | | +--------------------------+ | | 1844 | +------------------------------+ | 1845 +----------------------------------+ 1847 Figure 3: Encrypted private key container 1849 The PKI management entity delivers the private key in the privateKey 1850 field in the certifiedKeyPair structure of the response message also 1851 containing the newly issued certificate. 1853 The private key MUST be provided as an AsymmetricKeyPackage structure 1854 as defined in RFC 5958 [RFC5958]. 1856 This AsymmetricKeyPackage structure MUST be wrapped in a SignedData 1857 structure, as specified in CMS Section 5 [RFC5652] and [RFC8933], 1858 signed by the KGA generating the key pair. The signature MUST be 1859 performed using a private key related to a certificate asserting the 1860 extended key usage id-kp-cmKGA as described in CMP Updates 1861 Section 2.2 [I-D.ietf-lamps-cmp-updates] to demonstrate authorization 1862 to generate key pairs on behalf of an EE. The EE SHOULD validate the 1863 signer certificate contained in the SignedData structure and verify 1864 the presence of this extended key usage in the signer certificate. 1866 Note: When using password-based key management technique as described 1867 in Section 4.1.6.3 it may not be possible or meaningful to the EE to 1868 validate the KGA signature and the related certificate in the 1869 SignedData structure since shared secret information is used for 1870 initial authentication. In this case the EE MAY omit this 1871 validation. 1873 The SignedData structure MUST be wrapped in an EnvelopedData 1874 structure, as specified in CMS Section 6 [RFC5652], encrypting it 1875 using a newly generated symmetric content-encryption key. 1877 This content-encryption key MUST be securely provided as part of the 1878 EnvelopedData structure to the EE using one of three key management 1879 techniques. The choice of the key management technique to be used by 1880 the PKI management entity depends on the authentication mechanism the 1881 EE chose to protect the request message. See CMP Updates Section 2.7 1882 [I-D.ietf-lamps-cmp-updates] for more details on which key management 1883 technique to use. 1885 * Signature-based protection of the request message: 1887 - The content-encryption key SHALL be protected using the key 1888 agreement key management technique, see Section 4.1.6.1, if the 1889 certificate used by the EE for protecting the request message 1890 allows the key usage keyAgreement. If the certificate also 1891 allows the key usage keyEncipherment, the key transport key 1892 management technique SHALL NOT be used. 1894 - The content-encryption key SHALL be protected using the key 1895 transport key management technique, see Section 4.1.6.2, if the 1896 certificate used by the EE for protecting the respective 1897 request message allows the key usage keyEncipherment but not 1898 keyAgreement. 1900 * MAC-based protected of the request message: 1902 - The content-encryption key SHALL be protected using the 1903 password-based key management technique, see Section 4.1.6.3, 1904 if and only if the EE used MAC-based protection for the request 1905 message. 1907 If central key generation is supported, support of the key agreement 1908 key management technique is REQUIRED and support of key transport and 1909 password-based key management techniques are OPTION, for two reasons: 1910 The key agreement key management technique is supported by most 1911 asymmetric algorithms, while the key transport key management 1912 technique is supported only by a very few of them. The password- 1913 based key management technique shall only be used in combination with 1914 MAC-based protection, which is a sideline in this document. 1916 Specific prerequisites augmenting those of the respective certificate 1917 enrollment PKI management operations: 1919 * If signature-based protection is used, the EE MUST be able to 1920 authenticate and authorize the KGA, using suitable information, 1921 which includes a trust anchor. 1923 * If MAC-based protection is used, the KGA MUST also know the shared 1924 secret information to protect the encrypted transport of the newly 1925 generated key pair. Consequently, the EE can also authorize the 1926 KGA. 1928 * The PKI management entity MUST have a certificate containing the 1929 additional extended key usage extension id-kp-cmKGA for signing 1930 the SignedData structure containing the private key package. 1932 * For encrypting the SignedData structure a fresh content-encryption 1933 key to be used by the symmetric encryption algorithm MUST be 1934 generated with sufficient entropy. 1936 Note: The security strength of the protection of the generated 1937 private key should be similar or higher than the security strength 1938 of the generated private key. 1940 The detailed description of the privateKey field as follows: 1942 privateKey OPTIONAL 1943 -- MUST be an EnvelopedData structure as specified in CMS 1944 -- Section 6 [RFC5652] 1945 version REQUIRED 1946 -- MUST be 2 for recipientInfo type KeyAgreeRecipientInfo and 1947 -- KeyTransRecipientInfo 1948 -- MUST be 0 for recipientInfo type PasswordRecipientInfo 1949 recipientInfos REQUIRED 1950 -- MUST contain exactly one RecipientInfo, which MUST be 1951 -- kari of type KeyAgreeRecipientInfo (see section 4.1.6.1), 1952 -- ktri of type KeyTransRecipientInfo (see section 4.1.6.2), or 1953 -- pwri of type PasswordRecipientInfo (see section 4.1.6.3) 1954 encryptedContentInfo 1955 REQUIRED 1956 contentType REQUIRED 1957 -- MUST be id-signedData 1958 contentEncryptionAlgorithm 1959 REQUIRED 1960 -- MUST be the algorithm identifier of the algorithm used for 1961 -- content encryption 1962 -- The algorithm type MUST be a PROT_SYM_ALG as specified in 1963 -- RFC-CMP-Alg Section 5 1964 encryptedContent REQUIRED 1965 -- MUST be the SignedData structure as specified in CMS 1966 -- Section 5 [RFC5652] and [RFC8933] in encrypted form 1967 version REQUIRED 1968 -- MUST be 3 1969 digestAlgorithms 1970 REQUIRED 1971 -- MUST contain exactly one AlgorithmIdentifier element 1972 -- MUST be the algorithm identifier of the digest algorithm 1973 -- used for generating the signature and match the signature 1974 -- algorithm specified in signatureAlgorithm, see and [RFC8933] 1975 encapContentInfo 1976 REQUIRED 1977 -- MUST contain the content that is to be signed 1978 eContentType REQUIRED 1979 -- MUST be id-ct-KP-aKeyPackage as specified in [RFC5958] 1980 eContent REQUIRED 1981 -- MUST be of type AsymmetricKeyPackage and 1982 -- MUST contain exactly one OneAsymmetricKey element 1983 version REQUIRED 1984 -- MUST be 1 (indicating v2) 1985 privateKeyAlgorithm 1986 REQUIRED 1987 -- The privateKeyAlgorithm field MUST contain the algorithm 1988 -- identifier of the asymmetric key pair algorithm 1989 privateKey 1990 REQUIRED 1991 publicKey 1992 REQUIRED 1993 -- MUST contain the public key corresponding to the private key 1994 -- for simplicity and consistency with v2 of OneAsymmetricKey 1995 certificates REQUIRED 1996 -- MUST contain the certificate for the private key used to sign 1997 -- the signedData content, together with its chain 1998 -- The first certificate in this field MUST be the KGA 1999 -- certificate used for protecting this content 2000 -- Self-signed certificates SHOULD NOT be included and MUST NOT 2001 -- be trusted based on their inclusion in any case 2002 signerInfos REQUIRED 2003 -- MUST contain exactly one SignerInfo element 2004 version REQUIRED 2005 -- MUST be 3 2006 sid REQUIRED 2007 subjectKeyIdentifier 2008 REQUIRED 2009 -- MUST be the subjectKeyIdentifier of the KGA certificate 2010 digestAlgorithm 2011 REQUIRED 2012 -- MUST be the same as in digestAlgorithms 2013 signedAttrs REQUIRED 2014 -- MUST contain an id-contentType attribute containing the value 2015 -- id-ct-KP-aKeyPackage 2016 -- MUST contain an id-messageDigest attribute containing the 2017 -- message digest of eContent 2018 -- MAY contain an id-signingTime attribute containing the time 2019 -- of signature 2020 -- For details on the signed attributes see CMS Section 5.3 and 2021 -- Section 11 [RFC5652] and [RFC8933] 2022 signatureAlgorithm 2023 REQUIRED 2024 -- MUST be the algorithm identifier of the signature algorithm 2025 -- used for calculation of the signature bits 2026 -- The signature algorithm type MUST be a MSG_SIG_ALG as 2027 -- specified in RFC-CMP-Alg Section 3 and MUST be consistent 2028 -- with the subjectPublicKeyInfo field of the KGA certificate 2029 signature REQUIRED 2030 -- MUST be the digital signature of the encapContentInfo 2032 NOTE: As stated in Section 1.5, all fields of the ASN.1 syntax that 2033 are defined in RFC 5652 [RFC5652] but are not explicitly specified 2034 here SHOULD NOT be used. 2036 4.1.6.1. Using key agreement key management technique 2038 This variant can be applied in combination with the PKI management 2039 operations specified in Section 4.1.1 to Section 4.1.3 using 2040 signature-based protection of CMP messages. The EE certificate used 2041 for the signature-based protection of the request message MUST allow 2042 for the key usage "keyAgreement" and therefore, the related key pair 2043 MUST be used for establishment of the content-encryption key. For 2044 this key management technique the KeyAgreeRecipientInfo structure 2045 MUST be used in the contentInfo field. 2047 The KeyAgreeRecipientInfo structure included into the EnvelopedData 2048 structure is specified in CMS Section 6.2.2 [RFC5652]. 2050 The detailed description of the KeyAgreeRecipientInfo structure looks 2051 like this: 2053 kari REQUIRED 2054 -- MUST be a KeyAgreeRecipientInfo as specified in CMS Section 2055 -- 6.2.2 [RFC5652] 2056 version REQUIRED 2057 -- MUST be 3 2058 originator REQUIRED 2059 -- MUST contain the subjectKeyIdentifier of the certificate, 2060 -- and thereby identifies the sender's public key. 2061 -- MUST contain the same value as the senderKID in the 2062 -- message header 2063 ukm RECOMMENDED 2064 -- MUST be used when 1-pass ECMQV is used 2065 -- SHOULD be present to ensure uniqueness of the key 2066 -- encryption key 2067 keyEncryptionAlgorithm 2068 REQUIRED 2069 -- MUST be the algorithm identifier of the key agreement 2070 -- algorithm 2071 -- The algorithm type MUST be a KM_KA_ALG as specified in 2072 -- RFC-CMP-Alg Section 4.1 2073 -- The parameters field of the key agreement algorithm MUST 2074 -- contains the key wrap algorithm 2075 -- The algorithm type MUST be a KM_KW_ALG as specified in 2076 -- RFC-CMP-Alg Section 4.3 2077 recipientEncryptedKeys 2078 REQUIRED 2079 -- MUST contain exactly one RecipientEncryptedKey element 2080 rid REQUIRED 2081 -- MUST contain the rKeyId choice 2082 rKeyId REQUIRED 2083 subjectKeyIdentifier 2084 REQUIRED 2085 -- MUST contain the same value as the senderKID in the 2086 -- respective request message header 2087 encryptedKey 2088 REQUIRED 2089 -- MUST be the encrypted content-encryption key 2091 4.1.6.2. Using key transport key management technique 2093 This variant can be applied in combination with the PKI management 2094 operations specified in Section 4.1.1 to Section 4.1.3 using 2095 signature-based protection of CMP messages. The EE certificate used 2096 for the signature-based protection of the request message MUST allow 2097 for the key usage "keyEncipherment" and not for "keyAgreement". 2098 Therefore, the related key pair MUST be used for encipherment of the 2099 content-encryption key. For this key management technique, the 2100 KeyTransRecipientInfo structure MUST be used in the contentInfo 2101 field. 2103 The KeyTransRecipientInfo structure included into the EnvelopedData 2104 structure is specified in CMS Section 6.2.1 [RFC5652]. 2106 The detailed description of the KeyTransRecipientInfo structure looks 2107 like this: 2109 ktri REQUIRED 2110 -- MUST be a KeyTransRecipientInfo as specified in CMS 2111 -- Section 6.2.1 [RFC5652] 2112 version REQUIRED 2113 -- MUST be 2 2114 rid REQUIRED 2115 -- MUST contain the subjectKeyIdentifier choice 2116 subjectKeyIdentifier 2117 REQUIRED 2118 -- MUST contain the same value as the senderKID in the 2119 -- respective request message header 2120 keyEncryptionAlgorithm 2121 REQUIRED 2122 -- MUST be the algorithm identifier of the key transport 2123 -- algorithm 2124 -- The algorithm type MUST be a KM_KT_ALG as specified in 2125 -- RFC-CMP-Alg Section 4.2 2126 encryptedKey REQUIRED 2127 -- MUST be the encrypted content-encryption key 2129 4.1.6.3. Using password-based key management technique 2131 This variant can be applied in combination with the PKI management 2132 operation specified in Section 4.1.5 using MAC-based protection of 2133 CMP messages. The shared secret information used for the MAC-based 2134 protection MUST also be used for the encryption of the content- 2135 encryption key but with a different salt value applied in the key 2136 derivation algorithm. For this key management technique, the 2137 PasswordRecipientInfo structure MUST be used in the contentInfo 2138 field. 2140 Note: The entropy of the shared secret information is crucial for the 2141 level of protection when using a password-based key management 2142 technique. For centrally generated key pairs, the entropy of the 2143 shared secret information SHALL NOT be less than the security 2144 strength of the centrally generated key pair. Further guidance is 2145 available in Section 9. 2147 The PasswordRecipientInfo structure included into the EnvelopedData 2148 structure is specified in CMS Section 6.2.4 [RFC5652]. 2150 The detailed description of the PasswordRecipientInfo structure looks 2151 like this: 2153 pwri REQUIRED 2154 -- MUST be a PasswordRecipientInfo as specified in CMS 2155 -- Section 6.2.4 [RFC5652] 2156 version REQUIRED 2157 -- MUST be 0 2158 keyDerivationAlgorithm 2159 REQUIRED 2160 -- MUST be the algorithm identifier of the key derivation 2161 -- algorithm 2162 -- The algorithm type MUST be a KM_KD_ALG as specified in 2163 -- RFC-CMP-Alg Section 4.4 2164 keyEncryptionAlgorithm 2165 REQUIRED 2166 -- MUST be the algorithm identifier of the key wrap algorithm 2167 -- The algorithm type MUST be a KM_KW_ALG as specified in 2168 -- RFC-CMP-Alg Section 4.3 2169 encryptedKey REQUIRED 2170 -- MUST be the encrypted content-encryption key 2172 4.2. Revoking a certificate 2174 This PKI management operation should be used by an entity to request 2175 revocation of a certificate. Here the revocation request is used by 2176 an EE to revoke one of its own certificates. 2178 The revocation request message MUST be signed using the certificate 2179 that is to be revoked to prove the authorization to revoke. The 2180 revocation request message is signature-protected using this 2181 certificate. This requires, that the EE still possesses the private 2182 key. If this is not the case the revocation has to be initiated by 2183 other means, e.g., revocation by the RA as specified in 2184 Section 5.3.2. 2186 An EE requests the revocation of an own certificate at the CA that 2187 issued this certificate. The PKI management entity handles the 2188 request as described in Section 5.1.4 and responds with a message 2189 that contains the status of the revocation from the CA. 2191 Specific prerequisites augmenting the prerequisites in Section 3.4: 2193 * The certificate the EE wishes to revoke is not yet expired or 2194 revoked. 2196 Message flow: 2198 Step# EE PKI management entity 2199 1 format rr 2200 2 -> rr -> 2201 3 handle or forward rr 2202 4 format or receive rp 2203 5 <- rp <- 2204 6 handle rp 2206 For this PKI management operation, the EE MUST include exactly one 2207 RevDetails structure in the rr message body. In case no generic 2208 error occurred the response to the rr MUST be an rp message 2209 containing a single status field. 2211 Detailed message description: 2213 Revocation Request -- rr 2215 Field Value 2217 header 2218 -- As described in Section 3.1 2220 body 2221 -- The request of the EE to revoke its certificate 2222 rr REQUIRED 2223 -- MUST contain exactly one element of type RevDetails 2224 -- If more revocations are desired, further PKI management 2225 -- operations MUST be initiated 2226 certDetails REQUIRED 2227 -- MUST be present and is of type CertTemplate 2228 serialNumber REQUIRED 2229 -- MUST contain the certificate serialNumber attribute of the 2230 -- certificate to be revoked 2231 issuer REQUIRED 2232 -- MUST contain the issuer attribute of the certificate to be 2233 -- revoked 2234 crlEntryDetails REQUIRED 2235 -- MUST contain exactly one reasonCode of type CRLReason (see 2236 -- [RFC5280] section 5.3.1) 2237 -- If the reason for this revocation is not known or shall not 2238 -- be published the reasonCode MUST be 0 = unspecified 2240 protection REQUIRED 2241 -- As described in Section 3.2 and using the private key related 2242 -- to the certificate to be revoked 2244 extraCerts REQUIRED 2245 -- As described in Section 3.3 2247 Revocation Response -- rp 2249 Field Value 2251 header 2252 -- As described in Section 3.1 2254 body 2255 -- The responds of the PKI management entity to the request as 2256 -- appropriate 2257 rp REQUIRED 2258 status REQUIRED 2259 -- MUST contain exactly one element of type PKIStatusInfo 2260 status REQUIRED 2261 -- positive value allowed: "accepted" 2262 -- negative value allowed: "rejection" 2263 statusString OPTIONAL 2264 -- MAY be any human-readable text for debugging, logging or to 2265 -- display in a GUI 2266 failInfo OPTIONAL 2267 -- MAY be present if status is "rejection" 2268 -- MUST be absent if the status is "accepted" 2270 protection REQUIRED 2271 -- As described in section 3.2 2273 extraCerts REQUIRED 2274 -- As described in section 3.3 2276 4.3. Support messages 2278 The following support messages offer on demand in-band delivery of 2279 content relevant to the EE provided by a PKI management entity. CMP 2280 general messages and general response are used for this purpose. 2281 Depending on the environment, these requests may be answered by an RA 2282 or CA (see also Section 5.1.5). 2284 The general messages and general response messages contain 2285 InfoTypeAndValue structures. In addition to those infoType values 2286 defined in RFC 4210 [RFC4210] and CMP Updates 2287 [I-D.ietf-lamps-cmp-updates] further OIDs MAY be used to define new 2288 PKI management operations or new general-purpose support messages as 2289 needed in specific environments. 2291 The following contents are specified in this document: 2293 * Get CA certificates 2294 * Get root CA certificate update 2296 * Get certificate request template 2298 * Get new CRLs 2300 In the following the aspects common to all general messages (genm) 2301 and general response (genp) messages are described. 2303 Message flow: 2305 Step# EE PKI management entity 2306 1 format genm 2307 2 -> genm -> 2308 3 handle or forward genm 2309 4 format or receive genp 2310 5 <- genp <- 2311 6 handle genp 2313 Detailed message description: 2315 General Message -- genm 2317 Field Value 2319 header 2320 -- As described in Section 3.1 2322 body 2323 -- A request by the EE for information 2324 genm REQUIRED 2325 -- MUST contain exactly one element of type InfoTypeAndValue 2326 infoType REQUIRED 2327 -- MUST be the OID identifying one of the specific PKI 2328 -- management operations described below 2329 infoValue OPTIONAL 2330 -- MUST be as specified for the specific PKI management operation 2332 protection REQUIRED 2333 -- As described in Section 3.2 2335 extraCerts REQUIRED 2336 -- As described in Section 3.3 2338 General Response -- genp 2340 Field Value 2342 header 2343 -- As described in Section 3.1 2345 body 2346 -- The response of the PKI management entity providing 2347 -- information 2348 genp REQUIRED 2349 -- MUST contain exactly one element of type InfoTypeAndValue 2350 infoType REQUIRED 2351 -- MUST be the OID identifying the specific PKI management 2352 -- operation described below 2353 infoValue OPTIONAL 2354 -- MUST be as specified for the specific PKI management operation 2356 protection REQUIRED 2357 -- As described in Section 3.2 2359 extraCerts REQUIRED 2360 -- As described in Section 3.3 2362 4.3.1. Get CA certificates 2364 This PKI management operation can be used by an EE to request CA 2365 certificates from the PKI management entity. 2367 An EE requests CA certificates, e.g., for chain construction, from an 2368 PKI management entity by sending a general message with OID id-it- 2369 caCerts as specified in CMP Updates Section 2.13 2370 [I-D.ietf-lamps-cmp-updates]. The PKI management entity responds 2371 with a general response with the same OID that either contains a 2372 SEQUENCE of certificates populated with the available intermediate 2373 and issuing CA certificates or with no content in case no CA 2374 certificate is available. 2376 No specific prerequisites apply in addition to those specified in 2377 Section 3.4. 2379 The message sequence for this PKI management operation is as given 2380 above, with the following specific content: 2382 1 the infoType OID to use is id-it-caCerts 2384 2 the infoValue of the request MUST be absent 2386 3 if present, the infoValue of the response MUST contain a sequence 2387 of certificates 2389 The infoValue field of the general response containing the id-it- 2390 caCerts OID looks like this: 2392 infoValue OPTIONAL 2393 -- MUST be absent if no CA certificate is available 2394 -- MUST be present if CA certificates are available 2395 -- MUST be a sequence of CMPCertificate 2397 4.3.2. Get root CA certificate update 2399 This PKI management operation can be used by an EE to request an 2400 updated root CA Certificate as described in Section 4.4 of RFC 4210 2401 [RFC4210]. 2403 An EE requests an update of a root CA certificate from the PKI 2404 management entity by sending a general message with OID id-it- 2405 rootCaCert, which SHOULD include the old root CA certificate in the 2406 message body, as specified in CMP Updates Section 2.14 2407 [I-D.ietf-lamps-cmp-updates]. The PKI management entity responds 2408 with a general response with OID id-it-rootCaKeyUpdate that either 2409 contains the update of the root CA certificate consisting of up to 2410 three certificates, or with no content in case no update is 2411 available. 2413 Note: This mechanism may also be used to update trusted non-root 2414 certificates, i.e., trusted intermediate CA or issuing CA 2415 certificates. 2417 The newWithNew certificate is the new root CA certificate and is 2418 REQUIRED to be present if available. The newWithOld certificate is 2419 REQUIRED to be present in the response message because it is needed 2420 for the receiving entity trusting the old root CA certificate to gain 2421 trust in the new root CA certificate. The oldWithNew certificate is 2422 OPTIONAL because it is only needed in rare scenarios where entities 2423 do not already trust the old root CA. 2425 No specific prerequisites apply in addition to those specified in 2426 Section 3.4. 2428 The message sequence for this PKI management operation is as given 2429 above, with the following specific content: 2431 1 the infoType OID to use is id-it-rootCaCert in the request and id- 2432 it-rootCaKeyUpdate in the response 2434 2 the infoValue of the request SHOULD contain the root CA 2435 certificate the update is requested for 2437 3 if present, the infoValue of the response MUST be a 2438 RootCaKeyUpdateContent structure 2440 The infoValue field of the general request containing the id-it- 2441 rootCaCert OID looks like this: 2443 infoValue RECOMMENDED 2444 -- MUST contain the root CA certificate to be updated, if 2445 -- available 2447 The infoValue field of the general response containing the id-it- 2448 rootCaKeyUpdate OID looks like this: 2450 infoValue OPTIONAL 2451 -- MUST be absent if no update of the root CA certificate is 2452 -- available 2453 -- MUST be present if an update of the root CA certificate 2454 -- is available and MUST be of type RootCaKeyUpdateContent 2455 newWithNew REQUIRED 2456 -- MUST be present if infoValue is present 2457 -- MUST contain the new root CA certificate 2458 newWithOld REQUIRED 2459 -- MUST be present if infoValue is present 2460 -- MUST contain a certificate containing the new public 2461 -- root CA key signed with the old private root CA key 2462 oldWithNew OPTIONAL 2463 -- MAY be present if infoValue is present 2464 -- MUST contain a certificate containing the old public 2465 -- root CA key signed with the new private root CA key 2467 4.3.3. Get certificate request template 2469 This PKI management operation can be used by an EE to request a 2470 template with parameters for future certificate requests. 2472 An EE requests certificate request parameters from the PKI management 2473 entity by sending a general message with OID id-it-certReqTemplate as 2474 specified in CMP Updates Section 2.15 [I-D.ietf-lamps-cmp-updates]. 2475 The EE MAY indicate the certificate profile to use in the id-it- 2476 certProfile extension of the generalInfo field in the PKIHeader of 2477 the general message as described in Section 3.1. The PKI management 2478 entity responds with a general response with the same OID that either 2479 contains requirements on the certificate request template, or with no 2480 content in case no specific requirements are imposed by the PKI. The 2481 CertReqTemplateValue contains requirements on certificate fields and 2482 extensions in a certTemplate. Optionally it contains a keySpec field 2483 containing requirements on algorithms acceptable for key pair 2484 generation. 2486 The EE SHOULD follow the requirements from the received CertTemplate, 2487 by including in the certificate requests all the fields requested, 2488 taking over all the field values provided and filling in any 2489 remaining fields values. The EE SHOULD NOT add further fields, name 2490 components, and extensions or their (sub-)components. 2492 Note: We deliberately do not use "MUST" or "MUST NOT" here in order 2493 to allow more flexibility in case the rules given here are not 2494 sufficient for specific scenarios. The EE can populate the 2495 certificate request as wanted and ignore any of the requirements 2496 contained in the CertReqTemplateValue. On the other hand, a PKI 2497 management entity is free to ignore or replace any parts of the 2498 content of the certificate request provided by the EE. The 2499 CertReqTemplate PKI management operation offers means to ease a joint 2500 understanding which fields and/or which field values should be used. 2501 An example is provided in Appendix A. 2503 In case a field of type Name, e.g., subject, is present in the 2504 CertTemplate but has the value NULL-DN (i.e., has an empty list of 2505 RDN components), the field SHOULD be included in the certificate 2506 request and filled with content provided by the EE. Similarly, in 2507 case an X.509v3 extension is present but its extnValue is empty, this 2508 means that the extension SHOULD be included and filled with content 2509 provided by the EE. In case a Name component, for instance a common 2510 name or serial number, is given but has an empty string value, the EE 2511 SHOULD fill in a value. Similarly, in case an extension has sub- 2512 components (e.g., an IP address in a SubjectAltName field) with empty 2513 value, the EE SHOULD fill in a value. 2515 The EE MUST ignore (i.e., not include and fill in) empty fields, 2516 extensions, and sub-components that it does not understand or does 2517 not know suitable values to be filled in. 2519 The publicKey field of type SubjectPublicKeyInfo in the CertTemplate 2520 of the CertReqTemplateValue MUST be omitted. In case the PKI 2521 management entity wishes to make stipulation on algorithms the EE may 2522 use for key generation, this MUST be specified using the keySpec 2523 field as specified in CMP Updates Section 2.15 2524 [I-D.ietf-lamps-cmp-updates]. 2526 The keySpec field, if present, specifies the public key types 2527 optionally with parameters, and/or RSA key lengths for which a 2528 certificate may be requested. 2530 The value of a keySpec element with the OID id-regCtrl-algId, as 2531 specified in CMP Updates Section 2.15 [I-D.ietf-lamps-cmp-updates], 2532 MUST be of type AlgorithmIdentifier and give an algorithm other than 2533 RSA. For EC keys the curve information MUST be specified as 2534 described in the respective standard documents. 2536 The value of a keySpec element with the OID id-regCtrl-rsaKeyLen, as 2537 specified in CMP Updates Section 2.15 [I-D.ietf-lamps-cmp-updates], 2538 MUST be a positive integer value and give an RSA key length. 2540 In the CertTemplate of the CertReqTemplateValue the serialNumber, 2541 signingAlg, issuerUID, and subjectUID fields MUST be omitted. 2543 Specific prerequisites augmenting the prerequisites in Section 3.4: 2545 * When using the generalInfo field certProfile, the EE MUST know the 2546 identifier needed to indicate the requested certificate profile. 2548 The message sequence for this PKI management operation is as given 2549 above, with the following specific content: 2551 1 the infoType OID to use is id-it-certReqTemplate 2553 2 the id-it-certProfile generalInfo field in the header of the 2554 request MAY contain the name of the requested certificate request 2555 template 2557 3 the infoValue of the request MUST be absent 2559 4 if present, the infoValue of the response MUST be a 2560 CertReqTemplateValue containing a CertTemplate structure and an 2561 optional keySpec field 2563 The infoValue field of the general response containing the id-it- 2564 certReqTemplate OID looks like this: 2566 InfoValue OPTIONAL 2567 -- MUST be absent if no requirements are available 2568 -- MUST be present if the PKI management entity has any 2569 -- requirements on the contents of the certificate template 2570 certTemplate REQUIRED 2571 -- MUST be present if infoValue is present 2572 -- MUST contain the required CertTemplate structure elements 2573 -- The SubjectPublicKeyInfo field MUST be absent 2574 keySpec OPTIONAL 2575 -- MUST be absent if no requirements on the public key are 2576 -- available 2577 -- MUST be present if the PKI management entity has any 2578 -- requirements on the keys generated 2579 -- MUST contain one AttributeTypeAndValue per supported 2580 -- algorithm with attribute id-regCtrl-algId or 2581 -- id-regCtrl-rsaKeyLen 2583 4.3.4. CRL update retrieval 2585 This PKI management operation can be used by an EE to request a new 2586 CRL. If a CA offers methods to access a CRL, it may include CRL 2587 distribution points or authority information access extensions as 2588 specified in RFC 5280 [RFC5280] into the issued certificates. In 2589 addition, CMP offers CRL provisioning functionality as part of the 2590 PKI management operation. 2592 An EE requests a CRL update from the PKI management entity by sending 2593 a general message with OID id-it-crlStatusList. The EE MUST include 2594 the CRL source identifying the requested CRL and, if available, the 2595 thisUpdate time of the most current CRL instance it already has, as 2596 specified in CMP Updates Section 2.16 [I-D.ietf-lamps-cmp-updates]. 2597 The PKI management entity MUST respond with a general response with 2598 OID id-it-crls. If no thisUpdate value was given by the EE, the PKI 2599 management entity MUST return the latest CRL available. If a 2600 thisUpdate value was given, the PKI management entity MUST return the 2601 latest available CRL in case this CRL is more recent, otherwise the 2602 infoValue in the response message MUST be absent. 2604 The EE MUST identify the requested CRL either by its CRL distribution 2605 point name or issuer name. The CRL distribution point name can 2606 either be provided form the CRL distribution points extension of the 2607 certificate to be validated or from the issuing distribution point 2608 extension from the CRL to be updated. If no CRL distribution name is 2609 available to identify the CRL, the EE can use the issuer name either 2610 from the certificate to be validated or from the CRL to be updated. 2612 The PKI management entity SHOULD treat a CRL distribution point name 2613 as an internal pointer to identify a CRL for which is available at 2614 the PKI management entity directly. It is not intended as a way to 2615 fetch an arbitrary CRL from an external location. 2617 In addition to the prerequisites specified in Section 3.4, the EE 2618 MUST know which CRL to request. 2620 Note: If the EE does not want to request a specific CRL it MAY use 2621 instead a general message with OID id-it-currentCrl as specified in 2622 RFC 4210 Section 5.3.19.6 [RFC4210]. 2624 The message sequence for this PKI management operation is as given 2625 above, with the following specific content: 2627 1 the infoType OID to use is id-it-crlStatusList in the request and 2628 id-it-crls in the response 2630 2 the infoValue of the request MUST be present and contain a 2631 CRLStatus structure 2633 3 if present, the infoValue of the response MUST contain a CRL 2635 The infoValue field of the general request containing the id-it- 2636 crlStatusList OID looks like this: 2638 CRLSource REQUIRED 2639 -- MUST contain exactly one CRLSource structure 2640 -- MUST contain the dpn choice of type DistributionPointName if 2641 -- the CRL distribution point name is available 2642 -- Otherwise, MUST contain the issuer choice identifying the CA 2643 -- that issues the CRL. It MUST contain the issuer DN in the 2644 -- directoryName field of a GeneralName element. 2645 thisUpdate OPTIONAL 2646 -- SHOULD contain the thisUpdate field of the latest CRL form 2647 -- the issuer specified in the given dpn or issuer field, 2648 -- in case such a CRL is already known by the EE 2650 The infoValue field of the general response containing the id-it-crls 2651 OID looks like this: 2653 infoValue OPTIONAL 2654 -- MUST be absent if no CRL to be returned is available 2655 -- MUST contain one CRL update from the referenced source, if a 2656 -- thisUpdate value was not given or a more recent CRL is 2657 -- available 2659 4.4. Handling delayed delivery 2661 This is a variant of all PKI management operations described in this 2662 document. It is initiated in case a PKI management entity cannot 2663 respond to a request message in a timely manner, typically due to 2664 offline or asynchronous upstream communication, or due to delays in 2665 handling the request. The polling mechanism has been specified in 2666 RFC 4210 Section 5.3.22 [RFC4210] and updated by 2667 [I-D.ietf-lamps-cmp-updates]. 2669 Depending on the PKI architecture, the entity initiating delayed 2670 delivery is not necessarily the PKI management entity directly 2671 addressed by the EE. 2673 When initiating delayed delivery of a message received from an EE, 2674 the PKI management entity MUST respond with an ip/cp/kup/error 2675 message including the status "waiting". On receiving this response, 2676 the EE MUST store in its transaction context the senderNonce of the 2677 preceding request message because this value will be needed for 2678 checking the recipNonce of the final response to be received after 2679 polling. It sends a poll request with certReqId 0 if referring to 2680 the CertResponse element contained in the ip/cp/kup message, else -1 2681 to refer to the whole message. In case the final response is not yet 2682 available, the PKI management entity that initiated the delayed 2683 delivery MUST answer with a poll response, with the same certReqId. 2684 The included checkAfter time value indicates the minimum number of 2685 seconds that SHOULD elapse before the EE sends a new pollReq message 2686 to the PKI management entity. This is repeated until a final 2687 response is available or any party involved gives up on the current 2688 PKI management operation, i.e., a timeout occurs. 2690 When the PKI management entity that initiated delayed delivery can 2691 provide the final response for the original request message of the 2692 EE, it MUST send this response to the EE. Using this response, the 2693 EE can continue the current PKI management operation as usual. 2695 No specific prerequisites apply in addition to those of the 2696 respective PKI management operation. 2698 Message flow: 2700 Step# EE PKI management entity 2701 1 format request 2702 message 2703 2 -> request -> 2704 3 handle or forward 2705 request 2706 4 format ip/cp/kup/error 2707 with status "waiting" 2708 response in case no 2709 immediate final response 2710 is available, 2711 5 <- ip/cp/kup/error <- 2712 6 handle 2713 ip/cp/kup/error 2714 with status 2715 "waiting" 2717 -------------------------- start polling -------------------------- 2719 7 format pollReq 2720 8 -> pollReq -> 2721 9 handle or forward pollReq 2722 10 in case the final response 2723 for the original request 2724 is available, continue 2725 with step 14 2726 otherwise, format or 2727 receive pollRep with 2728 checkAfter value 2729 11 <- pollRep <- 2730 12 handle pollRep 2731 13 let checkAfter 2732 time elapse and 2733 continue with 2734 step 7 2736 ----------------- end polling, continue as usual ------------------ 2738 14 format or receive 2739 final response on 2740 original request 2741 15 <- response <- 2742 16 handle final 2743 response 2745 Detailed description of the ip/cp/kup/error response, pollReq, and 2746 pollRep: 2748 Response with status "waiting" -- ip/cp/kup/error 2750 Field Value 2752 header 2753 -- As described in Section 3.1 2755 body 2756 -- as described for the respective PKI management operation, with 2757 -- the following adaptations: 2758 status REQUIRED -- in case of ip/cp/kup 2759 pKIStatusInfo REQUIRED -- in case of error response 2760 -- PKIStatusInfo structure MUST be present 2761 status REQUIRED 2762 -- MUST be status "waiting" 2763 statusString OPTIONAL 2764 -- MAY be any human-readable text for debugging, logging or to 2765 -- display in a GUI 2766 failInfo PROHIBITED 2768 protection REQUIRED 2769 -- As described in Section 3.2 2771 extraCerts OPTIONAL 2772 -- As described in Section 3.3 2774 Polling Request -- pollReq 2776 Field Value 2778 header 2779 -- As described in Section 3.1 2781 body 2782 -- The message of the EE asking for the final response or for a 2783 -- time to check again 2784 pollReq REQUIRED 2785 certReqId REQUIRED 2786 -- MUST be 0 if referring to a CertResponse element, else -1 2788 protection REQUIRED 2789 -- As described in Section 3.2 2790 -- MUST use the same credentials as in the first request message 2791 -- of the PKI management operation 2793 extraCerts RECOMMENDED 2794 -- As described in Section 3.3 2795 -- MAY be omitted if the message size is critical and 2796 -- the PKI management entity caches the extraCerts from the 2797 -- first request message of the PKI management operation 2799 Polling Response -- pollRep 2801 Field Value 2803 header 2804 -- As described in Section 3.1 2806 body 2807 -- The message indicates the delay after which the EE SHOULD 2808 -- send another pollReq message for this transaction 2809 pollRep REQUIRED 2810 certReqId REQUIRED 2811 -- MUST be 0 if referring to a CertResponse element, else -1 2812 checkAfter REQUIRED 2813 -- time in seconds to elapse before a new pollReq SHOULD be sent 2814 reason OPTIONAL 2815 -- MAY be any human-readable text for debugging, logging or to 2816 -- display in a GUI 2818 protection REQUIRED 2819 -- As described in Section 3.2 2820 -- MUST use the same credentials as in the first response 2821 -- message of the PKI management operation 2823 extraCerts RECOMMENDED 2824 -- As described in Section 3.3 2825 -- MAY be omitted if the message size is critical and the EE has 2826 -- cached the extraCerts from the first response message of 2827 -- the PKI management operation 2829 Final response – any type of response message 2831 Field Value 2833 header 2835 -- MUST be the header as described for the response message 2836 -- of the respective PKI management operation 2838 body 2839 -- The response of the PKI management entity to the initial 2840 -- request as described in the respective PKI management 2841 -- operation 2843 protection REQUIRED 2844 -- MUST be as described for the response message of the 2845 -- respective PKI management operation 2847 extraCerts REQUIRED 2848 -- MUST be as described for the response message of the 2849 -- respective PKI management operation 2851 5. PKI management entity operations 2853 This section focuses on request processing by a PKI management 2854 entity. Depending on the network and PKI solution design, this can 2855 be an RA or CA, any of which may include protocol conversion or 2856 central key generation (i.e., acting as a KGA). 2858 A PKI management entity may directly respond to request messages from 2859 downstream and report errors. In case the PKI management entity is 2860 an RA it typically forwards the received request messages upstream 2861 after checking them and forwards respective response messages 2862 downstream. Besides responding to messages or forwarding them, a PKI 2863 management entity may request or revoke certificates on behalf of 2864 EEs. A PKI management entity may also need to manage its own 2865 certificates and thus act as an EE using the PKI management 2866 operations specified in Section 4. 2868 5.1. Responding to requests 2870 The PKI management entity terminating the PKI management operation at 2871 CMP level MUST respond to all received requests by returning a 2872 related CMP response message or an error. Any intermediate PKI 2873 management entity MAY respond depending on the PKI configuration and 2874 policy. 2876 In addition to the checks described in Section 3.5, the responding 2877 PKI management entity SHOULD check that a request that initiates a 2878 new PKI management operation does not use a transactionID that is 2879 currently in use. The failInfo bit value to use on reporting failure 2880 as described in Section 3.6.4 is transactionIdInUse. If any of these 2881 verification steps or any of the essential checks described in the 2882 following subsections fails, the PKI management entity MUST proceed 2883 as described in Section 3.6. 2885 The responding PKI management entity SHOULD copy the sender field of 2886 the request to the recipient field of the response, MUST copy the 2887 senderNonce of the request to the recipNonce of the response, and 2888 MUST use the same transactionID for the response. 2890 5.1.1. Responding to a certificate request 2892 An ir/cr/p10cr/kur message is used to request a certificate as 2893 described in Section 4.1. The responding PKI management entity MUST 2894 proceed as follows unless it initiates delayed delivery as described 2895 in Section 5.1.2. 2897 The PKI management entity SHOULD check the message body according to 2898 the applicable requirements from Section 4.1. Possible failInfo bit 2899 values used for error reporting in case a check failed include 2900 badCertId and badCertTemplate. It MUST verify the presence and value 2901 of the proof-of-possession (failInfo bit: badPOP), unless central key 2902 generation is requested. In case the special POP value "raVerified" 2903 is given, it SHOULD check that the request message was signed using a 2904 certificate containing the cmcRA extended key usage (failInfo bit: 2905 notAuthorized). The PKI management entity SHOULD perform also any 2906 further checks on the certTemplate contents (failInfo: 2907 badCertTemplate) according to any applicable PKI policy and 2908 certificate profile. 2910 If the requested certificate is available, the PKI management entity 2911 MUST respond with a positive ip/cp/kup message as described in 2912 Section 4.1. 2914 Note: If central key generation is performed by the responding PKI 2915 management entity, the responding PKI management entity MUST include 2916 in the response the privateKey field as specified in Section 4.1.6. 2917 It may have issued the certificate for the newly generated key pair 2918 itself if it is a CA, or have requested the certificate on behalf of 2919 the EE as described in Section 5.3.1, or have received it by other 2920 means from a CA. 2922 The prerequisites of the respective PKI management operation as 2923 specified in Section 4.1 apply. 2925 Note: If the EE requested omission of the certConf message, the PKI 2926 management entity SHOULD handle it as described in Section 4.1.1 and 2927 therefore MAY grant this by including the implicitConfirm extension 2928 in the response header. 2930 5.1.2. Initiating delayed delivery 2932 This functional extension can be used by a PKI management entity in 2933 case the response to a request takes longer than usual. In this case 2934 the PKI management entity MUST completely validate the request as 2935 usual and then start preparing the response or forward the request 2936 further upstream as soon as possible. In the meantime, it MUST 2937 respond with an ip/cp/kup/error message including the status 2938 "waiting" and handle subsequent polling as described in Section 4.4. 2940 Note: Typically, as stated in Section 5.2.3, an intermediate PKI 2941 management entity should not change the sender and recipient nonces 2942 even in case it modifies a request or a response message. In the 2943 special case of delayed delivery initiated by an intermediate PKI 2944 management entity, there is an exception. Between the EE and this 2945 PKI management entity, pollReq and pollRep messages are exchanged 2946 handling the nonces as usual. Yet when the final response from 2947 upstream has arrived at the PKI management entity, this response 2948 contains the recipNonce copied (as usual) from the senderNonce in the 2949 original request message. The PKI management entity that initiated 2950 the delayed delivery may replace the recipNonce in the response 2951 message with the senderNonce of the last received pollReq because the 2952 downstream entities, including the EE, might expect it in this way. 2953 Yet the check specified in Section 3.5 allows to alternatively use 2954 the senderNonce of the original request. 2956 No specific prerequisites apply in addition to those of the 2957 respective PKI management operation. 2959 5.1.3. Responding to a confirmation message 2961 A PKI management entity MUST handle a certConf message if it has 2962 responded before with a positive ip/cp/kup message not granting 2963 implicit confirmation. It SHOULD check the message body according to 2964 the requirements given in Section 4.1.1 (failInfo bit: badCertId) and 2965 react as described there. 2967 The prerequisites of the respective PKI management operation as 2968 specified in Section 4.1 apply. 2970 5.1.4. Responding to a revocation request 2972 An rr message is used to request revocation of a certificate. The 2973 responding PKI management entity SHOULD check the message body 2974 according to the requirements in Section 4.2. It MUST make sure that 2975 the referenced certificate exists (failInfo bit: badCertId), has been 2976 issued by the addressed CA, and is not already expired or revoked 2977 (failInfo bit: certRevoked). On success it MUST respond with a 2978 positive rp message as described in Section 4.2. 2980 No specific prerequisites apply in addition to those specified in 2981 Section 3.4. 2983 5.1.5. Responding to a support message 2985 A genm message is used to retrieve extra content. The responding PKI 2986 management entity SHOULD check the message body according to the 2987 applicable requirements in Section 4.3 and perform any further checks 2988 depending on the PKI policy. On success it MUST respond with a genp 2989 message as described there. 2991 Note: The responding PKI management entity may generate the response 2992 from scratch or reuse the contents of previous responses. Therefore, 2993 it may be worth caching the body of the response message as long as 2994 the contained information is still valid, such that further requests 2995 for the same contents can be answered immediately. 2997 No specific prerequisites apply in addition to those specified in 2998 Section 3.4. 3000 5.2. Forwarding messages 3002 In case the PKI solution consists of intermediate PKI management 3003 entities (i.e., LRA or RA), each CMP request message coming from an 3004 EE or any other downstream PKI management entity SHOULD be forwarded 3005 to the next (upstream) PKI management entity as described in this 3006 section and otherwise MUST be answered as described in Section 5.1. 3007 Any received response message or error message MUST be forwarded to 3008 the next (downstream) PKI entity. 3010 In addition to the checks described in Section 3.5, the forwarding 3011 PKI management entity MAY verify the proof-of-possession for 3012 ir/cr/p10cr/kur messages. If one of these verification procedures 3013 fails, the RA proceeds as described in Section 3.6. 3015 A PKI management entity SHOULD NOT change the received message unless 3016 necessary. The PKI management entity SHOULD only update the message 3017 protection and the certificate template in a certificate request 3018 message if this is technically necessary. Concrete PKI system 3019 specifications may define in more detail when to do so. 3021 This is particularly relevant in the upstream communication of a 3022 request message. 3024 Each forwarding PKI management entity has one or more 3025 functionalities. It may 3027 * verify the identities of EEs and make authorization decisions for 3028 certification request processing based on specific knowledge of 3029 the local setup, e.g., by consulting an inventory or asset 3030 management system, 3032 * add or modify fields of certificate request messages, 3034 * store data from a message in a database for later usage or audit 3035 purposes, 3037 * provide traversal of a network boundary, 3039 * replace a MAC-based protection by a signature-based protection 3040 that can be verified also further upstream, 3042 * double-check if the messages transferred back and forth are 3043 properly protected and well-formed, 3045 * provide an authentic indication that it has performed all required 3046 checks, 3048 * initiate a delayed delivery due to delays transferring messages or 3049 handling requests, or 3051 * collect messages from multiple RAs and forward them jointly. 3053 The decision if a message should be forwarded 3055 * unchanged with the original protection, 3057 * unchanged with a new protection, or 3059 * changed with a new protection 3061 depends on the PKI solution design and the associated security policy 3062 (CP/CPS [RFC3647]). 3064 A PKI management entity MUST replace or add a protection of a message 3065 if it 3067 * needs to securely indicate that it has done checks or validations 3068 on the message to one of the next (upstream) PKI management entity 3069 or 3071 * needs to protect the message using a key and certificate from a 3072 different PKI. 3074 A PKI management entity MUST replace a protection of a message if it 3076 * performs changes to the header or the body of the message or 3078 * needs to convert from or to a MAC-based protection. 3080 This is particularly relevant in the upstream communication of 3081 certificate request messages. 3083 Note that the message protection covers only the header and the body 3084 and not the extraCerts. The PKI management entity MAY change the 3085 extraCerts in any of the following message adaptations, e.g., to 3086 sort, add, or delete certificates to support subsequent PKI entities. 3087 This may be particularly helpful to augment upstream messages with 3088 additional certificates or to reduce the number of certificates in 3089 downstream messages when forwarding to constrained devices. 3091 5.2.1. Not changing protection 3093 This variant means that a PKI management entity forwards a CMP 3094 message without changing the header, body, or protection. In this 3095 case the PKI management entity acts more like a proxy, e.g., on a 3096 network boundary, implementing no specific RA-like security 3097 functionality that requires an authentic indication to the PKI. 3098 Still the PKI management entity might implement checks that result in 3099 refusing to forward the request message and instead responding as 3100 specified in Section 3.6. 3102 This variant of forwarding a message or the one described in 3103 Section 5.2.2.1 SHOULD be used for kur messages and for central key 3104 generation. 3106 No specific prerequisites apply in addition to those specified in 3107 Section 3.4. 3109 5.2.2. Adding protection and batching of messages 3111 This variant of forwarding a message means that a PKI management 3112 entity adds another protection to PKI management messages before 3113 forwarding them. 3115 The nested message is a PKI management message containing a 3116 PKIMessages sequence as its body containing one or more CMP messages. 3118 As specified in the updated Section 5.1.3.4 of RFC 4210 [RFC4210] 3119 (see also CMP Updates Section 2.6 [I-D.ietf-lamps-cmp-updates]) there 3120 are various use cases for adding another protection by a PKI 3121 management entity. Specific procedures are described in more detail 3122 in the following sections. 3124 Detailed message description: 3126 Nested Message - nested 3128 Field Value 3130 header 3131 -- As described in Section 3.1 3133 body 3134 -- Container to provide additional protection to original 3135 -- messages and to bundle request messages or alternatively 3136 -- response messages 3137 PKIMessages REQUIRED 3138 -- MUST be a sequence of one or more CMP messages 3140 protection REQUIRED 3141 -- As described in Section 3.2 using the CMP protection key of 3142 -- the PKI management entity 3144 extraCerts REQUIRED 3145 -- As described in Section 3.3 3147 5.2.2.1. Adding protection to a request message 3149 A PKI management entity may authentically indicate successful 3150 validation and approval of a request message by adding an extra 3151 signature to the original message. 3153 By adding a protection using its own CMP protecting key the PKI 3154 management entity provides a proof of verifying and approving the 3155 message as described above. Thus, the PKI management entity acts as 3156 an actual Registration Authority (RA), which implements important 3157 security functionality of the PKI. Applying an additional protection 3158 is specifically relevant when forwarding a message that requests a 3159 certificate update or central key generation. This is because the 3160 original protection of the EE must be preserved while adding an 3161 indication of approval by the PKI management entity. 3163 The PKI management entity wrapping the original request message in a 3164 nested message structure MUST take over the recipient, recipNonce, 3165 and transactionID of the original message to the nested message and 3166 apply signature-based protection. The additional signature serves as 3167 proof of verification and authorization by this PKI management 3168 entity. 3170 The PKI management entity receiving such a nested message that 3171 contains a single request message MUST validate the additional 3172 protection signature on the nested message and check the 3173 authorization for the approval it implies. 3175 The PKI management entity responding to the request contained in the 3176 nested message sends the response message as described in 3177 Section 5.1, without wrapping it in a nested message. 3179 Note: This form of nesting messages is characterized by the fact that 3180 the transactionID in the header of the nested message is the same as 3181 the one used in the included message. 3183 Specific prerequisites augmenting the prerequisites in Section 3.4: 3185 * The PKI management entity MUST have the authorization to perform 3186 the validation and approval of the respective request according to 3187 the PKI policies. 3189 Message flow: 3191 Step# PKI management entity PKI management entity 3192 1 format nested 3193 2 -> nested -> 3194 3 handle or forward nested 3195 4 format or receive response 3196 5 <- response <- 3197 6 forward response 3199 5.2.2.2. Batching messages 3201 A PKI management entity MAY bundle any number of PKI management 3202 messages for batch processing or to transfer a bulk of PKI management 3203 messages using the nested message structure. In this use case, 3204 nested messages are used both on the upstream interface towards the 3205 next PKI management entity and on the downstream interface from the 3206 PKI management entity towards the EE. 3208 This PKI management operation is typically used on the interface 3209 between an LRA and an RA to bundle several messages for offline 3210 delivery. In this case the LRA needs to initiate delayed delivery as 3211 described in Section 5.1.2. If the RA needs different routing 3212 information per nested PKI management message a suitable mechanism 3213 may need to be implemented. Since this mechanism strongly depends on 3214 the requirements of the target architecture, it is out of scope of 3215 this document. 3217 A nested message containing requests is generated locally at the PKI 3218 management entity. For the upstream nested message, the PKI 3219 management entity acts as a protocol end point and therefore a fresh 3220 transactionID and a fresh senderNonce MUST be used in the header of 3221 the nested message. An upstream nested message may contain request 3222 messages, e.g., ir, cr, p10cr, kur, pollReq, certConf, rr, or genm. 3224 While building the upstream nested message the PKI management entity 3225 SHOULD store the sender, transactionID, and senderNonce fields of all 3226 bundled messages together with the transactionID of the upstream 3227 nested message. 3229 Such an upstream nested message is sent to the next PKI management 3230 entity. The upstream PKI management entity that unbundles it MUST 3231 handle each of the included request messages as usual. It MUST 3232 answer with a downstream nested message. This downstream nested 3233 message MUST use the transactionID of the upstream nested message and 3234 return the senderNonce of the upstream nested message as the 3235 recipNonce of the downstream nested message. The downstream nested 3236 message SHOULD bundle the individual response messages (e.g., ip, cp, 3237 kup, pollRep, pkiConf, rp, genp, error) for all original request 3238 messages of the upstream nested message. While unbundling the 3239 downstream nested message, the former PKI management entity can 3240 determine lost and unexpected responses based on the previously 3241 stored transactionIDs. When it forwards the unbundled responses, any 3242 extra messages SHOULD be dropped, and any missing response message 3243 (failInfo bit: systemUnavail) MUST be answered with an error message 3244 to inform the respective requester about the failed certificate 3245 management operation. 3247 Note: This form of nesting messages is characterized by the fact that 3248 the transactionID in the header of the nested message is different to 3249 those used in the included messages. 3251 The protection of the nested messages SHOULD NOT be regarded as an 3252 indication of verification or approval of the bundled PKI request 3253 messages. 3255 No specific prerequisites apply in addition to those specified in 3256 Section 3.4. 3258 Message flow: 3260 Step# PKI management entity PKI management entity 3261 1 format nested 3262 2 -> nested -> 3263 3 handle or forward nested 3264 4 format or receive nested 3265 5 <- nested <- 3266 6 handle nested 3268 5.2.3. Replacing protection 3270 The following two alternatives can be used by any PKI management 3271 entity forwarding a CMP message with or without changes while 3272 providing its own protection and in this way asserting approval of 3273 the message. 3275 By replacing the existing protection using its own CMP protecting key 3276 the PKI management entity provides a proof of verifying and approving 3277 the message as described above. Thus, the PKI management entity acts 3278 as an actual Registration Authority (RA), which implements important 3279 security functionality of the PKI. 3281 Before replacing the existing protection by a new protection, the PKI 3282 management entity MUST verify the protection provided and approve its 3283 content, including any modifications that it may perform. It MUST 3284 also check that the sender, as authenticated by the message 3285 protection, is authorized for the given operation. 3287 These message adaptations MUST NOT be applied to kur messages 3288 described in Section 4.1.3 since their original protection using the 3289 key and certificate to be updated needs to be preserved, unless the 3290 regCtrl OldCertId is used to strongly identify the certificate to be 3291 updated. 3293 These message adaptations MUST NOT be applied to certificate request 3294 messages described in for central key generation Section 4.1.6 since 3295 their original protection needs to be preserved up to the Key 3296 Generation Authority, which needs to use it for encrypting the new 3297 private key for the EE. 3299 In both the kur and central key generation cases, if a PKI management 3300 entity needs to state its approval of the original request message it 3301 MUST provide this using a nested message as specified in 3302 Section 5.2.2.1. 3304 When an intermediate PKI management entity modifies a message, it 3305 SHOULD NOT change the transactionID nor the sender and recipient 3306 nonces. 3308 5.2.3.1. Not changing any included proof-of-possession 3310 This variant of forwarding a message means that a PKI management 3311 entity forwards a CMP message with or without modifying the message 3312 header or body while preserving any included proof-of-possession. 3314 In case the PKI management entity breaks an existing proof-of- 3315 possession, the message adaptation described in Section 5.2.3.2 needs 3316 to be applied instead. 3318 Specific prerequisites augmenting the prerequisites in Section 3.4: 3320 * The PKI management entity MUST have the authorization to perform 3321 the validation and approval of the respective request according to 3322 the PKI policies. 3324 5.2.3.2. Breaking proof-of-possession 3326 This variant of forwarding a message needs to be used if a PKI 3327 management entity breaks a signature-based proof-of-possession in a 3328 certificate request message, for instance because it forwards an ir 3329 or cr message with modifications of the certTemplate, i.e., 3330 modification, addition, or removal of fields. 3332 The PKI management entity MUST verify the proof-of-possession 3333 contained in the original message using the included public key. If 3334 successful, the PKI management entity MUST change the popo field 3335 value to raVerified. 3337 Specific prerequisites augmenting the prerequisites in Section 3.4: 3339 * The PKI management entity MUST have the authorization to verify 3340 the proof-of-possession. 3342 * The PKI management entity MUST have the authorization to perform 3343 the validation and approval of the respective request according to 3344 the PKI policies. 3346 The new popo field MUST contain the raVerified choice in the certReq 3347 structure of the modified message as follows: 3349 popo 3350 raVerified REQUIRED 3351 -- MUST have the value NULL and indicates that the PKI 3352 -- management entity verified the popo of the original message 3354 5.3. Acting on behalf of other PKI entities 3356 A PKI management entity may need to request a PKI management 3357 operation on behalf of another PKI entity. In this case the PKI 3358 management entity initiates the respective PKI management operation 3359 as described in Section 4 acting in the role of the EE. 3361 5.3.1. Requesting certificates 3363 A PKI management entity may use on of the PKI management operations 3364 described in Section 4.1 to request a certificate on behalf of 3365 another PKI entity. It either generates the key pair itself and 3366 inserts the new public key in the subjectPublicKey field of the 3367 request certTemplate, or it uses a certificate request received from 3368 downstream, e.g., by means of a different protocol. In the latter 3369 case it SHOULD verify the received proof-of-possession. 3371 No specific prerequisites apply in addition to those specified in 3372 Section 4.1. 3374 Note: An upstream PKI management entity will not be able to 3375 differentiate this PKI management operation from the one described in 3376 Section 5.2.3 because in both cases the message is protected by the 3377 PKI management entity. 3379 The message sequence for this PKI management operation is identical 3380 to the respective PKI management operation given in Section 4.1, with 3381 the following changes: 3383 1 The request messages MUST be signed using the CMP protection key 3384 of the PKI management entity taking the role of the EE in this 3385 operation. 3387 2 If inclusion of a proper proof-of-possession is not possible the 3388 PKI management entity MUST verify the POP provided from downstream 3389 and use "raVerified" in its upstream request. 3391 5.3.2. Revoking a certificate 3393 A PKI management entity may use the PKI management operation 3394 described in Section 4.2 to revoke a certificate of another PKI 3395 entity. This revocation request message MUST be signed by the PKI 3396 management entity using its own CMP protection key to prove to the 3397 PKI authorization to revoke the certificate on behalf of that PKI 3398 entity. 3400 No specific prerequisites apply in addition to those specified in 3401 Section 4.2. 3403 Note: An upstream PKI management entity will not be able to 3404 differentiate this PKI management operation from the ones described 3405 in Section 5.2.3. 3407 The message sequence for this PKI management operation is identical 3408 to that given in Section 4.2, with the following changes: 3410 1 The rr message MUST be signed using the CMP protection key of the 3411 PKI management entity taking the role of the EE in this operation. 3413 6. CMP message transfer mechanisms 3415 CMP messages are designed to be self-contained, such that in 3416 principle any reliable transfer mechanism can be used. HTTP SHOULD 3417 and CoAP MAY be used for online transfer. CMP messages MAY also be 3418 piggybacked on any other reliable transfer protocol. File-based 3419 transfer MAY be used in case offline transfer is required. 3421 Independently of the means of transfer, it can happen that messages 3422 are lost or that a communication partner does not respond. To 3423 prevent waiting indefinitely, each CMP client component SHOULD use a 3424 configurable per-request timeout, and each CMP server component 3425 SHOULD use a configurable per-response timeout in case a further 3426 Request message is to be expected from the client side within the 3427 same transaction. In this way a hanging transaction can be closed 3428 cleanly with an error as described in Section 3.6 (failInfo bit: 3429 systemUnavail) and related resources (for instance, any cached 3430 extraCerts) can be freed. 3432 Moreover, there are various situations where the delivery of messages 3433 gets delayed. For instance, a serving PKI management entity might 3434 take longer than expected to form a response due to administrative 3435 processes, resource constraints, or upstream message delivery delays. 3436 The transport layer itself may cause delays, for instance due to 3437 offline transport, network segmentation, or intermittent network 3438 connectivity. Part of these issues can be detected and handled at 3439 CMP level using pollReq and pollRep messages as described in 3440 Section 4.4, while others are better handled at transfer level. 3441 Depending on the transfer protocol and system architecture, solutions 3442 for handling delays at transfer level may be present and can be used 3443 for CMP connections, for instance connection re-establishment and 3444 message retransmission. 3446 Note: Long timeout periods are helpful to minimize the need for 3447 polling and maximize chances to handle transfer issues at lower 3448 levels. 3450 Note: When using TCP and similar reliable connection-oriented 3451 transport protocols, which is typical in conjunction with HTTP, there 3452 is the option to keep the connection alive over multiple request- 3453 response message pairs. This may improve efficiency, though is not 3454 required from a security point of view. 3456 When conveying CMP messages in HTTP, CoAP, or MIME-based transfer 3457 protocols, the internet media type "application/pkixcmp" MUST be set 3458 for transfer encoding as specified in Section 5.3 of RFC 2510 3459 [RFC2510], Section 2.4 of CMP over CoAP 3460 [I-D.ietf-ace-cmpv2-coap-transport], and Section 3.4 of CMP over HTTP 3461 [RFC6712]. 3463 6.1. HTTP transfer 3465 This transfer mechanism can be used by a PKI entity to transfer CMP 3466 messages over HTTP. If HTTP transfer is used the specifications as 3467 described in [RFC6712] and updated by CMP Updates 3468 [I-D.ietf-lamps-cmp-updates] MUST be followed. 3470 PKI management operations SHOULD use URI paths consisting of '/.well- 3471 known/cmp/' followed by an operation label depending on the type of 3472 PKI management operation. 3474 +============================+=====================+=========+ 3475 | PKI management operation | operation label | Details | 3476 +============================+=====================+=========+ 3477 | Enroll client to new PKI | /initialization | Section | 3478 | | | 4.1.1 | 3479 +----------------------------+---------------------+---------+ 3480 | Enroll client to existing | /certification | Section | 3481 | PKI | | 4.1.2 | 3482 +----------------------------+---------------------+---------+ 3483 | Update client certificate | /keyupdate | Section | 3484 | | | 4.1.3 | 3485 +----------------------------+---------------------+---------+ 3486 | Enroll client using | /p10 | Section | 3487 | PKCS#10 | | 4.1.4 | 3488 +----------------------------+---------------------+---------+ 3489 | Revoke client certificate | /revocation | Section | 3490 | | | 4.2 | 3491 +----------------------------+---------------------+---------+ 3492 | Get CA certificates | /getcacerts | Section | 3493 | | | 4.3.1 | 3494 +----------------------------+---------------------+---------+ 3495 | Get root CA certificate | /getrootupdate | Section | 3496 | update | | 4.3.2 | 3497 +----------------------------+---------------------+---------+ 3498 | Get certificate request | /getcertreqtemplate | Section | 3499 | template | | 4.3.1 | 3500 +----------------------------+---------------------+---------+ 3501 | Get CRL updates | /getcrls | Section | 3502 | | | 4.3.4 | 3503 +----------------------------+---------------------+---------+ 3504 | Batching messages | /nested | Section | 3505 | | | 5.2.2.2 | 3506 | Note: This path element is | | | 3507 | applicable only between | | | 3508 | PKI management entities. | | | 3509 +----------------------------+---------------------+---------+ 3511 Table 1: HTTP endpoints 3513 Independently of any variants used (see Section 4.1.5, Section 4.1.6, 3514 and Section 4.4) the operation label corresponding to the PKI 3515 management operation SHALL be used. 3517 Any certConf or pollReq messages are sent to the same endpoint as 3518 determined by the PKI management operation. 3520 When a single request message is nested as described in 3521 Section 5.2.2.1, the label to use is the same as for the underlying 3522 PKI management operation. 3524 By sending a request to its preferred endpoint, the PKI entity will 3525 recognize via the HTTP response status code whether a configured URI 3526 is supported by the PKI management entity. 3528 In case a PKI management entity receives an unexpected HTTP status 3529 code from upstream, it MUST respond downstream with an error message 3530 as described in Section 3.6 using a failInfo bit corresponding to the 3531 status code, e.g., systemFailure. 3533 For certificate management the major security goal is integrity and 3534 data origin authentication. For delivery of centrally generated 3535 keys, also confidentiality is a must. These goals are sufficiently 3536 achieved by CMP itself, also in an end-to-end fashion. If a second 3537 line of defense is required or general privacy concerns exist, TLS 3538 can be used to provide confidentiality on a hop-by-hop basis. 3540 TLS SHOULD be used with certificate-based authentication to further 3541 protect the HTTP transfer as described in [RFC2818]. The CMP 3542 transfer via HTTPS MUST use TLS server authentication and SHOULD use 3543 TLS client authentication. 3545 Note: The requirements for checking certificates given in [RFC5280], 3546 [RFC5246], and [RFC8446] MUST be followed for the TLS layer. 3547 Certificate status checking SHOULD be used for the TLS certificates 3548 of all communication partners. 3550 TLS with mutual authentication based on shared secret information MAY 3551 be used in case no suitable certificates for certificate-based 3552 authentication are available, e.g., a PKI management operation with 3553 MAC-based protection is used. 3555 Note: The entropy of the shared secret information is crucial for the 3556 level of protection available using shard secret information-based 3557 TLS authentication. A pre-shared key (PSK) mechanism is acceptable 3558 using shared secret information with an entropy of at least 128 bits. 3559 Otherwise, a password-authenticated key exchange (PAKE) protocol is 3560 RECOMMENDED. 3562 6.2. CoAP transfer 3564 This transfer mechanism can be used by a PKI entity to transfer CMP 3565 messages over CoAP [RFC7252], e.g., in constrained environments. If 3566 CoAP transfer is used the specifications as described in CMP over 3567 CoAP [I-D.ietf-ace-cmpv2-coap-transport] MUST be followed. 3569 PKI management operations SHOULD use URI paths consisting of '/.well- 3570 known/cmp/' followed by an operation label depending on the type of 3571 PKI management operation. 3573 +=======================================+===========+=========+ 3574 | PKI management operation | operation | Details | 3575 | | label | | 3576 +=======================================+===========+=========+ 3577 | Enroll client to new PKI | /ir | Section | 3578 | | | 4.1.1 | 3579 +---------------------------------------+-----------+---------+ 3580 | Enroll client to existing PKI | /cr | Section | 3581 | | | 4.1.2 | 3582 +---------------------------------------+-----------+---------+ 3583 | Update client certificate | /kur | Section | 3584 | | | 4.1.3 | 3585 +---------------------------------------+-----------+---------+ 3586 | Enroll client using PKCS#10 | /p10 | Section | 3587 | | | 4.1.4 | 3588 +---------------------------------------+-----------+---------+ 3589 | Revoke client certificate | /rr | Section | 3590 | | | 4.2 | 3591 +---------------------------------------+-----------+---------+ 3592 | Get CA certificates | /crts | Section | 3593 | | | 4.3.1 | 3594 +---------------------------------------+-----------+---------+ 3595 | Get root CA certificate update | /rcu | Section | 3596 | | | 4.3.2 | 3597 +---------------------------------------+-----------+---------+ 3598 | Get certificate request template | /att | Section | 3599 | | | 4.3.3 | 3600 +---------------------------------------+-----------+---------+ 3601 | Get CRL updates | /crls | Section | 3602 | | | 4.3.4 | 3603 +---------------------------------------+-----------+---------+ 3604 | Batching messages | /nest | Section | 3605 | | | 5.2.2.2 | 3606 | Note: This path element is applicable | | | 3607 | only between PKI management entities. | | | 3608 +---------------------------------------+-----------+---------+ 3610 Table 2: CoAP endpoints 3612 Independently of any variants used (see Section 4.1.5, Section 4.1.6, 3613 and Section 4.4) the operation label corresponding to the PKI 3614 management operation SHALL be used. 3616 Any certConf or pollReq messages are sent to the same endpoint as 3617 determined by the PKI management operation. 3619 When a single request message is nested as described in 3620 Section 5.2.2.1, the label to use is the same as for the underlying 3621 PKI management operation. 3623 By sending a request to its preferred endpoint, the PKI entity will 3624 recognize via the CoAP response status code whether a configured URI 3625 is supported by the PKI management entity. The CoAP-inherent 3626 discovery mechanisms MAY also be used. 3628 In case a PKI management entity receives an unexpected CoAP status 3629 code from upstream, it MUST respond downstream with an error message 3630 as described in Section 3.6 using a failInfo bit corresponding to the 3631 status code, e.g., systemFailure. 3633 Like for HTTP transfer , to offer a second line of defense or to 3634 provide hop-by-hop privacy protection, DTLS MAY be utilized as 3635 described in CMP over CoAP [I-D.ietf-ace-cmpv2-coap-transport]. 3637 6.3. Piggybacking on other reliable transfer 3639 CMP messages MAY also be transfer on some other reliable protocol. 3640 Connection, delay, and error handling mechanisms similar to those 3641 specified for HTTP in Section 6.1 need to be implemented. 3643 A more detailed specification is out of scope of this document and 3644 would need to be given for instance in the scope of the transfer 3645 protocol used. 3647 6.4. Offline transfer 3649 For transferring CMP messages between PKI entities, any mechanism can 3650 be used that is able to store and forward binary objects of 3651 sufficient length and with sufficient reliability while preserving 3652 the order of messages for each transaction. 3654 The transfer mechanism SHOULD be able to indicate message loss, 3655 excessive delay, and possibly other transmission errors. In such 3656 cases the PKI entities SHOULD report an error as specified in 3657 Section 3.6 as far as possible. 3659 6.4.1. File-based transfer 3661 CMP messages MAY be transferred between PKI entities using file-based 3662 mechanisms, for instance when an offline EE or a PKI management 3663 entity performs delayed delivery. Each file MUST contain the ASN.1 3664 DER encoding of one CMP message only, where the message may be 3665 nested. There MUST be no extraneous header or trailer information in 3666 the file. The file name extension ".pki" MUST be used. 3668 6.4.2. Other asynchronous transfer protocols 3670 Other asynchronous transfer protocols, e.g., email or website 3671 up-/download, MAY transfer CMP messages between PKI entities. A MIME 3672 wrapping is defined for those environments that are MIME-native. The 3673 MIME wrapping in this section is specified in RFC 8551 Section 3.1 3674 [RFC8551]. 3676 The ASN.1 DER encoding of the CMP messages MUST be transferred using 3677 the "application/pkixcmp" content type and base64-encoded content 3678 transfer encoding as specified in [RFC2510], section 5.3. A filename 3679 MUST be included either in a "content-type" or a "content- 3680 disposition" statement. The file name extension ".pki" MUST be used. 3682 7. Conformance requirements 3684 This section defines which level of support for the various features 3685 specified in this profile is required for which type of PKI entity. 3687 7.1. PKI management operations 3689 The following table provides an overview of the PKI management 3690 operations specified in Section 4 and Section 5 and states whether 3691 support by conforming EE, RA, and CA implementations is mandatory, 3692 recommended, optional, or not applicable. Variants amend or change 3693 behavior of base PKI management operations and are therefore also 3694 included. 3696 +==========+=============================+========+========+========+ 3697 | ID | PKI management operations | EE | RA | CA | 3698 | | and variants | | | | 3699 +==========+=============================+========+========+========+ 3700 | Generic | generic aspects of PKI | MUST | MUST | MUST | 3701 | | management operations, | | | | 3702 | | Section 3 | | | | 3703 +----------+-----------------------------+--------+--------+--------+ 3704 | IR | Requesting a certificate | MUST | MUST | MUST | 3705 | | from a new PKI with | | | | 3706 | | signature-based | | | | 3707 | | protection, Section 4.1.1 | | | | 3708 +----------+-----------------------------+--------+--------+--------+ 3709 | CR | Requesting an additional | MAY | MAY | MAY | 3710 | | certificate with | | | | 3711 | | signature-based | | | | 3712 | | protection, Section 4.1.2 | | | | 3713 +----------+-----------------------------+--------+--------+--------+ 3714 | KUR | Updating an existing | MUST | MUST | MUST | 3715 | | certificate with | | | | 3716 | | signature-based | | | | 3717 | | protection, Section 4.1.3 | | | | 3718 +----------+-----------------------------+--------+--------+--------+ 3719 | P10CR | Requesting a certificate | MAY | MAY | MAY | 3720 | | from a legacy PKI using a | | | | 3721 | | PKCS#10 request, | | | | 3722 | | Section 4.1.4 | | | | 3723 +----------+-----------------------------+--------+--------+--------+ 3724 | MAC | Requesting a certificate | SHOULD | SHOULD | SHOULD | 3725 | | from a PKI with MAC-based | | | | 3726 | | protection (IR, CR, KUR, | | | | 3727 | | and P10CR if supported), | | | | 3728 | | Section 4.1.5 | | | | 3729 +----------+-----------------------------+--------+--------+--------+ 3730 | CKeyGen | Adding central key | MAY | MAY | MAY | 3731 | | generation to a | | | | 3732 | | certificate request (IR, | | | | 3733 | | CR, KUR, and P10CR if | | | | 3734 | | supported). (If | | | | 3735 | | supported, key agreement | | | | 3736 | | key management technique | | | | 3737 | | is REQUIRED, and key | | | | 3738 | | transport and password- | | | | 3739 | | based key management | | | | 3740 | | techniques are | | | | 3741 | | OPTIONAL.), Section 4.1.6 | | | | 3742 +----------+-----------------------------+--------+--------+--------+ 3743 | RR | Revoking a certificate, | SHOULD | SHOULD | SHOULD | 3744 | | Section 4.2 | | | | 3745 +----------+-----------------------------+--------+--------+--------+ 3746 | CACerts | Get CA certificates, | MAY | MAY | MAY | 3747 | | Section 4.3.1 | | | | 3748 +----------+-----------------------------+--------+--------+--------+ 3749 | RootUpd | Get root CA certificate | MAY | MAY | MAY | 3750 | | update, Section 4.3.2 | | | | 3751 +----------+-----------------------------+--------+--------+--------+ 3752 | ReqTempl | Get certificate request | MAY | MAY | MAY | 3753 | | template, Section 4.3.3 | | | | 3754 +----------+-----------------------------+--------+--------+--------+ 3755 | CRLUpd | CRL update retrieval, | MAY | MAY | MAY | 3756 | | Section 4.3.4 | | | | 3757 +----------+-----------------------------+--------+--------+--------+ 3758 | Polling | Handling delayed | MAY | MAY | MAY | 3759 | | delivery, Section 4.4 | | | | 3760 +----------+-----------------------------+--------+--------+--------+ 3761 | CertResp | Responding to a | N/A | MAY | MUST | 3762 | | certificate request (IR, | | | | 3763 | | CR, KUR, and P10CR if | | | | 3764 | | supported), Section 5.1.1 | | | | 3765 +----------+-----------------------------+--------+--------+--------+ 3766 | InitPoll | Initiating delayed | N/A | MAY | MAY | 3767 | | delivery, Section 5.1.2 | | | | 3768 +----------+-----------------------------+--------+--------+--------+ 3769 | CertConf | Responding to a | MUST | MAY | MUST | 3770 | | confirmation message, | | | | 3771 | | Section 5.1.3 | | | | 3772 +----------+-----------------------------+--------+--------+--------+ 3773 | RevResp | Responding to a | N/A | MAY | SHOULD | 3774 | | revocation request, | | | | 3775 | | Section 5.1.4 | | | | 3776 +----------+-----------------------------+--------+--------+--------+ 3777 | GenResp | Responding to a support | N/A | MAY | MAY | 3778 | | message (CACerts, | | | | 3779 | | RootUpd, ReqTempl, CRLUpd | | | | 3780 | | if supported), | | | | 3781 | | Section 5.1.5 | | | | 3782 +----------+-----------------------------+--------+--------+--------+ 3783 | FwdKeep | Forwarding messages - not | N/A | MUST | N/A | 3784 | | changing protection, | | | | 3785 | | Section 5.2.1 | | | | 3786 +----------+-----------------------------+--------+--------+--------+ 3787 | FwdAddS | Adding protection to a | N/A | MUST | MUST | 3788 | | request message, | | | | 3789 | | Section 5.2.2.1 | | | | 3790 +----------+-----------------------------+--------+--------+--------+ 3791 | FwdAddB | Batching messages, | N/A | MAY | MAY | 3792 | | Section 5.2.2.2 | | | | 3793 +----------+-----------------------------+--------+--------+--------+ 3794 | FwdRepKP | Forwarding messages - | N/A | MAY | N/A | 3795 | | replacing protection, not | | | | 3796 | | changing any included | | | | 3797 | | proof-of-possession, | | | | 3798 | | Section 5.2.3.1 | | | | 3799 +----------+-----------------------------+--------+--------+--------+ 3800 | FwdRepBP | Forwarding messages - | N/A | MAY | MAY | 3801 | | replacing protection, | | | | 3802 | | breaking proof-of- | | | | 3803 | | possession, | | | | 3804 | | Section 5.2.3.2 | | | | 3805 +----------+-----------------------------+--------+--------+--------+ 3806 | CertOnB | Acting on behalf of other | N/A | MAY | N/A | 3807 | | PKI entities - requesting | | | | 3808 | | certificates, | | | | 3809 | | Section 5.3.1 | | | | 3810 +----------+-----------------------------+--------+--------+--------+ 3811 | RevROnB | Acting on behalf of other | N/A | SHOULD | SHOULD | 3812 | | PKI entities - revoking a | | | | 3813 | | certificate, | | | | 3814 | | Section 5.3.2 | | | | 3815 +----------+-----------------------------+--------+--------+--------+ 3817 Table 3: Level of support for PKI management operations and variants 3819 7.2. Message transfer 3821 CMP does not have specific needs regarding message transfer, except 3822 that for each request message sent, eventually exactly one response 3823 message should be received. Therefore, virtually any reliable 3824 transfer mechanism can be used, such as HTTP, CoAP, and file-based 3825 offline transfer. Thus, this document does not require any specific 3826 transfer protocol to be supported by conforming implementations. 3828 On different links between PKI entities, e.g., EE-RA and RA-CA, 3829 different transfer mechanisms as specified in Section 6 may be used. 3831 HTTP transfer is RECOMMENDED to use for all PKI entities for 3832 maximizing general interoperability at transfer level, yet full 3833 flexibility is retained to choose whatever transfer mechanism is 3834 suitable, for instance for devices and system architectures with 3835 specific constraints. 3837 The following table lists the name and level of support specified for 3838 each transfer mechanism. 3840 +=========+=======================+========+========+========+ 3841 | ID | Message transfer type | EE | RA | CA | 3842 +=========+=======================+========+========+========+ 3843 | HTTP | HTTP transfer, | SHOULD | SHOULD | SHOULD | 3844 | | Section 6.1 | | | | 3845 +---------+-----------------------+--------+--------+--------+ 3846 | CoAP | CoAP transfer, | MAY | MAY | MAY | 3847 | | Section 6.2 | | | | 3848 +---------+-----------------------+--------+--------+--------+ 3849 | Piggyb | Piggybacking on other | MAY | MAY | MAY | 3850 | | reliable transfer, | | | | 3851 | | Section 6.3 | | | | 3852 +---------+-----------------------+--------+--------+--------+ 3853 | Offline | Offline transfer, | MAY | MAY | MAY | 3854 | | Section 6.4 | | | | 3855 +---------+-----------------------+--------+--------+--------+ 3857 Table 4: Level of support for message transfer types 3859 8. IANA Considerations 3861 This document does not request changes to the IANA registry. 3863 9. Security Considerations 3865 The security considerations as laid out in CMP [RFC4210] updated by 3866 CMP Updates [I-D.ietf-lamps-cmp-updates] and CMP Algorithms 3867 [I-D.ietf-lamps-cmp-algorithms], CRMF [RFC4211] updated by Algorithm 3868 Requirements Update [RFC9045], CMP over HTTP [RFC6712], and CMP over 3869 CoAP [I-D.ietf-ace-cmpv2-coap-transport] apply. 3871 For TLS using shared secret information-based authentication, both 3872 PSK and PAKE provide the same amount of protection against a real- 3873 time authentication attack which is directly the amount of entropy in 3874 the shared secret. The difference between a pre-shared key (PSK) and 3875 a password-authenticated key exchange (PAKE) protocol is in the level 3876 of long-term confidentiality of the TLS messages against brute-force 3877 decryption, where a PSK-based cipher suite only provides security 3878 according to the entropy of the shared secret, while a PAKE-based 3879 cipher suite provides full security independent of the entropy of the 3880 shared secret. 3882 10. Acknowledgements 3884 We thank the various reviewers of this document. 3886 11. References 3887 11.1. Normative References 3889 [I-D.ietf-ace-cmpv2-coap-transport] 3890 Sahni, M. and S. Tripathi, "CoAP Transfer for the 3891 Certificate Management Protocol", Work in Progress, 3892 Internet-Draft, draft-ietf-ace-cmpv2-coap-transport-04, 8 3893 November 2021, . 3896 [I-D.ietf-lamps-cmp-algorithms] 3897 Brockhaus, H., Aschauer, H., Ounsworth, M., and J. Gray, 3898 "Certificate Management Protocol (CMP) Algorithms", Work 3899 in Progress, Internet-Draft, draft-ietf-lamps-cmp- 3900 algorithms-08, 17 November 2021, 3901 . 3904 [I-D.ietf-lamps-cmp-updates] 3905 Brockhaus, H., Oheimb, D. V., and J. Gray, "Certificate 3906 Management Protocol (CMP) Updates", Work in Progress, 3907 Internet-Draft, draft-ietf-lamps-cmp-updates-15, 17 3908 December 2021, . 3911 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 3912 Requirement Levels", BCP 14, RFC 2119, 3913 DOI 10.17487/RFC2119, March 1997, 3914 . 3916 [RFC2986] Nystrom, M. and B. Kaliski, "PKCS #10: Certification 3917 Request Syntax Specification Version 1.7", RFC 2986, 3918 DOI 10.17487/RFC2986, November 2000, 3919 . 3921 [RFC4210] Adams, C., Farrell, S., Kause, T., and T. Mononen, 3922 "Internet X.509 Public Key Infrastructure Certificate 3923 Management Protocol (CMP)", RFC 4210, 3924 DOI 10.17487/RFC4210, September 2005, 3925 . 3927 [RFC4211] Schaad, J., "Internet X.509 Public Key Infrastructure 3928 Certificate Request Message Format (CRMF)", RFC 4211, 3929 DOI 10.17487/RFC4211, September 2005, 3930 . 3932 [RFC5280] Cooper, D., Santesson, S., Farrell, S., Boeyen, S., 3933 Housley, R., and W. Polk, "Internet X.509 Public Key 3934 Infrastructure Certificate and Certificate Revocation List 3935 (CRL) Profile", RFC 5280, DOI 10.17487/RFC5280, May 2008, 3936 . 3938 [RFC5652] Housley, R., "Cryptographic Message Syntax (CMS)", STD 70, 3939 RFC 5652, DOI 10.17487/RFC5652, September 2009, 3940 . 3942 [RFC5958] Turner, S., "Asymmetric Key Packages", RFC 5958, 3943 DOI 10.17487/RFC5958, August 2010, 3944 . 3946 [RFC6712] Kause, T. and M. Peylo, "Internet X.509 Public Key 3947 Infrastructure -- HTTP Transfer for the Certificate 3948 Management Protocol (CMP)", RFC 6712, 3949 DOI 10.17487/RFC6712, September 2012, 3950 . 3952 [RFC8174] Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC 3953 2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174, 3954 May 2017, . 3956 [RFC8933] Housley, R., "Update to the Cryptographic Message Syntax 3957 (CMS) for Algorithm Identifier Protection", RFC 8933, 3958 DOI 10.17487/RFC8933, October 2020, 3959 . 3961 [RFC9045] Housley, R., "Algorithm Requirements Update to the 3962 Internet X.509 Public Key Infrastructure Certificate 3963 Request Message Format (CRMF)", RFC 9045, 3964 DOI 10.17487/RFC9045, June 2021, 3965 . 3967 11.2. Informative References 3969 [ETSI-3GPP.33.310] 3970 3GPP, "Network Domain Security (NDS); Authentication 3971 Framework (AF)", 3GPP TS 33.310 16.6.0, 16 December 2020. 3973 [I-D.ietf-anima-brski-async-enroll] 3974 Fries, S., Brockhaus, H., Oheimb, D. V., and E. Lear, 3975 "Support of Asynchronous Enrollment in BRSKI (BRSKI-AE)", 3976 Work in Progress, Internet-Draft, draft-ietf-anima-brski- 3977 async-enroll-04, 25 October 2021, 3978 . 3981 [I-D.ietf-anima-brski-prm] 3982 Fries, S., Werner, T., Lear, E., and M. Richardson, "BRSKI 3983 with Pledge in Responder Mode (BRSKI-PRM)", Work in 3984 Progress, Internet-Draft, draft-ietf-anima-brski-prm-00, 3985 25 October 2021, . 3988 [I-D.ietf-netconf-sztp-csr] 3989 Watsen, K., Housley, R., and S. Turner, "Conveying a 3990 Certificate Signing Request (CSR) in a Secure Zero Touch 3991 Provisioning (SZTP) Bootstrapping Request", Work in 3992 Progress, Internet-Draft, draft-ietf-netconf-sztp-csr-12, 3993 3 December 2021, . 3996 [IEC.62443-3-3] 3997 IEC, "Industrial communication networks - Network and 3998 system security - Part 3-3: System security requirements 3999 and security levels", IEC 62443-3-3, August 2013, 4000 . 4002 [IEEE.802.1AR_2018] 4003 IEEE, "IEEE Standard for Local and metropolitan area 4004 networks - Secure Device Identity", IEEE 802.1AR-2018, 4005 DOI 10.1109/IEEESTD.2018.8423794, 2 August 2018, 4006 . 4008 [NIST.CSWP.04162018] 4009 National Institute of Standards and Technology (NIST), 4010 "Framework for Improving Critical Infrastructure 4011 Cybersecurity, Version 1.1", NIST NIST.CSWP.04162018, 4012 DOI 10.6028/NIST.CSWP.04162018, April 2018, 4013 . 4016 [NIST.SP.800-57p1r5] 4017 Barker, E B., "Recommendation for key management, part 1 4018 :general", NIST NIST.SP.800-57pt1r5, 4019 DOI 10.6028/NIST.SP.800-57pt1r5, 2020, 4020 . 4022 [RFC2510] Adams, C. and S. Farrell, "Internet X.509 Public Key 4023 Infrastructure Certificate Management Protocols", 4024 RFC 2510, DOI 10.17487/RFC2510, March 1999, 4025 . 4027 [RFC2818] Rescorla, E., "HTTP Over TLS", RFC 2818, 4028 DOI 10.17487/RFC2818, May 2000, 4029 . 4031 [RFC3647] Chokhani, S., Ford, W., Sabett, R., Merrill, C., and S. 4032 Wu, "Internet X.509 Public Key Infrastructure Certificate 4033 Policy and Certification Practices Framework", RFC 3647, 4034 DOI 10.17487/RFC3647, November 2003, 4035 . 4037 [RFC5246] Dierks, T. and E. Rescorla, "The Transport Layer Security 4038 (TLS) Protocol Version 1.2", RFC 5246, 4039 DOI 10.17487/RFC5246, August 2008, 4040 . 4042 [RFC7030] Pritikin, M., Ed., Yee, P., Ed., and D. Harkins, Ed., 4043 "Enrollment over Secure Transport", RFC 7030, 4044 DOI 10.17487/RFC7030, October 2013, 4045 . 4047 [RFC7252] Shelby, Z., Hartke, K., and C. Bormann, "The Constrained 4048 Application Protocol (CoAP)", RFC 7252, 4049 DOI 10.17487/RFC7252, June 2014, 4050 . 4052 [RFC8366] Watsen, K., Richardson, M., Pritikin, M., and T. Eckert, 4053 "A Voucher Artifact for Bootstrapping Protocols", 4054 RFC 8366, DOI 10.17487/RFC8366, May 2018, 4055 . 4057 [RFC8446] Rescorla, E., "The Transport Layer Security (TLS) Protocol 4058 Version 1.3", RFC 8446, DOI 10.17487/RFC8446, August 2018, 4059 . 4061 [RFC8551] Schaad, J., Ramsdell, B., and S. Turner, "Secure/ 4062 Multipurpose Internet Mail Extensions (S/MIME) Version 4.0 4063 Message Specification", RFC 8551, DOI 10.17487/RFC8551, 4064 April 2019, . 4066 [RFC8572] Watsen, K., Farrer, I., and M. Abrahamsson, "Secure Zero 4067 Touch Provisioning (SZTP)", RFC 8572, 4068 DOI 10.17487/RFC8572, April 2019, 4069 . 4071 [RFC8995] Pritikin, M., Richardson, M., Eckert, T., Behringer, M., 4072 and K. Watsen, "Bootstrapping Remote Secure Key 4073 Infrastructure (BRSKI)", RFC 8995, DOI 10.17487/RFC8995, 4074 May 2021, . 4076 [UNISIG.Subset-137] 4077 UNISIG, "Subset-137; ERTMS/ETCS On-line Key Management 4078 FFFIS; V1.0.0", December 2015, 4079 . 4081 Appendix A. Example CertReqTemplate 4083 Suppose the server requires that the certTemplate contains 4085 * the issuer field with a value to be filled in by the EE, 4087 * the subject field with a common name to be filled in by the EE and 4088 two organizational unit fields with given values "myDept" and 4089 "myGroup", 4091 * the publicKey field contains an ECC key on curve secp256r1 or an 4092 RSA public key of length 2048, 4094 * the subjectAltName extension with DNS name "www.myServer.com" and 4095 an IP address to be filled in, 4097 * the keyUsage extension marked critical with the value 4098 digitalSignature and keyAgreement, and 4100 * the extKeyUsage extension with values to be filled in by the EE. 4102 Then the infoValue with certTemplate and keySpec fields returned to 4103 the EE will be encoded as follows: 4105 SEQUENCE { 4106 SEQUENCE { 4107 [3] { 4108 SEQUENCE {} 4109 } 4110 [5] { 4111 SEQUENCE { 4112 SET { 4113 SEQUENCE { 4114 OBJECT IDENTIFIER commonName (2 5 4 3) 4115 UTF8String "" 4116 } 4117 } 4118 SET { 4119 SEQUENCE { 4120 OBJECT IDENTIFIER organizationalUnitName (2 5 4 11) 4121 UTF8String "myDept" 4122 } 4124 } 4125 SET { 4126 SEQUENCE { 4127 OBJECT IDENTIFIER organizationalUnitName (2 5 4 11) 4128 UTF8String "myGroup" 4129 } 4130 } 4131 } 4132 } 4133 [9] { 4134 SEQUENCE { 4135 OBJECT IDENTIFIER subjectAltName (2 5 29 17) 4136 OCTET STRING, encapsulates { 4137 SEQUENCE { 4138 [2] "www.myServer.com" 4139 [7] "" 4140 } 4141 } 4142 } 4143 SEQUENCE { 4144 OBJECT IDENTIFIER keyUsage (2 5 29 15) 4145 BOOLEAN TRUE 4146 OCTET STRING, encapsulates { 4147 BIT STRING 3 unused bits 4148 "10001"B 4149 } 4150 } 4151 SEQUENCE { 4152 OBJECT IDENTIFIER extKeyUsage (2 5 29 37) 4153 OCTET STRING, encapsulates { 4154 SEQUENCE {} 4155 } 4156 } 4157 } 4158 } 4159 SEQUENCE { 4160 SEQUENCE { 4161 OBJECT IDENTIFIER algId (1 3 6 1 5 5 7 5 1 11) 4162 SEQUENCE { 4163 OBJECT IDENTIFIER ecPublicKey (1 2 840 10045 2 1) 4164 OBJECT IDENTIFIER secp256r1 (1 2 840 10045 3 1 7) 4165 } 4166 } 4167 SEQUENCE { 4168 OBJECT IDENTIFIER rsaKeyLen (1 3 6 1 5 5 7 5 1 12) 4169 INTEGER 2048 4170 } 4171 } 4173 } 4175 Appendix B. History of changes 4177 Note: This appendix will be deleted in the final version of the 4178 document. 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 4215 * Added reference to [I-D.ietf-anima-brski-async-enroll] in new 4216 Section 1.5 and Section 4.1.1 4217 * Changed reference in Section 2 to [I-D.ietf-anima-brski-prm] as 4218 the PUSH use case is continued to be discussed in this draft after 4219 the split of BRSKI-AE 4220 * Improved note regarding UNISIG Subset-137 in Section 1.6 4221 * Removed "rootCaCert" in Section 3.1 and updated the structure of 4222 the genm request for root CA certificate updates in Section 4.3.2. 4223 * Simplified handling of sender and recipient nonces in case of 4224 delayed delivery in Sections 3.1, 3.5, 4.4, and 5.1.2 4225 * Changed the order of Sections 4.1.4 and 4.1.5 4226 * Added reference on RFC 8933 regarding CMS signedAttrs to 4227 Section 4.1.6 4228 * Added Section 4.3.4 on CRL update retrieval 4229 * Generalized delayed enrollment to delayed delivery in Section 4.4 4230 and 5.1.2, updated the state machine in the introduction of 4231 Section 4 4232 * Updated Section 6 regarding delayed message transfer 4233 * Changed file name extension from ".PKI" to ".pki", deleted 4234 operational path for central key generation, and added an 4235 operational path for CRL update retrieval in Sections 6.1 and 6.2 4236 * Shifted many security considerations to CMP Updates 4237 * Replaced the term "transport" by "transfer" where appropriate to 4238 prevent confusion regarding TCP vs. HTTP and CoAP 4239 * Various editorial changes and language corrections 4241 From version 05 -> 06: 4243 * Changed in Section 2.3 the normative requirement in of adding 4244 protection to a single message to mandatory and replacing 4245 protection to optional 4246 * Added Section 3.4 specifying generic prerequisites to PKI 4247 management operations 4248 * Added Section 3.5 specifying generic message validation 4249 * Added Section 3.6 on generic error reporting. This section 4250 replaces the former error handling section from Section 4 and 5. 4251 * Added reference to using hashAlg 4252 * Updates Section 4.3.2 and Section 4.3.3 to align with CMP Updates 4253 * Added Section 5.1 specifying the behavior of PKI management 4254 entities when responding to requests 4255 * Reworked Section 5.2.3. on usage of nested messages 4256 * Updates Section 5.3 on performing PKI management operation on 4257 behalf of another entity 4258 * Updates Section 6.2 on HTTPS transport of CMP messages as 4259 discusses at IETF 110 and email thread "I-D Action: draft-ietf- 4260 lamps-lightweight-cmp-profile-05.txt" 4261 * Added CoAP endpoints to Section 6.4 4262 * Added security considerations on usage of shared secret 4263 information 4264 * Updated the example in Appendix A 4265 * Added newly registered OIDs to the example in Appendix A 4266 * Updated new RFC numbers for I-D.ietf-lamps-crmf-update-algs 4267 * Multiple language corrections, clarifications, and changes in 4268 wording 4270 From version 04 -> 05: 4272 * Changed to XML V3 4273 * Added algorithm names introduced in CMP Algorithms Section 7.3 to 4274 Section 4 of this document 4275 * Updates Syntax in Section 4.4.3 due to changes made in CMP Updates 4276 * Deleted the text on HTTP-based discovery as discussed in 4277 Section 6.1 4278 * Updates Appendix A due to change syntax in Section 4.4.3 4279 * Many clarifications and changes in wording thanks to David's 4280 extensive review 4282 From version 03 -> 04: 4284 * Deleted normative text sections on algorithms and refer to CMP 4285 Algorithms and CRMF Algorithm Requirements Update instead 4286 * Some clarifications and changes in wording 4288 From version 02 -> 03: 4290 * Updated the interoperability with [UNISIG.Subset-137] in 4291 Section 1.4. 4292 * Changed Section 2.3 to a tabular layout to enhanced readability 4293 * Added a ToDo to section 3.1 on aligning with the CMP Algorithms 4294 draft that will be set up as decided in IETF 108 4295 * Updated section 4.1.6 to add the AsymmetricKey Package structure 4296 to transport a newly generated private key as decided in IETF 108 4297 * Added a ToDo to section 4.1.7 on required review of the nonce 4298 handling in case an offline LRA responds and not forwards the 4299 pollReq messages 4300 * Updated Section 4 due to the definition of the new ITAV OIDs in 4301 CMP Updates 4302 * Updated Section 4.4.4 to utilize controls instead of rsaKeyLen 4303 (see thread "dtaft-ietf-lamps-cmp-updates and rsaKeyLen") 4304 * Deleted the section on definition and discovery of HTTP URIs and 4305 copied the text to the HTTP transport section and to CMP Updates 4306 section 3.2 4307 * Added some explanation to Section 5.1.2 and Section 5.1.3 on using 4308 nested messages when a protection by the RA is required. 4309 * Deleted the section on HTTP URI definition and discovery as some 4310 content was moved to CMP Updates. The rest of the content was 4311 moved back to the HTTP transport section 4312 * Deleted the ASN.1 module after moving the new OIDs id-it-caCerts, 4313 id-it-rootCaKeyUpdate, and id-it-certReqTemplate to CMP Updates 4314 * Minor changes in wording and addition of some open ToDos 4316 From version 01 -> 02: 4318 * Extend Section 1.6 with regard to conflicts with UNISIG Subset- 4319 137. 4320 * Minor clarifications on extraCerts in Section 3.3 and 4321 Section 4.1.1. 4322 * Complete specification of requesting a certificate from a trusted 4323 PKI with signature protection in Section 4.1.2. 4324 * Changed from symmetric key-encryption to password-based key 4325 management technique in section Section 4.1.6.3 as discussed on 4326 the mailing list (see thread "draft-ietf-lamps-lightweight-cmp- 4327 profile-01, section 5.1.6.1") 4328 * Changed delayed enrollment described in Section 4.4 from 4329 recommended to optional as decided at IETF 107 4330 * Introduced the new RootCAKeyUpdate structure for root CA 4331 certificate update in Section 4.3.2 as decided at IETF 107 (also 4332 see email thread "draft-ietf-lamps-lightweight-cmp-profile-01, 4333 section 5.4.3") 4334 * Extend the description of the CertReqTemplate PKI management 4335 operation, including an example added in the Appendix. Keep 4336 rsaKeyLen as a single integer value in Section 4.3.3 as discussed 4337 on the mailing list (see thread "draft-ietf-lamps-lightweight-cmp- 4338 profile-01, section 5.4.4") 4339 * Deleted Sections "Get certificate management configuration" and 4340 "Get enrollment voucher" as decided at IETF 107 4341 * Complete specification of adding an additional protection by an 4342 PKI management entity in Section 5.2.2. 4343 * Added a section on HTTP URI definition and discovery and extended 4344 Section 6.1 on definition and discovery of supported HTTP URIs and 4345 content types, add a path for nested messages as specified in 4346 Section 5.2.2 and delete the paths for /getCertMgtConfig and 4347 /getVoucher 4348 * Changed Section 6.4 to address offline transport and added more 4349 detailed specification file-based transport of CMP 4350 * Added a reference to the new I-D of Mohit Sahni on "CoAP Transport 4351 for CMPV2" in Section 6.2; thanks to Mohit supporting the effort 4352 to ease utilization of CMP 4353 * Moved the change history to the Appendix 4354 * Minor changes in wording 4356 From version 00 -> 01: 4358 * Harmonize terminology with CMP [RFC4210], e.g., 4359 - transaction, message sequence, exchange, use case -> PKI 4360 management operation 4361 - PKI component, (L)RA/CA -> PKI management entity 4362 * Minor changes in wording 4364 From draft-brockhaus-lamps-lightweight-cmp-profile-03 -> draft-ietf- 4365 lamps-lightweight-cmp-profile-00: 4367 * Changes required to reflect WG adoption 4368 * Minor changes in wording 4370 From version 02 -> 03: 4372 * Added a short summary of [RFC4210] Appendix D and E in 4373 Section 1.4. 4374 * Clarified some references to different sections and added some 4375 clarification in response to feedback from Michael Richardson and 4376 Tomas Gustavsson. 4377 * Added an additional label to the operational path to address 4378 multiple CAs or certificate profiles in Section 6.1. 4380 From version 01 -> 02: 4382 * Added some clarification on the key management techniques for 4383 protection of centrally generated keys in Section 4.1.6. 4384 * Added some clarifications on the certificates for root CA 4385 certificate update in Section 4.3.2. 4386 * Added a section to specify the usage of nested messages for RAs to 4387 add an additional protection for further discussion, see 4388 Section 5.2.2. 4389 * Added a table containing endpoints for HTTP transport in 4390 Section 6.1 to simplify addressing PKI management entities. 4391 * Added some ToDos resulting from discussion with Tomas Gustavsson. 4392 * Minor clarifications and changes in wording. 4394 From version 00 -> 01: 4396 * Added a section to specify the enrollment with an already trusted 4397 PKI for further discussion, see Section 4.1.2. 4398 * Complete specification of requesting a certificate from a legacy 4399 PKI using a PKCS#10 [RFC2986] request in Section 4.1.4. 4400 * Complete specification of adding central generation of a key pair 4401 on behalf of an end entity in Section 4.1.6. 4402 * Complete specification of handling delayed enrollment due to 4403 asynchronous message delivery in Section 4.4. 4404 * Complete specification of additional support messages, e.g., to 4405 update a Root CA certificate or to request an RFC 8366 [RFC8366] 4406 voucher, in Section 4.3. 4407 * Minor changes in wording. 4409 From draft-brockhaus-lamps-industrial-cmp-profile-00 -> draft- 4410 brockhaus-lamps-lightweight-cmp-profile-00: 4412 * Change focus from industrial to more multi-purpose use cases and 4413 lightweight CMP profile. 4415 * Incorporate the omitted confirmation into the header specified in 4416 Section 3.1 and described in the standard enrollment use case in 4417 Section 4.1.1 due to discussion with Tomas Gustavsson. 4418 * Change from OPTIONAL to RECOMMENDED for use case 'Revoke another's 4419 entities certificate' in Section 5.3.2, because it is regarded as 4420 important functionality in many environments to enable the 4421 management station to revoke EE certificates. 4422 * Complete the specification of the revocation message flow in 4423 Section 4.2 and Section 5.3.2. 4424 * The CoAP based transport mechanism and piggybacking of CMP 4425 messages on top of other reliable transport protocols is out of 4426 scope of this document and would need to be specified in another 4427 document. 4428 * Further minor changes in wording. 4430 Authors' Addresses 4432 Hendrik Brockhaus (editor) 4433 Siemens AG 4435 Email: hendrik.brockhaus@siemens.com 4437 David von Oheimb 4438 Siemens AG 4440 Email: david.von.oheimb@siemens.com 4442 Steffen Fries 4443 Siemens AG 4445 Email: steffen.fries@siemens.com