idnits 2.17.1 draft-brockhaus-lamps-lightweight-cmp-profile-00.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 : ---------------------------------------------------------------------------- -- The draft header indicates that this document updates RFC4210, but the abstract doesn't seem to mention this, which it should. 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 SHOULD ignore it. == 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: This functional extension can be applied in combination with certificate enrollment as described in Section 5.1.1 to Section 5.1.4. The functional extension can be used in case a (L)RA/ CA cannot respond to the certificate request in a timely manner, e.g. due to offline upstream communication or registration officer interaction. Depending on the PKI architecture, it is not necessarily the PKI component directly communicating with the EE that initiates the delayed enrollment. In this case this PKI component MUST include the status waiting in the response and this response MUST not contain a newly issued certificate. When receiving a response with status waiting the EE MUST send a poll request to the (L)RA/CA. The (L)RA/CA 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. (Using the creation date from RFC4210, updated by this document, for RFC5378 checks: 2000-03-07) -- The document seems to lack a disclaimer for pre-RFC5378 work, but may have content which was first submitted before 10 November 2008. If you have contacted all the original authors and they are all willing to grant the BCP78 rights to the IETF Trust, then this is fine, and you can ignore this comment. If not, you may need to add the pre-RFC5378 disclaimer. (See the Legal Provisions document at https://trustee.ietf.org/license-info for more information.) -- The document date (July 7, 2019) is 1749 days in the past. Is this intentional? Checking references for intended status: Proposed Standard ---------------------------------------------------------------------------- (See RFCs 3967 and 4897 for information about using normative references to lower-maturity documents in RFCs) == Missing Reference: 'RFC 5280' is mentioned on line 1344, but not defined == Unused Reference: 'RFC6402' is defined on line 1966, but no explicit reference was found in the text -- 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: 0 errors (**), 0 flaws (~~), 8 warnings (==), 5 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 Updates: 4210 (if approved) D. von Oheimb 5 Intended status: Standards Track Siemens 6 Expires: January 8, 2020 July 7, 2019 8 Lightweight CMP Profile 9 draft-brockhaus-lamps-lightweight-cmp-profile-00 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 constrained devices only the most crucial types of 20 transactions are specified as mandatory. To foster interoperability 21 also in more complex scenarios, other types of transactions are 22 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 January 8, 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 . . . . . . . . . . . . . . 4 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 . . . . . . . . 6 64 2.5. Scope of this document . . . . . . . . . . . . . . . . . 7 65 2.6. Structure of this document . . . . . . . . . . . . . . . 8 66 2.7. Convention and Terminology . . . . . . . . . . . . . . . 8 67 3. Architecture and use cases . . . . . . . . . . . . . . . . . 9 68 3.1. Solution architecture . . . . . . . . . . . . . . . . . . 9 69 3.2. Basic generic CMP message content . . . . . . . . . . . . 10 70 3.3. Supported use cases . . . . . . . . . . . . . . . . . . . 10 71 3.3.1. Mandatory use cases . . . . . . . . . . . . . . . . . 11 72 3.3.2. Recommended Use Cases . . . . . . . . . . . . . . . . 11 73 3.3.3. Optional use cases . . . . . . . . . . . . . . . . . 12 74 3.4. CMP message transport . . . . . . . . . . . . . . . . . . 12 75 4. Generic parts of the PKI message . . . . . . . . . . . . . . 13 76 4.1. General description of the CMP message header . . . . . . 13 77 4.2. General description of the CMP message protection . . . . 15 78 4.3. General description of CMP message extraCerts . . . . . . 15 79 5. End Entity focused certificate management use cases . . . . . 16 80 5.1. Requesting a new certificate from a PKI . . . . . . . . . 16 81 5.1.1. A certificate from a new PKI with signature 82 protection . . . . . . . . . . . . . . . . . . . . . 18 83 5.1.2. Update an existing certificate with signature 84 protection . . . . . . . . . . . . . . . . . . . . . 23 85 5.1.3. A certificate from a PKI with MAC protection . . . . 24 86 5.1.4. A certificate from a legacy PKI using PKCS#10 request 26 87 5.1.5. Generate the key pair centrally at the (L)RA/CA . . . 26 88 5.1.6. Delayed enrollment . . . . . . . . . . . . . . . . . 27 89 5.1.7. Omitted confirmation . . . . . . . . . . . . . . . . 28 90 5.2. Revoking a certificate . . . . . . . . . . . . . . . . . 28 91 5.3. Error reporting . . . . . . . . . . . . . . . . . . . . . 30 92 5.4. Support messages . . . . . . . . . . . . . . . . . . . . 32 93 5.4.1. Root CA certificate update . . . . . . . . . . . . . 32 94 5.4.2. Get enrollment voucher . . . . . . . . . . . . . . . 32 95 6. LRA and RA focused certificate management use cases . . . . . 33 96 6.1. Forwarding of messages . . . . . . . . . . . . . . . . . 33 97 6.1.1. Not changing protection . . . . . . . . . . . . . . . 35 98 6.1.2. Replacing protection . . . . . . . . . . . . . . . . 35 99 6.1.2.1. Keeping proof-of-possession . . . . . . . . . . . 36 100 6.1.2.2. Breaking proof-of-possession . . . . . . . . . . 36 101 6.1.3. Initiating delayed enrollment . . . . . . . . . . . . 37 102 6.1.4. Granting omitted confirmation . . . . . . . . . . . . 37 103 6.2. Revoking certificates on behalf of another's entities . . 37 104 6.3. Error reporting . . . . . . . . . . . . . . . . . . . . . 38 105 7. CMP message transport variants . . . . . . . . . . . . . . . 38 106 7.1. HTTP transport . . . . . . . . . . . . . . . . . . . . . 38 107 7.2. HTTPS transport using certificates . . . . . . . . . . . 39 108 7.3. HTTPS transport using shared secrets . . . . . . . . . . 39 109 7.4. File-based transport . . . . . . . . . . . . . . . . . . 40 110 7.5. CoAP transport . . . . . . . . . . . . . . . . . . . . . 40 111 7.6. Piggybacking on other reliable transport . . . . . . . . 40 112 8. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 40 113 9. Security Considerations . . . . . . . . . . . . . . . . . . . 40 114 10. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 40 115 11. References . . . . . . . . . . . . . . . . . . . . . . . . . 41 116 11.1. Normative References . . . . . . . . . . . . . . . . . . 41 117 11.2. Informative References . . . . . . . . . . . . . . . . . 41 118 Appendix A. Additional Stuff . . . . . . . . . . . . . . . . . . 43 119 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 43 121 1. History of changes 123 From version 00 -> 01: 125 o Change focus from industrial to more multi-purpose use cases and 126 lightweight CMP profile. 128 o Incorporate the omitted confirmation into the header specified in 129 section Section 4.1 and described in the standard enrollment use 130 case in section Section 5.1.1 due to discussion with Tomas 131 Gustavsson. 133 o Change from OPTIONAL to RECOMMENDED for use case 'Revoke another's 134 entities certificate' in section Section 6.2 and , because it is 135 regarded as important functionality in many environments to enable 136 the management station to revoke EE certificates. 138 o Complete the specification of the revocation message flow in 139 section Section 5.2 and Section 6.2. 141 o The CoAP based transport mechanism and piggybacking of CMP 142 messages on top of other reliable transport protocols is out of 143 scope of this document and would need to be specified in another 144 document. 146 o Further minor changes in wording. 148 2. Introduction 150 This document specifies certificate management transactions 151 implementing machine-to-machine and IoT use cases. The focus lies on 152 maximum automation and interoperable implementation of all involved 153 components from end entities (EE) through an optional Local 154 Registration Authority (LRA) and the RA up to the CA. The profile 155 makes use of the concepts and syntax specified in CMP [RFC4210], CRMF 156 [RFC4211], and HTTP transfer for CMP [RFC6712]. Especially CMP and 157 CRMF are very feature-rich standards, while only a limited subset of 158 the specified functionality is needed in many environments. 159 Additionally, the standards are not always precise enough on how to 160 interpret and implement the described concepts. Therefore, we aim at 161 tailoring and specifying in more detail how to use these concepts to 162 implement lightweight automated certificate management. 164 2.1. Motivation for profiling CMP 166 CMP was standardized in 1999 and is implemented in several CA 167 products. In 2005 a completely reworked and enhanced version 2 of 168 CMP [RFC4210] and CRMF [RFC4211] has been published followed by a 169 document specifying a transfer mechanism using http [RFC6712] in 170 2012. 172 Though CMP is a very solid and capable protocol it could be used more 173 widely. The most important reason for not more intense application 174 of CMP appears to be that the protocol is offering a large set of 175 features and options but being not always precise enough and leaving 176 room for interpretation. On the one hand, this makes CMP applicable 177 to a very wide range of scenarios, but on the other hand a full 178 implementation of all options is unrealistic because this would take 179 enormous effort. 181 Moreover, many details of the CMP protocol have been left open or 182 have not been specified in full preciseness. The profiles specified 183 in Appendix D and E of [RFC4210] offer some more detailed certificate 184 use cases. But the specific needs of highly automated scenarios for 185 a machine-to-machine communication are not covered sufficiently. 187 As also 3GPP, and UNISG already put across, profiling is a way of 188 coping with the challenges mentioned above. To profile means to take 189 advantage of the strengths of the given protocol, while explicitly 190 narrowing down the options it provides to exactly those needed for 191 the purpose(s) at hand and eliminating all identified ambiguities. 192 In this way all the general and applicable aspects of the protocol 193 can be taken over and only the peculiarities of the target scenario 194 need to be dealt with specifically. 196 Doing such a profiling for a new target environment can be a high 197 effort because the range of available options needs to be well 198 understood and the selected options need to be consistent with each 199 other and with the intended usage scenario. Since most industrial 200 use cases typically have much in common it is worth sharing this 201 effort, which is the aim of this document. Other standardization 202 bodies can then reference the profile from this document and do not 203 need to come up with individual profiles. 205 2.2. Motivation for a lightweight profile for CMP 207 The profiles specified in Appendix D and E of CMP have been developed 208 in particular to manage certificates of human end entities. With the 209 evolution of distributed systems and client-server architectures, 210 certificates for machines and applications on them have become widely 211 used. This trend has strengthened even more in emerging industrial 212 and IoT scenarios. CMP is sufficiently flexible to support these 213 very well. 215 Today's IT security architectures for industrial solutions typically 216 use certificates for endpoint authentication within protocols like 217 IPSec, TLS or SSH. Therefore, the security of these architectures 218 highly relies upon the security and availability of the implemented 219 certificate management procedures. 221 Due to increasing security in operational networks as well as 222 availability requirements, especially on critical infrastructures and 223 systems with a high volume of certificates, a state-of-the-art 224 certificate management must be constantly available and cost- 225 efficient, which calls for high automation and reliability. Such PKI 226 operation according to commonly accepted best practices is also 227 required in IEC 62443-3-3 [IEC62443-3-3] for security level 2 up to 228 security level 4. 230 Further challenges in many industrial systems are network 231 segmentation and asynchronous communication, where PKI operation is 232 often not deployed on-site but in a more protected environment of a 233 data center or trust center. Certificate management must be able to 234 cope with such network architectures. CMP offers the required 235 flexibility and functionality, namely self-contained messages, 236 efficient polling, and support for asynchronous message transfer with 237 end-to-end security. 239 2.3. Existing CMP profiles 241 As already stated, CMP contains profiles with mandatory and optional 242 transactions in the Appendixes D and E of [RFC4210]. Those profiles 243 focus on management of human user certificates and do not address the 244 specific needs for certificate management automation for unattended 245 machine or application-oriented end entities. 247 3GPP makes use of CMP [RFC4210] in its Technical Specification 133 248 310 [ETSI-3GPP] for automatic management of IPSec certificates in 249 UMTS, LTE, and 5G backbone networks. Since 2010 a dedicated CMP 250 profile for initial certificate enrollment and update transactions 251 between end entities and the RA/CA is specified in the document. 253 UNISIG has included a CMP profile for certificate enrollment in the 254 subset 137 specifying the ETRAM/ECTS on-line key management for train 255 control systems [UNISIG] in 2015. 257 Both standardization bodies use CMP [RFC4210], CRMF [RFC4211], and 258 HTTP transfer for CMP [RFC6712] to add tailored means for automated 259 certificate management for unattended machine or application-oriented 260 end entities. 262 2.4. Compatibility with existing CMP profiles 264 The profile specified in this document is compatible with CMP 265 [RFC4210] Appendixes D and E (PKI Management Message Profiles), with 266 the following exceptions: 268 o signature-based protection is the default protection; initial 269 transactions may also use HMAC, 271 o certification of a second key pair within the same transaction is 272 not supported, 274 o proof-of-possession (POPO) with self-signature of the certTemplate 275 according to [RFC4211] section 4.1 clause 3 is the only supported 276 POPO method, 278 o confirmation of newly enrolled certificates may be omitted, and 280 o all transactions consist of request-response message pairs 281 originating at the EE, i.e., announcement messages are omitted. 283 The profile specified in this document is compatible with the CMP 284 profile for UMTS, LTE, and 5G network domain security and 285 authentication framework [ETSI-3GPP], except that: 287 o protection of initial transactions may be HMAC-based, 289 o the subject name is mandatory in certificate templates, and 291 o confirmation of newly enrolled certificates may be omitted. 293 The profile specified in this document is compatible with the CMP 294 profile for on-line key management in rail networks as specified in 295 UNISIG subset-137 [UNISIG], except that: 297 o as of RFC 4210 [RFC4210] the messageTime is required to be 298 Greenwich Mean Time coded as generalizedTime (Note: While UNISIG 299 explicetely states that the messageTime in required to be 'UTC 300 time', it is not clear if this means a coding as UTCTime or 301 generalizedTime and if other time zones than Greenwich Mean Time 302 shall be allowed. Therfore UNISG may be in conflict with RFC 4210 303 [RFC4210]. Both time formates are described in RFC 5280 [RFC5280] 304 section 4.1.2.5.), and 306 o in case the request message is MAC protected, also the response, 307 certConf, and PKIconf messages have a MAC-based protection (Note: 308 if changing to signature protection of the response the caPubs 309 field cannot be used securely anymore.). 311 2.5. Scope of this document 313 This document specifies requirements on generating messages on the 314 sender side. It does not specify strictness of verification on the 315 receiving side and how in detail to handle error cases. 317 Especially on the EE side this profile aims at a lightweight protocol 318 that can be implemented on constrained devices. On the side of the 319 central PKI components the profile accepts higher resource needs. 321 For the sake of robustness and preservation of security properties 322 implementations should, as far as security is not affected, adhere to 323 Postel's law: "Be conservative in what you do, be liberal in what you 324 accept from others" (often reworded as: "Be conservative in what you 325 send, be liberal in what you accept"). 327 When in chapter 3, 4, and 5 a field of the ASN.1 syntax as defined in 328 RFC 4210 [RFC4210] and RFC 4211 [RFC4211] is not explicitly 329 specified, it SHOULD not be used by the sending entity. The 330 receiving entity MUST NOT require its absence and if present SHOULD 331 ignore it. 333 2.6. Structure of this document 335 Chapter 2 introduces the general PKI architecture and approach to 336 certificate management using CMP that is assumed in this document. 337 Then it enlists the certificate management use cases specified in 338 this document and describes them in general words. The list of 339 supported certificate management use cases is divided into mandatory, 340 recommended, and optional ones. 342 Chapter 3 profiles the CMP message header, protection, and extraCerts 343 section as they are general elements of CMP messages. 345 Chapter 4 profiles the exchange of CMP messages between an EE and the 346 first PKI component. There are various flavors of certificate 347 enrollment requests optionally with polling, revocation, error 348 handling, and general support transactions. 350 Chapter 5 profiles the exchange between further PKI components. 351 These are in the first place the forwarding of messages coming from 352 or going to an EE. This includes also initiating delayed delivery of 353 messages, which involves polling. Additionally, it specifies 354 transactions where the PKI component manages certificates on behalf 355 of an EE or for itself. 357 Chapter 6 outlines different mechanisms for CMP message transfer, 358 namely http-based transfer as already specified in [RFC6712], using 359 an additional TLS layer, offline file-based transport, CoAP 360 [RFC7252], or piggybacking CMP messages on other protocols. 362 2.7. Convention and Terminology 364 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 365 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 366 document are to be interpreted as described in RFC 2119 [RFC2119]. 368 In this document, these words will appear with that interpretation 369 only when in ALL CAPS. Lower case uses of these words are not to be 370 interpreted as carrying significance described in RFC 2119. 372 Technical terminology is used in conformance with RFC 4210 [RFC4210], 373 RFC 4211 [RFC4211], RFC 5280 [RFC5280], and IEEE 802.1AR 374 [IEEE802.1AR]. The following key words are used: 376 CA: Certification authority, which issues certificates. 378 RA: Registration authority, an optional system component to which 379 a CA delegates certificate management functions such as 380 authorization checks. 382 LRA: Local registration authority, an optional RA system component 383 with proximity to end entities. 385 EE: End entity, a user or device or service that holds a PKI 386 certificate. An identifier for the EE is given as the 387 subject of the certificate. 389 3. Architecture and use cases 391 3.1. Solution architecture 393 Typically, a machine EE will be equipped with a manufacturer issued 394 certificate during production. Such a manufacturer issued 395 certificate is installed during production to identify the device 396 throughout its lifetime. This manufacturer certificate can be used 397 to protect the initial enrollment of operational certificates after 398 installation of the EE in a plant or industrial network. An 399 operational certificate is issued by the owner or operator of the 400 device to identify the device during operation, e.g., within a 401 security protocol like IPSec, TLS, or SSH. In IEEE 802.1AR 402 [IEEE802.1AR] a manufacturer certificate is called IDevID certificate 403 and an operational certificate is called LDevID certificate. 405 All certificate management transactions are initiated by the EE. The 406 EE creates a CMP request message, protects it using its manufacturer 407 or operational certificate, if available, and sends it to its locally 408 reachable PKI component. This PKI component may be an LRA, RA, or 409 the CA, which checks the request, responds to it itself, or forwards 410 the request upstream to the next PKI component. In case an (L)RA 411 changes the CMP request message header or body or wants to prove a 412 successful verification or authorization, it can apply a protection 413 of its own. Especially the communication between an LRA and RA can 414 be performed synchronously or asynchronously. Synchronous 415 communication describes a timely uninterrupted communication between 416 two communication partners, as asynchronous communication is not 417 performed in a timely consistent manner, e.g., because of a delayed 418 message delivery. 420 +-----+ +-----+ +-----+ +-----+ 421 | | | | | | | | 422 | EE |<---------->| LRA |<-------------->| RA |<---------->| CA | 423 | | | | | | | | 424 +-----+ +-----+ +-----+ +-----+ 426 synchronous (a)synchronous synchronous 427 +----connection----+------connection------+----connection----+ 429 on site at operators service partner 430 +----------plant---------+-----backend services-----+-trust center-+ 432 Figure 1: Certificate management on site 434 In operation environments a layered LRA-RA-CA architecture can be 435 deployed, e.g., with LRAs bundling requests from multiple EEs at 436 dedicated locations and one (or more than one) central RA aggregating 437 the requests from multiple LRAs. Every (L)RA in this scenario will 438 have its own dedicated certificate and private key allowing it to 439 protect CMP messages it processes (CMP signing key/certificate). The 440 figure above shows an architecture using one LRA and one RA. It is 441 also possible to have only an RA or multiple LRAs and/or RAs. 442 Depending on the network infrastructure, the communication between 443 different PKI components may be synchronous online-communication, 444 delayed asynchronous communication, or even offline file transfer. 446 Third-party CAs typically implement different variants of CMP or even 447 use proprietary interfaces for certificate management. Therefore, 448 the LRA or the RA may need to adapt the exchanged CMP messages to the 449 flavor of communication required by the CA. 451 3.2. Basic generic CMP message content 453 Section 4 specifies the generic parts of the CMP messages as used 454 later in Section 5 and Section 6. 456 o Header of a CMP message; see Section 4.1. 458 o Protection of a CMP message; see Section 4.2. 460 o ExtraCerts field of a CMP message; see Section 4.3. 462 3.3. Supported use cases 464 Following the outlined scope from Section 2.5, this section gives a 465 brief overview of the certificate management use cases specified in 466 Section 5 and Section 6 and points out, if a implementation by 467 compliant EE or PKI component is mandatory, recommended or optional. 469 3.3.1. Mandatory use cases 471 The mandatory uses case in this document shall limit the overhead of 472 certificate management for constrained devices to the most crucial 473 types of transactions. 475 Section 5 - End Entity focused certificate management use cases 477 o Request a certificate from a new PKI with signature protection; 478 see Section 5.1.1. 480 o Request to update an existing certificate with signature 481 protection; see Section 5.1.2. 483 o Error reporting; see Section 5.3. 485 Section 6 - LRA and RA focused certificate management use cases 487 o Forward messages without changes; see Section 6.1.1. 489 o Forward messages with replaced protection and raVerified as proof- 490 of-possession; see Section 6.1.2.2. 492 o Error reporting; see Section 6.3. 494 3.3.2. Recommended Use Cases 496 Additional recommended use cases shall support some more complex 497 scenarios, that are considered as beneficial for environments with 498 more specific boundary conditions. 500 Section 5 - End Entity focused certificate management use cases 502 o Request a certificate from a PKI with MAC protection; see 503 Section 5.1.3. 505 o Handle delayed enrollment due to asynchronous message delivery. 507 < Motivation see Section 5.1.6, specification TBD > 509 o Revoke an own certificate. 511 Section 6 - LRA and RA focused certificate management use cases 513 o Revoke another's entities certificate. 515 3.3.3. Optional use cases 517 The optional use cases support specific requirements seen only in a 518 subset of environments. 520 Section 5 - End Entity focused certificate management use cases 522 o Request a certificate from a legacy PKI using a PKCS#10 [RFC2986] 523 request. 525 < Motivation see Section 5.1.4, specification TBD > 527 o Add central generation of a key pair to a certificate request. 529 < Motivation see Section 5.1.5, specification TBD > 531 o Additional support messages, e.g., to update a Root CA certificate 532 or to request an RFC 8366 [RFC8366] voucher. 534 < Motivation see Section 5.4, specification TBD > 536 Section 6 - LRA and RA focused certificate management use cases 538 o Initiate delayed enrollment due to asynchronous message delivery. 540 < Motivation see Section 6.1.3, specification TBD > 542 3.4. CMP message transport 544 Recommended transport 546 o Transfer CMP messages using HTTP; see Section 7.1. 548 Optional transport 550 o Transfer CMP messages using HTTPS with certificate-based 551 authentication; see Section 7.2. 553 o Transfer CMP messages using HTTPS with shared-secret based 554 protection; see Section 7.3. 556 o File-based CMP message transport. 558 < Motivation see Section 7.4, specification TBD > 560 4. Generic parts of the PKI message 562 To reduce redundancy in the text and to ease implementation, the 563 contents of the header, protection, and extraCerts fields of the CMP 564 messages used in the transactions specified in Section 5 and 565 Section 6 are standardized to the maximum extent possible. 566 Therefore, the generic parts of a CMP message are described centrally 567 in this section. 569 As described in section 5.1 of [RFC4210], all CMP messages have the 570 following general structure: 572 +--------------------------------------------+ 573 | PKIMessage | 574 | +----------------------------------------+ | 575 | | header | | 576 | +----------------------------------------+ | 577 | +----------------------------------------+ | 578 | | body | | 579 | +----------------------------------------+ | 580 | +----------------------------------------+ | 581 | | protection (OPTIONAL) | | 582 | +----------------------------------------+ | 583 | +----------------------------------------+ | 584 | | extraCerts (OPTIONAL) | | 585 | +----------------------------------------+ | 586 +--------------------------------------------+ 588 Figure 2: CMP message structure 590 The general contents of the message header, protection, and 591 extraCerts fields are specified in the Section 4.1 to Section 4.3. 593 In case a specific CMP message needs different contents in the 594 header, protection, or extraCerts fields, the differences are 595 described in the respective message. 597 The CMP message body contains the message-specific information. It 598 is described in the context of Section 5 and Section 6. 600 The behavior in case an error occurs while handling a CMP message is 601 described in Section 6.3. 603 4.1. General description of the CMP message header 605 This section describes the generic header field of all CMP messages 606 with signature-based protection. The only variations described here 607 are in the fields recipient, transactionID, and recipNonce of the 608 first message of a transaction. 610 In case a message has MAC-based protection the changes are described 611 in the respective section. The variations will affect the fields 612 sender, protectionAlg, and senderKID. 614 For requirements about proper random number generation please refer 615 to [RFC4086]. Any message-specific fields or variations are 616 described in the respective sections of this chapter. 618 header 619 pvno REQUIRED 620 -- MUST be set to 2 to indicate CMP V2 621 sender REQUIRED 622 -- MUST be the subject of the signing certificate used for 623 -- protection of this message 624 recipient REQUIRED 625 -- MUST be the name of the intended recipient 626 -- If this is the first message of a transaction: SHOULD be the 627 -- subject of the issuing CA certificate 628 -- In all other messages: SHOULD be the same name as in the 629 -- sender field of the previous message in this transaction 630 messageTime RECOMMENDED 631 -- MUST be the time at which the message was produced, if 632 -- present 633 protectionAlg REQUIRED 634 -- MUST be the algorithm identifier of the signature algorithm 635 -- used for calculation of the protection bits 636 -- The signature algorithm MUST be consistent with the 637 -- SubjectPublicKeyInfo field of the signer's certificate 638 -- The hash algorithm used SHOULD be SHA-256 639 algorithm REQUIRED 640 -- MUST be the OID of the signature algorithm, like 641 -- sha256WithRSAEncryption or ecdsa-with-SHA256 642 parameters PROHIBITED 643 -- MUST be absent 644 senderKID RECOMMENDED 645 -- MUST be the SubjectKeyIdentifier, if available, of the 646 -- certificate used for protecting this message 647 transactionID REQUIRED 648 -- If this is the first message of a transaction: 649 -- MUST be 128 bits of random data for the start of a 650 -- transaction to reduce the probability of having the 651 -- transactionID already in use at the server 652 -- In all other messages: 653 -- MUST be the value from the previous message in the same 654 -- transaction 656 senderNonce REQUIRED 657 -- MUST be fresh 128 random bits 658 recipNonce RECOMMENDED 659 -- If this is the first message of a transaction: SHOULD be 660 -- absent 661 -- In all other messages: MUST be present and contain the value 662 -- from senderNonce of the previous message in the same 663 -- transaction 664 generalInfo OPTIONAL 665 implicitConfirm OPTIONAL 666 ImplicitConfirmValue REQUIRED 667 -- The field is optional though it only applies to ir/cr/kur/p10cr 668 -- requests and ip/cp/kup responses 669 -- ImplicitConfirmValue of the request message MUST be NULL if 670 -- the EE wants to request not to send a confirmation message 671 -- ImplicitConfirmValue MUST be set to NULL if the (L)RA/CA wants 672 -- to grant not sending a confirmation message 674 4.2. General description of the CMP message protection 676 This section describes the generic protection field of all CMP 677 messages with signature-based protection. 679 protection REQUIRED 680 -- MUST contain the signature calculated using the signature 681 -- algorithm specified in protectionAlg 683 Only for MAC-based protection major differences apply as described in 684 the respective message. 686 The CMP message protection provides, if available, message origin 687 authentication and integrity protection for the CMP message header 688 and body. The CMP message extraCerts is not covered by this 689 protection. 691 NOTE: The requirements for checking certificates given in [RFC5280] 692 MUST be followed for the CMP message protection. OCSP or CRLs SHOULD 693 be used for status checking of the CMP signer certificates of 694 communication partners. 696 4.3. General description of CMP message extraCerts 698 This section describes the generic extraCerts field of all CMP 699 messages with signature-based protection. 701 extraCerts RECOMMENDED 702 -- SHOULD contain the signing certificate together with its 703 -- chain, if needed 704 -- If present, the first certificate in this field MUST 705 -- be the certificate used for signing this message 706 -- Self-signed certificates SHOULD NOT be included in 707 -- extraCerts and MUST NOT be trusted based on the listing in 708 -- extraCerts in any case 710 5. End Entity focused certificate management use cases 712 This chapter focuses on the communication of the EE and the first PKI 713 component it talks to. Depending on the network and PKI solution, 714 this will either be the LRA, the RA or the CA. 716 Profiles of the Certificate Management Protocol (CMP) [RFC4210] 717 handled in this chapter cover the following certificate management 718 use cases: 720 o Requesting a certificate from a PKI with variations like initial 721 requests and updating, central key generation and different 722 protection means 724 o Revocation of a certificate 726 o General messages for further support functions 728 The use cases mainly specify the message body of the CMP messages and 729 utilize the specification of the message header, protection and 730 extraCerts as specified in Section 5. 732 The behavior in case an error occurs is described in Section 5.3. 734 This chapter is aligned to Appendix D and Appendix E of [RFC4210]. 735 The general rules for interpretation stated in Appendix D.1 in 736 [RFC4210] need to be applied here, too. 738 This document does not mandate any specific supported algorithms like 739 Appendix D.2 of [RFC4210], [ETSI-3GPP], and [UNISIG] do. Using the 740 message sequences described here require agreement upon the 741 algorithms to support and thus the algorithm identifiers for the 742 specific target environment. 744 5.1. Requesting a new certificate from a PKI 746 There are different approaches to request a certificate from a PKI. 748 These approaches differ on the one hand in the way the EE can 749 authenticate itself to the PKI it wishes to get a new certificate 750 from and on the other hand in its capabilities to generate a proper 751 new key pair. The authentication means may be as follows: 753 o Using a certificate from a trusted PKI and the corresponding 754 private key, e.g., a manufacturer certificate 756 o Using the certificate to be updated and the corresponding private 757 key 759 o Using a shared secret known to the EE and the PKI 761 Typically, such EE requests a certificate from a CA. When the (L)RA/ 762 CA responds with a message containing a certificate, the EE MUST 763 reply with a confirmation message. The (L)RA/CA then MUST send 764 confirmation back, closing the transaction. 766 The message sequences in this section allow the EE to request 767 certification of a locally generated public-private key pair. (< The 768 functional extension for central key generation is TBD if needed. >) 769 For requirements about proper random number and key generation please 770 refer to [RFC4086]. The EE MUST provide a signature-based proof-of- 771 possession of the private key associated with the public key 772 contained in the certificate request as defined by [RFC4211] section 773 4.1 case 3. To this end it is assumed that the private key can 774 technically be used as signing key. The most commonly used 775 algorithms are RSA and ECDSA, which can technically be used for 776 signature calculation regardless of potentially intended restrictions 777 of the key usage. 779 The requesting EE provides the binding of the proof-of-possession to 780 its identity by signature-based or MAC-based protection of the CMP 781 request message containing that POPO. The (L)RA/CA needs to verify 782 whether this EE is authorized to obtain a certificate with the 783 requested subject and other attributes and extensions. Especially 784 when removing the protection provided by the EE and applying a new 785 protection the (L)RA MUST verify in particular the included proof-of- 786 possession self-signature of the certTemplate using the public key of 787 the requested certificate and MUST check that the EE, as 788 authenticated by the message protection, is authorized to request a 789 certificate with the subject as specified in the certTemplate (see 790 Section 6.1.2). 792 There are several ways to install the Root CA certificate of a new 793 PKI on an EE. The installation can be performed in an out-of-band 794 manner, using a voucher [RFC8366] for enrolment, or by the caPubs 795 field in the certificate response message. In case the installation 796 of the new Root CA certificate is performed using the caPubs field, 797 the certificate response message MUST be properly authenticated, and 798 the sender of this message MUST be authorized to install new Root CA 799 certificates on the EE. This authorization MUST be indicated by the 800 extended key usage in the (L)RA/CA certificate as specified in CMP 801 Updates [brockhaus-lamps-cmp-updates]. 803 5.1.1. A certificate from a new PKI with signature protection 805 This message sequence should be used by an EE to request a 806 certificate of a new PKI using an existing certificate from an 807 external PKI, e.g. a manufacturer certificate, to prove its identity 808 to the new PKI. The EE already has established trust in this new PKI 809 it is about to enroll to, e.g., by configuration means. The 810 initialization request message is signature-protected using the 811 existing certificate. 813 Preconditions: 815 1 The EE MUST have a certificate enrolled by an external PKI in 816 advance to this transaction to authenticate itself to the (L)RA/CA 817 using signature-based protection, e.g., using a manufacturer 818 certificate. 820 2 The EE SHOULD know the subject name of the new CA it requests a 821 certificate from; this name MAY be established using an enrollment 822 voucher or other configuration means. If the EE does not know the 823 name of the CA, the (L)RA/CA MUST know where to route this request 824 to. 826 3 The EE MUST authenticate responses from the (L)RA/CA; trust MAY be 827 established using an enrollment voucher or other configuration 828 means 830 4 The (L)RA/CA MUST trust the external PKI the EE uses to 831 authenticate itself; trust MAY be established using some 832 configuration means 834 This message sequenceis like that given in [RFC4210] Appendix E.7. 836 Message flow: 838 Step# EE (L)RA/CA 839 1 format ir 840 2 -> ir -> 841 3 handle, re-protect or 842 forward ir 843 4 format or receive ip 844 5 possibly grant implicit 845 confirm 846 6 <- ip <- 847 7 handle ip 848 8 In case of status 849 "rejection" in the 850 ip message, no certConf 851 and pkiConf are sent 852 9 format certConf (optional) 853 10 -> certConf -> 854 11 handle, re-protect or 855 forward certConf 856 12 format or receive PKIConf 857 13 <- pkiConf <- 858 14 handle pkiConf (optional) 860 For this message sequence the EE MUST include exactly one single 861 CertReqMsg in the ir. If more certificates are required, further 862 requests MUST be sent using separate CMP Messages. If the EE wants 863 to omit sending a certificate confirmation message after receiving 864 the ip to reduce the number of protocol messages exchanged in a 865 transaction, it MUST request this by setting the implicitControlValue 866 in the ir to NULL. 868 If the CA accepts the request it MUST return the new certificate in 869 the certifiedKeyPair field of the ip message. If the EE requested to 870 omit sending a certConf message after receiving the ip, the (L)RA/CA 871 MAY confirm this by also setting the implicitControlValue in the ip 872 to NULL. 874 If the EE did not request implicit confirmation or the request was 875 not granted by the (L)RA/CA the confirmation as follows MUST be 876 performed. If the EE successfully receives the certificate and 877 accepts it, the EE MUST send a certConf message, which MUST be 878 answered by the (L)RA/CA with a pkiConf message. If the (L)RA/CA 879 does not receive the expected certConf message in time it MUST handle 880 this like a rejection by the EE. 882 If the certificate request was refused by the CA, the (L)RA/CA must 883 return an ip message containing the status code "rejection" and no 884 certifiedKeyPair field. Such an ip message MUST NOT be followed by 885 the certConf and pkiConf messages. 887 Detailed message description: 889 Certification Request -- ir 891 Field Value 893 header 894 -- As described in section 3.1 896 body 897 -- The request of the EE for a new certificate 898 ir REQUIRED 899 -- MUST be exactly one CertReqMsg 900 -- If more certificates are required, further requests MUST be 901 -- packaged in separate PKI Messages 902 certReq REQUIRED 903 certReqId REQUIRED 904 -- MUST be set to 0 905 certTemplate REQUIRED 906 version OPTIONAL 907 -- MUST be 2 if supplied. 908 subject REQUIRED 909 -- MUST contain the suggested subject name of the EE 910 -- certificate 911 publicKey REQUIRED 912 -- MUST include the subject public key algorithm ID and value 913 extensions OPTIONAL 914 -- MAY include end-entity-specific X.509 extensions of the 915 -- requested certificate like subject alternative name, 916 -- key usage, and extended key usage 917 Popo REQUIRED 918 POPOSigningKey REQUIRED 919 poposkInput PROHIBITED 920 -- MUST NOT be used because subject and publicKey are both 921 -- present in the certTemplate 922 algorithmIdentifier REQUIRED 923 -- The signature algorithm MUST be consistent with the 924 -- publicKey field of the certTemplate 925 -- The hash algorithm used SHOULD be SHA-256 926 signature REQUIRED 927 -- MUST be the signature computed over the DER-encoded 928 -- certTemplate 930 protection REQUIRED 931 -- As described in section 3.2 933 extraCerts REQUIRED 934 -- As described in section 3.3 936 Certification Response -- ip 938 Field Value 940 header 941 -- As described in section 3.1 943 body 944 -- The response of the CA to the request as appropriate 945 ip REQUIRED 946 caPubs OPTIONAL 947 -- MAY be used 948 -- If used it MUST contain only the root certificate of the 949 -- certificate contained in certOrEncCert 950 response REQUIRED 951 -- MUST be exactly one CertResponse 952 certReqId REQUIRED 953 -- MUST be set to 0 954 status REQUIRED 955 -- PKIStatusInfo structure MUST be present 956 status REQUIRED 957 -- positive values allowed: "accepted", "grantedWithMods" 958 -- negative values allowed: "rejection" 959 -- In case of rejection no certConf and pkiConf messages will 960 -- be sent 961 statusString OPTIONAL 962 -- MAY be any human-readable text for debugging, logging or to 963 -- display in a GUI 964 failInfo OPTIONAL 965 -- MUST be present if status is "rejection" and in this case 966 -- the transaction MUST be terminated 967 -- MUST be absent if the status is "accepted" or 968 -- "grantedWithMods" 969 certifiedKeyPair OPTIONAL 970 -- MUST be present if status is "accepted" or "grantedWithMods" 971 -- MUST be absent if status is "rejection" 972 certOrEncCert REQUIRED 973 -- MUST be present when certifiedKeyPair is present 974 certificate REQUIRED 975 -- MUST be present when certifiedKeyPair is present 976 -- MUST contain the newly enrolled X.509 certificate 978 protection REQUIRED 979 -- As described in section 3.2 981 extraCerts REQUIRED 982 -- As described in section 3.3 983 -- MUST contain the chain of the issued certificate 984 -- Duplicate certificates MAY be omitted 986 Certificate Confirmation -- certConf 988 Field Value 990 header 991 -- As described in section 3.1 993 body 994 -- The message of the EE sends confirmation to the (L)RA/CA 995 -- to accept or reject the issued certificates 996 certConf REQUIRED 997 -- MUST be exactly one CertStatus 998 CertStatus REQUIRED 999 certHash REQUIRED 1000 -- MUST be the hash of the certificate, using the same hash 1001 -- algorithm as used to create the certificate signature 1002 certReqId REQUIRED 1003 -- MUST be set to 0 1004 status RECOMMENDED 1005 -- PKIStatusInfo structure SHOULD be present 1006 -- Omission indicates acceptance of the indicated certificate 1007 status REQUIRED 1008 -- positive values allowed: "accepted" 1009 -- negative values allowed: "rejection" 1010 statusString OPTIONAL 1011 -- MAY be any human-readable text for debugging or logging 1012 failInfo OPTIONAL 1013 -- MUST be present if status is "rejection" 1014 -- MUST be absent if the status is "accepted" 1016 protection REQUIRED 1017 -- As described in section 3.2 1018 -- MUST use the same certificate as for protection of the ir 1020 extraCerts RECOMMENDED 1021 -- SHOULD contain the protection certificate together with its 1022 -- chain 1023 -- If present, the first certificate in this field MUST be the 1024 -- certificate used for signing this message 1025 -- Self-signed certificates SHOULD NOT be included in 1026 -- extraCerts and 1027 -- MUST NOT be trusted based on the listing in extraCerts in 1028 -- any case 1030 PKI Confirmation -- pkiConf 1032 Field Value 1034 header 1035 -- As described in section 3.1 1037 body 1038 pkiConf REQUIRED 1039 -- The content of this field MUST be NULL 1041 protection REQUIRED 1042 -- As described in section 3.2 1043 -- SHOULD use the same certificate as for protection of the ip 1045 extraCerts RECOMMENDED 1046 -- SHOULD contain the protection certificate together with its 1047 -- chain 1048 -- If present, the first certificate in this field MUST be the 1049 -- certificate used for signing this message 1050 -- Self-signed certificates SHOULD NOT be included in extraCerts 1051 -- and 1052 -- MUST NOT be trusted based on the listing in extraCerts in 1053 -- any case 1055 5.1.2. Update an existing certificate with signature protection 1057 This message sequence should be used by an EE to request an update of 1058 one of the certificates it already has and that is still valid. The 1059 EE uses the certificate it wishes to update to prove its identity and 1060 possession of the private key for the certificate to be updated to 1061 the PKI. Therefore, the key update request message is signed using 1062 the certificate that is to be updated. 1064 The general message flow for this message sequence is the same as 1065 given in Section 5.1.1. 1067 Preconditions: 1069 1 The certificate the EE wishes to update MUST NOT be expired or 1070 revoked. 1072 2 A new public-private key pair SHOULD be used. 1074 The message sequence for this exchange is like that given in 1075 [RFC4210] Appendix D.6. 1077 The message sequence for this exchange is identical to that given in 1078 Section 5.1.1, with the following changes: 1080 1 The body of the first request and response MUST be kur and kup, 1081 respectively. 1083 2 Protection of the kur MUST be performed using the certificate to 1084 be updated. 1086 3 The subject field of the CertTemplate MUST contain the subject 1087 name of the existing certificate to be updated, without 1088 modifications. 1090 4 The CertTemplate MUST contain the subject, issuer and publicKey 1091 fields only. 1093 5 The regCtrl OldCertId SHOULD be used to make clear, even in case 1094 an (L)RA changes the message protection, which certificate is to 1095 be. 1097 6 The caPubs field in the kup message MUST be absent. 1099 As part of the certReq structure of the kur the control is added 1100 right after the certTemplate. 1102 controls 1103 type RECOMMENDED 1104 -- MUST be the value id-regCtrl-oldCertID, if present 1105 value 1106 issuer REQUIRED 1107 serialNumber REQUIRED 1108 -- MUST contain the issuer and serialNumber of the certificate 1109 -- to be updated 1111 5.1.3. A certificate from a PKI with MAC protection 1113 This message sequence should be used by an EE to request a 1114 certificate of a new PKI without having a certificate to prove its 1115 identity to the target PKI, but there is a shared secret established 1116 between the EE and the PKI. Therefore, the initialization request is 1117 MAC-protected using this shared secret. The (L)RA checking the MAC- 1118 protection SHOULD replace this protection according to Section 6.1.2 1119 in case the next hop does not know the shared secret too. 1121 For requirements with regard to proper random number and key 1122 generation please refer to [RFC4086]. 1124 The general message flow for this message sequence is the same as 1125 given in Section 5.1.1. 1127 Preconditions: 1129 1 The EE and the (L)RA/CA MUST share a symmetric key, this MAY be 1130 established by a service technician during initial local 1131 configuration. 1133 2 The EE SHOULD know the subject name of the new CA it requests a 1134 certificate from; this name MAY be established using an enrollment 1135 voucher or other configuration means. If the EE does not know the 1136 name of the CA, the (L)RA/CA MUST know where to route this request 1137 to. 1139 3 The EE MUST authenticate responses from the (L)RA/CA; trust MAY be 1140 established using the shared symmetric key. 1142 The message sequence for this exchange is like that given in 1143 [RFC4210] Appendix D.4. 1145 The message sequence for this exchange is identical to that given in 1146 Section 5.1.1, with the following changes: 1148 1 The protection of all messages MUST be calculated using Message 1149 Authentication Code (MAC); the protectionAlg field MUST be id- 1150 PasswordBasedMac as described in section 5.1.3.1 of [RFC4210]. 1152 2 The sender MUST contain a name representing the originator of the 1153 message. The senderKID MUST contain a reference all participating 1154 entities can use to identify the symmetric key used for the 1155 protection. 1157 3 The extraCerts of the ir, certConf, and PKIConf messages MUST be 1158 absent. 1160 4 The extraCerts of the ip message MUST contain the chain of the 1161 issued certificate and root certificates SHOULD not be included 1162 and MUST NOT be trusted in any case. 1164 Part of the protectionAlg structure, where the algorithm identifier 1165 MUST be id-PasswordBasedMac, is a PBMParameter sequence. The fields 1166 of PBMParameter SHOULD remain constant throughout this certificate 1167 management transaction to reduce the computational overhead. 1169 PBMParameter REQUIRED 1170 salt REQUIRED 1171 -- MUST be the random value to salt the secret key 1172 owf REQUIRED 1173 -- MUST be the algorithm identifier for the one-way function 1174 -- used 1175 -- The one-way function SHA-1 MUST be supported due to 1176 -- [RFC4211] requirements, but SHOULD NOT be used any more 1177 -- SHA-256 SHOULD be used instead 1178 iterationCount REQUIRED, 1179 -- MUST be a limited number of times the OWF is applied 1180 -- To prevent brute force and dictionary attacks a reasonable 1181 -- high number SHOULD be used 1182 mac REQUIRED 1183 -- MUST be the algorithm identifier of the MAC algorithm used 1184 -- The MAC function HMAC-SHA1 MUST be supported due to 1185 -- [RFC4211] requirements, but SHOULD NOT be used any more 1186 -- HMAC-SHA-256 SHOULD be used instead 1188 5.1.4. A certificate from a legacy PKI using PKCS#10 request 1190 This message sequence should be used by an EE to request a 1191 certificate of a legacy PKI only capable to process PKCS#10 [RFC2986] 1192 certification requests. The EE can prove its identity to the target 1193 PKI by using various protection means as described in Section 5.1.1 1194 or Section 5.1.3. 1196 In contrast to the other transactions described in Section 5.1, this 1197 transaction uses PKCS#10 [RFC2986] instead of CRMF [RFC4211] for the 1198 certificate request for compatibility reasons with legacy CA systems 1199 that require a PKCS#10 certificate request and cannot process CMP 1200 [RFC4210] or CRMF [RFC4211] messages. In such case the (L)RA can 1201 extract the PKCS#10 certificate request from the p10cr and provide it 1202 separately to the CA. 1204 < Details need to be defined later > 1206 5.1.5. Generate the key pair centrally at the (L)RA/CA 1208 It is strongly preferable to generate public-private key pairs 1209 locally at the EE. Together with proof-of-possession of the private 1210 key in the certification request, this is to make sure that only the 1211 entity identified in the newly issued certificate has the private 1212 key. 1214 There are some rare cases where an EE is not able or not willing to 1215 locally generate the new key pair. Reasons for this may be the 1216 following: 1218 o Lack of sufficient initial entropy. 1220 Note: Good random numbers are not only needed for key generation, but 1221 also for session keys and nonces in any security protocol. 1222 Therefore, we believe that a decent security architecture should 1223 anyway support good random number generation on the EE side or 1224 provide enough entropy for the RNG seed during manufacturing to 1225 guarantee good initial pseudo-random number generation. 1227 o Due to lack of computational resources, e.g., in case of RSA keys. 1229 Note: As key generation can be performed in advance to the 1230 certificate enrollment communication, it is typical not time 1231 critical. 1233 Note: Besides the initial enrollment right after the very first 1234 bootup of the device, where entropy available on the device may be 1235 insufficient, we do not see any good reason for central key 1236 generation. 1238 As the protection of centrally generated keys in the response message 1239 is being extended from EncryptedValue to EncryptedKey by CMP Updates 1240 [brockhaus-lamps-cmp-updates] also the alternative EnvelopedData can 1241 be used. As EncryptedValue offers only key transport, e.g. using RSA 1242 or symmetic encryption, EnvelopedData offers further key management 1243 techniques, e.g. key agreement, and therefore more crypto agility. 1245 Note that according to RFC 4211 [RFC4211] section 2.1.9 the use of 1246 the EncryptedValue structure has been deprecated in favor of the 1247 EnvelopedData structure. 1249 < Details need to be defined later > 1251 5.1.6. Delayed enrollment 1253 This functional extension can be applied in combination with 1254 certificate enrollment as described in Section 5.1.1 to 1255 Section 5.1.4. The functional extension can be used in case a (L)RA/ 1256 CA cannot respond to the certificate request in a timely manner, e.g. 1257 due to offline upstream communication or registration officer 1258 interaction. Depending on the PKI architecture, it is not 1259 necessarily the PKI component directly communicating with the EE that 1260 initiates the delayed enrollment. In this case this PKI component 1261 MUST include the status waiting in the response and this response 1262 MUST not contain a newly issued certificate. When receiving a 1263 response with status waiting the EE MUST send a poll request to the 1264 (L)RA/CA. The (L)RA/CA MUST answers with a poll response containing 1265 a checkAfter time. This value indicates the minimum number of 1266 seconds that must elapse before the EE sends another poll request. 1267 As soon as the (L)RA/CA can provide the final response message for 1268 the initial request of the EE, it MUST provide this in response to a 1269 poll request. After receiving this response, the EE can continue the 1270 original message sequence as described in the respective section of 1271 this document, e.g. send a certConf message. 1273 < Details need to be defined later > 1275 5.1.7. Omitted confirmation 1277 This section will be removed though the functionality was 1278 incorporated into the header specified in section Section 4.1 and 1279 described in the standard enrollment use case in section 1280 Section 5.1.1 due to discussion with Tomas Gustavsson. 1282 5.2. Revoking a certificate 1284 This message sequence should be used by an entity to request the 1285 revocation of a certificate. Here the revocation request is used by 1286 an EE to revoke one of its own certificates. A (L)RA could also act 1287 as an EE to revoke one of its own certificates. 1289 The revocation request message MUST be signed using the certificate 1290 that is to be revoked to prove the authorization to revoke to the 1291 PKI. The revocation request message is signature-protected using 1292 this certificate. 1294 An EE requests the revocation of an own certificate at the CA that 1295 issued this certificate. The (L)RA/CA responds with a message that 1296 contains the status of the revocation from the CA. 1298 Preconditions: 1300 1 The certificate the EE wishes to revoke is not yet expired or 1301 revoked. 1303 Message flow: 1305 Step# EE (L)RA/CA 1306 1 format rr 1307 2 -> rr -> 1308 3 handle, re-protect or 1309 forward rr 1310 4 receive rp 1311 5 <- rp <- 1312 6 handle rp 1314 For this profile, the EE MUST include exactly one RevDetails 1315 structure in the rr. In case no error occurred the response to the 1316 rr MUST be an rp message. The (L)RA/CA MUST produce a rp containing 1317 a status field with a single set of values. 1319 Detailed message description: 1321 Revocation Request -- rr 1323 Field Value 1325 header 1326 -- As described in section 3.1 1328 body 1329 -- The request of the EE to revoke its certificate 1330 rr REQUIRED 1331 -- MUST contain exactly one element of type RevDetails 1332 -- If more revocations are desired, further requests MUST be 1333 -- packaged in separate PKI Messages 1334 certDetails REQUIRED 1335 -- MUST be present and is of type CertTemplate 1336 serialNumber REQUIRED 1337 -- MUST contain the certificate serialNumber attribute of the X.509 1338 -- certificate to be revoked 1339 issuer REQUIRED 1340 -- MUST contain the issuer attribute of the X.509 certificate to be 1341 -- revoked 1342 crlEntryDetails REQUIRED 1343 -- MUST contain exactly one reasonCode of type CRLReason (see 1344 -- [RFC 5280] section 5.3.1) 1345 -- If the reason for this revocation is not known or shall not be 1346 -- published the reasonCode MUST be 0 = unspecified 1348 protection REQUIRED 1349 -- As described in section 3.2 and the private key related to the 1350 -- certificate to be revoked 1352 extraCerts REQUIRED 1353 -- As described in section 3.3 1355 Revocation Response -- rp 1357 Field Value 1359 header 1360 -- As described in section 3.1 1362 body 1363 -- The responds of the (L)RA/CA to the request as appropriate 1364 rp REQUIRED 1365 status REQUIRED 1366 -- MUST contain exactly one element of type PKIStatusInfo 1367 status REQUIRED 1368 -- positive value allowed: "accepted" 1369 -- negative value allowed: "rejection" 1370 statusString OPTIONAL 1371 -- MAY be any human-readable text for debugging, logging or to 1372 -- display in a GUI 1373 failInfo OPTIONAL 1374 -- MAY be present if and only if status is "rejection" 1376 protection REQUIRED 1377 -- As described in section 3.2 1379 extraCerts REQUIRED 1381 5.3. Error reporting 1383 This functionality should be used by an EE to report any error 1384 conditions upstream to the (L)RA/CA. Error reporting by the (L)RA 1385 downstream to the EE is described in Section 6.3. 1387 In case the error condition is related to specific details of an ip, 1388 cp, or kup response message and a confirmation is expected the error 1389 condition MUST be reported in the respective certConf message with 1390 negative contents. 1392 General error conditions, e.g., problems with the message header, 1393 protection, or extraCerts, and negative feedback on rp, pollRep, or 1394 pkiConf messages MAY be reported in the form of an error message. 1396 In both situations the error is reported in the PKIStatusInfo 1397 structure of the respective message. 1399 The (L)RA/CA MUST respond to an error message with a pkiConf message, 1400 or with another error message if any part of the header is not valid. 1401 Both sides MUST treat this message as the end of the current 1402 transaction. 1404 The PKIStatusInfo structure is used to report errors. The 1405 PKIStatusInfo structure SHOULD consist of the following fields: 1407 o status: Here the PKIStatus value rejection is the only one 1408 allowed. 1410 o statusString: Here any human-readable valid value for logging or 1411 to display in a GUI SHOULD be added. 1413 o failInfo: Here the PKIFailureInfo values MAY be used in the 1414 following way. For explanation of the reason behind a specific 1415 value, please refer to [RFC4210] Appendix F. 1417 * transactionIdInUse: This is sent in case the received request 1418 contains a transaction ID that is already in use for another 1419 transaction. An EE receiving such error message SHOULD resend 1420 the request in a new transaction using a different transaction 1421 ID. 1423 * systemUnavail or systemFailure: This is sent in case a back-end 1424 system is not available or currently not functioning correctly. 1425 An EE receiving such error message SHOULD resend the request in 1426 a new transaction after some time. 1428 Detailed error message description: 1430 Error Message -- error 1432 Field Value 1434 header 1435 -- As described in section 3.1 1437 body 1438 -- The message sent by the EE or the (L)RA/CA to indicate an 1439 -- error that occurred 1440 error REQUIRED 1441 pKIStatusInfo REQUIRED 1442 status REQUIRED 1443 -- MUST have the value "rejection" 1444 statusString RECOMMENDED 1445 -- SHOULD be any human-readable text for debugging, logging 1446 -- or to display in a GUI 1447 failInfo OPTIONAL 1448 -- MAY be present 1450 protection REQUIRED 1451 -- As described in section 3.2 1453 extraCerts OPTIONAL 1454 -- As described in section 3.3 1456 5.4. Support messages 1458 The following support messages offer on demand in-band transport of 1459 content that may be relevant to the EE. The general request messages 1460 and general response messages are used for this purpose. 1462 The general message and general response transport InfoTypeAndValue 1463 structures. In addition to those infoType values defined in CMP 1464 [RFC4210] further OIDs MAY be defined to define new certificate 1465 management transactions, or general-purpose messages as needed in a 1466 specific environment. 1468 Possible content described here address: 1470 o Update of Root CA certificates 1472 o Parameters needed for a planned certificate request message 1474 o Request an enrollment voucher 1476 < Details need to be defined later > 1478 5.4.1. Root CA certificate update 1480 This message sequence can be used by an EE to request an update of a 1481 Root CA Certificate by the EE. It utilizes the root CA key update 1482 announcement message as described in [RFC4210] Appendix E.4 as 1483 response to a respective general request message. 1485 An EE requests a root CA certificate update from the (L)RA/CA by 1486 sending a general message with OID id-it-caKeyUpdateInfo. The (L)RA/ 1487 CA responds with a general response with the same OID that either 1488 contains the update of the root CA certificate consisting of three 1489 certificates, or with no content in case no update is available. 1490 These three certificates are described in more detail in section 1491 4.4.1, section 6.2, and Appendix E.3 of [RFC4210]. 1493 < Details need to be defined later > 1495 5.4.2. Get enrollment voucher 1497 This message sequence can be used by an EE to request an enrollment 1498 voucher containing the root certificate of a new PKI to establish 1499 trust in this PKI, e.g., in case no out-of-band transport is 1500 available. Such an enrollment voucher can be used in advance to an 1501 enrollment to this new environment. It may contain further 1502 information depending on the use case. 1504 An EE requests an enrollment voucher from the (L)RA/CA by sending a 1505 general message. The (L)RA/CA responds with a general response with 1506 the same OID that contains the voucher. 1508 < Details need to be defined later > 1510 6. LRA and RA focused certificate management use cases 1512 This chapter focuses on the communication of PKI backend components 1513 with each other. Depending on the network and PKI solution design, 1514 these will either be an LRA, RA or CA. 1516 Typically, an (L)RA forwards messages from downstream, but it may 1517 also reply to them itself. Besides forwarding of received messages 1518 an (L)RA could also need to revoke certificates of EEs, report 1519 errors, or may need to manage its own certificates. 1521 < In CMP Updates [brockhaus-lamps-cmp-updates] additional extended 1522 key usages like id-kp-cmpRA will be defined to indicate that a key 1523 pair is entitled to be used for signature-based protection of a CMP 1524 message by an (L)RA/CA. > 1526 6.1. Forwarding of messages 1528 Each CMP request message (i.e., ir, cr, p10cr, kur, pollReq, or 1529 certConf) or error message coming from an EE or the previous 1530 (downstream) PKI component MUST be sent to the next (upstream) PKI 1531 component. This PKI component MUST forward response messages to the 1532 next (downstream) PKI component or EE. 1534 The (L)RA SHOULD verify the protection, the syntax, the required 1535 message fields, the message type, and if applicable the authorization 1536 and the proof-of-possession of the message. Additional checks or 1537 actions MAY be applied depending on the PKI solution requirements and 1538 concept. If one of these verification procedures fails, the (L)RA 1539 SHOULD respond with a negative response message and SHOULD not 1540 forward the message further upstream. General error conditions 1541 should be handled as described in Section 5.3 and Section 6.3. 1543 An (L)RA SHOULD not change the received message if not necessary. 1544 The (L)RA SHOULD only update the message protection if it is 1545 technically necessary. Concrete PKI system specifications may define 1546 in more detail if and when to do so. 1548 This is particularly relevant in the upstream communication of a 1549 request message. 1551 Each hop in a chain of PKI components has one or more 1552 functionalities, e.g.: 1554 o An (L)RA may need to verify the identities of EEs or base 1555 authorization decisions for certification request processing on 1556 specific knowledge of the local setup, e.g., by consulting an 1557 inventory or asset management system. 1559 o An (L)RA may need to add fields to certificate request messages. 1561 o An (L)RA may need to store data from a message in a database for 1562 later usage or documentation purposes. 1564 o An (L)RA may provide traversal of a network boundary. 1566 o An (L)RA may need to double-check if the messages transferred back 1567 and forth are properly protected and well formed. 1569 o An RA can collect messages from different LRAs and forward them to 1570 the CA. 1572 o An (L)RA may provide a proof that it has performed all required 1573 checks. 1575 o An (L)RA may initiate a delayed enrollment due to offline upstream 1576 communication or registration officer interaction. 1578 o An (L)RA may grant the request of an EE to omit sending a 1579 confirmation message. 1581 Therefore, the decision if a message should be forwarded 1583 o unchanged with the original protection, 1585 o unchanged with a new protection, or 1587 o changed with a new protection 1589 depends on the PKI solution design and the associated security policy 1590 (CP/CPS [RFC3647]). 1592 This section specifies the different options an (L)RA may implement 1593 and use. 1595 An (L)RA MAY update the protection of a message 1597 o if the (L)RA performs changes to the header or the body of the 1598 message, 1600 o if the (L)RA needs to prove checks or validations performed on the 1601 message to one of the next (upstream) PKI components, 1603 o if the (L)RA needs to protect the message using a key and 1604 certificate from a different PKI, or 1606 o if the (L)RA needs to replace a MAC based-protection. 1608 This is particularly relevant in the upstream communication of 1609 certificate request messages. 1611 The message protection covers only the header and the body and not 1612 the extraCerts. The (L)RA MAY change the extraCerts in any of the 1613 following message adaptations, e.g., to sort or add needed or to 1614 delete needless certificates to support the next hop. This may be 1615 particularly helpful to extend upstream messages with additional 1616 certificates or to reduce the number of certificates in downstream 1617 messages when forwarding to constrained devices. 1619 6.1.1. Not changing protection 1621 This message adaptation can be used by any (L)RA to forward an 1622 original CMP message without changing the header, body or protection. 1623 In any of these cases the (L)RA acts more like a proxy, e.g., on a 1624 network boundary, implementing no specific RA-like security 1625 functionality to the PKI. 1627 This message adaptation MUST be used for forwarding kur messages that 1628 must not be approved by the respective (L)RA. 1630 6.1.2. Replacing protection 1632 The following two message adaptations can be used by any (L)RA to 1633 forward a CMP message with or without changes, but providing its own 1634 protection using its CMP signer key providing approval of this 1635 message. In this case the (L)RA acts as an actual Registration 1636 Authority (RA), which implements important security functionality of 1637 the PKI. 1639 Before replacing the existing protection by a new protection, the 1640 (L)RA MUST verify the protection provided by the EE or by the 1641 previous PKI component and approve its content including any own 1642 modifications. For certificate requests the (L)RA MUST verify in 1643 particular the included proof-of-possession self-signature of the 1644 certTemplate using the public key of the requested certificate and 1645 MUST check that the EE, as authenticated by the message protection, 1646 is authorized to request a certificate with the subject as specified 1647 in the certTemplate. 1649 In case the received message has been protected by a CA or another 1650 (L)RA, the current (L)RA MUST verify its protection and approve its 1651 content including any own modifications. For certificate requests 1652 the (L)RA MUST check that the other (L)RA, as authenticated by the 1653 message protection, is authorized to issue or forward the request. 1655 These message adaptations MUST NOT be applied to kur request messages 1656 as described in Section 5.1.2 since their original protection using 1657 the key and certificate to be updated needs to be preserved, unless 1658 the regCtrl OldCertId is used to clearly identify the certificate to 1659 be updated. 1661 6.1.2.1. Keeping proof-of-possession 1663 This message adaptation can be used by any (L)RA to forward a CMP 1664 message with or without modifying the message header or body while 1665 preserving any included proof-of-possession. 1667 By replacing the existing using its own CMP signer key the (L)RA 1668 provides a proof of verifying and approving of the message as 1669 described above. 1671 In case the (L)RA modifies the certTemplate of an ir or cr message, 1672 the message adaptation in Section 6.1.2.2 needs to be applied 1673 instead. 1675 6.1.2.2. Breaking proof-of-possession 1677 This message adaptation can be used by any (L)RA to forward an ir or 1678 cr message with modifications of the certTemplate i.e., modification, 1679 addition, or removal of fields. Such changes will break the proof- 1680 of-possession provided by the EE in the original message. 1682 By replacing the existing or applying an initial protection using its 1683 own CMP signer key the (L)RA provides a proof of verifying and 1684 approving the new message as described above. 1686 In addition to the above the (L)RA MUST verify in particular the 1687 proof-of-possession contained in the original message as described 1688 above. If these checks were successfully performed the (L)RA MUST 1689 change the popo to raVerified. 1691 The popo field MUST contain the raVerified choice in the certReq 1692 structure of the modified message as follows: 1694 popo 1695 raVerified REQUIRED 1696 -- MUST have the value NULL and indicates that the (L)RA 1697 -- verified the popo of the original message. 1699 6.1.3. Initiating delayed enrollment 1701 This message adaptation can be used by an (L)RA to initiate delayed 1702 enrollment. In this case a (L)RA/CA MUST add the status waiting in 1703 the response message. The (L)RA/CA MUST then reply to the pollReq 1704 messages as described in Section 5.1.6. 1706 6.1.4. Granting omitted confirmation 1708 This section will be removed though the functionality was 1709 incorporated into the standard enrollment use case in section 1710 Section 5.1.1 due to discussion with Tomas Gustavsson. 1712 6.2. Revoking certificates on behalf of another's entities 1714 This message sequence can be used by an (L)RA to revoke a certificate 1715 of any other entity. This revocation request message MUST be signed 1716 by the (L)RA using its own CMP signer key to prove to the PKI 1717 authorization to revoke the certificate on behalf of the EE. 1719 The general message flow for this profile is the same as given in 1720 section Section 5.2. 1722 Preconditions: 1724 1 the certificate to be revoked MUST be known to the (L)RA 1726 2 the (L)RA MUST have the authorization to revoke the certificates 1727 of other entities issued by the corresponding CA 1729 The profile for this exchange is identical to that given in section 1730 Section 5.2, with the following changes: 1732 1 it is not required that the certificate to be revoked is not yet 1733 expired or revoked 1735 2 the (L)RA acts as EE for this message exchange 1737 3 the rr messages MUST be signed using the CMP signer key of the 1738 (L)RA. 1740 6.3. Error reporting 1742 This functionality should be used by the (L)RA to report any error 1743 conditions downstream to the EE. Potential error reporting by the EE 1744 upstream to the (L)RA/CA is described in Section 5.3. 1746 In case the error condition is related to specific details of an ir, 1747 cr, p10cr, or kur request message it MUST be reported in the specific 1748 response message, i.e., an ip, cp, or kup with negative contents. 1750 General error conditions, e.g., problems with the message header, 1751 protection, or extraCerts, and negative feedback on rr, pollReq, 1752 certConf, or error messages MUST be reported in the form of an error 1753 message. 1755 In both situations the (L)RA reports the errors in the PKIStatusInfo 1756 structure of the respective message as described in Section 5.3. 1758 An EE receiving any such negative feedback SHOULD log the error 1759 appropriately and MUST terminate the current transaction. 1761 7. CMP message transport variants 1763 The CMP messages are designed to be self-contained, such that in 1764 principle any transport can be used. HTTP SHOULD be used for online 1765 transport while file-based transport MAY be used in case offline 1766 transport is required. In case HTTP transport is not desired or 1767 possible, CMP messages MAY also be piggybacked on any other reliable 1768 transport protocol, e.g., CoAP [RFC7252]. 1770 Independently of the means of transport it could happen that messages 1771 are lost, or a communication partner does not respond. In order to 1772 prevent waiting indefinitely, each CMP client component SHOULD use a 1773 configurable per-request timeout, and each CMP server component 1774 SHOULD use a configurable per-response timeout in case a further 1775 message is to be expected from the client side. In this way a 1776 hanging transaction can be closed cleanly with an error and related 1777 resources (for instance, any cached extraCerts) can be freed. 1779 7.1. HTTP transport 1781 This transport mechanism can be used by an EE and (L)RA/CA to 1782 transfer CMP messages over HTTP. If HTTP transport is used the 1783 specifications as described in [RFC6712] MUST be followed. 1785 7.2. HTTPS transport using certificates 1787 This transport mechanism can be used by an EE and (L)RA/CA to further 1788 protect the HTTP transport as described in Section 7.1 using TLS 1.2 1789 [RFC5246] or TLS 1.3 [RFC8446] as described in [RFC2818] with 1790 certificate-based authentication. Using this transport mechanism, 1791 the CMP transport via HTTPS MUST use TLS server authentication and 1792 SHOULD use TLS client authentication. 1794 EE: 1796 o The EE SHOULD use a TLS client certificate as far as available. 1797 If no dedicated TLS certificate is available the EE SHOULD use an 1798 already existing certificate identifying the EE (e.g., a 1799 manufacturer certificate). 1801 o If no TLS certificate is available at the EE, server-only 1802 authenticated TLS SHOULD be used. 1804 o The EE MUST validate the TLS server certificate of its 1805 communication partner. 1807 (L)RA: 1809 o Each (L)RA SHOULD use a TLS client certificate on its upstream 1810 (client) interface. 1812 o Each (L)RA SHOULD use a TLS server certificate on its downstream 1813 (server) interface. 1815 o Each (L)RA MUST validate the TLS certificate of its communication 1816 partner. 1818 NOTE: The requirements for checking certificates given in [RFC5280], 1819 [RFC5246] and [RFC8446] MUST be followed for the TLS layer. OCSP or 1820 CRLs SHOULD be used for status checking of the TLS certificates of 1821 communication partners. 1823 7.3. HTTPS transport using shared secrets 1825 This transport mechanism can be used by an EE and (L)RA/CA to further 1826 protect the HTTP transport as described in Section 7.1 using TLS 1.2 1827 [RFC5246] or TLS 1.3 [RFC8446] as described in [RFC2818] with mutual 1828 authentication based on shared secrets as described in [RFC5054]. 1830 EE: 1832 o The EE MUST use the shared symmetric key for authentication. 1834 (L)RA: 1836 o The (L)RA MUST use the shared symmetric key for authentication. 1838 7.4. File-based transport 1840 For offline transfer file-based transport MAY be used. Offline 1841 transport is typically used between LRA and RA nodes. 1843 Connection and error handling mechanisms like those specified for 1844 HTTP in [RFC6712] need to be implemented. 1846 < Details need to be defined later > 1848 7.5. CoAP transport 1850 In constrained environments where no HTTP transport is desired or 1851 possible, CoAP [RFC7252] MAY be used instead. Connection and error 1852 handling mechanisms like those specified for HTTP in [RFC6712] may 1853 need to be implemented. 1855 Such specification is out of scope of this document and would need to 1856 be specifies in a separate document. 1858 7.6. Piggybacking on other reliable transport 1860 For online transfer where no HTTP transport is desired or possible 1861 CMP messages MAY also be transported on some other reliable protocol. 1862 Connection and error handling mechanisms like those specified for 1863 HTTP in [RFC6712] need to be implemented. 1865 Such specification is out of scope of this document and would need to 1866 be specifies in a separate document, e.g. in the scope of the 1867 respective transport protocol used. 1869 8. IANA Considerations 1871 1873 9. Security Considerations 1875 1877 10. Acknowledgements 1879 We would like to thank the various reviewers of this CMP profile. 1881 11. References 1883 11.1. Normative References 1885 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 1886 Requirement Levels", BCP 14, RFC 2119, 1887 DOI 10.17487/RFC2119, March 1997, 1888 . 1890 [RFC4086] Eastlake 3rd, D., Schiller, J., and S. Crocker, 1891 "Randomness Requirements for Security", BCP 106, RFC 4086, 1892 DOI 10.17487/RFC4086, June 2005, 1893 . 1895 [RFC4210] Adams, C., Farrell, S., Kause, T., and T. Mononen, 1896 "Internet X.509 Public Key Infrastructure Certificate 1897 Management Protocol (CMP)", RFC 4210, 1898 DOI 10.17487/RFC4210, September 2005, 1899 . 1901 [RFC4211] Schaad, J., "Internet X.509 Public Key Infrastructure 1902 Certificate Request Message Format (CRMF)", RFC 4211, 1903 DOI 10.17487/RFC4211, September 2005, 1904 . 1906 [RFC5280] Cooper, D., Santesson, S., Farrell, S., Boeyen, S., 1907 Housley, R., and W. Polk, "Internet X.509 Public Key 1908 Infrastructure Certificate and Certificate Revocation List 1909 (CRL) Profile", RFC 5280, DOI 10.17487/RFC5280, May 2008, 1910 . 1912 [RFC6712] Kause, T. and M. Peylo, "Internet X.509 Public Key 1913 Infrastructure -- HTTP Transfer for the Certificate 1914 Management Protocol (CMP)", RFC 6712, 1915 DOI 10.17487/RFC6712, September 2012, 1916 . 1918 11.2. Informative References 1920 [brockhaus-lamps-cmp-updates] 1921 Brockhaus, H., "CMP Updates (work in progress)", July 1922 2019, . 1925 [ETSI-3GPP] 1926 3GPP, "3GPP TS33.310; Network Domain Security (NDS); 1927 Authentication Framework (AF); Release 16; V16.1.0", 1928 December 2018, 1929 . 1931 [IEC62443-3-3] 1932 International Electrotechnical Commission, "IEC 62443 Part 1933 3-3 - System security requirements and security levels", 1934 IEC 62443-3-3, August 2013, . 1936 [IEEE802.1AR] 1937 IEEE, "IEEE 802.1AR Secure Device Identifier", 06 2018, 1938 . 1941 [RFC2818] Rescorla, E., "HTTP Over TLS", RFC 2818, 1942 DOI 10.17487/RFC2818, May 2000, 1943 . 1945 [RFC2986] Nystrom, M. and B. Kaliski, "PKCS #10: Certification 1946 Request Syntax Specification Version 1.7", RFC 2986, 1947 DOI 10.17487/RFC2986, November 2000, 1948 . 1950 [RFC3647] Chokhani, S., Ford, W., Sabett, R., Merrill, C., and S. 1951 Wu, "Internet X.509 Public Key Infrastructure Certificate 1952 Policy and Certification Practices Framework", RFC 3647, 1953 DOI 10.17487/RFC3647, November 2003, 1954 . 1956 [RFC5054] Taylor, D., Wu, T., Mavrogiannopoulos, N., and T. Perrin, 1957 "Using the Secure Remote Password (SRP) Protocol for TLS 1958 Authentication", RFC 5054, DOI 10.17487/RFC5054, November 1959 2007, . 1961 [RFC5246] Dierks, T. and E. Rescorla, "The Transport Layer Security 1962 (TLS) Protocol Version 1.2", RFC 5246, 1963 DOI 10.17487/RFC5246, August 2008, 1964 . 1966 [RFC6402] Schaad, J., "Certificate Management over CMS (CMC) 1967 Updates", RFC 6402, DOI 10.17487/RFC6402, November 2011, 1968 . 1970 [RFC7252] Shelby, Z., Hartke, K., and C. Bormann, "The Constrained 1971 Application Protocol (CoAP)", RFC 7252, 1972 DOI 10.17487/RFC7252, June 2014, 1973 . 1975 [RFC8366] Watsen, K., Richardson, M., Pritikin, M., and T. Eckert, 1976 "A Voucher Artifact for Bootstrapping Protocols", 1977 RFC 8366, DOI 10.17487/RFC8366, May 2018, 1978 . 1980 [RFC8446] Rescorla, E., "The Transport Layer Security (TLS) Protocol 1981 Version 1.3", RFC 8446, DOI 10.17487/RFC8446, August 2018, 1982 . 1984 [UNISIG] UNISIG, "UNISIG subset-137; ERTMS/ETCS On-line Key 1985 Management FFFIS; V1.0.0", December 2015, 1986 . 1988 Appendix A. Additional Stuff 1990 This becomes an Appendix. 1992 Authors' Addresses 1994 Hendrik Brockhaus 1995 Siemens AG 1996 Otto-Hahn-Rin 6 1997 Munich 81739 1998 Germany 2000 Email: hendrik.brockhaus@siemens.com 2001 URI: http://www.siemens.com/ 2003 Steffen Fries 2004 Siemens AG 2005 Otto-Hahn-Ring 6 2006 Munich 81739 2007 Germany 2009 Email: steffen.fries@siemens.com 2010 URI: http://www.siemens.com/ 2011 David von Oheimb 2012 Siemens AG 2013 Otto-Hahn-Ring 6 2014 Munich 81739 2015 Germany 2017 Email: david.von.oheimb@siemens.com 2018 URI: http://www.siemens.com/