idnits 2.17.1 draft-brockhaus-lamps-lightweight-cmp-profile-01.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- No issues found here. Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- No issues found here. Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- No issues found here. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust and authors Copyright Line does not match the current year == Using lowercase 'not' together with uppercase 'MUST', 'SHALL', 'SHOULD', or 'RECOMMENDED' is not an accepted usage according to RFC 2119. Please use uppercase 'NOT' together with RFC 2119 keywords (if that is what you mean). Found 'SHOULD not' in this paragraph: When in chapter 3, 4, and 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 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 'MUST not' in this paragraph: The PKI component initiating the delayed enrollment MUST include the status "waiting" in the response and this response MUST not contain the newly issued certificate. When receiving a response with status "waiting" the EE MUST send a poll request to the (L)RA/CA. The PKI component that initiated the delayed enrollment MUST answers with a poll response containing a checkAfter time. This value indicates the minimum number of seconds that must elapse before the EE sends another poll request. As soon as the (L)RA/CA can provide the final response message for the initial request of the EE, it MUST provide this in response to a poll request. After receiving this response, the EE can continue the original message sequence as described in the respective section of this document, e.g., send a certConf message. == 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 (L)RA SHOULD verify the protection, the syntax, the required message fields, the message type, and if applicable the authorization and the proof-of-possession of the message. Additional checks or actions MAY be applied depending on the PKI solution requirements and concept. If one of these verification procedures fails, the (L)RA SHOULD respond with a negative response message and SHOULD not forward the message further upstream. General error conditions should be handled as described in Section 5.3 and Section 6.3. == Using lowercase 'not' together with uppercase 'MUST', 'SHALL', 'SHOULD', or 'RECOMMENDED' is not an accepted usage according to RFC 2119. Please use uppercase 'NOT' together with RFC 2119 keywords (if that is what you mean). Found 'SHOULD not' in this paragraph: An (L)RA SHOULD not change the received message if not necessary. The (L)RA 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 (November 3, 2019) is 1637 days in the past. Is this intentional? Checking references for intended status: Proposed Standard ---------------------------------------------------------------------------- (See RFCs 3967 and 4897 for information about using normative references to lower-maturity documents in RFCs) == Outdated reference: A later version (-03) exists of draft-brockhaus-lamps-cmp-updates-00 -- Possible downref: Normative reference to a draft: ref. 'I-D.brockhaus-lamps-cmp-updates' ** Downref: Normative reference to an Informational RFC: RFC 2986 == Outdated reference: A later version (-45) exists of draft-ietf-anima-bootstrapping-keyinfra-29 -- Obsolete informational reference (is this intentional?): RFC 2818 (Obsoleted by RFC 9110) -- Obsolete informational reference (is this intentional?): RFC 5246 (Obsoleted by RFC 8446) Summary: 1 error (**), 0 flaws (~~), 8 warnings (==), 4 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 Internet Engineering Task Force H. Brockhaus 3 Internet-Draft S. Fries 4 Intended status: Standards Track D. von Oheimb 5 Expires: May 6, 2020 Siemens 6 November 3, 2019 8 Lightweight CMP Profile 9 draft-brockhaus-lamps-lightweight-cmp-profile-01 11 Abstract 13 The goal of this document is to facilitate interoperability and 14 automation by profiling the Certificate Management Protocol (CMP) 15 version 2 and the related Certificate Request Message Format (CRMF) 16 version 2. It specifies a subset of CMP and CRMF focusing on typical 17 uses cases relevant for managing certificates of devices in many 18 industrial and IoT scenarios. To limit the overhead of certificate 19 management for more constrained devices only the most crucial types 20 of transactions are specified as mandatory. To foster 21 interoperability also in more complex scenarios, other types of 22 transactions are specified as recommended or optional. 24 Status of This Memo 26 This Internet-Draft is submitted in full conformance with the 27 provisions of BCP 78 and BCP 79. 29 Internet-Drafts are working documents of the Internet Engineering 30 Task Force (IETF). Note that other groups may also distribute 31 working documents as Internet-Drafts. The list of current Internet- 32 Drafts is at https://datatracker.ietf.org/drafts/current/. 34 Internet-Drafts are draft documents valid for a maximum of six months 35 and may be updated, replaced, or obsoleted by other documents at any 36 time. It is inappropriate to use Internet-Drafts as reference 37 material or to cite them other than as "work in progress." 39 This Internet-Draft will expire on May 6, 2020. 41 Copyright Notice 43 Copyright (c) 2019 IETF Trust and the persons identified as the 44 document authors. All rights reserved. 46 This document is subject to BCP 78 and the IETF Trust's Legal 47 Provisions Relating to IETF Documents 48 (https://trustee.ietf.org/license-info) in effect on the date of 49 publication of this document. Please review these documents 50 carefully, as they describe your rights and restrictions with respect 51 to this document. Code Components extracted from this document must 52 include Simplified BSD License text as described in Section 4.e of 53 the Trust Legal Provisions and are provided without warranty as 54 described in the Simplified BSD License. 56 Table of Contents 58 1. History of changes . . . . . . . . . . . . . . . . . . . . . 3 59 2. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 4 60 2.1. Motivation for profiling CMP . . . . . . . . . . . . . . 5 61 2.2. Motivation for a lightweight profile for CMP . . . . . . 5 62 2.3. Existing CMP profiles . . . . . . . . . . . . . . . . . . 6 63 2.4. Compatibility with existing CMP profiles . . . . . . . . 7 64 2.5. Scope of this document . . . . . . . . . . . . . . . . . 8 65 2.6. Structure of this document . . . . . . . . . . . . . . . 8 66 2.7. Convention and Terminology . . . . . . . . . . . . . . . 9 67 3. Architecture and use cases . . . . . . . . . . . . . . . . . 9 68 3.1. Solution architecture . . . . . . . . . . . . . . . . . . 9 69 3.2. Basic generic CMP message content . . . . . . . . . . . . 11 70 3.3. Supported use cases . . . . . . . . . . . . . . . . . . . 11 71 3.3.1. Mandatory use cases . . . . . . . . . . . . . . . . . 11 72 3.3.2. Recommended Use Cases . . . . . . . . . . . . . . . . 12 73 3.3.3. Optional use cases . . . . . . . . . . . . . . . . . 12 74 3.4. CMP message transport . . . . . . . . . . . . . . . . . . 13 75 4. Generic parts of the PKI message . . . . . . . . . . . . . . 13 76 4.1. General description of the CMP message header . . . . . . 14 77 4.2. General description of the CMP message protection . . . . 16 78 4.3. General description of CMP message extraCerts . . . . . . 16 79 5. End Entity focused certificate management use cases . . . . . 16 80 5.1. Requesting a new certificate from a PKI . . . . . . . . . 17 81 5.1.1. A certificate from a new PKI with signature 82 protection . . . . . . . . . . . . . . . . . . . . . 18 83 5.1.2. A certificate from a trusted PKI with signature 84 protection . . . . . . . . . . . . . . . . . . . . . 25 85 5.1.3. Update an existing certificate with signature 86 protection . . . . . . . . . . . . . . . . . . . . . 25 87 5.1.4. A certificate from a PKI with MAC protection . . . . 26 88 5.1.5. A certificate from a legacy PKI using PKCS#10 request 28 89 5.1.6. Generate the key pair centrally at the (L)RA/CA . . . 29 90 5.1.6.1. Using symmetric key-encryption key management 91 technique . . . . . . . . . . . . . . . . . . . . 34 92 5.1.6.2. Using key agreement key management technique . . 35 93 5.1.6.3. Using key transport key management technique . . 36 94 5.1.7. Delayed enrollment . . . . . . . . . . . . . . . . . 37 95 5.2. Revoking a certificate . . . . . . . . . . . . . . . . . 41 96 5.3. Error reporting . . . . . . . . . . . . . . . . . . . . . 43 97 5.4. Support messages . . . . . . . . . . . . . . . . . . . . 45 98 5.4.1. General message and response . . . . . . . . . . . . 46 99 5.4.2. Get CA certiificates . . . . . . . . . . . . . . . . 47 100 5.4.3. Get root CA certificate update . . . . . . . . . . . 48 101 5.4.4. Get certificate request parameters . . . . . . . . . 49 102 5.4.5. Get certificate management configuration . . . . . . 50 103 5.4.6. Get enrollment voucher . . . . . . . . . . . . . . . 52 104 6. LRA and RA focused certificate management use cases . . . . . 53 105 6.1. Forwarding of messages . . . . . . . . . . . . . . . . . 53 106 6.1.1. Not changing protection . . . . . . . . . . . . . . . 55 107 6.1.2. Replacing protection . . . . . . . . . . . . . . . . 56 108 6.1.2.1. Keeping proof-of-possession . . . . . . . . . . . 56 109 6.1.2.2. Breaking proof-of-possession . . . . . . . . . . 57 110 6.1.3. Initiating delayed enrollment . . . . . . . . . . . . 57 111 6.2. Revoking certificates on behalf of another's entities . . 57 112 6.3. Error reporting . . . . . . . . . . . . . . . . . . . . . 58 113 7. CMP message transport variants . . . . . . . . . . . . . . . 58 114 7.1. HTTP transport . . . . . . . . . . . . . . . . . . . . . 59 115 7.2. HTTPS transport using certificates . . . . . . . . . . . 59 116 7.3. HTTPS transport using shared secrets . . . . . . . . . . 60 117 7.4. File-based transport . . . . . . . . . . . . . . . . . . 60 118 7.5. CoAP transport . . . . . . . . . . . . . . . . . . . . . 60 119 7.6. Piggybacking on other reliable transport . . . . . . . . 60 120 8. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 61 121 9. Security Considerations . . . . . . . . . . . . . . . . . . . 61 122 10. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 61 123 11. References . . . . . . . . . . . . . . . . . . . . . . . . . 61 124 11.1. Normative References . . . . . . . . . . . . . . . . . . 61 125 11.2. Informative References . . . . . . . . . . . . . . . . . 62 126 Appendix A. Additional Stuff . . . . . . . . . . . . . . . . . . 64 127 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 64 129 1. History of changes 131 From version 00 -> 01: 133 o Complete specification of requesting a certificate from a legacy 134 PKI using a PKCS#10 [RFC2986] request in Section 5.1.5. 136 o Complete specification of adding central generation of a key pair 137 to a certificate request in Section 5.1.6. 139 o Complete specification of handling delayed enrollment due to 140 asynchronous message delivery in Section 5.1.7. 142 o Complete specification of additional support messages, e.g., to 143 update a Root CA certificate or to request an RFC 8366 [RFC8366] 144 voucher, in Section 5.4. 146 o Minor changes in wording. 148 From version draft-brockhaus-lamps-industrial-cmp-profile-00 -> 149 brockhaus-lamps-lightweight-cmp-profile-00: 151 o Change focus from industrial to more multi-purpose use cases and 152 lightweight CMP profile. 154 o Incorporate the omitted confirmation into the header specified in 155 Section 4.1 and described in the standard enrollment use case in 156 Section 5.1.1 due to discussion with Tomas Gustavsson. 158 o Change from OPTIONAL to RECOMMENDED for use case 'Revoke another's 159 entities certificate' in Section 6.2, because it is regarded as 160 important functionality in many environments to enable the 161 management station to revoke EE certificates. 163 o Complete the specification of the revocation message flow in 164 Section 5.2 and Section 6.2. 166 o The CoAP based transport mechanism and piggybacking of CMP 167 messages on top of other reliable transport protocols is out of 168 scope of this document and would need to be specified in another 169 document. 171 o Further minor changes in wording. 173 2. Introduction 175 This document specifies PKI management operations supporting machine- 176 to-machine and IoT use cases. The focus lies on maximum automation 177 and interoperable implementation of all involved PKI entities from 178 end entities (EE) through an optional Local Registration Authority 179 (LRA) and the RA up to the CA. The profile makes use of the concepts 180 and syntax specified in CMP [RFC4210], CRMF [RFC4211], HTTP transfer 181 for CMP [RFC6712], and CMP Updates [I-D.brockhaus-lamps-cmp-updates]. 182 Especially CMP and CRMF are very feature-rich standards, while only a 183 limited subset of the specified functionality is needed in many 184 environments. Additionally, the standards are not always precise 185 enough on how to interpret and implement the described concepts. 186 Therefore, we aim at tailoring and specifying in more detail how to 187 use these concepts to implement lightweight automated certificate 188 management. 190 2.1. Motivation for profiling CMP 192 CMP was standardized in 1999 and is implemented in several CA 193 products. In 2005 a completely reworked and enhanced version 2 of 194 CMP [RFC4210] and CRMF [RFC4211] has been published followed by a 195 document specifying a transfer mechanism for CMP messages using http 196 [RFC6712] in 2012. 198 Though CMP is a very solid and capable protocol it could be used more 199 widely. The most important reason for not more intense application 200 of CMP appears to be that the protocol is offering a large set of 201 features and options but being not always precise enough and leaving 202 room for interpretation. On the one hand, this makes CMP applicable 203 to a very wide range of scenarios, but on the other hand a full 204 implementation of all options is unrealistic because this would take 205 enormous effort. 207 Moreover, many details of the CMP protocol have been left open or 208 have not been specified in full preciseness. The profiles specified 209 in Appendix D and E of [RFC4210] offer some more detailed certificate 210 use cases. But the specific needs of highly automated scenarios for 211 a machine-to-machine communication are not covered sufficiently. 213 As also 3GPP and UNISG already put across, profiling is a way of 214 coping with the challenges mentioned above. To profile means to take 215 advantage of the strengths of the given protocol, while explicitly 216 narrowing down the options it provides to exactly those needed for 217 the purpose(s) at hand and eliminating all identified ambiguities. 218 In this way all the general and applicable aspects of the protocol 219 can be taken over and only the peculiarities of the target scenario 220 need to be dealt with specifically. 222 Doing such a profiling for a new target environment can be a high 223 effort because the range of available options needs to be well 224 understood and the selected options need to be consistent with each 225 other and with the intended usage scenario. Since most industrial 226 use cases typically have much in common it is worth sharing this 227 effort, which is the aim of this document. Other standardization 228 bodies can then reference the profile from this document and do not 229 need to come up with individual profiles. 231 2.2. Motivation for a lightweight profile for CMP 233 The profiles specified in Appendix D and E of CMP have been developed 234 in particular to manage certificates of human end entities. With the 235 evolution of distributed systems and client-server architectures, 236 certificates for machines and applications on them have become widely 237 used. This trend has strengthened even more in emerging industrial 238 and IoT scenarios. CMP is sufficiently flexible to support these 239 very well. 241 Today's IT security architectures for industrial solutions typically 242 use certificates for endpoint authentication within protocols like 243 IPSec, TLS, or SSH. Therefore, the security of these architectures 244 highly relies upon the security and availability of the implemented 245 certificate management procedures. 247 Due to increasing security in operational networks as well as 248 availability requirements, especially on critical infrastructures and 249 systems with a high volume of certificates, a state-of-the-art 250 certificate management must be constantly available and cost- 251 efficient, which calls for high automation and reliability. The NIST 252 Cyber Security Framework [NIST-CSFW] also refers to proper processes 253 for issuance, management, verification, revocation, and audit for 254 authorized devices, users and processes involving identity and 255 credential management. Such PKI operation according to commonly 256 accepted best practices is also required in IEC 62443-3-3 257 [IEC62443-3-3] for security level 2 up to security level 4. 259 Further challenges in many industrial systems are network 260 segmentation and asynchronous communication, where PKI operation is 261 often not deployed on-site but in a more protected environment of a 262 data center or trust center. Certificate management must be able to 263 cope with such network architectures. CMP offers the required 264 flexibility and functionality, namely self-contained messages, 265 efficient polling, and support for asynchronous message transfer with 266 end-to-end security. 268 2.3. Existing CMP profiles 270 As already stated, CMP contains profiles with mandatory and optional 271 transactions in the Appendixes D and E of [RFC4210]. Those profiles 272 focus on management of human user certificates and do only partly 273 address the specific needs for certificate management automation for 274 unattended machine or application-oriented end entities. 276 3GPP makes use of CMP [RFC4210] in its Technical Specification 133 277 310 [ETSI-3GPP] for automatic management of IPSec certificates in 278 UMTS, LTE, and 5G backbone networks. Since 2010 a dedicated CMP 279 profile for initial certificate enrollment and update transactions 280 between end entities and the RA/CA is specified in the document. 282 UNISIG has included a CMP profile for certificate enrollment in the 283 subset 137 specifying the ETRAM/ECTS on-line key management for train 284 control systems [UNISIG] in 2015. 286 Both standardization bodies use CMP [RFC4210], CRMF [RFC4211], and 287 HTTP transfer for CMP [RFC6712] to add tailored means for automated 288 certificate management for unattended machine or application-oriented 289 end entities. 291 2.4. Compatibility with existing CMP profiles 293 The profile specified in this document is compatible with CMP 294 [RFC4210] Appendixes D and E (PKI Management Message Profiles), with 295 the following exceptions: 297 o signature-based protection is the default protection; initial 298 transactions may also use HMAC, 300 o certification of a second key pair within the same transaction is 301 not supported, 303 o proof-of-possession (POPO) with self-signature of the certTemplate 304 according to [RFC4211] section 4.1 clause 3 is the only supported 305 POPO method, 307 o confirmation of newly enrolled certificates may be omitted, and 309 o all transactions consist of request-response message pairs 310 originating at the EE, i.e., announcement messages are omitted. 312 The profile specified in this document is compatible with the CMP 313 profile for UMTS, LTE, and 5G network domain security and 314 authentication framework [ETSI-3GPP], except that: 316 o protection of initial transactions may be HMAC-based, 318 o the subject name is mandatory in certificate templates, and 320 o confirmation of newly enrolled certificates may be omitted. 322 The profile specified in this document is compatible with the CMP 323 profile for on-line key management in rail networks as specified in 324 UNISIG subset-137 [UNISIG], except that: 326 o as of RFC 4210 [RFC4210] the messageTime is required to be 327 Greenwich Mean Time coded as generalizedTime (Note: While UNISIG 328 explicitely states that the messageTime in required to be 'UTC 329 time', it is not clear if this means a coding as UTCTime or 330 generalizedTime and if other time zones than Greenwich Mean Time 331 shall be allowed. Therefore UNISG may be in conflict with 332 RFC 4210 [RFC4210]. Both time formats are described in RFC 5280 333 [RFC5280] section 4.1.2.5.), and 335 o in case the request message is MAC protected, also the response, 336 certConf, and PKIconf messages have a MAC-based protection (Note: 337 if changing to signature protection of the response the caPubs 338 field cannot be used securely anymore.). 340 2.5. Scope of this document 342 This document specifies requirements on generating messages on the 343 sender side. It does not specify strictness of verification on the 344 receiving side and how in detail to handle error cases. 346 Especially on the EE side this profile aims at a lightweight protocol 347 that can be implemented on more constrained devices. On the side of 348 the central PKI management entities the profile accepts higher 349 resource needed. 351 For the sake of robustness and preservation of security properties 352 implementations should, as far as security is not affected, adhere to 353 Postel's law: "Be conservative in what you do, be liberal in what you 354 accept from others" (often reworded as: "Be conservative in what you 355 send, be liberal in what you accept"). 357 When in chapter 3, 4, and 5 a field of the ASN.1 syntax as defined in 358 RFC 4210 [RFC4210] and RFC 4211 [RFC4211] is not explicitly 359 specified, it SHOULD not be used by the sending entity. The 360 receiving entity MUST NOT require its absence and if present MUST 361 gracefully handle its presence. 363 2.6. Structure of this document 365 Chapter 2 introduces the general PKI architecture and approach to 366 certificate management using CMP that is assumed in this document. 367 Then it enlists the PKI management opertations specified in this 368 document and describes them in general words. The list of supported 369 certificate management use cases is divided into mandatory, 370 recommended, and optional ones. 372 Chapter 3 profiles the CMP message header, protection, and extraCerts 373 section as they are general elements of CMP messages. 375 Chapter 4 profiles the exchange of CMP messages between an EE and the 376 first PKI management entities. There are various flavors of 377 certificate enrollment requests optionally with polling, revocation, 378 error handling, and general support transactions. 380 Chapter 5 profiles the exchange between PKI management entities. 381 These are in the first place the forwarding of messages coming from 382 or going to an EE. This includes also initiating delayed delivery of 383 messages, which involves polling. Additionally, it specifies 384 transactions where the PKI component manages certificates on behalf 385 of an EE or for itself. 387 Chapter 6 outlines different mechanisms for CMP message transfer, 388 namely http-based transfer as already specified in [RFC6712], using 389 an additional TLS layer, or offline file-based transport. CoAP 390 [RFC7252] and piggybacking CMP messages on other protocols is out of 391 scope and left for further documents. 393 2.7. Convention and Terminology 395 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 396 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 397 document are to be interpreted as described in RFC 2119 [RFC2119]. 399 In this document, these words will appear with that interpretation 400 only when in ALL CAPS. Lower case uses of these words are not to be 401 interpreted as carrying significance described in RFC 2119. 403 Technical terminology is used in conformance with RFC 4210 [RFC4210], 404 RFC 4211 [RFC4211], RFC 5280 [RFC5280], and IEEE 802.1AR 405 [IEEE802.1AR]. The following key words are used: 407 CA: Certification authority, which issues certificates. 409 RA: Registration authority, an optional system component to which 410 a CA delegates certificate management functions such as 411 authorization checks. 413 LRA: Local registration authority, an optional RA system component 414 with proximity to the end entities. 416 KGA: Key generation authority, an optional system component, 417 typically co-located with an LRA, RA, or CA, that offers key 418 generation services to end entities. 420 EE: End entity, a user, device, or service that holds a PKI 421 certificate. An identifier for the EE is given as the 422 subject of its certificate. 424 3. Architecture and use cases 426 3.1. Solution architecture 428 Typically, a machine EE will be equipped with a manufacturer issued 429 certificate during production. Such a manufacturer issued 430 certificate is installed during production to identify the device 431 throughout its lifetime. This manufacturer certificate can be used 432 to protect the initial enrollment of operational certificates after 433 installation of the EE in a plant or industrial network. An 434 operational certificate is issued by the owner or operator of the 435 device to identify the device during operation, e.g., within a 436 security protocol like IPSec, TLS, or SSH. In IEEE 802.1AR 437 [IEEE802.1AR] a manufacturer certificate is called IDevID certificate 438 and an operational certificate is called LDevID certificate. 440 All certificate management transactions are initiated by the EE. The 441 EE creates a CMP request message, protects it using its manufacturer 442 or operational certificate, if available, and sends it to its locally 443 reachable PKI component. This PKI component may be an LRA, RA, or 444 the CA, which checks the request, responds to it itself, or forwards 445 the request upstream to the next PKI component. In case an (L)RA 446 changes the CMP request message header or body or wants to prove a 447 successful verification or authorization, it can apply a protection 448 of its own. Especially the communication between an LRA and RA can 449 be performed synchronously or asynchronously. Synchronous 450 communication describes a timely uninterrupted communication between 451 two communication partners, as asynchronous communication is not 452 performed in a timely consistent manner, e.g., because of a delayed 453 message delivery. 455 +-----+ +-----+ +-----+ +-----+ 456 | | | | | | | | 457 | EE |<---------->| LRA |<-------------->| RA |<---------->| CA | 458 | | | | | | | | 459 +-----+ +-----+ +-----+ +-----+ 461 synchronous (a)synchronous synchronous 462 +----connection----+------connection------+----connection----+ 464 on site at operators service partner 465 +----------plant---------+-----backend services-----+-trust center-+ 467 Figure 1: Certificate management on site 469 In operation environments a layered LRA-RA-CA architecture can be 470 deployed, e.g., with LRAs bundling requests from multiple EEs at 471 dedicated locations and one (or more than one) central RA aggregating 472 the requests from multiple LRAs. Every (L)RA in this scenario will 473 have its own dedicated certificate containing an extended key usage 474 as specified in CMP Updates [I-D.brockhaus-lamps-cmp-updates] and 475 private key allowing it to protect CMP messages it processes (CMP 476 signing key/certificate). The figure above shows an architecture 477 using one LRA and one RA. It is also possible to have only an RA or 478 multiple LRAs and/or RAs. Depending on the network infrastructure, 479 the communication between different PKI components may be synchronous 480 online-communication, delayed asynchronous communication, or even 481 offline file transfer. 483 As this profile focusses on specifying the pull model, where the EE 484 always requests a PKI management operation. CMP response messages, 485 especially in case of central key generation as described in 486 Section 5.1.6, can also be used to deliver proactively to the EE to 487 implement the push model. 489 Third-party CAs typically implement different variants of CMP or even 490 use proprietary interfaces for certificate management. Therefore, 491 the LRA or the RA may need to adapt the exchanged CMP messages to the 492 flavor of communication required by the CA. 494 3.2. Basic generic CMP message content 496 Section 4 specifies the generic parts of the CMP messages as used 497 later in Section 5 and Section 6. 499 o Header of a CMP message; see Section 4.1. 501 o Protection of a CMP message; see Section 4.2. 503 o ExtraCerts field of a CMP message; see Section 4.3. 505 3.3. Supported use cases 507 Following the outlined scope from Section 2.5, this section gives a 508 brief overview of the certificate management use cases specified in 509 Section 5 and Section 6 and points out, if an implementation by 510 compliant EE or PKI component is mandatory, recommended or optional. 512 3.3.1. Mandatory use cases 514 The mandatory uses case in this document shall limit the overhead of 515 certificate management for more constrained devices to the most 516 crucial types of transactions. 518 Section 5 - End Entity focused certificate management use cases 520 o Request a certificate from a new PKI with signature protection; 521 see Section 5.1.1. 523 o Request to update an existing certificate with signature 524 protection; see Section 5.1.3. 526 o Error reporting; see Section 5.3. 528 Section 6 - LRA and RA focused certificate management use cases 530 o Forward messages without changes; see Section 6.1.1. 532 o Forward messages with replaced protection and raVerified as proof- 533 of-possession; see Section 6.1.2.2. 535 o Error reporting; see Section 6.3. 537 3.3.2. Recommended Use Cases 539 Additional recommended use cases shall support some more complex 540 scenarios, that are considered as beneficial for environments with 541 more specific boundary conditions. 543 Section 5 - End Entity focused certificate management use cases 545 o Request a certificate from a PKI with MAC protection; see 546 Section 5.1.4. 548 o Handle delayed enrollment due to asynchronous message delivery; 549 see Section 5.1.7. 551 o Revoke an own certificate. 553 Section 6 - LRA and RA focused certificate management use cases 555 o Revoke another's entities certificate. 557 3.3.3. Optional use cases 559 The optional use cases support specific requirements seen only in a 560 subset of environments. 562 Section 5 - End Entity focused certificate management use cases 564 o Request a certificate from a legacy PKI using a PKCS#10 [RFC2986] 565 request; see Section 5.1.5. 567 o Add central generation of a key pair to a certificate request; see 568 Section 5.1.6. 570 o Additional support messages, e.g., to update a Root CA certificate 571 or to request an RFC 8366 [RFC8366] voucher; see Section 5.4. 573 Section 6 - LRA and RA focused certificate management use cases 574 o Initiate delayed enrollment due to asynchronous message delivery; 575 see Section 6.1.3. 577 3.4. CMP message transport 579 Recommended transport 581 o Transfer CMP messages using HTTP; see Section 7.1. 583 Optional transport 585 o Transfer CMP messages using HTTPS with certificate-based 586 authentication; see Section 7.2. 588 o Transfer CMP messages using HTTPS with shared-secret based 589 protection; see Section 7.3. 591 o File-based CMP message transport. 593 < Motivation see Section 7.4, specification TBD > 595 4. Generic parts of the PKI message 597 To reduce redundancy in the text and to ease implementation, the 598 contents of the header, protection, and extraCerts fields of the CMP 599 messages used in the transactions specified in Section 5 and 600 Section 6 are standardized to the maximum extent possible. 601 Therefore, the generic parts of a CMP message are described centrally 602 in this section. 604 As described in section 5.1 of [RFC4210], all CMP messages have the 605 following general structure: 607 +--------------------------------------------+ 608 | PKIMessage | 609 | +----------------------------------------+ | 610 | | header | | 611 | +----------------------------------------+ | 612 | +----------------------------------------+ | 613 | | body | | 614 | +----------------------------------------+ | 615 | +----------------------------------------+ | 616 | | protection (OPTIONAL) | | 617 | +----------------------------------------+ | 618 | +----------------------------------------+ | 619 | | extraCerts (OPTIONAL) | | 620 | +----------------------------------------+ | 621 +--------------------------------------------+ 623 Figure 2: CMP message structure 625 The general contents of the message header, protection, and 626 extraCerts fields are specified in the Section 4.1 to Section 4.3. 628 In case a specific CMP message needs different contents in the 629 header, protection, or extraCerts fields, the differences are 630 described in the respective message. 632 The CMP message body contains the message-specific information. It 633 is described in the context of Section 5 and Section 6. 635 The behavior in case an error occurs while handling a CMP message is 636 described in Section 6.3. 638 4.1. General description of the CMP message header 640 This section describes the generic header field of all CMP messages 641 with signature-based protection. The only variations described here 642 are in the fields recipient, transactionID, and recipNonce of the 643 first message of a transaction. 645 In case a message has MAC-based protection the changes are described 646 in the respective section. The variations will affect the fields 647 sender, protectionAlg, and senderKID. 649 For requirements about proper random number generation please refer 650 to [RFC4086]. Any message-specific fields or variations are 651 described in the respective sections of this chapter. 653 header 654 pvno REQUIRED 655 -- MUST be set to 2 to indicate CMP V2 656 sender REQUIRED 657 -- MUST be the subject of the signing certificate used for 658 -- protection of this message 659 recipient REQUIRED 660 -- MUST be the name of the intended recipient 661 -- If this is the first message of a transaction: SHOULD be the 662 -- subject of the issuing CA certificate 663 -- In all other messages: SHOULD be the same name as in the 664 -- sender field of the previous message in this transaction 665 messageTime RECOMMENDED 666 -- MUST be the time at which the message was produced, if 667 -- present 668 protectionAlg REQUIRED 669 -- MUST be the algorithm identifier of the signature or algorithm 670 -- id-PasswordBasedMac algorithm used for calculation of the 671 -- protection bits 672 -- The signature algorithm MUST be consistent with the 673 -- SubjectPublicKeyInfo field of the signer's certificate 674 -- The hash algorithm used SHOULD be SHA-256 675 algorithm REQUIRED 676 -- MUST be the OID of the signature algorithm, like 677 -- sha256WithRSAEncryption or ecdsa-with-SHA256, or 678 -- id-PasswordBasedMac 679 senderKID RECOMMENDED 680 -- MUST be the SubjectKeyIdentifier, if available, of the 681 -- certificate used for protecting this message 682 transactionID REQUIRED 683 -- If this is the first message of a transaction: 684 -- MUST be 128 bits of random data for the start of a 685 -- transaction to reduce the probability of having the 686 -- transactionID already in use at the server 687 -- In all other messages: 688 -- MUST be the value from the previous message in the same 689 -- transaction 690 senderNonce REQUIRED 691 -- MUST be fresh 128 random bits 692 recipNonce RECOMMENDED 693 -- If this is the first message of a transaction: SHOULD be 694 -- absent 695 -- In all other messages: MUST be present and contain the value 696 -- from senderNonce of the previous message in the same 697 -- transaction 698 generalInfo OPTIONAL 699 implicitConfirm OPTIONAL 700 ImplicitConfirmValue REQUIRED 702 -- The field is optional though it only applies to 703 -- ir/cr/kur/p10cr requests and ip/cp/kup responses 704 -- ImplicitConfirmValue of the request message MUST be NULL if 705 -- the EE wants to request not to send a confirmation message 706 -- ImplicitConfirmValue MUST be set to NULL if the (L)RA/CA wants 707 -- to grant not sending a confirmation message 709 4.2. General description of the CMP message protection 711 This section describes the generic protection field of all CMP 712 messages with signature-based protection. 714 protection REQUIRED 715 -- MUST contain the signature calculated using the signature 716 -- algorithm specified in protectionAlg 718 Only for MAC-based protection major differences apply as described in 719 the respective message. 721 The CMP message protection provides, if available, message origin 722 authentication and integrity protection for the CMP message header 723 and body. The CMP message extraCerts is not covered by this 724 protection. 726 NOTE: The requirements for checking certificates given in [RFC5280] 727 MUST be followed for the CMP message protection. OCSP or CRLs SHOULD 728 be used for status checking of the CMP signer certificates of 729 communication partners. 731 4.3. General description of CMP message extraCerts 733 This section describes the generic extraCerts field of all CMP 734 messages with signature-based protection. 736 extraCerts RECOMMENDED 737 -- SHOULD contain the signing certificate together with its 738 -- chain, if needed 739 -- If present, the first certificate in this field MUST 740 -- be the certificate used for signing this message 741 -- Self-signed certificates SHOULD NOT be included in 742 -- extraCerts and MUST NOT be trusted based on the listing in 743 -- extraCerts in any case 745 5. End Entity focused certificate management use cases 747 This chapter focuses on the communication of the EE and the first PKI 748 component it talks to. Depending on the network and PKI solution, 749 this will either be the LRA, the RA or the CA. 751 Profiles of the Certificate Management Protocol (CMP) [RFC4210] 752 handled in this chapter cover the following certificate management 753 use cases: 755 o Requesting a certificate from a PKI with variations like initial 756 requests and updating, central key generation and different 757 protection means 759 o Revocation of a certificate 761 o General messages for further support functions 763 The use cases mainly specify the message body of the CMP messages and 764 utilize the specification of the message header, protection and 765 extraCerts as specified in Section 5. 767 The behavior in case an error occurs is described in Section 5.3. 769 This chapter is aligned to Appendix D and Appendix E of [RFC4210]. 770 The general rules for interpretation stated in Appendix D.1 in 771 [RFC4210] need to be applied here, too. 773 This document does not mandate any specific supported algorithms like 774 Appendix D.2 of [RFC4210], [ETSI-3GPP], and [UNISIG] do. Using the 775 message sequences described here require agreement upon the 776 algorithms to support and thus the algorithm identifiers for the 777 specific target environment. 779 5.1. Requesting a new certificate from a PKI 781 There are different approaches to request a certificate from a PKI. 783 These approaches differ on the one hand in the way the EE can 784 authenticate itself to the PKI it wishes to get a new certificate 785 from and on the other hand in its capabilities to generate a proper 786 new key pair. The authentication means may be as follows: 788 o Using a certificate from a trusted PKI and the corresponding 789 private key, e.g., a manufacturer certificate 791 o Using the certificate to be updated and the corresponding private 792 key 794 o Using a shared secret known to the EE and the PKI 796 Typically, such EE requests a certificate from a CA. When the (L)RA/ 797 CA responds with a message containing a certificate, the EE MUST 798 reply with a confirmation message. The (L)RA/CA then MUST send 799 confirmation back, closing the transaction. 801 The message sequences in this section allow the EE to request 802 certification of a locally generated public-private key pair. For 803 requirements about proper random number and key generation please 804 refer to [RFC4086]. The EE MUST provide a signature-based proof-of- 805 possession of the private key associated with the public key 806 contained in the certificate request as defined by [RFC4211] section 807 4.1 case 3. To this end it is assumed that the private key can 808 technically be used as signing key. The most commonly used 809 algorithms are RSA and ECDSA, which can technically be used for 810 signature calculation regardless of potentially intended restrictions 811 of the key usage. 813 The requesting EE provides the binding of the proof-of-possession to 814 its identity by signature-based or MAC-based protection of the CMP 815 request message containing that POPO. The (L)RA/CA needs to verify 816 whether this EE is authorized to obtain a certificate with the 817 requested subject and other attributes and extensions. Especially 818 when removing the protection provided by the EE and applying a new 819 protection the (L)RA MUST verify in particular the included proof-of- 820 possession self-signature of the certTemplate using the public key of 821 the requested certificate and MUST check that the EE, as 822 authenticated by the message protection, is authorized to request a 823 certificate with the subject as specified in the certTemplate (see 824 Section 6.1.2). 826 There are several ways to install the Root CA certificate of a new 827 PKI on an EE. The installation can be performed in an out-of-band 828 manner, using general messagesm, a voucher [RFC8366], or other 829 formats for enrolment, or in-band of CMP by the caPubs field in the 830 certificate response message. In case the installation of the new 831 Root CA certificate is performed using the caPubs field, the 832 certificate response message MUST be properly authenticated, and the 833 sender of this message MUST be authorized to install new Root CA 834 certificates on the EE. This authorization MUST be indicated by the 835 extended key usage in the (L)RA/CA certificate as specified in CMP 836 Updates [I-D.brockhaus-lamps-cmp-updates]. 838 5.1.1. A certificate from a new PKI with signature protection 840 This message sequence should be used by an EE to request a 841 certificate of a new PKI using an existing certificate from an 842 external PKI, e.g., a manufacturer certificate, to prove its identity 843 to the new PKI. The EE already has established trust in this new PKI 844 it is about to enroll to, e.g., by configuration means. The 845 initialization request message is signature-protected using the 846 existing certificate. 848 Preconditions: 850 1 The EE MUST have a certificate enrolled by an external PKI in 851 advance to this transaction to authenticate itself to the (L)RA/CA 852 using signature-based protection, e.g., using a manufacturer 853 certificate. 855 2 The EE SHOULD know the subject name of the new CA it requests a 856 certificate from; this name MAY be established using an enrollment 857 voucher or other configuration means. If the EE does not know the 858 name of the CA, the (L)RA/CA MUST know where to route this request 859 to. 861 3 The EE MUST authenticate responses from the (L)RA/CA; trust MAY be 862 established using an enrollment voucher or other configuration 863 means 865 4 The (L)RA/CA MUST trust the external PKI the EE uses to 866 authenticate itself; trust MAY be established using some 867 configuration means 869 This message sequence is like that given in [RFC4210] Appendix E.7. 871 Message flow: 873 Step# EE (L)RA/CA 874 1 format ir 875 2 -> ir -> 876 3 handle, re-protect or 877 forward ir 878 4 format or receive ip 879 5 possibly grant implicit 880 confirm 881 6 <- ip <- 882 7 handle ip 883 8 In case of status 884 "rejection" in the 885 ip message, no certConf 886 and pkiConf are sent 887 9 format certConf (optional) 888 10 -> certConf -> 889 11 handle, re-protect or 890 forward certConf 891 12 format or receive PKIConf 892 13 <- pkiConf <- 893 14 handle pkiConf (optional) 895 For this message sequence the EE MUST include exactly one single 896 CertReqMsg in the ir. If more certificates are required, further 897 requests MUST be sent using separate CMP Messages. If the EE wants 898 to omit sending a certificate confirmation message after receiving 899 the ip to reduce the number of protocol messages exchanged in a 900 transaction, it MUST request this by setting the implicitControlValue 901 in the ir to NULL. 903 If the CA accepts the request it MUST return the new certificate in 904 the certifiedKeyPair field of the ip message. If the EE requested to 905 omit sending a certConf message after receiving the ip, the (L)RA/CA 906 MAY confirm this by also setting the implicitControlValue in the ip 907 to NULL. 909 If the EE did not request implicit confirmation or the request was 910 not granted by the (L)RA/CA the confirmation as follows MUST be 911 performed. If the EE successfully receives the certificate and 912 accepts it, the EE MUST send a certConf message, which MUST be 913 answered by the (L)RA/CA with a pkiConf message. If the (L)RA/CA 914 does not receive the expected certConf message in time it MUST handle 915 this like a rejection by the EE. 917 If the certificate request was refused by the CA, the (L)RA/CA must 918 return an ip message containing the status code "rejection" and no 919 certifiedKeyPair field. Such an ip message MUST NOT be followed by 920 the certConf and pkiConf messages. 922 Detailed message description: 924 Certification Request -- ir 926 Field Value 928 header 929 -- As described in section 3.1 931 body 932 -- The request of the EE for a new certificate 933 ir REQUIRED 934 -- MUST be exactly one CertReqMsg 935 -- If more certificates are required, further requests MUST be 936 -- packaged in separate PKI Messages 937 certReq REQUIRED 938 certReqId REQUIRED 939 -- MUST be set to 0 940 certTemplate REQUIRED 941 version OPTIONAL 942 -- MUST be 2 if supplied. 943 subject REQUIRED 944 -- MUST contain the suggested subject name of the EE 945 -- certificate 946 publicKey REQUIRED 947 algorithm REQUIRED 948 -- MUST include the subject public key algorithm ID and value 949 -- In case a central key generation is requested, this field 950 -- contains the algorithm and parameter preferences of the 951 -- requesting entity regarding the to-be-generated key pair 952 subjectPublicKey REQUIRED 953 -- MUST contain the public key to be included into the requested 954 -- certificate in case of local key-generation 955 -- MUST contain a zero-length BIT STRING in case a central key 956 -- generation is requested 957 -- MUST include the subject public key algorithm ID and value 958 extensions OPTIONAL 959 -- MAY include end-entity-specific X.509 extensions of the 960 -- requested certificate like subject alternative name, 961 -- key usage, and extended key usage 962 Popo REQUIRED 963 POPOSigningKey OPTIONAL 964 -- MUST be used in case subjectPublicKey contains a public key 965 -- MUST be absent in case subjectPublicKey contains a 966 -- zero-length BIT STRING 967 POPOSigningKey REQUIRED 968 poposkInput PROHIBITED 969 -- MUST NOT be used because subject and publicKey are both 970 -- present in the certTemplate 971 algorithmIdentifier REQUIRED 972 -- The signature algorithm MUST be consistent with the 973 -- publicKey field of the certTemplate 974 -- The hash algorithm used SHOULD be SHA-256 975 signature REQUIRED 976 -- MUST be the signature computed over the DER-encoded 977 -- certTemplate 979 protection REQUIRED 980 -- As described in section 3.2 982 extraCerts REQUIRED 983 -- As described in section 3.3 985 Certification Response -- ip 987 Field Value 989 header 990 -- As described in section 3.1 992 body 993 -- The response of the CA to the request as appropriate 994 ip REQUIRED 995 caPubs OPTIONAL 996 -- MAY be used 997 -- If used it MUST contain only the root certificate of the 998 -- certificate contained in certOrEncCert 999 response REQUIRED 1000 -- MUST be exactly one CertResponse 1001 certReqId REQUIRED 1002 -- MUST be set to 0 1003 status REQUIRED 1004 -- PKIStatusInfo structure MUST be present 1005 status REQUIRED 1006 -- positive values allowed: "accepted", "grantedWithMods" 1007 -- negative values allowed: "rejection" 1008 -- In case of rejection no certConf and pkiConf messages will 1009 -- be sent 1010 statusString OPTIONAL 1011 -- MAY be any human-readable text for debugging, logging or to 1012 -- display in a GUI 1013 failInfo OPTIONAL 1015 -- MUST be present if status is "rejection" and in this case 1016 -- the transaction MUST be terminated 1017 -- MUST be absent if the status is "accepted" or 1018 -- "grantedWithMods" 1019 certifiedKeyPair OPTIONAL 1020 -- MUST be present if status is "accepted" or "grantedWithMods" 1021 -- MUST be absent if status is "rejection" 1022 certOrEncCert REQUIRED 1023 -- MUST be present when certifiedKeyPair is present 1024 certificate REQUIRED 1025 -- MUST be present when certifiedKeyPair is present 1026 -- MUST contain the newly enrolled X.509 certificate 1027 privateKey OPTIONAL 1028 -- MUST be absent in case of local key-generation 1029 -- MUST contain the encrypted private key in an EnvelopedData 1030 -- structure as specified in section 5.1.5 in case the private 1031 -- key was generated centrally 1033 protection REQUIRED 1034 -- As described in section 3.2 1036 extraCerts REQUIRED 1037 -- As described in section 3.3 1038 -- MUST contain the chain of the issued certificate 1039 -- Duplicate certificates MAY be omitted 1041 Certificate Confirmation -- certConf 1043 Field Value 1045 header 1046 -- As described in section 3.1 1048 body 1049 -- The message of the EE sends confirmation to the (L)RA/CA 1050 -- to accept or reject the issued certificates 1051 certConf REQUIRED 1052 -- MUST be exactly one CertStatus 1053 CertStatus REQUIRED 1054 certHash REQUIRED 1055 -- MUST be the hash of the certificate, using the same hash 1056 -- algorithm as used to create the certificate signature 1057 certReqId REQUIRED 1058 -- MUST be set to 0 1059 status RECOMMENDED 1060 -- PKIStatusInfo structure SHOULD be present 1061 -- Omission indicates acceptance of the indicated certificate 1062 status REQUIRED 1063 -- positive values allowed: "accepted" 1064 -- negative values allowed: "rejection" 1065 statusString OPTIONAL 1066 -- MAY be any human-readable text for debugging or logging 1067 failInfo OPTIONAL 1068 -- MUST be present if status is "rejection" 1069 -- MUST be absent if the status is "accepted" 1071 protection REQUIRED 1072 -- As described in section 3.2 1073 -- MUST use the same certificate as for protection of the ir 1075 extraCerts RECOMMENDED 1076 -- SHOULD contain the protection certificate together with its 1077 -- chain 1078 -- If present, the first certificate in this field MUST be the 1079 -- certificate used for signing this message 1080 -- Self-signed certificates SHOULD NOT be included in 1081 -- extraCerts and 1082 -- MUST NOT be trusted based on the listing in extraCerts in 1083 -- any case 1085 PKI Confirmation -- pkiConf 1087 Field Value 1089 header 1090 -- As described in section 3.1 1092 body 1093 pkiConf REQUIRED 1094 -- The content of this field MUST be NULL 1096 protection REQUIRED 1097 -- As described in section 3.2 1098 -- SHOULD use the same certificate as for protection of the ip 1100 extraCerts RECOMMENDED 1101 -- SHOULD contain the protection certificate together with its 1102 -- chain 1103 -- If present, the first certificate in this field MUST be the 1104 -- certificate used for signing this message 1105 -- Self-signed certificates SHOULD NOT be included in extraCerts 1106 -- and 1107 -- MUST NOT be trusted based on the listing in extraCerts in 1108 -- any case 1110 5.1.2. A certificate from a trusted PKI with signature protection 1112 < TBD: In case the PKI is already trusted the cr/cp messages could be 1113 used instead of ir/ip. It needs to be decided, whether an additional 1114 section should be added here, or the previous section should be 1115 extended to also cover this use case. > 1117 5.1.3. Update an existing certificate with signature protection 1119 This message sequence should be used by an EE to request an update of 1120 one of the certificates it already has and that is still valid. The 1121 EE uses the certificate it wishes to update to prove its identity and 1122 possession of the private key for the certificate to be updated to 1123 the PKI. Therefore, the key update request message is signed using 1124 the certificate that is to be updated. 1126 The general message flow for this message sequence is the same as 1127 given in Section 5.1.1. 1129 Preconditions: 1131 1 The certificate the EE wishes to update MUST NOT be expired or 1132 revoked. 1134 2 A new public-private key pair SHOULD be used. 1136 The message sequence for this exchange is like that given in 1137 [RFC4210] Appendix D.6. 1139 The message sequence for this exchange is identical to that given in 1140 Section 5.1.1, with the following changes: 1142 1 The body of the first request and response MUST be kur and kup, 1143 respectively. 1145 2 Protection of the kur MUST be performed using the certificate to 1146 be updated. 1148 3 The subject field of the CertTemplate MUST contain the subject 1149 name of the existing certificate to be updated, without 1150 modifications. 1152 4 The CertTemplate MUST contain the subject, issuer and publicKey 1153 fields only. 1155 5 The regCtrl OldCertId SHOULD be used to make clear, even in case 1156 an (L)RA changes the message protection, which certificate is to 1157 be. 1159 6 The caPubs field in the kup message MUST be absent. 1161 As part of the certReq structure of the kur the control is added 1162 right after the certTemplate. 1164 controls 1165 type RECOMMENDED 1166 -- MUST be the value id-regCtrl-oldCertID, if present 1167 value 1168 issuer REQUIRED 1169 serialNumber REQUIRED 1170 -- MUST contain the issuer and serialNumber of the certificate 1171 -- to be updated 1173 5.1.4. A certificate from a PKI with MAC protection 1175 This message sequence should be used by an EE to request a 1176 certificate of a new PKI without having a certificate to prove its 1177 identity to the target PKI, but there is a shared secret established 1178 between the EE and the PKI. Therefore, the initialization request is 1179 MAC-protected using this shared secret. The (L)RA checking the MAC- 1180 protection SHOULD replace this protection according to Section 6.1.2 1181 in case the next hop does not know the shared secret. 1183 For requirements with regard to proper random number and key 1184 generation please refer to [RFC4086]. 1186 The general message flow for this message sequence is the same as 1187 given in Section 5.1.1. 1189 Preconditions: 1191 1 The EE and the (L)RA/CA MUST share a symmetric key, this MAY be 1192 established by a service technician during initial local 1193 configuration. 1195 2 The EE SHOULD know the subject name of the new CA it requests a 1196 certificate from; this name MAY be established using an enrollment 1197 voucher or other configuration means. If the EE does not know the 1198 name of the CA, the (L)RA/CA MUST know where to route this request 1199 to. 1201 3 The EE MUST authenticate responses from the (L)RA/CA; trust MAY be 1202 established using the shared symmetric key. 1204 The message sequence for this exchange is like that given in 1205 [RFC4210] Appendix D.4. 1207 The message sequence for this exchange is identical to that given in 1208 Section 5.1.1, with the following changes: 1210 1 The protection of all messages MUST be calculated using Message 1211 Authentication Code (MAC); the protectionAlg field MUST be id- 1212 PasswordBasedMac as described in section 5.1.3.1 of [RFC4210]. 1214 2 The sender MUST contain a name representing the originator of the 1215 message. The senderKID MUST contain a reference all participating 1216 entities can use to identify the symmetric key used for the 1217 protection. 1219 3 The extraCerts of the ir, certConf, and PKIConf messages MUST be 1220 absent. 1222 4 The extraCerts of the ip message MUST contain the chain of the 1223 issued certificate and root certificates SHOULD not be included 1224 and MUST NOT be trusted in any case. 1226 Part of the protectionAlg structure, where the algorithm identifier 1227 MUST be id-PasswordBasedMac, is a PBMParameter sequence. The fields 1228 of PBMParameter SHOULD remain constant for message protection 1229 throughout this certificate management transaction to reduce the 1230 computational overhead. 1232 PBMParameter REQUIRED 1233 salt REQUIRED 1234 -- MUST be the random value to salt the secret key 1235 owf REQUIRED 1236 -- MUST be the algorithm identifier for the one-way function 1237 -- used 1238 -- The one-way function SHA-1 MUST be supported due to 1239 -- [RFC4211] requirements, but SHOULD NOT be used any more 1240 -- SHA-256 SHOULD be used instead 1241 iterationCount REQUIRED 1242 -- MUST be a limited number of times the OWF is applied 1243 -- To prevent brute force and dictionary attacks a reasonable 1244 -- high number SHOULD be used 1245 mac REQUIRED 1246 -- MUST be the algorithm identifier of the MAC algorithm used 1247 -- The MAC function HMAC-SHA1 MUST be supported due to 1248 -- [RFC4211] requirements, but SHOULD NOT be used any more 1249 -- HMAC-SHA-256 SHOULD be used instead 1251 5.1.5. A certificate from a legacy PKI using PKCS#10 request 1253 This message sequence should be used by an EE to request a 1254 certificate of a legacy PKI only capable to process PKCS#10 [RFC2986] 1255 certification requests. The EE can prove its identity to the target 1256 PKI by using various protection means as described in Section 5.1.1 1257 or Section 5.1.4. 1259 In contrast to the other transactions described in Section 5.1, this 1260 transaction uses PKCS#10 [RFC2986] instead of CRMF [RFC4211] for the 1261 certificate request for compatibility reasons with legacy CA systems 1262 that require a PKCS#10 certificate request and cannot process CMP 1263 [RFC4210] or CRMF [RFC4211] messages. In such case the (L)RA must 1264 extract the PKCS#10 certificate request from the p10cr and provides 1265 it separately to the CA. 1267 The general message flow for this message sequence is the same as 1268 given in Section 5.1.1, but the public key is contained in the 1269 subjectPKInfo of the PKCS#10 certificate request. 1271 Preconditions: 1273 1 The EE MUST either have a certificate enrolled from this or any 1274 other accepted PKI, or a shared secret known to the PKI and the EE 1275 to authenticate itself to the (L)RA/CA. 1277 2 The EE SHOULD know the subject name of the CA it requests a 1278 certificate from; this name MAY be established using an enrollment 1279 voucher or other configuration means. If the EE does not know the 1280 name of the CA, the (L)RA/CA MUST know where to route this request 1281 to. 1283 3 The EE MUST authenticate responses from the (L)RA/CA; trust MAY be 1284 established by an available root certificate, using an enrollment 1285 voucher, or other configuration means. 1287 4 The (L)RA/CA MUST trust the current or the PKI the EE uses to 1288 authenticate itself; trust MAY be established by a corresponding 1289 available root certificate or using some configuration means. 1291 The profile for this exchange is identical to that given in 1292 Section 5.1.1, with the following changes: 1294 1 The body of the first request and response MUST be p10cr and cp, 1295 respectively. 1297 2 The subject name of the CA MUST be in the recipient field of the 1298 p10cr message header. 1300 3 The certReqId in the cp message MUST be 0. 1302 4 The caPubs field in the cp message SHOULD be absent. 1304 Detailed description of the p10cr message: 1306 Certification Request -- p10cr 1308 Field Value 1310 header 1311 -- As described in section 3.1 1313 body 1314 -- The request of the EE for a new certificate using a PKCS#10 1315 -- certificate request 1316 p10cr REQUIRED 1317 CertificationRequestInfo REQUIRED 1318 version REQUIRED 1319 -- MUST be set to 0 to indicate PKCS#10 V1.7 1320 subject REQUIRED 1321 -- MUST contain the suggested subject name of the EE 1322 subjectPKInfo REQUIRED 1323 -- MUST include the subject public key algorithm ID and value 1324 attributes OPTIONAL 1325 -- MAY contain a set of end-entity-specific attributes or X.509 1326 -- extensions to be included in the requested certificate or used 1327 -- otherwise 1328 signatureAlgorithm REQUIRED 1329 -- The signature algorithm MUST be consistent with the 1330 -- subjectPKInfo field. The hash algorithm used SHOULD be SHA-256 1331 signature REQUIRED 1332 -- MUST containing the self-signature for proof-of-possession 1334 protection REQUIRED 1335 -- As described in section 3.2 1337 extraCerts REQUIRED 1338 -- As described in section 3.3 1340 5.1.6. Generate the key pair centrally at the (L)RA/CA 1342 This functional extension can be applied in combination with 1343 certificate enrollment as described in Section 5.1.1 and 1344 Section 5.1.4. The functional extension can be used in case an EE is 1345 not abele or is not willing to generate is't new public-private key 1346 pair itself. It is a matter of the local implementation which 1347 central PKI components will perform the key generation. This 1348 component must have a proper (L)RA/CA certificate containing the 1349 additional extended key usage id-kp-cmcKGA to be identified by the EE 1350 as a legitimate key-generation instance. In case the (L)RA generated 1351 the new key pair for the EE, it can use Section 5.1.1 to 1352 Section 5.1.4 to request the certificate for this key pair as usual. 1354 Generally speaking, in a machine-to-machine scenario it is strongly 1355 preferable to generate public-private key pairs locally at the EE. 1356 Together with proof-of-possession of the private key in the 1357 certification request, this is to make sure that only the entity 1358 identified in the newly issued certificate is the only entity who 1359 ever hold the private key. 1361 There are some cases where an EE is not able or not willing to 1362 locally generate the new key pair. Reasons for this may be the 1363 following: 1365 o Lack of sufficient initial entropy. 1367 Note: Good random numbers are not only needed for key generation, but 1368 also for session keys and nonces in any security protocol. 1369 Therefore, we believe that a decent security architecture should 1370 anyways support good random number generation on the EE side or 1371 provide enough entropy for the RNG seed during manufacturing to 1372 guarantee good initial pseudo-random number generation. 1374 o Due to lack of computational resources, e.g., in case of RSA keys. 1376 Note: As key generation can be performed in advance to the 1377 certificate enrollment communication, it is typical not time 1378 critical. 1380 Note: Besides the initial enrollment right after the very first 1381 bootup of the device, where entropy available on the device may be 1382 insufficient, we do not see any good reason for central key 1383 generation. 1385 Note: As mentioned in Section 3.1 central key generation may be 1386 required in a push model, where the certificate response message is 1387 transfered by the (L)RA/CA to the EE without receiving a previos 1388 request message. 1390 If the EE wishes to request central key generation, it MUST fill the 1391 subjectPublicKey field in the certTemplate structure of the request 1392 message with a zero-length BIT STRING. This indicates to the (L)RA/ 1393 CA that a new key pair shall be generated centrally on behalf of the 1394 EE. 1396 Note: As the protection of centrally generated keys in the response 1397 message is being extended from EncryptedValue to EncryptedKey by CMP 1398 Updates [I-D.brockhaus-lamps-cmp-updates] also the alternative 1399 EnvelopedData can be used. In CRMF Section 2.1.9 [RFC4211] the use 1400 of EncryptedValue has been deprecated in favor of the EnvelopedData 1401 structure. Therefore, this profile specifies using EnvelopedData as 1402 specified in CMS Section 6 [RFC5652] to offer more crypto agility. 1404 +------------------------------+ 1405 | EnvelopedData | 1406 | [RFC5652] section 6 | 1407 | +--------------------------+ | 1408 | | SignedData | | 1409 | | [RFC5652] section 5 | | 1410 | | +----------------------+ | | 1411 | | | privateKey | | | 1412 | | | OCTET STRING | | | 1413 | | +----------------------+ | | 1414 | +--------------------------+ | 1415 +------------------------------+ 1417 Figure 3: Encrypted private key container 1419 The (L)RA/CA delivers the private key in the privateKey field in the 1420 certifiedKeyPair structure of the response message also containing 1421 the newly issued certificate. 1423 The private key MUST be wrapped in a SignedData structure, as 1424 specified in CMS Section 5 [RFC5652], signed by the KGA generating 1425 the key pair. The signature MUST be performed using a CMP signer 1426 certificate asserting the extended key usage kp-id-cmpKGA as 1427 described in CMP Updates [I-D.brockhaus-lamps-cmp-updates] to show 1428 the authorization to generate key pairs on behalf of an EE. 1430 This SignedData structure MUST be wrapped in an EnvelopedData 1431 structure, as specified in CMS Section 6 [RFC5652], encrypting it 1432 using a newly generated symmetric content-encryption key. 1434 Note: Instead of the specification in CMP Appendix D 4.4 [RFC4210] 1435 this content-encryption key is not generated on the EE side. As we 1436 just mentioned, central key generation should only be used in this 1437 profile in case of lack of randomness on the EE. 1439 As part of the EnvelopedData structure this content-encryption key 1440 MUST be securely provided to the EE using one of three key management 1441 techniques. The choice of the key management technique to be used by 1442 the (L)RA/CA depends on the authentication mechanism the EE choose to 1443 protect the request message. 1445 o MAC protected request message: The content-encryption key will be 1446 protected using the symmetric key-encryption key management 1447 technique, see Section 5.1.6.1. 1449 o Signature protected request message using a certificate that 1450 contains a key usage extension asserting keyAgreement: The 1451 content-encryption key will be protected using the key agreement 1452 key management technique, see Section 5.1.6.2. 1454 o Signature protected request message using a certificate that 1455 contains a key usage extension asserting keyEncipherment: The 1456 content-encryption key will be protected using the key transport 1457 key management technique, see Section 5.1.6.3. 1459 For encrypting the SignedData structure containing the private key a 1460 fresh content-encryption key MUST be generated with enough entropy 1461 with regard to the used symmetric encryption algorithm. 1463 Note: Depending on the lifetime of the certificate and the 1464 criticality of the generated private key, it is advisable to use the 1465 strongest possible symmetric encryption algorithm. Therefore, this 1466 specification recommends using at least AES-256. 1468 The detailed description of the privateKey field looks like this: 1470 privateKey OPTIONAL 1471 -- MUST be an envelopedData structure as specified in 1472 -- CMS [RFC5652] section 6 1473 version REQUIRED 1474 -- MUST be set to 2 1475 recipientInfos REQUIRED 1476 -- MUST be exactly one RecipientInfo 1477 recipientInfo REQUIRED 1478 -- MUST be either KEKRecipientInfo (see section 5.1.5.1), 1479 -- KeyAgreeRecipientInfo (see section 5.1.5.2), or 1480 -- KeyTransRecipientInfo (see section 5.1.5.3) is used 1481 encryptedContentInfo 1482 REQUIRED 1483 contentType REQUIRED 1484 -- MUST be id-signedData 1485 contentEncryptionAlgorithm 1486 REQUIRED 1487 -- MUST be the algorithm identifier of the symmetric 1488 -- content-encryption algorithm used 1489 -- As private keys need long-term protection, the use of AES-256 1490 -- or a stronger symmetric algorithm is RECOMMENDED 1491 encryptedContent REQUIRED 1492 -- MUST be the encrypted signedData structure as specified in 1493 -- CMS [RFC5652] section 5 1494 version REQUIRED 1495 -- MUST be set to 3 1496 digestAlgorithms 1497 REQUIRED 1498 -- MUST be exactly one digestAlgorithm identifier 1499 digestAlgorithmIdentifier 1500 REQUIRED 1501 -- MUST be the OID of the digest algorithm used for generating 1502 -- the signature 1503 -- The hash algorithm used SHOULD be SHA-256 1504 encapContentInfo 1505 REQUIRED 1506 -- MUST be the content that is to be signed 1507 contentType REQUIRED 1508 -- MUST be id-data 1509 content REQUIRED 1510 -- MUST be the privateKey as OCTET STRING 1511 certificates REQUIRED 1512 -- SHOULD contain the signing certificate together with its chain 1513 -- If present, the first certificate in this field MUST 1514 -- be the certificate used for signing this content 1515 -- Self-signed certificates SHOULD NOT be included 1516 -- and MUST NOT be trusted based on the listing in any case 1517 crls OPTIONAL 1518 -- MAY be present to provide status information on the signer or 1519 -- its CA certificates 1520 signerInfos REQUIRED 1521 -- MUST be exactly one signerInfo 1522 version REQUIRED 1523 -- MUST be set to 3 1524 sid REQUIRED 1525 subjectKeyIdentifier 1526 REQUIRED 1527 -- MUST be the subjectKeyIdentifier of the signer's certificate 1528 digest algorithm 1529 REQUIRED 1530 -- MUST be the same OID as in digest algorithm 1531 signatureAlgorithm 1532 REQUIRED 1533 -- MUST be the algorithm identifier of the signature algorithm 1534 -- used for calculation of the signature bits, 1535 -- like sha256WithRSAEncryption or ecdsa-with-SHA256 1536 -- The signature algorithm MUST be consistent with the 1537 -- SubjectPublicKeyInfo field of the signer's certificate 1538 signature REQUIRED 1539 -- MUST be the result of the digital signature generation 1541 5.1.6.1. Using symmetric key-encryption key management technique 1543 This key management technique can be applied in combination with the 1544 message flow specified in Section 5.1.4 using MAC protected CMP 1545 messages. The shared secret used for the MAC protection MUST also be 1546 used for the encryption of the content-encryption key but with a 1547 different seed in the PBMParameter sequence. To use this key 1548 management technique the KEKRecipientInfo structure MUST be used in 1549 the contentInfo field. 1551 The KEKRecipientInfo structure included into the envelopedData 1552 structure is specified in CMS Section 6.2.3 [RFC5652]. 1554 The detailed description of the KEKRecipientInfo structure looks like 1555 this: 1557 recipientInfo REQUIRED 1558 -- MUST be KEKRecipientInfo as specified in 1559 -- CMS section 6.2.3 [RFC5652] 1560 version REQUIRED 1561 -- MUST be set to 4 1562 kekid REQUIRED 1563 keyIdentifier REQUIRED 1564 -- MUST contain the same value as the senderKID in the respective 1565 -- request messages 1566 keyEncryptionAlgorithm 1567 REQUIRED 1568 -- MUST be id-PasswordBasedMac 1569 PBMParameter REQUIRED 1570 salt REQUIRED 1571 -- MUST be the random value to salt the secret key 1572 -- MUST be a different value than used in the PBMParameter 1573 -- data structure in the header of this message 1574 owf REQUIRED 1575 -- MUST be the same value than used in the PBMParameter 1576 -- data structure in the header of this message 1577 iterationCount 1578 REQUIRED 1579 -- MUST be a limited number of times the OWF is applied 1580 -- To prevent brute force and dictionary attacks a reasonable 1581 -- high number SHOULD be used 1582 mac REQUIRED 1583 -- MUST be the same as in the contentEncryptionAlgorithm field 1584 encryptedKey REQUIRED 1585 -- MUST be the encrypted content-encryption key 1587 < To make use of a different symmetric keys for encrypting the 1588 private key and for MAC-protection of the CMP Message, we derive 1589 another key using the same PBMParameter structure from CMP, even 1590 though from the perspective of field names, it is not intended to be 1591 used for deriving encryption keys. 1593 Does anyone sees a better solution here? > 1595 5.1.6.2. Using key agreement key management technique 1597 This key management technique can be applied in combination with the 1598 message flow specified in Section 5.1.1 using signature-based 1599 protected CMP messages. The public key of the EE certificate used 1600 for the signature-based protection of the request message MUST also 1601 be used for the Ephemeral-Static Diffie-Hellmann key establishment of 1602 the content-encryption key. To use this key management technique the 1603 KeyAgreeRecipientInfo structure MUST be used in the contentInfo 1604 field. 1606 The KeyAgreeRecipientInfo structure included into the envelopedData 1607 structure is specified in CMS Section 6.2.2 [RFC5652]. 1609 The detailed description of the KeyAgreeRecipientInfo structure looks 1610 like this: 1612 recipientInfo REQUIRED 1613 -- MUST be KeyAgreeRecipientInfo as specified in 1614 version REQUIRED 1615 -- MUST be set to 3 1616 originator REQUIRED 1617 -- MUST contain the originatorKey sequence 1618 algorithm REQUIRED 1619 -- MUST be the algorithm identifier of the 1620 -- static-ephemeral Diffie-Hellmann algorithm 1621 publicKey REQUIRED 1622 -- MUST be the ephemeral public key of the sending party 1623 ukm OPTIONAL 1624 -- MUST be used when 1-pass ECMQV is used 1625 keyEncryptionAlgorithm 1626 REQUIRED 1627 -- MUST be the same as in the contentEncryptionAlgorithm field 1628 recipientEncryptedKeys 1629 REQUIRED 1630 -- MUST be exactly one recipientEncryptedKey sequence 1631 recipientEncryptedKey 1632 REQUIRED 1633 rid REQUIRED 1634 rKeyId REQUIRED 1635 subjectKeyID 1636 REQUIRED 1637 -- MUST contain the same value as the senderKID in the respective 1638 -- request messages 1639 encryptedKey 1640 REQUIRED 1641 -- MUST be the encrypted content-encryption key 1643 5.1.6.3. Using key transport key management technique 1645 This key management technique can be applied in combination with the 1646 message flow specified in Section 5.1.1 using signature-based 1647 protected CMP messages. The public key of the EE certificate used 1648 for the signature-based protection of the request message MUST also 1649 be used for key encipherment of the content-encryption key. To use 1650 this key management technique the KeyTransRecipientInfo structure 1651 MUST be used in the contentInfo field. 1653 The KeyTransRecipientInfo structure included into the envelopedData 1654 structure is specified in CMS Section 6.2.1 [RFC5652]. 1656 The detailed description of the KeyTransRecipientInfo structure looks 1657 like this: 1659 recipientInfo REQUIRED 1660 -- MUST be KeyTransRecipientInfo as specified in 1661 -- CMS section 6.2.1 [RFC5652] 1662 version REQUIRED 1663 -- MUST be set to 2 1664 rid REQUIRED 1665 subjectKeyIdentifier 1666 REQUIRED 1667 -- MUST contain the same value as the senderKID in the respective 1668 -- request messages 1669 keyEncryptionAlgorithm 1670 REQUIRED 1671 -- MUST contain the key encryption algorithm identifier used for 1672 -- public key encryption 1673 encryptedKey REQUIRED 1674 -- MUST be the encrypted content-encryption key 1676 5.1.7. Delayed enrollment 1678 This functional extension can be applied in combination with 1679 certificate enrollment as described in Section 5.1.1 to 1680 Section 5.1.5. The functional extension can be used in case a (L)RA/ 1681 CA cannot respond to the certificate request in a timely manner, 1682 e.g., due to offline upstream communication or required registration 1683 officer interaction. Depending on the PKI architecture, it is not 1684 necessary that the PKI component directly communicating with the EE 1685 initiates the delayed enrollment. 1687 The PKI component initiating the delayed enrollment MUST include the 1688 status "waiting" in the response and this response MUST not contain 1689 the newly issued certificate. When receiving a response with status 1690 "waiting" the EE MUST send a poll request to the (L)RA/CA. The PKI 1691 component that initiated the delayed enrollment MUST answers with a 1692 poll response containing a checkAfter time. This value indicates the 1693 minimum number of seconds that must elapse before the EE sends 1694 another poll request. As soon as the (L)RA/CA can provide the final 1695 response message for the initial request of the EE, it MUST provide 1696 this in response to a poll request. After receiving this response, 1697 the EE can continue the original message sequence as described in the 1698 respective section of this document, e.g., send a certConf message. 1700 Typically, intermediate PKI entities SHOULD NOT change the sender and 1701 recipient nonce even in case an intermediate (L)RA modifies a request 1702 or a response message. In the special case of polling between EE and 1703 LRA with offline transport between an LRA and RA, see Section 6.1.3, 1704 an exception occurs. The EE and LRA exchange pollReq and pollRep 1705 messages handle the nonce words as described. When, after pollRep, 1706 the final response from the CA arrives at the LRA, the next response 1707 will contain the recipientNonce set to the value of the senderNonce 1708 in the original request message (copied by the CA). The LRA needs to 1709 replace the recipientNonce in this case with the senderNonce of the 1710 last pollReq because the EE will validate it in this way. 1712 Message flow: 1714 Step# EE (L)RA/CA 1715 1 format ir/cr/p10cr/kur 1716 As described in the 1717 respective section 1718 in this document 1719 2 ->ir/cr/p10cr/kur-> 1720 3 handle request as described 1721 in the respective section 1722 in this document 1723 4 in case no immediate final 1724 response is possible, 1725 receive or format ip, cp 1726 or kup message containing 1727 status "waiting" 1728 5 <- ip/cp/kup <- 1729 6 handle ip/cp/kup 1730 7 format pollReq 1731 8 -> pollReq -> 1732 9 handle, re-protect or 1733 forward pollReq 1734 10 in case the requested 1735 certificate or a 1736 corresponding response 1737 message is available, 1738 receive or format ip, cp, 1739 or kup containing the 1740 issued certificate, or 1741 format or receive pollRep 1742 with appropriate 1743 checkAfter value 1744 11 <- pollRep <- 1745 12 handle pollRep 1746 13 let checkAfter 1747 time elapse 1748 14 continue with line 7 1750 Detailed description of the first ip/cp/kup: 1752 Response with status 'waiting' -- ip/cp/kup 1754 Field Value 1756 header 1757 -- MUST contain a header as described for the first response 1758 -- message of the respective sheme 1760 body 1761 -- The response of the (L)RA/CA to the request in case no 1762 -- immediate appropriate response can be sent 1763 ip/cp/kup REQUIRED 1764 response REQUIRED 1765 -- MUST be exactly one CertResponse 1766 certReqId REQUIRED 1767 -- MUST be set to 0 1768 status REQUIRED 1769 -- PKIStatusInfo structure MUST be present 1770 status REQUIRED 1771 -- MUST be set to "waiting" 1772 statusString OPTIONAL 1773 -- MAY be any human-readable text for debugging, logging or to 1774 -- display in a GUI 1775 failInfo PROHIBITED 1776 certifiedKeyPair PROHIBITED 1778 protection REQUIRED 1779 -- MUST contain protection as described for the first response 1780 -- message of the respective profile, but 1781 -- MUST use the protection key of the (L)RA/CA initiating the 1782 -- delayed enrollment and creating this response message 1784 extraCerts REQUIRED 1785 -- MUST contain certificates as described for the first response 1786 -- message of the respective profile. 1787 -- As no new certificate is issued yet, no respective certificate 1788 -- chain is included. 1790 Polling Request -- pollReq 1792 Field Value 1794 header 1795 -- MUST contain a header as described for the certConf message 1796 -- of the respective sheme 1798 body 1799 -- The message of the EE asks for the final response or for a 1800 -- time to check again 1801 pollReq REQUIRED 1802 certReqId REQUIRED 1803 -- MUST be exactly one value 1804 -- MUST be set to 0 1806 protection REQUIRED 1807 -- MUST contain protection as described for the certConf message 1808 -- of the respective profile 1810 extraCerts OPTIONAL 1811 -- If present, it MUST contain certificates as described for the 1812 -- certConf message of the respective profile. 1814 Polling Response -- pollRep 1816 Field Value 1818 header 1819 -- MUST contain a header as described for the pkiConf message 1820 -- of the respective sheme 1822 body pollRep 1823 -- The message indicated the time to after which the EE may 1824 -- send another pollReq messaged for this transaction 1825 pollRep REQUIRED 1826 -- MUST be exactly one set of the following values 1827 certReqId REQUIRED 1828 -- MUST be set to 0 1829 checkAfter REQUIRED 1830 -- time in seconds to elapse before a new pollReq may be sent by 1831 -- the EE 1833 protection REQUIRED 1834 -- MUST contain protection as described for the pkiConf message 1835 -- of the respective profile, but 1836 -- MUST use the protection key of the (L)RA/CA that initiated the 1837 -- delayed enrollment and is creating this response message 1839 extraCerts OPTIONAL 1840 -- If present, it MUST contain certificates as described for the 1841 -- pkiConf message of the respective profile. 1843 Final response -- ip/cp/kup 1844 Field Value 1846 header 1847 -- MUST contain a header as described for the first 1848 -- response message of the respective sheme 1849 -- but the recipientNonce MUST be the senderNonce of the last 1850 -- pollReq message 1852 body 1853 -- The response of the (L)RA/CA to the initial request as 1854 -- described in the respective profile 1856 protection REQUIRED 1857 -- MUST contain protection as described for the first response 1858 -- message of the respective profile, but 1859 -- MUST use the protection key of the (L)RA/CA that initiated the 1860 -- delayed enrollment and forwarding the response message 1862 extraCerts REQUIRED 1863 -- MUST contain certificates as described for the first 1864 -- response message of the respective profile 1866 5.2. Revoking a certificate 1868 This message sequence should be used by an entity to request the 1869 revocation of a certificate. Here the revocation request is used by 1870 an EE to revoke one of its own certificates. A (L)RA could also act 1871 as an EE to revoke one of its own certificates. 1873 The revocation request message MUST be signed using the certificate 1874 that is to be revoked to prove the authorization to revoke to the 1875 PKI. The revocation request message is signature-protected using 1876 this certificate. 1878 An EE requests the revocation of an own certificate at the CA that 1879 issued this certificate. The (L)RA/CA responds with a message that 1880 contains the status of the revocation from the CA. 1882 Preconditions: 1884 1 The certificate the EE wishes to revoke is not yet expired or 1885 revoked. 1887 Message flow: 1889 Step# EE (L)RA/CA 1890 1 format rr 1891 2 -> rr -> 1892 3 handle, re-protect or 1893 forward rr 1894 4 receive rp 1895 5 <- rp <- 1896 6 handle rp 1898 For this profile, the EE MUST include exactly one RevDetails 1899 structure in the rr. In case no error occurred the response to the 1900 rr MUST be an rp message. The (L)RA/CA MUST produce a rp containing 1901 a status field with a single set of values. 1903 Detailed message description: 1905 Revocation Request -- rr 1907 Field Value 1909 header 1910 -- As described in section 3.1 1912 body 1913 -- The request of the EE to revoke its certificate 1914 rr REQUIRED 1915 -- MUST contain exactly one element of type RevDetails 1916 -- If more revocations are desired, further requests MUST be 1917 -- packaged in separate PKI Messages 1918 certDetails REQUIRED 1919 -- MUST be present and is of type CertTemplate 1920 serialNumber REQUIRED 1921 -- MUST contain the certificate serialNumber attribute of the 1922 -- X.509 certificate to be revoked 1923 issuer REQUIRED 1924 -- MUST contain the issuer attribute of the X.509 certificate to 1925 -- be revoked 1926 crlEntryDetails REQUIRED 1927 -- MUST contain exactly one reasonCode of type CRLReason (see 1928 -- [RFC5280] section 5.3.1) 1929 -- If the reason for this revocation is not known or shall not be 1930 -- published the reasonCode MUST be 0 = unspecified 1932 protection REQUIRED 1933 -- As described in section 3.2 and the private key related to the 1934 -- certificate to be revoked 1936 extraCerts REQUIRED 1937 -- As described in section 3.3 1939 Revocation Response -- rp 1941 Field Value 1943 header 1944 -- As described in section 3.1 1946 body 1947 -- The responds of the (L)RA/CA to the request as appropriate 1948 rp REQUIRED 1949 status REQUIRED 1950 -- MUST contain exactly one element of type PKIStatusInfo 1951 status REQUIRED 1952 -- positive value allowed: "accepted" 1953 -- negative value allowed: "rejection" 1954 statusString OPTIONAL 1955 -- MAY be any human-readable text for debugging, logging or to 1956 -- display in a GUI 1957 failInfo OPTIONAL 1958 -- MAY be present if and only if status is "rejection" 1960 protection REQUIRED 1961 -- As described in section 3.2 1963 extraCerts REQUIRED 1965 5.3. Error reporting 1967 This functionality should be used by an EE to report any error 1968 conditions upstream to the (L)RA/CA. Error reporting by the (L)RA 1969 downstream to the EE is described in Section 6.3. 1971 In case the error condition is related to specific details of an ip, 1972 cp, or kup response message and a confirmation is expected the error 1973 condition MUST be reported in the respective certConf message with 1974 negative contents. 1976 General error conditions, e.g., problems with the message header, 1977 protection, or extraCerts, and negative feedback on rp, pollRep, or 1978 pkiConf messages MAY be reported in the form of an error message. 1980 In both situations the error is reported in the PKIStatusInfo 1981 structure of the respective message. 1983 The (L)RA/CA MUST respond to an error message with a pkiConf message, 1984 or with another error message if any part of the header is not valid. 1985 Both sides MUST treat this message as the end of the current 1986 transaction. 1988 The PKIStatusInfo structure is used to report errors. The 1989 PKIStatusInfo structure SHOULD consist of the following fields: 1991 o status: Here the PKIStatus value rejection is the only one 1992 allowed. 1994 o statusString: Here any human-readable valid value for logging or 1995 to display in a GUI SHOULD be added. 1997 o failInfo: Here the PKIFailureInfo values MAY be used in the 1998 following way. For explanation of the reason behind a specific 1999 value, please refer to [RFC4210] Appendix F. 2001 * transactionIdInUse: This is sent in case the received request 2002 contains a transaction ID that is already in use for another 2003 transaction. An EE receiving such error message SHOULD resend 2004 the request in a new transaction using a different transaction 2005 ID. 2007 * systemUnavail or systemFailure: This is sent in case a back-end 2008 system is not available or currently not functioning correctly. 2009 An EE receiving such error message SHOULD resend the request in 2010 a new transaction after some time. 2012 Detailed error message description: 2014 Error Message -- error 2016 Field Value 2018 header 2019 -- As described in section 3.1 2021 body 2022 -- The message sent by the EE or the (L)RA/CA to indicate an 2023 -- error that occurred 2024 error REQUIRED 2025 pKIStatusInfo REQUIRED 2026 status REQUIRED 2027 -- MUST have the value "rejection" 2028 statusString RECOMMENDED 2029 -- SHOULD be any human-readable text for debugging, logging 2030 -- or to display in a GUI 2031 failInfo OPTIONAL 2032 -- MAY be present 2034 protection REQUIRED 2035 -- As described in section 3.2 2037 extraCerts OPTIONAL 2038 -- As described in section 3.3 2040 5.4. Support messages 2042 The following support messages offer on demand in-band transport of 2043 content that may be provided by the (L)RA/CA and relevant to the EE. 2044 The general messages and general response are used for this purpose. 2045 Depending on the environment, these requests are answered by the LRA, 2046 RA, or CA. 2048 The general message and general response transport InfoTypeAndValue 2049 structures. In addition to those infoType values defined in CMP 2050 [RFC4210] further OIDs MAY be defined to define new PKI management 2051 operations, or general-purpose messages as needed in a specific 2052 environment. 2054 Possible content described here address: 2056 o Request of CA certificates 2058 o Update of Root CA certificates 2059 o Parameters needed for a planned certificate request message 2061 o Voucher request and enrollment voucher exchange 2063 5.4.1. General message and response 2065 The general message transaction is similar to that given in CMP 2066 Appendix E.5 [RFC4210]. In this section the general message (genm) 2067 and general response (genp) are described. The specific 2068 InfoTypeAndValue structures are described in the following sections. 2070 The behavior in case an error occurs is described in Section 5.3. 2072 Message flow: 2074 Step# EE (L)RA/CA 2075 1 format genm 2076 2 -> genm -> 2077 3 handle, re-protect or 2078 forward genm 2079 4 format or receive genp 2080 5 <- genp <- 2081 6 handle genp 2083 Detailed message description: 2085 General Message -- genm 2087 Field Value 2089 header 2090 -- As described in section 3.1 2092 body 2093 -- The request of the EE to receive information 2094 genm REQUIRED 2095 -- MUST contain exactly one element of type 2096 -- InfoTypeAndValue 2097 infoType REQUIRED 2098 -- MUST be the OID identifying the specific scheme 2099 -- described below 2100 infoValue OPTIONAL 2101 -- MUST be as described in the specific scheme described 2102 -- below 2104 protection REQUIRED 2105 -- As described in section 3.2 2107 extraCerts REQUIRED 2108 -- As described in section 3.3 2110 General Response -- genp 2112 Field Value 2114 header 2115 -- As described in section 3.1 2117 body 2118 -- The response of the (L)RA/CA to the information request 2119 genp REQUIRED 2120 -- MUST contain exactly one element of type 2121 -- InfoTypeAndValue 2122 infoType REQUIRED 2123 -- MUST be the OID identifying the specific scheme 2124 -- described below 2125 infoValue OPTIONAL 2126 -- MUST be as described in the specific scheme described 2127 -- below 2129 protection REQUIRED 2130 -- As described in section 3.2 2132 extraCerts REQUIRED 2133 -- As described in section 3.3 2135 5.4.2. Get CA certiificates 2137 This scheme can be used by an EE to request CA certificates from the 2138 (L)RA/CA. 2140 An EE requests CA certificates from the (L)RA/CA by sending a general 2141 message with OID id-it-getCaCerts. The (L)RA/CA responds with a 2142 general response with the same OID that either contains a SEQUENCE of 2143 certificates populated with the available CA intermediate and issuing 2144 CA certificates or with no content in case no CA certificate is 2145 available. 2147 < NOTE: The OID id-it-getCaCerts is not yet defined. It should be 2148 registered in the tree 1.3.6.1.5.5.7.4 (id-it) like other infoType 2149 OIDs, see CMP Appendix F [RFC4210] on page 92. > 2151 The profile for this exchange is as given in Section 5.4.1, with the 2152 following specific content: 2154 1 the body MUST contain as infoType the OID id-it-getCaCerts 2156 2 the infoValue of the request MUST be absent 2158 3 if present, the infoValue of the response MUST be caCerts field 2160 The infoValue field of the general response containing the id-it- 2161 getCaCerts OID looks like this: 2163 infoValue OPTIONAL 2164 -- MUST be absent if no CA certificate is available 2165 -- MUST be present if CA certificates are available 2166 caCerts REQUIRED 2167 -- MUST be present if infoValue is present 2168 -- MUST be a sequence of CMPCertificate 2170 5.4.3. Get root CA certificate update 2172 This scheme can be used by an EE to request an update of an existing 2173 root CA Certificate by the EE. It utilizes the root CA key update 2174 announcement message as described in CMP Appendix E.4 [RFC4210] as 2175 response to a respective general message. 2177 An EE requests a root CA certificate update from the (L)RA/CA by 2178 sending a general message with OID id-it-caKeyUpdateInfo. The (L)RA/ 2179 CA responds with a general response with the same OID that either 2180 contains the update of the root CA certificate consisting of three 2181 certificates, or with no content in case no update is available. 2182 These three certificates are described in more detail in section 2183 4.4.1, section 6.2, and Appendix E.3 of [RFC4210]. 2185 The profile for this exchange is as given in Section 5.4.1, with the 2186 following specific content: 2188 1 the body MUST contain as infoType the OID id-it-caKeyUpdateInfo 2190 2 the infoValue of the request MUST be absent 2192 3 if present, the infoValue of the response MUST be a 2193 CAKeyUpdAnnContent structure 2195 The infoValue field of the general response containing the id-it- 2196 caKeyUpdateInfo extension looks like this: 2198 infoValue OPTIONAL 2199 -- MUST be absent if no update of the root CA certificate is 2200 available 2201 -- MUST be present if an update of the root CA certificate 2202 -- is available 2203 caKeyUpdateInfo REQUIRED 2204 -- MUST be present and be of type CAKeyUpdAnnContent 2205 oldWithNew REQUIRED 2206 -- MUST be present if infoValue is present 2207 -- MUST contain an X.509 certificate containing the old public 2208 -- root CA key signed with the new private root CA key 2209 newWithOld REQUIRED 2210 -- MUST be present if infoValue is present 2211 -- MUST contain an X.509 certificate containing the new public 2212 -- root CA key signed with the old private root CA key 2213 newWithNew REQUIRED 2214 -- MUST be present if infoValue is present 2215 -- MUST contain the new root CA certificate 2217 5.4.4. Get certificate request parameters 2219 This scheme can be used by an EE to request configuration parameters 2220 for a planned certificate request transaction. 2222 An EE requests certificate request parameters from the (L)RA/CA by 2223 sending a general message with OID id-it-getCSRParam. The (L)RA/CA 2224 responds with a general response with the same OID that either 2225 contains the required fields, e.g., algorithm identifier for key pair 2226 generation or other attributes and extensions or with no content in 2227 case no specific requirements are made by the (L)RA/CA. 2229 < NOTE: The OID id-it-getCSRParam is not yet defined. It should be 2230 registered in the tree 1.3.6.1.5.5.7.4 (id-it) like other infoType 2231 OIDs, see CMP Appendix F [RFC4210] on page 92. > 2233 The EE SHOULD follow the requirements from the recieved CertTemplate 2234 and the optional RSA key length. In case a field is present but the 2235 value is absent, it means that this field is required but its content 2236 has to be provided by the EE. 2238 The profile for this exchange is as given in Section 5.4.1, with the 2239 following specific content: 2241 1 the body MUST contain as infoType the OID id-it-getCSRParam 2242 2 the infoValue of the request MUST be absent 2244 3 if present, the infoValue of the response MUST be a SEQUENCE of a 2245 certTemplate structure and an rsaKeyLen field of type INTEGER 2247 The infoValue field of the general response containing the id-it- 2248 getCSRParam OID looks like this: 2250 infoValue OPTIONAL 2251 -- MUST be absent if no requirements are available 2252 -- MUST be present if the (L)RA/CA has any requirements on the 2253 -- content of the certificates to be requested. 2254 certTemplate REQUIRED 2255 -- MUST be present if infoValue is present 2256 -- MUST contain the prefilled certTemplate structure 2257 rsaKeyLen OPTIONAL 2258 -- This field is of type INTEGER. Any reasonable RSA key length 2259 -- SHOULD be specified if the algorithm in the 2260 -- subjectPublicKeyInfo field of the certTemplate is of type 2261 -- rsaEncryption. 2263 5.4.5. Get certificate management configuration 2265 This scheme can be used by an EE to request the current certificate 2266 management configuration information by the EE in advance to a 2267 planned certificate management transaction, e.g., in case no out-of- 2268 band transport is available. Such certificate management 2269 configuration can consist of all information the EE needs to know to 2270 generate and deliver a proper certificate request, such as 2272 o algorithm, curve, and key length for key generation 2274 o various certificate extensions to be used for the certificate 2275 request 2277 o specific host name, port and path on the RA/LRA to send this CMP 2278 request to 2280 o Infrastructure Root CA Certificate, e.g., the root of the (L)RA 2281 TLS and CMP signer certificates. 2283 There is an overlap with Section 5.4.2 with regard to transport of CA 2284 certificates and with Section 5.4.4 with regard to key generation 2285 parameter and certificate request attributes and extensions. This 2286 profile offers to request a proprietary configuration file containing 2287 all information needed in one exchange. 2289 An EE requests certificate management configuration from the (L)RA/CA 2290 by sending a general message with the OID id-it-getCertMgtConfig. 2291 The (L)RA/CA responds with a general response with the same OID that 2292 either contains a certMgtConfig field containing the configuration 2293 file encoded as OCTET STRING or with no content in case no 2294 certificate management configuration is available. 2296 < NOTE: The OID id-it-getCertMgtConfig is not yet defined. It should 2297 be registered in the tree 1.3.6.1.5.5.7.4 (id-it) like other infoType 2298 OIDs, see CMP Appendix F [RFC4210] on page 92. > 2300 The EE SHOULD use the contents of this certMgtConfig to format and 2301 deliver the certificate request. The certificate management 2302 configuration may contain contact details, e.g., like an URI and 2303 issuing CA distinguished name, where to address the request messages 2304 to and may also contain certificate request parameters as described 2305 in Section 5.4.4. 2307 The certMgtConfig field may be of any format suitable for the EE, 2308 e.g., CMS [RFC5652], JWT [RFC7519] or, XML [W3C_XML]. The 2309 certMgtConfig contents MAY be signed, e.g., like CMS SignedData 2310 [RFC5652], JWS [RFC7515] or, XML-DSig [W3C_XML-Dsig]. For 2311 interoperability the format of the certMgtConfig field should be 2312 specified in detail if needed. 2314 The profile for this exchange is as given in Section 5.4.1, with the 2315 following specific content: 2317 1 the body MUST contain as infoType the OID id-it-getCertMgtConfig 2319 2 the infoValue of the request MUST be absent 2321 3 if present, the infoValue of the response MUST be a certMgtConfig 2322 structure 2324 The infoValue field of the general response containing the id-it- 2325 getCertMgtConfig extension looks like this: 2327 infoValue OPTIONAL 2328 -- MUST be absent if no certificate management configuration 2329 -- is available 2330 -- MUST be present if the (L)RA/CA provides any certificate 2331 -- management configuration 2332 certMgtConfig REQUIRED 2333 -- MUST be present if infoValue is present 2334 -- MUST contain the certificate management configuration as OCTET 2335 -- OCTET STRING 2337 5.4.6. Get enrollment voucher 2339 This scheme can be used by an EE to request an enrollment voucher 2340 containing the root certificate of a new, additional, or alternative 2341 PKI to establish trust in this PKI, e.g., in case no out-of-band 2342 transport is available. Such an enrollment voucher can be used in 2343 advance to an enrollment to this new environment. It may contain 2344 further information depending on the use case. 2346 An EE requests an enrollment voucher from the (L)RA/CA by sending a 2347 general message. The (L)RA/CA responds with a general response with 2348 the same OID that either contains the voucher or with no content in 2349 case no voucher is available. 2351 The (L)RA MAY use the content of the voucherRequest to get an 2352 enrollment voucher from other backend components, e.g., as described 2353 in BRSKI [I-D.ietf-anima-bootstrapping-keyinfra]. The EE SHOULD use 2354 the contents of the received enrollmentVoucher to authenticate the 2355 (L)RA/CA it is about to enroll to. The enrollment voucher may for 2356 example contain the Root CA certificate of the new PKI or the CMP 2357 signer certificate of the (L)RA. The general response message MUST 2358 be properly authenticated and the sender of this message MUST be 2359 authorized to install new root certificates. One example for an 2360 enrollment voucher is specified in RFC8366 [RFC8366]. 2362 The voucherRequest and enrollmentVoucher fields may be of any format 2363 suitable for the EE, e.g., CMS [RFC5652], JWT [RFC7519] or, XML 2364 [W3C_XML]. The voucherRequest and enrollmentVoucher contents MAY 2365 contain a signature, e.g., CMS SignedData [RFC5652], JWS [RFC7515] 2366 or, XML-DSig [W3C_XML-Dsig]. For interoperability the format of the 2367 voucherRequest and enrollmentVoucher field schould be specified in 2368 detail if needed, e.g., as defined in BRSKI 2369 [I-D.ietf-anima-bootstrapping-keyinfra] and RFC8366 [RFC8366]. 2371 < TBD: The vontent of the voucherRequest and enrollmentVoucher fields 2372 can also be linited to the specufucations in BRSKI 2373 [I-D.ietf-anima-bootstrapping-keyinfra] and RFC8366 [RFC8366]. > 2375 The profile for this exchange is as given in Section 5.4.1, with the 2376 following specific content: 2378 1 the body MUST contain as infoType the OID id-it- 2379 getEnrollmentVoucher 2381 2 if present, the infoValue of the request MUST be a voucherRequest 2382 structure 2384 3 if present, the infoValue of the response MUST be an 2385 enrollmentVoucher structure 2387 The infoValue field of the general message containing the id-it- 2388 getEnrollmentVoucher extension looks like this: 2390 infoValue OPTIONAL 2391 -- MUST be absent if no voucher request is available 2392 -- MUST be present if the EE provides the voucher request 2393 voucherRequest REQUIRED 2394 -- MUST be present if infoValue is present 2395 -- MUST contain the voucher request as OCTET STRING 2397 The infoValue field of the general response containing the id-it- 2398 getEnrollmentVoucher extension looks like this: 2400 infoValue OPTIONAL 2401 -- MUST be absent if no enrollment voucher is available 2402 -- MUST be present if the (L)RA/CA provides the enrollment 2403 -- voucher 2404 enrollmentVoucher REQUIRED 2405 -- MUST be present if infoValue is present 2406 -- MUST contain the enrollment voucher as OCTET STRING 2408 6. LRA and RA focused certificate management use cases 2410 This chapter focuses on the communication of PKI backend components 2411 with each other. Depending on the network and PKI solution design, 2412 these will either be an LRA, RA or CA. 2414 Typically, an (L)RA forwards messages from downstream, but it may 2415 also reply to them itself. Besides forwarding of received messages 2416 an (L)RA could also need to revoke certificates of EEs, report 2417 errors, or may need to manage its own certificates. 2419 < In CMP Updates [I-D.brockhaus-lamps-cmp-updates] additional 2420 extended key usages like id-kp-cmpRA will be defined to indicate that 2421 a key pair is entitled to be used for signature-based protection of a 2422 CMP message by an (L)RA/CA. > 2424 6.1. Forwarding of messages 2426 Each CMP request message (i.e., ir, cr, p10cr, kur, pollReq, or 2427 certConf) or error message coming from an EE or the previous 2428 (downstream) PKI component MUST be sent to the next (upstream) PKI 2429 component. This PKI component MUST forward response messages to the 2430 next (downstream) PKI component or EE. 2432 The (L)RA SHOULD verify the protection, the syntax, the required 2433 message fields, the message type, and if applicable the authorization 2434 and the proof-of-possession of the message. Additional checks or 2435 actions MAY be applied depending on the PKI solution requirements and 2436 concept. If one of these verification procedures fails, the (L)RA 2437 SHOULD respond with a negative response message and SHOULD not 2438 forward the message further upstream. General error conditions 2439 should be handled as described in Section 5.3 and Section 6.3. 2441 An (L)RA SHOULD not change the received message if not necessary. 2442 The (L)RA SHOULD only update the message protection if it is 2443 technically necessary. Concrete PKI system specifications may define 2444 in more detail if and when to do so. 2446 This is particularly relevant in the upstream communication of a 2447 request message. 2449 Each hop in a chain of PKI components has one or more 2450 functionalities, e.g., 2452 o An (L)RA may need to verify the identities of EEs or base 2453 authorization decisions for certification request processing on 2454 specific knowledge of the local setup, e.g., by consulting an 2455 inventory or asset management system. 2457 o An (L)RA may need to add fields to certificate request messages. 2459 o An (L)RA may need to store data from a message in a database for 2460 later usage or documentation purposes. 2462 o An (L)RA may provide traversal of a network boundary. 2464 o An (L)RA may need to double-check if the messages transferred back 2465 and forth are properly protected and well formed. 2467 o An RA can collect messages from different LRAs and forward them to 2468 the CA. 2470 o An (L)RA may provide a proof that it has performed all required 2471 checks. 2473 o An (L)RA may initiate a delayed enrollment due to offline upstream 2474 communication or registration officer interaction. 2476 o An (L)RA may grant the request of an EE to omit sending a 2477 confirmation message. 2479 Therefore, the decision if a message should be forwarded 2480 o unchanged with the original protection, 2482 o unchanged with a new protection, or 2484 o changed with a new protection 2486 depends on the PKI solution design and the associated security policy 2487 (CP/CPS [RFC3647]). 2489 This section specifies the different options an (L)RA may implement 2490 and use. 2492 An (L)RA MAY update the protection of a message 2494 o if the (L)RA performs changes to the header or the body of the 2495 message, 2497 o if the (L)RA needs to prove checks or validations performed on the 2498 message to one of the next (upstream) PKI components, 2500 o if the (L)RA needs to protect the message using a key and 2501 certificate from a different PKI, or 2503 o if the (L)RA needs to replace a MAC based-protection. 2505 This is particularly relevant in the upstream communication of 2506 certificate request messages. 2508 The message protection covers only the header and the body and not 2509 the extraCerts. The (L)RA MAY change the extraCerts in any of the 2510 following message adaptations, e.g., to sort or add needed or to 2511 delete needless certificates to support the next hop. This may be 2512 particularly helpful to extend upstream messages with additional 2513 certificates or to reduce the number of certificates in downstream 2514 messages when forwarding to constrained devices. 2516 6.1.1. Not changing protection 2518 This message adaptation can be used by any (L)RA to forward an 2519 original CMP message without changing the header, body or protection. 2520 In any of these cases the (L)RA acts more like a proxy, e.g., on a 2521 network boundary, implementing no specific RA-like security 2522 functionality to the PKI. 2524 This message adaptation MUST be used for forwarding kur messages that 2525 must not be approved by the respective (L)RA. 2527 6.1.2. Replacing protection 2529 The following two message adaptations can be used by any (L)RA to 2530 forward a CMP message with or without changes, but providing its own 2531 protection using its CMP signer key providing approval of this 2532 message. In this case the (L)RA acts as an actual Registration 2533 Authority (RA), which implements important security functionality of 2534 the PKI. 2536 Before replacing the existing protection by a new protection, the 2537 (L)RA MUST verify the protection provided by the EE or by the 2538 previous PKI component and approve its content including any own 2539 modifications. For certificate requests the (L)RA MUST verify in 2540 particular the included proof-of-possession self-signature of the 2541 certTemplate using the public key of the requested certificate and 2542 MUST check that the EE, as authenticated by the message protection, 2543 is authorized to request a certificate with the subject as specified 2544 in the certTemplate. 2546 In case the received message has been protected by a CA or another 2547 (L)RA, the current (L)RA MUST verify its protection and approve its 2548 content including any own modifications. For certificate requests 2549 the (L)RA MUST check that the other (L)RA, as authenticated by the 2550 message protection, is authorized to issue or forward the request. 2552 These message adaptations MUST NOT be applied to kur request messages 2553 as described in Section 5.1.3 since their original protection using 2554 the key and certificate to be updated needs to be preserved, unless 2555 the regCtrl OldCertId is used to clearly identify the certificate to 2556 be updated. 2558 6.1.2.1. Keeping proof-of-possession 2560 This message adaptation can be used by any (L)RA to forward a CMP 2561 message with or without modifying the message header or body while 2562 preserving any included proof-of-possession. 2564 By replacing the existing using its own CMP signer key the (L)RA 2565 provides a proof of verifying and approving of the message as 2566 described above. 2568 In case the (L)RA modifies the certTemplate of an ir or cr message, 2569 the message adaptation in Section 6.1.2.2 needs to be applied 2570 instead. 2572 6.1.2.2. Breaking proof-of-possession 2574 This message adaptation can be used by any (L)RA to forward an ir or 2575 cr message with modifications of the certTemplate i.e., modification, 2576 addition, or removal of fields. Such changes will break the proof- 2577 of-possession provided by the EE in the original message. 2579 By replacing the existing or applying an initial protection using its 2580 own CMP signer key the (L)RA provides a proof of verifying and 2581 approving the new message as described above. 2583 In addition to the above the (L)RA MUST verify in particular the 2584 proof-of-possession contained in the original message as described 2585 above. If these checks were successfully performed the (L)RA MUST 2586 change the popo to raVerified. 2588 The popo field MUST contain the raVerified choice in the certReq 2589 structure of the modified message as follows: 2591 popo 2592 raVerified REQUIRED 2593 -- MUST have the value NULL and indicates that the (L)RA 2594 -- verified the popo of the original message. 2596 6.1.3. Initiating delayed enrollment 2598 This message adaptation can be used by an (L)RA to initiate delayed 2599 enrollment. In this case a (L)RA/CA MUST add the status waiting in 2600 the response message. The (L)RA/CA MUST then reply to the pollReq 2601 messages as described in Section 5.1.7. 2603 6.2. Revoking certificates on behalf of another's entities 2605 This message sequence can be used by an (L)RA to revoke a certificate 2606 of any other entity. This revocation request message MUST be signed 2607 by the (L)RA using its own CMP signer key to prove to the PKI 2608 authorization to revoke the certificate on behalf of the EE. 2610 The general message flow for this profile is the same as given in 2611 section Section 5.2. 2613 Preconditions: 2615 1 the certificate to be revoked MUST be known to the (L)RA 2617 2 the (L)RA MUST have the authorization to revoke the certificates 2618 of other entities issued by the corresponding CA 2620 The profile for this exchange is identical to that given in section 2621 Section 5.2, with the following changes: 2623 1 it is not required that the certificate to be revoked is not yet 2624 expired or revoked 2626 2 the (L)RA acts as EE for this message exchange 2628 3 the rr messages MUST be signed using the CMP signer key of the 2629 (L)RA. 2631 6.3. Error reporting 2633 This functionality should be used by the (L)RA to report any error 2634 conditions downstream to the EE. Potential error reporting by the EE 2635 upstream to the (L)RA/CA is described in Section 5.3. 2637 In case the error condition is related to specific details of an ir, 2638 cr, p10cr, or kur request message it MUST be reported in the specific 2639 response message, i.e., an ip, cp, or kup with negative contents. 2641 General error conditions, e.g., problems with the message header, 2642 protection, or extraCerts, and negative feedback on rr, pollReq, 2643 certConf, or error messages MUST be reported in the form of an error 2644 message. 2646 In both situations the (L)RA reports the errors in the PKIStatusInfo 2647 structure of the respective message as described in Section 5.3. 2649 An EE receiving any such negative feedback SHOULD log the error 2650 appropriately and MUST terminate the current transaction. 2652 7. CMP message transport variants 2654 The CMP messages are designed to be self-contained, such that in 2655 principle any transport can be used. HTTP SHOULD be used for online 2656 transport while file-based transport MAY be used in case offline 2657 transport is required. In case HTTP transport is not desired or 2658 possible, CMP messages MAY also be piggybacked on any other reliable 2659 transport protocol, e.g., CoAP [RFC7252]. 2661 Independently of the means of transport it could happen that messages 2662 are lost, or a communication partner does not respond. In order to 2663 prevent waiting indefinitely, each CMP client component SHOULD use a 2664 configurable per-request timeout, and each CMP server component 2665 SHOULD use a configurable per-response timeout in case a further 2666 message is to be expected from the client side. In this way a 2667 hanging transaction can be closed cleanly with an error and related 2668 resources (for instance, any cached extraCerts) can be freed. 2670 7.1. HTTP transport 2672 This transport mechanism can be used by an EE and (L)RA/CA to 2673 transfer CMP messages over HTTP. If HTTP transport is used the 2674 specifications as described in [RFC6712] MUST be followed. 2676 7.2. HTTPS transport using certificates 2678 This transport mechanism can be used by an EE and (L)RA/CA to further 2679 protect the HTTP transport as described in Section 7.1 using TLS 1.2 2680 [RFC5246] or TLS 1.3 [RFC8446] as described in [RFC2818] with 2681 certificate-based authentication. Using this transport mechanism, 2682 the CMP transport via HTTPS MUST use TLS server authentication and 2683 SHOULD use TLS client authentication. 2685 EE: 2687 o The EE SHOULD use a TLS client certificate as far as available. 2688 If no dedicated TLS certificate is available the EE SHOULD use an 2689 already existing certificate identifying the EE (e.g., a 2690 manufacturer certificate). 2692 o If no TLS certificate is available at the EE, server-only 2693 authenticated TLS SHOULD be used. 2695 o The EE MUST validate the TLS server certificate of its 2696 communication partner. 2698 (L)RA: 2700 o Each (L)RA SHOULD use a TLS client certificate on its upstream 2701 (client) interface. 2703 o Each (L)RA SHOULD use a TLS server certificate on its downstream 2704 (server) interface. 2706 o Each (L)RA MUST validate the TLS certificate of its communication 2707 partner. 2709 NOTE: The requirements for checking certificates given in [RFC5280], 2710 [RFC5246] and [RFC8446] MUST be followed for the TLS layer. OCSP or 2711 CRLs SHOULD be used for status checking of the TLS certificates of 2712 communication partners. 2714 7.3. HTTPS transport using shared secrets 2716 This transport mechanism can be used by an EE and (L)RA/CA to further 2717 protect the HTTP transport as described in Section 7.1 using TLS 1.2 2718 [RFC5246] or TLS 1.3 [RFC8446] as described in [RFC2818] with mutual 2719 authentication based on shared secrets as described in [RFC5054]. 2721 EE: 2723 o The EE MUST use the shared symmetric key for authentication. 2725 (L)RA: 2727 o The (L)RA MUST use the shared symmetric key for authentication. 2729 7.4. File-based transport 2731 For offline transfer file-based transport MAY be used. Offline 2732 transport is typically used between LRA and RA nodes. 2734 Connection and error handling mechanisms like those specified for 2735 HTTP in [RFC6712] need to be implemented. 2737 < Details need to be defined later > 2739 7.5. CoAP transport 2741 In constrained environments where no HTTP transport is desired or 2742 possible, CoAP [RFC7252] MAY be used instead. Connection and error 2743 handling mechanisms like those specified for HTTP in [RFC6712] may 2744 need to be implemented. 2746 Such specification is out of scope of this document and would need to 2747 be specifies in a separate document. 2749 7.6. Piggybacking on other reliable transport 2751 For online transfer where no HTTP transport is desired or possible 2752 CMP messages MAY also be transported on some other reliable protocol. 2753 Connection and error handling mechanisms like those specified for 2754 HTTP in [RFC6712] need to be implemented. 2756 Such specification is out of scope of this document and would need to 2757 be specifies in a separate document, e.g., in the scope of the 2758 respective transport protocol used. 2760 8. IANA Considerations 2762 2764 9. Security Considerations 2766 2768 10. Acknowledgements 2770 We would like to thank the various reviewers of this CMP profile. 2772 11. References 2774 11.1. Normative References 2776 [I-D.brockhaus-lamps-cmp-updates] 2777 Brockhaus, H., "CMP Updates", draft-brockhaus-lamps-cmp- 2778 updates-00 (work in progress), July 2019. 2780 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 2781 Requirement Levels", BCP 14, RFC 2119, 2782 DOI 10.17487/RFC2119, March 1997, 2783 . 2785 [RFC2986] Nystrom, M. and B. Kaliski, "PKCS #10: Certification 2786 Request Syntax Specification Version 1.7", RFC 2986, 2787 DOI 10.17487/RFC2986, November 2000, 2788 . 2790 [RFC4086] Eastlake 3rd, D., Schiller, J., and S. Crocker, 2791 "Randomness Requirements for Security", BCP 106, RFC 4086, 2792 DOI 10.17487/RFC4086, June 2005, 2793 . 2795 [RFC4210] Adams, C., Farrell, S., Kause, T., and T. Mononen, 2796 "Internet X.509 Public Key Infrastructure Certificate 2797 Management Protocol (CMP)", RFC 4210, 2798 DOI 10.17487/RFC4210, September 2005, 2799 . 2801 [RFC4211] Schaad, J., "Internet X.509 Public Key Infrastructure 2802 Certificate Request Message Format (CRMF)", RFC 4211, 2803 DOI 10.17487/RFC4211, September 2005, 2804 . 2806 [RFC5280] Cooper, D., Santesson, S., Farrell, S., Boeyen, S., 2807 Housley, R., and W. Polk, "Internet X.509 Public Key 2808 Infrastructure Certificate and Certificate Revocation List 2809 (CRL) Profile", RFC 5280, DOI 10.17487/RFC5280, May 2008, 2810 . 2812 [RFC5652] Housley, R., "Cryptographic Message Syntax (CMS)", STD 70, 2813 RFC 5652, DOI 10.17487/RFC5652, September 2009, 2814 . 2816 [RFC6712] Kause, T. and M. Peylo, "Internet X.509 Public Key 2817 Infrastructure -- HTTP Transfer for the Certificate 2818 Management Protocol (CMP)", RFC 6712, 2819 DOI 10.17487/RFC6712, September 2012, 2820 . 2822 11.2. Informative References 2824 [ETSI-3GPP] 2825 3GPP, "TS33.310; Network Domain Security (NDS); 2826 Authentication Framework (AF); Release 16; V16.1.0", 2827 December 2018, 2828 . 2830 [I-D.ietf-anima-bootstrapping-keyinfra] 2831 Pritikin, M., Richardson, M., Eckert, T., Behringer, M., 2832 and K. Watsen, "Bootstrapping Remote Secure Key 2833 Infrastructures (BRSKI)", draft-ietf-anima-bootstrapping- 2834 keyinfra-29 (work in progress), October 2019. 2836 [IEC62443-3-3] 2837 IEC, "Industrial communication networks - Network and 2838 system security - Part 3-3: System security requirements 2839 and security levels", IEC 62443-3-3, August 2013, 2840 . 2842 [IEEE802.1AR] 2843 IEEE, "802.1AR Secure Device Identifier", June 2018, 2844 . 2847 [NIST-CSFW] 2848 NIST, "Framework for Improving Critical Infrastructure 2849 Cybersecurity Version 1.1", April 2018, 2850 . 2853 [RFC2818] Rescorla, E., "HTTP Over TLS", RFC 2818, 2854 DOI 10.17487/RFC2818, May 2000, 2855 . 2857 [RFC3647] Chokhani, S., Ford, W., Sabett, R., Merrill, C., and S. 2858 Wu, "Internet X.509 Public Key Infrastructure Certificate 2859 Policy and Certification Practices Framework", RFC 3647, 2860 DOI 10.17487/RFC3647, November 2003, 2861 . 2863 [RFC5054] Taylor, D., Wu, T., Mavrogiannopoulos, N., and T. Perrin, 2864 "Using the Secure Remote Password (SRP) Protocol for TLS 2865 Authentication", RFC 5054, DOI 10.17487/RFC5054, November 2866 2007, . 2868 [RFC5246] Dierks, T. and E. Rescorla, "The Transport Layer Security 2869 (TLS) Protocol Version 1.2", RFC 5246, 2870 DOI 10.17487/RFC5246, August 2008, 2871 . 2873 [RFC7252] Shelby, Z., Hartke, K., and C. Bormann, "The Constrained 2874 Application Protocol (CoAP)", RFC 7252, 2875 DOI 10.17487/RFC7252, June 2014, 2876 . 2878 [RFC7515] Jones, M., Bradley, J., and N. Sakimura, "JSON Web 2879 Signature (JWS)", RFC 7515, DOI 10.17487/RFC7515, May 2880 2015, . 2882 [RFC7519] Jones, M., Bradley, J., and N. Sakimura, "JSON Web Token 2883 (JWT)", RFC 7519, DOI 10.17487/RFC7519, May 2015, 2884 . 2886 [RFC8366] Watsen, K., Richardson, M., Pritikin, M., and T. Eckert, 2887 "A Voucher Artifact for Bootstrapping Protocols", 2888 RFC 8366, DOI 10.17487/RFC8366, May 2018, 2889 . 2891 [RFC8446] Rescorla, E., "The Transport Layer Security (TLS) Protocol 2892 Version 1.3", RFC 8446, DOI 10.17487/RFC8446, August 2018, 2893 . 2895 [UNISIG] UNISIG, "Subset-137; ERTMS/ETCS On-line Key Management 2896 FFFIS; V1.0.0", December 2015, 2897 . 2899 [W3C_XML] W3C, "Extensible Markup Language (XML) 1.0", W3C XML, 2900 November 2008, . 2902 [W3C_XML-Dsig] 2903 W3C, "XML Signature Syntax and Processing Version 2.0", 2904 W3C XML-DSIG, July 2015, 2905 . 2907 Appendix A. Additional Stuff 2909 This becomes an Appendix. 2911 Authors' Addresses 2913 Hendrik Brockhaus 2914 Siemens AG 2915 Otto-Hahn-Rin 6 2916 Munich 81739 2917 Germany 2919 Email: hendrik.brockhaus@siemens.com 2920 URI: http://www.siemens.com/ 2922 Steffen Fries 2923 Siemens AG 2924 Otto-Hahn-Ring 6 2925 Munich 81739 2926 Germany 2928 Email: steffen.fries@siemens.com 2929 URI: http://www.siemens.com/ 2931 David von Oheimb 2932 Siemens AG 2933 Otto-Hahn-Ring 6 2934 Munich 81739 2935 Germany 2937 Email: david.von.oheimb@siemens.com 2938 URI: http://www.siemens.com/