idnits 2.17.1 draft-ietf-lamps-lightweight-cmp-profile-02.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 3, Section 4, and Section 5 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 4.3 and Section 5.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 (July 11, 2020) is 1383 days in the past. Is this intentional? Checking references for intended status: Proposed Standard ---------------------------------------------------------------------------- (See RFCs 3967 and 4897 for information about using normative references to lower-maturity documents in RFCs) == Missing Reference: 'RFC8018' is mentioned on line 1841, but not defined -- Looks like a reference, but probably isn't: '0' on line 3276 -- Looks like a reference, but probably isn't: '1' on line 3277 -- Looks like a reference, but probably isn't: '3' on line 3309 -- Looks like a reference, but probably isn't: '5' on line 3312 -- Looks like a reference, but probably isn't: '6' on line 3333 -- Looks like a reference, but probably isn't: '9' on line 3342 -- Looks like a reference, but probably isn't: '2' on line 3347 -- Looks like a reference, but probably isn't: '7' on line 3348 == Outdated reference: A later version (-23) exists of draft-ietf-lamps-cmp-updates-02 ** Downref: Normative reference to an Informational RFC: RFC 2986 ** Obsolete normative reference: RFC 5785 (Obsoleted by RFC 8615) -- Obsolete informational reference (is this intentional?): RFC 2510 (Obsoleted by RFC 4210) -- Obsolete informational reference (is this intentional?): RFC 2818 (Obsoleted by RFC 9110) -- Obsolete informational reference (is this intentional?): RFC 5246 (Obsoleted by RFC 8446) Summary: 2 errors (**), 0 flaws (~~), 7 warnings (==), 12 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: January 12, 2021 Siemens 6 July 11, 2020 8 Lightweight CMP Profile 9 draft-ietf-lamps-lightweight-cmp-profile-02 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 in more complex scenarios, other types of operations are specified as 23 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 January 12, 2021. 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. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 3 60 1.1. Motivation for profiling CMP . . . . . . . . . . . . . . 4 61 1.2. Motivation for a lightweight profile for CMP . . . . . . 5 62 1.3. Existing CMP profiles . . . . . . . . . . . . . . . . . . 5 63 1.4. Compatibility with existing CMP profiles . . . . . . . . 7 64 1.5. Scope of this document . . . . . . . . . . . . . . . . . 9 65 1.6. Structure of this document . . . . . . . . . . . . . . . 9 66 1.7. Convention and Terminology . . . . . . . . . . . . . . . 10 67 2. Architecture and use cases . . . . . . . . . . . . . . . . . 11 68 2.1. Solution architecture . . . . . . . . . . . . . . . . . . 11 69 2.2. Basic generic CMP message content . . . . . . . . . . . . 12 70 2.3. Supported PKI management operations . . . . . . . . . . . 12 71 2.3.1. Mandatory PKI management operations . . . . . . . . . 13 72 2.3.2. Recommended PKI management operations . . . . . . . . 13 73 2.3.3. Optional PKI management operations . . . . . . . . . 14 74 2.4. CMP message transport . . . . . . . . . . . . . . . . . . 14 75 3. Generic parts of the PKI message . . . . . . . . . . . . . . 15 76 3.1. General description of the CMP message header . . . . . . 16 77 3.2. General description of the CMP message protection . . . . 17 78 3.3. General description of CMP message extraCerts . . . . . . 18 79 4. End Entity focused PKI management operations . . . . . . . . 19 80 4.1. Requesting a new certificate from a PKI . . . . . . . . . 19 81 4.1.1. Request a certificate from a new PKI with signature 82 protection . . . . . . . . . . . . . . . . . . . . . 20 83 4.1.2. Request a certificate from a trusted PKI with 84 signature protection . . . . . . . . . . . . . . . . 27 85 4.1.3. Update an existing certificate with signature 86 protection . . . . . . . . . . . . . . . . . . . . . 28 87 4.1.4. Request a certificate from a PKI with MAC protection 29 88 4.1.5. Request a certificate from a legacy PKI using PKCS#10 89 request . . . . . . . . . . . . . . . . . . . . . . . 31 90 4.1.6. Generate the key pair centrally at the PKI management 91 entity . . . . . . . . . . . . . . . . . . . . . . . 32 92 4.1.6.1. Using key agreement key management technique . . 37 93 4.1.6.2. Using key transport key management technique . . 38 94 4.1.6.3. Using password-based key management technique . . 39 95 4.1.7. Delayed enrollment . . . . . . . . . . . . . . . . . 40 96 4.2. Revoking a certificate . . . . . . . . . . . . . . . . . 45 97 4.3. Error reporting . . . . . . . . . . . . . . . . . . . . . 47 98 4.4. Support messages . . . . . . . . . . . . . . . . . . . . 49 99 4.4.1. General message and response . . . . . . . . . . . . 50 100 4.4.2. Get CA certificates . . . . . . . . . . . . . . . . . 51 101 4.4.3. Get root CA certificate update . . . . . . . . . . . 52 102 4.4.4. Get certificate request template . . . . . . . . . . 53 103 5. LRA and RA focused PKI management operations . . . . . . . . 55 104 5.1. Forwarding of messages . . . . . . . . . . . . . . . . . 55 105 5.1.1. Not changing protection . . . . . . . . . . . . . . . 57 106 5.1.2. Replacing protection . . . . . . . . . . . . . . . . 57 107 5.1.2.1. Keeping proof-of-possession . . . . . . . . . . . 58 108 5.1.2.2. Breaking proof-of-possession . . . . . . . . . . 58 109 5.1.3. Adding Protection . . . . . . . . . . . . . . . . . . 59 110 5.1.3.1. Handling a single PKI management message . . . . 60 111 5.1.3.2. Handling a batch of PKI management messages . . . 60 112 5.1.4. Initiating delayed enrollment . . . . . . . . . . . . 61 113 5.2. Revoking certificates on behalf of another's entities . . 62 114 5.3. Error reporting . . . . . . . . . . . . . . . . . . . . . 62 115 6. CMP message transport variants . . . . . . . . . . . . . . . 63 116 6.1. Definition and discovery of HTTP URIs . . . . . . . . . . 63 117 6.2. HTTP transport . . . . . . . . . . . . . . . . . . . . . 66 118 6.3. HTTPS transport using certificates . . . . . . . . . . . 66 119 6.4. HTTPS transport using shared secrets . . . . . . . . . . 67 120 6.5. Offline transport . . . . . . . . . . . . . . . . . . . . 67 121 6.5.1. File-based transport . . . . . . . . . . . . . . . . 68 122 6.5.2. Other asynchronous transport protocols . . . . . . . 68 123 6.6. CoAP transport . . . . . . . . . . . . . . . . . . . . . 68 124 6.7. Piggybacking on other reliable transport . . . . . . . . 68 125 7. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 69 126 8. Security Considerations . . . . . . . . . . . . . . . . . . . 69 127 9. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 69 128 10. References . . . . . . . . . . . . . . . . . . . . . . . . . 69 129 10.1. Normative References . . . . . . . . . . . . . . . . . . 69 130 10.2. Informative References . . . . . . . . . . . . . . . . . 70 131 Appendix A. ASN.1 Syntax . . . . . . . . . . . . . . . . . . . . 72 132 Appendix B. Example for CertReqTemplate . . . . . . . . . . . . 72 133 Appendix C. History of changes . . . . . . . . . . . . . . . . . 74 134 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 77 136 1. Introduction 138 !!! The change history was moved to Appendix C !!! 140 This document specifies PKI management operations supporting machine- 141 to-machine and IoT use cases. The focus lies on maximum automation 142 and interoperable implementation of all involved PKI entities from 143 end entities (EE) through an optional Local Registration Authority 144 (LRA) and the RA up to the CA. The profile makes use of the concepts 145 and syntax specified in CMP [RFC4210], CRMF [RFC4211], HTTP transfer 146 for CMP [RFC6712], and CMP Updates [I-D.ietf-lamps-cmp-updates]. 147 Especially CMP and CRMF are very feature-rich standards, while only a 148 limited subset of the specified functionality is needed in many 149 environments. Additionally, the standards are not always precise 150 enough on how to interpret and implement the described concepts. 151 Therefore, this document aims at tailoring and specifying in more 152 detail how to use these concepts to implement lightweight automated 153 certificate management. 155 1.1. Motivation for profiling CMP 157 CMP was standardized in 1999 and is implemented in several CA 158 products. In 2005 a completely reworked and enhanced version 2 of 159 CMP [RFC4210] and CRMF [RFC4211] has been published followed by a 160 document specifying a transfer mechanism for CMP messages using http 161 [RFC6712] in 2012. 163 Though CMP is a very solid and capable protocol it could be used more 164 widely. The most important reason for not more intense application 165 of CMP appears to be that the protocol is offering a large set of 166 features and options but being not always precise enough and leaving 167 room for interpretation. On the one hand, this makes CMP applicable 168 to a very wide range of scenarios, but on the other hand a full 169 implementation of all options is unrealistic because this would take 170 enormous effort. 172 Moreover, many details of the CMP protocol have been left open or 173 have not been specified in full preciseness. The profiles specified 174 in Appendix D and E of [RFC4210] offer some more detailed PKI 175 management operations. But the specific needs of highly automated 176 scenarios for a machine-to-machine communication are not covered 177 sufficiently. 179 As also 3GPP and UNISIG already put across, profiling is a way of 180 coping with the challenges mentioned above. To profile means to take 181 advantage of the strengths of the given protocol, while explicitly 182 narrowing down the options it provides to exactly those needed for 183 the purpose(s) at hand and eliminating all identified ambiguities. 184 In this way all the general and applicable aspects of the protocol 185 can be taken over and only the peculiarities of the target scenario 186 need to be dealt with specifically. 188 Doing such a profiling for a new target environment can be a high 189 effort because the range of available options needs to be well 190 understood and the selected options need to be consistent with each 191 other and with the intended usage scenario. Since most industrial 192 PKI management use cases typically have much in common it is worth 193 sharing this effort, which is the aim of this document. Other 194 standardization bodies can then reference the needed PKI management 195 operations from this document and do not need to come up with 196 individual profiles. 198 1.2. Motivation for a lightweight profile for CMP 200 The profiles specified in Appendix D and E of CMP have been developed 201 in particular to manage certificates of human end entities. With the 202 evolution of distributed systems and client-server architectures, 203 certificates for machines and applications on them have become widely 204 used. This trend has strengthened even more in emerging industrial 205 and IoT scenarios. CMP is sufficiently flexible to support these 206 very well. 208 Today's IT security architectures for industrial solutions typically 209 use certificates for endpoint authentication within protocols like 210 IPSec, TLS, or SSH. Therefore, the security of these architectures 211 highly relies upon the security and availability of the implemented 212 certificate management procedures. 214 Due to increasing security in operational networks as well as 215 availability requirements, especially on critical infrastructures and 216 systems with a high volume of certificates, a state-of-the-art 217 certificate management must be constantly available and cost- 218 efficient, which calls for high automation and reliability. The NIST 219 Cyber Security Framework [NIST-CSFW] also refers to proper processes 220 for issuance, management, verification, revocation, and audit for 221 authorized devices, users and processes involving identity and 222 credential management. Such PKI operation according to commonly 223 accepted best practices is also required in IEC 62443-3-3 224 [IEC62443-3-3] for security level 2 up to security level 4. 226 Further challenges in many industrial systems are network 227 segmentation and asynchronous communication, where PKI operation is 228 often not deployed on-site but in a more protected environment of a 229 data center or trust center. Certificate management must be able to 230 cope with such network architectures. CMP offers the required 231 flexibility and functionality, namely self-contained messages, 232 efficient polling, and support for asynchronous message transfer with 233 end-to-end security. 235 1.3. Existing CMP profiles 237 As already stated, CMP contains profiles with mandatory and optional 238 transactions in the Appendixes D and E of [RFC4210]. Those profiles 239 focus on management of human user certificates and do only partly 240 address the specific needs for certificate management automation for 241 unattended machine or application-oriented end entities. 243 [RFC4210] specifies in Appendix D the following mandatory PKI 244 management operations (all require support of, in the meantime 245 outdated, algorithms, e.g., SHA-1 and 3-DES; all operations may 246 enroll up to two certificates, one for a locally generated and 247 another optional one for a centrally generated key pair; all require 248 use of certConf/pkiConf messages for confirmation): 250 o Initial registration/certification; an (uninitialized) end entity 251 requests a (first) certificate from a CA using shared secret based 252 message authentication. The content is similar to the PKI 253 management operation specified in Section 4.1.4 of this document. 255 o Certificate request; an (initialized) end entity requests another 256 certificate from a CA using signature or shared secret based 257 message authentication. The content is similar to the PKI 258 management operation specified in Section 4.1.2 of this document. 260 o Key update; an (initialized) end entity requests a certificate 261 from a CA (to update the key pair and/or corresponding certificate 262 that it already possesses) using signature or shared secret based 263 message authentication. The content is similar to the PKI 264 management operation specified in Section 4.1.3 of this document. 266 Due to the two certificates that may be enrolled and the shared 267 secret based authentication, these PKI management operations focus 268 more on the enrollment of human users at a PKI. 270 [RFC4210] specifies in Appendix E the following optional PKI 271 management operations (all require support of, in the meantime 272 outdated, algorithms, e.g., SHA-1 and 3-DES): 274 o Root CA key update; a root CA updates its key pair and produces a 275 CA key update announcement message that can be made available (via 276 some transport mechanism) to the relevant end entities. This 277 operation only supports a push and no pull model. The content is 278 similar to the PKI management operation specified in Section 4.4.3 279 of this document. 281 o Information request/response; an end entity sends a general 282 message to the PKI requesting details that will be required for 283 later PKI management operations. The content is similar to the 284 PKI management operation specified in Section 4.4.4 of this 285 document. 287 o Cross-certification request/response (1-way); creation of a single 288 cross-certificate (i.e., not two at once). The requesting CA MAY 289 choose who is responsible for publication of the cross-certificate 290 created by the responding CA through use of the PKIPublicationInfo 291 control. 293 o In-band initialization using external identity certificate (this 294 PKI management operation may also enroll up to two certificates 295 and requires use of certConf/pkiConf messages for confirmation as 296 specified in Appendix D of [RFC4210]). An (uninitialized) end 297 entity wishes to initialize into the PKI with a CA, CA-1. It 298 uses, for authentication purposes, a pre-existing identity 299 certificate issued by another (external) CA, CA-X. A trust 300 relationship must already have been established between CA-1 and 301 CA-X so that CA-1 can validate the EE identity certificate signed 302 by CA-X. Furthermore, some mechanism must already have been 303 established within the Personal Security Environment (PSE) of the 304 EE that would allow it to authenticate and verify PKIMessages 305 signed by CA-1. The content is similar to the PKI management 306 operation specified in Section 4.1.1 of this document. 308 Both Appendixes focus on EE to CA/RA PKI management operations and do 309 not address further profiling of RA to CA communication as typically 310 used for full backend automation. 312 3GPP makes use of CMP [RFC4210] in its Technical Specification 133 313 310 [ETSI-3GPP] for automatic management of IPSec certificates in 314 UMTS, LTE, and 5G backbone networks. Since 2010 a dedicated CMP 315 profile for initial certificate enrollment and update operations 316 between EE and RA/CA is specified in that document. 318 UNISIG has included a CMP profile for certificate enrollment in the 319 subset 137 specifying the ETRAM/ECTS on-line key management for train 320 control systems [UNISIG] in 2015. 322 Both standardization bodies use CMP [RFC4210], CRMF [RFC4211], and 323 HTTP transfer for CMP [RFC6712] to add tailored means for automated 324 PKI management operations for unattended machine or application- 325 oriented end entities. 327 1.4. Compatibility with existing CMP profiles 329 The profile specified in this document is compatible with CMP 330 [RFC4210] Appendixes D and E (PKI Management Message Profiles), with 331 the following exceptions: 333 o signature-based protection is the default protection; an initial 334 PKI management operation may also use HMAC, 336 o certification of a second key pair within the same PKI management 337 operation is not supported, 339 o proof-of-possession (POPO) with self-signature of the certTemplate 340 according to [RFC4211] section 4.1 clause 3 is the recommended 341 default POPO method (deviations are possible by EEs when 342 requesting central key generation and by (L)RAs when using 343 raVerified), 345 o confirmation of newly enrolled certificates may be omitted, and 347 o all PKI management operations consist of request-response message 348 pairs originating at the EE, i.e., announcement messages are 349 omitted. 351 The profile specified in this document is compatible with the CMP 352 profile for UMTS, LTE, and 5G network domain security and 353 authentication framework [ETSI-3GPP], except that: 355 o protection of initial PKI management operations may be HMAC-based, 357 o the subject name is mandatory in certificate templates, and 359 o confirmation of newly enrolled certificates may be omitted. 361 The profile specified in this document is compatible with the CMP 362 profile for on-line key management in rail networks as specified in 363 UNISIG subset-137 [UNISIG], except that: 365 o As stated in Section 4.1.1 a CMP message SHALL only consist of one 366 certificate request (CertReqMsg). Therefore, UNISIG is in 367 conflict with this document as subset-137 allows to transport more 368 than one certificate request. 370 o as of RFC 4210 [RFC4210] the messageTime is required to be 371 Greenwich Mean Time coded as generalizedTime (Note: While UNISIG 372 explicitly states that the messageTime in required to be 'UTC 373 time', it is not clear if this means a coding as UTCTime or 374 generalizedTime and if other time zones than Greenwich Mean Time 375 shall be allowed. Therefore, UNISG may be in conflict with 376 RFC 4210 [RFC4210]. Both time formats are described in RFC 5280 377 [RFC5280] section 4.1.2.5.), and 379 o in case the request message is MAC protected, also the response, 380 certConf, and pkiConf messages have a MAC-based protection (Note: 381 if changing to signature protection of the response the caPubs 382 field cannot be used securely anymore.). 384 1.5. Scope of this document 386 This document specifies requirements on generating PKI management 387 messages on the sender side. It does not specify strictness of 388 verification on the receiving side and how in detail to handle error 389 cases. 391 Especially on the EE side this profile aims at a lightweight protocol 392 that can be implemented on more constrained devices. On the side of 393 the central PKI management entities the profile accepts higher 394 resources needed. 396 For the sake of robustness and preservation of security properties 397 implementations should, as far as security is not affected, adhere to 398 Postel's law: "Be conservative in what you do, be liberal in what you 399 accept from others" (often reworded as: "Be conservative in what you 400 send, be liberal in what you accept"). 402 When in Section 3, Section 4, and Section 5 a field of the ASN.1 403 syntax as defined in RFC 4210 [RFC4210] and RFC 4211 [RFC4211] is not 404 explicitly specified, it SHOULD not be used by the sending entity. 405 The receiving entity MUST NOT require its absence and if present MUST 406 gracefully handle its presence. 408 1.6. Structure of this document 410 Section 2 introduces the general PKI architecture and approach to 411 certificate management using CMP that is assumed in this document. 412 Then it enlists the PKI management operations specified in this 413 document and describes them in general words. The list of supported 414 PKI management operations is divided into mandatory, recommended, and 415 optional ones. 417 Section 3 profiles the CMP message header, protection, and extraCerts 418 section as they are general elements of CMP messages. 420 Section 4 profiles the exchange of CMP messages between an EE and the 421 first PKI management entities. There are various flavors of 422 certificate enrollment requests optionally with polling, revocation, 423 error handling, and general support PKI management operations. 425 Section 5 profiles the exchange between PKI management entities. 426 These are in the first place the forwarding of messages coming from 427 or going to an EE. This includes also initiating delayed delivery of 428 messages, which involves polling. Additionally, it specifies PKI 429 management operations where a PKI management entity manages 430 certificates on behalf of an EE or for itself. 432 Section 6 outlines different mechanisms for CMP message transfer, 433 namely http-based transfer as already specified in [RFC6712], using 434 an additional TLS layer, or offline file-based transport. CoAP 435 [RFC7252] and piggybacking CMP messages on other protocols is out of 436 scope and left for further documents. 438 1.7. Convention and Terminology 440 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 441 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 442 document are to be interpreted as described in RFC 2119 [RFC2119]. 444 In this document, these words will appear with that interpretation 445 only when in ALL CAPS. Lower case use of these words are not to be 446 interpreted as carrying significance described in RFC 2119. 448 Technical terminology is used in conformance with RFC 4210 [RFC4210], 449 RFC 4211 [RFC4211], RFC 5280 [RFC5280], and IEEE 802.1AR 450 [IEEE802.1AR]. The following key words are used: 452 CA: Certification authority, which issues certificates. 454 RA: Registration authority, an optional system component to which a 455 CA delegates certificate management functions such as 456 authorization checks. 458 LRA: Local registration authority, an optional RA system component 459 with proximity to the end entities. 461 KGA: Key generation authority, an optional system component, 462 typically co-located with an LRA, RA, or CA, that offers key 463 generation services to end entities. 465 EE: End entity, a user, device, or service that holds a PKI 466 certificate. An identifier for the EE is given as the subject 467 of its certificate. 469 The following terminology is reused from RFC 4210 [RFC4210] and used 470 as follows: 472 PKI management operation: All CMP messages belonging to one 473 transaction context. The transaction is 474 identified in the transactionID field of 475 the message header. 477 PKI management entity: All central PKI entities like LRA, RA and 478 CA. 480 PKI entity: EEs and PKI management entities 482 2. Architecture and use cases 484 2.1. Solution architecture 486 Typically, a machine EE will be equipped with a manufacturer issued 487 certificate during production. Such a manufacturer issued 488 certificate is installed during production to identify the device 489 throughout its lifetime. This manufacturer certificate can be used 490 to protect the initial enrollment of operational certificates after 491 installation of the EE in a plant or industrial network. An 492 operational certificate is issued by the owner or operator of the 493 device to identify the device during operation, e.g., within a 494 security protocol like IPSec, TLS, or SSH. In IEEE 802.1AR 495 [IEEE802.1AR] a manufacturer certificate is called IDevID certificate 496 and an operational certificate is called LDevID certificate. 498 All certificate management transactions specified in this document 499 are initiated by the EE. The EE creates a CMP request message, 500 protects it using its manufacturer or operational certificate, if 501 available, and sends it to its locally reachable PKI component. This 502 PKI component may be an LRA, RA, or the CA, which checks the request, 503 responds to it itself, or forwards the request upstream to the next 504 PKI component. In case an (L)RA changes the CMP request message 505 header or body or wants to prove a successful verification or 506 authorization, it can apply a protection of its own. Especially the 507 communication between an LRA and RA can be performed synchronously or 508 asynchronously. Synchronous communication describes a timely 509 uninterrupted communication between two communication partners, while 510 asynchronous communication is not performed in a timely consistent 511 manner, e.g., because of a delayed message delivery. 513 +-----+ +-----+ +-----+ +-----+ 514 | | | | | | | | 515 | EE |<---------->| LRA |<-------------->| RA |<---------->| CA | 516 | | | | | | | | 517 +-----+ +-----+ +-----+ +-----+ 519 synchronous (a)synchronous (a)synchronous 520 +----connection----+------connection------+----connection----+ 522 on site at operators service partner 523 +----------plant---------+-----backend services-----+-trust center-+ 525 Figure 1: Certificate management on site 527 In operation environments a layered LRA-RA-CA architecture can be 528 deployed, e.g., with LRAs bundling requests from multiple EEs at 529 dedicated locations and one (or more than one) central RA aggregating 530 the requests from multiple LRAs. Every (L)RA in this scenario will 531 have its own dedicated certificate containing an extended key usage 532 as specified in CMP Updates [I-D.ietf-lamps-cmp-updates] and private 533 key allowing it to protect CMP messages it processes (CMP signing 534 key/certificate). The figure above shows an architecture using one 535 LRA and one RA. It is also possible to have only an RA or multiple 536 LRAs and/or RAs. Depending on the network infrastructure, the 537 communication between different PKI management entities may be 538 synchronous online communication, delayed asynchronous communication, 539 or even offline file transfer. 541 This profile focusses on specifying the pull model, where the EE 542 always requests a specific PKI management operation. CMP response 543 messages, especially in case of central key generation, as described 544 in Section 4.1.6, could also be used proactively to implement the 545 push model towards the EE. 547 Third-party CAs typically implement different variants of CMP or even 548 use proprietary interfaces for certificate management. Therefore, 549 the LRA or the RA may need to adapt the exchanged CMP messages to the 550 flavor of communication required by the CA. 552 2.2. Basic generic CMP message content 554 Section 3 specifies the generic parts of the CMP messages as used 555 later in Section 4 and Section 5. 557 o Header of a CMP message; see Section 3.1. 559 o Protection of a CMP message; see Section 3.2. 561 o ExtraCerts field of a CMP message; see Section 3.3. 563 2.3. Supported PKI management operations 565 Following the outlined scope from Section 1.5, this section gives a 566 brief overview of the PKI management operations specified in 567 Section 4 and Section 5 and points out whether an implementation by 568 compliant EE or PKI management entities is mandatory, recommended or 569 optional. 571 2.3.1. Mandatory PKI management operations 573 The mandatory PKI management operations in this document shall limit 574 the overhead of certificate management for more constrained devices 575 to the most crucial types of operations. 577 Section 4 - End Entity focused PKI management operations 579 o Request a certificate from a new PKI with signature protection; 580 see Section 4.1.1. 582 o Request to update an existing certificate with signature 583 protection; see Section 4.1.3. 585 o Error reporting; see Section 4.3. 587 Section 5 - LRA and RA focused PKI management operations 589 o Forward messages without changes; see Section 5.1.1. 591 o Forward messages with replaced protection and keeping the original 592 proof-of-possession; see Section 5.1.2.1. 594 o Forward messages with replaced protection and raVerified as proof- 595 of-possession; see Section 5.1.2.2. 597 o Error reporting; see Section 5.3. 599 2.3.2. Recommended PKI management operations 601 Additional recommended PKI management operations shall support some 602 more complex scenarios, that are considered as beneficial for 603 environments with more specific boundary conditions. 605 Section 4 - End Entity focused PKI management operations 607 o Request a certificate from a PKI with MAC protection; see 608 Section 4.1.4. 610 o Revoke an own certificate. 612 Section 5 - LRA and RA focused PKI management operations 614 o Revoke another's entities certificate. 616 2.3.3. Optional PKI management operations 618 The optional PKI management operations support specific requirements 619 seen only in a subset of environments. 621 Section 4 - End Entity focused PKI management operations 623 o Request a certificate from a trusted PKI with signature 624 protection; see Section 4.1.2. 626 o Request a certificate from a legacy PKI using a PKCS#10 [RFC2986] 627 request; see Section 4.1.5. 629 o Add central generation of a key pair to a certificate request; see 630 Section 4.1.6. If central key generation is supported, the key 631 agreement key management technique is REQUIRED to be supported, 632 and the key transport and symmetric key-encryption key management 633 techniques are OPTIONAL. 635 o Handle delayed enrollment due to asynchronous message delivery; 636 see Section 4.1.7. 638 o Additional support messages, e.g., to update a root CA certificate 639 or to request an RFC 8366 [RFC8366] voucher; see Section 4.4. 641 Section 5 - LRA and RA focused PKI management operations 643 o Forward messages with additional protection; see Section 5.1.3 645 o Initiate delayed enrollment due to asynchronous message delivery; 646 see Section 5.1.4. 648 2.4. CMP message transport 650 On different links between PKI entities, e.g., EE<->RA and RA<->CA, 651 different transport MAY be used. As CMP has only very limited 652 requirement regarding the mechanisms used for message transport and 653 in different environments different transport mechanisms are 654 supported, e.g. HTTP, CoAP, or even offline files based, this 655 document requires no specific transport protocol to be supported by 656 all conforming implementations. 658 HTTP transfer is RECOMMENDED to use for all PKI entities, but there 659 is no transport specified as mandatory to be flexible for devices 660 with special constraints to choose whatever transport is suitable. 662 Recommended transport 663 o Transfer CMP messages using HTTP; see Section 6.2. 665 Optional transport 667 o Transfer CMP messages using HTTPS with certificate-based 668 authentication; see Section 6.3. 670 o Transfer CMP messages using HTTPS with shared-secret based 671 protection; see Section 6.4. 673 o File-based CMP message transport. 675 3. Generic parts of the PKI message 677 To reduce redundancy in the text and to ease implementation, the 678 contents of the header, protection, and extraCerts fields of the CMP 679 messages used in the transactions specified in Section 4 and 680 Section 5 are standardized to the maximum extent possible. 681 Therefore, the generic parts of a CMP message are described centrally 682 in this section. 684 As described in section 5.1 of [RFC4210], all CMP messages have the 685 following general structure: 687 +--------------------------------------------+ 688 | PKIMessage | 689 | +----------------------------------------+ | 690 | | header | | 691 | +----------------------------------------+ | 692 | +----------------------------------------+ | 693 | | body | | 694 | +----------------------------------------+ | 695 | +----------------------------------------+ | 696 | | protection (OPTIONAL) | | 697 | +----------------------------------------+ | 698 | +----------------------------------------+ | 699 | | extraCerts (OPTIONAL) | | 700 | +----------------------------------------+ | 701 +--------------------------------------------+ 703 Figure 2: CMP message structure 705 The general contents of the message header, protection, and 706 extraCerts fields are specified in the Section 3.1 to Section 3.3. 708 In case a specific CMP message needs different contents in the 709 header, protection, or extraCerts fields, the differences are 710 described in the respective message. 712 The CMP message body contains the message-specific information. It 713 is described in the context of Section 4 and Section 5. 715 The behavior in case an error occurs while handling a CMP message is 716 described in Section 5.3. 718 3.1. General description of the CMP message header 720 This section describes the generic header field of all CMP messages 721 with signature-based protection. The only variations described here 722 are in the fields recipient, transactionID, and recipNonce of the 723 first message of a PKI management operation. 725 In case a message has MAC-based protection the changes are described 726 in the respective section. The variations will affect the fields 727 sender, protectionAlg, and senderKID. 729 For requirements about proper random number generation please refer 730 to [RFC4086]. Any message-specific fields or variations are 731 described in the respective sections of this chapter. 733 header 734 pvno REQUIRED 735 -- MUST be set to 2 to indicate CMP V2 736 sender REQUIRED 737 -- MUST be the subject of the protection certificate used for, 738 -- the certificate for the private key used to sign the message 739 recipient REQUIRED 740 -- SHOULD be the name of the intended recipient and 741 -- MAY be a NULL_DN if the sender does not know the DN of 742 -- the recipient 743 -- If this is the first message of a transaction: SHOULD be the 744 -- subject of the issuing CA certificate 745 -- In all other messages: SHOULD be the same name as in the 746 -- sender field of the previous message in this transaction 747 messageTime RECOMMENDED 748 -- MUST be the time at which the message was produced, if 749 -- present 750 protectionAlg REQUIRED 751 -- MUST be the algorithm identifier of the signature algorithm or 752 -- id-PasswordBasedMac algorithm used for calculation of the 753 -- protection bits 754 -- The signature algorithm MUST be consistent with the 755 -- subjectPublicKeyInfo field of the signer's certificate 756 -- The hash algorithm used SHOULD be SHA-256 757 algorithm REQUIRED 758 -- MUST be the OID of the signature algorithm, like 759 -- sha256WithRSAEncryption or ecdsa-with-SHA256, or 760 -- id-PasswordBasedMac 761 senderKID RECOMMENDED 762 -- MUST be the SubjectKeyIdentifier, if available, of the 763 -- protection certificate 764 transactionID REQUIRED 765 -- If this is the first message of a transaction: 766 -- MUST be 128 bits of random data for the start of a 767 -- transaction to reduce the probability of having the 768 -- transactionID already in use at the server 769 -- In all other messages: 770 -- MUST be the value from the previous message in the same 771 -- transaction 772 senderNonce REQUIRED 773 -- MUST be fresh 128 random bits 774 recipNonce RECOMMENDED 775 -- If this is the first message of a transaction: SHOULD be 776 -- absent 777 -- In all other messages: MUST be present and contain the value 778 -- from senderNonce of the previous message in the same 779 -- transaction 780 generalInfo OPTIONAL 781 implicitConfirm OPTIONAL 782 -- The field is optional though it only applies to 783 -- ir/cr/kur/p10cr requests and ip/cp/kup response messages 784 -- Add to request messages to request omit sending certConf 785 -- message 786 -- Add to response messages to confirm omit sending certConf 787 -- message 788 ImplicitConfirmValue REQUIRED 789 -- ImplicitConfirmValue of the request message MUST be NULL if 790 -- the EE wants to request not to send a confirmation message 791 -- ImplicitConfirmValue MUST be set to NULL if the (L)RA/CA 792 -- wants to grant not sending a confirmation message 794 3.2. General description of the CMP message protection 796 This section describes the generic protection field of all CMP 797 messages with signature-based protection. The certificate for the 798 private key used to sign a CMP message is called 'protection 799 certificate'. 801 protection RECOMMENDED 802 -- MUST contain the signature calculated using the signature 803 -- algorithm specified in protectionAlg 805 Generally, CMP message protection is required for CMP messages, but 806 there are cases where protection of error messages as specified in 807 Section 4.3 and Section 5.3 is not possible and therefore MAY be 808 omitted. 810 For MAC-based protection as specified in Section 4.1.4 major 811 differences apply as described in the respective section. 813 The CMP message protection provides, if available, message origin 814 authentication and integrity protection for the CMP message header 815 and body. The CMP message extraCerts is not covered by this 816 protection. 818 NOTE: The extended key usages specified in CMP Updates 819 [I-D.ietf-lamps-cmp-updates] can be used for authorization of a 820 sending PKI management entity. 822 NOTE: The requirements for checking certificates given in [RFC5280] 823 MUST be followed for the CMP message protection. In case the CMP 824 signer certificate is not the CA certificate that signed the newly 825 issued certificate, certificate status checking SHOULD be used for 826 the CMP signer certificates of communication partners. 828 3.3. General description of CMP message extraCerts 830 This section describes the generic extraCerts field of all CMP 831 messages with signature-based protection. If extraCerts are 832 required, recommended, or optional is specified in the respective PKI 833 management operation. 835 extraCerts 836 -- SHOULD contain the protection certificate together with its 837 -- chain, if needed and the self-signed root certificate SHOULD 838 -- be omitted 839 -- If present, the first certificate in this field MUST 840 -- be the protection certificate and each following certificate 841 -- SHOULD directly certify the one immediately preceding it. 842 -- Self-signed certificates SHOULD be omitted from extraCerts 843 -- and MUST NOT be trusted based on the listing in extraCerts 844 -- in any case 846 Note: For maximum compatibility, all implementations SHOULD be 847 prepared to handle potentially additional and arbitrary orderings of 848 the certificates, except that the protection certificate is the first 849 certificate in extraCerts. 851 4. End Entity focused PKI management operations 853 This chapter focuses on the communication of the EE and the first PKI 854 management entities it talks to. Depending on the network and PKI 855 solution, this will either be the LRA, the RA or the CA. 857 Profiles of the Certificate Management Protocol (CMP) [RFC4210] 858 handled in this section cover the following PKI management 859 operations: 861 o Requesting a certificate from a PKI with variations like initial 862 requests and updating, central key generation and different 863 protection means 865 o Revocation of a certificate 867 o General messages for further support functions 869 These operations mainly specify the message body of the CMP messages 870 and utilize the specification of the message header, protection and 871 extraCerts as specified in Section 4. 873 The behavior in case an error occurs is described in Section 4.3. 875 This chapter is aligned to Appendix D and Appendix E of [RFC4210]. 876 The general rules for interpretation stated in Appendix D.1 in 877 [RFC4210] need to be applied here, too. 879 This document does not mandate any specific supported algorithms like 880 Appendix D.2 of [RFC4210], [ETSI-3GPP], and [UNISIG] do. Using the 881 message sequences described here require agreement upon the 882 algorithms to support and thus the algorithm identifiers for the 883 specific target environment. 885 4.1. Requesting a new certificate from a PKI 887 There are different approaches to request a certificate from a PKI. 889 These approaches differ on the one hand in the way the EE can 890 authenticate itself to the PKI it wishes to get a new certificate 891 from and on the other hand in its capabilities to generate a proper 892 new key pair. The authentication means may be as follows: 894 o Using a certificate from a trusted PKI and the corresponding 895 private key, e.g., a manufacturer issued certificate 897 o Using the certificate to be updated and the corresponding private 898 key 900 o Using a shared secret known to the EE and the PKI 902 Typically, such EE requests a certificate from a CA. When the PKI 903 management entity responds with a message containing a certificate, 904 the EE MUST reply with a confirmation message. The PKI management 905 entity then MUST send confirmation back, closing the transaction. 907 The message sequences in this section allow the EE to request 908 certification of a locally generated public-private key pair. For 909 requirements about proper random number and key generation please 910 refer to [RFC4086]. The EE MUST provide a signature-based proof-of- 911 possession of the private key associated with the public key 912 contained in the certificate request as defined by [RFC4211] section 913 4.1 case 3. To this end it is assumed that the private key can 914 technically be used as signing key. The most commonly used 915 algorithms are RSA and ECDSA, which can technically be used for 916 signature calculation regardless of potentially intended restrictions 917 of the key usage. 919 The requesting EE provides the binding of the proof-of-possession to 920 its identity by signature-based or MAC-based protection of the CMP 921 request message containing that POPO. The PKI management entity 922 needs to verify whether this EE is authorized to obtain a certificate 923 with the requested subject and other fields and extensions. 924 Especially when removing the protection provided by the EE and 925 applying a new protection, the PKI management entity MUST verify in 926 particular the included proof-of-possession self-signature of the 927 certTemplate using the public key of the requested certificate and 928 MUST check that the EE, as authenticated by the message protection, 929 is authorized to request a certificate with the subject as specified 930 in the certTemplate (see Section 5.1.2). 932 There are several ways to install the Root CA certificate of a new 933 PKI on an EE. The installation can be performed in an out-of-band 934 manner, using general messages, a voucher [RFC8366], or other formats 935 for enrollment, or in-band of CMP by the caPubs field in the 936 certificate response message. In case the installation of the new 937 root CA certificate is performed using the caPubs field, the 938 certificate response message MUST be properly authenticated, and the 939 sender of this message MUST be authorized to install new root CA 940 certificates on the EE. This authorization can be indicated by using 941 pre-shared keys for the CMP message protection. 943 4.1.1. Request a certificate from a new PKI with signature protection 945 This PKI management operation should be used by an EE to request a 946 certificate of a new PKI using an existing certificate from an 947 external PKI, e.g., a manufacturer certificate, to prove its identity 948 to the new PKI. The EE already has established trust in this new PKI 949 it is about to enroll to, e.g., by voucher exchange or configuration 950 means. The initialization request message is signature-protected 951 using the existing certificate. 953 Preconditions: 955 1 The EE MUST have a certificate enrolled by an external PKI in 956 advance to this PKI management operation to authenticate itself to 957 the PKI management entity using signature-based protection, e.g., 958 using a manufacturer issued certificate. 960 2 The EE SHOULD know the subject name of the new CA it requests a 961 certificate from; this name MAY be established using an enrollment 962 voucher, the issuer field from a the CertReqTemplate response 963 message, or other configuration means. If the EE does not know 964 the name of the CA, the PKI management entity MUST know where to 965 route this request to. 967 3 The EE MUST authenticate responses from the PKI management entity; 968 trust MAY be established using an enrollment voucher or other 969 configuration means. 971 4 The PKI management entity MUST trust the external PKI the EE uses 972 to authenticate itself; trust MAY be established using some 973 configuration means. 975 This PKI management operation is like that given in [RFC4210] 976 Appendix E.7. 978 Message flow: 980 Step# EE PKI management entity 981 1 format ir 982 2 -> ir -> 983 3 handle, re-protect or 984 forward ir 985 4 format or receive ip 986 5 possibly grant implicit 987 confirm 988 6 <- ip <- 989 7 handle ip 990 8 In case of status 991 "rejection" in the 992 ip message, no certConf 993 and pkiConf are sent 994 9 format certConf (optional) 995 10 -> certConf -> 996 11 handle, re-protect or 997 forward certConf 998 12 format or receive pkiConf 999 13 <- pkiconf <- 1000 14 handle pkiConf (optional) 1002 For this PKI management operation, the EE MUST include exactly one 1003 single CertReqMsg in the ir. If more certificates are required, 1004 further requests MUST be sent using separate CMP messages. If the EE 1005 wants to omit sending a certificate confirmation message after 1006 receiving the ip to reduce the number of protocol messages exchanged 1007 in this PKI management operation, it MUST request this by including 1008 the implicitConfirm extension in the ir. 1010 If the CA accepts the certificate request it MUST return the new 1011 certificate in the certifiedKeyPair field of the ip message. If the 1012 EE requested to omit sending a certConf message after receiving the 1013 ip, the PKI management entity MAY confirm it by also including the 1014 implicitConfirm extension or MAY rejects it by omitting the 1015 implicitConfirm field in the ip. 1017 If the EE did not request implicit confirmation or the request was 1018 not granted by the PKI management entity the confirmation as follows 1019 MUST be performed. If the EE successfully receives the certificate 1020 and accepts it, the EE MUST send a certConf message, which MUST be 1021 answered by the PKI management entity with a pkiConf message. If the 1022 PKI management entity does not receive the expected certConf message 1023 in time it MUST handle this like a rejection by the EE. 1025 If the certificate request was refused by the CA, the PKI management 1026 entity must return an ip message containing the status code 1027 "rejection" and no certifiedKeyPair field. Such an ip message MUST 1028 NOT be followed by the certConf and pkiConf messages. 1030 Detailed message description: 1032 Certification Request -- ir 1034 Field Value 1036 header 1037 -- As described in section 3.1 1039 body 1040 -- The request of the EE for a new certificate 1041 ir REQUIRED 1042 -- MUST be exactly one CertReqMsg 1043 -- If more certificates are required, further requests MUST be 1044 -- packaged in separate PKI Messages 1045 certReq REQUIRED 1046 certReqId REQUIRED 1047 -- MUST be set to 0 1048 certTemplate REQUIRED 1049 version OPTIONAL 1050 -- MUST be 2 if supplied. 1051 subject REQUIRED 1052 -- MUST contain the suggested subject name of the EE 1053 -- certificate 1054 publicKey REQUIRED 1055 algorithm REQUIRED 1056 -- MUST include the subject public key algorithm ID and value 1057 -- In case a central key generation is requested, this field 1058 -- contains the algorithm and parameter preferences of the 1059 -- requesting entity regarding the to-be-generated key pair 1060 subjectPublicKey REQUIRED 1061 -- MUST contain the public key to be included into the requested 1062 -- certificate in case of local key-generation 1063 -- MUST contain a zero-length BIT STRING in case a central key 1064 -- generation is requested 1065 -- MUST include the subject public key algorithm ID and value 1066 extensions OPTIONAL 1067 -- MAY include end-entity-specific X.509 extensions of the 1068 -- requested certificate like subject alternative name, 1069 -- key usage, and extended key usage 1070 Popo REQUIRED 1071 POPOSigningKey OPTIONAL 1072 -- MUST be used in case subjectPublicKey contains a public key 1073 -- MUST be absent in case subjectPublicKey contains a 1074 -- zero-length BIT STRING 1075 poposkInput PROHIBITED 1076 -- MUST NOT be used because subject and publicKey are both 1077 -- present in the certTemplate 1078 algorithmIdentifier REQUIRED 1079 -- The signature algorithm MUST be consistent with the 1080 -- publicKey field of the certTemplate 1081 -- The hash algorithm used SHOULD be SHA-256 1082 signature REQUIRED 1083 -- MUST be the signature computed over the DER-encoded 1084 -- certTemplate 1086 protection REQUIRED 1087 -- As described in section 3.2 1089 extraCerts REQUIRED 1090 -- As described in section 3.3 1092 Certification Response -- ip 1094 Field Value 1096 header 1097 -- As described in section 3.1 1099 body 1100 -- The response of the CA to the request as appropriate 1101 ip REQUIRED 1102 caPubs OPTIONAL 1103 -- MAY be used 1104 -- If used it MUST contain only the root certificate of the 1105 -- certificate contained in certOrEncCert 1106 response REQUIRED 1107 -- MUST be exactly one CertResponse 1108 certReqId REQUIRED 1109 -- MUST be set to 0 1110 status REQUIRED 1111 -- PKIStatusInfo structure MUST be present 1112 status REQUIRED 1113 -- positive values allowed: "accepted", "grantedWithMods" 1114 -- negative values allowed: "rejection" 1115 -- In case of rejection certConf and pkiConf messages MUST NOT 1116 -- be sent 1117 statusString OPTIONAL 1118 -- MAY be any human-readable text for debugging, logging or to 1119 -- display in a GUI 1120 failInfo OPTIONAL 1121 -- MUST be present if status is "rejection" and in this case 1122 -- the transaction MUST be terminated 1123 -- MUST be absent if the status is "accepted" or 1124 -- "grantedWithMods" 1125 certifiedKeyPair OPTIONAL 1126 -- MUST be present if status is "accepted" or "grantedWithMods" 1127 -- MUST be absent if status is "rejection" 1128 certOrEncCert REQUIRED 1129 -- MUST be present when certifiedKeyPair is present 1130 certificate REQUIRED 1131 -- MUST be present when certifiedKeyPair is present 1132 -- MUST contain the newly enrolled X.509 certificate 1133 privateKey OPTIONAL 1134 -- MUST be absent in case of local key-generation 1135 -- MUST contain the encrypted private key in an EnvelopedData 1136 -- structure as specified in section 5.1.5 in case the private 1137 -- key was generated centrally 1139 protection REQUIRED 1140 -- As described in section 3.2 1142 extraCerts REQUIRED 1143 -- As described in section 3.3 1144 -- MUST contain the chain of the certificate present in 1145 -- certOrEncCert, the self-signed root certificate SHOULD be 1146 -- omitted 1147 -- Duplicate certificates MAY be omitted 1149 Certificate Confirmation -- certConf 1151 Field Value 1153 header 1154 -- As described in section 3.1 1156 body 1157 -- The message of the EE sends confirmation to the PKI 1158 -- management entity to accept or reject the issued certificates 1159 certConf REQUIRED 1160 -- MUST be exactly one CertStatus 1161 CertStatus REQUIRED 1162 certHash REQUIRED 1163 -- MUST be the hash of the certificate, using the same hash 1164 -- algorithm as used to create the certificate signature 1165 certReqId REQUIRED 1166 -- MUST be set to 0 1167 status RECOMMENDED 1168 -- PKIStatusInfo structure SHOULD be present 1169 -- Omission indicates acceptance of the indicated certificate 1170 status REQUIRED 1171 -- positive values allowed: "accepted" 1172 -- negative values allowed: "rejection" 1173 statusString OPTIONAL 1174 -- MAY be any human-readable text for debugging, logging, or to 1175 -- display in a GUI 1176 failInfo OPTIONAL 1177 -- MUST be present if status is "rejection" 1178 -- MUST be absent if the status is "accepted" 1180 protection REQUIRED 1181 -- As described in section 3.2 1182 -- MUST use the same certificate as for protection of the ir 1184 extraCerts RECOMMENDED 1185 -- SHOULD contain the protection certificate together with its 1186 -- chain, but MAY be omitted if the message size is critical and 1187 -- the PKI management entity did cash the extraCerts from the ir 1188 -- If present, the first certificate in this field MUST be the 1189 -- certificate used for signing this message 1190 -- Self-signed certificates SHOULD NOT be included in 1191 -- extraCerts and 1192 -- MUST NOT be trusted based on the listing in extraCerts in 1193 -- any case 1195 PKI Confirmation -- pkiconf 1197 Field Value 1199 header 1200 -- As described in section 3.1 1202 body 1203 pkiconf REQUIRED 1204 -- The content of this field MUST be NULL 1206 protection REQUIRED 1207 -- As described in section 3.2 1208 -- SHOULD use the same certificate as for protection of the ip 1210 extraCerts RECOMMENDED 1211 -- SHOULD contain the protection certificate together with its 1212 -- chain, but MAY be omitted if the message size is critical and 1213 -- the PKI management entity did cash the extraCerts from the ip 1214 -- If present, the first certificate in this field MUST be the 1215 -- certificate used for signing this message 1216 -- Self-signed certificates SHOULD NOT be included in extraCerts 1217 -- and 1218 -- MUST NOT be trusted based on the listing in extraCerts in 1219 -- any case 1221 4.1.2. Request a certificate from a trusted PKI with signature 1222 protection 1224 This PKI management operation should be used by an EE to request an 1225 additional certificate of the same PKI it already has certificates 1226 from. The EE uses one of these existing certificates to prove its 1227 identity. The certificate request message is signature-protected 1228 using this certificate. 1230 The general message flow for this PKI management operation is the 1231 same as given in Section 4.1.1. 1233 Preconditions: 1235 1 The EE MUST have a certificate enrolled by the PKI it requests 1236 another certificate from in advance to this PKI management 1237 operation to authenticate itself to the PKI management entity 1238 using signature-based protection. 1240 2 The EE SHOULD know the subject name of the CA it requests a 1241 certificate from; this name MAY be established using an enrollment 1242 voucher, the issuer field from a the CertReqTemplate response 1243 message, or other configuration means. If the EE does not know 1244 the name of the CA, the PKI management entity MUST know where to 1245 route this request to. 1247 3 The EE MUST authenticate responses from the PKI management entity; 1248 trust MUST be established using an enrollment voucher or other 1249 configuration means. 1251 4 The PKI management entity MUST trust the current PKI; trust MAY be 1252 established using some configuration means. 1254 The message sequence for this PKI management operation is like that 1255 given in [RFC4210] Appendix D.5. 1257 The message sequence for this PKI management operation is identical 1258 to that given in Section 4.1.1, with the following changes: 1260 1 The body of the first request and response MUST be cr and cp, 1261 respectively. 1263 2 The caPubs field in the cp message SHOULD be absent. 1265 4.1.3. Update an existing certificate with signature protection 1267 This PKI management operation should be used by an EE to request an 1268 update of one of the certificates it already has and that is still 1269 valid. The EE uses the certificate it wishes to update to prove its 1270 identity and possession of the private key for the certificate to be 1271 updated to the PKI. Therefore, the key update request message is 1272 signed using the certificate that is to be updated. 1274 The general message flow for this PKI management operation is the 1275 same as given in Section 4.1.1. 1277 Preconditions: 1279 1 The certificate the EE wishes to update MUST NOT be expired or 1280 revoked. 1282 2 A new public-private key pair SHOULD be used. 1284 The message sequence for this PKI management operation is like that 1285 given in [RFC4210] Appendix D.6. 1287 The message sequence for this PKI management operation is identical 1288 to that given in Section 4.1.1, with the following changes: 1290 1 The body of the first request and response MUST be kur and kup, 1291 respectively. 1293 2 Protection of the kur MUST be performed using the certificate to 1294 be updated. 1296 3 The subject field of the CertTemplate MUST contain the subject 1297 name of the existing certificate to be updated, without 1298 modifications. 1300 4 The CertTemplate MUST contain the subject, issuer and publicKey 1301 fields only. 1303 5 The oldCertId control SHOULD be used to make clear, even in case 1304 an (L)RA changes the message protection, which certificate is to 1305 be updated. 1307 6 The caPubs field in the kup message MUST be absent. 1309 As part of the certReq structure of the kur the control is added 1310 right after the certTemplate. 1312 controls 1313 type RECOMMENDED 1314 -- MUST be the value id-regCtrl-oldCertID, if present 1315 value 1316 issuer REQUIRED 1317 serialNumber REQUIRED 1318 -- MUST contain the issuer and serialNumber of the certificate 1319 -- to be updated 1321 4.1.4. Request a certificate from a PKI with MAC protection 1323 This PKI management operation should be used by an EE to request a 1324 certificate of a new PKI without having a certificate to prove its 1325 identity to the target PKI, but there is a shared secret established 1326 between the EE and the PKI. Therefore, the initialization request is 1327 MAC-protected using this shared secret. The PKI management entity 1328 checking the MAC-protection SHOULD replace this protection according 1329 to Section 5.1.2 in case the next hop does not know the shared 1330 secret. 1332 For requirements with regard to proper random number and key 1333 generation please refer to [RFC4086]. 1335 The general message flow for this PKI management operation is the 1336 same as given in Section 4.1.1. 1338 Preconditions: 1340 1 The EE and the PKI management entity MUST share a symmetric key, 1341 this MAY be established by a service technician during initial 1342 local configuration. 1344 2 The EE SHOULD know the subject name of the new CA it requests a 1345 certificate from; this name MAY be established using an enrollment 1346 voucher, the issuer field from a the CertReqTemplate response 1347 message, or other configuration means. If the EE does not know 1348 the name of the CA, the PKI management entity MUST know where to 1349 route this request to. 1351 3 The EE MUST authenticate responses from the PKI management entity; 1352 trust MAY be established using the shared symmetric key. 1354 The message sequence for this PKI management operation is like that 1355 given in [RFC4210] Appendix D.4. 1357 The message sequence for this PKI management operation is identical 1358 to that given in Section 4.1.1, with the following changes: 1360 1 The protection of all messages MUST be calculated using Message 1361 Authentication Code (MAC); the protectionAlg field MUST be id- 1362 PasswordBasedMac as described in section 5.1.3.1 of [RFC4210]. 1364 2 The sender MUST contain a name representing the originator of the 1365 message. The senderKID MUST contain a reference all participating 1366 entities can use to identify the symmetric key used for the 1367 protection, e.g., the username of the EE. 1369 3 The extraCerts of the ir, certConf, and pkiConf messages MUST be 1370 absent. 1372 4 The extraCerts of the ip message MUST contain the chain of the 1373 issued certificate and root certificates SHOULD not be included 1374 and MUST NOT be directly trusted in any case. 1376 Part of the protectionAlg structure, where the algorithm identifier 1377 MUST be id-PasswordBasedMac, is a PBMParameter sequence. The fields 1378 of PBMParameter SHOULD remain constant for message protection 1379 throughout this PKI management operation to reduce the computational 1380 overhead. 1382 PBMParameter REQUIRED 1383 salt REQUIRED 1384 -- MUST be the random value to salt the secret key 1385 owf REQUIRED 1386 -- MUST be the algorithm identifier for the one-way function 1387 -- used 1388 -- The one-way function SHA-1 MUST be supported due to 1389 -- [RFC4211] requirements, but SHOULD NOT be used any more 1390 -- SHA-256 SHOULD be used instead 1391 iterationCount REQUIRED 1392 -- MUST be a limited number of times the one-way function is 1393 -- applied 1394 -- To prevent brute force and dictionary attacks a reasonable 1395 -- high number SHOULD be used 1396 mac REQUIRED 1397 -- MUST be the algorithm identifier of the MAC algorithm used 1398 -- The MAC function HMAC-SHA1 MUST be supported due to 1399 -- [RFC4211] requirements, but SHOULD NOT be used any more 1400 -- HMAC-SHA-256 SHOULD be used instead 1402 4.1.5. Request a certificate from a legacy PKI using PKCS#10 request 1404 This PKI management operation should be used by an EE to request a 1405 certificate of a legacy PKI only capable to process PKCS#10 [RFC2986] 1406 certification requests. The EE can prove its identity to the target 1407 PKI by using various protection means as described in Section 4.1.1 1408 or Section 4.1.4. 1410 In contrast to the other PKI management operations described in 1411 Section 4.1, this transaction uses PKCS#10 [RFC2986] instead of CRMF 1412 [RFC4211] for the certificate request for compatibility reasons with 1413 legacy CA systems that require a PKCS#10 certificate request and 1414 cannot process CRMF [RFC4211] requests. In such case the PKI 1415 management entity MUST extract the PKCS#10 certificate request from 1416 the p10cr and provides it separately to the CA. 1418 The general message flow for this PKI management operation is the 1419 same as given in Section 4.1.1, but the public key is contained in 1420 the subjectPKInfo of the PKCS#10 certificate request. 1422 Preconditions: 1424 1 The EE MUST either have a certificate enrolled from this or any 1425 other accepted PKI, or a shared secret known to the PKI and the EE 1426 to authenticate itself to the RA. 1428 2 The EE SHOULD know the subject name of the CA it requests a 1429 certificate from; this name MAY be established using an enrollment 1430 voucher, the issuer field from a the CertReqTemplate response 1431 message, or other configuration means. If the EE does not know 1432 the name of the CA, the RA MUST know where to route this request 1433 to. 1435 3 The EE MUST authenticate responses from the RA; trust MAY be 1436 established by an available root certificate, using an enrollment 1437 voucher, or other configuration means. 1439 4 The RA MUST trust the current or the PKI the EE uses to 1440 authenticate itself; trust MAY be established by a corresponding 1441 available root certificate or using some configuration means. 1443 The message sequence for this PKI management operation is identical 1444 to that given in Section 4.1.1, with the following changes: 1446 1 The body of the first request and response MUST be p10cr and cp, 1447 respectively. 1449 2 The certReqId in the cp message MUST be 0. 1451 3 The caPubs field in the cp message SHOULD be absent. 1453 Detailed description of the p10cr message: 1455 Certification Request -- p10cr 1457 Field Value 1459 header 1460 -- As described in section 3.1 1462 body 1463 -- The request of the EE for a new certificate using a PKCS#10 1464 -- certificate request 1465 p10cr REQUIRED 1466 certificationRequestInfo REQUIRED 1467 version REQUIRED 1468 -- MUST be set to 0 to indicate PKCS#10 V1.7 1469 subject REQUIRED 1470 -- MUST contain the suggested subject name of the EE 1471 subjectPKInfo REQUIRED 1472 algorithm REQUIRED 1473 -- MUST include the subject public key algorithm ID 1474 subjectPublicKey REQUIRED 1475 -- MUST include the subject public key algorithm value 1476 attributes OPTIONAL 1477 -- MAY contain a set of end-entity-specific fields or X.509 1478 -- extensions to be included in the requested certificate or used 1479 -- otherwise 1480 signatureAlgorithm REQUIRED 1481 -- The signature algorithm MUST be consistent with the 1482 -- subjectPKInfo field. The hash algorithm used SHOULD be SHA-256 1483 signature REQUIRED 1484 -- MUST containing the self-signature for proof-of-possession 1486 protection REQUIRED 1487 -- As described in section 3.2 1489 extraCerts REQUIRED 1490 -- As described in section 3.3 1492 4.1.6. Generate the key pair centrally at the PKI management entity 1494 This functional extension can be applied in combination with 1495 certificate enrollment as described in Section 4.1.1 and 1496 Section 4.1.4. The functional extension can be used in case an EE is 1497 not able or is not willing to generate its new public-private key 1498 pair itself. It is a matter of the local implementation which PKI 1499 management entity will perform the key generation. This entity MUST 1500 have a certificate containing the additional extended key usage 1501 extension id-kp-cmcKGA to be identified by the EE as a legitimate 1502 key-generation authority. In case the PKI management entity 1503 generated the new key pair for the EE, it can use Section 4.1.1 to 1504 Section 4.1.4 to request the certificate for this key pair as usual. 1506 Generally speaking, in a machine-to-machine scenario it is strongly 1507 preferable to generate public-private key pairs locally at the EE. 1508 Together with proof-of-possession of the private key in the 1509 certification request, this is to make sure that only the entity 1510 identified in the newly issued certificate is the only entity who 1511 ever hold the private key. 1513 There are some cases where an EE is not able or not willing to 1514 locally generate the new key pair. Reasons for this may be the 1515 following: 1517 o Lack of sufficient initial entropy. 1519 Note: Good random numbers are not only needed for key generation, but 1520 also for session keys and nonces in any security protocol. 1521 Therefore, we believe that a decent security architecture should 1522 anyways support good random number generation on the EE side or 1523 provide enough entropy for the RNG seed during manufacturing to 1524 guarantee good initial pseudo-random number generation. 1526 o Due to lack of computational resources, e.g., in case of RSA keys. 1528 Note: As key generation can be performed in advance to the 1529 certificate enrollment communication, it is typical not time 1530 critical. 1532 Note: Besides the initial enrollment right after the very first 1533 bootup of the device, where entropy available on the device may be 1534 insufficient, we do not see any good reason for central key 1535 generation. 1537 Note: As mentioned in Section 2.1 central key generation may be 1538 required in a push model, where the certificate response message is 1539 transferred by the PKI management entity to the EE without receiving 1540 a previous request message. 1542 If the EE wishes to request central key generation, it MUST fill the 1543 subjectPublicKey field in the certTemplate structure of the request 1544 message with a zero-length BIT STRING. This indicates to the PKI 1545 management entity that a new key pair shall be generated centrally on 1546 behalf of the EE. 1548 Note: As the protection of centrally generated keys in the response 1549 message is being extended from EncryptedValue to EncryptedKey by CMP 1550 Updates [I-D.ietf-lamps-cmp-updates] also the alternative 1551 EnvelopedData can be used. In CRMF Section 2.1.9 [RFC4211] the use 1552 of EncryptedValue has been deprecated in favor of the EnvelopedData 1553 structure. Therefore, this profile specifies using EnvelopedData as 1554 specified in CMS Section 6 [RFC5652] to offer more crypto agility. 1556 +------------------------------+ 1557 | EnvelopedData | 1558 | [RFC5652] section 6 | 1559 | +--------------------------+ | 1560 | | SignedData | | 1561 | | [RFC5652] section 5 | | 1562 | | +----------------------+ | | 1563 | | | privateKey | | | 1564 | | | OCTET STRING | | | 1565 | | +----------------------+ | | 1566 | +--------------------------+ | 1567 +------------------------------+ 1569 Figure 3: Encrypted private key container 1571 The PKI management entity delivers the private key in the privateKey 1572 field in the certifiedKeyPair structure of the response message also 1573 containing the newly issued certificate. 1575 The private key MUST be wrapped in a SignedData structure, as 1576 specified in CMS Section 5 [RFC5652], signed by the KGA generating 1577 the key pair. The signature MUST be performed using a CMP signer 1578 certificate asserting the extended key usage kp-id-cmpKGA as 1579 described in CMP Updates [I-D.ietf-lamps-cmp-updates] to show the 1580 authorization to generate key pairs on behalf of an EE. 1582 This SignedData structure MUST be wrapped in an EnvelopedData 1583 structure, as specified in CMS Section 6 [RFC5652], encrypting it 1584 using a newly generated symmetric content-encryption key. 1586 Note: Instead of the specification in CMP Appendix D 4.4 [RFC4210] 1587 this content-encryption key is not generated on the EE side. As we 1588 just mentioned, central key generation should only be used in this 1589 profile in case of lack of randomness on the EE. 1591 As part of the EnvelopedData structure this content-encryption key 1592 MUST be securely provided to the EE using one of three key management 1593 techniques. The choice of the key management technique to be used by 1594 the PKI management entity depends on the authentication mechanism the 1595 EE choose to protect the request message, see CMP Updates section 3.4 1597 [I-D.ietf-lamps-cmp-updates] for more details on which key management 1598 technique to use. 1600 o MAC protected request message: The content-encryption key SHALL be 1601 protected using the password-based key management technique, see 1602 Section 4.1.6.3, only if the EE used MAC protection for the 1603 respected request message. 1605 o Signature protected request message using a certificate that 1606 contains a key usage extension asserting keyAgreement: The 1607 content-encryption key SHALL be protected using the key agreement 1608 key management technique, see Section 4.1.6.1, if the certificate 1609 used by the EE for signing the respective request message contains 1610 the key usage keyAgreement. If the certificate also contains the 1611 key usage keyEncipherment, the key transport key management 1612 technique SHALL NOT be used. 1614 o Signature protected request message using a certificate that 1615 contains a key usage extension asserting keyEncipherment: The 1616 content-encryption key SHALL be protected using the key transport 1617 key management technique, see Section 4.1.6.2, if the certificate 1618 used by the EE for signing the respective request message contains 1619 the key usage keyEncipherment and not keyAgreement. 1621 The key agreement key management technique can be supported by most 1622 signature algorithms, as key transport key management technique can 1623 only be supported by a very limited number of algorithms. The 1624 password-based key management technique shall only be used in 1625 combination with MAC protection, which is a side-line in this 1626 document. Therefore, if central key generation is supported, the 1627 support of the key agreement key management technique is REQUIRED and 1628 the support of key transport and password-based key management 1629 techniques are OPTIONAL. 1631 For encrypting the SignedData structure containing the private key a 1632 fresh content-encryption key MUST be generated with enough entropy 1633 with regard to the used symmetric key-encryption algorithm. 1635 Note: Depending on the lifetime of the certificate and the 1636 criticality of the generated private key, it is advisable to use the 1637 strongest available symmetric encryption algorithm. Therefore, this 1638 specification recommends using at least AES-256. 1640 The detailed description of the privateKey field looks like this: 1642 privateKey OPTIONAL 1643 -- MUST be an EnvelopedData structure as specified in 1644 -- CMS [RFC5652] section 6 1645 version REQUIRED 1646 -- MUST be set to 2 1647 recipientInfos REQUIRED 1648 -- MUST be exactly one RecipientInfo 1649 recipientInfo REQUIRED 1650 -- MUST be either KeyAgreeRecipientInfo (see section 5.1.5.1), 1651 -- KeyTransRecipientInfo (see section 5.1.5.2), or 1652 -- PasswordRecipientInfo (see section 5.1.5.3) is used 1653 -- If central key generation is supported, support of 1654 -- KeyAgreeRecipientInfo is REQUIRED and support of 1655 -- KeyTransRecipientInfo and PasswordRecipientInfo are OPTIONAL 1656 encryptedContentInfo 1657 REQUIRED 1658 contentType REQUIRED 1659 -- MUST be id-signedData 1660 contentEncryptionAlgorithm 1661 REQUIRED 1662 -- MUST be the algorithm identifier of the symmetric 1663 -- content-encryption algorithm used 1664 -- As private keys need long-term protection, the use of AES-256 1665 -- or a stronger symmetric algorithm is RECOMMENDED 1666 encryptedContent REQUIRED 1667 -- MUST be the signedData structure as specified in 1668 -- CMS [RFC5652] section 5 in encrypted form 1669 version REQUIRED 1670 -- MUST be set to 3 1671 digestAlgorithms 1672 REQUIRED 1673 -- MUST be exactly one digestAlgorithm identifier 1674 digestAlgorithmIdentifier 1675 REQUIRED 1676 -- MUST be the OID of the digest algorithm used for generating 1677 -- the signature 1678 -- The hash algorithm used SHOULD be SHA-256 1679 encapContentInfo 1680 REQUIRED 1681 -- MUST be the content that is to be signed 1682 contentType REQUIRED 1683 -- MUST be id-data 1684 content REQUIRED 1685 -- MUST be the privateKey as OCTET STRING 1686 certificates REQUIRED 1687 -- SHOULD contain the certificate, for the private key used 1688 -- to sign the content, together with its chain 1689 -- If present, the first certificate in this field MUST 1690 -- be the certificate used for signing this content 1691 -- Self-signed certificates SHOULD NOT be included 1692 -- and MUST NOT be trusted based on the listing in any case 1693 crls OPTIONAL 1694 -- MAY be present to provide status information on the signer or 1695 -- its CA certificates 1696 signerInfos REQUIRED 1697 -- MUST be exactly one signerInfo 1698 version REQUIRED 1699 -- MUST be set to 3 1700 sid REQUIRED 1701 subjectKeyIdentifier 1702 REQUIRED 1703 -- MUST be the subjectKeyIdentifier of the signer's certificate 1704 digestAlgorithm 1705 REQUIRED 1706 -- MUST be the same OID as in digest algorithm 1707 signatureAlgorithm 1708 REQUIRED 1709 -- MUST be the algorithm identifier of the signature algorithm 1710 -- used for calculation of the signature bits, 1711 -- like sha256WithRSAEncryption or ecdsa-with-SHA256 1712 -- The signature algorithm MUST be consistent with the 1713 -- subjectPublicKeyInfo field of the signer's certificate 1714 signature REQUIRED 1715 -- MUST be the result of the digital signature generation 1717 4.1.6.1. Using key agreement key management technique 1719 This key management technique can be applied in combination with the 1720 PKI management operations specified in Section 4.1.1 to Section 4.1.3 1721 using signature-based protected CMP messages. The public key of the 1722 EE certificate used for the signature-based protection of the request 1723 message MUST also be used for the Ephemeral-Static Diffie-Hellmann 1724 key establishment of the content-encryption key. To use this key 1725 management technique the KeyAgreeRecipientInfo structure MUST be used 1726 in the contentInfo field. 1728 The KeyAgreeRecipientInfo structure included into the EnvelopedData 1729 structure is specified in CMS Section 6.2.2 [RFC5652]. 1731 The detailed description of the KeyAgreeRecipientInfo structure looks 1732 like this: 1734 recipientInfo REQUIRED 1735 -- MUST be KeyAgreeRecipientInfo as specified in 1736 version REQUIRED 1737 -- MUST be set to 3 1738 originator REQUIRED 1739 -- MUST contain the originatorKey sequence 1740 algorithm REQUIRED 1741 -- MUST be the algorithm identifier of the 1742 -- static-ephemeral Diffie-Hellmann algorithm 1743 publicKey REQUIRED 1744 -- MUST be the ephemeral public key of the sending party 1745 ukm OPTIONAL 1746 -- MUST be used when 1-pass ECMQV is used 1747 keyEncryptionAlgorithm 1748 REQUIRED 1749 -- MUST be the same as in the contentEncryptionAlgorithm field 1750 recipientEncryptedKeys 1751 REQUIRED 1752 -- MUST be exactly one recipientEncryptedKey sequence 1753 recipientEncryptedKey 1754 REQUIRED 1755 rid REQUIRED 1756 rKeyId REQUIRED 1757 subjectKeyID 1758 REQUIRED 1759 -- MUST contain the same value as the senderKID in the 1760 -- respective request messages 1761 encryptedKey 1762 REQUIRED 1763 -- MUST be the encrypted content-encryption key 1765 4.1.6.2. Using key transport key management technique 1767 This key management technique can be applied in combination with the 1768 PKI management operations specified in Section 4.1.1 to Section 4.1.3 1769 using signature-based protected CMP messages. The public key of the 1770 EE certificate used for the signature-based protection of the request 1771 message MUST also be used for key encipherment of the content- 1772 encryption key. To use this key management technique the 1773 KeyTransRecipientInfo structure MUST be used in the contentInfo 1774 field. 1776 The KeyTransRecipientInfo structure included into the EnvelopedData 1777 structure is specified in CMS Section 6.2.1 [RFC5652]. 1779 The detailed description of the KeyTransRecipientInfo structure looks 1780 like this: 1782 recipientInfo REQUIRED 1783 -- MUST be KeyTransRecipientInfo as specified in 1784 -- CMS section 6.2.1 [RFC5652] 1785 version REQUIRED 1786 -- MUST be set to 2 1787 rid REQUIRED 1788 subjectKeyIdentifier 1789 REQUIRED 1790 -- MUST contain the same value as the senderKID in the respective 1791 -- request messages 1792 keyEncryptionAlgorithm 1793 REQUIRED 1794 -- MUST contain the key encryption algorithm identifier used for 1795 -- public key encryption 1796 encryptedKey REQUIRED 1797 -- MUST be the encrypted content-encryption key 1799 4.1.6.3. Using password-based key management technique 1801 This key management technique can be applied in combination with the 1802 PKI management operation specified in Section 4.1.4 using MAC 1803 protected CMP messages. The shared secret used for the MAC 1804 protection MUST also be used for the encryption of the content- 1805 encryption key but with a different salt. To use this key management 1806 technique the PasswordRecipientInfo structure MUST be used in the 1807 contentInfo field. 1809 The PasswordRecipientInfo structure included into the EnvelopedData 1810 structure is specified in CMS Section 6.2.3 [RFC5652]. 1812 The detailed description of the PasswordRecipientInfo structure looks 1813 like this: 1815 recipientInfo REQUIRED 1816 -- MUST be PasswordRecipientInfo as specified in 1817 -- CMS section 6.2.4 [RFC5652] 1818 version REQUIRED 1819 -- MUST be set to 0 1820 keyDerivationAlgorithm 1821 REQUIRED 1822 -- MUST be set to id-PBKDF2 as specified in [RFC8018] 1823 -- The same shared secret MUST be used than used in 1824 -- PBMParameter data structure for the MAC protection in the 1825 -- header of this message 1826 salt REQUIRED 1827 -- MUST be the random value to salt the secret key 1828 -- MUST be a different value than used in the PBMParameter 1829 -- data structure of the CMP message protection in the 1830 -- header of this message 1831 iterationCount 1832 REQUIRED 1833 -- MUST be a limited number of times the OWF is applied 1834 -- To prevent brute force and dictionary attacks a reasonable 1835 -- high number SHOULD be used 1836 keyLength REQUIRED 1837 prf REQUIRED 1838 -- MUST be the algorithm identifier of the underlying 1839 -- pseudorandom function 1840 -- The pseudorandom function HMAC-SHA1 MUST be supported 1841 -- due to [RFC8018] requirements, but SHOULD NOT be used any 1842 -- more HMAC-SHA-256 SHOULD be used instead 1843 keyEncryptionAlgorithm 1844 REQUIRED 1845 -- MUST be the same as in the contentEncryptionAlgorithm field 1846 encryptedKey REQUIRED 1847 -- MUST be the encrypted content-encryption key 1849 4.1.7. Delayed enrollment 1851 This functional extension can be applied in combination with 1852 certificate enrollment as described in Section 4.1.1 to 1853 Section 4.1.5. The functional extension can be used in case a PKI 1854 management entity cannot respond to the certificate request in a 1855 timely manner, e.g., due to offline upstream communication or 1856 required registration officer interaction. Depending on the PKI 1857 architecture, it is not necessary that the PKI management entity 1858 directly communicating with the EE initiates the delayed enrollment. 1860 The PKI management entity initiating the delayed enrollment MUST 1861 include the status "waiting" in the response and this response MUST 1862 NOT contain a newly issued certificate. When receiving a response 1863 with status "waiting" the EE MUST send a poll request to the PKI 1864 management entity. The PKI management entity that initiated the 1865 delayed enrollment MUST answers with a poll response containing a 1866 checkAfter time. This value indicates the minimum number of seconds 1867 that must elapse before the EE sends another poll request. As soon 1868 as the PKI management entity can provide the final response message 1869 for the initial request of the EE, it MUST provide this in response 1870 to a poll request. After receiving this response, the EE can 1871 continue the original PKI management operation as described in the 1872 respective section of this document, e.g., send a certConf message. 1874 Typically, intermediate PKI management entities SHOULD NOT change the 1875 sender and recipient nonce even in case an intermediate PKI 1876 management entity modifies a request or a response message. In the 1877 special case of polling between EE and LRA with offline transport 1878 between an LRA and RA, see Section 5.1.4, an exception occurs. The 1879 EE and LRA exchange pollReq and pollRep messages handle the nonce 1880 words as described. When, after pollRep, the final response from the 1881 CA arrives at the LRA, the next response will contain the recipNonce 1882 set to the value of the senderNonce in the original request message 1883 (copied by the CA). The LRA needs to replace the recipNonce in this 1884 case with the senderNonce of the last pollReq because the EE will 1885 validate it in this way. 1887 Message flow: 1889 Step# EE PKI management entity 1890 1 format ir/cr/p10cr/kur 1891 As described in the 1892 respective section 1893 in this document 1894 2 ->ir/cr/p10cr/kur-> 1895 3 handle request as described 1896 in the respective section 1897 in this document 1898 4 in case no immediate final 1899 response is possible, 1900 receive or format ip, cp 1901 or kup message containing 1902 status "waiting" 1903 5 <- ip/cp/kup <- 1904 6 handle ip/cp/kup 1905 7 format pollReq 1906 8 -> pollReq -> 1907 9 handle, re-protect or 1908 forward pollReq 1909 10 in case the requested 1910 certificate or a 1911 corresponding response 1912 message is available, 1913 receive or format ip, cp, 1914 or kup containing the 1915 issued certificate, or 1916 format or receive pollRep 1917 with appropriate 1918 checkAfter value 1919 11 <- pollRep <- 1920 12 handle pollRep 1921 13 let checkAfter 1922 time elapse 1923 14 continue with line 7 1925 Detailed description of the first ip/cp/kup: 1927 Response with status 'waiting' -- ip/cp/kup 1929 Field Value 1931 header 1932 -- MUST contain a header as described for the first response 1933 -- message of the respective PKI management operation 1935 body 1936 -- The response of the PKI management entity to the request in 1937 -- case no immediate appropriate response can be sent 1938 ip/cp/kup REQUIRED 1939 response REQUIRED 1940 -- MUST be exactly one CertResponse 1941 certReqId REQUIRED 1942 -- MUST be set to 0 1943 status REQUIRED 1944 -- PKIStatusInfo structure MUST be present 1945 status REQUIRED 1946 -- MUST be set to "waiting" 1947 statusString OPTIONAL 1948 -- MAY be any human-readable text for debugging, logging or to 1949 -- display in a GUI 1950 failInfo PROHIBITED 1951 certifiedKeyPair PROHIBITED 1953 protection REQUIRED 1954 -- MUST contain protection as described for the first response 1955 -- message of the respective PKI management operation, but 1956 -- MUST use the protection key of the PKI management entity 1957 -- initiating the delayed enrollment and creating this response 1958 -- message 1960 extraCerts REQUIRED 1961 -- MUST contain certificates as described for the first response 1962 -- message of the respective PKI management operation. 1963 -- As no new certificate is issued yet, no respective certificate 1964 -- chain is included 1966 Polling Request -- pollReq 1968 Field Value 1970 header 1971 -- MUST contain a header as described for the certConf message 1972 -- of the respective PKI management operation 1974 body 1975 -- The message of the EE asks for the final response or for a 1976 -- time to check again 1977 pollReq REQUIRED 1978 certReqId REQUIRED 1979 -- MUST be exactly one value 1980 -- MUST be set to 0 1982 protection REQUIRED 1983 -- MUST contain protection as described for the certConf message 1984 -- of the respective PKI management operation 1986 extraCerts OPTIONAL 1987 -- If present, it MUST contain certificates as described for the 1988 -- certConf message of the respective PKI management operation 1990 Polling Response -- pollRep 1992 Field Value 1994 header 1995 -- MUST contain a header as described for the pkiConf message 1996 -- of the respective PKI management operation 1998 body pollRep 1999 -- The message indicated the time to after which the EE may 2000 -- send another pollReq messaged for this transaction 2001 pollRep REQUIRED 2002 -- MUST be exactly one set of the following values 2003 certReqId REQUIRED 2004 -- MUST be set to 0 2005 checkAfter REQUIRED 2006 -- time in seconds to elapse before a new pollReq may be sent by 2007 -- the EE 2009 protection REQUIRED 2010 -- MUST contain protection as described for the pkiConf message 2011 -- of the respective profile, but 2012 -- MUST use the protection key of the PKI management entity that 2013 -- initiated the delayed enrollment and is creating this response 2014 -- message 2016 extraCerts OPTIONAL 2017 -- If present, it MUST contain certificates as described for the 2018 -- pkiConf message of the respective PKI management operation. 2020 Final response -- ip/cp/kup 2022 Field Value 2024 header 2025 -- MUST contain a header as described for the first 2026 -- response message of the respective PKI management operation, 2027 -- but the recipNonce MUST be the senderNonce of the last 2028 -- pollReq message 2030 body 2031 -- The response of the PKI management entity to the initial 2032 -- request as described in the respective PKI management 2033 -- operation 2035 protection REQUIRED 2036 -- MUST contain protection as described for the first response 2037 -- message of the respective PKI management operation, but 2038 -- MUST use the protection key of the PKI management entity that 2039 -- initiated the delayed enrollment and forwarding the response 2040 -- message 2042 extraCerts REQUIRED 2043 -- MUST contain certificates as described for the first 2044 -- response message of the respective PKI management operation 2046 4.2. Revoking a certificate 2048 This PKI management operation should be used by an entity to request 2049 the revocation of a certificate. Here the revocation request is used 2050 by an EE to revoke one of its own certificates. A PKI management 2051 entity could also act as an EE to revoke one of its own certificates. 2053 The revocation request message MUST be signed using the certificate 2054 that is to be revoked to prove the authorization to revoke to the 2055 PKI. The revocation request message is signature-protected using 2056 this certificate. 2058 An EE requests the revocation of an own certificate at the CA that 2059 issued this certificate. The PKI management entity responds with a 2060 message that contains the status of the revocation from the CA. 2062 Preconditions: 2064 1 The certificate the EE wishes to revoke is not yet expired or 2065 revoked. 2067 Message flow: 2069 Step# EE PKI management entity 2070 1 format rr 2071 2 -> rr -> 2072 3 handle, re-protect or 2073 forward rr 2074 4 receive rp 2075 5 <- rp <- 2076 6 handle rp 2078 For this PKI management operation, the EE MUST include exactly one 2079 RevDetails structure in the rr message body. In case no error 2080 occurred the response to the rr MUST be a rp message. The PKI 2081 management entity MUST produce a rp containing a status field with a 2082 single set of values. 2084 Detailed message description: 2086 Revocation Request -- rr 2088 Field Value 2090 header 2091 -- As described in section 3.1 2093 body 2094 -- The request of the EE to revoke its certificate 2095 rr REQUIRED 2096 -- MUST contain exactly one element of type RevDetails 2097 -- If more revocations are desired, further requests MUST be 2098 -- packaged in separate PKI Messages 2099 certDetails REQUIRED 2100 -- MUST be present and is of type CertTemplate 2101 serialNumber REQUIRED 2102 -- MUST contain the certificate serialNumber attribute of the 2103 -- X.509 certificate to be revoked 2104 issuer REQUIRED 2105 -- MUST contain the issuer attribute of the X.509 certificate to 2106 -- be revoked 2107 crlEntryDetails REQUIRED 2108 -- MUST contain exactly one reasonCode of type CRLReason (see 2109 -- [RFC5280] section 5.3.1) 2110 -- If the reason for this revocation is not known or shall not be 2111 -- published the reasonCode MUST be 0 = unspecified 2113 protection REQUIRED 2114 -- As described in section 3.2 and the private key related to the 2115 -- certificate to be revoked 2117 extraCerts REQUIRED 2118 -- As described in section 3.3 2120 Revocation Response -- rp 2122 Field Value 2124 header 2125 -- As described in section 3.1 2127 body 2128 -- The responds of the PKI management entity to the request as 2129 -- appropriate 2130 rp REQUIRED 2131 status REQUIRED 2132 -- MUST contain exactly one element of type PKIStatusInfo 2133 status REQUIRED 2134 -- positive value allowed: "accepted" 2135 -- negative value allowed: "rejection" 2136 statusString OPTIONAL 2137 -- MAY be any human-readable text for debugging, logging or to 2138 -- display in a GUI 2139 failInfo OPTIONAL 2140 -- MAY be present if and only if status is "rejection" 2142 protection REQUIRED 2143 -- As described in section 3.2 2145 extraCerts REQUIRED 2146 -- As described in section 3.3 2148 4.3. Error reporting 2150 This functionality should be used by an EE to report any error 2151 conditions upstream to the PKI management entity. Error reporting by 2152 a PKI management entity downstream to the EE is described in 2153 Section 5.3. 2155 In case the error condition is related to specific details of an ip, 2156 cp, or kup response message and a confirmation is expected the error 2157 condition MUST be reported in the respective certConf message with 2158 negative contents. 2160 General error conditions, e.g., problems with the message header, 2161 protection, or extraCerts, and negative feedback on rp, pollRep, or 2162 pkiConf messages MAY be reported in the form of an error message. 2164 In both situations the EE reports error in the PKIStatusInfo 2165 structure of the respective message. 2167 Depending on the PKI architecture, the PKI management entity MUST 2168 forward the error message (upstream) to the next PKI management 2169 entity and MUST terminate this PKI management operation. 2171 The PKIStatusInfo structure is used to report errors. The 2172 PKIStatusInfo structure SHOULD consist of the following fields: 2174 o status: Here the PKIStatus value "rejection" is the only one 2175 allowed. 2177 o statusString: Here any human-readable valid value for logging or 2178 to display in a GUI SHOULD be added. 2180 o failInfo: Here the PKIFailureInfo values MAY be used in the 2181 following way. For explanation of the reason behind a specific 2182 value, please refer to [RFC4210] Appendix F. 2184 * transactionIdInUse: This is sent by a PKI management entity in 2185 case the received request contains a transaction ID that is 2186 already in use for another transaction. An EE receiving such 2187 error message SHOULD resend the request in a new transaction 2188 using a different transaction ID. 2190 * systemUnavail or systemFailure: This is sent by a PKI 2191 management entity in case a back-end system is not available or 2192 currently not functioning correctly. An EE receiving such 2193 error message SHOULD resend the request in a new transaction 2194 after some time. 2196 Detailed error message description: 2198 Error Message -- error 2200 Field Value 2202 header 2203 -- As described in section 3.1 2205 body 2206 -- The message sent by the EE or the (L)RA/CA to indicate an 2207 -- error that occurred 2208 error REQUIRED 2209 pKIStatusInfo REQUIRED 2210 status REQUIRED 2211 -- MUST have the value "rejection" 2212 statusString RECOMMENDED 2213 -- SHOULD be any human-readable text for debugging, logging 2214 -- or to display in a GUI 2215 failInfo OPTIONAL 2216 -- MAY be present 2218 protection REQUIRED 2219 -- As described in section 3.2 2221 extraCerts OPTIONAL 2222 -- As described in section 3.3 2224 4.4. Support messages 2226 The following support messages offer on demand in-band transport of 2227 content that may be provided by the PKI management entity and 2228 relevant to the EE. The general messages and general response are 2229 used for this purpose. Depending on the environment, these requests 2230 may be answered by the LRA, RA, or CA. 2232 The general message and general response transport InfoTypeAndValue 2233 structures. In addition to those infoType values defined in CMP 2234 [RFC4210] further OIDs MAY be defined to define new PKI management 2235 operations, or general-purpose support messages as needed in a 2236 specific environment. 2238 Content specified in this document is describs the following: 2240 o Request of CA certificates 2242 o Update of Root CA certificates 2243 o Parameters needed for a planned certificate request message 2245 4.4.1. General message and response 2247 The PKI management operation is similar to that given in CMP 2248 Appendix E.5 [RFC4210]. In this section the general message (genm) 2249 and general response (genp) are described. The specific 2250 InfoTypeAndValue structures are described in the following sections. 2252 The behavior in case an error occurs is described in Section 4.3. 2254 Message flow: 2256 Step# EE PKI management entity 2257 1 format genm 2258 2 -> genm -> 2259 3 handle, re-protect or 2260 forward genm 2261 4 format or receive genp 2262 5 <- genp <- 2263 6 handle genp 2265 Detailed message description: 2267 General Message -- genm 2269 Field Value 2271 header 2272 -- As described in section 3.1 2274 body 2275 -- The request of the EE to receive information 2276 genm REQUIRED 2277 -- MUST contain exactly one element of type 2278 -- InfoTypeAndValue 2279 infoType REQUIRED 2280 -- MUST be the OID identifying the specific PKI 2281 -- management operation described below 2282 infoValue OPTIONAL 2283 -- MUST be as described in the specific PKI 2284 -- management operation described below 2286 protection REQUIRED 2287 -- As described in section 3.2 2289 extraCerts REQUIRED 2290 -- As described in section 3.3 2292 General Response -- genp 2294 Field Value 2296 header 2297 -- As described in section 3.1 2299 body 2300 -- The response of the PKI management entity to the 2301 -- information request 2302 genp REQUIRED 2303 -- MUST contain exactly one element of type 2304 -- InfoTypeAndValue 2305 infoType REQUIRED 2306 -- MUST be the OID identifying the specific PKI 2307 -- management operation described below 2308 infoValue OPTIONAL 2309 -- MUST be as described in the specific PKI 2310 -- management operation described below 2312 protection REQUIRED 2313 -- As described in section 3.2 2315 extraCerts REQUIRED 2316 -- As described in section 3.3 2318 4.4.2. Get CA certificates 2320 This PKI management operation can be used by an EE to request CA 2321 certificates from the PKI management entity. 2323 An EE requests CA certificates from the PKI management entity by 2324 sending a general message with OID id-it-caCerts. The PKI management 2325 entity responds with a general response with the same OID that either 2326 contains a SEQUENCE of certificates populated with the available CA 2327 intermediate and issuing CA certificates or with no content in case 2328 no CA certificate is available. 2330 The message sequence for this PKI management operation is as given in 2331 Section 4.4.1, with the following specific content: 2333 1 the body MUST contain as infoType the OID id-it-caCerts 2335 2 the infoValue of the request MUST be absent 2337 3 if present, the infoValue of the response MUST be caCerts field 2338 The infoValue field of the general response containing the id-it- 2339 caCerts OID looks like this: 2341 infoValue OPTIONAL 2342 -- MUST be absent if no CA certificate is available 2343 -- MUST be present if CA certificates are available 2344 -- MUST be a sequence of CMPCertificate 2346 4.4.3. Get root CA certificate update 2348 This PKI management operation can be used by an EE to request an 2349 update of an existing root CA Certificate by the EE. 2351 An EE requests a root CA certificate update from the PKI management 2352 entity by sending a general message with OID id-it-rootCaKeyUpdate as 2353 infoType and no infoValue. The PKI management entity responds with a 2354 general response with the same OID that either contains the update of 2355 the root CA certificate consisting of up to three certificates, or 2356 with no content in case no update is available. 2358 These three certificates are described in more detail in section 2359 4.4.1, section 6.2, and Appendix E.3 of [RFC4210]. The newWithNew 2360 certificate is the new root CA certificates and is REQUIRED to be 2361 present in the response message. The newWithOld certificate is 2362 RECOMMENDED to be present in the response message though it is 2363 REQUIRED for those cases where the receiving entity trusts the old 2364 root CA certificate and wishes to gain trust in the new root CA 2365 certificate. The oldWithNew certificate is OPTIONAL though it is 2366 only needed in a scenario where the requesting entity already trusts 2367 the new root CA certificate and wants to gain trust in the old root 2368 certificate. 2370 The message sequence for this PKI management operation is as given in 2371 Section 4.4.1, with the following specific content: 2373 1 the body MUST contain as infoType the OID id-it-rootCaKeyUpdate 2375 2 the infoValue of the request MUST be absent 2377 3 if present, the infoValue of the response MUST be a 2378 RootCaKeyUpdate structure 2380 The infoValue field of the general response containing the id-it- 2381 rootCaKeyUpdate extension looks like this: 2383 infoValue OPTIONAL 2384 -- MUST be absent if no update of the root CA certificate is 2385 -- available 2386 -- MUST be present if an update of the root CA certificate 2387 -- is available and MUST be of type RootCaKeyUpdate 2388 newWithNew REQUIRED 2389 -- MUST be present if infoValue is present 2390 -- MUST contain the new root CA certificate 2391 newWithOld RECOMMENDED 2392 -- SHOULD be present if infoValue is present 2393 -- MUST contain an X.509 certificate containing the new public 2394 -- root CA key signed with the old private root CA key 2395 oldWithNew OPTIONAL 2396 -- MAY be present if infoValue is present 2397 -- MUST contain an X.509 certificate containing the old public 2398 -- root CA key signed with the new private root CA key 2400 4.4.4. Get certificate request template 2402 This PKI management operation can be used by an EE to request a 2403 template with parameters for a future certificate request operation. 2405 An EE requests certificate request parameters from the PKI management 2406 entity by sending a general message with OID id-it-certReqTemplate. 2407 The PKI management entity responds with a general response with the 2408 same OID that either contains a certificate template with the 2409 required fields and optionally a rsaKeyLen field containing 2410 requirements on, e.g., algorithm identifier for key pair generation 2411 or certificate fields and extensions, or with no content in case no 2412 specific requirements are made by the PKI. 2414 The EE SHOULD follow the requirements from the received CertTemplate 2415 and the optional rsaKeyLen fields, by filling in all the fields 2416 requested and taking over all the field values provided. The EE 2417 SHOULD NOT add further CertTemplate fields, Name components, and 2418 extensions or their (sub-)components. 2420 Note: We deliberately do not use 'MUST' or 'MUST NOT' here in order 2421 to allow more flexibility in case the rules given here are not 2422 sufficient for specific scenarios. The EE can populate the 2423 certificate request as wanted and ignore any of the requirements 2424 contained in the CertReqTemplate response message. On the other 2425 hand, a PKI management entity is free to ignore or replace the 2426 content of the certificate request provided by the EE. The 2427 CertReqTemplate PKI management operation offers means to ease a joint 2428 understanding which fields should be used. 2430 In case a field of type Name, e.g., issuer or subject name, is 2431 present but has the value NULL-DN (i.e., has an empty list of RDN 2432 components) the field SHOULD be included with content provided by the 2433 EE. Similarly, in case an X.509v3 extension is present but its 2434 extnValue is empty this means that the extension SHOULD be included 2435 with content provided by the EE. In case a Name component, for 2436 instance a common name or serial number, is given but has an empty 2437 string value the EE SHOULD fill in a value. Similarly, in case an 2438 extension has sub-components (e.g., an IP address in a SubjectAltName 2439 field) with empty value, the EE SHOULD fill in a value. 2441 The EE MUST ignore (i.e., not include and fill in) empty fields, 2442 extensions, and sub-components that it does not know. 2444 If the publicKey field of type SubjectPublicKeyInfo is present its 2445 algorithm field specifies the type of the public key to request a 2446 certificate for. The algorithm field contains the key type OID of 2447 the public key. For EC keys the full curve information MUST be 2448 specified as described in the respective standard documents. For RSA 2449 keys the key length MUST be specified in the rsaKeyLen field of the 2450 outer infoValue field. The algorithm field MUST be followed by a 2451 zero-length BIT STRING for the subjectPublicKey. If the publicKey 2452 field is not present the EE is free to choose the public key type and 2453 parameters. 2455 In the certTemplate structure the serialNumber, signingAlg, 2456 issuerUID, and subjectUID fields MUST be omitted. 2458 The message sequence for this PKI management operation is as given in 2459 Section 4.4.1, with the following specific content: 2461 1 the body MUST contain as infoType the OID id-it-certReqTemplate 2463 2 the infoValue of the request MUST be absent 2465 3 if present, the infoValue of the response MUST be a SEQUENCE of a 2466 certTemplate structure and an rsaKeyLen field of type INTEGER 2468 The infoValue field of the general response containing the id-it- 2469 certReqTemplate OID looks like this: 2471 InfoValue OPTIONAL 2472 -- MUST be absent if no requirements are available 2473 -- MUST be present if the PKI management entity has any 2474 -- requirements on the content of the certificates template 2475 -- is available and MUST be of type CertReqTemplateValue 2476 certTemplate REQUIRED 2477 -- MUST be present if infoValue is present 2478 -- MUST contain the prefilled certTemplate structure elements 2479 rsaKeyLen OPTIONAL 2480 -- This field is of type INTEGER. Any reasonable RSA key length 2481 -- MUST be specified if the algorithm in the 2482 -- subjectPublicKeyInfo field of the certTemplate has the OID 2483 -- rsaEncryption. 2484 -- MUST be omitted in otherwise. 2486 5. LRA and RA focused PKI management operations 2488 This chapter focuses on the communication among different PKI 2489 management entities. Depending on the network and PKI solution 2490 design, these will either be an LRA, RA or CA. 2492 Typically, a PKI management entity forwards messages from downstream, 2493 but it may also reply to them itself. Besides forwarding of received 2494 messages a PKI management entity could also need to revoke 2495 certificates of EEs, report errors, or may need to manage its own 2496 certificates. 2498 5.1. Forwarding of messages 2500 Each CMP request message (i.e., ir, cr, p10cr, kur, pollReq, or 2501 certConf) or error message coming from an EE or the previous 2502 (downstream) PKI management entity MUST be sent to the next 2503 (upstream) PKI management entity. This PKI management entity MUST 2504 forward response messages to the next (downstream) PKI management 2505 entity or EE. 2507 The PKI management entity SHOULD verify the protection, the syntax, 2508 the required message fields, the message type, and if applicable the 2509 authorization and the proof-of-possession of the message. Additional 2510 checks or actions MAY be applied depending on the PKI solution 2511 requirements and concept. If one of these verification procedures 2512 fails, the (L)RA SHOULD respond with a negative response message and 2513 SHOULD not forward the message further upstream. General error 2514 conditions should be handled as described in Section 4.3 and 2515 Section 5.3. 2517 A PKI management entity SHOULD not change the received message if not 2518 necessary. The PKI management entity SHOULD only update the message 2519 protection if it is technically necessary. Concrete PKI system 2520 specifications may define in more detail if and when to do so. 2522 This is particularly relevant in the upstream communication of a 2523 request message. 2525 Each hop in a chain of PKI management entity has one or more 2526 functionalities, e.g., a PKI management entity 2528 o may need to verify the identities of EEs or base authorization 2529 decisions for certification request processing on specific 2530 knowledge of the local setup, e.g., by consulting an inventory or 2531 asset management system, 2533 o may need to add fields to certificate request messages, 2535 o may need to store data from a message in a database for later 2536 usage or documentation purposes, 2538 o may provide traversal of a network boundary, 2540 o may need to double-check if the messages transferred back and 2541 forth are properly protected and well formed, 2543 o may provide a proof that it has performed all required checks, 2545 o may initiate a delayed enrollment due to offline upstream 2546 communication or registration officer interaction, 2548 o may grant the request of an EE to omit sending a confirmation 2549 message, or 2551 o can collect messages from different LRAs and forward them to the 2552 CA. 2554 Therefore, the decision if a message should be forwarded 2556 o unchanged with the original protection, 2558 o unchanged with a new protection, or 2560 o changed with a new protection 2562 depends on the PKI solution design and the associated security policy 2563 (CP/CPS [RFC3647]). 2565 This section specifies the different options a PKI management entity 2566 may implement and use. 2568 A PKI management entity MAY update the protection of a message 2570 o if it performs changes to the header or the body of the message, 2572 o if it needs to prove checks or validations performed on the 2573 message to one of the next (upstream) PKI components, 2575 o if it needs to protect the message using a key and certificate 2576 from a different PKI, or 2578 o if it needs to replace a MAC based-protection. 2580 This is particularly relevant in the upstream communication of 2581 certificate request messages. 2583 The message protection covers only the header and the body and not 2584 the extraCerts. The PKI management entity MAY change the extraCerts 2585 in any of the following message adaptations, e.g., to sort or add 2586 needed or to delete needless certificates to support the next hop. 2587 This may be particularly helpful to extend upstream messages with 2588 additional certificates or to reduce the number of certificates in 2589 downstream messages when forwarding to constrained devices. 2591 5.1.1. Not changing protection 2593 This alternative to forward a message can be used by any PKI 2594 management entity to forward an original CMP message without changing 2595 the header, body or protection. In any of these cases the PKI 2596 management entity acts more like a proxy, e.g., on a network 2597 boundary, implementing no specific RA-like security functionality to 2598 the PKI. 2600 This alternative to forward a message MUST be used for forwarding kur 2601 messages that must not be approved by the respective PKI management 2602 entity. 2604 5.1.2. Replacing protection 2606 The following two alternatives to forward a message can be used by 2607 any PKI management entity to forward a CMP message with or without 2608 changes, but providing its own protection using its CMP signer key to 2609 assert approval of this message. In this case the PKI management 2610 entity acts as an actual Registration Authority (RA), which 2611 implements important security functionality of the PKI. 2613 Before replacing the existing protection by a new protection, the PKI 2614 management entity MUST verify the protection provided by the EE or by 2615 the previous PKI component and approve its content including any own 2616 modifications. For certificate requests the PKI management entity 2617 MUST verify in particular the included proof-of-possession self- 2618 signature of the certTemplate using the public key of the requested 2619 certificate and MUST check that the EE, as authenticated by the 2620 message protection, is authorized to request a certificate with the 2621 subject as specified in the certTemplate. 2623 In case the received message has been protected by a CA or another 2624 PKI management entity, the current PKI management entity MUST verify 2625 its protection and approve its content including any own 2626 modifications. For certificate requests the PKI management entity 2627 MUST check that the other PKI management entity, as authenticated by 2628 the protection of the incoming message, was authorized to issue or 2629 forward the request. 2631 These message adaptations MUST NOT be applied to kur request messages 2632 as described in Section 4.1.3 since their original protection using 2633 the key and certificate to be updated needs to be preserved, unless 2634 the regCtrl OldCertId is used to clearly identify the certificate to 2635 be updated. 2637 5.1.2.1. Keeping proof-of-possession 2639 This alternative to forward a message can be used by any PKI 2640 management entity to forward a CMP message with or without modifying 2641 the message header or body while preserving any included proof-of- 2642 possession. 2644 By replacing the existing protection using its own CMP signer key the 2645 PKI management entity provides a proof of verifying and approving of 2646 the message as described above. 2648 In case the PKI management entity modifies the certTemplate of an ir 2649 or cr message, the message adaptation in Section 5.1.2.2 needs to be 2650 applied instead. 2652 5.1.2.2. Breaking proof-of-possession 2654 This alternative to forward a message can be used by any PKI 2655 management entity to forward an ir or cr message with modifications 2656 of the certTemplate i.e., modification, addition, or removal of 2657 fields. Such changes will break the proof-of-possession provided by 2658 the EE in the original message. 2660 By replacing the existing using its own CMP signer key the PKI 2661 management entity provides a proof of verifying and approving the new 2662 message as described above. 2664 In addition to the above the PKI management entity MUST verify in 2665 particular the proof-of-possession contained in the original message 2666 as described above. If these checks were successfully performed the 2667 PKI management entity MUST change the popo to raVerified. 2669 The popo field MUST contain the raVerified choice in the certReq 2670 structure of the modified message as follows: 2672 popo 2673 raVerified REQUIRED 2674 -- MUST have the value NULL and indicates that the PKI 2675 -- management entity verified the popo of the original 2676 -- message 2678 5.1.3. Adding Protection 2680 This PKI management operation can be used by a PKI management entity 2681 to add another protection to one or several PKI management messages. 2683 The nested message is a PKI management message containing a 2684 PKIMessages sequence as its body containing one or more CMP messages. 2686 As specified in the updated Section 5.1.3.4 of RFC4210 [RFC4210] (see 2687 Section 3.3 of CMP Updates [I-D.ietf-lamps-cmp-updates]) there are 2688 different use case for adding another protection by a PKI management 2689 entity. Specific procedures are described in more detail in the 2690 following sections. 2692 The behavior in case an error occurs is described in Section 4.3. 2694 Message flow: 2696 Step# PKI management entity PKI management entity 2697 1 format nested 2698 2 -> nested -> 2699 3 handle, re-protect or 2700 forward nested 2701 4 format or receive nested 2702 5 <- nested <- 2703 6 handle nested 2705 Detailed message description: 2707 Nested Message - nested 2709 Field Value 2711 header 2712 -- As described in section 3.1 2714 body nested 2715 -- Container to provide additional protection to original 2716 -- messages and to bundle request or response messages 2717 PKIMessages REQUIRED 2718 -- MUST be a sequence of one or more CMP messages 2720 protection REQUIRED 2721 -- As described in section 3.2 using the CMP signer key of 2722 -- the PKI management entity 2724 extraCerts REQUIRED 2725 -- As described in section 3.3 2727 5.1.3.1. Handling a single PKI management message 2729 A PKI management entity may prove successful validation and 2730 authorization of a PKI management message by adding an additional 2731 signature to the original PKI management message. 2733 A PKI management entity SHALL wrap the original PKI management 2734 messages in a nested message structure. The additional signature as 2735 prove of verification and authorization by the PKI management entity 2736 MUST be applies as signature-based message protection of the nested 2737 message. 2739 5.1.3.2. Handling a batch of PKI management messages 2741 A PKI management entity MAY bundle any number of PKI management 2742 messages for batch processing or to transfer a bulk of PKI management 2743 messages via an offline interface using the nested message structure. 2744 The nested message can be either used on the upstream interface 2745 towards the next PKI management entity as well as on the downstream 2746 interface from the PKI management entity towards the EE. 2748 This PKI management operation is typically used on the interface 2749 between LRA and RA to bundle several PKI management messages for 2750 offline transport. In this case the EE needs to make use of delayed 2751 enrollment as described in Section 4.1.7. If the RA may need 2752 different routing information per nested PKI management message a 2753 suitable mechanism may need to be implemented. This mechanism 2754 strongly depends on the requirements of the target architecture; 2755 therefore, it is out of scope of this document. 2757 An initial nested message is generated locally at the PKI management 2758 entity. For the initial nested message, the PKI management entity 2759 acts as a protocol end point and therefore a fresh transactionId and 2760 a fresh senderNonce MUST be used in the header of the nested message. 2761 The recipient field MUST identify the PKI management entity that is 2762 expected to unpack the nested message. An initial nested message 2763 should contain only request messages, e.g., ir, cr, p10cr, kur, 2764 certConf, rr, or genm. While building the initial nested message the 2765 PKI management entity SHOULD store the transactionIds and the 2766 senderNonces of all bundled messages together with the transactionId 2767 of the initial nested message. 2769 Such an initial nested message is sent to the next PKI management 2770 entity and SHOULD be answered with a responding nested message. This 2771 responding message SHOULD use the transactionId of the initial nested 2772 message and return the senderNonce of the initial nested message as 2773 recipNonce of the responding nested message. The responding nested 2774 message SHOULD bundle one response message (e.g. ip, cp, kup, 2775 pkiconf, rp, genp, error) for each request message (i.e., for each 2776 transactionId) in the initial nested message. While unbundling the 2777 responding nested message it is possible to determine lost and 2778 unexpected responses based on the previously stored transactionIds 2779 and senderNonces. While forwarding the unbundled responses, odd 2780 messages SHOULD be dropped, and lost messages should be replaced by 2781 an error message to inform the EE about the failed certificate 2782 management operation. 2784 The PKI management entity building the nested message applies a 2785 signature-based protection using its CMP-signer key as transport 2786 protection. This protection SHALL NOT be regarded as prove of 2787 verification or authorization of the bundled PKI management messages. 2789 5.1.4. Initiating delayed enrollment 2791 This functional extension can be used by a PKI management entity to 2792 initiate delayed enrollment. In this case a PKI management entity 2793 MUST add the status waiting in the response message. The PKI 2794 management entity MUST then reply to the pollReq messages as 2795 described in Section 4.1.7. 2797 5.2. Revoking certificates on behalf of another's entities 2799 This PKI management operation can be used by a PKI management entity 2800 to revoke a certificate of any other entity. This revocation request 2801 message MUST be signed by the PKI management entity using its own CMP 2802 signer key to prove to the PKI authorization to revoke the 2803 certificate on behalf of the EE. 2805 Preconditions: 2807 1 the certificate to be revoked MUST be known to the PKI management 2808 entity 2810 2 the PKI management entity MUST have the authorization to revoke 2811 the certificates of other entities issued by the corresponding CA 2813 The message sequence for this PKI management operation is identical 2814 to that given in Section 4.2, with the following changes: 2816 1 it is not required that the certificate to be revoked is not yet 2817 expired or revoked 2819 2 the PKI management entity acts as EE for this message exchange 2821 3 the rr messages MUST be signed using the CMP signer key of the PKI 2822 management entity. 2824 5.3. Error reporting 2826 This functionality should be used by the PKI management entity to 2827 report any error conditions downstream to the EE. Potential error 2828 reporting by the EE upstream to the PKI management entity is 2829 described in Section 4.3. 2831 In case the error condition is related to specific details of an ir, 2832 cr, p10cr, or kur request message it MUST be reported in the specific 2833 response message, i.e., an ip, cp, or kup with negative contents. 2835 General error conditions, e.g., problems with the message header, 2836 protection, or extraCerts, and negative feedback on rr, pollReq, 2837 certConf, or error messages MUST be reported in the form of an error 2838 message. 2840 In both situations the PKI management entity reports the errors in 2841 the PKIStatusInfo structure of the respective message as described in 2842 Section 4.3. 2844 An EE receiving any such negative feedback SHOULD log the error 2845 appropriately and MUST terminate the current transaction. 2847 6. CMP message transport variants 2849 The CMP messages are designed to be self-contained, such that in 2850 principle any transport can be used. HTTP SHOULD be used for online 2851 transport while file-based transport MAY be used in case offline 2852 transport is required. In case HTTP transport is not desired or 2853 possible, CMP messages MAY also be piggybacked on any other reliable 2854 transport protocol, e.g., CoAP [RFC7252]. 2856 Independently of the means of transport it could happen that messages 2857 are lost, or a communication partner does not respond. In order to 2858 prevent waiting indefinitely, each CMP client component SHOULD use a 2859 configurable per-request timeout, and each CMP server component 2860 SHOULD use a configurable per-response timeout in case a further 2861 message is to be expected from the client side. In this way a 2862 hanging transaction can be closed cleanly with an error and related 2863 resources (for instance, any cached extraCerts) can be freed. 2865 When conveying a CMP messages in HTTP or MIME-based transport 2866 protocols the internet media type "application/pkixcmp" MUST be set 2867 for transport encoding as specified in RFC2510 in Section 5.3 2868 [RFC2510] and RFC6712 in Section 3.4 [RFC7712]. 2870 6.1. Definition and discovery of HTTP URIs 2872 Each PKI management entity supporting HTTP or HTTPS transport MUST 2873 support the use of the path-prefix of '/.well-known/' as defined in 2874 [RFC5785] and the registered name of 'cmp' to ease interworking in a 2875 multi-vendor environment. 2877 The CMP client MUST be configured with sufficient information to form 2878 the CMP server URI. This MUST be at least the authority portion of 2879 the URI, e.g., 'www.example.com:80', or the full operational path of 2880 the PKI management entity. An additional arbitrary label, e.g., 2881 'arbitraryLabel', MAY be configured as a separate component or as 2882 part of the full operational path to provide further information to 2883 address multiple CAs or certificate profiles. A valid full 2884 operational path can look like this: 2886 1 http://www.example.com/.well-known/cmp 2888 2 http://www.example.com/.well-known/cmp/keyupdate 2890 3 http://www.example.com/.well-known/cmp/arbitraryLabel 2891 4 http://www.example.com/.well-known/cmp/arbitraryLabel/keyupdate 2893 PKI management operations SHOULD use the following URI path: 2895 +----------------------------------+---------------------+----------+ 2896 | PKI management operation | Path | Details | 2897 +----------------------------------+---------------------+----------+ 2898 | Enroll client to new PKI | /initialization | Section | 2899 | (REQUIRED) | | 4.1.1 | 2900 +----------------------------------+---------------------+----------+ 2901 | Enroll client to existing PKI | /certification | Section | 2902 | (OPTIONAL) | | 4.1.2 | 2903 +----------------------------------+---------------------+----------+ 2904 | Update client certificate | /keyupdate | Section | 2905 | (REQUIRED) | | 4.1.3 | 2906 +----------------------------------+---------------------+----------+ 2907 | Enroll client using PKCS#10 | /p10 | Section | 2908 | (OPTIONAL) | | 4.1.5 | 2909 +----------------------------------+---------------------+----------+ 2910 | Enroll client using central key | /serverkeygen | Section | 2911 | generation (OPTIONAL) | | 4.1.6 | 2912 +----------------------------------+---------------------+----------+ 2913 | Revoke client certificate | /revocation | Section | 2914 | (RECOMMENDED) | | 4.2 | 2915 +----------------------------------+---------------------+----------+ 2916 | Get CA certificates (OPTIONAL) | /getcacert | Section | 2917 | | | 4.4.2 | 2918 +----------------------------------+---------------------+----------+ 2919 | Get root CA certificate update | /getrootupdate | Section | 2920 | (OPTIONAL) | | 4.4.3 | 2921 +----------------------------------+---------------------+----------+ 2922 | Get certificate request template | /getcertreqtemplate | Section | 2923 | (OPTIONAL) | | 4.4.4 | 2924 +----------------------------------+---------------------+----------+ 2925 | Additional protection (OPTIONAL) | /nested | Section | 2926 | | | 5.1.3 | 2927 +----------------------------------+---------------------+----------+ 2929 Table 1: HTTP endpoints 2931 Subsequent certConf, error, and pollReq messages are sent to the URI 2932 of the respective PKI management operation. 2934 The discovery of supported endpoints as defined above will provide 2935 the information to the EE, how to contact the PKI management entity 2936 and, if available, how to request enrolment for a specific 2937 certificate profile or revoke a certificate at a specific CA. 2939 Querying the PKI management entity, the EE will get a list of 2940 potential endpoints supported by the PKI management entity. 2942 Performing a GET on "/.well-known/cmp" to the default port returns a 2943 set of links to endpoints available from the server or RA. In 2944 addition to the link also the expected format of the data object is 2945 provided as content type (ct). 2947 The following provides an illustrative example for a PKI management 2948 entity supporting different PKI management operations for a single 2949 certificate profile or a single CA. 2951 Detailed message description: 2953 REQ: GET /.well-known/cmp 2955 RES: Content 2956 ;ct=pkixcmp 2957 ;ct=pkixcmp 2958 ;ct=pkixcmp 2959 ;ct=pkixcmp 2960 ;ct=pkixcmp 2961 ;ct=pkixcmp 2962 ;ct=pkixcmp 2963 ;ct=pkixcmp 2964 ;ct=pkixcmp 2966 As it is very likely, that a CA supports different certification 2967 profiles or that the RA offers PKI management operations for 2968 different issuing CAs, the discovery can also be used to provide the 2969 information about these options. The second example listing contains 2970 the supported PKI management operations for three different 2971 certificate profiles. The supported CA hierarchy consists of one 2972 root CA and two issuing CAs. 2974 Detailed message description: 2976 REQ: GET /.well-known/cmp 2978 RES: Content 2979 ;ct=pkixcmp 2980 ;ct=pkixcmp 2981 ;ct=pkixcmp 2982 ;ct=pkixcmp 2983 ;ct=pkixcmp 2984 ;ct=pkixcmp 2985 ;ct=pkixcmp 2986 ;ct=pkixcmp 2987 ;ct=pkixcmp 2988 ;ct=pkixcmp 2989 ;ct=pkixcmp 2990 ;ct=pkixcmp 2991 ;ct=pkixcmp 2992 ;ct=pkixcmp 2993 ;ct=pkixcmp 2994 ;ct=pkixcmp 2995 ;ct=pkixcmp 2996 ;ct=pkixcmp 2997 ;ct=pkixcmp 2999 There are different options in the handling of the naming. The PKI 3000 management entity either needs to offer the certprofile or CA labels 3001 the EE expects. Alternatively, a mechanism is required to configure 3002 this information to the EE beforehand. 3004 6.2. HTTP transport 3006 This transport mechanism can be used by a PKI entity to transfer CMP 3007 messages over HTTP. If HTTP transport is used the specifications as 3008 described in [RFC6712] MUST be followed. 3010 6.3. HTTPS transport using certificates 3012 This transport mechanism can be used by a PKI entity to further 3013 protect the HTTP transport as described in Section 6.2 using TLS 1.2 3014 [RFC5246] or TLS 1.3 [RFC8446] as described in [RFC2818] with 3015 certificate-based authentication. Using this transport mechanism, 3016 the CMP transport via HTTPS MUST use TLS server authentication and 3017 SHOULD use TLS client authentication. 3019 EE: 3021 o The EE SHOULD use a TLS client certificate as far as available. 3022 If no dedicated TLS certificate is available, the EE SHOULD use an 3023 already existing certificate identifying the EE (e.g., a 3024 manufacturer certificate). 3026 o If no TLS certificate is available at the EE, server-only 3027 authenticated TLS SHOULD be used. 3029 o The EE MUST validate the TLS server certificate of its 3030 communication partner. 3032 PKI management entity: 3034 o Each PKI management entity SHOULD use a TLS client certificate on 3035 its upstream (client) interface. 3037 o Each PKI management entity MUST use a TLS server certificate on 3038 its downstream (server) interface. 3040 o Each PKI management entity MUST validate the TLS certificate of 3041 its communication partners. 3043 NOTE: The requirements for checking certificates given in [RFC5280], 3044 [RFC5246] and [RFC8446] MUST be followed for the TLS layer. 3045 Certificate status checking SHOULD be used for the TLS certificates 3046 of communication partners. 3048 6.4. HTTPS transport using shared secrets 3050 This transport mechanism can be used by a PKI entity to further 3051 protect the HTTP transport as described in Section 6.2 using TLS 1.2 3052 [RFC5246] or TLS 1.3 [RFC8446] as described in [RFC2818] with mutual 3053 authentication based on shared secrets as described in [RFC5054]. 3055 EE: 3057 o The EE MUST use the shared symmetric key for authentication. 3059 PKI management entity: 3061 o The PKI management entity MUST use the shared symmetric key for 3062 authentication. 3064 6.5. Offline transport 3066 For transporting CMP messages between PKI entities any mechanism can 3067 be used that is able to store and forward binary objects of 3068 sufficient length and with sufficient reliability while preserving 3069 the order of messages. 3071 The transport mechanism SHOULD be able to indicate message loss, 3072 excessive delay, and possibly other transmission errors. In such 3073 cases the PKI entities using this mechanism SHOULD report an error as 3074 specified in Section 4.3. 3076 6.5.1. File-based transport 3078 CMP messages MAY be transferred between PKI entities using file- 3079 system-based mechanisms, for instance when an off-line end entity or 3080 a PKI management entity performs delayed enrollment. Each file MUST 3081 contain the ASN.1 DER encoding of one CMP message only. There MUST 3082 be no extraneous header or trailer information in the file. The file 3083 type extensions ".PKI" SHOULD be used. 3085 6.5.2. Other asynchronous transport protocols 3087 Other asynchronous transport protocols, e.g., email or website 3088 up-/download, MAY transfer CMP messages between PKI entities. A MIME 3089 wrapping is defined for those environments that are MIME native. The 3090 MIME wrapping in this section is specified in [RFC8551], section 3.1. 3092 The ASN.1 DER encoding of the CMP messages MUST be transferred using 3093 the "application/pkixcmp" content type and base64-encoded content- 3094 transfer-encoding as specified in [RFC2510], section 5.3. A filename 3095 MUST be included either in a content-type or a content-disposition 3096 statement. The extension for the file MUST be ".PKI". 3098 6.6. CoAP transport 3100 In constrained environments where no HTTP transport is desired or 3101 possible, CoAP [RFC7252] as specified in 3102 [I-D.msahni-tbd-cmpv2-coap-transport] MAY be used instead. 3104 6.7. Piggybacking on other reliable transport 3106 For online transfer where no HTTP transport is desired or possible 3107 CMP messages MAY also be transported on some other reliable protocol. 3108 Connection and error handling mechanisms like those specified for 3109 HTTP in [RFC6712] need to be implemented. 3111 Such specification is out of scope of this document and would need to 3112 be specifies in a separate document, e.g., in the scope of the 3113 respective transport protocol used. 3115 7. IANA Considerations 3117 < TBD: The OID id-it-caCerts, id-it-rootCaKeyUpdate, and id-it- 3118 certReqTemplate are not yet defined and should be registered in the 3119 tree 1.3.6.1.5.5.7.4 (id-it) like other infoType OIDs, see CMP 3120 Appendix F [RFC4210] on page 92. > 3122 8. Security Considerations 3124 < TBD: Add any security considerations > 3126 9. Acknowledgements 3128 We would like to thank the various reviewers of this document. 3130 10. References 3132 10.1. Normative References 3134 [I-D.ietf-lamps-cmp-updates] 3135 Brockhaus, H., "CMP Updates", draft-ietf-lamps-cmp- 3136 updates-02 (work in progress), July 2020. 3138 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 3139 Requirement Levels", BCP 14, RFC 2119, 3140 DOI 10.17487/RFC2119, March 1997, 3141 . 3143 [RFC2986] Nystrom, M. and B. Kaliski, "PKCS #10: Certification 3144 Request Syntax Specification Version 1.7", RFC 2986, 3145 DOI 10.17487/RFC2986, November 2000, 3146 . 3148 [RFC4086] Eastlake 3rd, D., Schiller, J., and S. Crocker, 3149 "Randomness Requirements for Security", BCP 106, RFC 4086, 3150 DOI 10.17487/RFC4086, June 2005, 3151 . 3153 [RFC4210] Adams, C., Farrell, S., Kause, T., and T. Mononen, 3154 "Internet X.509 Public Key Infrastructure Certificate 3155 Management Protocol (CMP)", RFC 4210, 3156 DOI 10.17487/RFC4210, September 2005, 3157 . 3159 [RFC4211] Schaad, J., "Internet X.509 Public Key Infrastructure 3160 Certificate Request Message Format (CRMF)", RFC 4211, 3161 DOI 10.17487/RFC4211, September 2005, 3162 . 3164 [RFC5280] Cooper, D., Santesson, S., Farrell, S., Boeyen, S., 3165 Housley, R., and W. Polk, "Internet X.509 Public Key 3166 Infrastructure Certificate and Certificate Revocation List 3167 (CRL) Profile", RFC 5280, DOI 10.17487/RFC5280, May 2008, 3168 . 3170 [RFC5652] Housley, R., "Cryptographic Message Syntax (CMS)", STD 70, 3171 RFC 5652, DOI 10.17487/RFC5652, September 2009, 3172 . 3174 [RFC5785] Nottingham, M. and E. Hammer-Lahav, "Defining Well-Known 3175 Uniform Resource Identifiers (URIs)", RFC 5785, 3176 DOI 10.17487/RFC5785, April 2010, 3177 . 3179 [RFC6712] Kause, T. and M. Peylo, "Internet X.509 Public Key 3180 Infrastructure -- HTTP Transfer for the Certificate 3181 Management Protocol (CMP)", RFC 6712, 3182 DOI 10.17487/RFC6712, September 2012, 3183 . 3185 10.2. Informative References 3187 [ETSI-3GPP] 3188 3GPP, "TS33.310; Network Domain Security (NDS); 3189 Authentication Framework (AF); Release 16; V16.1.0", 3190 December 2018, 3191 . 3193 [I-D.msahni-tbd-cmpv2-coap-transport] 3194 Sahni, M., "CoAP Transport for CMPV2", draft-msahni-tbd- 3195 cmpv2-coap-transport-00 (work in progress), June 2020. 3197 [IEC62443-3-3] 3198 IEC, "Industrial communication networks - Network and 3199 system security - Part 3-3: System security requirements 3200 and security levels", IEC 62443-3-3, August 2013, 3201 . 3203 [IEEE802.1AR] 3204 IEEE, "802.1AR Secure Device Identifier", June 2018, 3205 . 3208 [NIST-CSFW] 3209 NIST, "Framework for Improving Critical Infrastructure 3210 Cybersecurity Version 1.1", April 2018, 3211 . 3214 [RFC2510] Adams, C. and S. Farrell, "Internet X.509 Public Key 3215 Infrastructure Certificate Management Protocols", 3216 RFC 2510, DOI 10.17487/RFC2510, March 1999, 3217 . 3219 [RFC2818] Rescorla, E., "HTTP Over TLS", RFC 2818, 3220 DOI 10.17487/RFC2818, May 2000, 3221 . 3223 [RFC3647] Chokhani, S., Ford, W., Sabett, R., Merrill, C., and S. 3224 Wu, "Internet X.509 Public Key Infrastructure Certificate 3225 Policy and Certification Practices Framework", RFC 3647, 3226 DOI 10.17487/RFC3647, November 2003, 3227 . 3229 [RFC5054] Taylor, D., Wu, T., Mavrogiannopoulos, N., and T. Perrin, 3230 "Using the Secure Remote Password (SRP) Protocol for TLS 3231 Authentication", RFC 5054, DOI 10.17487/RFC5054, November 3232 2007, . 3234 [RFC5246] Dierks, T. and E. Rescorla, "The Transport Layer Security 3235 (TLS) Protocol Version 1.2", RFC 5246, 3236 DOI 10.17487/RFC5246, August 2008, 3237 . 3239 [RFC7252] Shelby, Z., Hartke, K., and C. Bormann, "The Constrained 3240 Application Protocol (CoAP)", RFC 7252, 3241 DOI 10.17487/RFC7252, June 2014, 3242 . 3244 [RFC7712] Saint-Andre, P., Miller, M., and P. Hancke, "Domain Name 3245 Associations (DNA) in the Extensible Messaging and 3246 Presence Protocol (XMPP)", RFC 7712, DOI 10.17487/RFC7712, 3247 November 2015, . 3249 [RFC8366] Watsen, K., Richardson, M., Pritikin, M., and T. Eckert, 3250 "A Voucher Artifact for Bootstrapping Protocols", 3251 RFC 8366, DOI 10.17487/RFC8366, May 2018, 3252 . 3254 [RFC8446] Rescorla, E., "The Transport Layer Security (TLS) Protocol 3255 Version 1.3", RFC 8446, DOI 10.17487/RFC8446, August 2018, 3256 . 3258 [RFC8551] Schaad, J., Ramsdell, B., and S. Turner, "Secure/ 3259 Multipurpose Internet Mail Extensions (S/MIME) Version 4.0 3260 Message Specification", RFC 8551, DOI 10.17487/RFC8551, 3261 April 2019, . 3263 [UNISIG] UNISIG, "Subset-137; ERTMS/ETCS On-line Key Management 3264 FFFIS; V1.0.0", December 2015, 3265 . 3267 Appendix A. ASN.1 Syntax 3269 id-it-caCerts OBJECT IDENTIFIER ::= {1 3 6 1 5 5 7 4 xxx} 3270 CaCerts ::= SEQUENCE OF CMPCertificate 3271 } 3273 id-it-rootCaKeyUpdate OBJECT IDENTIFIER ::= {1 3 6 1 5 5 7 4 xxx} 3274 RootCaKeyUpdate ::= SEQUENCE { 3275 newWithNew CMPCertificate 3276 newWithOld [0] CMPCertificate OPTIONAL, 3277 oldWithNew [1] CMPCertificate OPTIONAL, 3278 } 3280 id-it-certReqTemplate OBJECT IDENTIFIER ::= {1 3 6 1 5 5 7 4 xxx} 3281 CertReqTemplateValue ::= SEQUENCE { 3282 certTemplate CertTemplate, 3283 rsaKeyLen INTEGER OPTIONAL, 3284 } 3286 < TBD: The OID id-it-caCerts, id-it-rootCaKeyUpdate, and id-it- 3287 certReqTemplate must be defined by IANA > 3289 Appendix B. Example for CertReqTemplate 3291 This Section provides a concrete example for the content of an 3292 infoValue used of type id-it-certReqTemplate as described in 3293 Section 4.4.4. 3295 Suppose the server requires that the certTemplate contains the issuer 3296 field with a value to be filled in by the EE, the subject field with 3297 a common name to be filled in by the EE and two organizational unit 3298 fields with given values "myDept" and "myGroup", the publicKey field 3299 with an RSA public key of length 2048, the subjectAltName extension 3300 with DNS name "www.myServer.com" and an IP address to be filled in, 3301 the keyUsage extension marked critical with the value 3302 digitalSignature and keyAgreement, and the extKeyUsage extension with 3303 values to be filled in by the EE. Then the infoValue with 3304 certTemplate and rsaKeyLen returned to the EE must be encoded as 3305 follows: 3307 SEQUENCE { 3308 SEQUENCE { 3309 [3] { 3310 SEQUENCE {} 3311 } 3312 [5] { 3313 SEQUENCE { 3314 SET { 3315 SEQUENCE { 3316 OBJECT IDENTIFIER commonName (2 5 4 3) 3317 UTF8String '' 3318 } 3319 } 3320 SEQUENCE { 3321 OBJECT IDENTIFIER organizationalUnitName (2 5 4 11) 3322 UTF8String 'myDept' 3323 } 3324 } 3325 SET { 3326 SEQUENCE { 3327 OBJECT IDENTIFIER organizationalUnitName (2 5 4 11) 3328 UTF8String 'myGroup' 3329 } 3330 } 3331 } 3332 } 3333 [6] { 3334 SEQUENCE { 3335 OBJECT IDENTIFIER rsaEncryption (1 2 840 113549 1 1 1) 3336 NULL 3337 } 3338 BIT STRING, encapsulates { 3339 SEQUENCE {} 3340 } 3341 } 3342 [9] { 3343 SEQUENCE { 3344 OBJECT IDENTIFIER subjectAltName (2 5 29 17) 3345 OCTET STRING, encapsulates { 3346 SEQUENCE { 3347 [2] 'www.myServer.com' 3348 [7] '' 3349 } 3351 } 3352 } 3353 SEQUENCE { 3354 OBJECT IDENTIFIER keyUsage (2 5 29 15) 3355 BOOLEAN TRUE 3356 OCTET STRING, encapsulates { 3357 BIT STRING 3 unused bits 3358 '10001'B 3359 } 3360 } 3361 SEQUENCE { 3362 OBJECT IDENTIFIER extKeyUsage (2 5 29 37) 3363 OCTET STRING, encapsulates { 3364 SEQUENCE {} 3365 } 3366 } 3367 } 3368 } 3369 INTEGER 2048 3370 } 3372 Appendix C. History of changes 3374 Note: This section will be deleted in the final version of the 3375 document. 3377 From version 01 -> 02: 3379 o Extend Section 1.4 with regard to conflicts with UNISIG Subset- 3380 137. 3382 o Minor clarifications on extraCerts in Section 3.3 and 3383 Section 4.1.1. 3385 o Complete specification of requesting a certificate from a trusted 3386 PKI with signature protection in Section 4.1.2. 3388 o Changed from symmetric key-encryption to password-based key 3389 management technique in section Section 4.1.6.3 as discussed on 3390 the mailing list (see thread "draft-ietf-lamps-lightweight-cmp- 3391 profile-01, section 5.1.6.1") 3393 o Changed delayed enrollment described in Section 4.1.7 from 3394 recommended to optional as decided at IETF 107 3396 o Introduced the new RootCAKeyUpdate structure for root CA 3397 certificate update in Section 4.4.3 as decided at IETF 107 (also 3398 see email thread "draft-ietf-lamps-lightweight-cmp-profile-01, 3399 section 5.4.3") 3401 o Extend the description of the CertReqTemplate PKI management 3402 operation, including an example added in the Appendix. Keep 3403 rsaKeyLen as a single integer value in Section 4.4.4 as discussed 3404 on the mailing list (see thread "draft-ietf-lamps-lightweight-cmp- 3405 profile-01, section 5.4.4") 3407 o Deleted Sections "Get certificate management configuration" and 3408 "Get enrollment voucher" as decided at IETF 107 3410 o Complete specification of adding an additional protection by an 3411 PKI management entity in Section 5.1.3. 3413 o Added Section 6.1 and extended Section 6.2 on definition and 3414 discovery of supported HTTP URIs and content types, add a path for 3415 nested messages as specified in Section 5.1.3 and delete the paths 3416 for /getCertMgtConfig and /getVoucher 3418 o Changed Section 6.5 to address offline transport and added more 3419 detailed specification file-based transport of CMP 3421 o Added a reference to the new I-D of Mohit Sahni on "CoAP Transport 3422 for CMPV2" in Section 6.6; thanks to Mohit supporting the effort 3423 to ease utilization of CMP 3425 o Moved the change history to the Appendix 3427 o Minor changes in wording 3429 From version 00 -> 01: 3431 o Harmonize terminology with CMP [RFC4210], e.g., 3433 * transaction, message sequence, exchange, use case -> PKI 3434 management operation 3436 * PKI component, (L)RA/CA -> PKI management entity 3438 o Minor changes in wording 3440 From draft-brockhaus-lamps-lightweight-cmp-profile-03 -> draft-ietf- 3441 lamps-lightweight-cmp-profile-00: 3443 o Changes required to reflect WG adoption 3445 o Minor changes in wording 3446 From version 02 -> 03: 3448 o Added a short summary of [RFC4210] Appendix D and E in 3449 Section 1.3. 3451 o Clarified some references to different sections and added some 3452 clarification in response to feedback from Michael Richardson and 3453 Tomas Gustavsson. 3455 o Added an additional label to the operational path to address 3456 multiple CAs or certificate profiles in Section 6.2. 3458 From version 01 -> 02: 3460 o Added some clarification on the key management techniques for 3461 protection of centrally generated keys in Section 4.1.6. 3463 o Added some clarifications on the certificates for root CA 3464 certificate update in Section 4.4.3. 3466 o Added a section to specify the usage of nested messages for RAs to 3467 add an additional protection for further discussion, see 3468 Section 5.1.3. 3470 o Added a table containing endpoints for HTTP transport in 3471 Section 6.2 to simplify addressing PKI management entities. 3473 o Added some ToDos resulting from discussion with Tomas Gustavsson. 3475 o Minor clarifications and changes in wording. 3477 From version 00 -> 01: 3479 o Added a section to specify the enrollment with an already trusted 3480 PKI for further discussion, see Section 4.1.2. 3482 o Complete specification of requesting a certificate from a legacy 3483 PKI using a PKCS#10 [RFC2986] request in Section 4.1.5. 3485 o Complete specification of adding central generation of a key pair 3486 on behalf of an end entity in Section 4.1.6. 3488 o Complete specification of handling delayed enrollment due to 3489 asynchronous message delivery in Section 4.1.7. 3491 o Complete specification of additional support messages, e.g., to 3492 update a Root CA certificate or to request an RFC 8366 [RFC8366] 3493 voucher, in Section 4.4. 3495 o Minor changes in wording. 3497 From draft-brockhaus-lamps-industrial-cmp-profile-00 -> draft- 3498 brockhaus-lamps-lightweight-cmp-profile-00: 3500 o Change focus from industrial to more multi-purpose use cases and 3501 lightweight CMP profile. 3503 o Incorporate the omitted confirmation into the header specified in 3504 Section 3.1 and described in the standard enrollment use case in 3505 Section 4.1.1 due to discussion with Tomas Gustavsson. 3507 o Change from OPTIONAL to RECOMMENDED for use case 'Revoke another's 3508 entities certificate' in Section 5.2, because it is regarded as 3509 important functionality in many environments to enable the 3510 management station to revoke EE certificates. 3512 o Complete the specification of the revocation message flow in 3513 Section 4.2 and Section 5.2. 3515 o The CoAP based transport mechanism and piggybacking of CMP 3516 messages on top of other reliable transport protocols is out of 3517 scope of this document and would need to be specified in another 3518 document. 3520 o Further minor changes in wording. 3522 Authors' Addresses 3524 Hendrik Brockhaus 3525 Siemens AG 3527 Email: hendrik.brockhaus@siemens.com 3529 Steffen Fries 3530 Siemens AG 3532 Email: steffen.fries@siemens.com 3534 David von Oheimb 3535 Siemens AG 3537 Email: david.von.oheimb@siemens.com