idnits 2.17.1 draft-ietf-lamps-lightweight-cmp-profile-01.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 : ---------------------------------------------------------------------------- No issues found here. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust and authors Copyright Line does not match the current year == Using lowercase 'not' together with uppercase 'MUST', 'SHALL', 'SHOULD', or 'RECOMMENDED' is not an accepted usage according to RFC 2119. Please use uppercase 'NOT' together with RFC 2119 keywords (if that is what you mean). Found 'SHOULD not' in this paragraph: When in Section 4, Section 5, and Section 6 a field of the ASN.1 syntax as defined in RFC 4210 [RFC4210] and RFC 4211 [RFC4211] is not explicitly specified, it SHOULD not be used by the sending entity. The receiving entity MUST NOT require its absence and if present MUST gracefully handle its presence. == Using lowercase 'not' together with uppercase 'MUST', 'SHALL', 'SHOULD', or 'RECOMMENDED' is not an accepted usage according to RFC 2119. Please use uppercase 'NOT' together with RFC 2119 keywords (if that is what you mean). Found 'SHOULD not' in this paragraph: 4 The extraCerts of the ip message MUST contain the chain of the issued certificate and root certificates SHOULD not be included and MUST NOT be directly trusted in any case. == Using lowercase 'not' together with uppercase 'MUST', 'SHALL', 'SHOULD', or 'RECOMMENDED' is not an accepted usage according to RFC 2119. Please use uppercase 'NOT' together with RFC 2119 keywords (if that is what you mean). Found 'SHOULD not' in this paragraph: The PKI management entity SHOULD verify the protection, the syntax, the required message fields, the message type, and if applicable the authorization and the proof-of-possession of the message. Additional checks or actions MAY be applied depending on the PKI solution requirements and concept. If one of these verification procedures fails, the (L)RA SHOULD respond with a negative response message and SHOULD not forward the message further upstream. General error conditions should be handled as described in Section 5.3 and Section 6.3. == Using lowercase 'not' together with uppercase 'MUST', 'SHALL', 'SHOULD', or 'RECOMMENDED' is not an accepted usage according to RFC 2119. Please use uppercase 'NOT' together with RFC 2119 keywords (if that is what you mean). Found 'SHOULD not' in this paragraph: A PKI management entity SHOULD not change the received message if not necessary. The PKI management entity SHOULD only update the message protection if it is technically necessary. Concrete PKI system specifications may define in more detail if and when to do so. -- The document date (March 4, 2020) is 1512 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) == Outdated reference: A later version (-23) exists of draft-ietf-lamps-cmp-updates-00 ** Downref: Normative reference to an Informational RFC: RFC 2986 ** Obsolete normative reference: RFC 5785 (Obsoleted by RFC 8615) == Outdated reference: A later version (-45) exists of draft-ietf-anima-bootstrapping-keyinfra-35 -- 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: 2 errors (**), 0 flaws (~~), 7 warnings (==), 3 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 LAMPS Working Group H. Brockhaus 3 Internet-Draft S. Fries 4 Intended status: Standards Track D. von Oheimb 5 Expires: September 5, 2020 Siemens 6 March 4, 2020 8 Lightweight CMP Profile 9 draft-ietf-lamps-lightweight-cmp-profile-01 11 Abstract 13 The goal of this document is to facilitate interoperability and 14 automation by profiling the Certificate Management Protocol (CMP) 15 version 2, the related Certificate Request Message Format (CRMF) 16 version 2, and the HTTP Transfer for the Certificate Management 17 Protocol. It specifies a subset of CMP and CRMF focusing on typical 18 uses cases relevant for managing certificates of devices in many 19 industrial and IoT scenarios. To limit the overhead of certificate 20 management for more constrained devices only the most crucial types 21 of operations are specified as mandatory. To foster interoperability 22 also in more complex scenarios, other types of operations are 23 specified as recommended or 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 September 5, 2020. 42 Copyright Notice 44 Copyright (c) 2020 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 49 (https://trustee.ietf.org/license-info) in effect on the date of 50 publication of this document. Please review these documents 51 carefully, as they describe your rights and restrictions with respect 52 to this document. Code Components extracted from this document must 53 include Simplified BSD License text as described in Section 4.e of 54 the Trust Legal Provisions and are provided without warranty as 55 described in the Simplified BSD License. 57 Table of Contents 59 1. History of changes . . . . . . . . . . . . . . . . . . . . . 3 60 2. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 5 61 2.1. Motivation for profiling CMP . . . . . . . . . . . . . . 6 62 2.2. Motivation for a lightweight profile for CMP . . . . . . 7 63 2.3. Existing CMP profiles . . . . . . . . . . . . . . . . . . 7 64 2.4. Compatibility with existing CMP profiles . . . . . . . . 9 65 2.5. Scope of this document . . . . . . . . . . . . . . . . . 11 66 2.6. Structure of this document . . . . . . . . . . . . . . . 11 67 2.7. Convention and Terminology . . . . . . . . . . . . . . . 12 68 3. Architecture and use cases . . . . . . . . . . . . . . . . . 13 69 3.1. Solution architecture . . . . . . . . . . . . . . . . . . 13 70 3.2. Basic generic CMP message content . . . . . . . . . . . . 14 71 3.3. Supported PKI management operations . . . . . . . . . . . 14 72 3.3.1. Mandatory PKI management operations . . . . . . . . . 15 73 3.3.2. Recommended PKI management operations . . . . . . . . 15 74 3.3.3. Optional PKI management operations . . . . . . . . . 16 75 3.4. CMP message transport . . . . . . . . . . . . . . . . . . 16 76 4. Generic parts of the PKI message . . . . . . . . . . . . . . 17 77 4.1. General description of the CMP message header . . . . . . 18 78 4.2. General description of the CMP message protection . . . . 19 79 4.3. General description of CMP message extraCerts . . . . . . 20 80 5. End Entity focused PKI management operations . . . . . . . . 20 81 5.1. Requesting a new certificate from a PKI . . . . . . . . . 21 82 5.1.1. Request a certificate from a new PKI with signature 83 protection . . . . . . . . . . . . . . . . . . . . . 22 84 5.1.2. Request a certificate from a trusted PKI with 85 signature protection . . . . . . . . . . . . . . . . 28 86 5.1.3. Update an existing certificate with signature 87 protection . . . . . . . . . . . . . . . . . . . . . 28 88 5.1.4. Request a certificate from a PKI with MAC protection 29 89 5.1.5. Request a certificate from a legacy PKI using PKCS#10 90 request . . . . . . . . . . . . . . . . . . . . . . . 31 91 5.1.6. Generate the key pair centrally at the PKI management 92 entity . . . . . . . . . . . . . . . . . . . . . . . 33 93 5.1.6.1. Using symmetric key-encryption key management 94 technique . . . . . . . . . . . . . . . . . . . . 38 95 5.1.6.2. Using key agreement key management technique . . 39 96 5.1.6.3. Using key transport key management technique . . 40 98 5.1.7. Delayed enrollment . . . . . . . . . . . . . . . . . 41 99 5.2. Revoking a certificate . . . . . . . . . . . . . . . . . 46 100 5.3. Error reporting . . . . . . . . . . . . . . . . . . . . . 48 101 5.4. Support messages . . . . . . . . . . . . . . . . . . . . 50 102 5.4.1. General message and response . . . . . . . . . . . . 51 103 5.4.2. Get CA certificates . . . . . . . . . . . . . . . . . 52 104 5.4.3. Get root CA certificate update . . . . . . . . . . . 53 105 5.4.4. Get certificate request parameters . . . . . . . . . 54 106 5.4.5. Get certificate management configuration . . . . . . 55 107 5.4.6. Get enrollment voucher . . . . . . . . . . . . . . . 57 108 6. LRA and RA focused PKI management operations . . . . . . . . 59 109 6.1. Forwarding of messages . . . . . . . . . . . . . . . . . 59 110 6.1.1. Not changing protection . . . . . . . . . . . . . . . 61 111 6.1.2. Replacing protection . . . . . . . . . . . . . . . . 62 112 6.1.2.1. Keeping proof-of-possession . . . . . . . . . . . 62 113 6.1.2.2. Breaking proof-of-possession . . . . . . . . . . 63 114 6.1.3. Adding Protection . . . . . . . . . . . . . . . . . . 63 115 6.1.4. Initiating delayed enrollment . . . . . . . . . . . . 63 116 6.2. Revoking certificates on behalf of another's entities . . 63 117 6.3. Error reporting . . . . . . . . . . . . . . . . . . . . . 64 118 7. CMP message transport variants . . . . . . . . . . . . . . . 65 119 7.1. HTTP transport . . . . . . . . . . . . . . . . . . . . . 65 120 7.2. HTTPS transport using certificates . . . . . . . . . . . 67 121 7.3. HTTPS transport using shared secrets . . . . . . . . . . 67 122 7.4. File-based transport . . . . . . . . . . . . . . . . . . 68 123 7.5. CoAP transport . . . . . . . . . . . . . . . . . . . . . 68 124 7.6. Piggybacking on other reliable transport . . . . . . . . 68 125 8. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 68 126 9. Security Considerations . . . . . . . . . . . . . . . . . . . 68 127 10. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 69 128 11. References . . . . . . . . . . . . . . . . . . . . . . . . . 69 129 11.1. Normative References . . . . . . . . . . . . . . . . . . 69 130 11.2. Informative References . . . . . . . . . . . . . . . . . 70 131 Appendix A. Additional Stuff . . . . . . . . . . . . . . . . . . 72 132 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 72 134 1. History of changes 136 Note: This section will be deleted in the final version of the 137 document. 139 From version 00 -> 01: 141 o Harmonize terminology with CMP [RFC4210], e.g., 143 * transaction, message sequence, exchange, use case -> PKI 144 management operqation 146 * PKI component, (L)RA/CA -> PKI management entity 148 o Minor changes in wording 150 From draft-brockhaus-lamps-lightweight-cmp-profile-03 -> draft-ietf- 151 lamps-lightweight-cmp-profile-00: 153 o Changes required to reflect WG adoption 155 o Minor changes in wording 157 From version 02 -> 03: 159 o Added a short summary of [RFC4210] Appendix D and E in 160 Section 2.3. 162 o Clarified some references to different sections and added some 163 clarification in response to feedback from Michael Richardson and 164 Tomas Gustavsson. 166 o Added an additional label to the operational path to address 167 multiple CAs or certificate profiles in Section 7.1. 169 From version 01 -> 02: 171 o Added some clarification on the key management techniques for 172 protection of centrally generated keys in Section 5.1.6. 174 o Added some clarifications on the certificates for root CA 175 certificate update in Section 5.4.3. 177 o Added a section to specify the usage of nested messages for RAs to 178 add an additional protection for further discussion, see 179 Section 6.1.3. 181 o Added a table containing endpoints for HTTP transport in 182 Section 7.1 to simplify addressing PKI management entities. 184 o Added some ToDos resulting from discussion with Tomas Gustavsson. 186 o Minor clarifications and changes in wording. 188 From version 00 -> 01: 190 o Added a section to specify the enrollment with a already trusted 191 PKI for further discussion, see Section 5.1.2. 193 o Complete specification of requesting a certificate from a legacy 194 PKI using a PKCS#10 [RFC2986] request in Section 5.1.5. 196 o Complete specification of adding central generation of a key pair 197 on behalf of an end entity in Section 5.1.6. 199 o Complete specification of handling delayed enrollment due to 200 asynchronous message delivery in Section 5.1.7. 202 o Complete specification of additional support messages, e.g., to 203 update a Root CA certificate or to request an RFC 8366 [RFC8366] 204 voucher, in Section 5.4. 206 o Minor changes in wording. 208 From draft-brockhaus-lamps-industrial-cmp-profile-00 -> draft- 209 brockhaus-lamps-lightweight-cmp-profile-00: 211 o Change focus from industrial to more multi-purpose use cases and 212 lightweight CMP profile. 214 o Incorporate the omitted confirmation into the header specified in 215 Section 4.1 and described in the standard enrollment use case in 216 Section 5.1.1 due to discussion with Tomas Gustavsson. 218 o Change from OPTIONAL to RECOMMENDED for use case 'Revoke another's 219 entities certificate' in Section 6.2, because it is regarded as 220 important functionality in many environments to enable the 221 management station to revoke EE certificates. 223 o Complete the specification of the revocation message flow in 224 Section 5.2 and Section 6.2. 226 o The CoAP based transport mechanism and piggybacking of CMP 227 messages on top of other reliable transport protocols is out of 228 scope of this document and would need to be specified in another 229 document. 231 o Further minor changes in wording. 233 2. Introduction 235 This document specifies PKI management operations supporting machine- 236 to-machine and IoT use cases. The focus lies on maximum automation 237 and interoperable implementation of all involved PKI entities from 238 end entities (EE) through an optional Local Registration Authority 239 (LRA) and the RA up to the CA. The profile makes use of the concepts 240 and syntax specified in CMP [RFC4210], CRMF [RFC4211], HTTP transfer 241 for CMP [RFC6712], and CMP Updates [I-D.ietf-lamps-cmp-updates]. 242 Especially CMP and CRMF are very feature-rich standards, while only a 243 limited subset of the specified functionality is needed in many 244 environments. Additionally, the standards are not always precise 245 enough on how to interpret and implement the described concepts. 246 Therefore, this document aims at tailoring and specifying in more 247 detail how to use these concepts to implement lightweight automated 248 certificate management. 250 2.1. Motivation for profiling CMP 252 CMP was standardized in 1999 and is implemented in several CA 253 products. In 2005 a completely reworked and enhanced version 2 of 254 CMP [RFC4210] and CRMF [RFC4211] has been published followed by a 255 document specifying a transfer mechanism for CMP messages using http 256 [RFC6712] in 2012. 258 Though CMP is a very solid and capable protocol it could be used more 259 widely. The most important reason for not more intense application 260 of CMP appears to be that the protocol is offering a large set of 261 features and options but being not always precise enough and leaving 262 room for interpretation. On the one hand, this makes CMP applicable 263 to a very wide range of scenarios, but on the other hand a full 264 implementation of all options is unrealistic because this would take 265 enormous effort. 267 Moreover, many details of the CMP protocol have been left open or 268 have not been specified in full preciseness. The profiles specified 269 in Appendix D and E of [RFC4210] offer some more detailed PKI 270 management operations. But the specific needs of highly automated 271 scenarios for a machine-to-machine communication are not covered 272 sufficiently. 274 As also 3GPP and UNISIG already put across, profiling is a way of 275 coping with the challenges mentioned above. To profile means to take 276 advantage of the strengths of the given protocol, while explicitly 277 narrowing down the options it provides to exactly those needed for 278 the purpose(s) at hand and eliminating all identified ambiguities. 279 In this way all the general and applicable aspects of the protocol 280 can be taken over and only the peculiarities of the target scenario 281 need to be dealt with specifically. 283 Doing such a profiling for a new target environment can be a high 284 effort because the range of available options needs to be well 285 understood and the selected options need to be consistent with each 286 other and with the intended usage scenario. Since most industrial 287 PKI management use cases typically have much in common it is worth 288 sharing this effort, which is the aim of this document. Other 289 standardization bodies can then reference the needed PKI management 290 operations from this document and do not need to come up with 291 individual profiles. 293 2.2. Motivation for a lightweight profile for CMP 295 The profiles specified in Appendix D and E of CMP have been developed 296 in particular to manage certificates of human end entities. With the 297 evolution of distributed systems and client-server architectures, 298 certificates for machines and applications on them have become widely 299 used. This trend has strengthened even more in emerging industrial 300 and IoT scenarios. CMP is sufficiently flexible to support these 301 very well. 303 Today's IT security architectures for industrial solutions typically 304 use certificates for endpoint authentication within protocols like 305 IPSec, TLS, or SSH. Therefore, the security of these architectures 306 highly relies upon the security and availability of the implemented 307 certificate management procedures. 309 Due to increasing security in operational networks as well as 310 availability requirements, especially on critical infrastructures and 311 systems with a high volume of certificates, a state-of-the-art 312 certificate management must be constantly available and cost- 313 efficient, which calls for high automation and reliability. The NIST 314 Cyber Security Framework [NIST-CSFW] also refers to proper processes 315 for issuance, management, verification, revocation, and audit for 316 authorized devices, users and processes involving identity and 317 credential management. Such PKI operation according to commonly 318 accepted best practices is also required in IEC 62443-3-3 319 [IEC62443-3-3] for security level 2 up to security level 4. 321 Further challenges in many industrial systems are network 322 segmentation and asynchronous communication, where PKI operation is 323 often not deployed on-site but in a more protected environment of a 324 data center or trust center. Certificate management must be able to 325 cope with such network architectures. CMP offers the required 326 flexibility and functionality, namely self-contained messages, 327 efficient polling, and support for asynchronous message transfer with 328 end-to-end security. 330 2.3. Existing CMP profiles 332 As already stated, CMP contains profiles with mandatory and optional 333 transactions in the Appendixes D and E of [RFC4210]. Those profiles 334 focus on management of human user certificates and do only partly 335 address the specific needs for certificate management automation for 336 unattended machine or application-oriented end entities. 338 [RFC4210] specifies in Appendix D the following mandatory PKI 339 management operations (all require support of, in the meantime 340 outdated, algorithms, e.g., SHA-1 and 3-DES; all operations may 341 enroll up to two certificates, one for a locally generated and 342 another optional one for a centrally generated key pair; all require 343 use of certConf/PKIConf messages for confirmation): 345 o Initial registration/certification; an (uninitialized) end entity 346 requests a (first) certificate from a CA using shared secret based 347 message authentication. The content is similar to the PKI 348 management operation specified in Section 5.1.4 of this document. 350 o Certificate request; an (initialized) end entity requests another 351 certificate from a CA using signature or shared secret based 352 message authentication. The content is similar to the PKI 353 management operation specified in Section 5.1.2 of this document. 355 o Key update; an (initialized) end entity requests a certificate 356 from a CA (to update the key pair and/or corresponding certificate 357 that it already possesses) using signature or shared secret based 358 message authentication. The content is similar to the PKI 359 management operation specified in Section 5.1.3 of this document. 361 Due to the two certificates that may be enrolled and the shared 362 secret based authentication, these PKI management operations focus 363 more on the enrollment of human users at a PKI. 365 [RFC4210] specifies in Appendix E the following optional PKI 366 management operations (all require support of, in the meantime 367 outdated, algorithms, e.g., SHA-1 and 3-DES): 369 o Root CA key update; a root CA updates its key pair and produces a 370 CA key update announcement message that can be made available (via 371 some transport mechanism) to the relevant end entities. This 372 operation only supports a push and no pull model. The content is 373 similar to the PKI management operation specified in Section 5.4.3 374 of this document. 376 o Information request/response; an end entity sends a general 377 message to the PKI requesting details that will be required for 378 later PKI management operations. The content is similar to the 379 PKI management operation specified in Section 5.4.4 and 380 Section 5.4.5 of this document. 382 o Cross-certification request/response (1-way); creation of a single 383 cross-certificate (i.e., not two at once). The requesting CA MAY 384 choose who is responsible for publication of the cross-certificate 385 created by the responding CA through use of the PKIPublicationInfo 386 control. 388 o In-band initialization using external identity certificate (this 389 PKI management operation may also enroll up to two certificates 390 and requires use of certConf/PKIConf messages for confirmation as 391 specified in Appendix D of [RFC4210]). An (uninitialized) end 392 entity wishes to initialize into the PKI with a CA, CA-1. It 393 uses, for authentication purposes, a pre-existing identity 394 certificate issued by another (external) CA, CA-X. A trust 395 relationship must already have been established between CA-1 and 396 CA-X so that CA-1 can validate the EE identity certificate signed 397 by CA-X. Furthermore, some mechanism must already have been 398 established within the Personal Security Environment (PSE) of the 399 EE that would allow it to authenticate and verify PKIMessages 400 signed by CA-1. The content is similar to the PKI management 401 operation specified in Section 5.1.1 of this document. The trust 402 establishment of the EE in CA-1 and of the CA/RA in CA-X can be 403 automated using, e.g., the exchange of a certificate management 404 configuration as specified in Section 5.4.5 or an enrollment 405 voucher as specified in Section 5.4.6 of this document. 407 Both Appendixes focus on EE to CA/RA PKI management operations and do 408 not address further profiling of RA to CA communication as typically 409 used for full backend automation. 411 3GPP makes use of CMP [RFC4210] in its Technical Specification 133 412 310 [ETSI-3GPP] for automatic management of IPSec certificates in 413 UMTS, LTE, and 5G backbone networks. Since 2010 a dedicated CMP 414 profile for initial certificate enrollment and update operations 415 between EE and RA/CA is specified in that document. 417 UNISIG has included a CMP profile for certificate enrollment in the 418 subset 137 specifying the ETRAM/ECTS on-line key management for train 419 control systems [UNISIG] in 2015. 421 Both standardization bodies use CMP [RFC4210], CRMF [RFC4211], and 422 HTTP transfer for CMP [RFC6712] to add tailored means for automated 423 PKI management operations for unattended machine or application- 424 oriented end entities. 426 2.4. Compatibility with existing CMP profiles 428 The profile specified in this document is compatible with CMP 429 [RFC4210] Appendixes D and E (PKI Management Message Profiles), with 430 the following exceptions: 432 o signature-based protection is the default protection; an initial 433 PKI management operation may also use HMAC, 435 o certification of a second key pair within the same PKI management 436 operation is not supported, 438 o proof-of-possession (POPO) with self-signature of the certTemplate 439 according to [RFC4211] section 4.1 clause 3 is the recommended 440 default POPO method (deviations are possible by EEs when 441 requesting central key generation and by (L)RAs when using 442 raVerified), 444 o confirmation of newly enrolled certificates may be omitted, and 446 o all PKI management operations consist of request-response message 447 pairs originating at the EE, i.e., announcement messages are 448 omitted. 450 The profile specified in this document is compatible with the CMP 451 profile for UMTS, LTE, and 5G network domain security and 452 authentication framework [ETSI-3GPP], except that: 454 o protection of initial PKI management operations may be HMAC-based, 456 o the subject name is mandatory in certificate templates, and 458 o confirmation of newly enrolled certificates may be omitted. 460 The profile specified in this document is compatible with the CMP 461 profile for on-line key management in rail networks as specified in 462 UNISIG subset-137 [UNISIG], except that: 464 o as of RFC 4210 [RFC4210] the messageTime is required to be 465 Greenwich Mean Time coded as generalizedTime (Note: While UNISIG 466 explicitely states that the messageTime in required to be 'UTC 467 time', it is not clear if this means a coding as UTCTime or 468 generalizedTime and if other time zones than Greenwich Mean Time 469 shall be allowed. Therefore UNISG may be in conflict with 470 RFC 4210 [RFC4210]. Both time formats are described in RFC 5280 471 [RFC5280] section 4.1.2.5.), and 473 o in case the request message is MAC protected, also the response, 474 certConf, and PKIconf messages have a MAC-based protection (Note: 475 if changing to signature protection of the response the caPubs 476 field cannot be used securely anymore.). 478 2.5. Scope of this document 480 This document specifies requirements on generating PKI management 481 messages on the sender side. It does not specify strictness of 482 verification on the receiving side and how in detail to handle error 483 cases. 485 Especially on the EE side this profile aims at a lightweight protocol 486 that can be implemented on more constrained devices. On the side of 487 the central PKI management entities the profile accepts higher 488 resources needed. 490 For the sake of robustness and preservation of security properties 491 implementations should, as far as security is not affected, adhere to 492 Postel's law: "Be conservative in what you do, be liberal in what you 493 accept from others" (often reworded as: "Be conservative in what you 494 send, be liberal in what you accept"). 496 When in Section 4, Section 5, and Section 6 a field of the ASN.1 497 syntax as defined in RFC 4210 [RFC4210] and RFC 4211 [RFC4211] is not 498 explicitly specified, it SHOULD not be used by the sending entity. 499 The receiving entity MUST NOT require its absence and if present MUST 500 gracefully handle its presence. 502 2.6. Structure of this document 504 Section 3 introduces the general PKI architecture and approach to 505 certificate management using CMP that is assumed in this document. 506 Then it enlists the PKI management opertations specified in this 507 document and describes them in general words. The list of supported 508 PKI management operations is divided into mandatory, recommended, and 509 optional ones. 511 Section 4 profiles the CMP message header, protection, and extraCerts 512 section as they are general elements of CMP messages. 514 Section 5 profiles the exchange of CMP messages between an EE and the 515 first PKI management entities. There are various flavors of 516 certificate enrollment requests optionally with polling, revocation, 517 error handling, and general support PKI management operations. 519 Section 6 profiles the exchange between PKI management entities. 520 These are in the first place the forwarding of messages coming from 521 or going to an EE. This includes also initiating delayed delivery of 522 messages, which involves polling. Additionally, it specifies PKI 523 management operations where a PKI management entity manages 524 certificates on behalf of an EE or for itself. 526 Section 7 outlines different mechanisms for CMP message transfer, 527 namely http-based transfer as already specified in [RFC6712], using 528 an additional TLS layer, or offline file-based transport. CoAP 529 [RFC7252] and piggybacking CMP messages on other protocols is out of 530 scope and left for further documents. 532 2.7. Convention and Terminology 534 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 535 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 536 document are to be interpreted as described in RFC 2119 [RFC2119]. 538 In this document, these words will appear with that interpretation 539 only when in ALL CAPS. Lower case use of these words are not to be 540 interpreted as carrying significance described in RFC 2119. 542 Technical terminology is used in conformance with RFC 4210 [RFC4210], 543 RFC 4211 [RFC4211], RFC 5280 [RFC5280], and IEEE 802.1AR 544 [IEEE802.1AR]. The following key words are used: 546 CA: Certification authority, which issues certificates. 548 RA: Registration authority, an optional system component to which a 549 CA delegates certificate management functions such as 550 authorization checks. 552 LRA: Local registration authority, an optional RA system component 553 with proximity to the end entities. 555 KGA: Key generation authority, an optional system component, 556 typically co-located with an LRA, RA, or CA, that offers key 557 generation services to end entities. 559 EE: End entity, a user, device, or service that holds a PKI 560 certificate. An identifier for the EE is given as the subject 561 of its certificate. 563 The following terminology is reused from RFC 4210 [RFC4210] and used 564 as follows: 566 PKI management operation: All CMP messages belonging to one 567 transaction context. The transaction is 568 identified in the transactionID field of 569 the message header. 571 PKI management entity: All central PKI entites like LRA, RA and 572 CA. 574 PKI entity: EEs and PKI management entites 576 3. Architecture and use cases 578 3.1. Solution architecture 580 Typically, a machine EE will be equipped with a manufacturer issued 581 certificate during production. Such a manufacturer issued 582 certificate is installed during production to identify the device 583 throughout its lifetime. This manufacturer certificate can be used 584 to protect the initial enrollment of operational certificates after 585 installation of the EE in a plant or industrial network. An 586 operational certificate is issued by the owner or operator of the 587 device to identify the device during operation, e.g., within a 588 security protocol like IPSec, TLS, or SSH. In IEEE 802.1AR 589 [IEEE802.1AR] a manufacturer certificate is called IDevID certificate 590 and an operational certificate is called LDevID certificate. 592 All certificate management transactions specified in this document 593 are initiated by the EE. The EE creates a CMP request message, 594 protects it using its manufacturer or operational certificate, if 595 available, and sends it to its locally reachable PKI component. This 596 PKI component may be an LRA, RA, or the CA, which checks the request, 597 responds to it itself, or forwards the request upstream to the next 598 PKI component. In case an (L)RA changes the CMP request message 599 header or body or wants to prove a successful verification or 600 authorization, it can apply a protection of its own. Especially the 601 communication between an LRA and RA can be performed synchronously or 602 asynchronously. Synchronous communication describes a timely 603 uninterrupted communication between two communication partners, while 604 asynchronous communication is not performed in a timely consistent 605 manner, e.g., because of a delayed message delivery. 607 +-----+ +-----+ +-----+ +-----+ 608 | | | | | | | | 609 | EE |<---------->| LRA |<-------------->| RA |<---------->| CA | 610 | | | | | | | | 611 +-----+ +-----+ +-----+ +-----+ 613 synchronous (a)synchronous (a)synchronous 614 +----connection----+------connection------+----connection----+ 616 on site at operators service partner 617 +----------plant---------+-----backend services-----+-trust center-+ 619 Figure 1: Certificate management on site 621 In operation environments a layered LRA-RA-CA architecture can be 622 deployed, e.g., with LRAs bundling requests from multiple EEs at 623 dedicated locations and one (or more than one) central RA aggregating 624 the requests from multiple LRAs. Every (L)RA in this scenario will 625 have its own dedicated certificate containing an extended key usage 626 as specified in CMP Updates [I-D.ietf-lamps-cmp-updates] and private 627 key allowing it to protect CMP messages it processes (CMP signing 628 key/certificate). The figure above shows an architecture using one 629 LRA and one RA. It is also possible to have only an RA or multiple 630 LRAs and/or RAs. Depending on the network infrastructure, the 631 communication between different PKI management entites may be 632 synchronous online-communication, delayed asynchronous communication, 633 or even offline file transfer. 635 This profile focusses on specifying the pull model, where the EE 636 always requests a specific PKI management operation. CMP response 637 messages, especially in case of central key generation, as described 638 in Section 5.1.6, could also be used proactively to implement the 639 push model towards the EE. 641 Third-party CAs typically implement different variants of CMP or even 642 use proprietary interfaces for certificate management. Therefore, 643 the LRA or the RA may need to adapt the exchanged CMP messages to the 644 flavor of communication required by the CA. 646 3.2. Basic generic CMP message content 648 Section 4 specifies the generic parts of the CMP messages as used 649 later in Section 5 and Section 6. 651 o Header of a CMP message; see Section 4.1. 653 o Protection of a CMP message; see Section 4.2. 655 o ExtraCerts field of a CMP message; see Section 4.3. 657 3.3. Supported PKI management operations 659 Following the outlined scope from Section 2.5, this section gives a 660 brief overview of the PKI management operations specified in 661 Section 5 and Section 6 and points out, whether an implementation by 662 compliant EE or PKI management entites is mandatory, recommended or 663 optional. 665 3.3.1. Mandatory PKI management operations 667 The mandatory PKI management operations in this document shall limit 668 the overhead of certificate management for more constrained devices 669 to the most crucial types of operations. 671 Section 5 - End Entity focused PKI management operations 673 o Request a certificate from a new PKI with signature protection; 674 see Section 5.1.1. 676 o Request to update an existing certificate with signature 677 protection; see Section 5.1.3. 679 o Error reporting; see Section 5.3. 681 Section 6 - LRA and RA focused PKI management operations 683 o Forward messages without changes; see Section 6.1.1. 685 o Forward messages with replaced protection and raVerified as proof- 686 of-possession; see Section 6.1.2.2. 688 o Error reporting; see Section 6.3. 690 3.3.2. Recommended PKI management operations 692 Additional recommended PKI management operations shall support some 693 more complex scenarios, that are considered as beneficial for 694 environments with more specific boundary conditions. 696 Section 5 - End Entity focused PKI management operations 698 o Request a certificate from a PKI with MAC protection; see 699 Section 5.1.4. 701 o Handle delayed enrollment due to asynchronous message delivery; 702 see Section 5.1.7. 704 < TBD: There still some discussion ongoing if this should be 705 recommended or optional. > 707 o Revoke an own certificate. 709 Section 6 - LRA and RA focused PKI management operations 711 o Revoke another's entities certificate. 713 3.3.3. Optional PKI management operations 715 The optional PKI management operations support specific requirements 716 seen only in a subset of environments. 718 Section 5 - End Entity focused PKI management operations 720 o Request a certificate from a trusted PKI with signature 721 protection; see Section 5.1.2. 723 o Request a certificate from a legacy PKI using a PKCS#10 [RFC2986] 724 request; see Section 5.1.5. 726 o Add central generation of a key pair to a certificate request; see 727 Section 5.1.6. If central key generation is supported, the key 728 agreement key management technique is REQUIRED to be supported, 729 and the key transport and symmetric key-encryption key management 730 techniques are OPTIONAL. 732 o Additional support messages, e.g., to update a root CA certificate 733 or to request an RFC 8366 [RFC8366] voucher; see Section 5.4. 735 Section 6 - LRA and RA focused PKI management operations 737 o Initiate delayed enrollment due to asynchronous message delivery; 738 see Section 6.1.4. 740 3.4. CMP message transport 742 On different links between PKI entities, e.g., EE<->RA and RA<->CA, 743 different transport MAY be used. As CMP has only very limited 744 requirement regarding the mechanisms used for message transport and 745 in different environments different transport mechanisms are 746 supported, e.g. HTTP, CoAP, or even offline files based, this 747 document requires no specific transport protocol to be supported by 748 all conforming implementations. 750 HTTP transfer is RECOMMENDED to use for all PKI entities, but there 751 is no transport specified as mandatory to be flexible for devices 752 with special constraines to choose whatever transport is suitable. 754 Recommended transport 756 o Transfer CMP messages using HTTP; see Section 7.1. 758 Optional transport 759 o Transfer CMP messages using HTTPS with certificate-based 760 authentication; see Section 7.2. 762 o Transfer CMP messages using HTTPS with shared-secret based 763 protection; see Section 7.3. 765 o File-based CMP message transport. 767 < TBD: Motivation see Section 7.4 > 769 < TBD: Michael Richardson proposed to also specify a CoAP based 770 message transport profile. If there is further support for this 771 profile and someone volunteering to provide the necessary input for 772 this section, I would like to add it to this document. > 774 4. Generic parts of the PKI message 776 To reduce redundancy in the text and to ease implementation, the 777 contents of the header, protection, and extraCerts fields of the CMP 778 messages used in the transactions specified in Section 5 and 779 Section 6 are standardized to the maximum extent possible. 780 Therefore, the generic parts of a CMP message are described centrally 781 in this section. 783 As described in section 5.1 of [RFC4210], all CMP messages have the 784 following general structure: 786 +--------------------------------------------+ 787 | PKIMessage | 788 | +----------------------------------------+ | 789 | | header | | 790 | +----------------------------------------+ | 791 | +----------------------------------------+ | 792 | | body | | 793 | +----------------------------------------+ | 794 | +----------------------------------------+ | 795 | | protection (OPTIONAL) | | 796 | +----------------------------------------+ | 797 | +----------------------------------------+ | 798 | | extraCerts (OPTIONAL) | | 799 | +----------------------------------------+ | 800 +--------------------------------------------+ 802 Figure 2: CMP message structure 804 The general contents of the message header, protection, and 805 extraCerts fields are specified in the Section 4.1 to Section 4.3. 807 In case a specific CMP message needs different contents in the 808 header, protection, or extraCerts fields, the differences are 809 described in the respective message. 811 The CMP message body contains the message-specific information. It 812 is described in the context of Section 5 and Section 6. 814 The behavior in case an error occurs while handling a CMP message is 815 described in Section 6.3. 817 4.1. General description of the CMP message header 819 This section describes the generic header field of all CMP messages 820 with signature-based protection. The only variations described here 821 are in the fields recipient, transactionID, and recipNonce of the 822 first message of a PKI management operation. 824 In case a message has MAC-based protection the changes are described 825 in the respective section. The variations will affect the fields 826 sender, protectionAlg, and senderKID. 828 For requirements about proper random number generation please refer 829 to [RFC4086]. Any message-specific fields or variations are 830 described in the respective sections of this chapter. 832 header 833 pvno REQUIRED 834 -- MUST be set to 2 to indicate CMP V2 835 sender REQUIRED 836 -- MUST be the subject of the protection certificate used for, 837 -- the certificate for the private key used to sign the message 838 recipient REQUIRED 839 -- SHOULD be the name of the intended recipient and 840 -- MAY be a NULL_DN if the sender does not know the DN of 841 -- the recipient 842 -- If this is the first message of a transaction: SHOULD be the 843 -- subject of the issuing CA certificate 844 -- In all other messages: SHOULD be the same name as in the 845 -- sender field of the previous message in this transaction 846 messageTime RECOMMENDED 847 -- MUST be the time at which the message was produced, if 848 -- present 849 protectionAlg REQUIRED 850 -- MUST be the algorithm identifier of the signature algorithm or 851 -- id-PasswordBasedMac algorithm used for calculation of the 852 -- protection bits 853 -- The signature algorithm MUST be consistent with the 854 -- SubjectPublicKeyInfo field of the signer's certificate 855 -- The hash algorithm used SHOULD be SHA-256 856 algorithm REQUIRED 857 -- MUST be the OID of the signature algorithm, like 858 -- sha256WithRSAEncryption or ecdsa-with-SHA256, or 859 -- id-PasswordBasedMac 860 senderKID RECOMMENDED 861 -- MUST be the SubjectKeyIdentifier, if available, of the 862 -- protection certificate 863 transactionID REQUIRED 864 -- If this is the first message of a transaction: 865 -- MUST be 128 bits of random data for the start of a 866 -- transaction to reduce the probability of having the 867 -- transactionID already in use at the server 868 -- In all other messages: 869 -- MUST be the value from the previous message in the same 870 -- transaction 871 senderNonce REQUIRED 872 -- MUST be fresh 128 random bits 873 recipNonce RECOMMENDED 874 -- If this is the first message of a transaction: SHOULD be 875 -- absent 876 -- In all other messages: MUST be present and contain the value 877 -- from senderNonce of the previous message in the same 878 -- transaction 879 generalInfo OPTIONAL 880 implicitConfirm OPTIONAL 881 -- The field is optional though it only applies to 882 -- ir/cr/kur/p10cr requests and ip/cp/kup response messages 883 -- Add to request messages to request omit sending certConf 884 -- message 885 -- Add to response messages to confirm omit sending certConf 886 -- message 887 ImplicitConfirmValue REQUIRED 888 -- ImplicitConfirmValue of the request message MUST be NULL if 889 -- the EE wants to request not to send a confirmation message 890 -- ImplicitConfirmValue MUST be set to NULL if the (L)RA/CA 891 -- wants to grant not sending a confirmation message 893 4.2. General description of the CMP message protection 895 This section describes the generic protection field of all CMP 896 messages with signature-based protection. The certificate for the 897 private key used to sign a CMP message is called 'protection 898 certificate'. 900 protection RECOMMENDED 901 -- MUST contain the signature calculated using the signature 902 -- algorithm specified in protectionAlg 904 Generally CMP message protection is required for CMP messages, but 905 there are cases where protection of error messages as specified in 906 Section 5.3 and Section 6.3 is not possible and therefore MAY be 907 omitted. 909 For MAC-based protection as specified in Section 5.1.4 major 910 differences apply as described in the respective section. 912 The CMP message protection provides, if available, message origin 913 authentication and integrity protection for the CMP message header 914 and body. The CMP message extraCerts is not covered by this 915 protection. 917 NOTE: The extended key usages specified in CMP Updates 918 [I-D.ietf-lamps-cmp-updates] can be used for authorization of a 919 sending PKI management entity. 921 NOTE: The requirements for checking certificates given in [RFC5280] 922 MUST be followed for the CMP message protection. In case the CMP 923 signer certificates is not the CA certificate that signed the newly 924 issued certificate, certificate status checking SHOULD be used for 925 the CMP signer certificates of communication partners. 927 4.3. General description of CMP message extraCerts 929 This section describes the generic extraCerts field of all CMP 930 messages with signature-based protection. If extraCerts are 931 required, recommended, or optional is specified in the respective PKI 932 management operation. 934 extraCerts 935 -- SHOULD contain the protection certificate together with its 936 -- chain, if needed 937 -- If present, the first certificate in this field MUST 938 -- be the protection certificate 939 -- Self-signed certificates SHOULD NOT be included in 940 -- extraCerts and MUST NOT be trusted based on the listing in 941 -- extraCerts in any case 943 5. End Entity focused PKI management operations 945 This chapter focuses on the communication of the EE and the first PKI 946 management entities it talks to. Depending on the network and PKI 947 solution, this will either be the LRA, the RA or the CA. 949 Profiles of the Certificate Management Protocol (CMP) [RFC4210] 950 handled in this section cover the following PKI management 951 operations: 953 o Requesting a certificate from a PKI with variations like initial 954 requests and updating, central key generation and different 955 protection means 957 o Revocation of a certificate 959 o General messages for further support functions 961 These operations mainly specify the message body of the CMP messages 962 and utilize the specification of the message header, protection and 963 extraCerts as specified in Section 5. 965 The behavior in case an error occurs is described in Section 5.3. 967 This chapter is aligned to Appendix D and Appendix E of [RFC4210]. 968 The general rules for interpretation stated in Appendix D.1 in 969 [RFC4210] need to be applied here, too. 971 This document does not mandate any specific supported algorithms like 972 Appendix D.2 of [RFC4210], [ETSI-3GPP], and [UNISIG] do. Using the 973 message sequences described here require agreement upon the 974 algorithms to support and thus the algorithm identifiers for the 975 specific target environment. 977 5.1. Requesting a new certificate from a PKI 979 There are different approaches to request a certificate from a PKI. 981 These approaches differ on the one hand in the way the EE can 982 authenticate itself to the PKI it wishes to get a new certificate 983 from and on the other hand in its capabilities to generate a proper 984 new key pair. The authentication means may be as follows: 986 o Using a certificate from a trusted PKI and the corresponding 987 private key, e.g., a manufacturer issued certificate 989 o Using the certificate to be updated and the corresponding private 990 key 992 o Using a shared secret known to the EE and the PKI 994 Typically, such EE requests a certificate from a CA. When the PKI 995 management entity responds with a message containing a certificate, 996 the EE MUST reply with a confirmation message. The PKI management 997 entity then MUST send confirmation back, closing the transaction. 999 The message sequences in this section allow the EE to request 1000 certification of a locally generated public-private key pair. For 1001 requirements about proper random number and key generation please 1002 refer to [RFC4086]. The EE MUST provide a signature-based proof-of- 1003 possession of the private key associated with the public key 1004 contained in the certificate request as defined by [RFC4211] section 1005 4.1 case 3. To this end it is assumed that the private key can 1006 technically be used as signing key. The most commonly used 1007 algorithms are RSA and ECDSA, which can technically be used for 1008 signature calculation regardless of potentially intended restrictions 1009 of the key usage. 1011 The requesting EE provides the binding of the proof-of-possession to 1012 its identity by signature-based or MAC-based protection of the CMP 1013 request message containing that POPO. The PKI management entity 1014 needs to verify whether this EE is authorized to obtain a certificate 1015 with the requested subject and other attributes and extensions. 1016 Especially when removing the protection provided by the EE and 1017 applying a new protection the PKI management entity MUST verify in 1018 particular the included proof-of-possession self-signature of the 1019 certTemplate using the public key of the requested certificate and 1020 MUST check that the EE, as authenticated by the message protection, 1021 is authorized to request a certificate with the subject as specified 1022 in the certTemplate (see Section 6.1.2). 1024 There are several ways to install the Root CA certificate of a new 1025 PKI on an EE. The installation can be performed in an out-of-band 1026 manner, using general messages, a voucher [RFC8366], or other formats 1027 for enrollment, or in-band of CMP by the caPubs field in the 1028 certificate response message. In case the installation of the new 1029 root CA certificate is performed using the caPubs field, the 1030 certificate response message MUST be properly authenticated, and the 1031 sender of this message MUST be authorized to install new root CA 1032 certificates on the EE. This authorization can be indicated by using 1033 pre-shared keys for the CMP message protection. 1035 5.1.1. Request a certificate from a new PKI with signature protection 1037 This PKI management operation should be used by an EE to request a 1038 certificate of a new PKI using an existing certificate from an 1039 external PKI, e.g., a manufacturer certificate, to prove its identity 1040 to the new PKI. The EE already has established trust in this new PKI 1041 it is about to enroll to, e.g., by voucher exchgnge or configuration 1042 means. The initialization request message is signature-protected 1043 using the existing certificate. 1045 Preconditions: 1047 1 The EE MUST have a certificate enrolled by an external PKI in 1048 advance to this PKI management operation to authenticate itself to 1049 the PKI management entity using signature-based protection, e.g., 1050 using a manufacturer issued certificate. 1052 2 The EE SHOULD know the subject name of the new CA it requests a 1053 certificate from; this name MAY be established using an enrollment 1054 voucher or other configuration means. If the EE does not know the 1055 name of the CA, the PKI management entity MUST know where to route 1056 this request to. 1058 3 The EE MUST authenticate responses from the PKI management entity; 1059 trust MAY be established using an enrollment voucher or other 1060 configuration means 1062 4 The PKI management entity MUST trust the external PKI the EE uses 1063 to authenticate itself; trust MAY be established using some 1064 configuration means 1066 This PKI management operation is like that given in [RFC4210] 1067 Appendix E.7. 1069 Message flow: 1071 Step# EE PKI management entity 1072 1 format ir 1073 2 -> ir -> 1074 3 handle, re-protect or 1075 forward ir 1076 4 format or receive ip 1077 5 possibly grant implicit 1078 confirm 1079 6 <- ip <- 1080 7 handle ip 1081 8 In case of status 1082 "rejection" in the 1083 ip message, no certConf 1084 and pkiConf are sent 1085 9 format certConf (optional) 1086 10 -> certConf -> 1087 11 handle, re-protect or 1088 forward certConf 1089 12 format or receive PKIConf 1090 13 <- pkiConf <- 1091 14 handle pkiConf (optional) 1093 For this PKI management operation the EE MUST include exactly one 1094 single CertReqMsg in the ir. If more certificates are required, 1095 further requests MUST be sent using separate CMP messages. If the EE 1096 wants to omit sending a certificate confirmation message after 1097 receiving the ip to reduce the number of protocol messages exchanged 1098 in this PKI management operation, it MUST request this by setting the 1099 implicitControlValue in the ir to NULL. 1101 If the CA accepts the certificate request it MUST return the new 1102 certificate in the certifiedKeyPair field of the ip message. If the 1103 EE requested to omit sending a certConf message after receiving the 1104 ip, the PKI management entity MAY confirm it by also setting the 1105 implicitControlValue to NULL or MAY rejects it by omitting the 1106 implicitConfirm field in the ip. 1108 If the EE did not request implicit confirmation or the request was 1109 not granted by the PKI management entity the confirmation as follows 1110 MUST be performed. If the EE successfully receives the certificate 1111 and accepts it, the EE MUST send a certConf message, which MUST be 1112 answered by the PKI management entity with a pkiConf message. If the 1113 PKI management entity does not receive the expected certConf message 1114 in time it MUST handle this like a rejection by the EE. 1116 If the certificate request was refused by the CA, the PKI management 1117 entity must return an ip message containing the status code 1118 "rejection" and no certifiedKeyPair field. Such an ip message MUST 1119 NOT be followed by the certConf and pkiConf messages. 1121 Detailed message description: 1123 Certification Request -- ir 1125 Field Value 1127 header 1128 -- As described in section 4.1 1130 body 1131 -- The request of the EE for a new certificate 1132 ir REQUIRED 1133 -- MUST be exactly one CertReqMsg 1134 -- If more certificates are required, further requests MUST be 1135 -- packaged in separate PKI Messages 1136 certReq REQUIRED 1137 certReqId REQUIRED 1138 -- MUST be set to 0 1139 certTemplate REQUIRED 1140 version OPTIONAL 1141 -- MUST be 2 if supplied. 1142 subject REQUIRED 1143 -- MUST contain the suggested subject name of the EE 1144 -- certificate 1145 publicKey REQUIRED 1146 algorithm REQUIRED 1147 -- MUST include the subject public key algorithm ID and value 1148 -- In case a central key generation is requested, this field 1149 -- contains the algorithm and parameter preferences of the 1150 -- requesting entity regarding the to-be-generated key pair 1151 subjectPublicKey REQUIRED 1152 -- MUST contain the public key to be included into the requested 1153 -- certificate in case of local key-generation 1154 -- MUST contain a zero-length BIT STRING in case a central key 1155 -- generation is requested 1156 -- MUST include the subject public key algorithm ID and value 1157 extensions OPTIONAL 1158 -- MAY include end-entity-specific X.509 extensions of the 1159 -- requested certificate like subject alternative name, 1160 -- key usage, and extended key usage 1161 Popo REQUIRED 1162 POPOSigningKey OPTIONAL 1163 -- MUST be used in case subjectPublicKey contains a public key 1164 -- MUST be absent in case subjectPublicKey contains a 1165 -- zero-length BIT STRING 1166 poposkInput PROHIBITED 1167 -- MUST NOT be used because subject and publicKey are both 1168 -- present in the certTemplate 1169 algorithmIdentifier REQUIRED 1170 -- The signature algorithm MUST be consistent with the 1171 -- publicKey field of the certTemplate 1172 -- The hash algorithm used SHOULD be SHA-256 1173 signature REQUIRED 1174 -- MUST be the signature computed over the DER-encoded 1175 -- certTemplate 1177 protection REQUIRED 1178 -- As described in section 4.2 1180 extraCerts REQUIRED 1181 -- As described in section 4.3 1183 Certification Response -- ip 1185 Field Value 1187 header 1188 -- As described in section 4.1 1190 body 1191 -- The response of the CA to the request as appropriate 1193 ip REQUIRED 1194 caPubs OPTIONAL 1195 -- MAY be used 1196 -- If used it MUST contain only the root certificate of the 1197 -- certificate contained in certOrEncCert 1198 response REQUIRED 1199 -- MUST be exactly one CertResponse 1200 certReqId REQUIRED 1201 -- MUST be set to 0 1202 status REQUIRED 1203 -- PKIStatusInfo structure MUST be present 1204 status REQUIRED 1205 -- positive values allowed: "accepted", "grantedWithMods" 1206 -- negative values allowed: "rejection" 1207 -- In case of rejection certConf and pkiConf messages MUST NOT 1208 -- be sent 1209 statusString OPTIONAL 1210 -- MAY be any human-readable text for debugging, logging or to 1211 -- display in a GUI 1212 failInfo OPTIONAL 1213 -- MUST be present if status is "rejection" and in this case 1214 -- the transaction MUST be terminated 1215 -- MUST be absent if the status is "accepted" or 1216 -- "grantedWithMods" 1217 certifiedKeyPair OPTIONAL 1218 -- MUST be present if status is "accepted" or "grantedWithMods" 1219 -- MUST be absent if status is "rejection" 1220 certOrEncCert REQUIRED 1221 -- MUST be present when certifiedKeyPair is present 1222 certificate REQUIRED 1223 -- MUST be present when certifiedKeyPair is present 1224 -- MUST contain the newly enrolled X.509 certificate 1225 privateKey OPTIONAL 1226 -- MUST be absent in case of local key-generation 1227 -- MUST contain the encrypted private key in an EnvelopedData 1228 -- structure as specified in section 5.1.5 in case the private 1229 -- key was generated centrally 1231 protection REQUIRED 1232 -- As described in section 4.2 1234 extraCerts REQUIRED 1235 -- As described in section 4.3 1236 -- MUST contain the chain of the certificate present in 1237 -- certOrEncCert 1238 -- Duplicate certificates MAY be omitted 1240 Certificate Confirmation -- certConf 1242 Field Value 1244 header 1245 -- As described in section 4.1 1247 body 1248 -- The message of the EE sends confirmation to the PKI 1249 -- management entity to accept or reject the issued certificates 1250 certConf REQUIRED 1251 -- MUST be exactly one CertStatus 1252 CertStatus REQUIRED 1253 certHash REQUIRED 1254 -- MUST be the hash of the certificate, using the same hash 1255 -- algorithm as used to create the certificate signature 1256 certReqId REQUIRED 1257 -- MUST be set to 0 1258 status RECOMMENDED 1259 -- PKIStatusInfo structure SHOULD be present 1260 -- Omission indicates acceptance of the indicated certificate 1261 status REQUIRED 1262 -- positive values allowed: "accepted" 1263 -- negative values allowed: "rejection" 1264 statusString OPTIONAL 1265 -- MAY be any human-readable text for debugging, logging, or to 1266 -- display in a GUI 1267 failInfo OPTIONAL 1268 -- MUST be present if status is "rejection" 1269 -- MUST be absent if the status is "accepted" 1271 protection REQUIRED 1272 -- As described in section 4.2 1273 -- MUST use the same certificate as for protection of the ir 1275 extraCerts RECOMMENDED 1276 -- SHOULD contain the protection certificate together with its 1277 -- chain, but MAY be omitted if the message size is critical and 1278 -- the PKI management entity did cash the extraCerts from the ir 1279 -- If present, the first certificate in this field MUST be the 1280 -- certificate used for signing this message 1281 -- Self-signed certificates SHOULD NOT be included in 1282 -- extraCerts and 1283 -- MUST NOT be trusted based on the listing in extraCerts in 1284 -- any case 1286 PKI Confirmation -- pkiConf 1287 Field Value 1289 header 1290 -- As described in section 4.1 1292 body 1293 pkiConf REQUIRED 1294 -- The content of this field MUST be NULL 1296 protection REQUIRED 1297 -- As described in section 4.2 1298 -- SHOULD use the same certificate as for protection of the ip 1300 extraCerts RECOMMENDED 1301 -- SHOULD contain the protection certificate together with its 1302 -- chain, but MAY be omitted if the message size is critical and 1303 -- the PKI management entity did cash the extraCerts from the ip 1304 -- If present, the first certificate in this field MUST be the 1305 -- certificate used for signing this message 1306 -- Self-signed certificates SHOULD NOT be included in extraCerts 1307 -- and 1308 -- MUST NOT be trusted based on the listing in extraCerts in 1309 -- any case 1311 5.1.2. Request a certificate from a trusted PKI with signature 1312 protection 1314 < TBD: In case the PKI is already trusted the cr/cp messages could be 1315 used instead of ir/ip. It needs to be decided, whether an additional 1316 section should be added here, or the previous section should be 1317 extended to also cover this use case. > 1319 5.1.3. Update an existing certificate with signature protection 1321 This PKI management operation should be used by an EE to request an 1322 update of one of the certificates it already has and that is still 1323 valid. The EE uses the certificate it wishes to update to prove its 1324 identity and possession of the private key for the certificate to be 1325 updated to the PKI. Therefore, the key update request message is 1326 signed using the certificate that is to be updated. 1328 The general message flow for this PKI management operation is the 1329 same as given in Section 5.1.1. 1331 Preconditions: 1333 1 The certificate the EE wishes to update MUST NOT be expired or 1334 revoked. 1336 2 A new public-private key pair SHOULD be used. 1338 The message sequence for this PKI management operation is like that 1339 given in [RFC4210] Appendix D.6. 1341 The message sequence for this PKI management operation is identical 1342 to that given in Section 5.1.1, with the following changes: 1344 1 The body of the first request and response MUST be kur and kup, 1345 respectively. 1347 2 Protection of the kur MUST be performed using the certificate to 1348 be updated. 1350 3 The subject field of the CertTemplate MUST contain the subject 1351 name of the existing certificate to be updated, without 1352 modifications. 1354 4 The CertTemplate MUST contain the subject, issuer and publicKey 1355 fields only. 1357 5 The regCtrl OldCertId SHOULD be used to make clear, even in case 1358 an (L)RA changes the message protection, which certificate is to 1359 be updated. 1361 6 The caPubs field in the kup message MUST be absent. 1363 As part of the certReq structure of the kur the control is added 1364 right after the certTemplate. 1366 controls 1367 type RECOMMENDED 1368 -- MUST be the value id-regCtrl-oldCertID, if present 1369 value 1370 issuer REQUIRED 1371 serialNumber REQUIRED 1372 -- MUST contain the issuer and serialNumber of the certificate 1373 -- to be updated 1375 5.1.4. Request a certificate from a PKI with MAC protection 1377 This PKI management operation should be used by an EE to request a 1378 certificate of a new PKI without having a certificate to prove its 1379 identity to the target PKI, but there is a shared secret established 1380 between the EE and the PKI. Therefore, the initialization request is 1381 MAC-protected using this shared secret. The PKI management entity 1382 checking the MAC-protection SHOULD replace this protection according 1383 to Section 6.1.2 in case the next hop does not know the shared 1384 secret. 1386 For requirements with regard to proper random number and key 1387 generation please refer to [RFC4086]. 1389 The general message flow for this PKI management operation is the 1390 same as given in Section 5.1.1. 1392 Preconditions: 1394 1 The EE and the PKI management ectitiy MUST share a symmetric key, 1395 this MAY be established by a service technician during initial 1396 local configuration. 1398 2 The EE SHOULD know the subject name of the new CA it requests a 1399 certificate from; this name MAY be established using an enrollment 1400 voucher or other configuration means. If the EE does not know the 1401 name of the CA, the (L)RA/CA MUST know where to route this request 1402 to. 1404 3 The EE MUST authenticate responses from the PKI management entity; 1405 trust MAY be established using the shared symmetric key. 1407 The message sequence for this PKI management operation is like that 1408 given in [RFC4210] Appendix D.4. 1410 The message sequence for this PKI management operation is identical 1411 to that given in Section 5.1.1, with the following changes: 1413 1 The protection of all messages MUST be calculated using Message 1414 Authentication Code (MAC); the protectionAlg field MUST be id- 1415 PasswordBasedMac as described in section 5.1.3.1 of [RFC4210]. 1417 2 The sender MUST contain a name representing the originator of the 1418 message. The senderKID MUST contain a reference all participating 1419 entities can use to identify the symmetric key used for the 1420 protection. 1422 3 The extraCerts of the ir, certConf, and PKIConf messages MUST be 1423 absent. 1425 4 The extraCerts of the ip message MUST contain the chain of the 1426 issued certificate and root certificates SHOULD not be included 1427 and MUST NOT be directly trusted in any case. 1429 Part of the protectionAlg structure, where the algorithm identifier 1430 MUST be id-PasswordBasedMac, is a PBMParameter sequence. The fields 1431 of PBMParameter SHOULD remain constant for message protection 1432 throughout this PKI management operation to reduce the computational 1433 overhead. 1435 PBMParameter REQUIRED 1436 salt REQUIRED 1437 -- MUST be the random value to salt the secret key 1438 owf REQUIRED 1439 -- MUST be the algorithm identifier for the one-way function 1440 -- used 1441 -- The one-way function SHA-1 MUST be supported due to 1442 -- [RFC4211] requirements, but SHOULD NOT be used any more 1443 -- SHA-256 SHOULD be used instead 1444 iterationCount REQUIRED 1445 -- MUST be a limited number of times the one-way function is 1446 -- applied 1447 -- To prevent brute force and dictionary attacks a reasonable 1448 -- high number SHOULD be used 1449 mac REQUIRED 1450 -- MUST be the algorithm identifier of the MAC algorithm used 1451 -- The MAC function HMAC-SHA1 MUST be supported due to 1452 -- [RFC4211] requirements, but SHOULD NOT be used any more 1453 -- HMAC-SHA-256 SHOULD be used instead 1455 5.1.5. Request a certificate from a legacy PKI using PKCS#10 request 1457 This PKI management operation should be used by an EE to request a 1458 certificate of a legacy PKI only capable to process PKCS#10 [RFC2986] 1459 certification requests. The EE can prove its identity to the target 1460 PKI by using various protection means as described in Section 5.1.1 1461 or Section 5.1.4. 1463 In contrast to the other PKI management operations described in 1464 Section 5.1, this transaction uses PKCS#10 [RFC2986] instead of CRMF 1465 [RFC4211] for the certificate request for compatibility reasons with 1466 legacy CA systems that require a PKCS#10 certificate request and 1467 cannot process CRMF [RFC4211] requests. In such case the PKI 1468 management entity must extract the PKCS#10 certificate request from 1469 the p10cr and provides it separately to the CA. 1471 The general message flow for this PKI management operation is the 1472 same as given in Section 5.1.1, but the public key is contained in 1473 the subjectPKInfo of the PKCS#10 certificate request. 1475 Preconditions: 1477 1 The EE MUST either have a certificate enrolled from this or any 1478 other accepted PKI, or a shared secret known to the PKI and the EE 1479 to authenticate itself to the RA. 1481 2 The EE SHOULD know the subject name of the CA it requests a 1482 certificate from; this name MAY be established using an enrollment 1483 voucher or other configuration means. If the EE does not know the 1484 name of the CA, the RA MUST know where to route this request to. 1486 3 The EE MUST authenticate responses from the RA; trust MAY be 1487 established by an available root certificate, using an enrollment 1488 voucher, or other configuration means. 1490 4 The RA MUST trust the current or the PKI the EE uses to 1491 authenticate itself; trust MAY be established by a corresponding 1492 available root certificate or using some configuration means. 1494 The message sequence for this PKI management operation is identical 1495 to that given in Section 5.1.1, with the following changes: 1497 1 The body of the first request and response MUST be p10cr and cp, 1498 respectively. 1500 2 The subject name of the CA MUST be in the recipient field of the 1501 p10cr message header. 1503 3 The certReqId in the cp message MUST be 0. 1505 4 The caPubs field in the cp message SHOULD be absent. 1507 Detailed description of the p10cr message: 1509 Certification Request -- p10cr 1511 Field Value 1513 header 1514 -- As described in section 4.1 1516 body 1517 -- The request of the EE for a new certificate using a PKCS#10 1518 -- certificate request 1519 p10cr REQUIRED 1520 CertificationRequestInfo REQUIRED 1521 version REQUIRED 1522 -- MUST be set to 0 to indicate PKCS#10 V1.7 1523 subject REQUIRED 1524 -- MUST contain the suggested subject name of the EE 1525 subjectPKInfo REQUIRED 1526 algorithm REQUIRED 1527 -- MUST include the subject public key algorithm ID 1528 subjectPublicKey REQUIRED 1529 -- MUST include the subject public key algorithm value 1530 attributes OPTIONAL 1531 -- MAY contain a set of end-entity-specific attributes or X.509 1532 -- extensions to be included in the requested certificate or used 1533 -- otherwise 1534 signatureAlgorithm REQUIRED 1535 -- The signature algorithm MUST be consistent with the 1536 -- subjectPKInfo field. The hash algorithm used SHOULD be SHA-256 1537 signature REQUIRED 1538 -- MUST containing the self-signature for proof-of-possession 1540 protection REQUIRED 1541 -- As described in section 4.2 1543 extraCerts REQUIRED 1544 -- As described in section 4.3 1546 5.1.6. Generate the key pair centrally at the PKI management entity 1548 This functional extension can be applied in combination with 1549 certificate enrollment as described in Section 5.1.1 and 1550 Section 5.1.4. The functional extension can be used in case an EE is 1551 not able or is not willing to generate its new public-private key 1552 pair itself. It is a matter of the local implementation which PKI 1553 management entity will perform the key generation. This entity MUST 1554 have a certificate containing the additional extended key usage 1555 extension id-kp-cmcKGA to be identified by the EE as a legitimate 1556 key-generation authority. In case the PKI management entity 1557 generated the new key pair for the EE, it can use Section 5.1.1 to 1558 Section 5.1.4 to request the certificate for this key pair as usual. 1560 Generally speaking, in a machine-to-machine scenario it is strongly 1561 preferable to generate public-private key pairs locally at the EE. 1562 Together with proof-of-possession of the private key in the 1563 certification request, this is to make sure that only the entity 1564 identified in the newly issued certificate is the only entity who 1565 ever hold the private key. 1567 There are some cases where an EE is not able or not willing to 1568 locally generate the new key pair. Reasons for this may be the 1569 following: 1571 o Lack of sufficient initial entropy. 1573 Note: Good random numbers are not only needed for key generation, but 1574 also for session keys and nonces in any security protocol. 1575 Therefore, we believe that a decent security architecture should 1576 anyways support good random number generation on the EE side or 1577 provide enough entropy for the RNG seed during manufacturing to 1578 guarantee good initial pseudo-random number generation. 1580 o Due to lack of computational resources, e.g., in case of RSA keys. 1582 Note: As key generation can be performed in advance to the 1583 certificate enrollment communication, it is typical not time 1584 critical. 1586 Note: Besides the initial enrollment right after the very first 1587 bootup of the device, where entropy available on the device may be 1588 insufficient, we do not see any good reason for central key 1589 generation. 1591 Note: As mentioned in Section 3.1 central key generation may be 1592 required in a push model, where the certificate response message is 1593 transferred by the PKI management entity to the EE without receiving 1594 a previous request message. 1596 If the EE wishes to request central key generation, it MUST fill the 1597 subjectPublicKey field in the certTemplate structure of the request 1598 message with a zero-length BIT STRING. This indicates to the PKI 1599 management entity that a new key pair shall be generated centrally on 1600 behalf of the EE. 1602 Note: As the protection of centrally generated keys in the response 1603 message is being extended from EncryptedValue to EncryptedKey by CMP 1604 Updates [I-D.ietf-lamps-cmp-updates] also the alternative 1605 EnvelopedData can be used. In CRMF Section 2.1.9 [RFC4211] the use 1606 of EncryptedValue has been deprecated in favor of the EnvelopedData 1607 structure. Therefore, this profile specifies using EnvelopedData as 1608 specified in CMS Section 6 [RFC5652] to offer more crypto agility. 1610 +------------------------------+ 1611 | EnvelopedData | 1612 | [RFC5652] section 6 | 1613 | +--------------------------+ | 1614 | | SignedData | | 1615 | | [RFC5652] section 5 | | 1616 | | +----------------------+ | | 1617 | | | privateKey | | | 1618 | | | OCTET STRING | | | 1619 | | +----------------------+ | | 1620 | +--------------------------+ | 1621 +------------------------------+ 1623 Figure 3: Encrypted private key container 1625 The PKI management entity delivers the private key in the privateKey 1626 field in the certifiedKeyPair structure of the response message also 1627 containing the newly issued certificate. 1629 The private key MUST be wrapped in a SignedData structure, as 1630 specified in CMS Section 5 [RFC5652], signed by the KGA generating 1631 the key pair. The signature MUST be performed using a CMP signer 1632 certificate asserting the extended key usage kp-id-cmpKGA as 1633 described in CMP Updates [I-D.ietf-lamps-cmp-updates] to show the 1634 authorization to generate key pairs on behalf of an EE. 1636 This SignedData structure MUST be wrapped in an EnvelopedData 1637 structure, as specified in CMS Section 6 [RFC5652], encrypting it 1638 using a newly generated symmetric content-encryption key. 1640 Note: Instead of the specification in CMP Appendix D 4.4 [RFC4210] 1641 this content-encryption key is not generated on the EE side. As we 1642 just mentioned, central key generation should only be used in this 1643 profile in case of lack of randomness on the EE. 1645 As part of the EnvelopedData structure this content-encryption key 1646 MUST be securely provided to the EE using one of three key management 1647 techniques. The choice of the key management technique to be used by 1648 the PKI management entity depends on the authentication mechanism the 1649 EE choose to protect the request message, see CMP Updates section 3.4 1651 [I-D.ietf-lamps-cmp-updates] for more details on which key management 1652 technique to use. 1654 o MAC protected request message: The content-encryption key SHALL be 1655 protected using the symmetric key-encryption key management 1656 technique, see Section 5.1.6.1, only if the EE used MAC protection 1657 for the respected request message. 1659 o Signature protected request message using a certificate that 1660 contains a key usage extension asserting keyAgreement: The 1661 content-encryption key SHALL be protected using the key agreement 1662 key management technique, see Section 5.1.6.2, if the certificate 1663 used by the EE for signing the respective request message contains 1664 the key usage keyAgreement. If the certificate also contains the 1665 key usage keyEncipherment, the key transport key management 1666 technique SHALL NOT be used. 1668 o Signature protected request message using a certificate that 1669 contains a key usage extension asserting keyEncipherment: The 1670 content-encryption key SHALL be protected using the key transport 1671 key management technique, see Section 5.1.6.3, if the certificate 1672 used by the EE for signing the respective request message contains 1673 the key usage keyEncipherment and not keyAgreement. 1675 The key agreement key management technique can be supported by most 1676 signature algorithms, as key transport key management technique can 1677 only be supported by a very limited number of algorithms. The 1678 symmetric key-encryption key management technique shall only be used 1679 in combination with MAC protection, which is a side-line in this 1680 document. Therefore, if central key generation is supported, the 1681 support ofthe key agreement key management technique is REQUIRED and 1682 the support of key transport and symmetric key-encryption key 1683 management techniques are OPTIONAL. 1685 For encrypting the SignedData structure containing the private key a 1686 fresh content-encryption key MUST be generated with enough entropy 1687 with regard to the used symmetric encryption algorithm. 1689 Note: Depending on the lifetime of the certificate and the 1690 criticality of the generated private key, it is advisable to use the 1691 strongest available symmetric encryption algorithm. Therefore, this 1692 specification recommends using at least AES-256. 1694 The detailed description of the privateKey field looks like this: 1696 privateKey OPTIONAL 1697 -- MUST be an envelopedData structure as specified in 1698 -- CMS [RFC5652] section 6 1699 version REQUIRED 1700 -- MUST be set to 2 1701 recipientInfos REQUIRED 1702 -- MUST be exactly one RecipientInfo 1703 recipientInfo REQUIRED 1704 -- MUST be either KEKRecipientInfo (see section 5.1.5.1), 1705 -- KeyAgreeRecipientInfo (see section 5.1.5.2), or 1706 -- KeyTransRecipientInfo (see section 5.1.5.3) is used 1707 -- If central key generation is supported, support of 1708 -- KEKRecipientInfo is REQUIRED and support of 1709 -- KeyAgreeRecipientInfo and KeyTransRecipientInfo is OPTIONAL 1710 encryptedContentInfo 1711 REQUIRED 1712 contentType REQUIRED 1713 -- MUST be id-signedData 1714 contentEncryptionAlgorithm 1715 REQUIRED 1716 -- MUST be the algorithm identifier of the symmetric 1717 -- content-encryption algorithm used 1718 -- As private keys need long-term protection, the use of AES-256 1719 -- or a stronger symmetric algorithm is RECOMMENDED 1720 encryptedContent REQUIRED 1721 -- MUST be the encrypted signedData structure as specified in 1722 -- CMS [RFC5652] section 5 1723 version REQUIRED 1724 -- MUST be set to 3 1725 digestAlgorithms 1726 REQUIRED 1727 -- MUST be exactly one digestAlgorithm identifier 1728 digestAlgorithmIdentifier 1729 REQUIRED 1730 -- MUST be the OID of the digest algorithm used for generating 1731 -- the signature 1732 -- The hash algorithm used SHOULD be SHA-256 1733 encapContentInfo 1734 REQUIRED 1735 -- MUST be the content that is to be signed 1736 contentType REQUIRED 1737 -- MUST be id-data 1738 content REQUIRED 1739 -- MUST be the privateKey as OCTET STRING 1740 certificates REQUIRED 1741 -- SHOULD contain the certificate, for the private key used 1742 -- to sign the content, together with its chain 1743 -- If present, the first certificate in this field MUST 1744 -- be the certificate used for signing this content 1745 -- Self-signed certificates SHOULD NOT be included 1746 -- and MUST NOT be trusted based on the listing in any case 1747 crls OPTIONAL 1748 -- MAY be present to provide status information on the signer or 1749 -- its CA certificates 1750 signerInfos REQUIRED 1751 -- MUST be exactly one signerInfo 1752 version REQUIRED 1753 -- MUST be set to 3 1754 sid REQUIRED 1755 subjectKeyIdentifier 1756 REQUIRED 1757 -- MUST be the subjectKeyIdentifier of the signer's certificate 1758 digest algorithm 1759 REQUIRED 1760 -- MUST be the same OID as in digest algorithm 1761 signatureAlgorithm 1762 REQUIRED 1763 -- MUST be the algorithm identifier of the signature algorithm 1764 -- used for calculation of the signature bits, 1765 -- like sha256WithRSAEncryption or ecdsa-with-SHA256 1766 -- The signature algorithm MUST be consistent with the 1767 -- SubjectPublicKeyInfo field of the signer's certificate 1768 signature REQUIRED 1769 -- MUST be the result of the digital signature generation 1771 5.1.6.1. Using symmetric key-encryption key management technique 1773 This key management technique can be applied in combination with the 1774 PKI management operation specified in Section 5.1.4 using MAC 1775 protected CMP messages. The shared secret used for the MAC 1776 protection MUST also be used for the encryption of the content- 1777 encryption key but with a different seed in the PBMParameter 1778 sequence. To use this key management technique the KEKRecipientInfo 1779 structure MUST be used in the contentInfo field. 1781 The KEKRecipientInfo structure included into the envelopedData 1782 structure is specified in CMS Section 6.2.3 [RFC5652]. 1784 The detailed description of the KEKRecipientInfo structure looks like 1785 this: 1787 recipientInfo REQUIRED 1788 -- MUST be KEKRecipientInfo as specified in 1789 -- CMS section 6.2.3 [RFC5652] 1790 version REQUIRED 1791 -- MUST be set to 4 1792 kekid REQUIRED 1793 keyIdentifier REQUIRED 1794 -- MUST contain the same value as the senderKID in the respective 1795 -- request messages 1796 keyEncryptionAlgorithm 1797 REQUIRED 1798 -- MUST be id-PasswordBasedMac 1799 PBMParameter REQUIRED 1800 salt REQUIRED 1801 -- MUST be the random value to salt the secret key 1802 -- MUST be a different value than used in the PBMParameter 1803 -- data structure of the CMP message protection in the 1804 -- header of this message 1805 owf REQUIRED 1806 -- MUST be the same value than used in the PBMParameter 1807 -- data structure in the header of this message 1808 iterationCount 1809 REQUIRED 1810 -- MUST be a limited number of times the OWF is applied 1811 -- To prevent brute force and dictionary attacks a reasonable 1812 -- high number SHOULD be used 1813 mac REQUIRED 1814 -- MUST be the same as in the contentEncryptionAlgorithm field 1815 encryptedKey REQUIRED 1816 -- MUST be the encrypted content-encryption key 1818 < TBD: To make use of a different symmetric keys for encrypting the 1819 private key and for MAC-protection of the CMP message, we derive 1820 another key using the same PBMParameter structure from CMP, even 1821 though from the perspective of field names, it is not intended to be 1822 used for deriving encryption keys. Does anyone sees a better 1823 solution here? > 1825 5.1.6.2. Using key agreement key management technique 1827 This key management technique can be applied in combination with the 1828 PKI management operations specified in Section 5.1.1 to Section 5.1.3 1829 using signature-based protected CMP messages. The public key of the 1830 EE certificate used for the signature-based protection of the request 1831 message MUST also be used for the Ephemeral-Static Diffie-Hellmann 1832 key establishment of the content-encryption key. To use this key 1833 management technique the KeyAgreeRecipientInfo structure MUST be used 1834 in the contentInfo field. 1836 The KeyAgreeRecipientInfo structure included into the envelopedData 1837 structure is specified in CMS Section 6.2.2 [RFC5652]. 1839 The detailed description of the KeyAgreeRecipientInfo structure looks 1840 like this: 1842 recipientInfo REQUIRED 1843 -- MUST be KeyAgreeRecipientInfo as specified in 1844 version REQUIRED 1845 -- MUST be set to 3 1846 originator REQUIRED 1847 -- MUST contain the originatorKey sequence 1848 algorithm REQUIRED 1849 -- MUST be the algorithm identifier of the 1850 -- static-ephemeral Diffie-Hellmann algorithm 1851 publicKey REQUIRED 1852 -- MUST be the ephemeral public key of the sending party 1853 ukm OPTIONAL 1854 -- MUST be used when 1-pass ECMQV is used 1855 keyEncryptionAlgorithm 1856 REQUIRED 1857 -- MUST be the same as in the contentEncryptionAlgorithm field 1858 recipientEncryptedKeys 1859 REQUIRED 1860 -- MUST be exactly one recipientEncryptedKey sequence 1861 recipientEncryptedKey 1862 REQUIRED 1863 rid REQUIRED 1864 rKeyId REQUIRED 1865 subjectKeyID 1866 REQUIRED 1867 -- MUST contain the same value as the senderKID in the 1868 -- respective request messages 1869 encryptedKey 1870 REQUIRED 1871 -- MUST be the encrypted content-encryption key 1873 5.1.6.3. Using key transport key management technique 1875 This key management technique can be applied in combination with the 1876 PKI management operations specified in Section 5.1.1 to Section 5.1.3 1877 using signature-based protected CMP messages. The public key of the 1878 EE certificate used for the signature-based protection of the request 1879 message MUST also be used for key encipherment of the content- 1880 encryption key. To use this key management technique the 1881 KeyTransRecipientInfo structure MUST be used in the contentInfo 1882 field. 1884 The KeyTransRecipientInfo structure included into the envelopedData 1885 structure is specified in CMS Section 6.2.1 [RFC5652]. 1887 The detailed description of the KeyTransRecipientInfo structure looks 1888 like this: 1890 recipientInfo REQUIRED 1891 -- MUST be KeyTransRecipientInfo as specified in 1892 -- CMS section 6.2.1 [RFC5652] 1893 version REQUIRED 1894 -- MUST be set to 2 1895 rid REQUIRED 1896 subjectKeyIdentifier 1897 REQUIRED 1898 -- MUST contain the same value as the senderKID in the respective 1899 -- request messages 1900 keyEncryptionAlgorithm 1901 REQUIRED 1902 -- MUST contain the key encryption algorithm identifier used for 1903 -- public key encryption 1904 encryptedKey REQUIRED 1905 -- MUST be the encrypted content-encryption key 1907 5.1.7. Delayed enrollment 1909 This functional extension can be applied in combination with 1910 certificate enrollment as described in Section 5.1.1 to 1911 Section 5.1.5. The functional extension can be used in case a PKI 1912 management entity cannot respond to the certificate request in a 1913 timely manner, e.g., due to offline upstream communication or 1914 required registration officer interaction. Depending on the PKI 1915 architecture, it is not necessary that the PKI management entity 1916 directly communicating with the EE initiates the delayed enrollment. 1918 The PKI management entity initiating the delayed enrollment MUST 1919 include the status "waiting" in the response and this response MUST 1920 NOT contain a newly issued certificate. When receiving a response 1921 with status "waiting" the EE MUST send a poll request to the PKI 1922 management entity. The PKI management entity that initiated the 1923 delayed enrollment MUST answers with a poll response containing a 1924 checkAfter time. This value indicates the minimum number of seconds 1925 that must elapse before the EE sends another poll request. As soon 1926 as the PKI management entity can provide the final response message 1927 for the initial request of the EE, it MUST provide this in response 1928 to a poll request. After receiving this response, the EE can 1929 continue the original PKI management operation as described in the 1930 respective section of this document, e.g., send a certConf message. 1932 Typically, intermediate PKI management entities SHOULD NOT change the 1933 sender and recipient nonce even in case an intermediate PKI 1934 management entity modifies a request or a response message. In the 1935 special case of polling between EE and LRA with offline transport 1936 between an LRA and RA, see Section 6.1.4, an exception occurs. The 1937 EE and LRA exchange pollReq and pollRep messages handle the nonce 1938 words as described. When, after pollRep, the final response from the 1939 CA arrives at the LRA, the next response will contain the 1940 recipientNonce set to the value of the senderNonce in the original 1941 request message (copied by the CA). The LRA needs to replace the 1942 recipientNonce in this case with the senderNonce of the last pollReq 1943 because the EE will validate it in this way. 1945 Message flow: 1947 Step# EE PKI management entity 1948 1 format ir/cr/p10cr/kur 1949 As described in the 1950 respective section 1951 in this document 1952 2 ->ir/cr/p10cr/kur-> 1953 3 handle request as described 1954 in the respective section 1955 in this document 1956 4 in case no immediate final 1957 response is possible, 1958 receive or format ip, cp 1959 or kup message containing 1960 status "waiting" 1961 5 <- ip/cp/kup <- 1962 6 handle ip/cp/kup 1963 7 format pollReq 1964 8 -> pollReq -> 1965 9 handle, re-protect or 1966 forward pollReq 1967 10 in case the requested 1968 certificate or a 1969 corresponding response 1970 message is available, 1971 receive or format ip, cp, 1972 or kup containing the 1973 issued certificate, or 1974 format or receive pollRep 1975 with appropriate 1976 checkAfter value 1977 11 <- pollRep <- 1978 12 handle pollRep 1979 13 let checkAfter 1980 time elapse 1981 14 continue with line 7 1983 Detailed description of the first ip/cp/kup: 1985 Response with status 'waiting' -- ip/cp/kup 1987 Field Value 1989 header 1990 -- MUST contain a header as described for the first response 1991 -- message of the respective PKI management operation 1993 body 1994 -- The response of the PKI management entity to the request in 1995 -- case no immediate appropriate response can be sent 1996 ip/cp/kup REQUIRED 1997 response REQUIRED 1998 -- MUST be exactly one CertResponse 1999 certReqId REQUIRED 2000 -- MUST be set to 0 2001 status REQUIRED 2002 -- PKIStatusInfo structure MUST be present 2003 status REQUIRED 2004 -- MUST be set to "waiting" 2005 statusString OPTIONAL 2006 -- MAY be any human-readable text for debugging, logging or to 2007 -- display in a GUI 2008 failInfo PROHIBITED 2009 certifiedKeyPair PROHIBITED 2011 protection REQUIRED 2012 -- MUST contain protection as described for the first response 2013 -- message of the respective PKI management operation, but 2014 -- MUST use the protection key of the PKI management entity 2015 -- initiating the delayed enrollment and creating this response 2016 -- message 2018 extraCerts REQUIRED 2019 -- MUST contain certificates as described for the first response 2020 -- message of the respective PKI management operation. 2021 -- As no new certificate is issued yet, no respective certificate 2022 -- chain is included 2024 Polling Request -- pollReq 2026 Field Value 2028 header 2029 -- MUST contain a header as described for the certConf message 2030 -- of the respective PKI management operation 2032 body 2033 -- The message of the EE asks for the final response or for a 2034 -- time to check again 2035 pollReq REQUIRED 2036 certReqId REQUIRED 2037 -- MUST be exactly one value 2038 -- MUST be set to 0 2040 protection REQUIRED 2041 -- MUST contain protection as described for the certConf message 2042 -- of the respective PKI management operation 2044 extraCerts OPTIONAL 2045 -- If present, it MUST contain certificates as described for the 2046 -- certConf message of the respective PKI management operation 2048 Polling Response -- pollRep 2050 Field Value 2052 header 2053 -- MUST contain a header as described for the pkiConf message 2054 -- of the respective PKI management operation 2056 body pollRep 2057 -- The message indicated the time to after which the EE may 2058 -- send another pollReq messaged for this transaction 2059 pollRep REQUIRED 2060 -- MUST be exactly one set of the following values 2061 certReqId REQUIRED 2062 -- MUST be set to 0 2063 checkAfter REQUIRED 2064 -- time in seconds to elapse before a new pollReq may be sent by 2065 -- the EE 2067 protection REQUIRED 2068 -- MUST contain protection as described for the pkiConf message 2069 -- of the respective profile, but 2070 -- MUST use the protection key of the PKI management entity that 2071 -- initiated the delayed enrollment and is creating this response 2072 -- message 2074 extraCerts OPTIONAL 2075 -- If present, it MUST contain certificates as described for the 2076 -- pkiConf message of the respective PKI management operation. 2078 Final response -- ip/cp/kup 2080 Field Value 2082 header 2083 -- MUST contain a header as described for the first 2084 -- response message of the respective PKI management operation, 2085 -- but the recipientNonce MUST be the senderNonce of the last 2086 -- pollReq message 2088 body 2089 -- The response of the PKI management entity to the initial 2090 -- request as described in the respective PKI management 2091 -- operation 2093 protection REQUIRED 2094 -- MUST contain protection as described for the first response 2095 -- message of the respective PKI management operation, but 2096 -- MUST use the protection key of the PKI management entity that 2097 -- initiated the delayed enrollment and forwarding the response 2098 -- message 2100 extraCerts REQUIRED 2101 -- MUST contain certificates as described for the first 2102 -- response message of the respective PKI management operation 2104 5.2. Revoking a certificate 2106 This PKI management operation should be used by an entity to request 2107 the revocation of a certificate. Here the revocation request is used 2108 by an EE to revoke one of its own certificates. A PKI management 2109 entity could also act as an EE to revoke one of its own certificates. 2111 The revocation request message MUST be signed using the certificate 2112 that is to be revoked to prove the authorization to revoke to the 2113 PKI. The revocation request message is signature-protected using 2114 this certificate. 2116 An EE requests the revocation of an own certificate at the CA that 2117 issued this certificate. The PKI management entity responds with a 2118 message that contains the status of the revocation from the CA. 2120 Preconditions: 2122 1 The certificate the EE wishes to revoke is not yet expired or 2123 revoked. 2125 Message flow: 2127 Step# EE PKI management entity 2128 1 format rr 2129 2 -> rr -> 2130 3 handle, re-protect or 2131 forward rr 2132 4 receive rp 2133 5 <- rp <- 2134 6 handle rp 2136 For this PKI management operation, the EE MUST include exactly one 2137 RevDetails structure in the rr message body. In case no error 2138 occurred the response to the rr MUST be an rp message. The PKI 2139 management entity MUST produce a rp containing a status field with a 2140 single set of values. 2142 Detailed message description: 2144 Revocation Request -- rr 2146 Field Value 2148 header 2149 -- As described in section 4.1 2151 body 2152 -- The request of the EE to revoke its certificate 2153 rr REQUIRED 2154 -- MUST contain exactly one element of type RevDetails 2155 -- If more revocations are desired, further requests MUST be 2156 -- packaged in separate PKI Messages 2157 certDetails REQUIRED 2158 -- MUST be present and is of type CertTemplate 2159 serialNumber REQUIRED 2160 -- MUST contain the certificate serialNumber attribute of the 2161 -- X.509 certificate to be revoked 2162 issuer REQUIRED 2163 -- MUST contain the issuer attribute of the X.509 certificate to 2164 -- be revoked 2165 crlEntryDetails REQUIRED 2166 -- MUST contain exactly one reasonCode of type CRLReason (see 2167 -- [RFC5280] section 5.3.1) 2168 -- If the reason for this revocation is not known or shall not be 2169 -- published the reasonCode MUST be 0 = unspecified 2171 protection REQUIRED 2172 -- As described in section 4.2 and the private key related to the 2173 -- certificate to be revoked 2175 extraCerts REQUIRED 2176 -- As described in section 4.3 2178 Revocation Response -- rp 2180 Field Value 2182 header 2183 -- As described in section 4.1 2185 body 2186 -- The responds of the PKI management entity to the request as 2187 -- appropriate 2188 rp REQUIRED 2189 status REQUIRED 2190 -- MUST contain exactly one element of type PKIStatusInfo 2191 status REQUIRED 2192 -- positive value allowed: "accepted" 2193 -- negative value allowed: "rejection" 2194 statusString OPTIONAL 2195 -- MAY be any human-readable text for debugging, logging or to 2196 -- display in a GUI 2197 failInfo OPTIONAL 2198 -- MAY be present if and only if status is "rejection" 2200 protection REQUIRED 2201 -- As described in section 4.2 2203 extraCerts REQUIRED 2204 -- As described in section 4.3 2206 5.3. Error reporting 2208 This functionality should be used by an EE to report any error 2209 conditions upstream to the PKI management entity. Error reporting by 2210 a PKI management entity downstream to the EE is described in 2211 Section 6.3. 2213 In case the error condition is related to specific details of an ip, 2214 cp, or kup response message and a confirmation is expected the error 2215 condition MUST be reported in the respective certConf message with 2216 negative contents. 2218 General error conditions, e.g., problems with the message header, 2219 protection, or extraCerts, and negative feedback on rp, pollRep, or 2220 pkiConf messages MAY be reported in the form of an error message. 2222 In both situations the EE reports error in the PKIStatusInfo 2223 structure of the respective message. 2225 Depending on the PKI architecture, the PKI management entity MUST 2226 forward the error message (upstream) to the next PKI management 2227 entity and MUST terminate this PKI management operation. 2229 The PKIStatusInfo structure is used to report errors. The 2230 PKIStatusInfo structure SHOULD consist of the following fields: 2232 o status: Here the PKIStatus value "rejection" is the only one 2233 allowed. 2235 o statusString: Here any human-readable valid value for logging or 2236 to display in a GUI SHOULD be added. 2238 o failInfo: Here the PKIFailureInfo values MAY be used in the 2239 following way. For explanation of the reason behind a specific 2240 value, please refer to [RFC4210] Appendix F. 2242 * transactionIdInUse: This is sent by a PKI management entity in 2243 case the received request contains a transaction ID that is 2244 already in use for another transaction. An EE receiving such 2245 error message SHOULD resend the request in a new transaction 2246 using a different transaction ID. 2248 * systemUnavail or systemFailure: This is sent by a PKI 2249 management entity in case a back-end system is not available or 2250 currently not functioning correctly. An EE receiving such 2251 error message SHOULD resend the request in a new transaction 2252 after some time. 2254 Detailed error message description: 2256 Error Message -- error 2258 Field Value 2260 header 2261 -- As described in section 4.1 2263 body 2264 -- The message sent by the EE or the (L)RA/CA to indicate an 2265 -- error that occurred 2266 error REQUIRED 2267 pKIStatusInfo REQUIRED 2268 status REQUIRED 2269 -- MUST have the value "rejection" 2270 statusString RECOMMENDED 2271 -- SHOULD be any human-readable text for debugging, logging 2272 -- or to display in a GUI 2273 failInfo OPTIONAL 2274 -- MAY be present 2276 protection REQUIRED 2277 -- As described in section 4.2 2279 extraCerts OPTIONAL 2280 -- As described in section 4.3 2282 5.4. Support messages 2284 The following support messages offer on demand in-band transport of 2285 content that may be provided by the PKI management entity and 2286 relevant to the EE. The general messages and general response are 2287 used for this purpose. Depending on the environment, these requests 2288 may be answered by the LRA, RA, or CA. 2290 The general message and general response transport InfoTypeAndValue 2291 structures. In addition to those infoType values defined in CMP 2292 [RFC4210] further OIDs MAY be defined to define new PKI management 2293 operations, or general-purpose messages as needed in a specific 2294 environment. 2296 Possible content described here address: 2298 o Request of CA certificates 2300 o Update of Root CA certificates 2301 o Parameters needed for a planned certificate request message 2303 o Voucher request and enrollment voucher exchange 2305 5.4.1. General message and response 2307 The PKI management operation is similar to that given in CMP 2308 Appendix E.5 [RFC4210]. In this section the general message (genm) 2309 and general response (genp) are described. The specific 2310 InfoTypeAndValue structures are described in the following sections. 2312 The behavior in case an error occurs is described in Section 5.3. 2314 Message flow: 2316 Step# EE PKI management entity 2317 1 format genm 2318 2 -> genm -> 2319 3 handle, re-protect or 2320 forward genm 2321 4 format or receive genp 2322 5 <- genp <- 2323 6 handle genp 2325 Detailed message description: 2327 General Message -- genm 2329 Field Value 2331 header 2332 -- As described in section 4.1 2334 body 2335 -- The request of the EE to receive information 2336 genm REQUIRED 2337 -- MUST contain exactly one element of type 2338 -- InfoTypeAndValue 2339 infoType REQUIRED 2340 -- MUST be the OID identifying the specific PKI 2341 -- management operation described below 2342 infoValue OPTIONAL 2343 -- MUST be as described in the specific PKI 2344 -- management operation described below 2346 protection REQUIRED 2347 -- As described in section 4.2 2349 extraCerts REQUIRED 2350 -- As described in section 4.3 2352 General Response -- genp 2354 Field Value 2356 header 2357 -- As described in section 4.1 2359 body 2360 -- The response of the PKI management entity to the 2361 -- information request 2362 genp REQUIRED 2363 -- MUST contain exactly one element of type 2364 -- InfoTypeAndValue 2365 infoType REQUIRED 2366 -- MUST be the OID identifying the specific PKI 2367 -- management operationdescribed below 2368 infoValue OPTIONAL 2369 -- MUST be as described in the specific PKI 2370 -- management operation described below 2372 protection REQUIRED 2373 -- As described in section 4.2 2375 extraCerts REQUIRED 2376 -- As described in section 4.3 2378 5.4.2. Get CA certificates 2380 This PKI management operation can be used by an EE to request CA 2381 certificates from the PKI management entity. 2383 An EE requests CA certificates from the PKI management entity by 2384 sending a general message with OID id-it-getCaCerts. The PKI 2385 management entity responds with a general response with the same OID 2386 that either contains a SEQUENCE of certificates populated with the 2387 available CA intermediate and issuing CA certificates or with no 2388 content in case no CA certificate is available. 2390 < NOTE: The OID id-it-getCaCerts is not yet defined. It should be 2391 registered in the tree 1.3.6.1.5.5.7.4 (id-it) like other infoType 2392 OIDs, see CMP Appendix F [RFC4210] on page 92. > 2394 The message sequence for this PKI management operation is as given in 2395 Section 5.4.1, with the following specific content: 2397 1 the body MUST contain as infoType the OID id-it-getCaCerts 2399 2 the infoValue of the request MUST be absent 2401 3 if present, the infoValue of the response MUST be caCerts field 2403 The infoValue field of the general response containing the id-it- 2404 getCaCerts OID looks like this: 2406 infoValue OPTIONAL 2407 -- MUST be absent if no CA certificate is available 2408 -- MUST be present if CA certificates are available 2409 caCerts REQUIRED 2410 -- MUST be present if infoValue is present 2411 -- MUST be a sequence of CMPCertificate 2413 5.4.3. Get root CA certificate update 2415 This PKI management operation can be used by an EE to request an 2416 update of an existing root CA Certificate by the EE. It utilizes the 2417 CAKeyUpdAnnContent structure as described in CMP Appendix E.4 2418 [RFC4210] as response to a respective general message. 2420 An EE requests a root CA certificate update from the PKI management 2421 entity by sending a general message with OID id-it-caKeyUpdateInfo as 2422 infoType and no infoValue. The PKI management entity responds with a 2423 general response with the same OID that either contains the update of 2424 the root CA certificate consisting of up to three certificates, or 2425 with no content in case no update is available. 2427 These three certificates are described in more detail in section 2428 4.4.1, section 6.2, and Appendix E.3 of [RFC4210]. The newWithNew 2429 certificate is the new root CA certificates and is REQUIRED to be 2430 present in the response message. The newWithOld certificate is 2431 RECOMMENDED to be present in the response message though it is 2432 REQUIRED for those cases where the receiving entity trusts the old 2433 root CA certificate and whishes to gain trust in the new root CA 2434 certificate. The oldWithNew certificate is OPTIONAL though it is 2435 only needed in a scenario where the requesting entity already trusts 2436 the new root CA certificate and wants to gain trust in the old root 2437 certificate. 2439 The message sequence for this PKI management operation is as given in 2440 Section 5.4.1, with the following specific content: 2442 1 the body MUST contain as infoType the OID id-it-caKeyUpdateInfo 2444 2 the infoValue of the request MUST be absent 2445 3 if present, the infoValue of the response MUST be a 2446 CAKeyUpdAnnContent structure 2448 The infoValue field of the general response containing the id-it- 2449 caKeyUpdateInfo extension looks like this: 2451 infoValue OPTIONAL 2452 -- MUST be absent if no update of the root CA certificate is 2453 available 2454 -- MUST be present if an update of the root CA certificate 2455 -- is available 2456 caKeyUpdateInfo REQUIRED 2457 -- MUST be present and be of type CAKeyUpdAnnContent 2458 oldWithNew OPTIONAL 2459 -- MAY be present if infoValue is present 2460 -- MUST contain an X.509 certificate containing the old public 2461 -- root CA key signed with the new private root CA key 2462 newWithOld RECOMMENDED 2463 -- SHOULD be present if infoValue is present 2464 -- MUST contain an X.509 certificate containing the new public 2465 -- root CA key signed with the old private root CA key 2466 newWithNew REQUIRED 2467 -- MUST be present if infoValue is present 2468 -- MUST contain the new root CA certificate 2470 < TBD: To reduce unnecessary overhead by including not needed 2471 certificates, we intend to require only to incert the newWithNew 2472 certificate in the caKeyUpdateInfo structure and optionally omit the 2473 oldWithNew and newWithOld certificates. This is in conflict with 2474 [RFC4210] where also oldWithNew and newWithOld are required fields in 2475 caKeyUpdateInfo. Is there any possiblility to optionally leave these 2476 filds empty and still reuse the caKeyUpdateInfo structure as 2477 specified in [RFC4210]? > 2479 5.4.4. Get certificate request parameters 2481 This PKI management operation can be used by an EE to request 2482 configuration parameters for a planned certificate request operation. 2484 An EE requests for a planned certificate request parameters from the 2485 PKI management entity by sending a general message with OID id-it- 2486 getCSRParam. The PKI management entity responds with a general 2487 response with the same OID that either contains the required fields, 2488 e.g., algorithm identifier for key pair generation or other 2489 attributes and extensions or with no content in case no specific 2490 requirements are made by the PKI. 2492 < NOTE: The OID id-it-getCSRParam is not yet defined. It should be 2493 registered in the tree 1.3.6.1.5.5.7.4 (id-it) like other infoType 2494 OIDs, see CMP Appendix F [RFC4210] on page 92. > 2496 The EE SHOULD follow the requirements from the recieved CertTemplate 2497 and the optional RSA key length. In case a field is present but the 2498 value is absent or NULL, it means that this field is required but its 2499 content has to be provided by the EE. 2501 < TBD: There is some more explanation needed to explain how to 2502 prefill the certTemplate structure. Possibly an example will help to 2503 clarify this. > 2505 The message sequence for this PKI management operation is as given in 2506 Section 5.4.1, with the following specific content: 2508 1 the body MUST contain as infoType the OID id-it-getCSRParam 2510 2 the infoValue of the request MUST be absent 2512 3 if present, the infoValue of the response MUST be a SEQUENCE of a 2513 certTemplate structure and an rsaKeyLen field of type INTEGER 2515 The infoValue field of the general response containing the id-it- 2516 getCSRParam OID looks like this: 2518 infoValue OPTIONAL 2519 -- MUST be absent if no requirements are available 2520 -- MUST be present if the PKI management entity has any 2521 -- requirements on the content of the certificates to be 2522 -- requested 2523 certTemplate REQUIRED 2524 -- MUST be present if infoValue is present 2525 -- MUST contain the prefilled certTemplate structure 2526 rsaKeyLen OPTIONAL 2527 -- This field is of type INTEGER. Any reasonable RSA key length 2528 -- SHOULD be specified if the algorithm in the 2529 -- subjectPublicKeyInfo field of the certTemplate is of type 2530 -- rsaEncryption. 2532 < TBD: To offer a set of allowed key lenths, the rsaKeyLen field 2533 could also be specified as a SEQUENCE OF INTEGER. > 2535 5.4.5. Get certificate management configuration 2537 This PKI management operation can be used by an EE to request the 2538 current certificate management configuration information by the EE in 2539 advance to a planned PKI management operation, e.g., in case no out- 2540 of-band transport is available. Such certificate management 2541 configuration can consist of all information the EE needs to know to 2542 generate and deliver a proper certificate request, such as 2544 o algorithm, curve, and key length for key generation 2546 o various certificate attributes and extensions to be used for the 2547 certificate request 2549 o specific host name, port and path on the RA/LRA to send this CMP 2550 request to 2552 o Infrastructure Root CA Certificate, e.g., the root of the (L)RA 2553 TLS and CMP signer certificates. 2555 There is an overlap with Section 5.4.2 regarding transport of CA 2556 certificates and with Section 5.4.4 regarding key generation 2557 parameter and certificate request attributes and extensions. This 2558 profile offers to request a proprietary configuration file containing 2559 all information needed in one exchange. 2561 < TBD: Especially with section 5.4.4 there is some overlap regarding 2562 algorithms, attributes and, extensions of the certificate that will 2563 be requested. It needs to be decided if both variants have a right 2564 to exist next to each other or if one option should be removed from 2565 this document. > 2567 An EE requests certificate management configuration from the PKI 2568 management entity by sending a general message with the OID id-it- 2569 getCertMgtConfig. The PKI management entity responds with a general 2570 response with the same OID that either contains a certMgtConfig field 2571 containing the configuration file encoded as OCTET STRING or with no 2572 content in case no certificate management configuration is available. 2574 < NOTE: The OID id-it-getCertMgtConfig is not yet defined. It should 2575 be registered in the tree 1.3.6.1.5.5.7.4 (id-it) like other infoType 2576 OIDs, see CMP Appendix F [RFC4210] on page 92. > 2578 The EE SHOULD use the contents of this certMgtConfig to format and 2579 deliver the certificate request. The certificate management 2580 configuration may contain contact details, e.g., like an URI and 2581 issuing CA distinguished name, where to address the request messages 2582 to and may also contain certificate request parameters as described 2583 in Section 5.4.4. 2585 The certMgtConfig field may be of any format suitable for the EE, 2586 e.g., JWT [RFC7519] or XML [W3C_XML]. The certMgtConfig contents MAY 2587 be signed, e.g., like CMS SignedData [RFC5652], JWS [RFC7515] or, 2588 XML-DSig [W3C_XML-Dsig]. For interoperability the format of the 2589 certMgtConfig field should be specified in detail if needed. 2591 The message sequence for this PKI management operation is as given in 2592 Section 5.4.1, with the following specific content: 2594 1 the body MUST contain as infoType the OID id-it-getCertMgtConfig 2596 2 the infoValue of the request MUST be absent 2598 3 if present, the infoValue of the response MUST be a certMgtConfig 2599 structure 2601 The infoValue field of the general response containing the id-it- 2602 getCertMgtConfig extension looks like this: 2604 infoValue OPTIONAL 2605 -- MUST be absent if no certificate management configuration 2606 -- is available 2607 -- MUST be present if the PKI management entity provides any 2608 -- certificate management configuration 2609 certMgtConfig REQUIRED 2610 -- MUST be present if infoValue is present 2611 -- MUST contain the certificate management configuration as OCTET 2612 -- OCTET STRING 2614 5.4.6. Get enrollment voucher 2616 This PKI management operation can be used by an EE to request an 2617 enrollment voucher containing the root certificate of a new, 2618 additional, or alternative PKI to establish trust in this PKI, e.g., 2619 in case no out-of-band transport is available. Such an enrollment 2620 voucher can be used in advance to an enrollment to this new 2621 environment. 2623 An EE requests an enrollment voucher from the PKI management entity 2624 by sending a general message. The PKI management entity responds 2625 with a general response with the same OID that either contains the 2626 voucher or with no content in case no voucher is available. 2628 The PKI management entity MAY use the content of the voucherRequest 2629 to get an enrollment voucher from other backend components, e.g., as 2630 described in BRSKI [I-D.ietf-anima-bootstrapping-keyinfra]. The EE 2631 SHOULD use the contents of the received enrollmentVoucher to 2632 authenticate the PKI management entity it is about to enroll to. The 2633 enrollment voucher may for example contain the Root CA certificate of 2634 the new PKI or the CMP signer certificate of the PKI management 2635 entity. The general response message MUST be properly authenticated 2636 and the EE MUST verify the authorization of the sender to install new 2637 root certificates. One example for an enrollment voucher is 2638 specified in RFC8366 [RFC8366]. 2640 The voucherRequest and enrollmentVoucher fields may be of any format 2641 suitable for the EE, e.g., JWT [RFC7519] or XML [W3C_XML]. The 2642 voucherRequest and enrollmentVoucher contents MAY contain a 2643 signature, e.g., CMS SignedData [RFC5652], JWS [RFC7515] or, XML-DSig 2644 [W3C_XML-Dsig]. For interoperability the format of the 2645 voucherRequest and enrollmentVoucher field schould be specified in 2646 detail if needed, e.g., as defined in BRSKI 2647 [I-D.ietf-anima-bootstrapping-keyinfra] and RFC8366 [RFC8366]. 2649 < TBD: The vontent of the voucherRequest and enrollmentVoucher fields 2650 can also be linited to the specifications in BRSKI 2651 [I-D.ietf-anima-bootstrapping-keyinfra] and RFC8366 [RFC8366]. > 2653 The message sequence for this PKI management operation is as given in 2654 Section 5.4.1, with the following specific content: 2656 1 the body MUST contain as infoType the OID id-it- 2657 getEnrollmentVoucher 2659 2 if present, the infoValue of the request MUST be a voucherRequest 2660 structure 2662 3 if present, the infoValue of the response MUST be an 2663 enrollmentVoucher structure 2665 The infoValue field of the general message containing the id-it- 2666 getEnrollmentVoucher extension looks like this: 2668 infoValue OPTIONAL 2669 -- MUST be absent if no voucher request is available 2670 -- MUST be present if the EE provides the voucher request 2671 voucherRequest REQUIRED 2672 -- MUST be present if infoValue is present 2673 -- MUST contain the voucher request as OCTET STRING 2675 The infoValue field of the general response containing the id-it- 2676 getEnrollmentVoucher extension looks like this: 2678 infoValue OPTIONAL 2679 -- MUST be absent if no enrollment voucher is available 2680 -- MUST be present if the PKI management entity provides 2681 -- the enrollment voucher 2682 enrollmentVoucher REQUIRED 2683 -- MUST be present if infoValue is present 2684 -- MUST contain the enrollment voucher as OCTET STRING 2686 6. LRA and RA focused PKI management operations 2688 This chapter focuses on the communication among different PKI 2689 management entities. Depending on the network and PKI solution 2690 design, these will either be an LRA, RA or CA. 2692 Typically, a PKI management entity forwards messages from downstream, 2693 but it may also reply to them itself. Besides forwarding of received 2694 messages a PKI management entity could also need to revoke 2695 certificates of EEs, report errors, or may need to manage its own 2696 certificates. 2698 < TBD: In CMP Updates [I-D.ietf-lamps-cmp-updates] additional 2699 extended key usages like id-kp-cmpRA will be defined to indicate that 2700 a key pair is entitled to be used for signature-based protection of a 2701 CMP message by a PKI management entity. > 2703 6.1. Forwarding of messages 2705 Each CMP request message (i.e., ir, cr, p10cr, kur, pollReq, or 2706 certConf) or error message coming from an EE or the previous 2707 (downstream) PKI management entity MUST be sent to the next 2708 (upstream) PKI management entity. This PKI management entity MUST 2709 forward response messages to the next (downstream) PKI management 2710 entity or EE. 2712 The PKI management entity SHOULD verify the protection, the syntax, 2713 the required message fields, the message type, and if applicable the 2714 authorization and the proof-of-possession of the message. Additional 2715 checks or actions MAY be applied depending on the PKI solution 2716 requirements and concept. If one of these verification procedures 2717 fails, the (L)RA SHOULD respond with a negative response message and 2718 SHOULD not forward the message further upstream. General error 2719 conditions should be handled as described in Section 5.3 and 2720 Section 6.3. 2722 A PKI management entity SHOULD not change the received message if not 2723 necessary. The PKI management entity SHOULD only update the message 2724 protection if it is technically necessary. Concrete PKI system 2725 specifications may define in more detail if and when to do so. 2727 This is particularly relevant in the upstream communication of a 2728 request message. 2730 Each hop in a chain of PKI management entity has one or more 2731 functionalities, e.g., a PKI management entity 2733 o may need to verify the identities of EEs or base authorization 2734 decisions for certification request processing on specific 2735 knowledge of the local setup, e.g., by consulting an inventory or 2736 asset management system, 2738 o may need to add fields to certificate request messages, 2740 o may need to store data from a message in a database for later 2741 usage or documentation purposes, 2743 o may provide traversal of a network boundary, 2745 o may need to double-check if the messages transferred back and 2746 forth are properly protected and well formed, 2748 o may provide a proof that it has performed all required checks, 2750 o may initiate a delayed enrollment due to offline upstream 2751 communication or registration officer interaction, 2753 o may grant the request of an EE to omit sending a confirmation 2754 message, or 2756 o can collect messages from different LRAs and forward them to the 2757 CA. 2759 Therefore, the decision if a message should be forwarded 2761 o unchanged with the original protection, 2763 o unchanged with a new protection, or 2765 o changed with a new protection 2767 depends on the PKI solution design and the associated security policy 2768 (CP/CPS [RFC3647]). 2770 < TBD: In CMP Updates [I-D.ietf-lamps-cmp-updates] different 2771 circumstances that require adding of an additional protection by a 2772 PKI management entity or batching CMP messages at a PKI management 2773 entity by using the nested messages is described. It needs to be 2774 decided which of these variants should be specified here. Finally, I 2775 guess they will all be OPTIONAL. > 2777 This section specifies the different options a PKI management entity 2778 may implement and use. 2780 A PKI management entity MAY update the protection of a message 2782 o if it performs changes to the header or the body of the message, 2784 o if it needs to prove checks or validations performed on the 2785 message to one of the next (upstream) PKI components, 2787 o if it needs to protect the message using a key and certificate 2788 from a different PKI, or 2790 o if it needs to replace a MAC based-protection. 2792 This is particularly relevant in the upstream communication of 2793 certificate request messages. 2795 The message protection covers only the header and the body and not 2796 the extraCerts. The PKI management entity MAY change the extraCerts 2797 in any of the following message adaptations, e.g., to sort or add 2798 needed or to delete needless certificates to support the next hop. 2799 This may be particularly helpful to extend upstream messages with 2800 additional certificates or to reduce the number of certificates in 2801 downstream messages when forwarding to constrained devices. 2803 6.1.1. Not changing protection 2805 This alternative to forward a message can be used by any PKI 2806 management entity to forward an original CMP message without changing 2807 the header, body or protection. In any of these cases the PKI 2808 management entity acts more like a proxy, e.g., on a network 2809 boundary, implementing no specific RA-like security functionality to 2810 the PKI. 2812 This alternative to forward a message MUST be used for forwarding kur 2813 messages that must not be approved by the respective PKI management 2814 entity. 2816 6.1.2. Replacing protection 2818 The following two alternatives to forward a message can be used by 2819 any PKI management entity to forward a CMP message with or without 2820 changes, but providing its own protection using its CMP signer key to 2821 assert approval of this message. In this case the PKI management 2822 entity acts as an actual Registration Authority (RA), which 2823 implements important security functionality of the PKI. 2825 Before replacing the existing protection by a new protection, the PKI 2826 management entity MUST verify the protection provided by the EE or by 2827 the previous PKI component and approve its content including any own 2828 modifications. For certificate requests the PKI management entity 2829 MUST verify in particular the included proof-of-possession self- 2830 signature of the certTemplate using the public key of the requested 2831 certificate and MUST check that the EE, as authenticated by the 2832 message protection, is authorized to request a certificate with the 2833 subject as specified in the certTemplate. 2835 In case the received message has been protected by a CA or another 2836 PKI management entity, the current PKI management entity MUST verify 2837 its protection and approve its content including any own 2838 modifications. For certificate requests the PKI management entity 2839 MUST check that the other PKI management entity, as authenticated by 2840 the protection of the incomming message, was authorized to issue or 2841 forward the request. 2843 These message adaptations MUST NOT be applied to kur request messages 2844 as described in Section 5.1.3 since their original protection using 2845 the key and certificate to be updated needs to be preserved, unless 2846 the regCtrl OldCertId is used to clearly identify the certificate to 2847 be updated. 2849 6.1.2.1. Keeping proof-of-possession 2851 This alternative to forward a message can be used by any PKI 2852 management entity to forward a CMP message with or without modifying 2853 the message header or body while preserving any included proof-of- 2854 possession. 2856 By replacing the existing protection using its own CMP signer key the 2857 PKI management entity provides a proof of verifying and approving of 2858 the message as described above. 2860 In case the PKI management entity modifies the certTemplate of an ir 2861 or cr message, the message adaptation in Section 6.1.2.2 needs to be 2862 applied instead. 2864 6.1.2.2. Breaking proof-of-possession 2866 This alternativeto forward a message can be used by any PKI 2867 management entity to forward an ir or cr message with modifications 2868 of the certTemplate i.e., modification, addition, or removal of 2869 fields. Such changes will break the proof-of-possession provided by 2870 the EE in the original message. 2872 By replacing the existing using its own CMP signer key the PKI 2873 management entity provides a proof of verifying and approving the new 2874 message as described above. 2876 In addition to the above the PKI management entity MUST verify in 2877 particular the proof-of-possession contained in the original message 2878 as described above. If these checks were successfully performed the 2879 PKI management entity MUST change the popo to raVerified. 2881 The popo field MUST contain the raVerified choice in the certReq 2882 structure of the modified message as follows: 2884 popo 2885 raVerified REQUIRED 2886 -- MUST have the value NULL and indicates that the PKI 2887 -- management entity verified the popo of the original 2888 -- message 2890 6.1.3. Adding Protection 2892 < TBD: In CMP Updates [I-D.ietf-lamps-cmp-updates] different 2893 circumstances that require adding of an additional protection by a 2894 PKI management entity or batching CMP messages at a PKI management 2895 entity by using the nested messages is described. It needs to be 2896 decided which of these variants should be specified here. Finally, I 2897 guess they will all be OPTIONAL. > 2899 6.1.4. Initiating delayed enrollment 2901 This functional extension can be used by a PKI management entity to 2902 initiate delayed enrollment. In this case a PKI management entity 2903 MUST add the status waiting in the response message. The PKI 2904 management entity MUST then reply to the pollReq messages as 2905 described in Section 5.1.7. 2907 6.2. Revoking certificates on behalf of another's entities 2909 This PKI management operation can be used by a PKI management entity 2910 to revoke a certificate of any other entity. This revocation request 2911 message MUST be signed by the PKI management entity using its own CMP 2912 signer key to prove to the PKI authorization to revoke the 2913 certificate on behalf of the EE. 2915 Preconditions: 2917 1 the certificate to be revoked MUST be known to the PKI management 2918 entity 2920 2 the PKI management entity MUST have the authorization to revoke 2921 the certificates of other entities issued by the corresponding CA 2923 The message sequence for this PKI management operation is identical 2924 to that given in section Section 5.2, with the following changes: 2926 1 it is not required that the certificate to be revoked is not yet 2927 expired or revoked 2929 2 the PKI management entity acts as EE for this message exchange 2931 3 the rr messages MUST be signed using the CMP signer key of the PKI 2932 management entity. 2934 6.3. Error reporting 2936 This functionality should be used by the PKI management entity to 2937 report any error conditions downstream to the EE. Potential error 2938 reporting by the EE upstream to the PKI management entity is 2939 described in Section 5.3. 2941 In case the error condition is related to specific details of an ir, 2942 cr, p10cr, or kur request message it MUST be reported in the specific 2943 response message, i.e., an ip, cp, or kup with negative contents. 2945 General error conditions, e.g., problems with the message header, 2946 protection, or extraCerts, and negative feedback on rr, pollReq, 2947 certConf, or error messages MUST be reported in the form of an error 2948 message. 2950 In both situations the PKI management entity reports the errors in 2951 the PKIStatusInfo structure of the respective message as described in 2952 Section 5.3. 2954 An EE receiving any such negative feedback SHOULD log the error 2955 appropriately and MUST terminate the current transaction. 2957 7. CMP message transport variants 2959 The CMP messages are designed to be self-contained, such that in 2960 principle any transport can be used. HTTP SHOULD be used for online 2961 transport while file-based transport MAY be used in case offline 2962 transport is required. In case HTTP transport is not desired or 2963 possible, CMP messages MAY also be piggybacked on any other reliable 2964 transport protocol, e.g., CoAP [RFC7252]. 2966 Independently of the means of transport it could happen that messages 2967 are lost, or a communication partner does not respond. In order to 2968 prevent waiting indefinitely, each CMP client component SHOULD use a 2969 configurable per-request timeout, and each CMP server component 2970 SHOULD use a configurable per-response timeout in case a further 2971 message is to be expected from the client side. In this way a 2972 hanging transaction can be closed cleanly with an error and related 2973 resources (for instance, any cached extraCerts) can be freed. 2975 7.1. HTTP transport 2977 This transport mechanism can be used by a PKI entity to transfer CMP 2978 messages over HTTP. If HTTP transport is used the specifications as 2979 described in [RFC6712] MUST be followed. 2981 Each PKI management entity supporting HTTP or HTTPS transport MUST 2982 support the use of the path-prefix of '/.well-known/' as defined in 2983 [RFC5785] and the registered name of 'cmp' to ease interworking in a 2984 multi-vendor environment. 2986 The CMP client MUST be configured with sufficient information to form 2987 the CMP server URI. This MUST be at least the authority portion of 2988 the URI, e.g., 'www.example.com:80', or the full operational path of 2989 the PKI management entity. An additional arbitrary label, e.g., 2990 'arbitraryLabel1', MAY be configured as a separate component or as 2991 part of the full operational path to provide further information to 2992 address multiple CAs or certificate profiles. A valid full 2993 operational path can look like this: 2995 1 http://www.example.com/.well-known/cmp 2997 2 http://www.example.com/.well-known/cmp/keyupdate 2999 3 http://www.example.com/.well-known/cmp/arbitraryLabel1 3001 4 http://www.example.com/.well-known/cmp/arbitraryLabel1/keyupdate 3002 PKI management operations SHOULD use the following URI path: 3004 +---------------------------------+----------------------+----------+ 3005 | PKI management operation | Path | Details | 3006 +---------------------------------+----------------------+----------+ 3007 | Enroll client to new PKI | /initialization | Section | 3008 | (REQUIRED) | | 5.1.1 | 3009 +---------------------------------+----------------------+----------+ 3010 | Enroll client to existing PKI | /certification | Section | 3011 | (OPTIONAL) | | 5.1.2 | 3012 +---------------------------------+----------------------+----------+ 3013 | Update client certificate | /keyupdate | Section | 3014 | (REQUIRED) | | 5.1.3 | 3015 +---------------------------------+----------------------+----------+ 3016 | Enroll client using PKCS#10 | /p10 | Section | 3017 | (OPTIONAL) | | 5.1.5 | 3018 +---------------------------------+----------------------+----------+ 3019 | Enroll client using central key | /serverkeygen | Section | 3020 | generation (OPTIONAL) | | 5.1.6 | 3021 +---------------------------------+----------------------+----------+ 3022 | Revoke client certificate | /revocation | Section | 3023 | (RECOMMENDED) | | 5.2 | 3024 +---------------------------------+----------------------+----------+ 3025 | Get CA certificates (OPTIONAL) | /getCAcert | Section | 3026 | | | 5.4.2 | 3027 +---------------------------------+----------------------+----------+ 3028 | Get root CA certificate update | /getRootCAcertUpdate | Section | 3029 | (OPTIONAL) | | 5.4.3 | 3030 +---------------------------------+----------------------+----------+ 3031 | Get certificate request | /getCSRparam | Section | 3032 | parameters (OPTIONAL) | | 5.4.4 | 3033 +---------------------------------+----------------------+----------+ 3034 | Get certificate management | /getCertMgtConfig | Section | 3035 | configuration (OPTIONAL) | | 5.4.5 | 3036 +---------------------------------+----------------------+----------+ 3037 | Get enrollment voucher | /getVoucher | Section | 3038 | (OPTIONAL) | | 5.4.6 | 3039 +---------------------------------+----------------------+----------+ 3041 Table 1: HTTP endpoints 3043 Subsequent certConf, error, and pollReq messages are sent to the URI 3044 of the respective PKI management operation. 3046 < TBD: It needs to be defined if specific path values for 3047 communication between PKI management entities as specified in section 3048 6 are needed, e.g., 'forward' or 'nested'.> 3050 7.2. HTTPS transport using certificates 3052 This transport mechanism can be used by a PKI entity to further 3053 protect the HTTP transport as described in Section 7.1 using TLS 1.2 3054 [RFC5246] or TLS 1.3 [RFC8446] as described in [RFC2818] with 3055 certificate-based authentication. Using this transport mechanism, 3056 the CMP transport via HTTPS MUST use TLS server authentication and 3057 SHOULD use TLS client authentication. 3059 EE: 3061 o The EE SHOULD use a TLS client certificate as far as available. 3062 If no dedicated TLS certificate is available the EE SHOULD use an 3063 already existing certificate identifying the EE (e.g., a 3064 manufacturer certificate). 3066 o If no TLS certificate is available at the EE, server-only 3067 authenticated TLS SHOULD be used. 3069 o The EE MUST validate the TLS server certificate of its 3070 communication partner. 3072 PKI management entity: 3074 o Each PKI management entity SHOULD use a TLS client certificate on 3075 its upstream (client) interface. 3077 o Each PKI management entity MUST use a TLS server certificate on 3078 its downstream (server) interface. 3080 o Each PKI management entity MUST validate the TLS certificate of 3081 its communication partners. 3083 NOTE: The requirements for checking certificates given in [RFC5280], 3084 [RFC5246] and [RFC8446] MUST be followed for the TLS layer. 3085 Certificate status checking SHOULD be used for the TLS certificates 3086 of communication partners. 3088 7.3. HTTPS transport using shared secrets 3090 This transport mechanism can be used by a PKI entity to further 3091 protect the HTTP transport as described in Section 7.1 using TLS 1.2 3092 [RFC5246] or TLS 1.3 [RFC8446] as described in [RFC2818] with mutual 3093 authentication based on shared secrets as described in [RFC5054]. 3095 EE: 3097 o The EE MUST use the shared symmetric key for authentication. 3099 PKI management entity: 3101 o The PKI management entity MUST use the shared symmetric key for 3102 authentication. 3104 7.4. File-based transport 3106 For offline transfer file-based transport MAY be used. Offline 3107 transport is typically used between LRA and RA nodes. 3109 Connection and error handling mechanisms like those specified for 3110 HTTP in [RFC6712] need to be implemented. 3112 < TBD: Details need to be defined later > 3114 7.5. CoAP transport 3116 In constrained environments where no HTTP transport is desired or 3117 possible, CoAP [RFC7252] MAY be used instead. Connection and error 3118 handling mechanisms like those specified for HTTP in [RFC6712] may 3119 need to be implemented. 3121 Such specification is out of scope of this document and would need to 3122 be specifies in a separate document. 3124 7.6. Piggybacking on other reliable transport 3126 For online transfer where no HTTP transport is desired or possible 3127 CMP messages MAY also be transported on some other reliable protocol. 3128 Connection and error handling mechanisms like those specified for 3129 HTTP in [RFC6712] need to be implemented. 3131 Such specification is out of scope of this document and would need to 3132 be specifies in a separate document, e.g., in the scope of the 3133 respective transport protocol used. 3135 8. IANA Considerations 3137 3139 9. Security Considerations 3141 3143 10. Acknowledgements 3145 We would like to thank the various reviewers of this document. 3147 11. References 3149 11.1. Normative References 3151 [I-D.ietf-lamps-cmp-updates] 3152 Brockhaus, H., "CMP Updates", draft-ietf-lamps-cmp- 3153 updates-00 (work in progress), February 2020. 3155 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 3156 Requirement Levels", BCP 14, RFC 2119, 3157 DOI 10.17487/RFC2119, March 1997, 3158 . 3160 [RFC2986] Nystrom, M. and B. Kaliski, "PKCS #10: Certification 3161 Request Syntax Specification Version 1.7", RFC 2986, 3162 DOI 10.17487/RFC2986, November 2000, 3163 . 3165 [RFC4086] Eastlake 3rd, D., Schiller, J., and S. Crocker, 3166 "Randomness Requirements for Security", BCP 106, RFC 4086, 3167 DOI 10.17487/RFC4086, June 2005, 3168 . 3170 [RFC4210] Adams, C., Farrell, S., Kause, T., and T. Mononen, 3171 "Internet X.509 Public Key Infrastructure Certificate 3172 Management Protocol (CMP)", RFC 4210, 3173 DOI 10.17487/RFC4210, September 2005, 3174 . 3176 [RFC4211] Schaad, J., "Internet X.509 Public Key Infrastructure 3177 Certificate Request Message Format (CRMF)", RFC 4211, 3178 DOI 10.17487/RFC4211, September 2005, 3179 . 3181 [RFC5280] Cooper, D., Santesson, S., Farrell, S., Boeyen, S., 3182 Housley, R., and W. Polk, "Internet X.509 Public Key 3183 Infrastructure Certificate and Certificate Revocation List 3184 (CRL) Profile", RFC 5280, DOI 10.17487/RFC5280, May 2008, 3185 . 3187 [RFC5652] Housley, R., "Cryptographic Message Syntax (CMS)", STD 70, 3188 RFC 5652, DOI 10.17487/RFC5652, September 2009, 3189 . 3191 [RFC5785] Nottingham, M. and E. Hammer-Lahav, "Defining Well-Known 3192 Uniform Resource Identifiers (URIs)", RFC 5785, 3193 DOI 10.17487/RFC5785, April 2010, 3194 . 3196 [RFC6712] Kause, T. and M. Peylo, "Internet X.509 Public Key 3197 Infrastructure -- HTTP Transfer for the Certificate 3198 Management Protocol (CMP)", RFC 6712, 3199 DOI 10.17487/RFC6712, September 2012, 3200 . 3202 11.2. Informative References 3204 [ETSI-3GPP] 3205 3GPP, "TS33.310; Network Domain Security (NDS); 3206 Authentication Framework (AF); Release 16; V16.1.0", 3207 December 2018, 3208 . 3210 [I-D.ietf-anima-bootstrapping-keyinfra] 3211 Pritikin, M., Richardson, M., Eckert, T., Behringer, M., 3212 and K. Watsen, "Bootstrapping Remote Secure Key 3213 Infrastructures (BRSKI)", draft-ietf-anima-bootstrapping- 3214 keyinfra-35 (work in progress), February 2020. 3216 [IEC62443-3-3] 3217 IEC, "Industrial communication networks - Network and 3218 system security - Part 3-3: System security requirements 3219 and security levels", IEC 62443-3-3, August 2013, 3220 . 3222 [IEEE802.1AR] 3223 IEEE, "802.1AR Secure Device Identifier", June 2018, 3224 . 3227 [NIST-CSFW] 3228 NIST, "Framework for Improving Critical Infrastructure 3229 Cybersecurity Version 1.1", April 2018, 3230 . 3233 [RFC2818] Rescorla, E., "HTTP Over TLS", RFC 2818, 3234 DOI 10.17487/RFC2818, May 2000, 3235 . 3237 [RFC3647] Chokhani, S., Ford, W., Sabett, R., Merrill, C., and S. 3238 Wu, "Internet X.509 Public Key Infrastructure Certificate 3239 Policy and Certification Practices Framework", RFC 3647, 3240 DOI 10.17487/RFC3647, November 2003, 3241 . 3243 [RFC5054] Taylor, D., Wu, T., Mavrogiannopoulos, N., and T. Perrin, 3244 "Using the Secure Remote Password (SRP) Protocol for TLS 3245 Authentication", RFC 5054, DOI 10.17487/RFC5054, November 3246 2007, . 3248 [RFC5246] Dierks, T. and E. Rescorla, "The Transport Layer Security 3249 (TLS) Protocol Version 1.2", RFC 5246, 3250 DOI 10.17487/RFC5246, August 2008, 3251 . 3253 [RFC7252] Shelby, Z., Hartke, K., and C. Bormann, "The Constrained 3254 Application Protocol (CoAP)", RFC 7252, 3255 DOI 10.17487/RFC7252, June 2014, 3256 . 3258 [RFC7515] Jones, M., Bradley, J., and N. Sakimura, "JSON Web 3259 Signature (JWS)", RFC 7515, DOI 10.17487/RFC7515, May 3260 2015, . 3262 [RFC7519] Jones, M., Bradley, J., and N. Sakimura, "JSON Web Token 3263 (JWT)", RFC 7519, DOI 10.17487/RFC7519, May 2015, 3264 . 3266 [RFC8366] Watsen, K., Richardson, M., Pritikin, M., and T. Eckert, 3267 "A Voucher Artifact for Bootstrapping Protocols", 3268 RFC 8366, DOI 10.17487/RFC8366, May 2018, 3269 . 3271 [RFC8446] Rescorla, E., "The Transport Layer Security (TLS) Protocol 3272 Version 1.3", RFC 8446, DOI 10.17487/RFC8446, August 2018, 3273 . 3275 [UNISIG] UNISIG, "Subset-137; ERTMS/ETCS On-line Key Management 3276 FFFIS; V1.0.0", December 2015, 3277 . 3279 [W3C_XML] W3C, "Extensible Markup Language (XML) 1.0", W3C XML, 3280 November 2008, . 3282 [W3C_XML-Dsig] 3283 W3C, "XML Signature Syntax and Processing Version 2.0", 3284 W3C XML-DSIG, July 2015, 3285 . 3287 Appendix A. Additional Stuff 3289 This becomes an Appendix. 3291 Authors' Addresses 3293 Hendrik Brockhaus 3294 Siemens AG 3295 Otto-Hahn-Ring 6 3296 Munich 81739 3297 Germany 3299 Email: hendrik.brockhaus@siemens.com 3300 URI: http://www.siemens.com/ 3302 Steffen Fries 3303 Siemens AG 3304 Otto-Hahn-Ring 6 3305 Munich 81739 3306 Germany 3308 Email: steffen.fries@siemens.com 3309 URI: http://www.siemens.com/ 3311 David von Oheimb 3312 Siemens AG 3313 Otto-Hahn-Ring 6 3314 Munich 81739 3315 Germany 3317 Email: david.von.oheimb@siemens.com 3318 URI: http://www.siemens.com/