idnits 2.17.1 draft-brockhaus-lamps-industrial-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 abstract seems to contain references ([RFC4211], [RFC4210]), which it shouldn't. Please replace those with straight textual mentions of the documents in question. -- The draft header indicates that this document updates RFC4210, but the abstract doesn't seem to directly say this. It does mention RFC4210 though, so this could be OK. 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 4.1.1 to Section 4.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 4.3 and Section 5.3. == Using lowercase 'not' together with uppercase 'MUST', 'SHALL', 'SHOULD', or 'RECOMMENDED' is not an accepted usage according to RFC 2119. Please use uppercase 'NOT' together with RFC 2119 keywords (if that is what you mean). Found 'SHOULD not' in this paragraph: 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 (March 11, 2019) is 1873 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) ** Obsolete normative reference: RFC 2818 (Obsoleted by RFC 9110) ** Downref: Normative reference to an Informational RFC: RFC 2986 ** Downref: Normative reference to an Informational RFC: RFC 5054 ** Obsolete normative reference: RFC 5246 (Obsoleted by RFC 8446) Summary: 5 errors (**), 0 flaws (~~), 6 warnings (==), 3 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: September 12, 2019 March 11, 2019 8 Lightweight Industrial CMP Profile 9 draft-brockhaus-lamps-industrial-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 [RFC4210] and the related Certificate Request Message Format (CRMF) 16 [RFC4211]. It specifies a subset of CMP and CRMF focusing on typical 17 uses cases relevant for managing certificates of devices in 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 September 12, 2019. 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. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 3 59 1.1. Motivation for profiling CMP . . . . . . . . . . . . . . 3 60 1.2. Motivation for an industrial profile for CMP . . . . . . 4 61 1.3. Existing CMP profiles . . . . . . . . . . . . . . . . . . 5 62 1.4. Compatibility with existing CMP profiles . . . . . . . . 5 63 1.5. Scope of this document . . . . . . . . . . . . . . . . . 6 64 1.6. Structure of this document . . . . . . . . . . . . . . . 7 65 1.7. Convention and Terminology . . . . . . . . . . . . . . . 7 66 2. Architecture and use cases . . . . . . . . . . . . . . . . . 8 67 2.1. Solution architecture . . . . . . . . . . . . . . . . . . 8 68 2.2. Basic generic CMP message content . . . . . . . . . . . . 9 69 2.3. Supported use cases . . . . . . . . . . . . . . . . . . . 9 70 2.3.1. Mandatory use cases . . . . . . . . . . . . . . . . . 10 71 2.3.2. Recommended Use Cases . . . . . . . . . . . . . . . . 10 72 2.3.3. Optional use cases . . . . . . . . . . . . . . . . . 11 73 2.4. CMP message transport . . . . . . . . . . . . . . . . . . 11 74 3. Generic parts of the PKI message . . . . . . . . . . . . . . 12 75 3.1. General description of the CMP message header . . . . . . 13 76 3.2. General description of the CMP message protection . . . . 15 77 3.3. General description of CMP message extraCerts . . . . . . 15 78 4. End Entity focused certificate management use cases . . . . . 15 79 4.1. Requesting a new certificate from a PKI . . . . . . . . . 16 80 4.1.1. A certificate from a new PKI with signature 81 protection . . . . . . . . . . . . . . . . . . . . . 17 82 4.1.2. Update an existing certificate with signature 83 protection . . . . . . . . . . . . . . . . . . . . . 22 84 4.1.3. A certificate from a PKI with MAC protection . . . . 24 85 4.1.4. A certificate from a legacy PKI using PKCS#10 request 25 86 4.1.5. Generate the key pair centrally at the (L)RA/CA . . . 26 87 4.1.6. Delayed enrollment . . . . . . . . . . . . . . . . . 26 88 4.1.7. Omitted confirmation . . . . . . . . . . . . . . . . 27 89 4.2. Revoking a certificate . . . . . . . . . . . . . . . . . 27 90 4.3. Error reporting . . . . . . . . . . . . . . . . . . . . . 28 91 4.4. Support messages . . . . . . . . . . . . . . . . . . . . 29 92 4.4.1. Root CA certificate update . . . . . . . . . . . . . 30 93 4.4.2. Get enrollment voucher . . . . . . . . . . . . . . . 30 94 5. LRA and RA focused certificate management use cases . . . . . 30 95 5.1. Forwarding of messages . . . . . . . . . . . . . . . . . 31 96 5.1.1. Not changing protection . . . . . . . . . . . . . . . 33 97 5.1.2. Replacing protection . . . . . . . . . . . . . . . . 33 98 5.1.2.1. Keeping proof-of-possession . . . . . . . . . . . 33 99 5.1.2.2. Breaking proof-of-possession . . . . . . . . . . 34 100 5.1.3. Initiating delayed enrollment . . . . . . . . . . . . 34 101 5.1.4. Granting omitted confirmation . . . . . . . . . . . . 34 102 5.2. Revoking certificates of other entities . . . . . . . . . 35 103 5.3. Error reporting . . . . . . . . . . . . . . . . . . . . . 35 104 6. CMP message transport variants . . . . . . . . . . . . . . . 35 105 6.1. HTTP transport . . . . . . . . . . . . . . . . . . . . . 36 106 6.2. HTTPS transport using certificates . . . . . . . . . . . 36 107 6.3. HTTPS transport using shared secrets . . . . . . . . . . 37 108 6.4. File-based transport . . . . . . . . . . . . . . . . . . 37 109 6.5. CoAP transport . . . . . . . . . . . . . . . . . . . . . 37 110 6.6. Piggybacking on other reliable transport . . . . . . . . 37 111 7. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 38 112 8. Security Considerations . . . . . . . . . . . . . . . . . . . 38 113 9. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 38 114 10. References . . . . . . . . . . . . . . . . . . . . . . . . . 38 115 10.1. Normative References . . . . . . . . . . . . . . . . . . 38 116 10.2. Informative References . . . . . . . . . . . . . . . . . 39 117 Appendix A. Additional Stuff . . . . . . . . . . . . . . . . . . 40 118 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 40 120 1. Introduction 122 This document specifies certificate management transactions 123 implementing industrial machine-to-machine and IoT use cases. The 124 focus lies on maximum automation and interoperable implementation of 125 all involved components from end entities (EE) through an optional 126 Local Registration Authority (LRA) and the RA up to the CA. The 127 profile makes use of the concepts and syntax specified in CMP 128 [RFC4210], CRMF [RFC4211], and HTTP transfer for CMP [RFC6712]. 129 Especially CMP and CRMF are very feature-rich standards, while only a 130 limited subset of the specified functionality is needed in the target 131 environment of this document. Additionally, both standards are not 132 always precise enough on how to interpret and implement the described 133 concepts. Therefore, we aim at tailoring and specifying in more 134 detail how to use these concepts to implement automated certificate 135 management in industrial target environments. 137 1.1. Motivation for profiling CMP 139 CMP was standardized in 1999 and is implemented in several CA 140 products. In 2005 a completely reworked and enhanced version 2 of 141 CMP [RFC4210] and CRMF [RFC4211] has been published followed by a 142 document specifying a transfer mechanism using http [RFC6712] in 143 2012. 145 Though CMP is a very solid and capable protocol it could be used more 146 widely. The most important reason for not more intense application 147 of CMP appears to be that the protocol is offering a large set of 148 features and options but being not always precise enough and leaving 149 room for interpretation. On the one hand, this makes CMP applicable 150 to a very wide range of scenarios, but on the other hand a full 151 implementation of all options is unrealistic because this would take 152 enormous effort. 154 Moreover, many details of the CMP protocol have been left open or 155 have not been specified in full preciseness. The profiles specified 156 in Appendix D and E of [RFC4210] offer some more detailed certificate 157 use cases. But the specific needs of highly automated industrial 158 scenarios are not covered sufficiently. 160 As also 3GPP, and UNISG already put across, profiling is a way of 161 coping with the challenges mentioned above. To profile means to take 162 advantage of the strengths of the given protocol, while explicitly 163 narrowing down the options it provides to exactly those needed for 164 the purpose(s) at hand and eliminating all identified ambiguities. 165 In this way all the general and applicable aspects of the protocol 166 can be taken over and only the peculiarities of the target scenario 167 need to be dealt with specifically. 169 Doing such a profiling for a new target environment can be a high 170 effort because the range of available options needs to be well 171 understood and the selected options need to be consistent with each 172 other and with the intended usage scenario. Since industrial use 173 cases typically have much in common it is worth sharing this effort, 174 which is the aim of this document. Other standardization bodies can 175 then reference the profile from this document and do not need to come 176 up with individual profiles. 178 1.2. Motivation for an industrial profile for CMP 180 The profiles specified in Appendix D and E of CMP have been developed 181 in particular to manage certificates of human end entities. With the 182 evolution of distributed systems and client-server architectures, 183 certificates for machines and applications on them have become widely 184 used. This trend has strengthened even more in emerging industrial 185 and IoT scenarios. CMP is sufficiently flexible to support these 186 very well. 188 Today's IT security architectures for industrial solutions typically 189 use certificates for endpoint authentication within protocols like 190 IPSec, TLS or SSH. Therefore, the security of these architectures 191 highly relies upon the security and availability of the implemented 192 certificate management procedures. 194 Due to increasing security in operational networks as well as 195 availability requirements, especially on critical infrastructures and 196 systems with a high volume of certificates, a state-of-the-art 197 certificate management must be constantly available and cost- 198 efficient, which calls for high automation and reliability. Such PKI 199 operation according to commonly accepted best practices is also 200 required in IEC 62443-3-3 [IEC62443-3-3] for security level 2 up to 201 security level 4. 203 Further challenges in industrial systems are network segmentation and 204 asynchronous communication, where PKI operation is often not deployed 205 on-site but in a more protected environment of a data center or trust 206 center. Certificate management must be able to cope with such 207 network architectures. CMP offers the required flexibility and 208 functionality, namely self-contained messages, efficient polling, and 209 support for asynchronous message transfer with end-to-end security. 211 1.3. Existing CMP profiles 213 As already stated, CMP contains profiles with mandatory and optional 214 transactions in the Appendixes D and E of [RFC4210]. Those profiles 215 focus on management of human user certificates and do not address the 216 specific needs of industrial use cases. 218 3GPP makes use of CMP [RFC4210] in its Technical Specification 133 219 310 [ETSI-3GPP] for automatic management of IPSec certificates in 220 UMTS, LTE, and 5G backbone networks. Since 2010 a dedicated CMP 221 profile for initial certificate enrollment and update transactions 222 between end entities and the RA/CA is specified in the document. 224 UNISIG has included a CMP profile for certificate enrollment in the 225 subset 137 specifying the ETRAM/ECTS on-line key management for train 226 control systems [UNISIG] in 2015. 228 Both standardization bodies use CMP [RFC4210], CRMF [RFC4211], and 229 HTTP transfer for CMP [RFC6712] to add tailored means for automated 230 certificate management in an industrial setting. 232 1.4. Compatibility with existing CMP profiles 234 The profile specified in this document is compatible with CMP 235 [RFC4210] Appendixes D and E (PKI Management Message Profiles), with 236 the following exceptions: 238 o signature-based protection is the default protection; initial 239 transactions may also use HMAC, 241 o certification of a second key pair within the same transaction is 242 not supported, 244 o proof-of-possession (POPO) with self-signature of the certTemplate 245 according to [RFC4211] section 4.1 clause 3 is the only supported 246 POPO method, 248 o confirmation of newly enrolled certificates may be omitted, and 250 o all transactions consist of request-response message pairs 251 originating at the EE, i.e., announcement messages are omitted. 253 The profile specified in this document is compatible with the CMP 254 profile for UMTS, LTE, and 5G network domain security and 255 authentication framework [ETSI-3GPP], except that: 257 o protection of initial transactions may be HMAC-based, 259 o the subject name is mandatory in certificate templates, and 261 o confirmation of newly enrolled certificates may be omitted. 263 The profile specified in this document is compatible with the CMP 264 profile for on-line key management in rail networks as specified in 265 UNISIG subset-137 [UNISIG], except that: 267 o the messageTime format is required to be generalizedTime (Note: 268 While requiring UTC, UNISIG is in conflicts with CMP [RFC4210] 269 that requires the messageTime format to be generalizedTime), and 271 o in case the request message is MAC protected, also the response, 272 certConf, and PKIconf messages have a MAC-based protection (Note: 273 if changing to signature protection of the response the caPubs 274 field cannot be used securely anymore.). 276 1.5. Scope of this document 278 This document specifies requirements on generating messages on the 279 sender side. It does not specify strictness of verification on the 280 receiving side and how in detail to handle error cases. 282 Especially on the EE side this profile aims at a lightweight protocol 283 that can be implemented on constrained devices. On the side of the 284 central PKI components the profile accepts higher resource needs. 286 For the sake of robustness and preservation of security properties 287 implementations should, as far as security is not affected, adhere to 288 Postel's law: "Be conservative in what you do, be liberal in what you 289 accept from others" (often reworded as: "Be conservative in what you 290 send, be liberal in what you accept"). 292 When in chapter 3, 4, and 5 a field of the ASN.1 syntax as defined in 293 RFC 4210 [RFC4210] and RFC 4211 [RFC4211] is not explicitly 294 specified, it SHOULD not be used by the sending entity. The 295 receiving entity MUST NOT require its absence and if present SHOULD 296 ignore it. 298 1.6. Structure of this document 300 Chapter 2 introduces the general PKI architecture and approach to 301 certificate management using CMP that is assumed in this document. 302 Then it enlists the industrial certificate management use cases 303 specified in this document and describes them in general words. The 304 list of supported certificate management use cases is divided into 305 mandatory, recommended, and optional ones. 307 Chapter 3 profiles the CMP message header, protection, and extraCerts 308 section as they are general elements of CMP messages. 310 Chapter 4 profiles the exchange of CMP messages between an EE and the 311 first PKI component. There are various flavors of certificate 312 enrollment requests optionally with polling, revocation, error 313 handling, and general support transactions. 315 Chapter 5 profiles the exchange between further PKI components. 316 These are in the first place the forwarding of messages coming from 317 or going to an EE. This includes also initiating delayed delivery of 318 messages, which involves polling. Additionally, it specifies 319 transactions where the PKI component manages certificates on behalf 320 of an EE or for itself. 322 Chapter 6 outlines different mechanisms for CMP message transfer, 323 namely http-based transfer as already specified in [RFC6712], using 324 an additional TLS layer, offline file-based transport, CoAP 325 [RFC7252], or piggybacking CMP messages on other protocols. 327 1.7. Convention and Terminology 329 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 330 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 331 document are to be interpreted as described in RFC 2119 [RFC2119]. 333 In this document, these words will appear with that interpretation 334 only when in ALL CAPS. Lower case uses of these words are not to be 335 interpreted as carrying significance described in RFC 2119. 337 Technical terminology is used in conformance with RFC 4210 [RFC4210], 338 RFC 4211 [RFC4211], RFC 5280 [RFC5280], and IEEE 802.1AR 339 [IEEE802.1AR]. The following key words are used: 341 CA: Certification authority, which issues certificates. 343 RA: Registration authority, an optional system component to which 344 a CA delegates certificate management functions such as 345 authorization checks. 347 LRA: Local registration authority, an optional RA system component 348 with proximity to end entities. 350 EE: End entity, a user or device or service that holds a PKI 351 certificate. An identifier for the EE is given as the 352 subject of the certificate. 354 2. Architecture and use cases 356 2.1. Solution architecture 358 Typically, an industrial EE will be equipped with a manufacturer 359 certificate during production. A manufacturer certificate is 360 installed during production to identify the device throughout its 361 lifetime. This manufacturer certificate can be used to protect the 362 initial enrollment of operational certificates after installation of 363 the EE in a plant or industrial network. An operational certificate 364 is issued by the owner or operator of the device to identify the 365 device during operation, e.g., within a security protocol like IPSec, 366 TLS, or SSH. In IEEE 802.1AR [IEEE802.1AR] a manufacturer 367 certificate is called IDevID certificate and an operational 368 certificate is called LDevID certificate. 370 All certificate management transactions are initiated by the EE. The 371 EE creates a CMP request message, protects it using its manufacturer 372 or operational certificate, if available, and sends it to its locally 373 reachable PKI component. This PKI component may be an LRA, RA, or 374 the CA, which checks the request, responds to it itself, or forwards 375 the request upstream to the next PKI component. In case an (L)RA 376 changes the CMP request message header or body or wants to prove a 377 successful verification or authorization, it can apply a protection 378 of its own. Especially the communication between an LRA and RA can 379 be performed synchronously or asynchronously. Synchronous 380 communication describes a timely uninterrupted communication between 381 two communication partners, as asynchronous communication is not 382 performed in a timely consistent manner, e.g., because of a delayed 383 message delivery. 385 +-----+ +-----+ +-----+ +-----+ 386 | | | | | | | | 387 | EE |<---------->| LRA |<-------------->| RA |<---------->| CA | 388 | | | | | | | | 389 +-----+ +-----+ +-----+ +-----+ 391 synchronous (a)synchronous synchronous 392 +----connection----+------connection------+----connection----+ 394 on site at operators service partner 395 +----industrial plant----+-----backend services-----+-trust center-+ 397 Figure 1: Certificate management on site 399 In operation environments a layered LRA-RA-CA architecture can be 400 deployed, e.g., with LRAs bundling requests from multiple EEs at 401 dedicated locations and one (or more than one) central RA aggregating 402 the requests from multiple LRAs. Every (L)RA in this scenario will 403 have its own dedicated certificate and private key allowing it to 404 protect CMP messages it processes (CMP signing key/certificate). The 405 figure above shows an architecture using one LRA and one RA. It is 406 also possible to have only an RA or multiple LRAs and/or RAs. 407 Depending on the network infrastructure, the communication between 408 different PKI components may be synchronous online-communication, 409 delayed asynchronous communication, or even offline file transfer. 411 Third-party CAs typically implement different variants of CMP or even 412 use proprietary interfaces for certificate management. Therefore, 413 the LRA or the RA may need to adapt the exchanged CMP messages to the 414 flavor of communication required by the CA. 416 2.2. Basic generic CMP message content 418 Section 3 specifies the generic parts of the CMP messages as used 419 later in Section 4 and Section 5. 421 o Header of a CMP message; see Section 3.1. 423 o Protection of a CMP message; see Section 3.2. 425 o ExtraCerts field of a CMP message; see Section 3.3. 427 2.3. Supported use cases 429 Following the outlined scope from Section 1.5, this section gives a 430 brief overview of the certificate management use cases specified in 431 Section 4 and Section 5 and points out, if a implementation by 432 compliant EE or PKI component is mandatory, recommended or optional. 434 2.3.1. Mandatory use cases 436 The mandatory uses case in this document shall limit the overhead of 437 certificate management for constrained devices to the most crucial 438 types of transactions. 440 Section 4 - End Entity focused certificate management use cases 442 o Request a certificate from a new PKI with signature protection; 443 see Section 4.1.1. 445 o Request to update an existing certificate with signature 446 protection; see Section 4.1.2. 448 o Error reporting; see Section 4.3. 450 Section 5 - LRA and RA focused certificate management use cases 452 o Forward messages without changes; see Section 5.1.1. 454 o Forward messages with replaced protection and raVerified as proof- 455 of-possession; see Section 5.1.2.2. 457 o Error reporting; see Section 5.3. 459 2.3.2. Recommended Use Cases 461 Additional recommended use cases shall support some more complex 462 scenarios, that are considered as beneficial for industrial 463 environments. 465 Section 4 - End Entity focused certificate management use cases 467 o Request a certificate from a PKI with MAC protection; see 468 Section 4.1.3. 470 o Handle delayed enrollment due to asynchronous message delivery. 472 < Motivation see Section 4.1.6, specification TBD > 474 Section 5 - LRA and RA focused certificate management use cases 476 o Revoke a certificate on LRA or RA side. 478 < Motivation see Section 4.2, specification TBD > 480 2.3.3. Optional use cases 482 The optional use cases support specific requirements seen only in a 483 subset of industrial environments. 485 Section 4 - End Entity focused certificate management use cases 487 o Request a certificate from a legacy PKI using a PKCS#10 [RFC2986] 488 request. 490 < Motivation see Section 4.1.4, specification TBD > 492 o Add central generation of a key pair to a certificate request. 494 < Motivation see Section 4.1.5, specification TBD > 496 o Request to omit confirmation messages; see Section 4.1.7. 498 o Request to revoke a certificate from EE side. 500 < Motivation see Section 4.2, specification TBD > 502 o Additional support messages, e.g., to update a Root CA certificate 503 or to request an RFC 8366 [RFC8366] voucher. 505 < Motivation see Section 4.4, specification TBD > 507 Section 5 - LRA and RA focused certificate management use cases 509 o Initiate delayed enrollment due to asynchronous message delivery. 511 < Motivation see Section 5.1.3, specification TBD > 513 o Grant an EE's request to omit confirmation messages; see 514 Section 5.1.4. 516 o Revoke a certificate of another entity. 518 < Motivation see Section 5.2, specification TBD > 520 2.4. CMP message transport 522 Recommended transport 524 o Transfer CMP messages using HTTP; see Section 6.1. 526 Optional transport 527 o Transfer CMP messages using HTTPS with certificate-based 528 authentication; see Section 6.2. 530 o Transfer CMP messages using HTTPS with shared-secret based 531 protection; see Section 6.3. 533 o File-based CMP message transport. 535 < Motivation see Section 6.4, specification TBD > 537 o Transfer CMP messages using CoAP. 539 < Motivation see Section 6.5, specification TBD > 541 o Piggyback CMP messages on other reliable transport protocols. 543 < Motivation see Section 6.6, specification TBD > 545 3. Generic parts of the PKI message 547 To reduce redundancy in the text and to ease implementation, the 548 contents of the header, protection, and extraCerts fields of the CMP 549 messages used in the transactions specified in Section 4 and 550 Section 5 are standardized to the maximum extent possible. 551 Therefore, the generic parts of a CMP message are described centrally 552 in this section. 554 As described in section 5.1 of [RFC4210], all CMP messages have the 555 following general structure: 557 +--------------------------------------------+ 558 | PKIMessage | 559 | +----------------------------------------+ | 560 | | header | | 561 | +----------------------------------------+ | 562 | +----------------------------------------+ | 563 | | body | | 564 | +----------------------------------------+ | 565 | +----------------------------------------+ | 566 | | protection (OPTIONAL) | | 567 | +----------------------------------------+ | 568 | +----------------------------------------+ | 569 | | extraCerts (OPTIONAL) | | 570 | +----------------------------------------+ | 571 +--------------------------------------------+ 573 Figure 2: CMP message structure 575 The general contents of the message header, protection, and 576 extraCerts fields are specified in the Section 3.1 to Section 3.3. 578 In case a specific CMP message needs different contents in the 579 header, protection, or extraCerts fields, the differences are 580 described in the respective message. 582 The CMP message body contains the message-specific information. It 583 is described in the context of Section 4 and Section 5. 585 The behavior in case an error occurs while handling a CMP message is 586 described in Section 5.3. 588 3.1. General description of the CMP message header 590 This section describes the generic header field of all CMP messages 591 with signature-based protection. The only variations described here 592 are in the fields recipient, transactionID, and recipNonce of the 593 first message of a transaction. 595 In case a message has MAC-based protection the changes are described 596 in the respective section. The variations will affect the fields 597 sender, protectionAlg, and senderKID. 599 For requirements about proper random number generation please refer 600 to [RFC4086]. Any message-specific fields or variations are 601 described in the respective sections of this chapter. 603 header 604 pvno REQUIRED 605 -- MUST be set to 2 to indicate CMP V2 606 sender REQUIRED 607 -- MUST be the subject of the signing certificate used for 608 -- protection of this message 609 recipient REQUIRED 610 -- MUST be the name of the intended recipient 611 -- If this is the first message of a transaction: SHOULD be the 612 -- subject of the issuing CA certificate 613 -- In all other messages: SHOULD be the same name as in the 614 -- sender field of the previous message in this transaction 615 messageTime RECOMMENDED 616 -- MUST be the time at which the message was produced, if 617 -- present 618 protectionAlg REQUIRED 619 -- MUST be the algorithm identifier of the signature algorithm 620 -- used for calculation of the protection bits 621 -- The signature algorithm MUST be consistent with the 622 -- SubjectPublicKeyInfo field of the signer's certificate 623 -- The hash algorithm used SHOULD be SHA-256 624 algorithm REQUIRED 625 -- MUST be the OID of the signature algorithm, like 626 -- sha256WithRSAEncryption or ecdsa-with-SHA256 627 parameters PROHIBITED 628 -- MUST be absent 629 senderKID RECOMMENDED 630 -- MUST be the SubjectKeyIdentifier, if available, of the 631 -- certificate used for protecting this message 632 transactionID REQUIRED 633 -- If this is the first message of a transaction: 634 -- MUST be 128 bits of random data for the start of a 635 -- transaction to reduce the probability of having the 636 -- transactionID already in use at the server 637 -- In all other messages: 638 -- MUST be the value from the previous message in the same 639 -- transaction 640 senderNonce REQUIRED 641 -- MUST be fresh 128 random bits 642 recipNonce RECOMMENDED 643 -- If this is the first message of a transaction: SHOULD be 644 -- absent 645 -- In all other messages: MUST be present and contain the value 646 -- from senderNonce of the previous message in the same 647 -- transaction 649 3.2. General description of the CMP message protection 651 This section describes the generic protection field of all CMP 652 messages with signature-based protection. 654 protection REQUIRED 655 -- MUST contain the signature calculated using the signature 656 -- algorithm specified in protectionAlg 658 Only for MAC-based protection major differences apply as described in 659 the respective message. 661 The CMP message protection provides, if available, message origin 662 authentication and integrity protection for the CMP message header 663 and body. The CMP message extraCerts is not covered by this 664 protection. 666 NOTE: The requirements for checking certificates given in [RFC5280] 667 MUST be followed for the CMP message protection. OCSP or CRLs SHOULD 668 be used for status checking of the CMP signer certificates of 669 communication partners. 671 3.3. General description of CMP message extraCerts 673 This section describes the generic extraCerts field of all CMP 674 messages with signature-based protection. 676 extraCerts RECOMMENDED 677 -- SHOULD contain the signing certificate together with its 678 -- chain, if needed 679 -- If present, the first certificate in this field MUST 680 -- be the certificate used for signing this message 681 -- Self-signed certificates SHOULD NOT be included in 682 -- extraCerts and MUST NOT be trusted based on the listing in 683 -- extraCerts in any case 685 4. End Entity focused certificate management use cases 687 This chapter focuses on the communication of the EE and the first PKI 688 component it talks to. Depending on the network and PKI solution, 689 this will either be the LRA, the RA or the CA. 691 Profiles of the Certificate Management Protocol (CMP) [RFC4210] 692 handled in this chapter cover the following certificate management 693 use cases: 695 o Requesting a certificate from a PKI with variations like initial 696 requests and updating, central key generation and different 697 protection means 699 o Revocation of a certificate 701 o General messages for further support functions 703 The use cases mainly specify the message body of the CMP messages and 704 utilize the specification of the message header, protection and 705 extraCerts as specified in Section 4. 707 The behavior in case an error occurs is described in Section 4.3. 709 This chapter is aligned to Appendix D and Appendix E of [RFC4210]. 710 The general rules for interpretation stated in Appendix D.1 in 711 [RFC4210] need to be applied here, too. 713 This document does not mandate any specific supported algorithms like 714 Appendix D.2 of [RFC4210], [ETSI-3GPP], and [UNISIG] do. Using the 715 message sequences described here require agreement upon the 716 algorithms to support and thus the algorithm identifiers for the 717 specific target environment. 719 4.1. Requesting a new certificate from a PKI 721 There are different approaches to request a certificate from a PKI. 723 These approaches differ on the one hand in the way the EE can 724 authenticate itself to the PKI it wishes to get a new certificate 725 from and on the other hand in its capabilities to generate a proper 726 new key pair. The authentication means may be as follows: 728 o Using a certificate from a trusted PKI and the corresponding 729 private key, e.g., a manufacturer certificate 731 o Using the certificate to be updated and the corresponding private 732 key 734 o Using a shared secret known to the EE and the PKI 736 Typically, such EE requests a certificate from a CA. When the (L)RA/ 737 CA responds with a message containing a certificate, the EE MUST 738 reply with a confirmation message. The (L)RA/CA then MUST send 739 confirmation back, closing the transaction. 741 The message sequences in this section allow the EE to request 742 certification of a locally generated public-private key pair. (< The 743 functional extension for central key generation is TBD if needed. >) 744 For requirements about proper random number and key generation please 745 refer to [RFC4086]. The EE MUST provide a signature-based proof-of- 746 possession of the private key associated with the public key 747 contained in the certificate request as defined by [RFC4211] section 748 4.1 case 3. To this end it is assumed that the private key can 749 technically be used as signing key. The most commonly used 750 algorithms in industrial use cases are RSA and ECDSA, which can 751 technically be used for signature calculation regardless of 752 potentially intended restrictions of the key usage. 754 The requesting EE provides the binding of the proof-of-possession to 755 its identity by signature-based or MAC-based protection of the CMP 756 request message containing that POPO. The (L)RA/CA needs to verify 757 whether this EE is authorized to obtain a certificate with the 758 requested subject and other attributes and extensions. Especially 759 when removing the protection provided by the EE and applying a new 760 protection the (L)RA MUST verify in particular the included proof-of- 761 possession self-signature of the certTemplate using the public key of 762 the requested certificate and MUST check that the EE, as 763 authenticated by the message protection, is authorized to request a 764 certificate with the subject as specified in the certTemplate (see 765 Section 5.1.2). 767 There are several ways to install the Root CA certificate of a new 768 PKI on an EE. The installation can be performed in an out-of-band 769 manner, using a voucher [RFC8366] for enrolment, or by the caPubs 770 field in the certificate response message. In case the installation 771 of the new Root CA certificate is performed using the caPubs field, 772 the certificate response message MUST be properly authenticated, and 773 the sender of this message MUST be authorized to install new Root CA 774 certificates on the EE, e.g., by using a specific extendedKeyUsage in 775 the RA certificate. 777 4.1.1. A certificate from a new PKI with signature protection 779 This message sequence should be used by an EE to request a 780 certificate of a new PKI using an existing certificate from an 781 external PKI, e.g. a manufacturer certificate, to prove its identity 782 to the new PKI. The EE already has established trust in this new PKI 783 it is about to enroll to, e.g., by configuration means. The 784 initialization request message is signature-protected using the 785 existing certificate. 787 Preconditions: 789 1 The EE MUST have a certificate enrolled by an external PKI in 790 advance to this transaction to authenticate itself to the (L)RA/CA 791 using signature-based protection, e.g., using a manufacturer 792 certificate. 794 2 The EE SHOULD know the subject name of the new CA it requests a 795 certificate from; this name MAY be established using an enrollment 796 voucher or other configuration means. If the EE does not know the 797 name of the CA, the (L)RA/CA MUST know where to route this request 798 to. 800 3 The EE MUST authenticate responses from the (L)RA/CA; trust MAY be 801 established using an enrollment voucher or other configuration 802 means 804 4 The (L)RA/CA MUST trust the external PKI the EE uses to 805 authenticate itself; trust MAY be established using some 806 configuration means 808 This message sequenceis like that given in [RFC4210] Appendix E.7. 810 Message flow: 812 Step# EE (L)RA/CA 813 1 format ir 814 2 -> ir -> 815 3 handle, re-protect or 816 forward ir 817 4 format or receive ip 818 5 <- ip <- 819 6 handle ip 820 7 In case of status 821 "rejection" in the 822 ip message, no certConf 823 and pkiConf are sent 824 8 format certConf 825 9 -> certConf -> 826 10 handle, re-protect or 827 forward certConf 828 11 format or receive PKIConf 829 12 <- pkiConf <- 830 13 handle pkiConf 832 For this message sequence the EE MUST include exactly one single 833 CertReqMsg in the ir. If more certificates are required, further 834 requests MUST be sent using separate CMP Messages. 836 If the CA accepts the request it MUST return the new certificate in 837 the certifiedKeyPair field of the ip message. If the EE successfully 838 receives the certificate and accepts it, the EE MUST send a certConf 839 message, which MUST be answered by the (L)RA/CA with a pkiConf 840 message. If the (L)RA/CA does not receive the expected certConf 841 message in time it MUST handle this like a rejection by the EE. 843 If the certificate request was refused by the CA, the (L)RA/CA must 844 return an ip message containing the status code "rejection" and no 845 certifiedKeyPair field. Such an ip message MUST NOT be followed by 846 the certConf and pkiConf messages. 848 Detailed message description: 850 Certification Request -- ir 852 Field Value 854 header 855 -- As described in section 3.1 857 body 858 -- The request of the EE for a new certificate 859 ir REQUIRED 860 -- MUST be exactly one CertReqMsg 861 -- If more certificates are required, further requests MUST be 862 -- packaged in separate PKI Messages 863 certReq REQUIRED 864 certReqId REQUIRED 865 -- MUST be set to 0 866 certTemplate REQUIRED 867 version OPTIONAL 868 -- MUST be 2 if supplied. 869 subject REQUIRED 870 -- MUST contain the suggested subject name of the EE 871 -- certificate 872 publicKey REQUIRED 873 -- MUST include the subject public key algorithm ID and value 874 extensions OPTIONAL 875 -- MAY include end-entity-specific X.509 extensions of the 876 -- requested certificate like subject alternative name, 877 -- key usage, and extended key usage 878 Popo REQUIRED 879 POPOSigningKey REQUIRED 880 poposkInput PROHIBITED 881 -- MUST NOT be used because subject and publicKey are both 882 -- present in the certTemplate 883 algorithmIdentifier REQUIRED 884 -- The signature algorithm MUST be consistent with the 885 -- publicKey field of the certTemplate 886 -- The hash algorithm used SHOULD be SHA-256 887 signature REQUIRED 888 -- MUST be the signature computed over the DER-encoded 889 -- certTemplate 891 protection REQUIRED 892 -- As described in section 3.2 894 extraCerts REQUIRED 895 -- As described in section 3.3 897 Certification Response -- ip 899 Field Value 901 header 902 -- As described in section 3.1 904 body 905 -- The response of the CA to the request as appropriate 906 ip REQUIRED 907 caPubs OPTIONAL 908 -- MAY be used 909 -- If used it MUST contain only the root certificate of the 910 -- certificate contained in certOrEncCert 911 response REQUIRED 912 -- MUST be exactly one CertResponse 913 certReqId REQUIRED 914 -- MUST be set to 0 915 status REQUIRED 916 -- PKIStatusInfo structure MUST be present 917 status REQUIRED 918 -- positive values allowed: "accepted", "grantedWithMods" 919 -- negative values allowed: "rejection" 920 -- In case of rejection no certConf and pkiConf messages will 921 -- be sent 922 statusString OPTIONAL 923 -- MAY be any human-readable text for debugging, logging or to 924 -- display in a GUI 925 failInfo OPTIONAL 926 -- MUST be present if status is "rejection" and in this case 927 -- the transaction MUST be terminated 928 -- MUST be absent if the status is "accepted" or 929 -- "grantedWithMods" 930 certifiedKeyPair OPTIONAL 931 -- MUST be present if status is "accepted" or "grantedWithMods" 932 -- MUST be absent if status is "rejection" 933 certOrEncCert REQUIRED 935 -- MUST be present when certifiedKeyPair is present 936 certificate REQUIRED 937 -- MUST be present when certifiedKeyPair is present 938 -- MUST contain the newly enrolled X.509 certificate 940 protection REQUIRED 941 -- As described in section 3.2 943 extraCerts REQUIRED 944 -- As described in section 3.3 945 -- MUST contain the chain of the issued certificate 946 -- Duplicate certificates MAY be omitted 948 Certificate Confirmation -- certConf 950 Field Value 952 header 953 -- As described in section 3.1 955 body 956 -- The message of the EE sends confirmation to the (L)RA/CA 957 -- to accept or reject the issued certificates 958 certConf REQUIRED 959 -- MUST be exactly one CertStatus 960 CertStatus REQUIRED 961 certHash REQUIRED 962 -- MUST be the hash of the certificate, using the same hash 963 -- algorithm as used to create the certificate signature 964 certReqId REQUIRED 965 -- MUST be set to 0 966 status RECOMMENDED 967 -- PKIStatusInfo structure SHOULD be present 968 -- Omission indicates acceptance of the indicated certificate 969 status REQUIRED 970 -- positive values allowed: "accepted" 971 -- negative values allowed: "rejection" 972 statusString OPTIONAL 973 -- MAY be any human-readable text for debugging or logging 974 failInfo OPTIONAL 975 -- MUST be present if status is "rejection" 976 -- MUST be absent if the status is "accepted" 978 protection REQUIRED 979 -- As described in section 3.2 980 -- MUST use the same certificate as for protection of the ir 982 extraCerts RECOMMENDED 983 -- SHOULD contain the protection certificate together with its 984 -- chain 985 -- If present, the first certificate in this field MUST be the 986 -- certificate used for signing this message 987 -- Self-signed certificates SHOULD NOT be included in 988 -- extraCerts and 989 -- MUST NOT be trusted based on the listing in extraCerts in 990 -- any case 992 PKI Confirmation -- pkiConf 994 Field Value 996 header 997 -- As described in section 3.1 999 body 1000 pkiConf REQUIRED 1001 -- The content of this field MUST be NULL 1003 protection REQUIRED 1004 -- As described in section 3.2 1005 -- SHOULD use the same certificate as for protection of the ip 1007 extraCerts RECOMMENDED 1008 -- SHOULD contain the protection certificate together with its 1009 -- chain 1010 -- If present, the first certificate in this field MUST be the 1011 -- certificate used for signing this message 1012 -- Self-signed certificates SHOULD NOT be included in extraCerts 1013 -- and 1014 -- MUST NOT be trusted based on the listing in extraCerts in 1015 -- any case 1017 4.1.2. Update an existing certificate with signature protection 1019 This message sequence should be used by an EE to request an update of 1020 one of the certificates it already has and that is still valid. The 1021 EE uses the certificate it wishes to update to prove its identity and 1022 possession of the private key for the certificate to be updated to 1023 the PKI. Therefore, the key update request message is signed using 1024 the certificate that is to be updated. 1026 The general message flow for this message sequence is the same as 1027 given in Section 4.1.1. 1029 Preconditions: 1031 1 The certificate the EE wishes to update MUST NOT be expired or 1032 revoked. 1034 2 A new public-private key pair SHOULD be used. 1036 The message sequence for this exchange is like that given in 1037 [RFC4210] Appendix D.6. 1039 The message sequence for this exchange is identical to that given in 1040 Section 4.1.1, with the following changes: 1042 1 The body of the first request and response MUST be kur and kup, 1043 respectively. 1045 2 Protection of the kur MUST be performed using the certificate to 1046 be updated. 1048 3 The subject field of the CertTemplate MUST contain the subject 1049 name of the existing certificate to be updated, without 1050 modifications. 1052 4 The CertTemplate MUST contain the subject, issuer and publicKey 1053 fields only. 1055 5 The regCtrl OldCertId SHOULD be used to make clear, even in case 1056 an (L)RA changes the message protection, which certificate is to 1057 be. 1059 6 The caPubs field in the kup message MUST be absent. 1061 As part of the certReq structure of the kur the control is added 1062 right after the certTemplate. 1064 controls 1065 type RECOMMENDED 1066 -- MUST be the value id-regCtrl-oldCertID, if present 1067 value 1068 issuer REQUIRED 1069 serialNumber REQUIRED 1070 -- MUST contain the issuer and serialNumber of the certificate 1071 -- to be updated 1073 4.1.3. A certificate from a PKI with MAC protection 1075 This message sequence should be used by an EE to request a 1076 certificate of a new PKI without having a certificate to prove its 1077 identity to the target PKI, but there is a shared secret established 1078 between the EE and the PKI. Therefore, the initialization request is 1079 MAC-protected using this shared secret. The (L)RA checking the MAC- 1080 protection SHOULD replace this protection according to Section 5.1.2 1081 in case the next hop does not know the shared secret too. 1083 For requirements with regard to proper random number and key 1084 generation please refer to [RFC4086]. 1086 The general message flow for this message sequence is the same as 1087 given in Section 4.1.1. 1089 Preconditions: 1091 1 The EE and the (L)RA/CA MUST share a symmetric key, this MAY be 1092 established by a service technician during initial local 1093 configuration. 1095 2 The EE SHOULD know the subject name of the new CA it requests a 1096 certificate from; this name MAY be established using an enrollment 1097 voucher or other configuration means. If the EE does not know the 1098 name of the CA, the (L)RA/CA MUST know where to route this request 1099 to. 1101 3 The EE MUST authenticate responses from the (L)RA/CA; trust MAY be 1102 established using the shared symmetric key. 1104 The message sequence for this exchange is like that given in 1105 [RFC4210] Appendix D.4. 1107 The message sequence for this exchange is identical to that given in 1108 Section 4.1.1, with the following changes: 1110 1 The protection of all messages MUST be calculated using Message 1111 Authentication Code (MAC); the protectionAlg field MUST be id- 1112 PasswordBasedMac as described in section 5.1.3.1 of [RFC4210]. 1114 2 The sender MUST contain a name representing the originator of the 1115 message. The senderKID MUST contain a reference all participating 1116 entities can use to identify the symmetric key used for the 1117 protection. 1119 3 The extraCerts of the ir, certConf, and PKIConf messages MUST be 1120 absent. 1122 4 The extraCerts of the ip message MUST contain the chain of the 1123 issued certificate and root certificates SHOULD not be included 1124 and MUST NOT be trusted in any case. 1126 Part of the protectionAlg structure, where the algorithm identifier 1127 MUST be id-PasswordBasedMac, is a PBMParameter sequence. The fields 1128 of PBMParameter SHOULD remain constant throughout this certificate 1129 management transaction to reduce the computational overhead. 1131 PBMParameter REQUIRED 1132 salt REQUIRED 1133 -- MUST be the random value to salt the secret key 1134 owf REQUIRED 1135 -- MUST be the algorithm identifier for the one-way function 1136 -- used 1137 -- The one-way function SHA-1 MUST be supported due to 1138 -- [RFC4211] requirements, but SHOULD NOT be used any more 1139 -- SHA-256 SHOULD be used instead 1140 iterationCount REQUIRED, 1141 -- MUST be a limited number of times the OWF is applied 1142 -- To prevent brute force and dictionary attacks a reasonable 1143 -- high number SHOULD be used 1144 mac REQUIRED 1145 -- MUST be the algorithm identifier of the MAC algorithm used 1146 -- The MAC function HMAC-SHA1 MUST be supported due to 1147 -- [RFC4211] requirements, but SHOULD NOT be used any more 1148 -- HMAC-SHA-256 SHOULD be used instead 1150 4.1.4. A certificate from a legacy PKI using PKCS#10 request 1152 This message sequence should be used by an EE to request a 1153 certificate of a legacy PKI only capable to process PKCS#10 [RFC2986] 1154 certification requests. The EE can prove its identity to the target 1155 PKI by using various protection means as described in Section 4.1.1 1156 or Section 4.1.3. 1158 In contrast to the other transactions described in Section 4.1, this 1159 transaction uses PKCS#10 [RFC2986] instead of CRMF [RFC4211] for the 1160 certificate request for compatibility reasons with legacy CA systems 1161 that require a PKCS#10 certificate request and cannot process CMP 1162 [RFC4210] or CRMF [RFC4211] messages. In such case the (L)RA can 1163 extract the PKCS#10 certificate request from the p10cr and provide it 1164 separately to the CA. 1166 < Details need to be defined later > 1168 4.1.5. Generate the key pair centrally at the (L)RA/CA 1170 It is strongly preferable to generate public-private key pairs 1171 locally at the EE. Together with proof-of-possession of the private 1172 key in the certification request, this is to make sure that only the 1173 entity identified in the newly issued certificate has the private 1174 key. 1176 There are some rare cases where an EE is not able or not willing to 1177 locally generate the new key pair. Reasons for this may be the 1178 following: 1180 o Lack of sufficient initial entropy. 1182 Note: Good random numbers are not only needed for key generation, but 1183 also for session keys and nonces in any security protocol. 1184 Therefore, we believe that a decent security architecture should 1185 anyway support good random number generation on the EE side or 1186 provide enough entropy for the RNG seed during manufacturing to 1187 guarantee good initial pseudo-random number generation. 1189 o Due to lack of computational resources, e.g., in case of RSA keys. 1191 Note: As key generation can be performed in advance to the 1192 certificate enrollment communication, it is typical not time 1193 critical. 1195 Note: Besides the initial enrollment right after the very first 1196 bootup of the device, where entropy available on the device may be 1197 insufficient, we do not see any good reason for central key 1198 generation. 1200 < Details need to be defined later > 1202 4.1.6. Delayed enrollment 1204 This functional extension can be applied in combination with 1205 certificate enrollment as described in Section 4.1.1 to 1206 Section 4.1.4. The functional extension can be used in case a (L)RA/ 1207 CA cannot respond to the certificate request in a timely manner, e.g. 1208 due to offline upstream communication or registration officer 1209 interaction. Depending on the PKI architecture, it is not 1210 necessarily the PKI component directly communicating with the EE that 1211 initiates the delayed enrollment. In this case this PKI component 1212 MUST include the status waiting in the response and this response 1213 MUST not contain a newly issued certificate. When receiving a 1214 response with status waiting the EE MUST send a poll request to the 1215 (L)RA/CA. The (L)RA/CA MUST answers with a poll response containing 1216 a checkAfter time. This value indicates the minimum number of 1217 seconds that must elapse before the EE sends another poll request. 1218 As soon as the (L)RA/CA can provide the final response message for 1219 the initial request of the EE, it MUST provide this in response to a 1220 poll request. After receiving this response, the EE can continue the 1221 original message sequence as described in the respective section of 1222 this document, e.g. send a certConf message. 1224 < Details need to be defined later > 1226 4.1.7. Omitted confirmation 1228 This functional extension can be applied in combination with 1229 certificate enrollment as described in sections Section 4.1.1 to 1230 Section 4.1.4. The functional extension can be used in case an EE 1231 does not want to send certificate confirmation messages to reduce the 1232 number of protocol messages exchanged in a transaction, it can 1233 indicate this by including the implicitConfirm extension in the 1234 header of a certificate request message. Only if the (L)RA/CA 1235 confirms this request using the same mechanism, the EE SHOULD omit 1236 sending the certificate confirmation message. Depending on the PKI 1237 architecture, it is not necessarily that the PKI component directly 1238 communicating with the EE replies to the request to omit sending 1239 confirmation messages, see also Section 5.1.4. 1241 The EE MUST use the implicitConfirm extension as part of the 1242 generalInfo field in the header of the ir/cr/p10cr/kur to indicate 1243 its wish to not send a CertConf message. If the (L)RA/CA confirms 1244 this request, it MUST include the implicitConfirm extension as part 1245 of the generalInfo field in the header of the ip/cp/kup message as 1246 well. If the EE does not find the implicitConfirm extension in the 1247 response message, it MUST send the certificate confirmation. 1249 The generalInfo field containing the implicitConfirm extension looks 1250 like this: 1252 generalInfo REQUIRED 1253 implicitConfirm REQUIRED 1254 -- The value MUST be NULL 1256 4.2. Revoking a certificate 1258 This message sequence should be used by an EE to revoke one of its 1259 certificates. The revocation request message MUST be signed using 1260 the certificate that is to be revoked to prove the authorization to 1261 revoke to the PKI. The certificate request message is signature- 1262 protected using this certificate. 1264 < Details need to be defined later > 1266 4.3. Error reporting 1268 This functionality should be used by an EE to report any error 1269 conditions upstream to the (L)RA/CA. Error reporting by the (L)RA 1270 downstream to the EE is described in Section 5.3. 1272 In case the error condition is related to specific details of an ip, 1273 cp, or kup response message and a confirmation is expected the error 1274 condition MUST be reported in the respective certConf message with 1275 negative contents. 1277 General error conditions, e.g., problems with the message header, 1278 protection, or extraCerts, and negative feedback on rp, pollRep, or 1279 pkiConf messages MAY be reported in the form of an error message. 1281 In both situations the error is reported in the PKIStatusInfo 1282 structure of the respective message. 1284 The (L)RA/CA MUST respond to an error message with a pkiConf message, 1285 or with another error message if any part of the header is not valid. 1286 Both sides MUST treat this message as the end of the current 1287 transaction. 1289 The PKIStatusInfo structure is used to report errors. The 1290 PKIStatusInfo structure SHOULD consist of the following fields: 1292 o status: Here the PKIStatus value rejection is the only one 1293 allowed. 1295 o statusString: Here any human-readable valid value for logging or 1296 to display in a GUI SHOULD be added. 1298 o failInfo: Here the PKIFailureInfo values MAY be used in the 1299 following way. For explanation of the reason behind a specific 1300 value, please refer to [RFC4210] Appendix F. 1302 * transactionIdInUse: This is sent in case the received request 1303 contains a transaction ID that is already in use for another 1304 transaction. An EE receiving such error message SHOULD resend 1305 the request in a new transaction using a different transaction 1306 ID. 1308 * systemUnavail or systemFailure: This is sent in case a back-end 1309 system is not available or currently not functioning correctly. 1310 An EE receiving such error message SHOULD resend the request in 1311 a new transaction after some time. 1313 Detailed error message description: 1315 Error Message -- error 1317 Field Value 1319 header 1320 -- As described in section 3.1 1322 body 1323 -- The message sent by the EE or the (L)RA/CA to indicate an 1324 -- error that occurred 1325 error REQUIRED 1326 pKIStatusInfo REQUIRED 1327 status REQUIRED 1328 -- MUST have the value "rejection" 1329 statusString RECOMMENDED 1330 -- SHOULD be any human-readable text for debugging, logging 1331 -- or to display in a GUI 1332 failInfo OPTIONAL 1333 -- MAY be present 1335 protection REQUIRED 1336 -- As described in section 3.2 1338 extraCerts OPTIONAL 1339 -- As described in section 3.3 1341 4.4. Support messages 1343 The following support messages offer on demand in-band transport of 1344 content that may be relevant to the EE. The general request messages 1345 and general response messages are used for this purpose. 1347 The general message and general response transport InfoTypeAndValue 1348 structures. In addition to those infoType values defined in CMP 1349 [RFC4210] further OIDs MAY be defined to define new certificate 1350 management transactions, or general-purpose messages as needed in a 1351 specific environment. 1353 Possible content described here address: 1355 o Update of Root CA certificates 1357 o Parameters needed for a planned certificate request message 1359 o Request an enrollment voucher 1360 < Details need to be defined later > 1362 4.4.1. Root CA certificate update 1364 This message sequence can be used by an EE to request an update of a 1365 Root CA Certificate by the EE. It utilizes the root CA key update 1366 announcement message as described in [RFC4210] Appendix E.4 as 1367 response to a respective general request message. 1369 An EE requests a root CA certificate update from the (L)RA/CA by 1370 sending a general message with OID id-it-caKeyUpdateInfo. The (L)RA/ 1371 CA responds with a general response with the same OID that either 1372 contains the update of the root CA certificate consisting of three 1373 certificates, or with no content in case no update is available. 1374 These three certificates are described in more detail in section 1375 4.4.1, section 6.2, and Appendix E.3 of [RFC4210]. 1377 < Details need to be defined later > 1379 4.4.2. Get enrollment voucher 1381 This message sequence can be used by an EE to request an enrollment 1382 voucher containing the root certificate of a new PKI to establish 1383 trust in this PKI, e.g., in case no out-of-band transport is 1384 available. Such an enrollment voucher can be used in advance to an 1385 enrollment to this new environment. It may contain further 1386 information depending on the use case. 1388 An EE requests an enrollment voucher from the (L)RA/CA by sending a 1389 general message. The (L)RA/CA responds with a general response with 1390 the same OID that contains the voucher. 1392 < Details need to be defined later > 1394 5. LRA and RA focused certificate management use cases 1396 This chapter focuses on the communication of PKI backend components 1397 with each other. Depending on the network and PKI solution design, 1398 these will either be an LRA, RA or CA. 1400 Typically, an (L)RA forwards messages from downstream, but it may 1401 also reply to them itself. Besides forwarding of received messages 1402 an (L)RA could also need to revoke certificates of EEs, report 1403 errors, or may need to manage its own certificates. 1405 < Like in the CMC Updates [RFC6402] additional Extended Key Usages 1406 like id-kp-cmpRA may be defined to indicate that a key pair is 1407 entitled to be used for signature-based protection of a CMP message 1408 by an (L)RA/CA. > 1410 5.1. Forwarding of messages 1412 Each CMP request message (i.e., ir, cr, p10cr, kur, pollReq, or 1413 certConf) or error message coming from an EE or the previous 1414 (downstream) PKI component MUST be sent to the next (upstream) PKI 1415 component. This PKI component MUST forward response messages to the 1416 next (downstream) PKI component or EE. 1418 The (L)RA SHOULD verify the protection, the syntax, the required 1419 message fields, the message type, and if applicable the authorization 1420 and the proof-of-possession of the message. Additional checks or 1421 actions MAY be applied depending on the PKI solution requirements and 1422 concept. If one of these verification procedures fails, the (L)RA 1423 SHOULD respond with a negative response message and SHOULD not 1424 forward the message further upstream. General error conditions 1425 should be handled as described in Section 4.3 and Section 5.3. 1427 An (L)RA SHOULD not change the received message if not necessary. 1428 The (L)RA SHOULD only update the message protection if it is 1429 technically necessary. Concrete PKI system specifications may define 1430 in more detail if and when to do so. 1432 This is particularly relevant in the upstream communication of a 1433 request message. 1435 Each hop in a chain of PKI components has one or more 1436 functionalities, e.g.: 1438 o An (L)RA may need to verify the identities of EEs or base 1439 authorization decisions for certification request processing on 1440 specific knowledge of the local setup, e.g., by consulting an 1441 inventory or asset management system. 1443 o An (L)RA may need to add fields to certificate request messages. 1445 o An (L)RA may need to store data from a message in a database for 1446 later usage or documentation purposes. 1448 o An (L)RA may provide traversal of a network boundary. 1450 o An (L)RA may need to double-check if the messages transferred back 1451 and forth are properly protected and well formed. 1453 o An RA can collect messages from different LRAs and forward them to 1454 the CA. 1456 o An (L)RA may provide a proof that it has performed all required 1457 checks. 1459 o An (L)RA may initiate a delayed enrollment due to offline upstream 1460 communication or registration officer interaction. 1462 o An (L)RA may grant the request of an EE to omit sending a 1463 confirmation message. 1465 Therefore, the decision if a message should be forwarded 1467 o unchanged with the original protection, 1469 o unchanged with a new protection, or 1471 o changed with a new protection 1473 depends on the PKI solution design and the associated security policy 1474 (CP/CPS [RFC3647]). 1476 This section specifies the different options an (L)RA may implement 1477 and use. 1479 An (L)RA MAY update the protection of a message 1481 o if the (L)RA performs changes to the header or the body of the 1482 message, 1484 o if the (L)RA needs to prove checks or validations performed on the 1485 message to one of the next (upstream) PKI components, 1487 o if the (L)RA needs to protect the message using a key and 1488 certificate from a different PKI, or 1490 o if the (L)RA needs to replace a MAC based-protection. 1492 This is particularly relevant in the upstream communication of 1493 certificate request messages. 1495 The message protection covers only the header and the body and not 1496 the extraCerts. The (L)RA MAY change the extraCerts in any of the 1497 following message adaptations, e.g., to sort or add needed or to 1498 delete needless certificates to support the next hop. This may be 1499 particularly helpful to extend upstream messages with additional 1500 certificates or to reduce the number of certificates in downstream 1501 messages when forwarding to constrained devices. 1503 5.1.1. Not changing protection 1505 This message adaptation can be used by any (L)RA to forward an 1506 original CMP message without changing the header, body or protection. 1507 In any of these cases the (L)RA acts more like a proxy, e.g., on a 1508 network boundary, implementing no specific RA-like security 1509 functionality to the PKI. 1511 This message adaptation MUST be used for forwarding kur messages that 1512 must not be approved by the respective (L)RA. 1514 5.1.2. Replacing protection 1516 The following two message adaptations can be used by any (L)RA to 1517 forward a CMP message with or without changes, but providing its own 1518 protection using its CMP signer key providing approval of this 1519 message. In this case the (L)RA acts as an actual Registration 1520 Authority (RA), which implements important security functionality of 1521 the PKI. 1523 Before replacing the existing protection by a new protection, the 1524 (L)RA MUST verify the protection provided by the EE or by the 1525 previous PKI component and approve its content including any own 1526 modifications. For certificate requests the (L)RA MUST verify in 1527 particular the included proof-of-possession self-signature of the 1528 certTemplate using the public key of the requested certificate and 1529 MUST check that the EE, as authenticated by the message protection, 1530 is authorized to request a certificate with the subject as specified 1531 in the certTemplate. 1533 In case the received message has been protected by a CA or another 1534 (L)RA, the current (L)RA MUST verify its protection and approve its 1535 content including any own modifications. For certificate requests 1536 the (L)RA MUST check that the other (L)RA, as authenticated by the 1537 message protection, is authorized to issue or forward the request. 1539 These message adaptations MUST NOT be applied to kur request messages 1540 as described in Section 4.1.2 since their original protection using 1541 the key and certificate to be updated needs to be preserved, unless 1542 the regCtrl OldCertId is used to clearly identify the certificate to 1543 be updated. 1545 5.1.2.1. Keeping proof-of-possession 1547 This message adaptation can be used by any (L)RA to forward a CMP 1548 message with or without modifying the message header or body while 1549 preserving any included proof-of-possession. 1551 By replacing the existing using its own CMP signer key the (L)RA 1552 provides a proof of verifying and approving of the message as 1553 described above. 1555 In case the (L)RA modifies the certTemplate of an ir or cr message, 1556 the message adaptation in Section 5.1.2.2 needs to be applied 1557 instead. 1559 5.1.2.2. Breaking proof-of-possession 1561 This message adaptation can be used by any (L)RA to forward an ir or 1562 cr message with modifications of the certTemplate i.e., modification, 1563 addition, or removal of fields. Such changes will break the proof- 1564 of-possession provided by the EE in the original message. 1566 By replacing the existing or applying an initial protection using its 1567 own CMP signer key the (L)RA provides a proof of verifying and 1568 approving the new message as described above. 1570 In addition to the above the (L)RA MUST verify in particular the 1571 proof-of-possession contained in the original message as described 1572 above. If these checks were successfully performed the (L)RA MUST 1573 change the popo to raVerified. 1575 The popo field MUST contain the raVerified choice in the certReq 1576 structure of the modified message as follows: 1578 popo 1579 raVerified REQUIRED 1580 -- MUST have the value NULL and indicates that the (L)RA 1581 -- verified the popo of the original message. 1583 5.1.3. Initiating delayed enrollment 1585 This message adaptation can be used by an (L)RA to initiate delayed 1586 enrollment. In this case a (L)RA/CA MUST add the status waiting in 1587 the response message. The (L)RA/CA MUST then reply to the pollReq 1588 messages as described in Section 4.1.6. 1590 5.1.4. Granting omitted confirmation 1592 This message adaptation can be applied for omitted confirmation in 1593 case a (L)RA/CA grants the request to omit sending confirmation 1594 messages. This (L)RA/CA includes the implicitConfirm extension in 1595 the header of an ip, cp, or kup response message as described in 1596 Section 4.1.7. 1598 5.2. Revoking certificates of other entities 1600 This message sequence can be used by an (L)RA to revoke a certificate 1601 of any other entity. The revocation request message MUST be signed 1602 by the (L)RA using its own CMP signer key to prove to the PKI 1603 authorization to revoke the certificate on behalf of the EE. 1605 < Details need to be defined later > 1607 5.3. Error reporting 1609 This functionality should be used by the (L)RA to report any error 1610 conditions downstream to the EE. Potential error reporting by the EE 1611 upstream to the (L)RA/CA is described in Section 4.3. 1613 In case the error condition is related to specific details of an ir, 1614 cr, p10cr, or kur request message it MUST be reported in the specific 1615 response message, i.e., an ip, cp, or kup with negative contents. 1617 General error conditions, e.g., problems with the message header, 1618 protection, or extraCerts, and negative feedback on rr, pollReq, 1619 certConf, or error messages MUST be reported in the form of an error 1620 message. 1622 In both situations the (L)RA reports the errors in the PKIStatusInfo 1623 structure of the respective message as described in Section 4.3. 1625 An EE receiving any such negative feedback SHOULD log the error 1626 appropriately and MUST terminate the current transaction. 1628 6. CMP message transport variants 1630 The CMP messages are designed to be self-contained, such that in 1631 principle any transport can be used. HTTP SHOULD be used for online 1632 transport while file-based transport MAY be used in case offline 1633 transport is required. In case HTTP transport is not desired or 1634 possible, CMP messages MAY also be piggybacked on any other reliable 1635 transport protocol, e.g., CoAP [RFC7252]. 1637 Independently of the means of transport it could happen that messages 1638 are lost, or a communication partner does not respond. In order to 1639 prevent waiting indefinitely, each CMP client component SHOULD use a 1640 configurable per-request timeout, and each CMP server component 1641 SHOULD use a configurable per-response timeout in case a further 1642 message is to be expected from the client side. In this way a 1643 hanging transaction can be closed cleanly with an error and related 1644 resources (for instance, any cached extraCerts) can be freed. 1646 6.1. HTTP transport 1648 This transport mechanism can be used by an EE and (L)RA/CA to 1649 transfer CMP messages over HTTP. If HTTP transport is used the 1650 specifications as described in [RFC6712] MUST be followed. 1652 6.2. HTTPS transport using certificates 1654 This transport mechanism can be used by an EE and (L)RA/CA to further 1655 protect the HTTP transport as described in Section 6.1 using TLS 1.2 1656 [RFC5246] or TLS 1.3 [RFC8446] as described in [RFC2818] with 1657 certificate-based authentication. Using this transport mechanism, 1658 the CMP transport via HTTPS MUST use TLS server authentication and 1659 SHOULD use TLS client authentication. 1661 EE: 1663 o The EE SHOULD use a TLS client certificate as far as available. 1664 If no dedicated TLS certificate is available the EE SHOULD use an 1665 already existing certificate identifying the EE (e.g., a 1666 manufacturer certificate). 1668 o If no TLS certificate is available at the EE, server-only 1669 authenticated TLS SHOULD be used. 1671 o The EE MUST validate the TLS server certificate of its 1672 communication partner. 1674 (L)RA: 1676 o Each (L)RA SHOULD use a TLS client certificate on its upstream 1677 (client) interface. 1679 o Each (L)RA SHOULD use a TLS server certificate on its downstream 1680 (server) interface. 1682 o Each (L)RA MUST validate the TLS certificate of its communication 1683 partner. 1685 NOTE: The requirements for checking certificates given in [RFC5280], 1686 [RFC5246] and [RFC8446] MUST be followed for the TLS layer. OCSP or 1687 CRLs SHOULD be used for status checking of the TLS certificates of 1688 communication partners. 1690 6.3. HTTPS transport using shared secrets 1692 This transport mechanism can be used by an EE and (L)RA/CA to further 1693 protect the HTTP transport as described in Section 6.1 using TLS 1.2 1694 [RFC5246] or TLS 1.3 [RFC8446] as described in [RFC2818] with mutual 1695 authentication based on shared secrets as described in [RFC5054]. 1697 EE: 1699 o The EE MUST use the shared symmetric key for authentication. 1701 (L)RA: 1703 o The (L)RA MUST use the shared symmetric key for authentication. 1705 6.4. File-based transport 1707 For offline transfer file-based transport MAY be used. Offline 1708 transport is typically used between LRA and RA nodes. 1710 Connection and error handling mechanisms like those specified for 1711 HTTP in [RFC6712] need to be implemented. 1713 < Details need to be defined later > 1715 6.5. CoAP transport 1717 In constrained environments where no HTTP transport is desired or 1718 possible, CoAP [RFC7252] MAY be used instead. 1720 Connection and error handling mechanisms like those specified for 1721 HTTP in [RFC6712] need to be implemented. 1723 < Details need to be defined later > 1725 6.6. Piggybacking on other reliable transport 1727 For online transfer where no HTTP transport is desired or possible 1728 CMP messages MAY also be transported on some other reliable protocol. 1730 Connection and error handling mechanisms like those specified for 1731 HTTP in [RFC6712] need to be implemented. 1733 < Details need to be defined later > 1735 7. IANA Considerations 1737 1739 8. Security Considerations 1741 1743 9. Acknowledgements 1745 We would like to thank the various reviewers of this CMP profile. 1747 10. References 1749 10.1. Normative References 1751 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 1752 Requirement Levels", BCP 14, RFC 2119, 1753 DOI 10.17487/RFC2119, March 1997, 1754 . 1756 [RFC2818] Rescorla, E., "HTTP Over TLS", RFC 2818, 1757 DOI 10.17487/RFC2818, May 2000, 1758 . 1760 [RFC2986] Nystrom, M. and B. Kaliski, "PKCS #10: Certification 1761 Request Syntax Specification Version 1.7", RFC 2986, 1762 DOI 10.17487/RFC2986, November 2000, 1763 . 1765 [RFC4086] Eastlake 3rd, D., Schiller, J., and S. Crocker, 1766 "Randomness Requirements for Security", BCP 106, RFC 4086, 1767 DOI 10.17487/RFC4086, June 2005, 1768 . 1770 [RFC4210] Adams, C., Farrell, S., Kause, T., and T. Mononen, 1771 "Internet X.509 Public Key Infrastructure Certificate 1772 Management Protocol (CMP)", RFC 4210, 1773 DOI 10.17487/RFC4210, September 2005, 1774 . 1776 [RFC4211] Schaad, J., "Internet X.509 Public Key Infrastructure 1777 Certificate Request Message Format (CRMF)", RFC 4211, 1778 DOI 10.17487/RFC4211, September 2005, 1779 . 1781 [RFC5054] Taylor, D., Wu, T., Mavrogiannopoulos, N., and T. Perrin, 1782 "Using the Secure Remote Password (SRP) Protocol for TLS 1783 Authentication", RFC 5054, DOI 10.17487/RFC5054, November 1784 2007, . 1786 [RFC5246] Dierks, T. and E. Rescorla, "The Transport Layer Security 1787 (TLS) Protocol Version 1.2", RFC 5246, 1788 DOI 10.17487/RFC5246, August 2008, 1789 . 1791 [RFC5280] Cooper, D., Santesson, S., Farrell, S., Boeyen, S., 1792 Housley, R., and W. Polk, "Internet X.509 Public Key 1793 Infrastructure Certificate and Certificate Revocation List 1794 (CRL) Profile", RFC 5280, DOI 10.17487/RFC5280, May 2008, 1795 . 1797 [RFC6712] Kause, T. and M. Peylo, "Internet X.509 Public Key 1798 Infrastructure -- HTTP Transfer for the Certificate 1799 Management Protocol (CMP)", RFC 6712, 1800 DOI 10.17487/RFC6712, September 2012, 1801 . 1803 [RFC8446] Rescorla, E., "The Transport Layer Security (TLS) Protocol 1804 Version 1.3", RFC 8446, DOI 10.17487/RFC8446, August 2018, 1805 . 1807 10.2. Informative References 1809 [ETSI-3GPP] 1810 3GPP, "3GPP TS33.310; Network Domain Security (NDS); 1811 Authentication Framework (AF); Release 16; V16.1.0", 1812 December 2018, 1813 . 1815 [IEC62443-3-3] 1816 International Electrotechnical Commission, "IEC 62443 Part 1817 3-3 - System security requirements and security levels", 1818 IEC 62443-3-3, August 2013, . 1820 [IEEE802.1AR] 1821 IEEE, "IEEE 802.1AR Secure Device Identifier", 06 2018, 1822 . 1825 [RFC3647] Chokhani, S., Ford, W., Sabett, R., Merrill, C., and S. 1826 Wu, "Internet X.509 Public Key Infrastructure Certificate 1827 Policy and Certification Practices Framework", RFC 3647, 1828 DOI 10.17487/RFC3647, November 2003, 1829 . 1831 [RFC6402] Schaad, J., "Certificate Management over CMS (CMC) 1832 Updates", RFC 6402, DOI 10.17487/RFC6402, November 2011, 1833 . 1835 [RFC7252] Shelby, Z., Hartke, K., and C. Bormann, "The Constrained 1836 Application Protocol (CoAP)", RFC 7252, 1837 DOI 10.17487/RFC7252, June 2014, 1838 . 1840 [RFC8366] Watsen, K., Richardson, M., Pritikin, M., and T. Eckert, 1841 "A Voucher Artifact for Bootstrapping Protocols", 1842 RFC 8366, DOI 10.17487/RFC8366, May 2018, 1843 . 1845 [UNISIG] UNISIG, "UNISIG subset-137; ERTMS/ETCS On-line Key 1846 Management FFFIS; V1.0.0", December 2015, 1847 . 1849 Appendix A. Additional Stuff 1851 This becomes an Appendix. 1853 Authors' Addresses 1855 Hendrik Brockhaus 1856 Siemens AG 1857 Otto-Hahn-Rin 6 1858 Munich 81739 1859 Germany 1861 Email: hendrik.brockhaus@siemens.com 1862 URI: http://www.siemens.com/ 1864 Steffen Fries 1865 Siemens AG 1866 Otto-Hahn-Ring 6 1867 Munich 81739 1868 Germany 1870 Email: steffen.fries@siemens.com 1871 URI: http://www.siemens.com/ 1872 David von Oheimb 1873 Siemens AG 1874 Otto-Hahn-Ring 6 1875 Munich 81739 1876 Germany 1878 Email: david.von.oheimb@siemens.com 1879 URI: http://www.siemens.com/