idnits 2.17.1 draft-ietf-lamps-lightweight-cmp-profile-11.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- No issues found here. Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- No issues found here. Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- == There are 2 instances of lines with non-RFC6890-compliant IPv4 addresses in the document. If these are example addresses, they should be changed. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust and authors Copyright Line does not match the current year -- The document date (15 April 2022) is 735 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 699, but not defined == Missing Reference: 'RFC-CMP-Updates' is mentioned on line 737, but not defined -- Looks like a reference, but probably isn't: '3' on line 4186 -- Looks like a reference, but probably isn't: '5' on line 4189 -- Looks like a reference, but probably isn't: '9' on line 4211 -- Looks like a reference, but probably isn't: '2' on line 4216 -- Looks like a reference, but probably isn't: '7' on line 4217 == 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-12 == Outdated reference: A later version (-23) exists of draft-ietf-lamps-cmp-updates-18 ** Downref: Normative reference to an Informational RFC: RFC 2986 == Outdated reference: A later version (-10) exists of draft-ietf-anima-brski-ae-01 == Outdated reference: A later version (-12) exists of draft-ietf-anima-brski-prm-02 -- 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 (~~), 9 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: 17 October 2022 Siemens 6 15 April 2022 8 Lightweight Certificate Management Protocol (CMP) Profile 9 draft-ietf-lamps-lightweight-cmp-profile-11 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 17 October 2022. 42 Copyright Notice 44 Copyright (c) 2022 IETF Trust and the persons identified as the 45 document authors. All rights reserved. 47 This document is subject to BCP 78 and the IETF Trust's Legal 48 Provisions Relating to IETF Documents (https://trustee.ietf.org/ 49 license-info) in effect on the date of publication of this document. 50 Please review these documents carefully, as they describe your rights 51 and restrictions with respect to this document. Code Components 52 extracted from this document must include Revised BSD License text as 53 described in Section 4.e of the Trust Legal Provisions and are 54 provided without warranty as described in the Revised BSD License. 56 Table of Contents 58 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 4 59 1.1. How to Read This Document . . . . . . . . . . . . . . . . 4 60 1.2. Motivation for a Lightweight Profile of CMP . . . . . . . 5 61 1.3. Special Requirements of Industrial and IoT Scenarios . . 6 62 1.4. Existing CMP Profiles . . . . . . . . . . . . . . . . . . 7 63 1.5. Use of CMP in SZTP and BRSKI Environments . . . . . . . . 7 64 1.6. Compatibility with Existing CMP Profiles . . . . . . . . 8 65 1.7. Scope of this Document . . . . . . . . . . . . . . . . . 10 66 1.8. Structure of this Document . . . . . . . . . . . . . . . 10 67 1.9. Convention and Terminology . . . . . . . . . . . . . . . 11 68 2. Solution Architecture . . . . . . . . . . . . . . . . . . . . 12 69 3. Generic Aspects of PKI Messages and PKI Management 70 Operations . . . . . . . . . . . . . . . . . . . . . . . 14 71 3.1. General Description of the CMP Message Header . . . . . . 15 72 3.2. General Description of the CMP Message Protection . . . . 17 73 3.3. General Description of CMP Message ExtraCerts . . . . . . 17 74 3.4. Generic PKI Management Operation Prerequisites . . . . . 18 75 3.5. Generic Validation of a PKI Message . . . . . . . . . . . 19 76 3.6. Error Handling . . . . . . . . . . . . . . . . . . . . . 21 77 3.6.1. Reporting Error Conditions Upstream . . . . . . . . . 21 78 3.6.2. Reporting Error Conditions Downstream . . . . . . . . 22 79 3.6.3. Handling Error Conditions on Nested Messages Used for 80 Batching . . . . . . . . . . . . . . . . . . . . . . 22 81 3.6.4. PKIStatusInfo and Error Messages . . . . . . . . . . 23 82 4. PKI Management Operations . . . . . . . . . . . . . . . . . . 25 83 4.1. Enrolling End Entities . . . . . . . . . . . . . . . . . 27 84 4.1.1. Enrolling an End Entity to a New PKI . . . . . . . . 28 85 4.1.2. Enrolling an End Entity to a Known PKI . . . . . . . 34 86 4.1.3. Updating a Valid Certificate . . . . . . . . . . . . 35 87 4.1.4. Enrolling an End Entity Using a PKCS#10 Request . . . 36 88 4.1.5. Using MAC-Based Protection for Enrollment . . . . . . 38 89 4.1.6. Adding Central Key Pair Generation to Enrollment . . 39 90 4.1.6.1. Using Key Agreement Key Management Technique . . 45 91 4.1.6.2. Using Key Transport Key Managemen Technique . . . 46 92 4.1.6.3. Using Password-Based Key Management Technique . . 47 93 4.2. Revoking a Certificate . . . . . . . . . . . . . . . . . 48 94 4.3. Support Messages . . . . . . . . . . . . . . . . . . . . 50 95 4.3.1. Get CA Certificates . . . . . . . . . . . . . . . . . 53 96 4.3.2. Get Root CA Certificate Update . . . . . . . . . . . 53 97 4.3.3. Get Certificate Request Template . . . . . . . . . . 55 98 4.3.4. CRL Update Retrieval . . . . . . . . . . . . . . . . 57 99 4.4. Handling Delayed Delivery . . . . . . . . . . . . . . . . 59 100 5. PKI Management Entity Operations . . . . . . . . . . . . . . 64 101 5.1. Responding to Requests . . . . . . . . . . . . . . . . . 64 102 5.1.1. Responding to a Certificate Request . . . . . . . . . 65 103 5.1.2. Responding to a Confirmation Message . . . . . . . . 65 104 5.1.3. Responding to a Revocation Request . . . . . . . . . 66 105 5.1.4. Responding to a Support Message . . . . . . . . . . . 66 106 5.1.5. Initiating Delayed Delivery . . . . . . . . . . . . . 66 107 5.2. Forwarding Messages . . . . . . . . . . . . . . . . . . . 67 108 5.2.1. Not Changing Protection . . . . . . . . . . . . . . . 69 109 5.2.2. Adding Protection and Batching of Messages . . . . . 69 110 5.2.2.1. Adding Protection to a Request Message . . . . . 70 111 5.2.2.2. Batching Messages . . . . . . . . . . . . . . . . 71 112 5.2.3. Replacing Protection . . . . . . . . . . . . . . . . 73 113 5.2.3.1. Not Changing Proof-of-Possession . . . . . . . . 73 114 5.2.3.2. Using raVerified . . . . . . . . . . . . . . . . 74 115 5.3. Acting on Behalf of other PKI Entities . . . . . . . . . 74 116 5.3.1. Requesting a Certificate . . . . . . . . . . . . . . 75 117 5.3.2. Revoking a Certificate . . . . . . . . . . . . . . . 75 118 6. CMP Message Transfer Mechanisms . . . . . . . . . . . . . . . 76 119 6.1. HTTP Transfer . . . . . . . . . . . . . . . . . . . . . . 77 120 6.2. CoAP Transfer . . . . . . . . . . . . . . . . . . . . . . 79 121 6.3. Piggybacking on other Reliable Transfer . . . . . . . . . 81 122 6.4. Offline Transfer . . . . . . . . . . . . . . . . . . . . 81 123 6.4.1. File-Based Transfer . . . . . . . . . . . . . . . . . 82 124 6.4.2. Other Asynchronous Transfer Protocols . . . . . . . . 82 125 7. Conformance Requirements . . . . . . . . . . . . . . . . . . 82 126 7.1. PKI Management Operations . . . . . . . . . . . . . . . . 82 127 7.2. Message Transfer . . . . . . . . . . . . . . . . . . . . 85 128 8. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 86 129 9. Security Considerations . . . . . . . . . . . . . . . . . . . 88 130 10. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 88 131 11. References . . . . . . . . . . . . . . . . . . . . . . . . . 88 132 11.1. Normative References . . . . . . . . . . . . . . . . . . 88 133 11.2. Informative References . . . . . . . . . . . . . . . . . 90 134 Appendix A. Example CertReqTemplate . . . . . . . . . . . . . . 92 135 Appendix B. History of Changes . . . . . . . . . . . . . . . . . 94 136 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 100 138 1. Introduction 140 [RFC Editor: please delete]: The labels "RFC-CMP-Updates" and "RFC- 141 CMP-Alg" in ASN.1 Syntax need to be replaced with the RFC numbers of 142 CMP Updates [I-D.ietf-lamps-cmp-updates] and CMP Algorithms 143 [I-D.ietf-lamps-cmp-algorithms], when available. 145 This document specifies PKI management operations supporting machine- 146 to-machine and IoT use cases. Its focus is to maximize automation 147 and interoperability between all involved PKI entities, ranging from 148 end entities (EE) over any number of intermediate PKI management 149 entities such as Registration Authorities (RA) to the CMP endpoints 150 of Certification Authority (CA) systems. This profile makes use of 151 the concepts and syntax specified in CMP [RFC4210], 152 [I-D.ietf-lamps-cmp-updates], and [I-D.ietf-lamps-cmp-algorithms], 153 CRMF [RFC4211] and [RFC9045], CMS [RFC5652] and [RFC8933], HTTP 154 transfer for CMP [RFC6712], and CoAP transfer for CMP 155 [I-D.ietf-ace-cmpv2-coap-transport]. Especially CMP, CRMF, and CMS 156 are very feature-rich standards, while in most application scenarios 157 only a limited subset of the specified functionality is needed. 158 Additionally, the standards are not always precise enough on how to 159 interpret and implement the described concepts. Therefore, this 160 document aims at tailoring the available options and specifying at an 161 adequate detail how to use them to make the implementation of 162 interoperable automated certificate management as straightforward and 163 lightweight as possible. 165 1.1. How to Read This Document 167 This document has become longer than the authors would have liked it 168 to be. Yet apart from studying Section 3, which contains general 169 requirements, the reader does not have to work through the whole 170 document. The guidance in Section 1.8 and Section 7 should be used 171 to figure out which parts of Section 4 to Section 6 are relevant for 172 the target certificate management solution depending on the PKI 173 management operations, their variants, and types of message transfer 174 needed. 176 Since conformity to this document can be achieved by implementing 177 only the functionality declared mandatory in Section 7, the profile 178 can still be called lightweight because in particular for end 179 entities the mandatory-to-implement set of features is rather 180 limited. 182 1.2. Motivation for a Lightweight Profile of CMP 184 CMP was standardized in 1999 and is implemented in several PKI 185 products. In 2005, a completely reworked and enhanced version 2 of 186 CMP [RFC4210] and CRMF [RFC4211] has been published, followed by a 187 document specifying a transfer mechanism for CMP messages using HTTP 188 [RFC6712] in 2012. 190 Though CMP is a solid and very capable protocol it is so far not used 191 very widely. The most important reason appears to be that the 192 protocol offers a too large set of features and options. On the one 193 hand, this makes CMP applicable to a very wide range of scenarios, 194 but on the other hand, a full implementation supporting all options 195 is not realistic because this would take undue effort. 197 In order to reduce complexity, the set of mandatory PKI management 198 operations and variants required by this specification has been kept 199 lean. This limits development effort and minimizes resource needs, 200 which is particularly important for memory-constrained devices. To 201 this end, when there was a choice to have necessary complexity more 202 on the EE or PKI management entity side, it has been pushed towards 203 PKI management entities, where typically more computational resources 204 are available and the development can be consolidated better. 205 Additional recommended PKI management operations and variants support 206 some more complex scenarios that are considered beneficial for 207 environments with more specific demands or boundary conditions. The 208 optional PKI management operations support less common scenarios and 209 requirements. 211 Moreover, many details of the CMP protocol have been left open or 212 have not been specified in full preciseness. The profiles specified 213 in Appendix D and E of [RFC4210] define some more detailed PKI 214 management operations. Yet, the specific needs of highly automated 215 scenarios for a machine-to-machine communication are not covered 216 sufficiently. 218 As also 3GPP and UNISIG already put across, profiling is a way of 219 coping with the challenges mentioned above. To profile means to take 220 advantage of the strengths of the given protocol, while explicitly 221 narrowing down the options it provides to those needed for the 222 purpose(s) at hand and eliminating all identified ambiguities. In 223 this way all the general and applicable aspects of the general 224 protocol are taken over and only the peculiarities of the target 225 scenarios need to be dealt with specifically. 227 Defining a profile for a new target environment takes high effort 228 because the range of available options needs to be well understood 229 and the selected options need to be consistent with each other and 230 suitably cover the intended application scenario. Since most 231 industrial PKI management use cases typically have much in common it 232 is worth sharing this effort, which is the aim of this document. 233 Other standardization bodies can reference this document and do not 234 need to come up with individual profiles from scratch. 236 1.3. Special Requirements of Industrial and IoT Scenarios 238 The profiles specified in Appendix D and E of RFC 4210 [RFC4210] have 239 been developed particularly for managing certificates of human end 240 entities. With the evolution of distributed systems and client- 241 server architectures, certificates for machines and applications on 242 them have become widely used. This trend has strengthened even more 243 in emerging industrial and IoT scenarios. CMP is sufficiently 244 flexible to support them well. 246 Today's IT security architectures for industrial solutions typically 247 use certificates for endpoint authentication within protocols like 248 IPsec, TLS, or SSH. Therefore, the security of these architectures 249 highly relies upon the security and availability of the implemented 250 certificate management operations. 252 Due to increasing security needs in operational networks as well as 253 availability requirements, especially on critical infrastructures and 254 systems with a high number of certificates, a state-of-the-art 255 certificate management system must be constantly available and cost- 256 efficient, which calls for high automation and reliability. 257 Consequently, the NIST Framework for Improving Critical 258 Infrastructure Cybersecurity [NIST.CSWP.04162018] refers to proper 259 processes for issuance, management, verification, revocation, and 260 audit for authorized devices, users, and processes involving identity 261 and credential management. Such PKI management operations according 262 to commonly accepted best practices are also required in 263 IEC 62443-3-3 [IEC.62443-3-3] for security level 2 and higher. 265 Further challenges in many industrial systems are network 266 segmentation and asynchronous communication, while PKI management 267 entities like Certification Authorities (CA) typically are not 268 deployed on-site but in a more protected environment of a data center 269 or trust center. Certificate management must be able to cope with 270 such network architectures. CMP offers the required flexibility and 271 functionality, namely self-contained messages, efficient polling, and 272 support for asynchronous message transfer while retaining end-to-end 273 security. 275 1.4. Existing CMP Profiles 277 As already stated, RFC 4210 [RFC4210] contains profiles with 278 mandatory and optional PKI management operations in Appendix D and E. 279 Those profiles focus on management of human user certificates and 280 only partly address the specific needs of certificate management 281 automation for unattended devices or machine-to-machine application 282 scenarios. 284 Both Appendixes D and E focus on EE-to-RA/CA PKI management 285 operations and do not address further profiling of RA-to-CA 286 communication as typically needed for full backend automation. All 287 requirements regarding algorithm support for RFC 4210 Appendix D and 288 E [RFC4210] have been updated by CMP Algorithms Section 7.1 289 [I-D.ietf-lamps-cmp-algorithms]. 291 3GPP makes use of CMP [RFC4210] in its Technical Specification 33.310 292 [ETSI-3GPP.33.310] for automatic management of IPsec certificates in 293 3G, LTE, and 5G backbone networks. Since 2010, a dedicated CMP 294 profile for initial certificate enrollment and certificate update 295 operations between EE and RA/CA is specified in that document. 297 UNISIG has included a CMP profile for enrollment of TLS certificates 298 in the Subset-137 specifying the ETRAM/ETCS on-line key management 299 for train control systems [UNISIG.Subset-137] in 2015. 301 Both standardization bodies tailor CMP [RFC4210], CRMF [RFC4211], and 302 HTTP transfer for CMP [RFC6712] for highly automated and reliable PKI 303 management operations for unattended devices and services. 305 1.5. Use of CMP in SZTP and BRSKI Environments 307 In Secure Zero Touch Provisioning (SZTP) [RFC8572] and other 308 environments using NETCONF/YANG modules, SZTP-CSR 309 [I-D.ietf-netconf-sztp-csr] offers a YANG module that includes 310 different types of certificate requests to obtain a public-key 311 certificate for a locally generated key pair. One option is using a 312 CMP p10cr message. Such a message is of the form ietf-ztp-types:cmp- 313 csr from module ietf-ztp-csr and offers both proof-of-possession and 314 proof-of-identity. To allow PKI management entities to also comply 315 with this profile, the p10cr message must be formatted by the EE as 316 described in Section 4.1.4 of this profile, and it may be forwarded 317 as specified in Section 5.2. 319 In Bootstrapping Remote Secure Key Infrastructure (BRSKI) [RFC8995] 320 environments, BRSKI Asynchronous Enrollment BRSKI Asynchronous 321 Enrollment [I-D.ietf-anima-brski-ae] describes a generalization 322 regarding the employed enrollment protocols to allow alternatives to 323 EST [RFC7030]. For the use of CMP, it requires adherence to this 324 profile. 326 1.6. Compatibility with Existing CMP Profiles 328 The profile specified in this document is compatible with RFC 4210 329 Appendixes D and E (PKI Management Message Profiles) [RFC4210], with 330 the following exceptions: 332 * signature-based protection is the default protection; an initial 333 PKI management operation may also use MAC-based protection, 335 * certification of a second key pair within the same PKI management 336 operation is not supported, 338 * proof-of-possession (POPO) with self-signature of the certTemplate 339 according to RFC 4211 Section 4.1 [RFC4211] clause 3 is the 340 recommended default POPO method (deviations are possible for EEs 341 when requesting central key generation, for RAs when using 342 raVerified, and if the newly generated keypair is technically not 343 capable to generate digital signatures), 345 * confirmation of newly enrolled certificates may be omitted, and 347 * all PKI management operations consist of request-response message 348 pairs originating at the EE, i.e., announcement messages 349 (requiring a push model, a CMP server on the EE) are excluded in 350 favor of a lightweight implementation on the EE. 352 The profile specified in this document is compatible with the CMP 353 profile for 3G, LTE, and 5G network domain security and 354 authentication framework [ETSI-3GPP.33.310], except that: 356 * protection of initial PKI management operations may be MAC-based, 358 * the subject field is mandatory in certificate templates, and 360 * confirmation of newly enrolled certificates may be omitted. 362 The profile specified in this document is compatible with the CMP 363 profile for on-line key management in rail networks as specified in 364 UNISIG Subset-137 [UNISIG.Subset-137], except that: 366 * A certificate enrollment request message consists of only one 367 certificate request (CertReqMsg). 369 * RFC 4210 [RFC4210] requires that the messageTime is Greenwich Mean 370 Time coded as generalizedTime. 372 Note: As UNISIG Subset-137 Table 5 [UNISIG.Subset-137] explicitly 373 states that the messageTime in required to be "UTC time", it is 374 not clear if this means a coding as UTCTime or generalizedTime and 375 if other time zones than Greenwich Mean Time shall be allowed. 376 Both time formats are described in RFC 5280 Section 4.1.2.5 377 [RFC5280]. 379 * The same type of protection is required to be used for all 380 messages of one PKI management operation. This means, in case the 381 request message protection is MAC-based, also the response, 382 certConf, and pkiConf messages must have a MAC-based protection. 384 * Use of caPubs is not required but typically allowed in combination 385 with MAC-based protected PKI management operations. On the other 386 hand UNISIG Subset-137 Table 12 [UNISIG.Subset-137] requires using 387 caPubs. 389 Note: It remains unclear from UNISIG Subset-137 for which 390 certificate(s) the caPubs field should be used. For security 391 reasons, it cannot be used for delivering the root CA certificate 392 needed for validating the signature-based protection of the given 393 response message (as stated indirectly also in its UNISIG 394 Subset-137 Section 6.3.1.5.2 b [UNISIG.Subset-137]). 396 * This profile requires that the certConf message has one CertStatus 397 element where the statusInfo field is recommended. 399 Note: In contrast, UNISIG Subset-137 Table 18 [UNISIG.Subset-137] 400 requires that the certConf message has one CertStatus element 401 where the statusInfo field must be absent. This precludes sending 402 a negative certConf message in case the EE rejects the newly 403 enrolled certificate. This results in violating the general rule 404 that a certificate request transaction must include a certConf 405 message (since moreover, using implicitConfirm is not allowed 406 there, neither). 408 1.7. Scope of this Document 410 To minimize ambiguity and complexity through needless variety, this 411 document specifies exhaustive requirements on generating PKI 412 management messages on the sender side. On the other hand, it gives 413 only minimal requirements on checks by the receiving side and how to 414 handle error cases. 416 Especially on the EE side this profile aims at a lightweight 417 implementation. This means that the number of PKI management 418 operations implementations are reduced to a reasonable minimum to 419 support typical certificate management use cases in industrial 420 machine-to-machine environments. On the EE side only limited 421 resources are expected, while on the side of the PKI management 422 entities the profile accepts higher requirements. 424 For the sake of interoperability and robustness, implementations 425 should, as far as security is not affected, adhere to Postel's law: 426 "Be conservative in what you do, be liberal in what you accept from 427 others" (often reworded as: "Be conservative in what you send, be 428 liberal in what you receive"). 430 When in Section 3, Section 4, and Section 5 a field of the ASN.1 431 syntax as defined in CMP [RFC4210] and [I-D.ietf-lamps-cmp-updates], 432 CRMF [RFC4211], and CMS [RFC5652] and [RFC8933] is not explicitly 433 specified, it SHOULD NOT be used by the sending entity. The 434 receiving entity MUST NOT require its absence and if present MUST 435 gracefully handle its presence. 437 1.8. Structure of this Document 439 Section 2 introduces the general PKI architecture and approach to 440 certificate management that is assumed in this document. Then it 441 lists the PKI management operations specified in this document, 442 partitioning them into mandatory, recommended, and optional ones. 444 Section 3 profiles the generic aspects of the PKI management 445 operations specified in detail in Section 4 and Section 5 to minimize 446 redundancy in the description and to ease implementation. This 447 covers the general structure and protection of messages, as well as 448 generic prerequisites, validation, and error handling. 450 Section 4 profiles the exchange of CMP messages between an EE and the 451 PKI management entity. There are various flavors of certificate 452 enrollment requests, optionally with polling, central key generation, 453 revocation, and general support PKI management operations. 455 Section 5 profiles responding to requests, exchange between PKI 456 management entities, and operations on behalf of other PKI entities. 457 This may include delayed delivery of messages, which involves polling 458 for responses, and nesting of messages. 460 Section 6 outlines several mechanisms for CMP message transfer, 461 including HTTP-based [RFC6712] transfer optionally using TLS, and 462 [I-D.ietf-ace-cmpv2-coap-transport] transfer optionally using DTLS, 463 and offline file-based transport. 465 Section 7 defines which parts of the profile are mandatory, 466 recommended, optional, or not relevant to implement for which type of 467 entity. 469 1.9. Convention and Terminology 471 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 472 "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and 473 "OPTIONAL" in this document are to be interpreted as described in BCP 474 14 [RFC2119] [RFC8174] when, and only when, they appear in all 475 capitals, as shown here. 477 Technical terminology is used in conformance with RFC 4210 [RFC4210], 478 RFC 4211 [RFC4211], RFC 5280 [RFC5280], and IEEE 802.1AR 479 [IEEE.802.1AR_2018]. The following key words are used: 481 CA: Certification authority, which issues certificates. 483 RA: Registration authority, an optional PKI component to which a CA 484 delegates certificate management functions such as end entity 485 authentication and authorization checks for incoming requests. 486 An RA can also provide conversion between various certificate 487 management protocols and other protocols providing some 488 operations related to certificate management. 490 LRA: Local registration authority, a specific form of RA with 491 proximity to the end entities. 493 Note: For ease of reading, this document uses the term "RA" 494 also for LRAs in all cases where the difference is not 495 relevant. 497 KGA: Key generation authority, an optional system component, 498 typically co-located with an RA or CA, that offers key 499 generation services to end entities. 501 EE: End entity, typically a device or service that holds a public- 502 private key pair for which it manages a public-key certificate. 503 An identifier for the EE is given as the subject of its 504 certificate. 506 The following terminology is reused from RFC 4210 [RFC4210], as 507 follows: 509 PKI management operation: All CMP messages belonging to a single 510 transaction. The transaction is 511 identified by the transactionID field of 512 the message headers. 514 PKI management entity: A non-EE PKI entity, i.e., RA or CA. 516 PKI entity: An EE or PKI management entity. 518 2. Solution Architecture 520 To facilitate secure automatic certificate enrollment, the device 521 hosting an EE is typically equipped with a manufacturer-issued device 522 certificate. Such a certificate is typically installed during 523 production and is meant to identify the device throughout its 524 lifetime. This certificate can be used to protect the initial 525 enrollment of operational certificates after installation of the EE 526 in its operational environment. In contrast to the manufacturer- 527 issued device certificate, operational certificates are issued by the 528 owner or operator of the device to identify the device or one of its 529 components for operational use, e.g., in a security protocol like 530 IPsec, TLS, or SSH. In IEEE 802.1AR [IEEE.802.1AR_2018] a 531 manufacturer-issued device certificate is called IDevID certificate 532 and an operational certificate is called LDevID certificate. 534 Note: According to IEEE 802.1AR [IEEE.802.1AR_2018] a DevID comprises 535 the triple of the certificate, the corresponding private key, and the 536 certificate chain. 538 All certificate management operations specified in this document 539 follow the pull model, i.e., are initiated by an EE (or by an RA 540 acting as an EE). The EE creates a CMP request message, protects it 541 using some asymmetric credential or shared secret information and 542 sends it to its locally reachable PKI management entity. This PKI 543 management entity may be a CA or more typically an RA, which checks 544 the request, responds to it itself, or forwards the request upstream 545 to the next PKI management entity. In case an RA changes the CMP 546 request message header or body or wants to demonstrate successful 547 verification or authorization, it can apply a protection of its own. 548 Especially the communication between an LRA and RA can be performed 549 synchronously or asynchronously. Synchronous communication describes 550 a timely uninterrupted communication between two communication 551 partners, while asynchronous communication is not performed in a 552 timely consistent manner, e.g., because of a delayed message 553 delivery. 555 +-----+ +-----+ +-----+ +-----+ 556 | | | | | | | | 557 | EE |<---------->| LRA |<-------------->| RA |<---------->| CA | 558 | | | | | | | | 559 +-----+ +-----+ +-----+ +-----+ 561 synchronous (a)synchronous (a)synchronous 562 +----connection----+------connection------+----connection----+ 564 operators service partner 565 +---------on site--------+----back-end services-----+-trust center-+ 567 Figure 1: Certificate Management Architecture Example 569 In operational environments the certificate management architecture 570 can have multiple LRAs bundling requests from multiple EEs at 571 dedicated locations and one (or more than one) central RA aggregating 572 the requests from the LRAs. Every LRA in this scenario has shared 573 secret information (one per EE) for MAC-based protection or a CMP 574 protection key and certificate allowing it to (re-)protect CMP 575 messages it processes. The figure above shows an architecture 576 example with at least one LRA, RA, and CA. It is also possible not 577 to have an RA or LRA or that there is no CA with a CMP interface. 578 Depending on the network infrastructure, the message transfer between 579 PKI management entities may be based on synchronous online 580 connections, asynchronous connections, or even offline (e.g., file- 581 based) transfer. 583 Note: CMP response messages could also be used proactively to 584 implement the push model towards the EE. In this case the EE acts as 585 receiver, not initiating the interaction with the PKI. Also, when 586 using a commissioning tool or a registrar agent as described in BRSKI 587 with Pledge in Responder Mode (BRSKI-PRM) [I-D.ietf-anima-brski-prm], 588 certificate enrollment in a push model is needed. CMP in general and 589 the messages specified in this profile offer all required 590 capabilities, but the message flow and state machine as described in 591 Section 4 must be adapted to implement a push model. 593 Third-party CAs may implement other variants of CMP, different 594 standardized protocols, or even proprietary interfaces for 595 certificate management. Therefore, the RA may need to adapt the 596 exchanged CMP messages to the flavor of certificate management 597 interaction required by the CA. 599 3. Generic Aspects of PKI Messages and PKI Management Operations 601 This section covers the generic aspects of the PKI management 602 operations specified in Section 4 and Section 5 as upfront general 603 requirements to minimize redundancy in the description and to ease 604 implementation. 606 As described in Section 5.1 of RFC 4210 [RFC4210], all CMP messages 607 have the following general structure: 609 +--------------------------------------------+ 610 | PKIMessage | 611 | +----------------------------------------+ | 612 | | header | | 613 | +----------------------------------------+ | 614 | +----------------------------------------+ | 615 | | body | | 616 | +----------------------------------------+ | 617 | +----------------------------------------+ | 618 | | protection (OPTIONAL) | | 619 | +----------------------------------------+ | 620 | +----------------------------------------+ | 621 | | extraCerts (OPTIONAL) | | 622 | +----------------------------------------+ | 623 +--------------------------------------------+ 625 Figure 2: CMP Message Structure 627 The general contents of the message header, protection, and 628 extraCerts fields are specified in the following three subsections. 630 In case a specific PKI management operation needs different contents 631 in the header, protection, or extraCerts fields, the differences are 632 described in the respective subsections. 634 The CMP message body contains the PKI management operation-specific 635 information. It is described in Section 4 and Section 5. 637 The generic prerequisites needed by the PKI entities in order to be 638 able to perform PKI management operations are described in 639 Section 3.4. 641 The generic validation steps to be performed by PKI entities on 642 receiving a CMP message are described in Section 3.5. 644 The generic aspects of handling and reporting errors are described in 645 Section 3.6. 647 3.1. General Description of the CMP Message Header 649 This section describes the generic header fields of all CMP messages 650 with signature-based protection. 652 In case a message has MAC-based protection the changes are described 653 in Section 4.1.5. The variations will affect the fields sender, 654 protectionAlg, and senderKID. 656 Any PKI management operation-specific fields or variations are 657 described in Section 4 and 5. 659 header 660 pvno REQUIRED 661 -- MUST be 3 to indicate CMP v3 in all cases where EnvelopedData 662 -- is supported and expected to be used in the current 663 -- PKI management operation 664 -- MUST be 3 to indicate CMP v3 in certConf messages when using 665 -- the hashAlg field 666 -- MUST be 2 to indicate CMP v2 in all other cases 667 -- For details on version negotiation see RFC-CMP-Updates 668 sender REQUIRED 669 -- SHOULD contain a name representing the originator of the 670 -- message; otherwise, the NULL-DN (a zero-length 671 -- SEQUENCE OF RelativeDistinguishedNames) MUST be used 672 -- SHOULD be the subject of the CMP protection certificate, i.e., 673 -- the certificate corresponding to the private key used to sign 674 -- the message 675 -- In a multi-hop scenario, the receiving entity SHOULD NOT rely 676 -- on the correctness of the sender field. 677 recipient REQUIRED 678 -- SHOULD be the name of the intended recipient; otherwise, the 679 -- NULL-DN MUST be used 680 -- In the first message of a PKI management operation: 681 -- SHOULD be the subject DN of the CA the PKI management 682 -- operation is requested from 683 -- In all other messages: 684 -- SHOULD contain the value of the sender field of the previous 685 -- message in the same PKI management operation 686 -- The recipient field SHALL be handled gracefully by the 687 -- receiving entity, because in a multi-hop scenario its 688 -- correctness cannot be guaranteed. 689 messageTime RECOMMENDED 690 -- MUST be the time at which the message was produced, if present 691 protectionAlg REQUIRED 692 -- MUST be an algorithm identifier indicating the algorithm 693 -- used for calculating the protection bits 694 -- If it is a signature algorithm its type MUST be a 695 -- MSG_SIG_ALG as specified in [RFC-CMP-Alg] Section 3 and 696 -- MUST be consistent with the subjectPublicKeyInfo field of 697 -- the protection certificate 698 -- If it is a MAC algorithm its type MUST be a MSG_MAC_ALG as 699 -- specified in [RFC-CMP-Alg] Section 6.1 700 senderKID RECOMMENDED 701 -- MUST be the SubjectKeyIdentifier of the CMP protection 702 -- certificate in case of signature-based protection 703 transactionID REQUIRED 704 -- In the first message of a PKI management operation: 705 -- MUST be 128 bits of random data, to minimize the probability 706 -- of having the transactionID already in use at the server 707 -- In all other messages: 708 -- MUST be the value from the previous message in the same 709 -- PKI management operation 710 senderNonce REQUIRED 711 -- MUST be cryptographically secure and fresh 128 random bits 712 recipNonce RECOMMENDED 713 -- If this is the first message of a transaction: SHOULD be 714 -- absent 715 -- If this is a delayed response message: MUST be present and 716 -- contain the value of the senderNonce of the respective request 717 -- message in the same transaction 718 -- In all other messages: MUST be present and contain the value 719 -- of the senderNonce of the previous message in the same 720 -- transaction 721 generalInfo OPTIONAL 722 implicitConfirm OPTIONAL 723 -- RECOMENDED in ir/cr/kur/p10cr messages, 724 -- OPTIONAL in ip/cp/kup response messages, and 725 -- PROHIBITED in other types of messages 726 -- Added to request messages to request omission of the certConf 727 -- message 728 -- Added to response messages to grant omission of the certConf 729 -- message 730 -- See [RFC4210] Section 5.1.1.1. 731 ImplicitConfirmValue REQUIRED 732 -- ImplicitConfirmValue MUST be NULL 733 certProfile OPTIONAL 734 -- MAY be present in ir/cr/kur/p10cr and in genm messages of type 735 -- id-it-certReqTemplate 736 -- MUST be omitted in all other messages 737 -- See [RFC-CMP-Updates] 738 CertProfileValue REQUIRED 739 -- MUST contain exactly one UTF8String element 740 -- MUST contain the name of a certificate profile 742 3.2. General Description of the CMP Message Protection 744 This section describes the generic protection field contents of all 745 CMP messages with signature-based protection, which is the default 746 protection mechanism for all CMP messages described in this profile. 747 The private key used to sign a CMP message is called "protection key" 748 and the related certificate is called "protection certificate". Any 749 included keyUsage extension SHOULD allow digitalSignature. 751 protection 752 -- RECOMMENDED for error messages 753 -- REQUIRED for all other messages 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 messages MUST be protected, but there are cases where 759 protection of error messages specified in Section 3.6.4 is not 760 possible and therefore MAY be omitted. 762 For MAC-based protection as specified in Section 4.1.5 and 763 Section 4.1.6.3 major 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 based on local PKI policy. 858 3.5. Generic Validation of a PKI Message 860 This section describes generic validation steps of each PKI entity 861 receiving a PKI request or response message before any further 862 processing or forwarding. If a PKI management entity decides to 863 terminate a PKI management operation because a check failed, it MUST 864 send a negative response or an error message as described in 865 Section 3.6. The PKIFailureInfo bits given below in parentheses MAY 866 be used in the failInfo field of the PKIStatusInfo as described in 867 Section 3.6.4, see also RFC 4210 Appendix F [RFC4210]. 869 All PKI message header fields not mentioned in this section like the 870 recipient and generalInfo fields SHOULD be handled gracefully on 871 reception. 873 The following list describes the basic set of message input 874 validation steps. Without these checks the protocol becomes 875 dysfunctional. 877 * The formal ASN.1 syntax of the whole message MUST be compliant 878 with the definitions given in CMP [RFC4210] and 879 [I-D.ietf-lamps-cmp-updates], CRMF [RFC4211], and CMS [RFC5652] 880 and [RFC8933]. (failInfo: badDataFormat) 882 * The pvno MUST be cmp2000(2) or cmp2021(3). (failInfo bit: 883 unsupportedVersion) 885 * The transactionID MUST be present. (failInfo bit: badDataFormat) 886 * The PKI message body type MUST be one of the message types 887 supported by the receiving PKI entity and MUST be allowed in the 888 current state of the PKI management operation identified by the 889 given transactionID. (failInfo bit: badRequest) 891 The following list describes the set of message input validation 892 steps required to ensure secure protocol operation: 894 * The senderNonce MUST be present and MUST contain at least 128 bits 895 of data. (failInfo bit: badSenderNonce) 897 * Unless the PKI message is the first message of a PKI management 898 operation, 900 - the recipNonce MUST be present and MUST equal the senderNonce 901 of the previous message or equal the senderNonce of the most 902 recent request message for which the response was delayed, in 903 case of delayed delivery as specified in Section 4.4. (failInfo 904 bit: badRecipientNonce) 906 * The message protection MUST be validated: 908 - The protection MUST be signature-based except if 910 o MAC-based protection is used as described in Section 4.1.5 911 and Section 4.1.6.3 or 913 o protection is omitted in certain error messages as described 914 in Section 3.6.4. 916 (failInfo bit: wrongIntegrity) 918 - The senderKID SHOULD identify the key material used for 919 verifying the message protection. (failInfo bit: 920 badMessageCheck) 922 - The protection, if present, MUST be validated successfully. If 923 signature-based protection is used, the CMP protection 924 certificate MUST be successfully validated including path 925 validation using a trust anchor and MUST be authorized 926 according to local policies. If the keyUsage extension is 927 present in the CMP protection certificate the digitalSignature 928 bit SHOULD be set. (failInfo bit: badAlg, badMessageCheck, or 929 signerNotTrusted) 931 - The sender of a request message MUST be authorized for 932 requesting the operation according to PKI policies. (failInfo 933 bit: notAuthorized) 935 Note: The requirements for checking certificates given in RFC 5280 936 [RFC5280] MUST be followed for signature-based CMP message 937 protection. Unless the message is a positive ip/cp/kup where the 938 issuing CA certificate of the newly enrolled certificate is the same 939 as the CMP protection certificate of that message, certificate status 940 checking SHOULD be performed on the CMP protection certificates. 942 Depending on local policies, one or more of the input validation 943 checks described below need to be implemented: 945 * If signature-based protection is used, the sender field SHOULD 946 match the subject of the CMP protection certificate. (failInfo 947 bit: badMessageCheck) 949 * If the messageTime is present, it SHOULD be close to the current 950 time. (failInfo bit: badTime) 952 3.6. Error Handling 954 This section describes how a PKI entity handles error conditions on 955 messages it receives. Each error condition SHOULD be logged 956 appropriately. 958 3.6.1. Reporting Error Conditions Upstream 960 An EE SHALL NOT send error messages. PKI management entities SHALL 961 NOT send error messages in upstream direction, either. 963 In case an EE rejects a newly issued certificate contained in an ip, 964 cp, or kup message and implicit confirmation has not been granted, 965 the EE MUST report this using a certConf message with "rejection" 966 status and await the pkiConf response as described in Section 4.1.1. 968 On all other error conditions regarding response messages, the EE or 969 PKI management entity MUST regard the current PKI management 970 operation as terminated with failure. The error conditions include 972 * invalid response message header, body type, protection, or 973 extraCerts according to the checks described in Section 3.5, 975 * any issue detected with response message contents, 977 * receipt of an error message from upstream, 979 * timeout occurred while waiting for a response, 981 * rejection of a newly issued certificate while implicit 982 confirmation has been granted. 984 Upstream PKI management entities will not receive any CMP message to 985 learn that the PKI management operation has been terminated. In case 986 they expect a further message from the EE, a connection interruption 987 or timeout will occur. Then they also MUST regard the current PKI 988 management operation as terminated with failure and MUST NOT attempt 989 to send an error message downstream. 991 3.6.2. Reporting Error Conditions Downstream 993 In case the PKI management entity detects an error condition, e.g., 994 rejecting the request due to policy decision, in the body of an ir, 995 cr, p10cr, kur, or rr message received from downstream, it SHOULD 996 report the error in the specific response message, i.e., an ip, cp, 997 kup, or rp with "rejection" status, as described in Section 4.1.1 and 998 Section 4.2. This can also happen in case of polling. 1000 In case the PKI management entity detects any other error condition 1001 on requests, including pollReq, certConf, genm, and nested messages, 1002 received from downstream and on responses received from upstream, 1003 such as invalid message header, body type, protection, or extraCerts 1004 according to the checks described in Section 3.5 it MUST report them 1005 downstream in the form of an error message as described in 1006 Section 3.6.4. 1008 3.6.3. Handling Error Conditions on Nested Messages Used for Batching 1010 Batching of messages using nested messages as described in 1011 Section 5.2.2.2 requires special error handling. 1013 If the error condition is on an upstream nested message containing 1014 batched requests, it MUST NOT attempt to respond to the individual 1015 requests included in it. 1017 In case a PKI management entity receives an error message in response 1018 to a nested message, it must propagate the error by responding with 1019 an error message to each of the request messages contained in the 1020 nested message. 1022 In case a PKI management entity detects an error condition on the 1023 downstream nested message received in response to a nested message 1024 sent before, it MAY ignore this error condition and handle the 1025 response as described in Section 5.2.2.2. Otherwise, it MUST 1026 propagate the error by responding with an error message to each of 1027 the requests contained in the nested message it sent originally. 1029 3.6.4. PKIStatusInfo and Error Messages 1031 When sending any kind of negative response, including error messages, 1032 a PKI entity MUST indicate the error condition in the PKIStatusInfo 1033 structure of the respective message as described below. It then MUST 1034 regard the current PKI management operation as terminated with 1035 failure. 1037 The PKIStatusInfo structure is used to report errors. It may be part 1038 of various message types, in particular: certConf, ip, cp, kup, and 1039 error. The PKIStatusInfo structure consists of the following fields: 1041 * status: Here the PKIStatus value "rejection" MUST be used. 1043 Note: When a PKI management entity indicates delayed delivery of a 1044 CMP response message to the EE with an error message as described 1045 in Section 4.4, the status "waiting" is used there. 1047 * statusString: Here any human-readable valid value for logging or 1048 to display via a user interface SHOULD be added. 1050 * failInfo: Here the PKIFailureInfo bits MAY be used in the way 1051 explained in Appendix F of RFC 4210 [RFC4210]. PKIFailureInfo 1052 bits regarding the validation described in Section 3.5 are 1053 referenced there. The PKIFailureInfo bits referenced in 1054 Section 5.1 and Section 6 are described here: 1056 - badCertId: A kur, certConf, or rr message references an unknown 1057 certificate 1059 - badPOP: An ir/cr/p10cr/kur contains an invalid proof-of- 1060 possession 1062 - certRevoked: Revocation requested for a certificate already 1063 revoked 1065 - badCertTemplate: The contents of a certificate request are not 1066 accepted, e.g., a field is missing or has a non-acceptable 1067 value or the given public key is already in use in some other 1068 certificate (depending on policy). 1070 - transactionIdInUse: This is sent by a PKI management entity in 1071 case the received request contains a transactionID that has 1072 already been used for another transaction. An EE receiving 1073 such error message SHOULD resend the request in a new 1074 transaction using a different transactionID. 1076 - notAuthorized: The sender of a request message is not 1077 authorized for requesting the operation. 1079 - systemUnavail: This is sent by a PKI management entity in case 1080 a back-end system is not available. 1082 - systemFailure: This is sent by a PKI management entity in case 1083 a back-end system is currently not functioning correctly. 1085 An EE receiving a systemUnavail or systemFailure failInfo SHOULD 1086 resend the request in a new transaction after some time. 1088 Detailed Message Description: 1090 Error Message -- error 1092 Field Value 1094 header 1095 -- As described in Section 3.1 1097 body 1098 -- The message indicating the error that occurred 1099 error REQUIRED 1100 pKIStatusInfo REQUIRED 1101 status REQUIRED 1102 -- MUST have the value "rejection" 1103 statusString RECOMMENDED 1104 -- SHOULD be any human-readable text for debugging, logging 1105 -- or to display in a GUI 1106 failInfo OPTIONAL 1107 -- MAY be present and contain the relevant PKIFailureInfo bits 1109 protection RECOMMENDED 1110 -- As described in Section 3.2 1111 -- MAY be omitted if protection is technically not feasible 1113 extraCerts RECOMMENDED 1114 -- As described in Section 3.3 1116 Note: Protecting the error message may not be technically feasible if 1117 it is not clear which credential the recipient will be able to use 1118 when validating this protection, e.g., in case the request message 1119 was fundamentally broken. 1121 4. PKI Management Operations 1123 This chapter focuses on the communication of an EE with the PKI 1124 management entity it directly talks to. Depending on the network and 1125 PKI solution, this can be an RA or directly a CA. Handling of a 1126 message by a PKI management entity is described in Section 5. 1128 The PKI management operations specified in this section cover the 1129 following: 1131 * Requesting a certificate with variations like initial enrollment, 1132 certificate updates, central key generation, and MAC-based 1133 protection 1135 * Revoking a certificate 1137 * Support messages 1139 These operations mainly specify the message body of the CMP messages 1140 and utilize the specification of the message header, protection and 1141 extraCerts as specified in Section 3. The messages are named by the 1142 respective field names in PKIBody like ir, ip, cr, cp, etc., see 1143 RFC 4210 Section 5.1.2 [RFC4210]. 1145 The following diagram shows the EE state machine covering all PKI 1146 management operations described in this section, including negative 1147 responses, error messages described in Section 3.6.4, as well as 1148 ip/cp/kup/error messages with status "waiting", pollReq, and pollRep 1149 messages described in Section 4.4. 1151 On receiving messages from upstream, the EE MUST perform the general 1152 validation checks described in Section 3.5. The behavior in case an 1153 error occurs is described in Section 3.6. 1155 End Entity State Machine: 1156 start 1157 | 1158 | send ir/cr/p10cr/kur/rr/genm 1159 v 1160 waiting for response 1161 | 1162 +--------------------------+--------------------------+ 1163 | | | 1164 | receives ip/cp/kup with | received ip/cp/kup/error | received 1165 | status "accepted" or | with status "waiting" | rp/genp or 1166 | "grantedWithMods" | | ip/cp/kup/ 1167 | v | error 1168 | +-------> polling | with status 1169 | | | | "rejection" 1170 | | received | send | 1171 | | pollRep | pollReq | 1172 | | v | 1173 | | waiting for response | 1174 | | | | 1175 | +------------+--------+ | 1176 | | | | 1177 | received ip/cp/kup | | received | 1178 | with status "accepted" | | rp/genp or | 1179 | or "grantedWithMods" | | ip/cp/kup/error | 1180 | | | with status | 1181 +---------->+<-------------+ | "rejection" | 1182 | | | 1183 +-----------+-----+ | | 1184 | | | | 1185 | implicitConfirm | implicitConfirm | | 1186 | granted | not granted | | 1187 | | | | 1188 | | send certConf | | 1189 | v | | 1190 | waiting for pkiConf*) | | 1191 | | | | 1192 | | received | | 1193 | | pkiConf | | 1194 +-----------------+------->+<-------+-----------------+ 1195 | 1196 v 1197 end 1199 *) in case of a delayed delivery of pkiConf responses the same 1200 polling mechanism is initiated as for rp or genp messages, by 1201 sending an error message with status "waiting". 1203 Note: All CMP messages belonging to the same PKI management operation 1204 MUST have the same transactionID because the message receiver 1205 identifies the elements of the operation in this way. 1207 This section is aligned with CMP [RFC4210], CMP Updates 1208 [I-D.ietf-lamps-cmp-updates], and CMP Algorithms 1209 [I-D.ietf-lamps-cmp-algorithms]. 1211 Guidelines as well as an algorithm use profile for this document are 1212 available in CMP Algorithms [I-D.ietf-lamps-cmp-algorithms]. 1214 4.1. Enrolling End Entities 1216 There are various approaches for requesting a certificate from a PKI. 1218 These approaches differ in the way the EE authenticates itself to the 1219 PKI, in the form of the request being used, and how the key pair to 1220 be certified is generated. The authentication mechanisms may be as 1221 follows: 1223 * Using a certificate from an external PKI, e.g., a manufacturer- 1224 issued device certificate, and the corresponding private key 1226 * Using a private key and certificate issued from the same PKI that 1227 is addressed for requesting a certificate 1229 * Using the certificate to be updated and the corresponding private 1230 key 1232 * Using shared secret information known to the EE and the PKI 1233 management entity 1235 An EE requests a certificate indirectly or directly from a CA. When 1236 the PKI management entity handles the request as described in 1237 Section 5.1.1 and responds with a message containing the requested 1238 certificate, the EE MUST reply with a confirmation message unless 1239 implicitConfirm was granted. The PKI management entity then MUST 1240 handle it as described in Section 5.1.2 and respond with a 1241 confirmation, closing the PKI management operation. 1243 The message sequences described in this section allow the EE to 1244 request certification of a locally or centrally generated public- 1245 private key pair. Typically, the EE provides a signature-based 1246 proof-of-possession of the private key associated with the public key 1247 contained in the certificate request as defined by RFC 4211 1248 Section 4.1 [RFC4211] case 3. To this end it is assumed that the 1249 private key can technically be used for signing. This is the case 1250 for the most common algorithms RSA and ECDSA, regardless of 1251 potentially intended restrictions of the key usage. 1253 Note: In conformance with NIST SP 800-57 Part 1 Section 8.1.5.1.1.2 1254 [NIST.SP.800-57p1r5] the newly generated private key MAY be used for 1255 self-signature, if technically possible, even if the keyUsage 1256 extension requested in the certificate request prohibits generation 1257 of digital signatures. 1259 The requesting EE provides the binding of the proof-of-possession to 1260 its identity by signature-based or MAC-based protection of the CMP 1261 request message containing that POP. An upstream PKI management 1262 entity should verify whether this EE is authorized to obtain a 1263 certificate with the requested subject and other fields and 1264 extensions. 1266 The EE MAY indicate the certificate profile to use in the certProfile 1267 extension of the generalInfo field in the PKIHeader of the 1268 certificate request message as described in Section 3.1. 1270 In case the EE receives a CA certificate in the caPubs field for 1271 installation as a new trust anchor, it MUST properly authenticate the 1272 message and authorize the sender as trusted source of the new trust 1273 anchor. This authorization is typically indicated using shared 1274 secret information for protecting an initialization response (ir) 1275 message. Authorization can also be signature-based using a 1276 certificate issued by another PKI that is explicitly authorized for 1277 this purpose. A certificate received in caPubs MUST NOT be accepted 1278 as a trust anchor if it is the root CA certificate of the certificate 1279 used for protecting the message. 1281 4.1.1. Enrolling an End Entity to a New PKI 1283 This PKI management operation should be used by an EE to request a 1284 certificate from a new PKI using an existing certificate from an 1285 external PKI, e.g., a manufacturer-issued IDevID certificate 1286 [IEEE.802.1AR_2018], to authenticate itself to the new PKI. 1288 Note: In Bootstrapping Remote Secure Key Infrastructure (BRSKI) 1289 [RFC8995] environments, BRSKI Asynchronous Enrollment (BRSKI-AE) 1290 [I-D.ietf-anima-brski-ae] describes a generalization regarding 1291 enrollment protocols alternative to EST [RFC7030]. As replacement of 1292 EST simpleenroll, BRSKI-AE uses this PKI management operation for 1293 bootstrapping LDevID certificates. 1295 Specific prerequisites augmenting the prerequisites in Section 3.4: 1297 * The certificate of the EE MUST have been enrolled by an external 1298 PKI, e.g., a manufacturer-issued device certificate. 1300 * The PKI management entity MUST have the trust anchor of the 1301 external PKI. 1303 * When using the generalInfo field certProfile, the EE MUST know the 1304 identifier needed to indicate the requested certificate profile. 1306 Message Flow: 1308 Step# EE PKI management entity 1309 1 format ir 1310 2 -> ir -> 1311 3 handle or 1312 forward ir 1313 4 format or receive ip 1314 5 possibly grant 1315 implicitConfirm 1316 6 <- ip <- 1317 7 handle ip 1319 ----------------- if implicitConfirm not granted ----------------- 1321 8 format certConf 1322 9 -> certConf -> 1323 10 handle or 1324 forward certConf 1325 11 format or receive pkiConf 1326 12 <- pkiConf <- 1327 13 handle pkiConf 1329 For this PKI management operation, the EE MUST include exactly one 1330 CertReqMsg in the ir. If more certificates are required, further 1331 requests MUST be sent using separate PKI management operation. 1333 The EE SHOULD include the implicitConfirm extension in the header of 1334 the ir message as described in Section 3.1, unless it knows that 1335 certificate confirmation is needed. This leaves the choice to the 1336 PKI management entities whether the EE must send a certConf message 1337 on receiving a new certificate. Depending on the PKI policy and 1338 requirements for managing EE certificates, it can be important for 1339 PKI management entities to learn if the EE accepted the new 1340 certificate. In such cases, when responding with an ip message, the 1341 PKI management entity MUST NOT include the implicitConfirm extension. 1342 In case the PKI management entity does not need any explicit 1343 confirmation from the EE, it MUST include the extension as described 1344 in Section 3.1. This prevents explicit certificate confirmation and 1345 saves the overhead of a further message round-trip. 1347 If the EE did not request implicit confirmation or implicit 1348 confirmation was not granted by the PKI management entity, 1349 certificate confirmation MUST be performed as follows. If the EE 1350 successfully received the certificate, it MUST send a certConf 1351 message in due time. On receiving a valid certConf message, the PKI 1352 management entity MUST respond with a pkiConf message. If the PKI 1353 management entity does not receive the expected certConf message in 1354 time it MUST handle this like a rejection by the EE. In case of 1355 rejection, depending on its policy the PKI management entity MAY 1356 revoke the newly issued certificate, notify a monitoring system, or 1357 log the event internally. 1359 Note: Depending on PKI policy, a new certificate may be published by 1360 a PKI management entity, and explicit confirmation may be required. 1361 In this case it is advisable not to do the publication until a 1362 positive certificate confirmation has been received. This way the 1363 need to revoke the certificate on negative confirmation is avoided. 1365 If the certificate request was rejected by the CA, the PKI management 1366 entity must return an ip message containing the status code 1367 "rejection" as described in Section 3.6 and no certifiedKeyPair 1368 field. The EE MUST NOT react to such an ip message with a certConf 1369 message and the PKI management operation MUST be terminated. 1371 Detailed Message Description: 1373 Initialization Request -- ir 1375 Field Value 1377 header 1378 -- As described in Section 3.1 1380 body 1381 -- The request of the EE for a new certificate 1382 ir REQUIRED 1383 -- MUST contain exactly one CertReqMsg 1384 -- If more certificates are required, further PKI management 1385 -- operations MUST be initiated 1386 certReq REQUIRED 1387 certReqId REQUIRED 1388 -- MUST be 0 1389 certTemplate REQUIRED 1390 version OPTIONAL 1391 -- MUST be 2 if supplied 1392 subject REQUIRED 1393 -- The EE subject name MUST be carried in the subject field 1394 -- and/or the subjectAltName extension. 1395 -- If subject name is present only in the subjectAltName 1396 -- extension, then the subject field MUST be a NULL-DN 1397 publicKey REQUIRED 1398 algorithm REQUIRED 1399 -- MUST include the subject public key algorithm identifier 1400 subjectPublicKey REQUIRED 1401 -- MUST contain the public key to be certified in case of local 1402 -- key generation 1403 extensions OPTIONAL 1404 -- MAY include end-entity-specific X.509 extensions of the 1405 -- requested certificate like subject alternative name, key 1406 -- usage, and extended key usage 1407 -- The subjectAltName extension MUST be present if the EE subject 1408 -- name includes a subject alternative name. 1409 popo OPTIONAL 1410 -- MUST be present if local key generation is used 1411 -- MUST be absent if central key generation is requested 1412 signature RECOMMENDED 1413 -- MUST be used by an EE if the key can be used for signing and 1414 -- has the type POPOSigningKey 1415 poposkInput PROHIBITED 1416 -- MUST NOT be used; it is not needed because subject and 1417 -- publicKey are both present in the certTemplate 1418 algorithmIdentifier REQUIRED 1419 -- The signature algorithm MUST be consistent with the publicKey 1420 -- algorithm field of the certTemplate 1421 signature REQUIRED 1422 -- MUST contain the signature value computed over the DER-encoded 1423 -- certTemplate 1424 raVerified OPTIONAL 1425 -- MAY be used by an RA after verifying the proof-of-possession 1426 -- provided by the EE 1428 protection REQUIRED 1429 -- As described in Section 3.2 1431 extraCerts REQUIRED 1432 -- As described in Section 3.3 1434 Initialization Response -- ip 1436 Field Value 1438 header 1439 -- As described in Section 3.1 1441 body 1442 -- The response of the CA to the request as appropriate 1443 ip REQUIRED 1444 caPubs OPTIONAL 1445 -- MAY be used if the certifiedKeyPair field is present 1446 -- If used it MUST contain only a trust anchor, e.g. root 1447 -- certificate, of the certificate contained in certOrEncCert 1448 response REQUIRED 1449 -- MUST contain exactly one CertResponse 1450 certReqId REQUIRED 1451 -- MUST be 0 1452 status REQUIRED 1453 -- PKIStatusInfo structure MUST be present 1454 status REQUIRED 1455 -- positive values allowed: "accepted", "grantedWithMods" 1456 -- negative values allowed: "rejection" 1457 -- "waiting" only allowed with polling use case as described in 1458 -- Section 4.4 1459 statusString OPTIONAL 1460 -- MAY be any human-readable text for debugging, logging or to 1461 -- display in a GUI 1462 failInfo OPTIONAL 1463 -- MAY be present if status is "rejection" 1464 -- MUST be absent if status is "accepted" or "grantedWithMods" 1465 certifiedKeyPair OPTIONAL 1466 -- MUST be present if status is "accepted" or "grantedWithMods" 1467 -- MUST be absent if status is "rejection" 1468 certOrEncCert REQUIRED 1469 -- MUST be present if status is "accepted" or "grantedWithMods" 1470 certificate REQUIRED 1471 -- MUST be present when certifiedKeyPair is present 1472 -- MUST contain the newly enrolled X.509 certificate 1473 privateKey OPTIONAL 1474 -- MUST be absent in case of local key generation or "rejection" 1475 -- MUST contain the encrypted private key in an EnvelopedData 1476 -- structure as specified in Section 4.1.6 in case the private 1477 -- key was generated centrally 1479 protection REQUIRED 1480 -- As described in Section 3.2 1482 extraCerts REQUIRED 1483 -- As described in Section 3.3 1484 -- MUST contain the chain of the certificate present in 1485 -- certOrEncCert 1486 -- Self-signed certificates SHOULD be omitted 1487 -- Duplicate certificates MAY be omitted 1489 Certificate Confirmation -- certConf 1491 Field Value 1493 header 1494 -- As described in Section 3.1 1496 body 1497 -- The message of the EE sends as confirmation to the PKI 1498 -- management entity to accept or reject the issued certificates 1499 certConf REQUIRED 1500 -- MUST contain exactly one CertStatus 1501 CertStatus REQUIRED 1502 certHash REQUIRED 1503 -- MUST be the hash of the certificate, using the hash algorithm 1504 -- indicated in hashAlg, see below, or the same one as used to 1505 -- create the certificate signature 1506 certReqId REQUIRED 1507 -- MUST be 0 1508 statusInfo RECOMMENDED 1509 -- PKIStatusInfo structure SHOULD be present 1510 -- Omission indicates acceptance of the indicated certificate 1511 status REQUIRED 1512 -- positive values allowed: "accepted" 1513 -- negative values allowed: "rejection" 1514 statusString OPTIONAL 1515 -- MAY be any human-readable text for debugging, logging, or to 1516 -- display in a GUI 1517 failInfo OPTIONAL 1518 -- MAY be present if status is "rejection" 1519 -- MUST be absent if status is "accepted" 1520 hashAlg OPTIONAL 1521 -- The hash algorithm to use for calculating certHash 1522 -- SHOULD NOT be used in all cases where the AlgorithmIdentifier 1523 -- of the certificate signature specifies a hash algorithm 1524 -- If used, the pvno field in the header MUST be cmp2021 (3) 1526 protection REQUIRED 1527 -- As described in Section 3.2 1528 -- MUST use the same credentials as in the first request message 1529 -- of this PKI management operation 1531 extraCerts RECOMMENDED 1532 -- As described in Section 3.3 1533 -- MAY be omitted if the message size is critical and 1534 -- the PKI management entity caches the extraCerts from the 1535 -- first request message of this PKI management operation 1537 PKI Confirmation -- pkiConf 1539 Field Value 1541 header 1542 -- As described in Section 3.1 1544 body 1545 pkiconf REQUIRED 1546 -- The content of this field MUST be NULL 1548 protection REQUIRED 1549 -- As described in Section 3.2 1550 -- MUST use the same credentials as in the first response 1551 -- message of this PKI management operation 1553 extraCerts RECOMMENDED 1554 -- As described in Section 3.3 1555 -- MAY be omitted if the message size is critical and the EE has 1556 -- cached the extraCerts from the first response message of 1557 -- this PKI management operation 1559 4.1.2. Enrolling an End Entity to a Known PKI 1561 This PKI management operation should be used by an EE to request an 1562 additional certificate of the same PKI it already has certificates 1563 from. The EE uses one of these existing certificates to authenticate 1564 itself by signing its request messages using the respective private 1565 key. 1567 Specific prerequisites augmenting the prerequisites in Section 3.4: 1569 * The certificate used by the EE MUST have been enrolled by the PKI 1570 it requests another certificate from. 1572 * When using the generalInfo field certProfile, the EE MUST know the 1573 identifier needed to indicate the requested certificate profile. 1575 The message sequence for this PKI management operation is identical 1576 to that given in Section 4.1.1, with the following changes: 1578 1 The body of the first request and response SHOULD be cr and cp, 1579 respectively. 1581 Note: Since the difference between ir/ip and cr/cp is 1582 syntactically not essential, an ir/ip MAY be used in this PKI 1583 management operation. 1585 2 The caPubs field in the certificate response message SHOULD be 1586 absent. 1588 4.1.3. Updating a Valid Certificate 1590 This PKI management operation should be used by an EE to request an 1591 update for one of its certificates that is still valid. The EE uses 1592 the certificate it wishes to update as the protection certificate. 1593 Both for authenticating itself and for proving ownership of the 1594 certificate to be updated, it signs the request messages with the 1595 corresponding private key. 1597 Specific prerequisites augmenting the prerequisites in Section 3.4: 1599 * The certificate the EE wishes to update MUST NOT be expired or 1600 revoked and MUST have been issued by the addressed CA. 1602 * A new public-private key pair SHOULD be used. 1604 * When using the generalInfo field certProfile, the EE MUST know the 1605 identifier needed to indicate the requested certificate profile. 1607 The message sequence for this PKI management operation is identical 1608 to that given in Section 4.1.1, with the following changes: 1610 1 The body of the first request and response MUST be kur and kup, 1611 respectively. 1613 2 Protection of the kur MUST be performed using the certificate to 1614 be updated. 1616 3 The subject field and/or the subjectAltName extension of the 1617 certTemplate MUST contain the EE subject name of the existing 1618 certificate to be updated, without modifications. 1620 4 The certTemplate SHOULD contain the subject and/or subjectAltName 1621 extension and publicKey of the EE only. 1623 5 The oldCertId control MAY be used to make clear which certificate 1624 is to be updated. 1626 6 The caPubs field in the kup message MUST be absent. 1628 As part of the certReq structure of the kur the oldCertId control is 1629 added after the certTemplate field. 1631 controls 1632 type RECOMMENDED 1633 -- MUST be the value id-regCtrl-oldCertID, if present 1634 value 1635 issuer REQUIRED 1636 serialNumber REQUIRED 1637 -- MUST contain the issuer and serialNumber of the certificate 1638 -- to be updated 1640 4.1.4. Enrolling an End Entity Using a PKCS#10 Request 1642 This PKI management operation can be used by an EE to request a 1643 certificate using a legacy PKCS#10 [RFC2986] request instead of CRMF 1644 [RFC4211]. This offers a variation of the PKI management operations 1645 specified in Section 4.1.2. 1647 In Secure Zero Touch Provisioning (SZTP) [RFC8572] environments, 1648 SZTP-CSR [I-D.ietf-netconf-sztp-csr] describes the use of a CMP p10cr 1649 message as a form of certificate signing request (CSR) to optionally 1650 include in device bootstrapping to obtain an identity certificate as 1651 part of the onboarding information. Such a CSR is of form ietf-sztp- 1652 types:cmp-csr from module ietf-sztp-csr. The requirements given 1653 below on p10cr message MUST be adhered to. 1655 In this PKI management operation, the public key and all further 1656 certificate template data MUST be contained in the subjectPKInfo and 1657 other certificationRequestInfo fields of the PKCS#10 structure. 1659 The prerequisites are the same as given in Section 4.1.2. 1661 The message sequence for this PKI management operation is identical 1662 to that given in Section 4.1.2, with the following changes: 1664 1 The body of the first request and response MUST be p10cr and cp, 1665 respectively. 1667 2 The certReqId in the cp message MUST be -1. 1669 3 The caPubs field in the cp message SHOULD be absent. 1671 Detailed Message Description: 1673 Certification Request -- p10cr 1675 Field Value 1677 header 1678 -- As described in Section 3.1 1680 body 1681 -- The request of the EE for a new certificate using a PKCS#10 1682 -- certificate request 1683 p10cr REQUIRED 1684 certificationRequestInfo REQUIRED 1685 version REQUIRED 1686 -- MUST be 0 to indicate PKCS#10 V1.7 1687 subject REQUIRED 1688 -- The EE subject name MUST be carried in the subject field 1689 -- and/or the subjectAltName extension. 1690 -- If subject name is present only in the subjectAltName 1691 -- extension, then the subject field MUST be a NULL-DN 1692 subjectPKInfo REQUIRED 1693 algorithm REQUIRED 1694 -- MUST include the subject public key algorithm identifier 1695 subjectPublicKey REQUIRED 1696 -- MUST include the public key to be certified 1697 attributes OPTIONAL 1698 -- MAY include end-entity-specific X.509 extensions of the 1699 -- requested certificate like subject alternative name, 1700 -- key usage, and extended key usage 1701 -- The subjectAltName extension MUST be present if the EE 1702 -- subject name includes a subject alternative name. 1703 signatureAlgorithm REQUIRED 1704 -- The signature algorithm MUST be consistent with the 1705 -- subjectPKInfo field. 1706 signature REQUIRED 1707 -- MUST contain the self-signature for proof-of-possession 1709 protection REQUIRED 1710 -- As described in Section 3.2 1712 extraCerts REQUIRED 1713 -- As described for the underlying PKI management operation 1715 4.1.5. Using MAC-Based Protection for Enrollment 1717 This is a variant of the PKI management operations described in 1718 Section 4.1.1 to Section 4.1.4. It should be used by an EE to 1719 request a certificate of a new PKI in case it does not have a 1720 certificate to prove its identity to the target PKI, but has some 1721 secret information shared with the PKI management entity. Therefore, 1722 the request and response messages are MAC-protected using this shared 1723 secret information. The distribution of this shared secret is out of 1724 scope for this document. The PKI management entity checking the MAC- 1725 based protection SHOULD replace this protection according to 1726 Section 5.2.3 in case the next hop does not know the shared secret 1727 information. 1729 Note: The entropy of the shared secret information is crucial for the 1730 level of protection when using MAC-based protection. Further 1731 guidance is available in the security considerations of CMP updated 1732 by [I-D.ietf-lamps-cmp-updates]. 1734 Specific prerequisites augmenting the prerequisites in Section 3.4: 1736 * Rather than using private keys, certificates, and trust anchors, 1737 the EE and the PKI management entity MUST share secret 1738 information. 1740 Note: The shared secret information MUST be established out-of- 1741 band, e.g., by a service technician during initial local 1742 configuration. 1744 * When using the generalInfo field certProfile, the EE MUST know the 1745 identifier needed to indicate the requested certificate profile. 1747 The message sequence for this PKI management operation is identical 1748 to that given in Section 4.1.1, with the following changes: 1750 1 The protection of all messages MUST be MAC-based. 1752 2 The senderKID MUST contain a reference the recipient can use to 1753 identify the shared secret information used for the protection, 1754 e.g., the username of the EE. 1756 3 The extraCerts of all messages does not contain CMP protection 1757 certs and associated chains. 1759 See Section 6 of CMP Algorithms [I-D.ietf-lamps-cmp-algorithms] for 1760 details on message authentication code algorithms (MSG_MAC_ALG) to 1761 use. Typically, parameters are part of the protectionAlg field, 1762 e.g., used for key derivation, like a salt and an iteration count. 1763 Such fields SHOULD remain constant for message protection throughout 1764 this PKI management operation to reduce the computational overhead. 1766 4.1.6. Adding Central Key Pair Generation to Enrollment 1768 This is a variant of the PKI management operations described in 1769 Section 4.1.1 to Section 4.1.4 and the variant described in 1770 Section 4.1.5. It needs to be used in case an EE is not able to 1771 generate its new public-private key pair itself or central generation 1772 of the EE key material is preferred. It is a matter of the local 1773 implementation which PKI management entity will act as Key Generation 1774 Authority (KGA) and perform the key generation. This PKI management 1775 entity MUST use a certificate containing the additional extended key 1776 usage extension id-kp-cmKGA in order to be accepted by the EE as a 1777 legitimate key generation authority. 1779 As described in Section 5.3.1, the KGA can use one of the PKI 1780 management operations described in the sections above to request the 1781 certificate for this key pair on behalf of the EE. 1783 Generally speaking, in machine-to-machine scenarios it is strongly 1784 preferable to generate public-private key pairs locally at the EE. 1785 Together with proof-of-possession of the private key in the 1786 certificate request, this is advisable to make sure that the entity 1787 identified in the newly issued certificate is the only entity that 1788 knows the private key. 1790 Reasons for central key generation may include the following: 1792 * Lack of sufficient initial entropy. 1794 Note: Good random numbers are needed not only for key generation 1795 but also for session keys and nonces in any security protocol. 1796 Therefore, a decent security architecture should anyways support 1797 good random number generation on the EE side or provide enough 1798 initial entropy for the RNG seed to guarantee good pseudo-random 1799 number generation. Yet maybe this is not the case at the time of 1800 requesting an initial certificate during manufacturing. 1802 * Lack of computational resources, in particular for RSA key 1803 generation. 1805 Note: Since key generation could be performed in advance to the 1806 certificate enrollment communication, it is often not time 1807 critical. 1809 Note: As mentioned in Section 2, central key generation may be 1810 required in a push model, where the certificate response message is 1811 transferred by the PKI management entity to the EE without a previous 1812 request message. 1814 The EE requesting central key generation MUST omit the publicKey 1815 field from the certTemplate or, in case it has a preference on the 1816 key type to be generated, provide it in the algorithm sub-field and 1817 fill the subjectPublicKey sub-field with a zero-length BIT STRING. 1818 Both variants indicate to the PKI management entity that a new key 1819 pair shall be generated centrally on behalf of the EE. 1821 Note: As the protection of centrally generated keys in the response 1822 message has been extended to EncryptedKey by CMP Updates Section 2.7 1823 [I-D.ietf-lamps-cmp-updates], EnvelopedData is the preferred 1824 alternative to EncryptedValue. In CRMF Section 2.1.9 [RFC4211] the 1825 use of EncryptedValue has been deprecated in favor of the 1826 EnvelopedData structure. Therefore, this profile requires using 1827 EnvelopedData as specified in CMS Section 6 [RFC5652]. When 1828 EnvelopedData is to be used in a PKI management operation, CMP v3 1829 MUST be indicated in the message header already for the initial 1830 request message, see CMP Updates Section 2.19 and Section 2.20 1831 [I-D.ietf-lamps-cmp-updates]. 1833 +----------------------------------+ 1834 | EnvelopedData | 1835 | [RFC5652] section 6 | 1836 | +------------------------------+ | 1837 | | SignedData | | 1838 | | [RFC5652] section 5 | | 1839 | | +--------------------------+ | | 1840 | | | AsymmetricKeyPackage | | | 1841 | | | [RFC5958] | | | 1842 | | | +----------------------+ | | | 1843 | | | | privateKey | | | | 1844 | | | | OCTET STRING | | | | 1845 | | | +----------------------+ | | | 1846 | | +--------------------------+ | | 1847 | +------------------------------+ | 1848 +----------------------------------+ 1850 Figure 3: Encrypted Private Key Container 1852 The PKI management entity delivers the private key in the privateKey 1853 field in the certifiedKeyPair structure of the response message also 1854 containing the newly issued certificate. 1856 The private key MUST be provided as an AsymmetricKeyPackage structure 1857 as defined in RFC 5958 [RFC5958]. 1859 This AsymmetricKeyPackage structure MUST be wrapped in a SignedData 1860 structure, as specified in CMS Section 5 [RFC5652] and [RFC8933], 1861 signed by the KGA generating the key pair. The signature MUST be 1862 performed using a private key related to a certificate asserting the 1863 extended key usage id-kp-cmKGA as described in CMP Updates 1864 Section 2.2 [I-D.ietf-lamps-cmp-updates] to demonstrate authorization 1865 to generate key pairs on behalf of an EE. The EE SHOULD validate the 1866 signer certificate contained in the SignedData structure and verify 1867 the presence of this extended key usage in the signer certificate. 1869 Note: When using password-based key management technique as described 1870 in Section 4.1.6.3 it may not be possible or meaningful to the EE to 1871 validate the KGA signature and the related certificate in the 1872 SignedData structure since shared secret information is used for 1873 initial authentication. In this case the EE MAY omit this 1874 validation. 1876 The SignedData structure MUST be wrapped in an EnvelopedData 1877 structure, as specified in CMS Section 6 [RFC5652], encrypting it 1878 using a newly generated symmetric content-encryption key. 1880 This content-encryption key MUST be securely provided as part of the 1881 EnvelopedData structure to the EE using one of three key management 1882 techniques. The choice of the key management technique to be used by 1883 the PKI management entity depends on the authentication mechanism the 1884 EE chose to protect the request message. See CMP Updates Section 2.7 1885 [I-D.ietf-lamps-cmp-updates] for more details on which key management 1886 technique to use. 1888 * Signature-based protection of the request message: 1890 - The content-encryption key SHALL be protected using the key 1891 agreement key management technique, see Section 4.1.6.1, if the 1892 certificate used by the EE for protecting the request message 1893 allows the key usage keyAgreement. If the certificate also 1894 allows the key usage keyEncipherment, the key transport key 1895 management technique SHALL NOT be used. 1897 - The content-encryption key SHALL be protected using the key 1898 transport key management technique, see Section 4.1.6.2, if the 1899 certificate used by the EE for protecting the respective 1900 request message allows the key usage keyEncipherment but not 1901 keyAgreement. 1903 * MAC-based protected of the request message: 1905 - The content-encryption key SHALL be protected using the 1906 password-based key management technique, see Section 4.1.6.3, 1907 if and only if the EE used MAC-based protection for the request 1908 message. 1910 If central key generation is supported, support of the key agreement 1911 key management technique is REQUIRED and support of key transport and 1912 password-based key management techniques are OPTION, for two reasons: 1913 The key agreement key management technique is supported by most 1914 asymmetric algorithms, while the key transport key management 1915 technique is supported only by a very few of them. The password- 1916 based key management technique shall only be used in combination with 1917 MAC-based protection, which is a sideline in this document. 1919 Specific prerequisites augmenting those of the respective certificate 1920 enrollment PKI management operations: 1922 * If signature-based protection is used, the EE MUST be able to 1923 authenticate and authorize the KGA, using suitable information, 1924 which includes a trust anchor. 1926 * If MAC-based protection is used, the KGA MUST also know the shared 1927 secret information to protect the encrypted transport of the newly 1928 generated key pair. Consequently, the EE can also authorize the 1929 KGA. 1931 * The PKI management entity MUST have a certificate containing the 1932 additional extended key usage extension id-kp-cmKGA for signing 1933 the SignedData structure containing the private key package. 1935 * For encrypting the SignedData structure a fresh content-encryption 1936 key to be used by the symmetric encryption algorithm MUST be 1937 generated with sufficient entropy. 1939 Note: The security strength of the protection of the generated 1940 private key should be similar or higher than the security strength 1941 of the generated private key. 1943 Detailed Description of privateKey Field: 1945 privateKey OPTIONAL 1946 -- MUST be an EnvelopedData structure as specified in CMS 1947 -- Section 6 [RFC5652] 1948 version REQUIRED 1949 -- MUST be 2 for recipientInfo type KeyAgreeRecipientInfo and 1950 -- KeyTransRecipientInfo 1951 -- MUST be 0 for recipientInfo type PasswordRecipientInfo 1952 recipientInfos REQUIRED 1953 -- MUST contain exactly one RecipientInfo, which MUST be 1954 -- kari of type KeyAgreeRecipientInfo (see section 4.1.6.1), 1955 -- ktri of type KeyTransRecipientInfo (see section 4.1.6.2), or 1956 -- pwri of type PasswordRecipientInfo (see section 4.1.6.3) 1957 encryptedContentInfo 1958 REQUIRED 1959 contentType REQUIRED 1960 -- MUST be id-signedData 1961 contentEncryptionAlgorithm 1962 REQUIRED 1963 -- MUST be the algorithm identifier of the algorithm used for 1964 -- content encryption 1965 -- The algorithm type MUST be a PROT_SYM_ALG as specified in 1966 -- RFC-CMP-Alg Section 5 1967 encryptedContent REQUIRED 1968 -- MUST be the SignedData structure as specified in CMS 1969 -- Section 5 [RFC5652] and [RFC8933] in encrypted form 1970 version REQUIRED 1971 -- MUST be 3 1972 digestAlgorithms 1973 REQUIRED 1974 -- MUST contain exactly one AlgorithmIdentifier element 1975 -- MUST be the algorithm identifier of the digest algorithm 1976 -- used for generating the signature and match the signature 1977 -- algorithm specified in signatureAlgorithm, see and [RFC8933] 1978 encapContentInfo 1979 REQUIRED 1980 -- MUST contain the content that is to be signed 1981 eContentType REQUIRED 1982 -- MUST be id-ct-KP-aKeyPackage as specified in [RFC5958] 1983 eContent REQUIRED 1984 -- MUST be of type AsymmetricKeyPackage and 1985 -- MUST contain exactly one OneAsymmetricKey element 1986 version REQUIRED 1987 -- MUST be 1 (indicating v2) 1988 privateKeyAlgorithm 1989 REQUIRED 1990 -- The privateKeyAlgorithm field MUST contain the algorithm 1991 -- identifier of the asymmetric key pair algorithm 1992 privateKey 1993 REQUIRED 1994 publicKey 1995 REQUIRED 1996 -- MUST contain the public key corresponding to the private key 1997 -- for simplicity and consistency with v2 of OneAsymmetricKey 1998 certificates REQUIRED 1999 -- MUST contain the certificate for the private key used to sign 2000 -- the signedData content, together with its chain 2001 -- The first certificate in this field MUST be the KGA 2002 -- certificate used for protecting this content 2003 -- Self-signed certificates SHOULD NOT be included and MUST NOT 2004 -- be trusted based on their inclusion in any case 2005 signerInfos REQUIRED 2006 -- MUST contain exactly one SignerInfo element 2007 version REQUIRED 2008 -- MUST be 3 2009 sid REQUIRED 2010 subjectKeyIdentifier 2011 REQUIRED 2012 -- MUST be the subjectKeyIdentifier of the KGA certificate 2013 digestAlgorithm 2014 REQUIRED 2015 -- MUST be the same as in digestAlgorithms 2016 signedAttrs REQUIRED 2017 -- MUST contain an id-contentType attribute containing the value 2018 -- id-ct-KP-aKeyPackage 2019 -- MUST contain an id-messageDigest attribute containing the 2020 -- message digest of eContent 2021 -- MAY contain an id-signingTime attribute containing the time 2022 -- of signature 2023 -- For details on the signed attributes see CMS Section 5.3 and 2024 -- Section 11 [RFC5652] and [RFC8933] 2025 signatureAlgorithm 2026 REQUIRED 2027 -- MUST be the algorithm identifier of the signature algorithm 2028 -- used for calculation of the signature bits 2029 -- The signature algorithm type MUST be a MSG_SIG_ALG as 2030 -- specified in RFC-CMP-Alg Section 3 and MUST be consistent 2031 -- with the subjectPublicKeyInfo field of the KGA certificate 2032 signature REQUIRED 2033 -- MUST be the digital signature of the encapContentInfo 2035 NOTE: As stated in Section 1.5, all fields of the ASN.1 syntax that 2036 are defined in RFC 5652 [RFC5652] but are not explicitly specified 2037 here SHOULD NOT be used. 2039 4.1.6.1. Using Key Agreement Key Management Technique 2041 This variant can be applied in combination with the PKI management 2042 operations specified in Section 4.1.1 to Section 4.1.3 using 2043 signature-based protection of CMP messages. The EE certificate used 2044 for the signature-based protection of the request message MUST allow 2045 for the key usage "keyAgreement" and therefore, the related key pair 2046 MUST be used for establishment of the content-encryption key. For 2047 this key management technique the KeyAgreeRecipientInfo structure 2048 MUST be used in the contentInfo field. 2050 The KeyAgreeRecipientInfo structure included into the EnvelopedData 2051 structure is specified in CMS Section 6.2.2 [RFC5652]. 2053 Detailed Description of KeyAgreeRecipientInfo Structure: 2055 kari REQUIRED 2056 -- MUST be a KeyAgreeRecipientInfo as specified in CMS Section 2057 -- 6.2.2 [RFC5652] 2058 version REQUIRED 2059 -- MUST be 3 2060 originator REQUIRED 2061 -- MUST contain the subjectKeyIdentifier of the certificate, 2062 -- and thereby identifies the sender's public key. 2063 -- MUST contain the same value as the senderKID in the 2064 -- message header 2065 ukm RECOMMENDED 2066 -- MUST be used when 1-pass ECMQV is used 2067 -- SHOULD be present to ensure uniqueness of the key 2068 -- encryption key 2069 keyEncryptionAlgorithm 2070 REQUIRED 2071 -- MUST be the algorithm identifier of the key agreement 2072 -- algorithm 2073 -- The algorithm type MUST be a KM_KA_ALG as specified in 2074 -- RFC-CMP-Alg Section 4.1 2075 -- The parameters field of the key agreement algorithm MUST 2076 -- contains the key wrap algorithm 2077 -- The algorithm type MUST be a KM_KW_ALG as specified in 2078 -- RFC-CMP-Alg Section 4.3 2079 recipientEncryptedKeys 2080 REQUIRED 2081 -- MUST contain exactly one RecipientEncryptedKey element 2082 rid REQUIRED 2083 -- MUST contain the rKeyId choice 2084 rKeyId REQUIRED 2085 subjectKeyIdentifier 2086 REQUIRED 2087 -- MUST contain the same value as the senderKID in the 2088 -- respective request message header 2089 encryptedKey 2090 REQUIRED 2091 -- MUST be the encrypted content-encryption key 2093 4.1.6.2. Using Key Transport Key Managemen Technique 2095 This variant can be applied in combination with the PKI management 2096 operations specified in Section 4.1.1 to Section 4.1.3 using 2097 signature-based protection of CMP messages. The EE certificate used 2098 for the signature-based protection of the request message MUST allow 2099 for the key usage "keyEncipherment" and not for "keyAgreement". 2100 Therefore, the related key pair MUST be used for encipherment of the 2101 content-encryption key. For this key management technique, the 2102 KeyTransRecipientInfo structure MUST be used in the contentInfo 2103 field. 2105 The KeyTransRecipientInfo structure included into the EnvelopedData 2106 structure is specified in CMS Section 6.2.1 [RFC5652]. 2108 Detailed Description of KeyTransRecipientInfo Structure: 2110 ktri REQUIRED 2111 -- MUST be a KeyTransRecipientInfo as specified in CMS 2112 -- Section 6.2.1 [RFC5652] 2113 version REQUIRED 2114 -- MUST be 2 2115 rid REQUIRED 2116 -- MUST contain the subjectKeyIdentifier choice 2117 subjectKeyIdentifier 2118 REQUIRED 2119 -- MUST contain the same value as the senderKID in the 2120 -- respective request message header 2121 keyEncryptionAlgorithm 2122 REQUIRED 2123 -- MUST be the algorithm identifier of the key transport 2124 -- algorithm 2125 -- The algorithm type MUST be a KM_KT_ALG as specified in 2126 -- RFC-CMP-Alg Section 4.2 2127 encryptedKey REQUIRED 2128 -- MUST be the encrypted content-encryption key 2130 4.1.6.3. Using Password-Based Key Management Technique 2132 This variant can be applied in combination with the PKI management 2133 operation specified in Section 4.1.5 using MAC-based protection of 2134 CMP messages. The shared secret information used for the MAC-based 2135 protection MUST also be used for the encryption of the content- 2136 encryption key but with a different salt value applied in the key 2137 derivation algorithm. For this key management technique, the 2138 PasswordRecipientInfo structure MUST be used in the contentInfo 2139 field. 2141 Note: The entropy of the shared secret information is crucial for the 2142 level of protection when using a password-based key management 2143 technique. For centrally generated key pairs, the entropy of the 2144 shared secret information SHALL NOT be less than the security 2145 strength of the centrally generated key pair. Further guidance is 2146 available in Section 9. 2148 The PasswordRecipientInfo structure included into the EnvelopedData 2149 structure is specified in CMS Section 6.2.4 [RFC5652]. 2151 Detailed Description of PasswordRecipientInfo Structure: 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.3 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.4). 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 Detailed Description of infoValue Field of genp: 2391 infoValue OPTIONAL 2392 -- MUST be absent if no CA certificate is available 2393 -- MUST be present if CA certificates are available 2394 -- MUST be a sequence of CMPCertificate 2396 4.3.2. Get Root CA Certificate Update 2398 This PKI management operation can be used by an EE to request an 2399 updated root CA Certificate as described in Section 4.4 of RFC 4210 2400 [RFC4210]. 2402 An EE requests an update of a root CA certificate from the PKI 2403 management entity by sending a general message with OID id-it- 2404 rootCaCert, which SHOULD include the old root CA certificate in the 2405 message body, as specified in CMP Updates Section 2.14 2406 [I-D.ietf-lamps-cmp-updates]. The PKI management entity responds 2407 with a general response with OID id-it-rootCaKeyUpdate that either 2408 contains the update of the root CA certificate consisting of up to 2409 three certificates, or with no content in case no update is 2410 available. 2412 Note: This mechanism may also be used to update trusted non-root 2413 certificates, i.e., trusted intermediate CA or issuing CA 2414 certificates. 2416 The newWithNew certificate is the new root CA certificate and is 2417 REQUIRED to be present if available. The newWithOld certificate is 2418 REQUIRED to be present in the response message because it is needed 2419 for the receiving entity trusting the old root CA certificate to gain 2420 trust in the new root CA certificate. The oldWithNew certificate is 2421 OPTIONAL because it is only needed in rare scenarios where entities 2422 do not already trust the old root CA. 2424 No specific prerequisites apply in addition to those specified in 2425 Section 3.4. 2427 The message sequence for this PKI management operation is as given 2428 above, with the following specific content: 2430 1 the infoType OID to use is id-it-rootCaCert in the request and id- 2431 it-rootCaKeyUpdate in the response 2433 2 the infoValue of the request SHOULD contain the root CA 2434 certificate the update is requested for 2436 3 if present, the infoValue of the response MUST be a 2437 RootCaKeyUpdateContent structure 2439 Detailed Description of infoValue Field of genm: 2441 infoValue RECOMMENDED 2442 -- MUST contain the root CA certificate to be updated, if 2443 -- available 2445 Detailed Description of infoValue Field of genp: 2447 infoValue OPTIONAL 2448 -- MUST be absent if no update of the root CA certificate is 2449 -- available 2450 -- MUST be present if an update of the root CA certificate 2451 -- is available and MUST be of type RootCaKeyUpdateContent 2452 newWithNew REQUIRED 2453 -- MUST be present if infoValue is present 2454 -- MUST contain the new root CA certificate 2455 newWithOld REQUIRED 2456 -- MUST be present if infoValue is present 2457 -- MUST contain a certificate containing the new public 2458 -- root CA key signed with the old private root CA key 2459 oldWithNew OPTIONAL 2460 -- MAY be present if infoValue is present 2461 -- MUST contain a certificate containing the old public 2462 -- root CA key signed with the new private root CA key 2464 4.3.3. Get Certificate Request Template 2466 This PKI management operation can be used by an EE to request a 2467 template with parameters for future certificate requests. 2469 An EE requests certificate request parameters from the PKI management 2470 entity by sending a general message with OID id-it-certReqTemplate as 2471 specified in CMP Updates Section 2.15 [I-D.ietf-lamps-cmp-updates]. 2472 The EE MAY indicate the certificate profile to use in the id-it- 2473 certProfile extension of the generalInfo field in the PKIHeader of 2474 the general message as described in Section 3.1. The PKI management 2475 entity responds with a general response with the same OID that either 2476 contains requirements on the certificate request template, or with no 2477 content in case no specific requirements are imposed by the PKI. The 2478 CertReqTemplateValue contains requirements on certificate fields and 2479 extensions in a certTemplate. Optionally it contains a keySpec field 2480 containing requirements on algorithms acceptable for key pair 2481 generation. 2483 The EE SHOULD follow the requirements from the received CertTemplate, 2484 by including in the certificate requests all the fields requested, 2485 taking over all the field values provided and filling in any 2486 remaining fields values. The EE SHOULD NOT add further fields, name 2487 components, and extensions or their (sub-)components. 2489 Note: We deliberately do not use "MUST" or "MUST NOT" here in order 2490 to allow more flexibility in case the rules given here are not 2491 sufficient for specific scenarios. The EE can populate the 2492 certificate request as wanted and ignore any of the requirements 2493 contained in the CertReqTemplateValue. On the other hand, a PKI 2494 management entity is free to ignore or replace any parts of the 2495 content of the certificate request provided by the EE. The 2496 CertReqTemplate PKI management operation offers means to ease a joint 2497 understanding which fields and/or which field values should be used. 2498 An example is provided in Appendix A. 2500 In case a field of type Name, e.g., subject, is present in the 2501 CertTemplate but has the value NULL-DN (i.e., has an empty list of 2502 RDN components), the field SHOULD be included in the certificate 2503 request and filled with content provided by the EE. Similarly, in 2504 case an X.509v3 extension is present but its extnValue is empty, this 2505 means that the extension SHOULD be included and filled with content 2506 provided by the EE. In case a Name component, for instance a common 2507 name or serial number, is given but has an empty string value, the EE 2508 SHOULD fill in a value. Similarly, in case an extension has sub- 2509 components (e.g., an IP address in a SubjectAltName field) with empty 2510 value, the EE SHOULD fill in a value. 2512 The EE MUST ignore (i.e., not include and fill in) empty fields, 2513 extensions, and sub-components that it does not understand or does 2514 not know suitable values to be filled in. 2516 The publicKey field of type SubjectPublicKeyInfo in the CertTemplate 2517 of the CertReqTemplateValue MUST be omitted. In case the PKI 2518 management entity wishes to make stipulation on algorithms the EE may 2519 use for key generation, this MUST be specified using the keySpec 2520 field as specified in CMP Updates Section 2.15 2521 [I-D.ietf-lamps-cmp-updates]. 2523 The keySpec field, if present, specifies the public key types 2524 optionally with parameters, and/or RSA key lengths for which a 2525 certificate may be requested. 2527 The value of a keySpec element with the OID id-regCtrl-algId, as 2528 specified in CMP Updates Section 2.15 [I-D.ietf-lamps-cmp-updates], 2529 MUST be of type AlgorithmIdentifier and give an algorithm other than 2530 RSA. For EC keys the curve information MUST be specified as 2531 described in the respective standard documents. 2533 The value of a keySpec element with the OID id-regCtrl-rsaKeyLen, as 2534 specified in CMP Updates Section 2.15 [I-D.ietf-lamps-cmp-updates], 2535 MUST be a positive integer value and give an RSA key length. 2537 In the CertTemplate of the CertReqTemplateValue the serialNumber, 2538 signingAlg, issuerUID, and subjectUID fields MUST be omitted. 2540 Specific prerequisites augmenting the prerequisites in Section 3.4: 2542 * When using the generalInfo field certProfile, the EE MUST know the 2543 identifier needed to indicate the requested certificate profile. 2545 The message sequence for this PKI management operation is as given 2546 above, with the following specific content: 2548 1 the infoType OID to use is id-it-certReqTemplate 2550 2 the id-it-certProfile generalInfo field in the header of the 2551 request MAY contain the name of the requested certificate request 2552 template 2554 3 the infoValue of the request MUST be absent 2556 4 if present, the infoValue of the response MUST be a 2557 CertReqTemplateValue containing a CertTemplate structure and an 2558 optional keySpec field 2560 Detailed Description of infoValue Field of genp: 2562 InfoValue OPTIONAL 2563 -- MUST be absent if no requirements are available 2564 -- MUST be present if the PKI management entity has any 2565 -- requirements on the contents of the certificate template 2566 certTemplate REQUIRED 2567 -- MUST be present if infoValue is present 2568 -- MUST contain the required CertTemplate structure elements 2569 -- The SubjectPublicKeyInfo field MUST be absent 2570 keySpec OPTIONAL 2571 -- MUST be absent if no requirements on the public key are 2572 -- available 2573 -- MUST be present if the PKI management entity has any 2574 -- requirements on the keys generated 2575 -- MUST contain one AttributeTypeAndValue per supported 2576 -- algorithm with attribute id-regCtrl-algId or 2577 -- id-regCtrl-rsaKeyLen 2579 4.3.4. CRL Update Retrieval 2581 This PKI management operation can be used by an EE to request a new 2582 CRL. If a CA offers methods to access a CRL, it may include CRL 2583 distribution points or authority information access extensions as 2584 specified in RFC 5280 [RFC5280] into the issued certificates. In 2585 addition, CMP offers CRL provisioning functionality as part of the 2586 PKI management operation. 2588 An EE requests a CRL update from the PKI management entity by sending 2589 a general message with OID id-it-crlStatusList. The EE MUST include 2590 the CRL source identifying the requested CRL and, if available, the 2591 thisUpdate time of the most current CRL instance it already has, as 2592 specified in CMP Updates Section 2.16 [I-D.ietf-lamps-cmp-updates]. 2593 The PKI management entity MUST respond with a general response with 2594 OID id-it-crls. If no thisUpdate value was given by the EE, the PKI 2595 management entity MUST return the latest CRL available. If a 2596 thisUpdate value was given, the PKI management entity MUST return the 2597 latest available CRL in case this CRL is more recent, otherwise the 2598 infoValue in the response message MUST be absent. 2600 The EE MUST identify the requested CRL either by its CRL distribution 2601 point name or issuer name. The CRL distribution point name can 2602 either be provided form the CRL distribution points extension of the 2603 certificate to be validated or from the issuing distribution point 2604 extension from the CRL to be updated. If no CRL distribution name is 2605 available to identify the CRL, the EE can use the issuer name either 2606 from the certificate to be validated or from the CRL to be updated. 2608 The PKI management entity SHOULD treat a CRL distribution point name 2609 as an internal pointer to identify a CRL for which is available at 2610 the PKI management entity directly. It is not intended as a way to 2611 fetch an arbitrary CRL from an external location. 2613 In addition to the prerequisites specified in Section 3.4, the EE 2614 MUST know which CRL to request. 2616 Note: If the EE does not want to request a specific CRL it MAY use 2617 instead a general message with OID id-it-currentCrl as specified in 2618 RFC 4210 Section 5.3.19.6 [RFC4210]. 2620 The message sequence for this PKI management operation is as given 2621 above, with the following specific content: 2623 1 the infoType OID to use is id-it-crlStatusList in the request and 2624 id-it-crls in the response 2626 2 the infoValue of the request MUST be present and contain a 2627 CRLStatus structure 2629 3 if present, the infoValue of the response MUST contain a CRL 2631 Detailed Description of infoValue Field of genm: 2633 CRLSource REQUIRED 2634 -- MUST contain exactly one CRLSource structure 2635 -- MUST contain the dpn choice of type DistributionPointName if 2636 -- the CRL distribution point name is available 2637 -- Otherwise, MUST contain the issuer choice identifying the CA 2638 -- that issues the CRL. It MUST contain the issuer DN in the 2639 -- directoryName field of a GeneralName element. 2640 thisUpdate OPTIONAL 2641 -- SHOULD contain the thisUpdate field of the latest CRL form 2642 -- the issuer specified in the given dpn or issuer field, 2643 -- in case such a CRL is already known by the EE 2645 Detailed Description of infoValue Field of genp: 2647 infoValue OPTIONAL 2648 -- MUST be absent if no CRL to be returned is available 2649 -- MUST contain one CRL update from the referenced source, if a 2650 -- thisUpdate value was not given or a more recent CRL is 2651 -- available 2653 4.4. Handling Delayed Delivery 2655 This is a variant of all PKI management operations described in this 2656 document. It is initiated in case a PKI management entity cannot 2657 respond to a request message in a timely manner, typically due to 2658 offline or asynchronous upstream communication, or due to delays in 2659 handling the request. The polling mechanism has been specified in 2660 RFC 4210 Section 5.3.22 [RFC4210] and updated by 2661 [I-D.ietf-lamps-cmp-updates]. 2663 Depending on the PKI architecture, the entity initiating delayed 2664 delivery is not necessarily the PKI management entity directly 2665 addressed by the EE. 2667 When initiating delayed delivery of a message received from an EE, 2668 the PKI management entity MUST respond with an ip/cp/kup/error 2669 message including the status "waiting". On receiving this response, 2670 the EE MUST store in its transaction context the senderNonce of the 2671 preceding request message because this value will be needed for 2672 checking the recipNonce of the final response to be received after 2673 polling. It sends a poll request with certReqId 0 if referring to 2674 the CertResponse element contained in the ip/cp/kup message, else -1 2675 to refer to the whole message. In case the final response is not yet 2676 available, the PKI management entity that initiated the delayed 2677 delivery MUST answer with a poll response, with the same certReqId. 2678 The included checkAfter time value indicates the minimum number of 2679 seconds that SHOULD elapse before the EE sends a new pollReq message 2680 to the PKI management entity. This is repeated until a final 2681 response is available or any party involved gives up on the current 2682 PKI management operation, i.e., a timeout occurs. 2684 When the PKI management entity that initiated delayed delivery can 2685 provide the final response for the original request message of the 2686 EE, it MUST send this response to the EE. Using this response, the 2687 EE can continue the current PKI management operation as usual. 2689 No specific prerequisites apply in addition to those of the 2690 respective PKI management operation. 2692 Message Flow: 2694 Step# EE PKI management entity 2695 1 format request 2696 message 2697 2 -> request -> 2698 3 handle or forward 2699 request 2700 4 format ip/cp/kup/error 2701 with status "waiting" 2702 response in case no 2703 immediate final response 2704 is available, 2705 5 <- ip/cp/kup/error <- 2706 6 handle 2707 ip/cp/kup/error 2708 with status 2709 "waiting" 2711 -------------------------- start polling -------------------------- 2713 7 format pollReq 2714 8 -> pollReq -> 2715 9 handle or forward pollReq 2716 10 in case the final response 2717 for the original request 2718 is available, continue 2719 with step 14 2720 otherwise, format or 2721 receive pollRep with 2722 checkAfter value 2723 11 <- pollRep <- 2724 12 handle pollRep 2725 13 let checkAfter 2726 time elapse and 2727 continue with 2728 step 7 2730 ----------------- end polling, continue as usual ------------------ 2732 14 format or receive 2733 final response on 2734 original request 2735 15 <- response <- 2736 16 handle final 2737 response 2739 Detailed Message Description: 2741 Response with Status "waiting" -- ip/cp/kup/error 2743 Field Value 2745 header 2746 -- As described in Section 3.1 2748 body 2749 -- as described for the respective PKI management operation, with 2750 -- the following adaptations: 2751 status REQUIRED -- in case of ip/cp/kup 2752 pKIStatusInfo REQUIRED -- in case of error response 2753 -- PKIStatusInfo structure MUST be present 2754 status REQUIRED 2755 -- MUST be status "waiting" 2756 statusString OPTIONAL 2757 -- MAY be any human-readable text for debugging, logging or to 2758 -- display in a GUI 2759 failInfo PROHIBITED 2761 protection REQUIRED 2762 -- As described in Section 3.2 2764 extraCerts OPTIONAL 2765 -- As described in Section 3.3 2767 Polling Request -- pollReq 2769 Field Value 2771 header 2772 -- As described in Section 3.1 2774 body 2775 -- The message of the EE asking for the final response or for a 2776 -- time to check again 2777 pollReq REQUIRED 2778 certReqId REQUIRED 2779 -- MUST be 0 if referring to a CertResponse element, else -1 2781 protection REQUIRED 2782 -- As described in Section 3.2 2783 -- MUST use the same credentials as in the first request message 2784 -- of the PKI management operation 2786 extraCerts RECOMMENDED 2787 -- As described in Section 3.3 2788 -- MAY be omitted if the message size is critical and 2789 -- the PKI management entity caches the extraCerts from the 2790 -- first request message of the PKI management operation 2792 Polling Response -- pollRep 2794 Field Value 2796 header 2797 -- As described in Section 3.1 2799 body 2800 -- The message indicates the delay after which the EE SHOULD 2801 -- send another pollReq message for this transaction 2802 pollRep REQUIRED 2803 certReqId REQUIRED 2804 -- MUST be 0 if referring to a CertResponse element, else -1 2805 checkAfter REQUIRED 2806 -- time in seconds to elapse before a new pollReq SHOULD be sent 2807 reason OPTIONAL 2808 -- MAY be any human-readable text for debugging, logging or to 2809 -- display in a GUI 2811 protection REQUIRED 2812 -- As described in Section 3.2 2813 -- MUST use the same credentials as in the first response 2814 -- message of the PKI management operation 2816 extraCerts RECOMMENDED 2817 -- As described in Section 3.3 2818 -- MAY be omitted if the message size is critical and the EE has 2819 -- cached the extraCerts from the first response message of 2820 -- the PKI management operation 2822 Final Response - Any Type of Response Message 2824 Field Value 2826 header 2828 -- MUST be the header as described for the response message 2829 -- of the respective PKI management operation 2831 body 2832 -- The response of the PKI management entity to the initial 2833 -- request as described in the respective PKI management 2834 -- operation 2836 protection REQUIRED 2837 -- MUST be as described for the response message of the 2838 -- respective PKI management operation 2840 extraCerts REQUIRED 2841 -- MUST be as described for the response message of the 2842 -- respective PKI management operation 2844 5. PKI Management Entity Operations 2846 This section focuses on request processing by a PKI management 2847 entity. Depending on the network and PKI solution design, this can 2848 be an RA or CA, any of which may include protocol conversion or 2849 central key generation (i.e., acting as a KGA). 2851 A PKI management entity may directly respond to request messages from 2852 downstream and report errors. In case the PKI management entity is 2853 an RA it typically forwards the received request messages upstream 2854 after checking them and forwards respective response messages 2855 downstream. Besides responding to messages or forwarding them, a PKI 2856 management entity may request or revoke certificates on behalf of 2857 EEs. A PKI management entity may also need to manage its own 2858 certificates and thus act as an EE using the PKI management 2859 operations specified in Section 4. 2861 5.1. Responding to Requests 2863 The PKI management entity terminating the PKI management operation at 2864 CMP level MUST respond to all received requests by returning a 2865 related CMP response message or an error. Any intermediate PKI 2866 management entity MAY respond depending on the PKI configuration and 2867 policy. 2869 In addition to the checks described in Section 3.5, the responding 2870 PKI management entity SHOULD check that a request that initiates a 2871 new PKI management operation does not use a transactionID that is 2872 currently in use. The failInfo bit value to use on reporting failure 2873 as described in Section 3.6.4 is transactionIdInUse. If any of these 2874 verification steps or any of the essential checks described in the 2875 following subsections fails, the PKI management entity MUST proceed 2876 as described in Section 3.6. 2878 The responding PKI management entity SHOULD copy the sender field of 2879 the request to the recipient field of the response, MUST copy the 2880 senderNonce of the request to the recipNonce of the response, and 2881 MUST use the same transactionID for the response. 2883 5.1.1. Responding to a Certificate Request 2885 An ir/cr/p10cr/kur message is used to request a certificate as 2886 described in Section 4.1. The responding PKI management entity MUST 2887 proceed as follows unless it initiates delayed delivery as described 2888 in Section 5.1.5. 2890 The PKI management entity SHOULD check the message body according to 2891 the applicable requirements from Section 4.1. Possible failInfo bit 2892 values used for error reporting in case a check failed include 2893 badCertId and badCertTemplate. It MUST verify the presence and value 2894 of the proof-of-possession (failInfo bit: badPOP), unless central key 2895 generation is requested. In case the special POP value "raVerified" 2896 is given, it SHOULD check that the request message was signed using a 2897 certificate containing the cmcRA extended key usage (failInfo bit: 2898 notAuthorized). The PKI management entity SHOULD perform also any 2899 further checks on the certTemplate contents (failInfo: 2900 badCertTemplate) according to any applicable PKI policy and 2901 certificate profile. 2903 If the requested certificate is available, the PKI management entity 2904 MUST respond with a positive ip/cp/kup message as described in 2905 Section 4.1. 2907 Note: If central key generation is performed by the responding PKI 2908 management entity, the responding PKI management entity MUST include 2909 in the response the privateKey field as specified in Section 4.1.6. 2910 It may have issued the certificate for the newly generated key pair 2911 itself if it is a CA, or have requested the certificate on behalf of 2912 the EE as described in Section 5.3.1, or have received it by other 2913 means from a CA. 2915 The prerequisites of the respective PKI management operation as 2916 specified in Section 4.1 apply. 2918 Note: If the EE requested omission of the certConf message, the PKI 2919 management entity SHOULD handle it as described in Section 4.1.1 and 2920 therefore MAY grant this by including the implicitConfirm extension 2921 in the response header. 2923 5.1.2. Responding to a Confirmation Message 2925 A PKI management entity MUST handle a certConf message if it has 2926 responded before with a positive ip/cp/kup message not granting 2927 implicit confirmation. It SHOULD check the message body according to 2928 the requirements given in Section 4.1.1 (failInfo bit: badCertId) and 2929 react as described there. 2931 The prerequisites of the respective PKI management operation as 2932 specified in Section 4.1 apply. 2934 5.1.3. Responding to a Revocation Request 2936 An rr message is used to request revocation of a certificate. The 2937 responding PKI management entity SHOULD check the message body 2938 according to the requirements in Section 4.2. It MUST make sure that 2939 the referenced certificate exists (failInfo bit: badCertId), has been 2940 issued by the addressed CA, and is not already expired or revoked 2941 (failInfo bit: certRevoked). On success it MUST respond with a 2942 positive rp message as described in Section 4.2. 2944 No specific prerequisites apply in addition to those specified in 2945 Section 3.4. 2947 5.1.4. Responding to a Support Message 2949 A genm message is used to retrieve extra content. The responding PKI 2950 management entity SHOULD check the message body according to the 2951 applicable requirements in Section 4.3 and perform any further checks 2952 depending on the PKI policy. On success it MUST respond with a genp 2953 message as described there. 2955 Note: The responding PKI management entity may generate the response 2956 from scratch or reuse the contents of previous responses. Therefore, 2957 it may be worth caching the body of the response message as long as 2958 the contained information is still valid, such that further requests 2959 for the same contents can be answered immediately. 2961 No specific prerequisites apply in addition to those specified in 2962 Section 3.4. 2964 5.1.5. Initiating Delayed Delivery 2966 This functional extension can be used by a PKI management entity in 2967 case the response to a request takes longer than usual. In this case 2968 the PKI management entity MUST completely validate the request as 2969 usual and then start preparing the response or forward the request 2970 further upstream as soon as possible. In the meantime, it MUST 2971 respond with an ip/cp/kup/error message including the status 2972 "waiting" and handle subsequent polling as described in Section 4.4. 2974 Note: Typically, as stated in Section 5.2.3, an intermediate PKI 2975 management entity should not change the sender and recipient nonces 2976 even in case it modifies a request or a response message. In the 2977 special case of delayed delivery initiated by an intermediate PKI 2978 management entity, there is an exception. Between the EE and this 2979 PKI management entity, pollReq and pollRep messages are exchanged 2980 handling the nonces as usual. Yet when the final response from 2981 upstream has arrived at the PKI management entity, this response 2982 contains the recipNonce copied (as usual) from the senderNonce in the 2983 original request message. The PKI management entity that initiated 2984 the delayed delivery may replace the recipNonce in the response 2985 message with the senderNonce of the last received pollReq because the 2986 downstream entities, including the EE, might expect it in this way. 2987 Yet the check specified in Section 3.5 allows to alternatively use 2988 the senderNonce of the original request. 2990 No specific prerequisites apply in addition to those of the 2991 respective PKI management operation. 2993 5.2. Forwarding Messages 2995 In case the PKI solution consists of intermediate PKI management 2996 entities (i.e., LRA or RA), each CMP request message coming from an 2997 EE or any other downstream PKI management entity SHOULD be forwarded 2998 to the next (upstream) PKI management entity as described in this 2999 section and otherwise MUST be answered as described in Section 5.1. 3000 Any received response message or error message MUST be forwarded to 3001 the next (downstream) PKI entity. 3003 In addition to the checks described in Section 3.5, the forwarding 3004 PKI management entity MAY verify the proof-of-possession for 3005 ir/cr/p10cr/kur messages. If one of these verification procedures 3006 fails, the RA proceeds as described in Section 3.6. 3008 A PKI management entity SHOULD NOT change the received message unless 3009 necessary. The PKI management entity SHOULD only update the message 3010 protection and the certificate template in a certificate request 3011 message if this is technically necessary. Concrete PKI system 3012 specifications may define in more detail when to do so. 3014 This is particularly relevant in the upstream communication of a 3015 request message. 3017 Each forwarding PKI management entity has one or more 3018 functionalities. It may 3020 * verify the identities of EEs and make authorization decisions for 3021 certification request processing based on local PKI policy, 3023 * add or modify fields of certificate request messages, 3025 * store data from a message in a database for later usage or audit 3026 purposes, 3028 * provide traversal of a network boundary, 3030 * replace a MAC-based protection by a signature-based protection 3031 that can be verified also further upstream, 3033 * double-check if the messages transferred back and forth are 3034 properly protected and well-formed, 3036 * provide an authentic indication that it has performed all required 3037 checks, 3039 * initiate a delayed delivery due to delays transferring messages or 3040 handling requests, or 3042 * collect messages from multiple RAs and forward them jointly. 3044 The decision if a message should be forwarded 3046 * unchanged with the original protection, 3048 * unchanged with a new protection, or 3050 * changed with a new protection 3052 depends on the PKI solution design and the associated security policy 3053 (CP/CPS [RFC3647]). 3055 A PKI management entity MUST replace or add a protection of a message 3056 if it 3058 * needs to securely indicate that it has done checks or validations 3059 on the message to one of the next (upstream) PKI management entity 3060 or 3062 * needs to protect the message using a key and certificate from a 3063 different PKI. 3065 A PKI management entity MUST replace a protection of a message if it 3067 * performs changes to the header or the body of the message or 3069 * needs to convert from or to a MAC-based protection. 3071 This is particularly relevant in the upstream communication of 3072 certificate request messages. 3074 Note that the message protection covers only the header and the body 3075 and not the extraCerts. The PKI management entity MAY change the 3076 extraCerts in any of the following message adaptations, e.g., to 3077 sort, add, or delete certificates to support subsequent PKI entities. 3078 This may be particularly helpful to augment upstream messages with 3079 additional certificates or to reduce the number of certificates in 3080 downstream messages when forwarding to constrained devices. 3082 5.2.1. Not Changing Protection 3084 This variant means that a PKI management entity forwards a CMP 3085 message without changing the header, body, or protection. In this 3086 case the PKI management entity acts more like a proxy, e.g., on a 3087 network boundary, implementing no specific RA-like security 3088 functionality that requires an authentic indication to the PKI. 3089 Still the PKI management entity might implement checks that result in 3090 refusing to forward the request message and instead responding as 3091 specified in Section 3.6. 3093 This variant of forwarding a message or the one described in 3094 Section 5.2.2.1 SHOULD be used for kur messages and for central key 3095 generation. 3097 No specific prerequisites apply in addition to those specified in 3098 Section 3.4. 3100 5.2.2. Adding Protection and Batching of Messages 3102 This variant of forwarding a message means that a PKI management 3103 entity adds another protection to PKI management messages before 3104 forwarding them. 3106 The nested message is a PKI management message containing a 3107 PKIMessages sequence as its body containing one or more CMP messages. 3109 As specified in the updated Section 5.1.3.4 of RFC 4210 [RFC4210] 3110 (see also CMP Updates Section 2.6 [I-D.ietf-lamps-cmp-updates]) there 3111 are various use cases for adding another protection by a PKI 3112 management entity. Specific procedures are described in more detail 3113 in the following sections. 3115 Detailed Message Description: 3117 Nested Message - nested 3119 Field Value 3121 header 3122 -- As described in Section 3.1 3124 body 3125 -- Container to provide additional protection to original 3126 -- messages and to bundle request messages or alternatively 3127 -- response messages 3128 PKIMessages REQUIRED 3129 -- MUST be a sequence of one or more CMP messages 3131 protection REQUIRED 3132 -- As described in Section 3.2 using the CMP protection key of 3133 -- the PKI management entity 3135 extraCerts REQUIRED 3136 -- As described in Section 3.3 3138 5.2.2.1. Adding Protection to a Request Message 3140 This variant means that a PKI management entity forwards a CMP 3141 message while authentically indicating successful validation and 3142 approval of a request message without changing the original message. 3144 By adding a protection using its own CMP protecting key the PKI 3145 management entity provides a proof of verifying and approving the 3146 message as described above. Thus, the PKI management entity acts as 3147 an actual Registration Authority (RA), which implements important 3148 security functionality of the PKI. Applying an additional protection 3149 is specifically relevant when forwarding a message that requests a 3150 certificate update or central key generation. This is because the 3151 original protection of the EE must be preserved while adding an 3152 indication of approval by the PKI management entity. 3154 The PKI management entity wrapping the original request message in a 3155 nested message structure MUST take over the recipient, recipNonce, 3156 and transactionID of the original message to the nested message and 3157 apply signature-based protection. The additional signature serves as 3158 proof of verification and authorization by this PKI management 3159 entity. 3161 The PKI management entity receiving such a nested message that 3162 contains a single request message MUST validate the additional 3163 protection signature on the nested message and check the 3164 authorization for the approval it implies. 3166 The PKI management entity responding to the request contained in the 3167 nested message sends the response message as described in 3168 Section 5.1, without wrapping it in a nested message. 3170 Note: This form of nesting messages is characterized by the fact that 3171 the transactionID in the header of the nested message is the same as 3172 the one used in the included message. 3174 Specific prerequisites augmenting the prerequisites in Section 3.4: 3176 * The PKI management entity MUST be able to validate the respective 3177 request and have the authorization to perform approval of the 3178 request according to the PKI policies. 3180 Message Flow: 3182 Step# PKI management entity PKI management entity 3183 1 format nested 3184 2 -> nested -> 3185 3 handle or forward nested 3186 4 format or receive response 3187 5 <- response <- 3188 6 forward response 3190 5.2.2.2. Batching Messages 3192 A PKI management entity MAY bundle any number of PKI management 3193 messages for batch processing or to transfer a bulk of PKI management 3194 messages using the nested message structure. In this use case, 3195 nested messages are used both on the upstream interface towards the 3196 next PKI management entity and on the downstream interface from the 3197 PKI management entity towards the EE. 3199 This PKI management operation is typically used on the interface 3200 between an LRA and an RA to bundle several messages for offline 3201 delivery. In this case the LRA needs to initiate delayed delivery as 3202 described in Section 5.1.5. If the RA needs different routing 3203 information per nested PKI management message a suitable mechanism 3204 may need to be implemented. Since this mechanism strongly depends on 3205 the requirements of the target architecture, it is out of scope of 3206 this document. 3208 A nested message containing requests is generated locally at the PKI 3209 management entity. For the upstream nested message, the PKI 3210 management entity acts as a protocol end point and therefore a fresh 3211 transactionID and a fresh senderNonce MUST be used in the header of 3212 the nested message. An upstream nested message may contain request 3213 messages, e.g., ir, cr, p10cr, kur, pollReq, certConf, rr, or genm. 3215 While building the upstream nested message the PKI management entity 3216 SHOULD store the sender, transactionID, and senderNonce fields of all 3217 bundled messages together with the transactionID of the upstream 3218 nested message. 3220 Such an upstream nested message is sent to the next PKI management 3221 entity. The upstream PKI management entity that unbundles it MUST 3222 handle each of the included request messages as usual. It MUST 3223 answer with a downstream nested message. This downstream nested 3224 message MUST use the transactionID of the upstream nested message and 3225 return the senderNonce of the upstream nested message as the 3226 recipNonce of the downstream nested message. The downstream nested 3227 message SHOULD bundle the individual response messages (e.g., ip, cp, 3228 kup, pollRep, pkiConf, rp, genp, error) for all original request 3229 messages of the upstream nested message. While unbundling the 3230 downstream nested message, the former PKI management entity can 3231 determine lost and unexpected responses based on the previously 3232 stored transactionIDs. When it forwards the unbundled responses, any 3233 extra messages SHOULD be dropped, and any missing response message 3234 (failInfo bit: systemUnavail) MUST be answered with an error message 3235 to inform the respective requester about the failed certificate 3236 management operation. 3238 Note: This form of nesting messages is characterized by the fact that 3239 the transactionID in the header of the nested message is different to 3240 those used in the included messages. 3242 The protection of the nested messages SHOULD NOT be regarded as an 3243 indication of verification or approval of the bundled PKI request 3244 messages. 3246 No specific prerequisites apply in addition to those specified in 3247 Section 3.4. 3249 Message Flow: 3251 Step# PKI management entity PKI management entity 3252 1 format nested 3253 2 -> nested -> 3254 3 handle or forward nested 3255 4 format or receive nested 3256 5 <- nested <- 3257 6 handle nested 3259 5.2.3. Replacing Protection 3261 The following two alternatives can be used by any PKI management 3262 entity forwarding a CMP message with or without changes while 3263 providing its own protection and in this way asserting approval of 3264 the message. 3266 By replacing the existing protection using its own CMP protecting key 3267 the PKI management entity provides a proof of verifying and approving 3268 the message as described above. Thus, the PKI management entity acts 3269 as an actual Registration Authority (RA), which implements important 3270 security functionality of the PKI. 3272 Before replacing the existing protection by a new protection, the PKI 3273 management entity MUST verify the protection provided and approve its 3274 content, including any modifications that it may perform. It MUST 3275 also check that the sender, as authenticated by the message 3276 protection, is authorized for the given operation. 3278 These message adaptations MUST NOT be applied to kur messages 3279 described in Section 4.1.3 since their original protection using the 3280 key and certificate to be updated needs to be preserved, unless the 3281 regCtrl OldCertId is used to strongly identify the certificate to be 3282 updated. 3284 These message adaptations MUST NOT be applied to certificate request 3285 messages described in for central key generation Section 4.1.6 since 3286 their original protection needs to be preserved up to the Key 3287 Generation Authority, which needs to use it for encrypting the new 3288 private key for the EE. 3290 In both the kur and central key generation cases, if a PKI management 3291 entity needs to state its approval of the original request message it 3292 MUST provide this using a nested message as specified in 3293 Section 5.2.2.1. 3295 When an intermediate PKI management entity modifies a message, it 3296 SHOULD NOT change the transactionID nor the sender and recipient 3297 nonces. 3299 5.2.3.1. Not Changing Proof-of-Possession 3301 This variant of forwarding a message means that a PKI management 3302 entity forwards a CMP message with or without modifying the message 3303 header or body while preserving any included proof-of-possession. 3305 In case the PKI management entity breaks an existing proof-of- 3306 possession, the message adaptation described in Section 5.2.3.2 needs 3307 to be applied instead. 3309 Specific prerequisites augmenting the prerequisites in Section 3.4: 3311 * The PKI management entity MUST be able to validate the respective 3312 request and have the authorization to perform approval of the 3313 request according to the PKI policies. 3315 5.2.3.2. Using raVerified 3317 This variant of forwarding a message needs to be used if a PKI 3318 management entity breaks a signature-based proof-of-possession in a 3319 certificate request message, for instance because it forwards an ir 3320 or cr message with modifications of the certTemplate, i.e., 3321 modification, addition, or removal of fields. 3323 The PKI management entity MUST verify the proof-of-possession 3324 contained in the original message using the included public key. If 3325 successful, the PKI management entity MUST change the popo field 3326 value to raVerified. 3328 Specific prerequisites augmenting the prerequisites in Section 3.4: 3330 * The PKI management entity MUST be authorized to replace the proof- 3331 of-possession (after verifying it) with raVerified. 3333 * The PKI management entity MUST be able to validate the respective 3334 request and have the authorization to perform approval of the 3335 request according to the PKI policies. 3337 Detailed Description of popo Field of certReq Structure: 3339 popo 3340 raVerified REQUIRED 3341 -- MUST have the value NULL and indicates that the PKI 3342 -- management entity verified the popo of the original message 3344 5.3. Acting on Behalf of other PKI Entities 3346 A PKI management entity may need to request a PKI management 3347 operation on behalf of another PKI entity. In this case the PKI 3348 management entity initiates the respective PKI management operation 3349 as described in Section 4 acting in the role of the EE. 3351 5.3.1. Requesting a Certificate 3353 A PKI management entity may use on of the PKI management operations 3354 described in Section 4.1 to request a certificate on behalf of 3355 another PKI entity. It either generates the key pair itself and 3356 inserts the new public key in the subjectPublicKey field of the 3357 request certTemplate, or it uses a certificate request received from 3358 downstream, e.g., by means of a different protocol. In the latter 3359 case it SHOULD verify the received proof-of-possession. 3361 No specific prerequisites apply in addition to those specified in 3362 Section 4.1. 3364 Note: An upstream PKI management entity will not be able to 3365 differentiate this PKI management operation from the one described in 3366 Section 5.2.3 because in both cases the message is protected by the 3367 PKI management entity. 3369 The message sequence for this PKI management operation is identical 3370 to the respective PKI management operation given in Section 4.1, with 3371 the following changes: 3373 1 The request messages MUST be signed using the CMP protection key 3374 of the PKI management entity taking the role of the EE in this 3375 operation. 3377 2 If inclusion of a proper proof-of-possession is not possible the 3378 PKI management entity MUST verify the POP provided from downstream 3379 and use "raVerified" in its upstream request. 3381 5.3.2. Revoking a Certificate 3383 A PKI management entity may use the PKI management operation 3384 described in Section 4.2 to revoke a certificate of another PKI 3385 entity. This revocation request message MUST be signed by the PKI 3386 management entity using its own CMP protection key to prove to the 3387 PKI authorization to revoke the certificate on behalf of that PKI 3388 entity. 3390 No specific prerequisites apply in addition to those specified in 3391 Section 4.2. 3393 Note: An upstream PKI management entity will not be able to 3394 differentiate this PKI management operation from the ones described 3395 in Section 5.2.3. 3397 The message sequence for this PKI management operation is identical 3398 to that given in Section 4.2, with the following changes: 3400 1 The rr message MUST be signed using the CMP protection key of the 3401 PKI management entity acting on behalf of the EE in this 3402 operation. 3404 6. CMP Message Transfer Mechanisms 3406 CMP messages are designed to be self-contained, such that in 3407 principle any reliable transfer mechanism can be used. HTTP SHOULD 3408 and CoAP MAY be used for online transfer. CMP messages MAY also be 3409 piggybacked on any other reliable transfer protocol. File-based 3410 transfer MAY be used in case offline transfer is required. 3412 Independently of the means of transfer, it can happen that messages 3413 are lost or that a communication partner does not respond. To 3414 prevent waiting indefinitely, each CMP client component SHOULD use a 3415 configurable per-request timeout, and each CMP server component 3416 SHOULD use a configurable per-response timeout in case a further 3417 Request message is to be expected from the client side within the 3418 same transaction. In this way a hanging transaction can be closed 3419 cleanly with an error as described in Section 3.6 (failInfo bit: 3420 systemUnavail) and related resources (for instance, any cached 3421 extraCerts) can be freed. 3423 Moreover, there are various situations where the delivery of messages 3424 gets delayed. For instance, a serving PKI management entity might 3425 take longer than expected to form a response due to administrative 3426 processes, resource constraints, or upstream message delivery delays. 3427 The transport layer itself may cause delays, for instance due to 3428 offline transport, network segmentation, or intermittent network 3429 connectivity. Part of these issues can be detected and handled at 3430 CMP level using pollReq and pollRep messages as described in 3431 Section 4.4, while others are better handled at transfer level. 3432 Depending on the transfer protocol and system architecture, solutions 3433 for handling delays at transfer level may be present and can be used 3434 for CMP connections, for instance connection re-establishment and 3435 message retransmission. 3437 Note: Long timeout periods are helpful to minimize the need for 3438 polling and maximize chances to handle transfer issues at lower 3439 levels. 3441 Note: When using TCP and similar reliable connection-oriented 3442 transport protocols, which is typical in conjunction with HTTP, there 3443 is the option to keep the connection alive over multiple request- 3444 response message pairs. This may improve efficiency, though is not 3445 required from a security point of view. 3447 When conveying CMP messages in HTTP, CoAP, or MIME-based transfer 3448 protocols, the internet media type "application/pkixcmp" MUST be set 3449 for transfer encoding as specified in Section 5.3 of RFC 2510 3450 [RFC2510], Section 2.4 of CMP over CoAP 3451 [I-D.ietf-ace-cmpv2-coap-transport], and Section 3.4 of CMP over HTTP 3452 [RFC6712]. 3454 6.1. HTTP Transfer 3456 This transfer mechanism can be used by a PKI entity to transfer CMP 3457 messages over HTTP. If HTTP transfer is used the specifications as 3458 described in [RFC6712] and updated by CMP Updates 3459 [I-D.ietf-lamps-cmp-updates] MUST be followed. 3461 PKI management operations SHOULD use URI paths consisting of '/.well- 3462 known/cmp/' or '/.well-known/cmp/p//' as specified in CMP 3463 Updates Section 3.3 [I-D.ietf-lamps-cmp-updates] followed by an 3464 operation label depending on the type of PKI management operation. 3466 +============================+====================+=========+ 3467 | PKI Management Operation | URI Path Segment | Details | 3468 +============================+====================+=========+ 3469 | Enrolling an End Entity to | initialization | Section | 3470 | a New PKI | | 4.1.1 | 3471 +----------------------------+--------------------+---------+ 3472 | Enrolling an End Entity to | certification | Section | 3473 | a Known PKI | | 4.1.2 | 3474 +----------------------------+--------------------+---------+ 3475 | Updating a Valid | keyupdate | Section | 3476 | Certificate | | 4.1.3 | 3477 +----------------------------+--------------------+---------+ 3478 | Enrolling an End Entity | pkcs10 | Section | 3479 | Using a PKCS#10 Request | | 4.1.4 | 3480 +----------------------------+--------------------+---------+ 3481 | Revoking a Certificate | revocation | Section | 3482 | | | 4.2 | 3483 +----------------------------+--------------------+---------+ 3484 | Get CA Certificates | getcacerts | Section | 3485 | | | 4.3.1 | 3486 +----------------------------+--------------------+---------+ 3487 | Get Root CA Certificate | getrootupdate | Section | 3488 | Update | | 4.3.2 | 3489 +----------------------------+--------------------+---------+ 3490 | Get CA Certificates | getcertreqtemplate | Section | 3491 | | | 4.3.1 | 3492 +----------------------------+--------------------+---------+ 3493 | CRL Update Retrieval | getcrls | Section | 3494 | | | 4.3.4 | 3495 +----------------------------+--------------------+---------+ 3496 | Batching Messages | nested | Section | 3497 | | | 5.2.2.2 | 3498 | Note: This path element is | | | 3499 | applicable only between | | | 3500 | PKI management entities. | | | 3501 +----------------------------+--------------------+---------+ 3503 Table 1: HTTP URI Path Segment 3505 Independently of any variants used (see Section 4.1.5, Section 4.1.6, 3506 and Section 4.4) the operation label corresponding to the PKI 3507 management operation SHALL be used. 3509 Any certConf or pollReq messages are sent to the same endpoint as 3510 determined by the PKI management operation. 3512 When a single request message is nested as described in 3513 Section 5.2.2.1, the label to use is the same as for the underlying 3514 PKI management operation. 3516 By sending a request to its preferred endpoint, the PKI entity will 3517 recognize via the HTTP response status code whether a configured URI 3518 is supported by the PKI management entity. 3520 In case a PKI management entity receives an unexpected HTTP status 3521 code from upstream, it MUST respond downstream with an error message 3522 as described in Section 3.6 using a failInfo bit corresponding to the 3523 status code, e.g., systemFailure. 3525 For certificate management the major security goal is integrity and 3526 data origin authentication. For delivery of centrally generated 3527 keys, also confidentiality is a must. These goals are sufficiently 3528 achieved by CMP itself, also in an end-to-end fashion. If a second 3529 line of defense is required or general privacy concerns exist, TLS 3530 can be used to provide confidentiality on a hop-by-hop basis. 3532 TLS SHOULD be used with certificate-based authentication to further 3533 protect the HTTP transfer as described in [RFC2818]. The CMP 3534 transfer via HTTPS MUST use TLS server authentication and SHOULD use 3535 TLS client authentication. 3537 Note: The requirements for checking certificates given in [RFC5280] 3538 and either [RFC5246] or [RFC8446] MUST be followed for the TLS layer. 3539 Certificate status checking SHOULD be used for the TLS certificates 3540 of all communication partners. 3542 TLS with mutual authentication based on shared secret information MAY 3543 be used in case no suitable certificates for certificate-based 3544 authentication are available, e.g., a PKI management operation with 3545 MAC-based protection is used. 3547 Note: The entropy of the shared secret information is crucial for the 3548 level of protection available using shard secret information-based 3549 TLS authentication. A pre-shared key (PSK) mechanism is acceptable 3550 using shared secret information with an entropy of at least 128 bits. 3551 Otherwise, a password-authenticated key exchange (PAKE) protocol is 3552 RECOMMENDED. 3554 6.2. CoAP Transfer 3556 This transfer mechanism can be used by a PKI entity to transfer CMP 3557 messages over CoAP [RFC7252], e.g., in constrained environments. If 3558 CoAP transfer is used the specifications as described in CMP over 3559 CoAP [I-D.ietf-ace-cmpv2-coap-transport] MUST be followed. 3561 PKI management operations SHOULD use URI paths consisting of '/.well- 3562 known/cmp/' or '/.well-known/cmp/p//' as specified in CMP over 3563 CoAP Section 2.1 [I-D.ietf-ace-cmpv2-coap-transport] followed by an 3564 operation label depending on the type of PKI management operation. 3566 +=======================================+=========+=========+ 3567 | PKI Management Operation | URI | Details | 3568 | | Path | | 3569 | | Segment | | 3570 +=======================================+=========+=========+ 3571 | Enrolling an End Entity to a New PKI | ir | Section | 3572 | | | 4.1.1 | 3573 +---------------------------------------+---------+---------+ 3574 | Enrolling an End Entity to a Known | cr | Section | 3575 | PKI | | 4.1.2 | 3576 +---------------------------------------+---------+---------+ 3577 | Updating a Valid Certificate | kur | Section | 3578 | | | 4.1.3 | 3579 +---------------------------------------+---------+---------+ 3580 | Enrolling an End Entity Using a | p10 | Section | 3581 | PKCS#10 Request | | 4.1.4 | 3582 +---------------------------------------+---------+---------+ 3583 | Revoking a Certificate | rr | Section | 3584 | | | 4.2 | 3585 +---------------------------------------+---------+---------+ 3586 | Get CA Certificates | crts | Section | 3587 | | | 4.3.1 | 3588 +---------------------------------------+---------+---------+ 3589 | Get Root CA Certificate Update | rcu | Section | 3590 | | | 4.3.2 | 3591 +---------------------------------------+---------+---------+ 3592 | Get Certificate Request Template | att | Section | 3593 | | | 4.3.3 | 3594 +---------------------------------------+---------+---------+ 3595 | CRL Update Retrieval | crls | Section | 3596 | | | 4.3.4 | 3597 +---------------------------------------+---------+---------+ 3598 | Batching Messages | nest | Section | 3599 | | | 5.2.2.2 | 3600 | Note: This path element is applicable | | | 3601 | only between PKI management entities. | | | 3602 +---------------------------------------+---------+---------+ 3604 Table 2: CoAP URI Path Segment 3606 Independently of any variants used (see Section 4.1.5, Section 4.1.6, 3607 and Section 4.4) the operation label corresponding to the PKI 3608 management operation SHALL be used. 3610 Any certConf or pollReq messages are sent to the same endpoint as 3611 determined by the PKI management operation. 3613 When a single request message is nested as described in 3614 Section 5.2.2.1, the label to use is the same as for the underlying 3615 PKI management operation. 3617 By sending a request to its preferred endpoint, the PKI entity will 3618 recognize via the CoAP response status code whether a configured URI 3619 is supported by the PKI management entity. The CoAP-inherent 3620 discovery mechanisms MAY also be used. 3622 In case a PKI management entity receives an unexpected CoAP status 3623 code from upstream, it MUST respond downstream with an error message 3624 as described in Section 3.6 using a failInfo bit corresponding to the 3625 status code, e.g., systemFailure. 3627 Like for HTTP transfer , to offer a second line of defense or to 3628 provide hop-by-hop privacy protection, DTLS MAY be utilized as 3629 described in CMP over CoAP [I-D.ietf-ace-cmpv2-coap-transport]. 3631 6.3. Piggybacking on other Reliable Transfer 3633 CMP messages MAY also be transfer on some other reliable protocol, 3634 e.g., EAP or MQTT. Connection, delay, and error handling mechanisms 3635 similar to those specified for HTTP in Section 6.1 need to be 3636 implemented. 3638 A more detailed specification is out of scope of this document and 3639 would need to be given for instance in the scope of the transfer 3640 protocol used. 3642 6.4. Offline Transfer 3644 For transferring CMP messages between PKI entities, any mechanism can 3645 be used that is able to store and forward binary objects of 3646 sufficient length and with sufficient reliability while preserving 3647 the order of messages for each transaction. 3649 The transfer mechanism SHOULD be able to indicate message loss, 3650 excessive delay, and possibly other transmission errors. In such 3651 cases the PKI entities SHOULD report an error as specified in 3652 Section 3.6 as far as possible. 3654 6.4.1. File-Based Transfer 3656 CMP messages MAY be transferred between PKI entities using file-based 3657 mechanisms, for instance when an offline EE or a PKI management 3658 entity performs delayed delivery. Each file MUST contain the ASN.1 3659 DER encoding of one CMP message only, where the message may be 3660 nested. There MUST be no extraneous header or trailer information in 3661 the file. The file name extension ".pki" MUST be used. 3663 6.4.2. Other Asynchronous Transfer Protocols 3665 Other asynchronous transfer protocols, e.g., email or website 3666 up-/download, MAY transfer CMP messages between PKI entities. A MIME 3667 wrapping is defined for those environments that are MIME-native. The 3668 MIME wrapping in this section is specified in RFC 8551 Section 3.1 3669 [RFC8551]. 3671 The ASN.1 DER encoding of the CMP messages MUST be transferred using 3672 the "application/pkixcmp" content type and base64-encoded content 3673 transfer encoding as specified in RFC 2510 Section 5.3 [RFC2510]. A 3674 filename MUST be included either in a "content-type" or a "content- 3675 disposition" statement. The file name extension ".pki" MUST be used. 3677 7. Conformance Requirements 3679 This section defines which level of support for the various features 3680 specified in this profile is required for which type of PKI entity. 3682 7.1. PKI Management Operations 3684 The following table provides an overview of the PKI management 3685 operations specified in Section 4 and Section 5 and states whether 3686 support by conforming EE, RA, and CA implementations is mandatory, 3687 recommended, optional, or not applicable. Variants amend or change 3688 behavior of base PKI management operations and are therefore also 3689 included. 3691 The PKI management operation specifications in Section 4 assume that 3692 either the RA or CA is the PKI management entity that terminates the 3693 CMP protocol. If the RA terminates the CMP protocol it either 3694 responds directly as described in Section 5.1 or forwards the 3695 certificate management operation towards the CA not using CMP. 3696 Section 5.2 describes different options how an RA can forward a CMP 3697 message using CMP. Section 5.3 offers the option that an RA operates 3698 on behalf on an EE and therefore takes the role of the EE in 3699 Section 4. 3701 +==========+=============================+========+========+========+ 3702 | ID | PKI Management Operations | EE | RA | CA | 3703 | | and Variants | | | | 3704 +==========+=============================+========+========+========+ 3705 | Generic | Generic Aspects of PKI | MUST | MAY | MUST | 3706 | | Messages and PKI | | | | 3707 | | Management Operations, | | | | 3708 | | Section 3 | | | | 3709 +----------+-----------------------------+--------+--------+--------+ 3710 | IR | Enrolling an End Entity | MUST | MAY | MUST | 3711 | | to a New PKI, | | | | 3712 | | Section 4.1.1 | | | | 3713 +----------+-----------------------------+--------+--------+--------+ 3714 | CR | Enrolling an End Entity | MAY | MAY | MAY | 3715 | | to a Known PKI, | | | | 3716 | | Section 4.1.2 | | | | 3717 +----------+-----------------------------+--------+--------+--------+ 3718 | KUR | Updating a Valid | MUST | MAY | MUST | 3719 | | Certificate, | | | | 3720 | | Section 4.1.3 | | | | 3721 +----------+-----------------------------+--------+--------+--------+ 3722 | P10CR | Enrolling an End Entity | MAY | MAY | MAY | 3723 | | Using a PKCS#10 Request, | | | | 3724 | | Section 4.1.4 | | | | 3725 +----------+-----------------------------+--------+--------+--------+ 3726 | MAC | Using MAC-Based | SHOULD | SHOULD | SHOULD | 3727 | | Protection for | | 1) | | 3728 | | Enrollment, with IR, CR, | | | | 3729 | | KUR, and P10CR if | | | | 3730 | | supported, Section 4.1.5 | | | | 3731 +----------+-----------------------------+--------+--------+--------+ 3732 | CKeyGen | Adding Central Key Pair | MAY | MAY | MAY | 3733 | | Generation to Enrollment, | | | | 3734 | | IR, CR, KUR, and P10CR if | | | | 3735 | | supported, Section 4.1.6 | | | | 3736 | | | | | | 3737 | | If supported, key | | | | 3738 | | agreement key management | | | | 3739 | | technique is REQUIRED, | | | | 3740 | | and key transport and | | | | 3741 | | password-based key | | | | 3742 | | management techniques are | | | | 3743 | | OPTIONAL. | | | | 3744 +----------+-----------------------------+--------+--------+--------+ 3745 | RR | Revoking a Certificate, | SHOULD | SHOULD | SHOULD | 3746 | | Section 4.2 | | 2) | | 3747 +----------+-----------------------------+--------+--------+--------+ 3748 | CACerts | Get CA Certificates, | MAY | MAY | MAY | 3749 | | Section 4.3.1 | | | | 3750 +----------+-----------------------------+--------+--------+--------+ 3751 | RootUpd | Get Root CA Certificate | MAY | MAY | MAY | 3752 | | Update, Section 4.3.2 | | | | 3753 +----------+-----------------------------+--------+--------+--------+ 3754 | ReqTempl | Get Certificate Request | MAY | MAY | MAY | 3755 | | Template, Section 4.3.3 | | | | 3756 +----------+-----------------------------+--------+--------+--------+ 3757 | CRLUpd | CRL Update Retrieval, | MAY | MAY | MAY | 3758 | | Section 4.3.4 | | | | 3759 +----------+-----------------------------+--------+--------+--------+ 3760 | Polling | Handling Delayed | MAY | MAY | MAY | 3761 | | Delivery, Section 4.4 | | | | 3762 +----------+-----------------------------+--------+--------+--------+ 3763 | CertResp | Responding to a | N/A | MAY | MUST | 3764 | | Certificate Request (IR, | | | | 3765 | | CR, KUR, and P10CR if | | | | 3766 | | supported), Section 5.1.1 | | | | 3767 +----------+-----------------------------+--------+--------+--------+ 3768 | CertConf | Responding to a | N/A | MAY | MUST | 3769 | | Confirmation Message, | | | | 3770 | | Section 5.1.2 | | | | 3771 +----------+-----------------------------+--------+--------+--------+ 3772 | RevResp | Responding to a | N/A | MAY | SHOULD | 3773 | | Revocation Request, | | | | 3774 | | Section 5.1.3 | | | | 3775 +----------+-----------------------------+--------+--------+--------+ 3776 | GenResp | Responding to a Support | N/A | MAY | MAY | 3777 | | Message (CACerts, | | | | 3778 | | RootUpd, ReqTempl, CRLUpd | | | | 3779 | | if supported), | | | | 3780 | | Section 5.1.4 | | | | 3781 +----------+-----------------------------+--------+--------+--------+ 3782 | InitPoll | Initiating Delayed | N/A | MAY | MAY | 3783 | | Delivery, Section 5.1.5 | | | | 3784 +----------+-----------------------------+--------+--------+--------+ 3785 | FwdKeep | Forwarding Messages - Not | N/A | MUST | N/A | 3786 | | Changing Protection, | | | | 3787 | | Section 5.2.1 | | | | 3788 +----------+-----------------------------+--------+--------+--------+ 3789 | FwdAddS | Forwarding Messages - | N/A | MUST | MUST | 3790 | | Adding Protection to a | | | | 3791 | | Request Message, | | | | 3792 | | Section 5.2.2.1 | | | | 3793 +----------+-----------------------------+--------+--------+--------+ 3794 | FwdAddB | Forwarding Messages - | N/A | MAY | MAY | 3795 | | Batching Messages, | | | | 3796 | | Section 5.2.2.2 | | | | 3797 +----------+-----------------------------+--------+--------+--------+ 3798 | FwdRepKP | Forwarding Messages - Not | N/A | SHOULD | N/A | 3799 | | Changing | | 1) | | 3800 | | Proof-of-Possession, | | | | 3801 | | Section 5.2.3.1 | | | | 3802 +----------+-----------------------------+--------+--------+--------+ 3803 | FwdRepBP | Forwarding Messages - | N/A | MAY | MAY | 3804 | | Using raVerified, | | | | 3805 | | Section 5.2.3.2 | | | | 3806 +----------+-----------------------------+--------+--------+--------+ 3807 | CertOnB | Acting on Behalf of other | N/A | MAY | N/A | 3808 | | PKI Entities - Requesting | | | | 3809 | | a Certificate, | | | | 3810 | | Section 5.3.1 | | | | 3811 +----------+-----------------------------+--------+--------+--------+ 3812 | RevROnB | Acting on Behalf of other | N/A | SHOULD | SHOULD | 3813 | | PKI Entities - Revoking a | | 2) | | 3814 | | Certificate, | | | | 3815 | | Section 5.3.2 | | | | 3816 +----------+-----------------------------+--------+--------+--------+ 3818 Table 3: Level of Support for PKI Management Operations and Variants 3820 1) The RA should be able to change the CMP message protection from 3821 MAC-based to signature-based protection, see Section 5.2.3.1. 3823 2) The RA should be able to request certificate revocation on behalf 3824 of an EE, see Section 5.3.2. 3826 7.2. Message Transfer 3828 CMP does not have specific needs regarding message transfer, except 3829 that for each request message sent, eventually exactly one response 3830 message should be received. Therefore, virtually any reliable 3831 transfer mechanism can be used, such as HTTP, CoAP, and file-based 3832 offline transfer. Thus, this document does not require any specific 3833 transfer protocol to be supported by conforming implementations. 3835 On different links between PKI entities, e.g., EE-RA and RA-CA, 3836 different transfer mechanisms as specified in Section 6 may be used. 3838 HTTP transfer is RECOMMENDED to use for all PKI entities for 3839 maximizing general interoperability at transfer level, yet full 3840 flexibility is retained to choose whatever transfer mechanism is 3841 suitable, for instance for devices and system architectures with 3842 specific constraints. 3844 The following table lists the name and level of support specified for 3845 each transfer mechanism. 3847 +=========+=======================+========+========+========+ 3848 | ID | Message Transfer Type | EE | RA | CA | 3849 +=========+=======================+========+========+========+ 3850 | HTTP | HTTP Transfer, | SHOULD | SHOULD | SHOULD | 3851 | | Section 6.1 | | | | 3852 +---------+-----------------------+--------+--------+--------+ 3853 | CoAP | CoAP Transfer, | MAY | MAY | MAY | 3854 | | Section 6.2 | | | | 3855 +---------+-----------------------+--------+--------+--------+ 3856 | Piggyb | Piggybacking on other | MAY | MAY | MAY | 3857 | | Reliable Transfer, | | | | 3858 | | Section 6.3 | | | | 3859 +---------+-----------------------+--------+--------+--------+ 3860 | Offline | Offline Transfer, | MAY | MAY | MAY | 3861 | | Section 6.4 | | | | 3862 +---------+-----------------------+--------+--------+--------+ 3864 Table 4: Level of Support for Message Transfer Types 3866 8. IANA Considerations 3868 This document defines new entries with the following content in the 3869 "CMP Well-Known URI Path Segments" registry (see 3870 https://www.iana.org/assignments/cmp/) as defined in RFC 8615 3871 [RFC8615]. 3873 +====================+===============================+===========+ 3874 | Path Segment | Description | Reference | 3875 +====================+===============================+===========+ 3876 | initialization | Enrolling an End Entity to a | [thisRFC] | 3877 | | New PKI over HTTP | | 3878 +--------------------+-------------------------------+-----------+ 3879 | certification | Enrolling an End Entity to a | [thisRFC] | 3880 | | Known PKI over HTTP | | 3881 +--------------------+-------------------------------+-----------+ 3882 | keyupdate | Updating a Valid Certificate | [thisRFC] | 3883 | | over HTTP | | 3884 +--------------------+-------------------------------+-----------+ 3885 | pkcs10 | Enrolling an End Entity Using | [thisRFC] | 3886 | | a PKCS#10 Request over HTTP | | 3887 +--------------------+-------------------------------+-----------+ 3888 | revocation | Revoking a Certificate over | [thisRFC] | 3889 | | HTTP | | 3890 +--------------------+-------------------------------+-----------+ 3891 | getcacerts | Get CA Certificates over HTTP | [thisRFC] | 3892 +--------------------+-------------------------------+-----------+ 3893 | getrootupdate | Get Root CA Certificate | [thisRFC] | 3894 | | Update over HTTP | | 3895 +--------------------+-------------------------------+-----------+ 3896 | getcertreqtemplate | Get CA Certificates over HTTP | [thisRFC] | 3897 +--------------------+-------------------------------+-----------+ 3898 | getcrls | CRL Update Retrieval over | [thisRFC] | 3899 | | HTTP | | 3900 +--------------------+-------------------------------+-----------+ 3901 | nested | Batching Messages over HTTP | [thisRFC] | 3902 +--------------------+-------------------------------+-----------+ 3903 | ir | Enrolling an End Entity to a | [thisRFC] | 3904 | | New PKI over CoAP | | 3905 +--------------------+-------------------------------+-----------+ 3906 | cr | Enrolling an End Entity to a | [thisRFC] | 3907 | | Known PKI over CoAP | | 3908 +--------------------+-------------------------------+-----------+ 3909 | kur | Updating a Valid Certificate | [thisRFC] | 3910 | | over CoAP | | 3911 +--------------------+-------------------------------+-----------+ 3912 | p10 | Enrolling an End Entity Using | [thisRFC] | 3913 | | a PKCS#10 Request over CoAP | | 3914 +--------------------+-------------------------------+-----------+ 3915 | rr | Revoking a Certificate over | [thisRFC] | 3916 | | CoAP | | 3917 +--------------------+-------------------------------+-----------+ 3918 | crts | Get CA Certificates over CoAP | [thisRFC] | 3919 +--------------------+-------------------------------+-----------+ 3920 | rcu | Get Root CA Certificate | [thisRFC] | 3921 | | Update over CoAP | | 3922 +--------------------+-------------------------------+-----------+ 3923 | att | Get Certificate Request | [thisRFC] | 3924 | | Template over CoAP | | 3925 +--------------------+-------------------------------+-----------+ 3926 | crls | CRL Update Retrieval over | [thisRFC] | 3927 | | CoAP | | 3928 +--------------------+-------------------------------+-----------+ 3929 | nest | Batching Messages over CoAP | [thisRFC] | 3930 +--------------------+-------------------------------+-----------+ 3932 Table 5: New "CMP Well-Known URI Path Segments" Registry Entries 3934 < TBD: New entries must be added to the registry "CMP Well-Known URI 3935 Path Segments". > 3937 9. Security Considerations 3939 The security considerations as laid out in CMP [RFC4210] updated by 3940 CMP Updates [I-D.ietf-lamps-cmp-updates] and CMP Algorithms 3941 [I-D.ietf-lamps-cmp-algorithms], CRMF [RFC4211] updated by Algorithm 3942 Requirements Update [RFC9045], CMP over HTTP [RFC6712], and CMP over 3943 CoAP [I-D.ietf-ace-cmpv2-coap-transport] apply. 3945 For TLS using shared secret information-based authentication, both 3946 PSK and PAKE provide the same amount of protection against a real- 3947 time authentication attack which is directly the amount of entropy in 3948 the shared secret. The difference between a pre-shared key (PSK) and 3949 a password-authenticated key exchange (PAKE) protocol is in the level 3950 of long-term confidentiality of the TLS messages against brute-force 3951 decryption, where a PSK-based cipher suite only provides security 3952 according to the entropy of the shared secret, while a PAKE-based 3953 cipher suite provides full security independent of the entropy of the 3954 shared secret. 3956 10. Acknowledgements 3958 We thank the various reviewers of this document. 3960 11. References 3962 11.1. Normative References 3964 [I-D.ietf-ace-cmpv2-coap-transport] 3965 Sahni, M. and S. Tripathi, "CoAP Transfer for the 3966 Certificate Management Protocol", Work in Progress, 3967 Internet-Draft, draft-ietf-ace-cmpv2-coap-transport-04, 8 3968 November 2021, . 3971 [I-D.ietf-lamps-cmp-algorithms] 3972 Brockhaus, H., Aschauer, H., Ounsworth, M., and J. Gray, 3973 "Certificate Management Protocol (CMP) Algorithms", Work 3974 in Progress, Internet-Draft, draft-ietf-lamps-cmp- 3975 algorithms-12, 6 April 2022, 3976 . 3979 [I-D.ietf-lamps-cmp-updates] 3980 Brockhaus, H., Oheimb, D. V., and J. Gray, "Certificate 3981 Management Protocol (CMP) Updates", Work in Progress, 3982 Internet-Draft, draft-ietf-lamps-cmp-updates-18, 6 April 3983 2022, . 3986 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 3987 Requirement Levels", BCP 14, RFC 2119, 3988 DOI 10.17487/RFC2119, March 1997, 3989 . 3991 [RFC2986] Nystrom, M. and B. Kaliski, "PKCS #10: Certification 3992 Request Syntax Specification Version 1.7", RFC 2986, 3993 DOI 10.17487/RFC2986, November 2000, 3994 . 3996 [RFC4210] Adams, C., Farrell, S., Kause, T., and T. Mononen, 3997 "Internet X.509 Public Key Infrastructure Certificate 3998 Management Protocol (CMP)", RFC 4210, 3999 DOI 10.17487/RFC4210, September 2005, 4000 . 4002 [RFC4211] Schaad, J., "Internet X.509 Public Key Infrastructure 4003 Certificate Request Message Format (CRMF)", RFC 4211, 4004 DOI 10.17487/RFC4211, September 2005, 4005 . 4007 [RFC5280] Cooper, D., Santesson, S., Farrell, S., Boeyen, S., 4008 Housley, R., and W. Polk, "Internet X.509 Public Key 4009 Infrastructure Certificate and Certificate Revocation List 4010 (CRL) Profile", RFC 5280, DOI 10.17487/RFC5280, May 2008, 4011 . 4013 [RFC5652] Housley, R., "Cryptographic Message Syntax (CMS)", STD 70, 4014 RFC 5652, DOI 10.17487/RFC5652, September 2009, 4015 . 4017 [RFC5958] Turner, S., "Asymmetric Key Packages", RFC 5958, 4018 DOI 10.17487/RFC5958, August 2010, 4019 . 4021 [RFC6712] Kause, T. and M. Peylo, "Internet X.509 Public Key 4022 Infrastructure -- HTTP Transfer for the Certificate 4023 Management Protocol (CMP)", RFC 6712, 4024 DOI 10.17487/RFC6712, September 2012, 4025 . 4027 [RFC8174] Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC 4028 2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174, 4029 May 2017, . 4031 [RFC8615] Nottingham, M., "Well-Known Uniform Resource Identifiers 4032 (URIs)", RFC 8615, DOI 10.17487/RFC8615, May 2019, 4033 . 4035 [RFC8933] Housley, R., "Update to the Cryptographic Message Syntax 4036 (CMS) for Algorithm Identifier Protection", RFC 8933, 4037 DOI 10.17487/RFC8933, October 2020, 4038 . 4040 [RFC9045] Housley, R., "Algorithm Requirements Update to the 4041 Internet X.509 Public Key Infrastructure Certificate 4042 Request Message Format (CRMF)", RFC 9045, 4043 DOI 10.17487/RFC9045, June 2021, 4044 . 4046 11.2. Informative References 4048 [ETSI-3GPP.33.310] 4049 3GPP, "Network Domain Security (NDS); Authentication 4050 Framework (AF)", 3GPP TS 33.310 16.6.0, 16 December 2020. 4052 [I-D.ietf-anima-brski-ae] 4053 Oheimb, D. V., Fries, S., Brockhaus, H., and E. Lear, 4054 "BRSKI-AE: Alternative Enrollment Protocols in BRSKI", 4055 Work in Progress, Internet-Draft, draft-ietf-anima-brski- 4056 ae-01, 6 April 2022, 4057 . 4060 [I-D.ietf-anima-brski-prm] 4061 Fries, S., Werner, T., Lear, E., and M. C. Richardson, 4062 "BRSKI with Pledge in Responder Mode (BRSKI-PRM)", Work in 4063 Progress, Internet-Draft, draft-ietf-anima-brski-prm-02, 4 4064 March 2022, . 4067 [I-D.ietf-netconf-sztp-csr] 4068 Watsen, K., Housley, R., and S. Turner, "Conveying a 4069 Certificate Signing Request (CSR) in a Secure Zero Touch 4070 Provisioning (SZTP) Bootstrapping Request", Work in 4071 Progress, Internet-Draft, draft-ietf-netconf-sztp-csr-14, 4072 2 March 2022, . 4075 [IEC.62443-3-3] 4076 IEC, "Industrial communication networks - Network and 4077 system security - Part 3-3: System security requirements 4078 and security levels", IEC 62443-3-3, August 2013, 4079 . 4081 [IEEE.802.1AR_2018] 4082 IEEE, "IEEE Standard for Local and metropolitan area 4083 networks - Secure Device Identity", IEEE 802.1AR-2018, 4084 DOI 10.1109/IEEESTD.2018.8423794, 2 August 2018, 4085 . 4087 [NIST.CSWP.04162018] 4088 National Institute of Standards and Technology (NIST), 4089 "Framework for Improving Critical Infrastructure 4090 Cybersecurity, Version 1.1", NIST NIST.CSWP.04162018, 4091 DOI 10.6028/NIST.CSWP.04162018, April 2018, 4092 . 4095 [NIST.SP.800-57p1r5] 4096 Barker, E B., "Recommendation for key management, part 1 4097 :general", NIST NIST.SP.800-57pt1r5, 4098 DOI 10.6028/NIST.SP.800-57pt1r5, 2020, 4099 . 4101 [RFC2510] Adams, C. and S. Farrell, "Internet X.509 Public Key 4102 Infrastructure Certificate Management Protocols", 4103 RFC 2510, DOI 10.17487/RFC2510, March 1999, 4104 . 4106 [RFC2818] Rescorla, E., "HTTP Over TLS", RFC 2818, 4107 DOI 10.17487/RFC2818, May 2000, 4108 . 4110 [RFC3647] Chokhani, S., Ford, W., Sabett, R., Merrill, C., and S. 4111 Wu, "Internet X.509 Public Key Infrastructure Certificate 4112 Policy and Certification Practices Framework", RFC 3647, 4113 DOI 10.17487/RFC3647, November 2003, 4114 . 4116 [RFC5246] Dierks, T. and E. Rescorla, "The Transport Layer Security 4117 (TLS) Protocol Version 1.2", RFC 5246, 4118 DOI 10.17487/RFC5246, August 2008, 4119 . 4121 [RFC7030] Pritikin, M., Ed., Yee, P., Ed., and D. Harkins, Ed., 4122 "Enrollment over Secure Transport", RFC 7030, 4123 DOI 10.17487/RFC7030, October 2013, 4124 . 4126 [RFC7252] Shelby, Z., Hartke, K., and C. Bormann, "The Constrained 4127 Application Protocol (CoAP)", RFC 7252, 4128 DOI 10.17487/RFC7252, June 2014, 4129 . 4131 [RFC8366] Watsen, K., Richardson, M., Pritikin, M., and T. Eckert, 4132 "A Voucher Artifact for Bootstrapping Protocols", 4133 RFC 8366, DOI 10.17487/RFC8366, May 2018, 4134 . 4136 [RFC8446] Rescorla, E., "The Transport Layer Security (TLS) Protocol 4137 Version 1.3", RFC 8446, DOI 10.17487/RFC8446, August 2018, 4138 . 4140 [RFC8551] Schaad, J., Ramsdell, B., and S. Turner, "Secure/ 4141 Multipurpose Internet Mail Extensions (S/MIME) Version 4.0 4142 Message Specification", RFC 8551, DOI 10.17487/RFC8551, 4143 April 2019, . 4145 [RFC8572] Watsen, K., Farrer, I., and M. Abrahamsson, "Secure Zero 4146 Touch Provisioning (SZTP)", RFC 8572, 4147 DOI 10.17487/RFC8572, April 2019, 4148 . 4150 [RFC8995] Pritikin, M., Richardson, M., Eckert, T., Behringer, M., 4151 and K. Watsen, "Bootstrapping Remote Secure Key 4152 Infrastructure (BRSKI)", RFC 8995, DOI 10.17487/RFC8995, 4153 May 2021, . 4155 [UNISIG.Subset-137] 4156 UNISIG, "Subset-137; ERTMS/ETCS On-line Key Management 4157 FFFIS; V1.0.0", December 2015, 4158 . 4160 Appendix A. Example CertReqTemplate 4162 Suppose the server requires that the certTemplate contains 4164 * the issuer field with a value to be filled in by the EE, 4166 * the subject field with a common name to be filled in by the EE and 4167 two organizational unit fields with given values "myDept" and 4168 "myGroup", 4170 * the publicKey field contains an ECC key on curve secp256r1 or an 4171 RSA public key of length 2048, 4173 * the subjectAltName extension with DNS name "www.myServer.com" and 4174 an IP address to be filled in, 4176 * the keyUsage extension marked critical with the value 4177 digitalSignature and keyAgreement, and 4179 * the extKeyUsage extension with values to be filled in by the EE. 4181 Then the infoValue with certTemplate and keySpec fields returned to 4182 the EE will be encoded as follows: 4184 SEQUENCE { 4185 SEQUENCE { 4186 [3] { 4187 SEQUENCE {} 4188 } 4189 [5] { 4190 SEQUENCE { 4191 SET { 4192 SEQUENCE { 4193 OBJECT IDENTIFIER commonName (2 5 4 3) 4194 UTF8String "" 4195 } 4196 } 4197 SET { 4198 SEQUENCE { 4199 OBJECT IDENTIFIER organizationalUnitName (2 5 4 11) 4200 UTF8String "myDept" 4201 } 4202 } 4203 SET { 4204 SEQUENCE { 4205 OBJECT IDENTIFIER organizationalUnitName (2 5 4 11) 4206 UTF8String "myGroup" 4207 } 4208 } 4209 } 4210 } 4211 [9] { 4212 SEQUENCE { 4213 OBJECT IDENTIFIER subjectAltName (2 5 29 17) 4214 OCTET STRING, encapsulates { 4215 SEQUENCE { 4216 [2] "www.myServer.com" 4217 [7] "" 4218 } 4219 } 4221 } 4222 SEQUENCE { 4223 OBJECT IDENTIFIER keyUsage (2 5 29 15) 4224 BOOLEAN TRUE 4225 OCTET STRING, encapsulates { 4226 BIT STRING 3 unused bits 4227 "10001"B 4228 } 4229 } 4230 SEQUENCE { 4231 OBJECT IDENTIFIER extKeyUsage (2 5 29 37) 4232 OCTET STRING, encapsulates { 4233 SEQUENCE {} 4234 } 4235 } 4236 } 4237 } 4238 SEQUENCE { 4239 SEQUENCE { 4240 OBJECT IDENTIFIER algId (1 3 6 1 5 5 7 5 1 11) 4241 SEQUENCE { 4242 OBJECT IDENTIFIER ecPublicKey (1 2 840 10045 2 1) 4243 OBJECT IDENTIFIER secp256r1 (1 2 840 10045 3 1 7) 4244 } 4245 } 4246 SEQUENCE { 4247 OBJECT IDENTIFIER rsaKeyLen (1 3 6 1 5 5 7 5 1 12) 4248 INTEGER 2048 4249 } 4250 } 4251 } 4253 Appendix B. History of Changes 4255 Note: This appendix will be deleted in the final version of the 4256 document. 4258 From version 10 -> 11: 4260 * Updated Section 3.2, 3.5, and 3.6.4 to define more clearly 4261 signature-based protection as the default and the exception for 4262 not protecting error messages as mentioned at IETF 113 4263 * Streamlined headlines in Section 4.1 4264 * Updates Section 6.1 and Section 6.2 regarding new well-known path 4265 segment for profile labels as discussed during IETF 113 4266 * Updated Section 7.1. on the support of PKI management operations 4267 required for EEs, RAs, and CAs as mentioned at IETF 113 4269 * Updates Section 8 adding well-known path segments on PKI 4270 management operations to be used with HTTP and CoAP 4271 * Capitalized all headlines 4273 From version 09 -> 10: 4275 * Resolved some nits reported by I-D nit checker tool 4276 * Resolve some wording issues 4278 From version 08 -> 09: 4280 * Updated Section 1.1 and 1.2 and converted Section 2.2 and 2.3 into 4281 more detailed tables in Section 7 (see thread "WG Last Call for 4282 draft-ietf-lamps-cmp-updates-14 and draft-ietf-lamps-lightweight- 4283 cmp-profile-08") 4284 * Updated Section 3.1 and 4.1.1 making implicitConfirm recommended 4285 for ir/cr/p10cr/kur and providing further recommendations on its 4286 use (see thread "certConf - WG Last Call for draft-ietf-lamps-cmp- 4287 updates-14 and draft-ietf-lamps-lightweight-cmp-profile-08") 4288 * Updated Section 4.1.6 adding some clarifications regarding 4289 validating the authorization of centrally generated keys 4290 * Updated Section 4.3.4 adding some clarifications on CRL update 4291 retrieval (see thread "CRL update retrieval - WG Last Call for 4292 draft-ietf-lamps-cmp-updates-14 and draft-ietf-lamps-lightweight- 4293 cmp-profile-08") 4294 * Updated references to CMP Updates pointing to concrete sections 4295 (see thread "CRL update retrieval - WG Last Call for draft-ietf- 4296 lamps-cmp-updates-14 and draft-ietf-lamps-lightweight-cmp-profile- 4297 08")) 4298 * Corrected a couple of nits elsewhere 4300 From version 07 -> 08: 4302 * Updates Section 4.1.6.1. regarding content of the originator and 4303 keyEncryptionAlgorithm fields (see thread "AD review of draft- 4304 ietf-lamps-cmp-algorithms-07") 4305 * Rolled back part of the changes on root CA certificate updates in 4306 Section 4.3.2 (see thread "Allocation of OIDs for CRL update 4307 retrieval (draft-ietf-lamps-cmp-updates-13)") 4309 From version 06 -> 07: 4311 * Added references to [draft-ietf-netconf-sztp-csr] in new 4312 Section 1.5 and Section 4.1.4 4313 * Added reference to [I-D.ietf-anima-brski-ae] in new Section 1.5 4314 and Section 4.1.1 4316 * Changed reference in Section 2 to [I-D.ietf-anima-brski-prm] as 4317 the PUSH use case is continued to be discussed in this draft after 4318 the split of BRSKI-AE 4319 * Improved note regarding UNISIG Subset-137 in Section 1.6 4320 * Removed "rootCaCert" in Section 3.1 and updated the structure of 4321 the genm request for root CA certificate updates in Section 4.3.2. 4322 * Simplified handling of sender and recipient nonces in case of 4323 delayed delivery in Sections 3.1, 3.5, 4.4, and 5.1.2 4324 * Changed the order of Sections 4.1.4 and 4.1.5 4325 * Added reference on RFC 8933 regarding CMS signedAttrs to 4326 Section 4.1.6 4327 * Added Section 4.3.4 on CRL update retrieval 4328 * Generalized delayed enrollment to delayed delivery in Section 4.4 4329 and 5.1.2, updated the state machine in the introduction of 4330 Section 4 4331 * Updated Section 6 regarding delayed message transfer 4332 * Changed file name extension from ".PKI" to ".pki", deleted 4333 operational path for central key generation, and added an 4334 operational path for CRL update retrieval in Sections 6.1 and 6.2 4335 * Shifted many security considerations to CMP Updates 4336 * Replaced the term "transport" by "transfer" where appropriate to 4337 prevent confusion regarding TCP vs. HTTP and CoAP 4338 * Various editorial changes and language corrections 4340 From version 05 -> 06: 4342 * Changed in Section 2.3 the normative requirement in of adding 4343 protection to a single message to mandatory and replacing 4344 protection to optional 4345 * Added Section 3.4 specifying generic prerequisites to PKI 4346 management operations 4347 * Added Section 3.5 specifying generic message validation 4348 * Added Section 3.6 on generic error reporting. This section 4349 replaces the former error handling section from Section 4 and 5. 4350 * Added reference to using hashAlg 4351 * Updates Section 4.3.2 and Section 4.3.3 to align with CMP Updates 4352 * Added Section 5.1 specifying the behavior of PKI management 4353 entities when responding to requests 4354 * Reworked Section 5.2.3. on usage of nested messages 4355 * Updates Section 5.3 on performing PKI management operation on 4356 behalf of another entity 4357 * Updates Section 6.2 on HTTPS transport of CMP messages as 4358 discusses at IETF 110 and email thread "I-D Action: draft-ietf- 4359 lamps-lightweight-cmp-profile-05.txt" 4360 * Added CoAP endpoints to Section 6.4 4361 * Added security considerations on usage of shared secret 4362 information 4363 * Updated the example in Appendix A 4364 * Added newly registered OIDs to the example in Appendix A 4365 * Updated new RFC numbers for I-D.ietf-lamps-crmf-update-algs 4366 * Multiple language corrections, clarifications, and changes in 4367 wording 4369 From version 04 -> 05: 4371 * Changed to XML V3 4372 * Added algorithm names introduced in CMP Algorithms Section 7.3 to 4373 Section 4 of this document 4374 * Updates Syntax in Section 4.4.3 due to changes made in CMP Updates 4375 * Deleted the text on HTTP-based discovery as discussed in 4376 Section 6.1 4377 * Updates Appendix A due to change syntax in Section 4.4.3 4378 * Many clarifications and changes in wording thanks to David's 4379 extensive review 4381 From version 03 -> 04: 4383 * Deleted normative text sections on algorithms and refer to CMP 4384 Algorithms and CRMF Algorithm Requirements Update instead 4385 * Some clarifications and changes in wording 4387 From version 02 -> 03: 4389 * Updated the interoperability with [UNISIG.Subset-137] in 4390 Section 1.4. 4391 * Changed Section 2.3 to a tabular layout to enhanced readability 4392 * Added a ToDo to section 3.1 on aligning with the CMP Algorithms 4393 draft that will be set up as decided in IETF 108 4394 * Updated section 4.1.6 to add the AsymmetricKey Package structure 4395 to transport a newly generated private key as decided in IETF 108 4396 * Added a ToDo to section 4.1.7 on required review of the nonce 4397 handling in case an offline LRA responds and not forwards the 4398 pollReq messages 4399 * Updated Section 4 due to the definition of the new ITAV OIDs in 4400 CMP Updates 4401 * Updated Section 4.4.4 to utilize controls instead of rsaKeyLen 4402 (see thread "dtaft-ietf-lamps-cmp-updates and rsaKeyLen") 4403 * Deleted the section on definition and discovery of HTTP URIs and 4404 copied the text to the HTTP transport section and to CMP Updates 4405 section 3.2 4406 * Added some explanation to Section 5.1.2 and Section 5.1.3 on using 4407 nested messages when a protection by the RA is required. 4408 * Deleted the section on HTTP URI definition and discovery as some 4409 content was moved to CMP Updates. The rest of the content was 4410 moved back to the HTTP transport section 4412 * Deleted the ASN.1 module after moving the new OIDs id-it-caCerts, 4413 id-it-rootCaKeyUpdate, and id-it-certReqTemplate to CMP Updates 4414 * Minor changes in wording and addition of some open ToDos 4416 From version 01 -> 02: 4418 * Extend Section 1.6 with regard to conflicts with UNISIG Subset- 4419 137. 4420 * Minor clarifications on extraCerts in Section 3.3 and 4421 Section 4.1.1. 4422 * Complete specification of requesting a certificate from a trusted 4423 PKI with signature protection in Section 4.1.2. 4424 * Changed from symmetric key-encryption to password-based key 4425 management technique in Section 4.1.6.3 as discussed on the 4426 mailing list (see thread "draft-ietf-lamps-lightweight-cmp- 4427 profile-01, section 5.1.6.1") 4428 * Changed delayed enrollment described in Section 4.4 from 4429 recommended to optional as decided at IETF 107 4430 * Introduced the new RootCAKeyUpdate structure for root CA 4431 certificate update in Section 4.3.2 as decided at IETF 107 (also 4432 see email thread "draft-ietf-lamps-lightweight-cmp-profile-01, 4433 section 5.4.3") 4434 * Extend the description of the CertReqTemplate PKI management 4435 operation, including an example added in the Appendix. Keep 4436 rsaKeyLen as a single integer value in Section 4.3.3 as discussed 4437 on the mailing list (see thread "draft-ietf-lamps-lightweight-cmp- 4438 profile-01, section 5.4.4") 4439 * Deleted Sections "Get certificate management configuration" and 4440 "Get enrollment voucher" as decided at IETF 107 4441 * Complete specification of adding an additional protection by an 4442 PKI management entity in Section 5.2.2. 4443 * Added a section on HTTP URI definition and discovery and extended 4444 Section 6.1 on definition and discovery of supported HTTP URIs and 4445 content types, add a path for nested messages as specified in 4446 Section 5.2.2 and delete the paths for /getCertMgtConfig and 4447 /getVoucher 4448 * Changed Section 6.4 to address offline transport and added more 4449 detailed specification file-based transport of CMP 4450 * Added a reference to the new I-D of Mohit Sahni on "CoAP Transport 4451 for CMPV2" in Section 6.2; thanks to Mohit supporting the effort 4452 to ease utilization of CMP 4453 * Moved the change history to the Appendix 4454 * Minor changes in wording 4456 From version 00 -> 01: 4458 * Harmonize terminology with CMP [RFC4210], e.g., 4459 - transaction, message sequence, exchange, use case -> PKI 4460 management operation 4461 - PKI component, (L)RA/CA -> PKI management entity 4462 * Minor changes in wording 4464 From draft-brockhaus-lamps-lightweight-cmp-profile-03 -> draft-ietf- 4465 lamps-lightweight-cmp-profile-00: 4467 * Changes required to reflect WG adoption 4468 * Minor changes in wording 4470 From version 02 -> 03: 4472 * Added a short summary of [RFC4210] Appendix D and E in 4473 Section 1.4. 4474 * Clarified some references to different sections and added some 4475 clarification in response to feedback from Michael Richardson and 4476 Tomas Gustavsson. 4477 * Added an additional label to the operational path to address 4478 multiple CAs or certificate profiles in Section 6.1. 4480 From version 01 -> 02: 4482 * Added some clarification on the key management techniques for 4483 protection of centrally generated keys in Section 4.1.6. 4484 * Added some clarifications on the certificates for root CA 4485 certificate update in Section 4.3.2. 4486 * Added a section to specify the usage of nested messages for RAs to 4487 add an additional protection for further discussion, see 4488 Section 5.2.2. 4489 * Added a table containing endpoints for HTTP transport in 4490 Section 6.1 to simplify addressing PKI management entities. 4491 * Added some ToDos resulting from discussion with Tomas Gustavsson. 4492 * Minor clarifications and changes in wording. 4494 From version 00 -> 01: 4496 * Added a section to specify the enrollment with an already trusted 4497 PKI for further discussion, see Section 4.1.2. 4498 * Complete specification of requesting a certificate from a legacy 4499 PKI using a PKCS#10 [RFC2986] request in Section 4.1.4. 4500 * Complete specification of adding central generation of a key pair 4501 on behalf of an end entity in Section 4.1.6. 4502 * Complete specification of handling delayed enrollment due to 4503 asynchronous message delivery in Section 4.4. 4504 * Complete specification of additional support messages, e.g., to 4505 update a Root CA certificate or to request an RFC 8366 [RFC8366] 4506 voucher, in Section 4.3. 4508 * Minor changes in wording. 4510 From draft-brockhaus-lamps-industrial-cmp-profile-00 -> draft- 4511 brockhaus-lamps-lightweight-cmp-profile-00: 4513 * Change focus from industrial to more multi-purpose use cases and 4514 lightweight CMP profile. 4515 * Incorporate the omitted confirmation into the header specified in 4516 Section 3.1 and described in the standard enrollment use case in 4517 Section 4.1.1 due to discussion with Tomas Gustavsson. 4518 * Change from OPTIONAL to RECOMMENDED for use case 'Revoke another's 4519 entities certificate' in Section 5.3.2, because it is regarded as 4520 important functionality in many environments to enable the 4521 management station to revoke EE certificates. 4522 * Complete the specification of the revocation message flow in 4523 Section 4.2 and Section 5.3.2. 4524 * The CoAP based transport mechanism and piggybacking of CMP 4525 messages on top of other reliable transport protocols is out of 4526 scope of this document and would need to be specified in another 4527 document. 4528 * Further minor changes in wording. 4530 Authors' Addresses 4532 Hendrik Brockhaus (editor) 4533 Siemens AG 4534 Email: hendrik.brockhaus@siemens.com 4536 David von Oheimb 4537 Siemens AG 4538 Email: david.von.oheimb@siemens.com 4540 Steffen Fries 4541 Siemens AG 4542 Email: steffen.fries@siemens.com