idnits 2.17.1 draft-brockhaus-lamps-lightweight-cmp-profile-02.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- No issues found here. Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- No issues found here. Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- No issues found here. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust and authors Copyright Line does not match the current year == Using lowercase 'not' together with uppercase 'MUST', 'SHALL', 'SHOULD', or 'RECOMMENDED' is not an accepted usage according to RFC 2119. Please use uppercase 'NOT' together with RFC 2119 keywords (if that is what you mean). Found 'SHOULD not' in this paragraph: When in chapter 3, 4, and 5 a field of the ASN.1 syntax as defined in RFC 4210 [RFC4210] and RFC 4211 [RFC4211] is not explicitly specified, it SHOULD not be used by the sending entity. The receiving entity MUST NOT require its absence and if present MUST gracefully handle its presence. == Using lowercase 'not' together with uppercase 'MUST', 'SHALL', 'SHOULD', or 'RECOMMENDED' is not an accepted usage according to RFC 2119. Please use uppercase 'NOT' together with RFC 2119 keywords (if that is what you mean). Found 'SHOULD not' in this paragraph: 4 The extraCerts of the ip message MUST contain the chain of the issued certificate and root certificates SHOULD not be included and MUST NOT be trusted in any case. == Using lowercase 'not' together with uppercase 'MUST', 'SHALL', 'SHOULD', or 'RECOMMENDED' is not an accepted usage according to RFC 2119. Please use uppercase 'NOT' together with RFC 2119 keywords (if that is what you mean). Found 'MUST not' in this paragraph: The PKI component initiating the delayed enrollment MUST include the status "waiting" in the response and this response MUST not contain the newly issued certificate. When receiving a response with status "waiting" the EE MUST send a poll request to the (L)RA/CA. The PKI component that initiated the delayed enrollment MUST answers with a poll response containing a checkAfter time. This value indicates the minimum number of seconds that must elapse before the EE sends another poll request. As soon as the (L)RA/CA can provide the final response message for the initial request of the EE, it MUST provide this in response to a poll request. After receiving this response, the EE can continue the original message sequence as described in the respective section of this document, e.g., send a certConf message. == Using lowercase 'not' together with uppercase 'MUST', 'SHALL', 'SHOULD', or 'RECOMMENDED' is not an accepted usage according to RFC 2119. Please use uppercase 'NOT' together with RFC 2119 keywords (if that is what you mean). Found 'SHOULD not' in this paragraph: The (L)RA SHOULD verify the protection, the syntax, the required message fields, the message type, and if applicable the authorization and the proof-of-possession of the message. Additional checks or actions MAY be applied depending on the PKI solution requirements and concept. If one of these verification procedures fails, the (L)RA SHOULD respond with a negative response message and SHOULD not forward the message further upstream. General error conditions should be handled as described in Section 5.3 and Section 6.3. == Using lowercase 'not' together with uppercase 'MUST', 'SHALL', 'SHOULD', or 'RECOMMENDED' is not an accepted usage according to RFC 2119. Please use uppercase 'NOT' together with RFC 2119 keywords (if that is what you mean). Found 'SHOULD not' in this paragraph: An (L)RA SHOULD not change the received message if not necessary. The (L)RA SHOULD only update the message protection if it is technically necessary. Concrete PKI system specifications may define in more detail if and when to do so. -- The document date (December 31, 2019) is 1578 days in the past. Is this intentional? Checking references for intended status: Proposed Standard ---------------------------------------------------------------------------- (See RFCs 3967 and 4897 for information about using normative references to lower-maturity documents in RFCs) == Outdated reference: A later version (-03) exists of draft-brockhaus-lamps-cmp-updates-01 -- Possible downref: Normative reference to a draft: ref. 'I-D.brockhaus-lamps-cmp-updates' ** Downref: Normative reference to an Informational RFC: RFC 2986 ** Obsolete normative reference: RFC 5785 (Obsoleted by RFC 8615) == Outdated reference: A later version (-45) exists of draft-ietf-anima-bootstrapping-keyinfra-31 -- Obsolete informational reference (is this intentional?): RFC 2818 (Obsoleted by RFC 9110) -- Obsolete informational reference (is this intentional?): RFC 5246 (Obsoleted by RFC 8446) Summary: 2 errors (**), 0 flaws (~~), 8 warnings (==), 4 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 Internet Engineering Task Force H. Brockhaus 3 Internet-Draft S. Fries 4 Intended status: Standards Track D. von Oheimb 5 Expires: July 3, 2020 Siemens 6 December 31, 2019 8 Lightweight CMP Profile 9 draft-brockhaus-lamps-lightweight-cmp-profile-02 11 Abstract 13 The goal of this document is to facilitate interoperability and 14 automation by profiling the Certificate Management Protocol (CMP) 15 version 2 and the related Certificate Request Message Format (CRMF) 16 version 2 and the HTTP Transfer for the Certificate Management 17 Protocol. It specifies a subset of CMP and CRMF focusing on typical 18 uses cases relevant for managing certificates of devices in many 19 industrial and IoT scenarios. To limit the overhead of certificate 20 management for more constrained devices only the most crucial types 21 of transactions are specified as mandatory. To foster 22 interoperability also in more complex scenarios, other types of 23 transactions are specified as recommended or optional. 25 Status of This Memo 27 This Internet-Draft is submitted in full conformance with the 28 provisions of BCP 78 and BCP 79. 30 Internet-Drafts are working documents of the Internet Engineering 31 Task Force (IETF). Note that other groups may also distribute 32 working documents as Internet-Drafts. The list of current Internet- 33 Drafts is at https://datatracker.ietf.org/drafts/current/. 35 Internet-Drafts are draft documents valid for a maximum of six months 36 and may be updated, replaced, or obsoleted by other documents at any 37 time. It is inappropriate to use Internet-Drafts as reference 38 material or to cite them other than as "work in progress." 40 This Internet-Draft will expire on July 3, 2020. 42 Copyright Notice 44 Copyright (c) 2019 IETF Trust and the persons identified as the 45 document authors. All rights reserved. 47 This document is subject to BCP 78 and the IETF Trust's Legal 48 Provisions Relating to IETF Documents 49 (https://trustee.ietf.org/license-info) in effect on the date of 50 publication of this document. Please review these documents 51 carefully, as they describe your rights and restrictions with respect 52 to this document. Code Components extracted from this document must 53 include Simplified BSD License text as described in Section 4.e of 54 the Trust Legal Provisions and are provided without warranty as 55 described in the Simplified BSD License. 57 Table of Contents 59 1. History of changes . . . . . . . . . . . . . . . . . . . . . 3 60 2. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 5 61 2.1. Motivation for profiling CMP . . . . . . . . . . . . . . 5 62 2.2. Motivation for a lightweight profile for CMP . . . . . . 6 63 2.3. Existing CMP profiles . . . . . . . . . . . . . . . . . . 7 64 2.4. Compatibility with existing CMP profiles . . . . . . . . 7 65 2.5. Scope of this document . . . . . . . . . . . . . . . . . 8 66 2.6. Structure of this document . . . . . . . . . . . . . . . 9 67 2.7. Convention and Terminology . . . . . . . . . . . . . . . 9 68 3. Architecture and use cases . . . . . . . . . . . . . . . . . 10 69 3.1. Solution architecture . . . . . . . . . . . . . . . . . . 10 70 3.2. Basic generic CMP message content . . . . . . . . . . . . 12 71 3.3. Supported use cases . . . . . . . . . . . . . . . . . . . 12 72 3.3.1. Mandatory use cases . . . . . . . . . . . . . . . . . 12 73 3.3.2. Recommended Use Cases . . . . . . . . . . . . . . . . 12 74 3.3.3. Optional use cases . . . . . . . . . . . . . . . . . 13 75 3.4. CMP message transport . . . . . . . . . . . . . . . . . . 13 76 4. Generic parts of the PKI message . . . . . . . . . . . . . . 14 77 4.1. General description of the CMP message header . . . . . . 15 78 4.2. General description of the CMP message protection . . . . 17 79 4.3. General description of CMP message extraCerts . . . . . . 17 80 5. End Entity focused certificate management use cases . . . . . 18 81 5.1. Requesting a new certificate from a PKI . . . . . . . . . 18 82 5.1.1. A certificate from a new PKI with signature 83 protection . . . . . . . . . . . . . . . . . . . . . 20 84 5.1.2. A certificate from a trusted PKI with signature 85 protection . . . . . . . . . . . . . . . . . . . . . 26 86 5.1.3. Update an existing certificate with signature 87 protection . . . . . . . . . . . . . . . . . . . . . 26 88 5.1.4. A certificate from a PKI with MAC protection . . . . 27 89 5.1.5. A certificate from a legacy PKI using PKCS#10 request 29 90 5.1.6. Generate the key pair centrally at the (L)RA/CA . . . 31 91 5.1.6.1. Using symmetric key-encryption key management 92 technique . . . . . . . . . . . . . . . . . . . . 35 93 5.1.6.2. Using key agreement key management technique . . 36 94 5.1.6.3. Using key transport key management technique . . 37 95 5.1.7. Delayed enrollment . . . . . . . . . . . . . . . . . 38 96 5.2. Revoking a certificate . . . . . . . . . . . . . . . . . 43 97 5.3. Error reporting . . . . . . . . . . . . . . . . . . . . . 45 98 5.4. Support messages . . . . . . . . . . . . . . . . . . . . 47 99 5.4.1. General message and response . . . . . . . . . . . . 47 100 5.4.2. Get CA certiificates . . . . . . . . . . . . . . . . 49 101 5.4.3. Get root CA certificate update . . . . . . . . . . . 49 102 5.4.4. Get certificate request parameters . . . . . . . . . 51 103 5.4.5. Get certificate management configuration . . . . . . 52 104 5.4.6. Get enrollment voucher . . . . . . . . . . . . . . . 54 105 6. LRA and RA focused certificate management use cases . . . . . 55 106 6.1. Forwarding of messages . . . . . . . . . . . . . . . . . 55 107 6.1.1. Not changing protection . . . . . . . . . . . . . . . 57 108 6.1.2. Replacing protection . . . . . . . . . . . . . . . . 58 109 6.1.2.1. Keeping proof-of-possession . . . . . . . . . . . 58 110 6.1.2.2. Breaking proof-of-possession . . . . . . . . . . 59 111 6.1.3. Adding Protection . . . . . . . . . . . . . . . . . . 59 112 6.1.4. Initiating delayed enrollment . . . . . . . . . . . . 59 113 6.2. Revoking certificates on behalf of another's entities . . 59 114 6.3. Error reporting . . . . . . . . . . . . . . . . . . . . . 60 115 7. CMP message transport variants . . . . . . . . . . . . . . . 61 116 7.1. HTTP transport . . . . . . . . . . . . . . . . . . . . . 61 117 7.2. HTTPS transport using certificates . . . . . . . . . . . 63 118 7.3. HTTPS transport using shared secrets . . . . . . . . . . 63 119 7.4. File-based transport . . . . . . . . . . . . . . . . . . 64 120 7.5. CoAP transport . . . . . . . . . . . . . . . . . . . . . 64 121 7.6. Piggybacking on other reliable transport . . . . . . . . 64 122 8. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 64 123 9. Security Considerations . . . . . . . . . . . . . . . . . . . 64 124 10. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 64 125 11. References . . . . . . . . . . . . . . . . . . . . . . . . . 65 126 11.1. Normative References . . . . . . . . . . . . . . . . . . 65 127 11.2. Informative References . . . . . . . . . . . . . . . . . 66 128 Appendix A. Additional Stuff . . . . . . . . . . . . . . . . . . 68 129 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 68 131 1. History of changes 133 Note: This section will be deleted in the final version of the 134 document. Be aware that the nubering of references in CDATA-sections 135 (e.g., ASN.1 syntax) of this document do not take the existence of 136 the 'History of changes' section into account. As long as it is part 137 of this document, the numbering of references in CDATA-sections have 138 to be incremented by one to refer to the intended section of this 139 document. 141 From version 01 -> 02: 143 o Added some clarification on the key management techniques for 144 protection of centrally generated keys in Section 5.1.6. 146 o Added some clarifications on the certificates for root CA 147 certificate update in Section 5.4.3. 149 o Added a section to specify the usage of nested messages for RAs to 150 add an additional protection for further discussion, see 151 Section 6.1.3. 153 o Added a table containing endpoints for HTTP transport in 154 Section 7.1 to simplify addressing PKI management entities. 156 o Added some ToDos resulting from discussion with Tomas Gustavson. 158 o Minor clarifications and changes in wording. 160 From version 00 -> 01: 162 o Added a section to specify the enrollment with a already trusted 163 PKI for further discussion, see Section 5.1.2. 165 o Complete specification of requesting a certificate from a legacy 166 PKI using a PKCS#10 [RFC2986] request in Section 5.1.5. 168 o Complete specification of adding central generation of a key pair 169 on behalf of an end entity in Section 5.1.6. 171 o Complete specification of handling delayed enrollment due to 172 asynchronous message delivery in Section 5.1.7. 174 o Complete specification of additional support messages, e.g., to 175 update a Root CA certificate or to request an RFC 8366 [RFC8366] 176 voucher, in Section 5.4. 178 o Minor changes in wording. 180 From version draft-brockhaus-lamps-industrial-cmp-profile-00 -> 181 brockhaus-lamps-lightweight-cmp-profile-00: 183 o Change focus from industrial to more multi-purpose use cases and 184 lightweight CMP profile. 186 o Incorporate the omitted confirmation into the header specified in 187 Section 4.1 and described in the standard enrollment use case in 188 Section 5.1.1 due to discussion with Tomas Gustavsson. 190 o Change from OPTIONAL to RECOMMENDED for use case 'Revoke another's 191 entities certificate' in Section 6.2, because it is regarded as 192 important functionality in many environments to enable the 193 management station to revoke EE certificates. 195 o Complete the specification of the revocation message flow in 196 Section 5.2 and Section 6.2. 198 o The CoAP based transport mechanism and piggybacking of CMP 199 messages on top of other reliable transport protocols is out of 200 scope of this document and would need to be specified in another 201 document. 203 o Further minor changes in wording. 205 2. Introduction 207 This document specifies PKI management operations supporting machine- 208 to-machine and IoT use cases. The focus lies on maximum automation 209 and interoperable implementation of all involved PKI entities from 210 end entities (EE) through an optional Local Registration Authority 211 (LRA) and the RA up to the CA. The profile makes use of the concepts 212 and syntax specified in CMP [RFC4210], CRMF [RFC4211], HTTP transfer 213 for CMP [RFC6712], and CMP Updates [I-D.brockhaus-lamps-cmp-updates]. 214 Especially CMP and CRMF are very feature-rich standards, while only a 215 limited subset of the specified functionality is needed in many 216 environments. Additionally, the standards are not always precise 217 enough on how to interpret and implement the described concepts. 218 Therefore, we aim at tailoring and specifying in more detail how to 219 use these concepts to implement lightweight automated certificate 220 management. 222 2.1. Motivation for profiling CMP 224 CMP was standardized in 1999 and is implemented in several CA 225 products. In 2005 a completely reworked and enhanced version 2 of 226 CMP [RFC4210] and CRMF [RFC4211] has been published followed by a 227 document specifying a transfer mechanism for CMP messages using http 228 [RFC6712] in 2012. 230 Though CMP is a very solid and capable protocol it could be used more 231 widely. The most important reason for not more intense application 232 of CMP appears to be that the protocol is offering a large set of 233 features and options but being not always precise enough and leaving 234 room for interpretation. On the one hand, this makes CMP applicable 235 to a very wide range of scenarios, but on the other hand a full 236 implementation of all options is unrealistic because this would take 237 enormous effort. 239 Moreover, many details of the CMP protocol have been left open or 240 have not been specified in full preciseness. The profiles specified 241 in Appendix D and E of [RFC4210] offer some more detailed certificate 242 use cases. But the specific needs of highly automated scenarios for 243 a machine-to-machine communication are not covered sufficiently. 245 As also 3GPP and UNISG already put across, profiling is a way of 246 coping with the challenges mentioned above. To profile means to take 247 advantage of the strengths of the given protocol, while explicitly 248 narrowing down the options it provides to exactly those needed for 249 the purpose(s) at hand and eliminating all identified ambiguities. 250 In this way all the general and applicable aspects of the protocol 251 can be taken over and only the peculiarities of the target scenario 252 need to be dealt with specifically. 254 Doing such a profiling for a new target environment can be a high 255 effort because the range of available options needs to be well 256 understood and the selected options need to be consistent with each 257 other and with the intended usage scenario. Since most industrial 258 use cases typically have much in common it is worth sharing this 259 effort, which is the aim of this document. Other standardization 260 bodies can then reference the profile from this document and do not 261 need to come up with individual profiles. 263 2.2. Motivation for a lightweight profile for CMP 265 The profiles specified in Appendix D and E of CMP have been developed 266 in particular to manage certificates of human end entities. With the 267 evolution of distributed systems and client-server architectures, 268 certificates for machines and applications on them have become widely 269 used. This trend has strengthened even more in emerging industrial 270 and IoT scenarios. CMP is sufficiently flexible to support these 271 very well. 273 Today's IT security architectures for industrial solutions typically 274 use certificates for endpoint authentication within protocols like 275 IPSec, TLS, or SSH. Therefore, the security of these architectures 276 highly relies upon the security and availability of the implemented 277 certificate management procedures. 279 Due to increasing security in operational networks as well as 280 availability requirements, especially on critical infrastructures and 281 systems with a high volume of certificates, a state-of-the-art 282 certificate management must be constantly available and cost- 283 efficient, which calls for high automation and reliability. The NIST 284 Cyber Security Framework [NIST-CSFW] also refers to proper processes 285 for issuance, management, verification, revocation, and audit for 286 authorized devices, users and processes involving identity and 287 credential management. Such PKI operation according to commonly 288 accepted best practices is also required in IEC 62443-3-3 289 [IEC62443-3-3] for security level 2 up to security level 4. 291 Further challenges in many industrial systems are network 292 segmentation and asynchronous communication, where PKI operation is 293 often not deployed on-site but in a more protected environment of a 294 data center or trust center. Certificate management must be able to 295 cope with such network architectures. CMP offers the required 296 flexibility and functionality, namely self-contained messages, 297 efficient polling, and support for asynchronous message transfer with 298 end-to-end security. 300 2.3. Existing CMP profiles 302 As already stated, CMP contains profiles with mandatory and optional 303 transactions in the Appendixes D and E of [RFC4210]. Those profiles 304 focus on management of human user certificates and do only partly 305 address the specific needs for certificate management automation for 306 unattended machine or application-oriented end entities. 308 3GPP makes use of CMP [RFC4210] in its Technical Specification 133 309 310 [ETSI-3GPP] for automatic management of IPSec certificates in 310 UMTS, LTE, and 5G backbone networks. Since 2010 a dedicated CMP 311 profile for initial certificate enrollment and update transactions 312 between end entities and the RA/CA is specified in the document. 314 UNISIG has included a CMP profile for certificate enrollment in the 315 subset 137 specifying the ETRAM/ECTS on-line key management for train 316 control systems [UNISIG] in 2015. 318 Both standardization bodies use CMP [RFC4210], CRMF [RFC4211], and 319 HTTP transfer for CMP [RFC6712] to add tailored means for automated 320 certificate management for unattended machine or application-oriented 321 end entities. 323 2.4. Compatibility with existing CMP profiles 325 The profile specified in this document is compatible with CMP 326 [RFC4210] Appendixes D and E (PKI Management Message Profiles), with 327 the following exceptions: 329 o signature-based protection is the default protection; initial 330 transactions may also use HMAC, 332 o certification of a second key pair within the same transaction is 333 not supported, 335 o proof-of-possession (POPO) with self-signature of the certTemplate 336 according to [RFC4211] section 4.1 clause 3 is the recommended 337 default POPO method (deviations are possible by EEs when 338 requesting central key generation and by (L)RAs when using 339 raVerified), 341 o confirmation of newly enrolled certificates may be omitted, and 343 o all transactions consist of request-response message pairs 344 originating at the EE, i.e., announcement messages are omitted. 346 The profile specified in this document is compatible with the CMP 347 profile for UMTS, LTE, and 5G network domain security and 348 authentication framework [ETSI-3GPP], except that: 350 o protection of initial transactions may be HMAC-based, 352 o the subject name is mandatory in certificate templates, and 354 o confirmation of newly enrolled certificates may be omitted. 356 The profile specified in this document is compatible with the CMP 357 profile for on-line key management in rail networks as specified in 358 UNISIG subset-137 [UNISIG], except that: 360 o as of RFC 4210 [RFC4210] the messageTime is required to be 361 Greenwich Mean Time coded as generalizedTime (Note: While UNISIG 362 explicitely states that the messageTime in required to be 'UTC 363 time', it is not clear if this means a coding as UTCTime or 364 generalizedTime and if other time zones than Greenwich Mean Time 365 shall be allowed. Therefore UNISG may be in conflict with 366 RFC 4210 [RFC4210]. Both time formats are described in RFC 5280 367 [RFC5280] section 4.1.2.5.), and 369 o in case the request message is MAC protected, also the response, 370 certConf, and PKIconf messages have a MAC-based protection (Note: 371 if changing to signature protection of the response the caPubs 372 field cannot be used securely anymore.). 374 2.5. Scope of this document 376 This document specifies requirements on generating messages on the 377 sender side. It does not specify strictness of verification on the 378 receiving side and how in detail to handle error cases. 380 Especially on the EE side this profile aims at a lightweight protocol 381 that can be implemented on more constrained devices. On the side of 382 the central PKI management entities the profile accepts higher 383 resource needed. 385 For the sake of robustness and preservation of security properties 386 implementations should, as far as security is not affected, adhere to 387 Postel's law: "Be conservative in what you do, be liberal in what you 388 accept from others" (often reworded as: "Be conservative in what you 389 send, be liberal in what you accept"). 391 When in chapter 3, 4, and 5 a field of the ASN.1 syntax as defined in 392 RFC 4210 [RFC4210] and RFC 4211 [RFC4211] is not explicitly 393 specified, it SHOULD not be used by the sending entity. The 394 receiving entity MUST NOT require its absence and if present MUST 395 gracefully handle its presence. 397 2.6. Structure of this document 399 Chapter 2 introduces the general PKI architecture and approach to 400 certificate management using CMP that is assumed in this document. 401 Then it enlists the PKI management opertations specified in this 402 document and describes them in general words. The list of supported 403 certificate management use cases is divided into mandatory, 404 recommended, and optional ones. 406 Chapter 3 profiles the CMP message header, protection, and extraCerts 407 section as they are general elements of CMP messages. 409 Chapter 4 profiles the exchange of CMP messages between an EE and the 410 first PKI management entities. There are various flavors of 411 certificate enrollment requests optionally with polling, revocation, 412 error handling, and general support transactions. 414 Chapter 5 profiles the exchange between PKI management entities. 415 These are in the first place the forwarding of messages coming from 416 or going to an EE. This includes also initiating delayed delivery of 417 messages, which involves polling. Additionally, it specifies 418 transactions where the PKI component manages certificates on behalf 419 of an EE or for itself. 421 Chapter 6 outlines different mechanisms for CMP message transfer, 422 namely http-based transfer as already specified in [RFC6712], using 423 an additional TLS layer, or offline file-based transport. CoAP 424 [RFC7252] and piggybacking CMP messages on other protocols is out of 425 scope and left for further documents. 427 2.7. Convention and Terminology 429 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 430 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 431 document are to be interpreted as described in RFC 2119 [RFC2119]. 433 In this document, these words will appear with that interpretation 434 only when in ALL CAPS. Lower case uses of these words are not to be 435 interpreted as carrying significance described in RFC 2119. 437 Technical terminology is used in conformance with RFC 4210 [RFC4210], 438 RFC 4211 [RFC4211], RFC 5280 [RFC5280], and IEEE 802.1AR 439 [IEEE802.1AR]. The following key words are used: 441 CA: Certification authority, which issues certificates. 443 RA: Registration authority, an optional system component to which a 444 CA delegates certificate management functions such as 445 authorization checks. 447 LRA: Local registration authority, an optional RA system component 448 with proximity to the end entities. 450 KGA: Key generation authority, an optional system component, 451 typically co-located with an LRA, RA, or CA, that offers key 452 generation services to end entities. 454 EE: End entity, a user, device, or service that holds a PKI 455 certificate. An identifier for the EE is given as the subject 456 of its certificate. 458 3. Architecture and use cases 460 3.1. Solution architecture 462 Typically, a machine EE will be equipped with a manufacturer issued 463 certificate during production. Such a manufacturer issued 464 certificate is installed during production to identify the device 465 throughout its lifetime. This manufacturer certificate can be used 466 to protect the initial enrollment of operational certificates after 467 installation of the EE in a plant or industrial network. An 468 operational certificate is issued by the owner or operator of the 469 device to identify the device during operation, e.g., within a 470 security protocol like IPSec, TLS, or SSH. In IEEE 802.1AR 471 [IEEE802.1AR] a manufacturer certificate is called IDevID certificate 472 and an operational certificate is called LDevID certificate. 474 All certificate management transactions are initiated by the EE. The 475 EE creates a CMP request message, protects it using its manufacturer 476 or operational certificate, if available, and sends it to its locally 477 reachable PKI component. This PKI component may be an LRA, RA, or 478 the CA, which checks the request, responds to it itself, or forwards 479 the request upstream to the next PKI component. In case an (L)RA 480 changes the CMP request message header or body or wants to prove a 481 successful verification or authorization, it can apply a protection 482 of its own. Especially the communication between an LRA and RA can 483 be performed synchronously or asynchronously. Synchronous 484 communication describes a timely uninterrupted communication between 485 two communication partners, as asynchronous communication is not 486 performed in a timely consistent manner, e.g., because of a delayed 487 message delivery. 489 +-----+ +-----+ +-----+ +-----+ 490 | | | | | | | | 491 | EE |<---------->| LRA |<-------------->| RA |<---------->| CA | 492 | | | | | | | | 493 +-----+ +-----+ +-----+ +-----+ 495 synchronous (a)synchronous synchronous 496 +----connection----+------connection------+----connection----+ 498 on site at operators service partner 499 +----------plant---------+-----backend services-----+-trust center-+ 501 Figure 1: Certificate management on site 503 In operation environments a layered LRA-RA-CA architecture can be 504 deployed, e.g., with LRAs bundling requests from multiple EEs at 505 dedicated locations and one (or more than one) central RA aggregating 506 the requests from multiple LRAs. Every (L)RA in this scenario will 507 have its own dedicated certificate containing an extended key usage 508 as specified in CMP Updates [I-D.brockhaus-lamps-cmp-updates] and 509 private key allowing it to protect CMP messages it processes (CMP 510 signing key/certificate). The figure above shows an architecture 511 using one LRA and one RA. It is also possible to have only an RA or 512 multiple LRAs and/or RAs. Depending on the network infrastructure, 513 the communication between different PKI components may be synchronous 514 online-communication, delayed asynchronous communication, or even 515 offline file transfer. 517 As this profile focusses on specifying the pull model, where the EE 518 always requests a specific PKI management operation. CMP response 519 messages, especially in case of central key generation, as described 520 in Section 5.1.6, can also be used to deliver proactively to the EE 521 to implement the push model. 523 Third-party CAs typically implement different variants of CMP or even 524 use proprietary interfaces for certificate management. Therefore, 525 the LRA or the RA may need to adapt the exchanged CMP messages to the 526 flavor of communication required by the CA. 528 3.2. Basic generic CMP message content 530 Section 4 specifies the generic parts of the CMP messages as used 531 later in Section 5 and Section 6. 533 o Header of a CMP message; see Section 4.1. 535 o Protection of a CMP message; see Section 4.2. 537 o ExtraCerts field of a CMP message; see Section 4.3. 539 3.3. Supported use cases 541 Following the outlined scope from Section 2.5, this section gives a 542 brief overview of the certificate management use cases specified in 543 Section 5 and Section 6 and points out, if an implementation by 544 compliant EE or PKI component is mandatory, recommended or optional. 546 3.3.1. Mandatory use cases 548 The mandatory uses case in this document shall limit the overhead of 549 certificate management for more constrained devices to the most 550 crucial types of transactions. 552 Section 5 - End Entity focused certificate management use cases 554 o Request a certificate from a new PKI with signature protection; 555 see Section 5.1.1. 557 o Request to update an existing certificate with signature 558 protection; see Section 5.1.3. 560 o Error reporting; see Section 5.3. 562 Section 6 - LRA and RA focused certificate management use cases 564 o Forward messages without changes; see Section 6.1.1. 566 o Forward messages with replaced protection and raVerified as proof- 567 of-possession; see Section 6.1.2.2. 569 o Error reporting; see Section 6.3. 571 3.3.2. Recommended Use Cases 573 Additional recommended use cases shall support some more complex 574 scenarios, that are considered as beneficial for environments with 575 more specific boundary conditions. 577 Section 5 - End Entity focused certificate management use cases 579 o Request a certificate from a PKI with MAC protection; see 580 Section 5.1.4. 582 o Handle delayed enrollment due to asynchronous message delivery; 583 see Section 5.1.7. 585 < TBD: There still some discussion ongoing if this should be 586 recommended or optional. > 588 o Revoke an own certificate. 590 Section 6 - LRA and RA focused certificate management use cases 592 o Revoke another's entities certificate. 594 3.3.3. Optional use cases 596 The optional use cases support specific requirements seen only in a 597 subset of environments. 599 Section 5 - End Entity focused certificate management use cases 601 o Request a certificate from a legacy PKI using a PKCS#10 [RFC2986] 602 request; see Section 5.1.5. 604 o Add central generation of a key pair to a certificate request; see 605 Section 5.1.6. If central key generation is supported, the key 606 agreement key management technique is REQUIRED to be supported, 607 and the key transport and symmetric key-encryption key management 608 techniques are OPTIONAL. 610 o Additional support messages, e.g., to update a Root CA certificate 611 or to request an RFC 8366 [RFC8366] voucher; see Section 5.4. 613 Section 6 - LRA and RA focused certificate management use cases 615 o Initiate delayed enrollment due to asynchronous message delivery; 616 see Section 6.1.4. 618 3.4. CMP message transport 620 On different links between PKI entities, e.g., EE<->RA and RA<->CA, 621 different transport MAY be used. 623 HTTP transfer is RESOMMENDED to use for all PKI entities, but there 624 is no transport specified as mandatory to be flexible for devices 625 with special constrained to choose whatever transport is suitable. 627 Recommended transport 629 o Transfer CMP messages using HTTP; see Section 7.1. 631 Optional transport 633 o Transfer CMP messages using HTTPS with certificate-based 634 authentication; see Section 7.2. 636 o Transfer CMP messages using HTTPS with shared-secret based 637 protection; see Section 7.3. 639 o File-based CMP message transport. 641 < TBD: Motivation see Section 7.4 > 643 4. Generic parts of the PKI message 645 To reduce redundancy in the text and to ease implementation, the 646 contents of the header, protection, and extraCerts fields of the CMP 647 messages used in the transactions specified in Section 5 and 648 Section 6 are standardized to the maximum extent possible. 649 Therefore, the generic parts of a CMP message are described centrally 650 in this section. 652 As described in section 5.1 of [RFC4210], all CMP messages have the 653 following general structure: 655 +--------------------------------------------+ 656 | PKIMessage | 657 | +----------------------------------------+ | 658 | | header | | 659 | +----------------------------------------+ | 660 | +----------------------------------------+ | 661 | | body | | 662 | +----------------------------------------+ | 663 | +----------------------------------------+ | 664 | | protection (OPTIONAL) | | 665 | +----------------------------------------+ | 666 | +----------------------------------------+ | 667 | | extraCerts (OPTIONAL) | | 668 | +----------------------------------------+ | 669 +--------------------------------------------+ 671 Figure 2: CMP message structure 673 The general contents of the message header, protection, and 674 extraCerts fields are specified in the Section 4.1 to Section 4.3. 676 In case a specific CMP message needs different contents in the 677 header, protection, or extraCerts fields, the differences are 678 described in the respective message. 680 The CMP message body contains the message-specific information. It 681 is described in the context of Section 5 and Section 6. 683 The behavior in case an error occurs while handling a CMP message is 684 described in Section 6.3. 686 4.1. General description of the CMP message header 688 This section describes the generic header field of all CMP messages 689 with signature-based protection. The only variations described here 690 are in the fields recipient, transactionID, and recipNonce of the 691 first message of a transaction. 693 In case a message has MAC-based protection the changes are described 694 in the respective section. The variations will affect the fields 695 sender, protectionAlg, and senderKID. 697 For requirements about proper random number generation please refer 698 to [RFC4086]. Any message-specific fields or variations are 699 described in the respective sections of this chapter. 701 header 702 pvno REQUIRED 703 -- MUST be set to 2 to indicate CMP V2 704 sender REQUIRED 705 -- MUST be the subject of the signing certificate used for 706 -- protection of this message 707 recipient REQUIRED 708 -- MUST be the name of the intended recipient 709 -- If this is the first message of a transaction: SHOULD be the 710 -- subject of the issuing CA certificate 711 -- In all other messages: SHOULD be the same name as in the 712 -- sender field of the previous message in this transaction 713 messageTime RECOMMENDED 714 -- MUST be the time at which the message was produced, if 715 -- present 716 protectionAlg REQUIRED 717 -- MUST be the algorithm identifier of the signature or algorithm 718 -- id-PasswordBasedMac algorithm used for calculation of the 719 -- protection bits 720 -- The signature algorithm MUST be consistent with the 721 -- SubjectPublicKeyInfo field of the signer's certificate 722 -- The hash algorithm used SHOULD be SHA-256 723 algorithm REQUIRED 724 -- MUST be the OID of the signature algorithm, like 725 -- sha256WithRSAEncryption or ecdsa-with-SHA256, or 726 -- id-PasswordBasedMac 727 senderKID RECOMMENDED 728 -- MUST be the SubjectKeyIdentifier, if available, of the 729 -- certificate used for protecting this message 730 transactionID REQUIRED 731 -- If this is the first message of a transaction: 732 -- MUST be 128 bits of random data for the start of a 733 -- transaction to reduce the probability of having the 734 -- transactionID already in use at the server 735 -- In all other messages: 736 -- MUST be the value from the previous message in the same 737 -- transaction 738 senderNonce REQUIRED 739 -- MUST be fresh 128 random bits 740 recipNonce RECOMMENDED 741 -- If this is the first message of a transaction: SHOULD be 742 -- absent 743 -- In all other messages: MUST be present and contain the value 744 -- from senderNonce of the previous message in the same 745 -- transaction 746 generalInfo OPTIONAL 747 implicitConfirm OPTIONAL 748 ImplicitConfirmValue REQUIRED 750 -- The field is optional though it only applies to 751 -- ir/cr/kur/p10cr requests and ip/cp/kup responses 752 -- ImplicitConfirmValue of the request message MUST be NULL if 753 -- the EE wants to request not to send a confirmation message 754 -- ImplicitConfirmValue MUST be set to NULL if the (L)RA/CA wants 755 -- to grant not sending a confirmation message 757 4.2. General description of the CMP message protection 759 This section describes the generic protection field of all CMP 760 messages with signature-based protection. 762 protection REQUIRED 763 -- MUST contain the signature calculated using the signature 764 -- algorithm specified in protectionAlg 766 Only for MAC-based protection major differences apply as described in 767 the respective message. 769 The CMP message protection provides, if available, message origin 770 authentication and integrity protection for the CMP message header 771 and body. The CMP message extraCerts is not covered by this 772 protection. 774 NOTE: The requirements for checking certificates given in [RFC5280] 775 MUST be followed for the CMP message protection. In case the CMP 776 signer certificates is not the CA certificate that signed the newly 777 issued certificate, certificate status checking SHOULD be used for 778 the CMP signer certificates of communication partners. 780 4.3. General description of CMP message extraCerts 782 This section describes the generic extraCerts field of all CMP 783 messages with signature-based protection. 785 extraCerts RECOMMENDED 786 -- SHOULD contain the signing certificate together with its 787 -- chain, if needed 788 -- If present, the first certificate in this field MUST 789 -- be the certificate used for signing this message 790 -- Self-signed certificates SHOULD NOT be included in 791 -- extraCerts and MUST NOT be trusted based on the listing in 792 -- extraCerts in any case 794 5. End Entity focused certificate management use cases 796 This chapter focuses on the communication of the EE and the first PKI 797 component it talks to. Depending on the network and PKI solution, 798 this will either be the LRA, the RA or the CA. 800 Profiles of the Certificate Management Protocol (CMP) [RFC4210] 801 handled in this chapter cover the following certificate management 802 use cases: 804 o Requesting a certificate from a PKI with variations like initial 805 requests and updating, central key generation and different 806 protection means 808 o Revocation of a certificate 810 o General messages for further support functions 812 The use cases mainly specify the message body of the CMP messages and 813 utilize the specification of the message header, protection and 814 extraCerts as specified in Section 5. 816 The behavior in case an error occurs is described in Section 5.3. 818 This chapter is aligned to Appendix D and Appendix E of [RFC4210]. 819 The general rules for interpretation stated in Appendix D.1 in 820 [RFC4210] need to be applied here, too. 822 This document does not mandate any specific supported algorithms like 823 Appendix D.2 of [RFC4210], [ETSI-3GPP], and [UNISIG] do. Using the 824 message sequences described here require agreement upon the 825 algorithms to support and thus the algorithm identifiers for the 826 specific target environment. 828 5.1. Requesting a new certificate from a PKI 830 There are different approaches to request a certificate from a PKI. 832 These approaches differ on the one hand in the way the EE can 833 authenticate itself to the PKI it wishes to get a new certificate 834 from and on the other hand in its capabilities to generate a proper 835 new key pair. The authentication means may be as follows: 837 o Using a certificate from a trusted PKI and the corresponding 838 private key, e.g., a manufacturer certificate 840 o Using the certificate to be updated and the corresponding private 841 key 843 o Using a shared secret known to the EE and the PKI 845 Typically, such EE requests a certificate from a CA. When the (L)RA/ 846 CA responds with a message containing a certificate, the EE MUST 847 reply with a confirmation message. The (L)RA/CA then MUST send 848 confirmation back, closing the transaction. 850 The message sequences in this section allow the EE to request 851 certification of a locally generated public-private key pair. For 852 requirements about proper random number and key generation please 853 refer to [RFC4086]. The EE MUST provide a signature-based proof-of- 854 possession of the private key associated with the public key 855 contained in the certificate request as defined by [RFC4211] section 856 4.1 case 3. To this end it is assumed that the private key can 857 technically be used as signing key. The most commonly used 858 algorithms are RSA and ECDSA, which can technically be used for 859 signature calculation regardless of potentially intended restrictions 860 of the key usage. 862 The requesting EE provides the binding of the proof-of-possession to 863 its identity by signature-based or MAC-based protection of the CMP 864 request message containing that POPO. The (L)RA/CA needs to verify 865 whether this EE is authorized to obtain a certificate with the 866 requested subject and other attributes and extensions. Especially 867 when removing the protection provided by the EE and applying a new 868 protection the (L)RA MUST verify in particular the included proof-of- 869 possession self-signature of the certTemplate using the public key of 870 the requested certificate and MUST check that the EE, as 871 authenticated by the message protection, is authorized to request a 872 certificate with the subject as specified in the certTemplate (see 873 Section 6.1.2). 875 There are several ways to install the Root CA certificate of a new 876 PKI on an EE. The installation can be performed in an out-of-band 877 manner, using general messages, a voucher [RFC8366], or other formats 878 for enrolment, or in-band of CMP by the caPubs field in the 879 certificate response message. In case the installation of the new 880 Root CA certificate is performed using the caPubs field, the 881 certificate response message MUST be properly authenticated, and the 882 sender of this message MUST be authorized to install new Root CA 883 certificates on the EE. This authorization MUST be indicated by the 884 extended key usage in the (L)RA/CA certificate as specified in CMP 885 Updates [I-D.brockhaus-lamps-cmp-updates]. 887 5.1.1. A certificate from a new PKI with signature protection 889 This message sequence should be used by an EE to request a 890 certificate of a new PKI using an existing certificate from an 891 external PKI, e.g., a manufacturer certificate, to prove its identity 892 to the new PKI. The EE already has established trust in this new PKI 893 it is about to enroll to, e.g., by configuration means. The 894 initialization request message is signature-protected using the 895 existing certificate. 897 Preconditions: 899 1 The EE MUST have a certificate enrolled by an external PKI in 900 advance to this transaction to authenticate itself to the (L)RA/CA 901 using signature-based protection, e.g., using a manufacturer 902 certificate. 904 2 The EE SHOULD know the subject name of the new CA it requests a 905 certificate from; this name MAY be established using an enrollment 906 voucher or other configuration means. If the EE does not know the 907 name of the CA, the (L)RA/CA MUST know where to route this request 908 to. 910 3 The EE MUST authenticate responses from the (L)RA/CA; trust MAY be 911 established using an enrollment voucher or other configuration 912 means 914 4 The (L)RA/CA MUST trust the external PKI the EE uses to 915 authenticate itself; trust MAY be established using some 916 configuration means 918 This message sequence is like that given in [RFC4210] Appendix E.7. 920 Message flow: 922 Step# EE (L)RA/CA 923 1 format ir 924 2 -> ir -> 925 3 handle, re-protect or 926 forward ir 927 4 format or receive ip 928 5 possibly grant implicit 929 confirm 930 6 <- ip <- 931 7 handle ip 932 8 In case of status 933 "rejection" in the 934 ip message, no certConf 935 and pkiConf are sent 936 9 format certConf (optional) 937 10 -> certConf -> 938 11 handle, re-protect or 939 forward certConf 940 12 format or receive PKIConf 941 13 <- pkiConf <- 942 14 handle pkiConf (optional) 944 For this message sequence the EE MUST include exactly one single 945 CertReqMsg in the ir. If more certificates are required, further 946 requests MUST be sent using separate CMP Messages. If the EE wants 947 to omit sending a certificate confirmation message after receiving 948 the ip to reduce the number of protocol messages exchanged in a 949 transaction, it MUST request this by setting the implicitControlValue 950 in the ir to NULL. 952 If the CA accepts the request it MUST return the new certificate in 953 the certifiedKeyPair field of the ip message. If the EE requested to 954 omit sending a certConf message after receiving the ip, the (L)RA/CA 955 MAY confirm this by also setting the implicitControlValue in the ip 956 to NULL. 958 If the EE did not request implicit confirmation or the request was 959 not granted by the (L)RA/CA the confirmation as follows MUST be 960 performed. If the EE successfully receives the certificate and 961 accepts it, the EE MUST send a certConf message, which MUST be 962 answered by the (L)RA/CA with a pkiConf message. If the (L)RA/CA 963 does not receive the expected certConf message in time it MUST handle 964 this like a rejection by the EE. 966 If the certificate request was refused by the CA, the (L)RA/CA must 967 return an ip message containing the status code "rejection" and no 968 certifiedKeyPair field. Such an ip message MUST NOT be followed by 969 the certConf and pkiConf messages. 971 Detailed message description: 973 Certification Request -- ir 975 Field Value 977 header 978 -- As described in section 3.1 980 body 981 -- The request of the EE for a new certificate 982 ir REQUIRED 983 -- MUST be exactly one CertReqMsg 984 -- If more certificates are required, further requests MUST be 985 -- packaged in separate PKI Messages 986 certReq REQUIRED 987 certReqId REQUIRED 988 -- MUST be set to 0 989 certTemplate REQUIRED 990 version OPTIONAL 991 -- MUST be 2 if supplied. 992 subject REQUIRED 993 -- MUST contain the suggested subject name of the EE 994 -- certificate 995 publicKey REQUIRED 996 algorithm REQUIRED 997 -- MUST include the subject public key algorithm ID and value 998 -- In case a central key generation is requested, this field 999 -- contains the algorithm and parameter preferences of the 1000 -- requesting entity regarding the to-be-generated key pair 1001 subjectPublicKey REQUIRED 1002 -- MUST contain the public key to be included into the requested 1003 -- certificate in case of local key-generation 1004 -- MUST contain a zero-length BIT STRING in case a central key 1005 -- generation is requested 1006 -- MUST include the subject public key algorithm ID and value 1007 extensions OPTIONAL 1008 -- MAY include end-entity-specific X.509 extensions of the 1009 -- requested certificate like subject alternative name, 1010 -- key usage, and extended key usage 1011 Popo REQUIRED 1012 POPOSigningKey OPTIONAL 1013 -- MUST be used in case subjectPublicKey contains a public key 1014 -- MUST be absent in case subjectPublicKey contains a 1015 -- zero-length BIT STRING 1016 POPOSigningKey REQUIRED 1017 poposkInput PROHIBITED 1018 -- MUST NOT be used because subject and publicKey are both 1019 -- present in the certTemplate 1020 algorithmIdentifier REQUIRED 1021 -- The signature algorithm MUST be consistent with the 1022 -- publicKey field of the certTemplate 1023 -- The hash algorithm used SHOULD be SHA-256 1024 signature REQUIRED 1025 -- MUST be the signature computed over the DER-encoded 1026 -- certTemplate 1028 protection REQUIRED 1029 -- As described in section 3.2 1031 extraCerts REQUIRED 1032 -- As described in section 3.3 1034 Certification Response -- ip 1036 Field Value 1038 header 1039 -- As described in section 3.1 1041 body 1042 -- The response of the CA to the request as appropriate 1043 ip REQUIRED 1044 caPubs OPTIONAL 1045 -- MAY be used 1046 -- If used it MUST contain only the root certificate of the 1047 -- certificate contained in certOrEncCert 1048 response REQUIRED 1049 -- MUST be exactly one CertResponse 1050 certReqId REQUIRED 1051 -- MUST be set to 0 1052 status REQUIRED 1053 -- PKIStatusInfo structure MUST be present 1054 status REQUIRED 1055 -- positive values allowed: "accepted", "grantedWithMods" 1056 -- negative values allowed: "rejection" 1057 -- In case of rejection no certConf and pkiConf messages will 1058 -- be sent 1059 statusString OPTIONAL 1060 -- MAY be any human-readable text for debugging, logging or to 1061 -- display in a GUI 1062 failInfo OPTIONAL 1064 -- MUST be present if status is "rejection" and in this case 1065 -- the transaction MUST be terminated 1066 -- MUST be absent if the status is "accepted" or 1067 -- "grantedWithMods" 1068 certifiedKeyPair OPTIONAL 1069 -- MUST be present if status is "accepted" or "grantedWithMods" 1070 -- MUST be absent if status is "rejection" 1071 certOrEncCert REQUIRED 1072 -- MUST be present when certifiedKeyPair is present 1073 certificate REQUIRED 1074 -- MUST be present when certifiedKeyPair is present 1075 -- MUST contain the newly enrolled X.509 certificate 1076 privateKey OPTIONAL 1077 -- MUST be absent in case of local key-generation 1078 -- MUST contain the encrypted private key in an EnvelopedData 1079 -- structure as specified in section 5.1.5 in case the private 1080 -- key was generated centrally 1082 protection REQUIRED 1083 -- As described in section 3.2 1085 extraCerts REQUIRED 1086 -- As described in section 3.3 1087 -- MUST contain the chain of the issued certificate 1088 -- Duplicate certificates MAY be omitted 1090 Certificate Confirmation -- certConf 1092 Field Value 1094 header 1095 -- As described in section 3.1 1097 body 1098 -- The message of the EE sends confirmation to the (L)RA/CA 1099 -- to accept or reject the issued certificates 1100 certConf REQUIRED 1101 -- MUST be exactly one CertStatus 1102 CertStatus REQUIRED 1103 certHash REQUIRED 1104 -- MUST be the hash of the certificate, using the same hash 1105 -- algorithm as used to create the certificate signature 1106 certReqId REQUIRED 1107 -- MUST be set to 0 1108 status RECOMMENDED 1109 -- PKIStatusInfo structure SHOULD be present 1110 -- Omission indicates acceptance of the indicated certificate 1111 status REQUIRED 1112 -- positive values allowed: "accepted" 1113 -- negative values allowed: "rejection" 1114 statusString OPTIONAL 1115 -- MAY be any human-readable text for debugging or logging 1116 failInfo OPTIONAL 1117 -- MUST be present if status is "rejection" 1118 -- MUST be absent if the status is "accepted" 1120 protection REQUIRED 1121 -- As described in section 3.2 1122 -- MUST use the same certificate as for protection of the ir 1124 extraCerts RECOMMENDED 1125 -- SHOULD contain the protection certificate together with its 1126 -- chain 1127 -- If present, the first certificate in this field MUST be the 1128 -- certificate used for signing this message 1129 -- Self-signed certificates SHOULD NOT be included in 1130 -- extraCerts and 1131 -- MUST NOT be trusted based on the listing in extraCerts in 1132 -- any case 1134 PKI Confirmation -- pkiConf 1136 Field Value 1138 header 1139 -- As described in section 3.1 1141 body 1142 pkiConf REQUIRED 1143 -- The content of this field MUST be NULL 1145 protection REQUIRED 1146 -- As described in section 3.2 1147 -- SHOULD use the same certificate as for protection of the ip 1149 extraCerts RECOMMENDED 1150 -- SHOULD contain the protection certificate together with its 1151 -- chain 1152 -- If present, the first certificate in this field MUST be the 1153 -- certificate used for signing this message 1154 -- Self-signed certificates SHOULD NOT be included in extraCerts 1155 -- and 1156 -- MUST NOT be trusted based on the listing in extraCerts in 1157 -- any case 1159 5.1.2. A certificate from a trusted PKI with signature protection 1161 < TBD: In case the PKI is already trusted the cr/cp messages could be 1162 used instead of ir/ip. It needs to be decided, whether an additional 1163 section should be added here, or the previous section should be 1164 extended to also cover this use case. > 1166 5.1.3. Update an existing certificate with signature protection 1168 This message sequence should be used by an EE to request an update of 1169 one of the certificates it already has and that is still valid. The 1170 EE uses the certificate it wishes to update to prove its identity and 1171 possession of the private key for the certificate to be updated to 1172 the PKI. Therefore, the key update request message is signed using 1173 the certificate that is to be updated. 1175 The general message flow for this message sequence is the same as 1176 given in Section 5.1.1. 1178 Preconditions: 1180 1 The certificate the EE wishes to update MUST NOT be expired or 1181 revoked. 1183 2 A new public-private key pair SHOULD be used. 1185 The message sequence for this exchange is like that given in 1186 [RFC4210] Appendix D.6. 1188 The message sequence for this exchange is identical to that given in 1189 Section 5.1.1, with the following changes: 1191 1 The body of the first request and response MUST be kur and kup, 1192 respectively. 1194 2 Protection of the kur MUST be performed using the certificate to 1195 be updated. 1197 3 The subject field of the CertTemplate MUST contain the subject 1198 name of the existing certificate to be updated, without 1199 modifications. 1201 4 The CertTemplate MUST contain the subject, issuer and publicKey 1202 fields only. 1204 5 The regCtrl OldCertId SHOULD be used to make clear, even in case 1205 an (L)RA changes the message protection, which certificate is to 1206 be. 1208 6 The caPubs field in the kup message MUST be absent. 1210 As part of the certReq structure of the kur the control is added 1211 right after the certTemplate. 1213 controls 1214 type RECOMMENDED 1215 -- MUST be the value id-regCtrl-oldCertID, if present 1216 value 1217 issuer REQUIRED 1218 serialNumber REQUIRED 1219 -- MUST contain the issuer and serialNumber of the certificate 1220 -- to be updated 1222 5.1.4. A certificate from a PKI with MAC protection 1224 This message sequence should be used by an EE to request a 1225 certificate of a new PKI without having a certificate to prove its 1226 identity to the target PKI, but there is a shared secret established 1227 between the EE and the PKI. Therefore, the initialization request is 1228 MAC-protected using this shared secret. The (L)RA checking the MAC- 1229 protection SHOULD replace this protection according to Section 6.1.2 1230 in case the next hop does not know the shared secret. 1232 For requirements with regard to proper random number and key 1233 generation please refer to [RFC4086]. 1235 The general message flow for this message sequence is the same as 1236 given in Section 5.1.1. 1238 Preconditions: 1240 1 The EE and the (L)RA/CA MUST share a symmetric key, this MAY be 1241 established by a service technician during initial local 1242 configuration. 1244 2 The EE SHOULD know the subject name of the new CA it requests a 1245 certificate from; this name MAY be established using an enrollment 1246 voucher or other configuration means. If the EE does not know the 1247 name of the CA, the (L)RA/CA MUST know where to route this request 1248 to. 1250 3 The EE MUST authenticate responses from the (L)RA/CA; trust MAY be 1251 established using the shared symmetric key. 1253 The message sequence for this exchange is like that given in 1254 [RFC4210] Appendix D.4. 1256 The message sequence for this exchange is identical to that given in 1257 Section 5.1.1, with the following changes: 1259 1 The protection of all messages MUST be calculated using Message 1260 Authentication Code (MAC); the protectionAlg field MUST be id- 1261 PasswordBasedMac as described in section 5.1.3.1 of [RFC4210]. 1263 2 The sender MUST contain a name representing the originator of the 1264 message. The senderKID MUST contain a reference all participating 1265 entities can use to identify the symmetric key used for the 1266 protection. 1268 3 The extraCerts of the ir, certConf, and PKIConf messages MUST be 1269 absent. 1271 4 The extraCerts of the ip message MUST contain the chain of the 1272 issued certificate and root certificates SHOULD not be included 1273 and MUST NOT be trusted in any case. 1275 Part of the protectionAlg structure, where the algorithm identifier 1276 MUST be id-PasswordBasedMac, is a PBMParameter sequence. The fields 1277 of PBMParameter SHOULD remain constant for message protection 1278 throughout this certificate management transaction to reduce the 1279 computational overhead. 1281 PBMParameter REQUIRED 1282 salt REQUIRED 1283 -- MUST be the random value to salt the secret key 1284 owf REQUIRED 1285 -- MUST be the algorithm identifier for the one-way function 1286 -- used 1287 -- The one-way function SHA-1 MUST be supported due to 1288 -- [RFC4211] requirements, but SHOULD NOT be used any more 1289 -- SHA-256 SHOULD be used instead 1290 iterationCount REQUIRED 1291 -- MUST be a limited number of times the OWF is applied 1292 -- To prevent brute force and dictionary attacks a reasonable 1293 -- high number SHOULD be used 1294 mac REQUIRED 1295 -- MUST be the algorithm identifier of the MAC algorithm used 1296 -- The MAC function HMAC-SHA1 MUST be supported due to 1297 -- [RFC4211] requirements, but SHOULD NOT be used any more 1298 -- HMAC-SHA-256 SHOULD be used instead 1300 < TBD: SHA-1 is no collision resistant hash algorithm. Even though 1301 this capability is not required for HMAC calculation, it is 1302 recommended to switch to SHA-2 algorithms. As I am no crypto expert, 1303 I am uncertain if collision resistance required for owf to derive a 1304 shared secret. Anyhow, I would recommend using SHA-256 as owf and 1305 HMAC-SHA-256 as mac also for simplicity of implementation. What do 1306 others think? > 1308 5.1.5. A certificate from a legacy PKI using PKCS#10 request 1310 This message sequence should be used by an EE to request a 1311 certificate of a legacy PKI only capable to process PKCS#10 [RFC2986] 1312 certification requests. The EE can prove its identity to the target 1313 PKI by using various protection means as described in Section 5.1.1 1314 or Section 5.1.4. 1316 In contrast to the other transactions described in Section 5.1, this 1317 transaction uses PKCS#10 [RFC2986] instead of CRMF [RFC4211] for the 1318 certificate request for compatibility reasons with legacy CA systems 1319 that require a PKCS#10 certificate request and cannot process CMP 1320 [RFC4210] or CRMF [RFC4211] messages. In such case the (L)RA must 1321 extract the PKCS#10 certificate request from the p10cr and provides 1322 it separately to the CA. 1324 The general message flow for this message sequence is the same as 1325 given in Section 5.1.1, but the public key is contained in the 1326 subjectPKInfo of the PKCS#10 certificate request. 1328 Preconditions: 1330 1 The EE MUST either have a certificate enrolled from this or any 1331 other accepted PKI, or a shared secret known to the PKI and the EE 1332 to authenticate itself to the (L)RA/CA. 1334 2 The EE SHOULD know the subject name of the CA it requests a 1335 certificate from; this name MAY be established using an enrollment 1336 voucher or other configuration means. If the EE does not know the 1337 name of the CA, the (L)RA/CA MUST know where to route this request 1338 to. 1340 3 The EE MUST authenticate responses from the (L)RA/CA; trust MAY be 1341 established by an available root certificate, using an enrollment 1342 voucher, or other configuration means. 1344 4 The (L)RA/CA MUST trust the current or the PKI the EE uses to 1345 authenticate itself; trust MAY be established by a corresponding 1346 available root certificate or using some configuration means. 1348 The profile for this exchange is identical to that given in 1349 Section 5.1.1, with the following changes: 1351 1 The body of the first request and response MUST be p10cr and cp, 1352 respectively. 1354 2 The subject name of the CA MUST be in the recipient field of the 1355 p10cr message header. 1357 3 The certReqId in the cp message MUST be 0. 1359 4 The caPubs field in the cp message SHOULD be absent. 1361 Detailed description of the p10cr message: 1363 Certification Request -- p10cr 1365 Field Value 1367 header 1368 -- As described in section 3.1 1370 body 1371 -- The request of the EE for a new certificate using a PKCS#10 1372 -- certificate request 1373 p10cr REQUIRED 1374 CertificationRequestInfo REQUIRED 1375 version REQUIRED 1376 -- MUST be set to 0 to indicate PKCS#10 V1.7 1377 subject REQUIRED 1378 -- MUST contain the suggested subject name of the EE 1379 subjectPKInfo REQUIRED 1380 -- MUST include the subject public key algorithm ID and value 1381 attributes OPTIONAL 1382 -- MAY contain a set of end-entity-specific attributes or X.509 1383 -- extensions to be included in the requested certificate or used 1384 -- otherwise 1385 signatureAlgorithm REQUIRED 1386 -- The signature algorithm MUST be consistent with the 1387 -- subjectPKInfo field. The hash algorithm used SHOULD be SHA-256 1388 signature REQUIRED 1389 -- MUST containing the self-signature for proof-of-possession 1391 protection REQUIRED 1392 -- As described in section 3.2 1394 extraCerts REQUIRED 1395 -- As described in section 3.3 1397 5.1.6. Generate the key pair centrally at the (L)RA/CA 1399 This functional extension can be applied in combination with 1400 certificate enrollment as described in Section 5.1.1 and 1401 Section 5.1.4. The functional extension can be used in case an EE is 1402 not abele or is not willing to generate is't new public-private key 1403 pair itself. It is a matter of the local implementation which 1404 central PKI components will perform the key generation. This 1405 component must have a proper (L)RA/CA certificate containing the 1406 additional extended key usage id-kp-cmcKGA to be identified by the EE 1407 as a legitimate key-generation instance. In case the (L)RA generated 1408 the new key pair for the EE, it can use Section 5.1.1 to 1409 Section 5.1.4 to request the certificate for this key pair as usual. 1411 Generally speaking, in a machine-to-machine scenario it is strongly 1412 preferable to generate public-private key pairs locally at the EE. 1413 Together with proof-of-possession of the private key in the 1414 certification request, this is to make sure that only the entity 1415 identified in the newly issued certificate is the only entity who 1416 ever hold the private key. 1418 There are some cases where an EE is not able or not willing to 1419 locally generate the new key pair. Reasons for this may be the 1420 following: 1422 o Lack of sufficient initial entropy. 1424 Note: Good random numbers are not only needed for key generation, but 1425 also for session keys and nonces in any security protocol. 1426 Therefore, we believe that a decent security architecture should 1427 anyways support good random number generation on the EE side or 1428 provide enough entropy for the RNG seed during manufacturing to 1429 guarantee good initial pseudo-random number generation. 1431 o Due to lack of computational resources, e.g., in case of RSA keys. 1433 Note: As key generation can be performed in advance to the 1434 certificate enrollment communication, it is typical not time 1435 critical. 1437 Note: Besides the initial enrollment right after the very first 1438 bootup of the device, where entropy available on the device may be 1439 insufficient, we do not see any good reason for central key 1440 generation. 1442 Note: As mentioned in Section 3.1 central key generation may be 1443 required in a push model, where the certificate response message is 1444 transfered by the (L)RA/CA to the EE without receiving a previos 1445 request message. 1447 If the EE wishes to request central key generation, it MUST fill the 1448 subjectPublicKey field in the certTemplate structure of the request 1449 message with a zero-length BIT STRING. This indicates to the (L)RA/ 1450 CA that a new key pair shall be generated centrally on behalf of the 1451 EE. 1453 Note: As the protection of centrally generated keys in the response 1454 message is being extended from EncryptedValue to EncryptedKey by CMP 1455 Updates [I-D.brockhaus-lamps-cmp-updates] also the alternative 1456 EnvelopedData can be used. In CRMF Section 2.1.9 [RFC4211] the use 1457 of EncryptedValue has been deprecated in favor of the EnvelopedData 1458 structure. Therefore, this profile specifies using EnvelopedData as 1459 specified in CMS Section 6 [RFC5652] to offer more crypto agility. 1461 +------------------------------+ 1462 | EnvelopedData | 1463 | [RFC5652] section 6 | 1464 | +--------------------------+ | 1465 | | SignedData | | 1466 | | [RFC5652] section 5 | | 1467 | | +----------------------+ | | 1468 | | | privateKey | | | 1469 | | | OCTET STRING | | | 1470 | | +----------------------+ | | 1471 | +--------------------------+ | 1472 +------------------------------+ 1474 Figure 3: Encrypted private key container 1476 The (L)RA/CA delivers the private key in the privateKey field in the 1477 certifiedKeyPair structure of the response message also containing 1478 the newly issued certificate. 1480 The private key MUST be wrapped in a SignedData structure, as 1481 specified in CMS Section 5 [RFC5652], signed by the KGA generating 1482 the key pair. The signature MUST be performed using a CMP signer 1483 certificate asserting the extended key usage kp-id-cmpKGA as 1484 described in CMP Updates [I-D.brockhaus-lamps-cmp-updates] to show 1485 the authorization to generate key pairs on behalf of an EE. 1487 This SignedData structure MUST be wrapped in an EnvelopedData 1488 structure, as specified in CMS Section 6 [RFC5652], encrypting it 1489 using a newly generated symmetric content-encryption key. 1491 Note: Instead of the specification in CMP Appendix D 4.4 [RFC4210] 1492 this content-encryption key is not generated on the EE side. As we 1493 just mentioned, central key generation should only be used in this 1494 profile in case of lack of randomness on the EE. 1496 As part of the EnvelopedData structure this content-encryption key 1497 MUST be securely provided to the EE using one of three key management 1498 techniques. The choice of the key management technique to be used by 1499 the (L)RA/CA depends on the authentication mechanism the EE choose to 1500 protect the request message, see CMP Updates section 3.4 1501 [I-D.brockhaus-lamps-cmp-updates] for more details on which key 1502 management technique to use. 1504 o MAC protected request message: The content-encryption key SHALL be 1505 protected using the symmetric key-encryption key management 1506 technique, see Section 5.1.6.1, only if the EE used MAC protection 1507 for the respected request message. 1509 o Signature protected request message using a certificate that 1510 contains a key usage extension asserting keyAgreement: The 1511 content-encryption key SHALL be protected using the key agreement 1512 key management technique, see Section 5.1.6.2, if the certificate 1513 used by the EE for signing the respective request message contains 1514 the key usage keyAgreement. If the certificate also contains the 1515 key usage keyEncipherment, the key transport key management 1516 technique SHALL NOT be used. 1518 o Signature protected request message using a certificate that 1519 contains a key usage extension asserting keyEncipherment: The 1520 content-encryption key SHALL be protected using the key transport 1521 key management technique, see Section 5.1.6.3, if the certificate 1522 used by the EE for signing the respective request message contains 1523 the key usage keyEncipherment and not keyAgreement. 1525 The key agreement key management technique can be supported by most 1526 signature algorithms, as key transport key management technique can 1527 only be supported by a very limited number of algorithms. The 1528 symmetric key-encryption key management technique shall only be used 1529 in combination with MAC protection, wich is a side-line in this 1530 profile. Therfore, this profile REQUIRES support of the key 1531 agreement key management technique and the key transport and 1532 symmetric key-encryption key management techniques are OPTIONAL. 1534 For encrypting the SignedData structure containing the private key a 1535 fresh content-encryption key MUST be generated with enough entropy 1536 with regard to the used symmetric encryption algorithm. 1538 Note: Depending on the lifetime of the certificate and the 1539 criticality of the generated private key, it is advisable to use the 1540 strongest possible symmetric encryption algorithm. Therefore, this 1541 specification recommends using at least AES-256. 1543 The detailed description of the privateKey field looks like this: 1545 privateKey OPTIONAL 1546 -- MUST be an envelopedData structure as specified in 1547 -- CMS [RFC5652] section 6 1548 version REQUIRED 1549 -- MUST be set to 2 1550 recipientInfos REQUIRED 1551 -- MUST be exactly one RecipientInfo 1552 recipientInfo REQUIRED 1553 -- MUST be either KEKRecipientInfo (see section 5.1.5.1), 1554 -- KeyAgreeRecipientInfo (see section 5.1.5.2), or 1555 -- KeyTransRecipientInfo (see section 5.1.5.3) is used 1556 encryptedContentInfo 1557 REQUIRED 1558 contentType REQUIRED 1559 -- MUST be id-signedData 1560 contentEncryptionAlgorithm 1561 REQUIRED 1562 -- MUST be the algorithm identifier of the symmetric 1563 -- content-encryption algorithm used 1564 -- As private keys need long-term protection, the use of AES-256 1565 -- or a stronger symmetric algorithm is RECOMMENDED 1566 encryptedContent REQUIRED 1567 -- MUST be the encrypted signedData structure as specified in 1568 -- CMS [RFC5652] section 5 1569 version REQUIRED 1570 -- MUST be set to 3 1571 digestAlgorithms 1572 REQUIRED 1573 -- MUST be exactly one digestAlgorithm identifier 1574 digestAlgorithmIdentifier 1575 REQUIRED 1576 -- MUST be the OID of the digest algorithm used for generating 1577 -- the signature 1578 -- The hash algorithm used SHOULD be SHA-256 1579 encapContentInfo 1580 REQUIRED 1581 -- MUST be the content that is to be signed 1582 contentType REQUIRED 1583 -- MUST be id-data 1584 content REQUIRED 1585 -- MUST be the privateKey as OCTET STRING 1586 certificates REQUIRED 1587 -- SHOULD contain the signing certificate together with its chain 1588 -- If present, the first certificate in this field MUST 1589 -- be the certificate used for signing this content 1590 -- Self-signed certificates SHOULD NOT be included 1591 -- and MUST NOT be trusted based on the listing in any case 1592 crls OPTIONAL 1593 -- MAY be present to provide status information on the signer or 1594 -- its CA certificates 1595 signerInfos REQUIRED 1596 -- MUST be exactly one signerInfo 1597 version REQUIRED 1598 -- MUST be set to 3 1599 sid REQUIRED 1600 subjectKeyIdentifier 1601 REQUIRED 1602 -- MUST be the subjectKeyIdentifier of the signer's certificate 1603 digest algorithm 1604 REQUIRED 1605 -- MUST be the same OID as in digest algorithm 1606 signatureAlgorithm 1607 REQUIRED 1608 -- MUST be the algorithm identifier of the signature algorithm 1609 -- used for calculation of the signature bits, 1610 -- like sha256WithRSAEncryption or ecdsa-with-SHA256 1611 -- The signature algorithm MUST be consistent with the 1612 -- SubjectPublicKeyInfo field of the signer's certificate 1613 signature REQUIRED 1614 -- MUST be the result of the digital signature generation 1616 5.1.6.1. Using symmetric key-encryption key management technique 1618 This key management technique can be applied in combination with the 1619 message flow specified in Section 5.1.4 using MAC protected CMP 1620 messages. The shared secret used for the MAC protection MUST also be 1621 used for the encryption of the content-encryption key but with a 1622 different seed in the PBMParameter sequence. To use this key 1623 management technique the KEKRecipientInfo structure MUST be used in 1624 the contentInfo field. 1626 The KEKRecipientInfo structure included into the envelopedData 1627 structure is specified in CMS Section 6.2.3 [RFC5652]. 1629 The detailed description of the KEKRecipientInfo structure looks like 1630 this: 1632 recipientInfo REQUIRED 1633 -- MUST be KEKRecipientInfo as specified in 1634 -- CMS section 6.2.3 [RFC5652] 1635 version REQUIRED 1636 -- MUST be set to 4 1637 kekid REQUIRED 1638 keyIdentifier REQUIRED 1639 -- MUST contain the same value as the senderKID in the respective 1640 -- request messages 1641 keyEncryptionAlgorithm 1642 REQUIRED 1643 -- MUST be id-PasswordBasedMac 1644 PBMParameter REQUIRED 1645 salt REQUIRED 1646 -- MUST be the random value to salt the secret key 1647 -- MUST be a different value than used in the PBMParameter 1648 -- data structure of the CMP message prtection in the 1649 -- header of this message 1650 owf REQUIRED 1651 -- MUST be the same value than used in the PBMParameter 1652 -- data structure in the header of this message 1653 iterationCount 1654 REQUIRED 1655 -- MUST be a limited number of times the OWF is applied 1656 -- To prevent brute force and dictionary attacks a reasonable 1657 -- high number SHOULD be used 1658 mac REQUIRED 1659 -- MUST be the same as in the contentEncryptionAlgorithm field 1660 encryptedKey REQUIRED 1661 -- MUST be the encrypted content-encryption key 1663 < TBD: To make use of a different symmetric keys for encrypting the 1664 private key and for MAC-protection of the CMP message, we derive 1665 another key using the same PBMParameter structure from CMP, even 1666 though from the perspective of field names, it is not intended to be 1667 used for deriving encryption keys. Does anyone sees a better 1668 solution here? > 1670 5.1.6.2. Using key agreement key management technique 1672 This key management technique can be applied in combination with the 1673 message flow specified in Section 5.1.1 using signature-based 1674 protected CMP messages. The public key of the EE certificate used 1675 for the signature-based protection of the request message MUST also 1676 be used for the Ephemeral-Static Diffie-Hellmann key establishment of 1677 the content-encryption key. To use this key management technique the 1678 KeyAgreeRecipientInfo structure MUST be used in the contentInfo 1679 field. 1681 The KeyAgreeRecipientInfo structure included into the envelopedData 1682 structure is specified in CMS Section 6.2.2 [RFC5652]. 1684 The detailed description of the KeyAgreeRecipientInfo structure looks 1685 like this: 1687 recipientInfo REQUIRED 1688 -- MUST be KeyAgreeRecipientInfo as specified in 1689 version REQUIRED 1690 -- MUST be set to 3 1691 originator REQUIRED 1692 -- MUST contain the originatorKey sequence 1693 algorithm REQUIRED 1694 -- MUST be the algorithm identifier of the 1695 -- static-ephemeral Diffie-Hellmann algorithm 1696 publicKey REQUIRED 1697 -- MUST be the ephemeral public key of the sending party 1698 ukm OPTIONAL 1699 -- MUST be used when 1-pass ECMQV is used 1700 keyEncryptionAlgorithm 1701 REQUIRED 1702 -- MUST be the same as in the contentEncryptionAlgorithm field 1703 recipientEncryptedKeys 1704 REQUIRED 1705 -- MUST be exactly one recipientEncryptedKey sequence 1706 recipientEncryptedKey 1707 REQUIRED 1708 rid REQUIRED 1709 rKeyId REQUIRED 1710 subjectKeyID 1711 REQUIRED 1712 -- MUST contain the same value as the senderKID in the respective 1713 -- request messages 1714 encryptedKey 1715 REQUIRED 1716 -- MUST be the encrypted content-encryption key 1718 5.1.6.3. Using key transport key management technique 1720 This key management technique can be applied in combination with the 1721 message flow specified in Section 5.1.1 using signature-based 1722 protected CMP messages. The public key of the EE certificate used 1723 for the signature-based protection of the request message MUST also 1724 be used for key encipherment of the content-encryption key. To use 1725 this key management technique the KeyTransRecipientInfo structure 1726 MUST be used in the contentInfo field. 1728 The KeyTransRecipientInfo structure included into the envelopedData 1729 structure is specified in CMS Section 6.2.1 [RFC5652]. 1731 The detailed description of the KeyTransRecipientInfo structure looks 1732 like this: 1734 recipientInfo REQUIRED 1735 -- MUST be KeyTransRecipientInfo as specified in 1736 -- CMS section 6.2.1 [RFC5652] 1737 version REQUIRED 1738 -- MUST be set to 2 1739 rid REQUIRED 1740 subjectKeyIdentifier 1741 REQUIRED 1742 -- MUST contain the same value as the senderKID in the respective 1743 -- request messages 1744 keyEncryptionAlgorithm 1745 REQUIRED 1746 -- MUST contain the key encryption algorithm identifier used for 1747 -- public key encryption 1748 encryptedKey REQUIRED 1749 -- MUST be the encrypted content-encryption key 1751 5.1.7. Delayed enrollment 1753 This functional extension can be applied in combination with 1754 certificate enrollment as described in Section 5.1.1 to 1755 Section 5.1.5. The functional extension can be used in case a (L)RA/ 1756 CA cannot respond to the certificate request in a timely manner, 1757 e.g., due to offline upstream communication or required registration 1758 officer interaction. Depending on the PKI architecture, it is not 1759 necessary that the PKI component directly communicating with the EE 1760 initiates the delayed enrollment. 1762 The PKI component initiating the delayed enrollment MUST include the 1763 status "waiting" in the response and this response MUST not contain 1764 the newly issued certificate. When receiving a response with status 1765 "waiting" the EE MUST send a poll request to the (L)RA/CA. The PKI 1766 component that initiated the delayed enrollment MUST answers with a 1767 poll response containing a checkAfter time. This value indicates the 1768 minimum number of seconds that must elapse before the EE sends 1769 another poll request. As soon as the (L)RA/CA can provide the final 1770 response message for the initial request of the EE, it MUST provide 1771 this in response to a poll request. After receiving this response, 1772 the EE can continue the original message sequence as described in the 1773 respective section of this document, e.g., send a certConf message. 1775 Typically, intermediate PKI entities SHOULD NOT change the sender and 1776 recipient nonce even in case an intermediate (L)RA modifies a request 1777 or a response message. In the special case of polling between EE and 1778 LRA with offline transport between an LRA and RA, see Section 6.1.4, 1779 an exception occurs. The EE and LRA exchange pollReq and pollRep 1780 messages handle the nonce words as described. When, after pollRep, 1781 the final response from the CA arrives at the LRA, the next response 1782 will contain the recipientNonce set to the value of the senderNonce 1783 in the original request message (copied by the CA). The LRA needs to 1784 replace the recipientNonce in this case with the senderNonce of the 1785 last pollReq because the EE will validate it in this way. 1787 Message flow: 1789 Step# EE (L)RA/CA 1790 1 format ir/cr/p10cr/kur 1791 As described in the 1792 respective section 1793 in this document 1794 2 ->ir/cr/p10cr/kur-> 1795 3 handle request as described 1796 in the respective section 1797 in this document 1798 4 in case no immediate final 1799 response is possible, 1800 receive or format ip, cp 1801 or kup message containing 1802 status "waiting" 1803 5 <- ip/cp/kup <- 1804 6 handle ip/cp/kup 1805 7 format pollReq 1806 8 -> pollReq -> 1807 9 handle, re-protect or 1808 forward pollReq 1809 10 in case the requested 1810 certificate or a 1811 corresponding response 1812 message is available, 1813 receive or format ip, cp, 1814 or kup containing the 1815 issued certificate, or 1816 format or receive pollRep 1817 with appropriate 1818 checkAfter value 1819 11 <- pollRep <- 1820 12 handle pollRep 1821 13 let checkAfter 1822 time elapse 1823 14 continue with line 7 1825 Detailed description of the first ip/cp/kup: 1827 Response with status 'waiting' -- ip/cp/kup 1829 Field Value 1831 header 1832 -- MUST contain a header as described for the first response 1833 -- message of the respective sheme 1835 body 1836 -- The response of the (L)RA/CA to the request in case no 1837 -- immediate appropriate response can be sent 1838 ip/cp/kup REQUIRED 1839 response REQUIRED 1840 -- MUST be exactly one CertResponse 1841 certReqId REQUIRED 1842 -- MUST be set to 0 1843 status REQUIRED 1844 -- PKIStatusInfo structure MUST be present 1845 status REQUIRED 1846 -- MUST be set to "waiting" 1847 statusString OPTIONAL 1848 -- MAY be any human-readable text for debugging, logging or to 1849 -- display in a GUI 1850 failInfo PROHIBITED 1851 certifiedKeyPair PROHIBITED 1853 protection REQUIRED 1854 -- MUST contain protection as described for the first response 1855 -- message of the respective profile, but 1856 -- MUST use the protection key of the (L)RA/CA initiating the 1857 -- delayed enrollment and creating this response message 1859 extraCerts REQUIRED 1860 -- MUST contain certificates as described for the first response 1861 -- message of the respective profile. 1862 -- As no new certificate is issued yet, no respective certificate 1863 -- chain is included. 1865 Polling Request -- pollReq 1867 Field Value 1869 header 1870 -- MUST contain a header as described for the certConf message 1871 -- of the respective sheme 1873 body 1874 -- The message of the EE asks for the final response or for a 1875 -- time to check again 1876 pollReq REQUIRED 1877 certReqId REQUIRED 1878 -- MUST be exactly one value 1879 -- MUST be set to 0 1881 protection REQUIRED 1882 -- MUST contain protection as described for the certConf message 1883 -- of the respective profile 1885 extraCerts OPTIONAL 1886 -- If present, it MUST contain certificates as described for the 1887 -- certConf message of the respective profile. 1889 Polling Response -- pollRep 1891 Field Value 1893 header 1894 -- MUST contain a header as described for the pkiConf message 1895 -- of the respective sheme 1897 body pollRep 1898 -- The message indicated the time to after which the EE may 1899 -- send another pollReq messaged for this transaction 1900 pollRep REQUIRED 1901 -- MUST be exactly one set of the following values 1902 certReqId REQUIRED 1903 -- MUST be set to 0 1904 checkAfter REQUIRED 1905 -- time in seconds to elapse before a new pollReq may be sent by 1906 -- the EE 1908 protection REQUIRED 1909 -- MUST contain protection as described for the pkiConf message 1910 -- of the respective profile, but 1911 -- MUST use the protection key of the (L)RA/CA that initiated the 1912 -- delayed enrollment and is creating this response message 1914 extraCerts OPTIONAL 1915 -- If present, it MUST contain certificates as described for the 1916 -- pkiConf message of the respective profile. 1918 Final response -- ip/cp/kup 1920 Field Value 1922 header 1923 -- MUST contain a header as described for the first 1924 -- response message of the respective sheme 1925 -- but the recipientNonce MUST be the senderNonce of the last 1926 -- pollReq message 1928 body 1929 -- The response of the (L)RA/CA to the initial request as 1930 -- described in the respective profile 1932 protection REQUIRED 1933 -- MUST contain protection as described for the first response 1934 -- message of the respective profile, but 1935 -- MUST use the protection key of the (L)RA/CA that initiated the 1936 -- delayed enrollment and forwarding the response message 1938 extraCerts REQUIRED 1939 -- MUST contain certificates as described for the first 1940 -- response message of the respective profile 1942 5.2. Revoking a certificate 1944 This message sequence should be used by an entity to request the 1945 revocation of a certificate. Here the revocation request is used by 1946 an EE to revoke one of its own certificates. A (L)RA could also act 1947 as an EE to revoke one of its own certificates. 1949 The revocation request message MUST be signed using the certificate 1950 that is to be revoked to prove the authorization to revoke to the 1951 PKI. The revocation request message is signature-protected using 1952 this certificate. 1954 An EE requests the revocation of an own certificate at the CA that 1955 issued this certificate. The (L)RA/CA responds with a message that 1956 contains the status of the revocation from the CA. 1958 Preconditions: 1960 1 The certificate the EE wishes to revoke is not yet expired or 1961 revoked. 1963 Message flow: 1965 Step# EE (L)RA/CA 1966 1 format rr 1967 2 -> rr -> 1968 3 handle, re-protect or 1969 forward rr 1970 4 receive rp 1971 5 <- rp <- 1972 6 handle rp 1974 For this profile, the EE MUST include exactly one RevDetails 1975 structure in the rr. In case no error occurred the response to the 1976 rr MUST be an rp message. The (L)RA/CA MUST produce a rp containing 1977 a status field with a single set of values. 1979 Detailed message description: 1981 Revocation Request -- rr 1983 Field Value 1985 header 1986 -- As described in section 3.1 1988 body 1989 -- The request of the EE to revoke its certificate 1990 rr REQUIRED 1991 -- MUST contain exactly one element of type RevDetails 1992 -- If more revocations are desired, further requests MUST be 1993 -- packaged in separate PKI Messages 1994 certDetails REQUIRED 1995 -- MUST be present and is of type CertTemplate 1996 serialNumber REQUIRED 1997 -- MUST contain the certificate serialNumber attribute of the 1998 -- X.509 certificate to be revoked 1999 issuer REQUIRED 2000 -- MUST contain the issuer attribute of the X.509 certificate to 2001 -- be revoked 2002 crlEntryDetails REQUIRED 2003 -- MUST contain exactly one reasonCode of type CRLReason (see 2004 -- [RFC5280] section 5.3.1) 2005 -- If the reason for this revocation is not known or shall not be 2006 -- published the reasonCode MUST be 0 = unspecified 2008 protection REQUIRED 2009 -- As described in section 3.2 and the private key related to the 2010 -- certificate to be revoked 2012 extraCerts REQUIRED 2013 -- As described in section 3.3 2015 Revocation Response -- rp 2017 Field Value 2019 header 2020 -- As described in section 3.1 2022 body 2023 -- The responds of the (L)RA/CA to the request as appropriate 2024 rp REQUIRED 2025 status REQUIRED 2026 -- MUST contain exactly one element of type PKIStatusInfo 2027 status REQUIRED 2028 -- positive value allowed: "accepted" 2029 -- negative value allowed: "rejection" 2030 statusString OPTIONAL 2031 -- MAY be any human-readable text for debugging, logging or to 2032 -- display in a GUI 2033 failInfo OPTIONAL 2034 -- MAY be present if and only if status is "rejection" 2036 protection REQUIRED 2037 -- As described in section 3.2 2039 extraCerts REQUIRED 2041 5.3. Error reporting 2043 This functionality should be used by an EE to report any error 2044 conditions upstream to the (L)RA/CA. Error reporting by the (L)RA 2045 downstream to the EE is described in Section 6.3. 2047 In case the error condition is related to specific details of an ip, 2048 cp, or kup response message and a confirmation is expected the error 2049 condition MUST be reported in the respective certConf message with 2050 negative contents. 2052 General error conditions, e.g., problems with the message header, 2053 protection, or extraCerts, and negative feedback on rp, pollRep, or 2054 pkiConf messages MAY be reported in the form of an error message. 2056 In both situations the error is reported in the PKIStatusInfo 2057 structure of the respective message. 2059 The (L)RA/CA MUST respond to an error message with a pkiConf message, 2060 or with another error message if any part of the header is not valid. 2061 Both sides MUST treat this message as the end of the current 2062 transaction. 2064 The PKIStatusInfo structure is used to report errors. The 2065 PKIStatusInfo structure SHOULD consist of the following fields: 2067 o status: Here the PKIStatus value rejection is the only one 2068 allowed. 2070 o statusString: Here any human-readable valid value for logging or 2071 to display in a GUI SHOULD be added. 2073 o failInfo: Here the PKIFailureInfo values MAY be used in the 2074 following way. For explanation of the reason behind a specific 2075 value, please refer to [RFC4210] Appendix F. 2077 * transactionIdInUse: This is sent in case the received request 2078 contains a transaction ID that is already in use for another 2079 transaction. An EE receiving such error message SHOULD resend 2080 the request in a new transaction using a different transaction 2081 ID. 2083 * systemUnavail or systemFailure: This is sent in case a back-end 2084 system is not available or currently not functioning correctly. 2085 An EE receiving such error message SHOULD resend the request in 2086 a new transaction after some time. 2088 Detailed error message description: 2090 Error Message -- error 2092 Field Value 2094 header 2095 -- As described in section 3.1 2097 body 2098 -- The message sent by the EE or the (L)RA/CA to indicate an 2099 -- error that occurred 2100 error REQUIRED 2101 pKIStatusInfo REQUIRED 2102 status REQUIRED 2103 -- MUST have the value "rejection" 2104 statusString RECOMMENDED 2105 -- SHOULD be any human-readable text for debugging, logging 2106 -- or to display in a GUI 2107 failInfo OPTIONAL 2108 -- MAY be present 2110 protection REQUIRED 2111 -- As described in section 3.2 2113 extraCerts OPTIONAL 2114 -- As described in section 3.3 2116 5.4. Support messages 2118 The following support messages offer on demand in-band transport of 2119 content that may be provided by the (L)RA/CA and relevant to the EE. 2120 The general messages and general response are used for this purpose. 2121 Depending on the environment, these requests are answered by the LRA, 2122 RA, or CA. 2124 The general message and general response transport InfoTypeAndValue 2125 structures. In addition to those infoType values defined in CMP 2126 [RFC4210] further OIDs MAY be defined to define new PKI management 2127 operations, or general-purpose messages as needed in a specific 2128 environment. 2130 Possible content described here address: 2132 o Request of CA certificates 2134 o Update of Root CA certificates 2136 o Parameters needed for a planned certificate request message 2138 o Voucher request and enrollment voucher exchange 2140 5.4.1. General message and response 2142 The general message transaction is similar to that given in CMP 2143 Appendix E.5 [RFC4210]. In this section the general message (genm) 2144 and general response (genp) are described. The specific 2145 InfoTypeAndValue structures are described in the following sections. 2147 The behavior in case an error occurs is described in Section 5.3. 2149 Message flow: 2151 Step# EE (L)RA/CA 2152 1 format genm 2153 2 -> genm -> 2154 3 handle, re-protect or 2155 forward genm 2156 4 format or receive genp 2157 5 <- genp <- 2158 6 handle genp 2160 Detailed message description: 2162 General Message -- genm 2163 Field Value 2165 header 2166 -- As described in section 3.1 2168 body 2169 -- The request of the EE to receive information 2170 genm REQUIRED 2171 -- MUST contain exactly one element of type 2172 -- InfoTypeAndValue 2173 infoType REQUIRED 2174 -- MUST be the OID identifying the specific scheme 2175 -- described below 2176 infoValue OPTIONAL 2177 -- MUST be as described in the specific scheme described 2178 -- below 2180 protection REQUIRED 2181 -- As described in section 3.2 2183 extraCerts REQUIRED 2184 -- As described in section 3.3 2186 General Response -- genp 2188 Field Value 2190 header 2191 -- As described in section 3.1 2193 body 2194 -- The response of the (L)RA/CA to the information request 2195 genp REQUIRED 2196 -- MUST contain exactly one element of type 2197 -- InfoTypeAndValue 2198 infoType REQUIRED 2199 -- MUST be the OID identifying the specific scheme 2200 -- described below 2201 infoValue OPTIONAL 2202 -- MUST be as described in the specific scheme described 2203 -- below 2205 protection REQUIRED 2206 -- As described in section 3.2 2208 extraCerts REQUIRED 2209 -- As described in section 3.3 2211 5.4.2. Get CA certiificates 2213 This scheme can be used by an EE to request CA certificates from the 2214 (L)RA/CA. 2216 An EE requests CA certificates from the (L)RA/CA by sending a general 2217 message with OID id-it-getCaCerts. The (L)RA/CA responds with a 2218 general response with the same OID that either contains a SEQUENCE of 2219 certificates populated with the available CA intermediate and issuing 2220 CA certificates or with no content in case no CA certificate is 2221 available. 2223 < NOTE: The OID id-it-getCaCerts is not yet defined. It should be 2224 registered in the tree 1.3.6.1.5.5.7.4 (id-it) like other infoType 2225 OIDs, see CMP Appendix F [RFC4210] on page 92. > 2227 The profile for this exchange is as given in Section 5.4.1, with the 2228 following specific content: 2230 1 the body MUST contain as infoType the OID id-it-getCaCerts 2232 2 the infoValue of the request MUST be absent 2234 3 if present, the infoValue of the response MUST be caCerts field 2236 The infoValue field of the general response containing the id-it- 2237 getCaCerts OID looks like this: 2239 infoValue OPTIONAL 2240 -- MUST be absent if no CA certificate is available 2241 -- MUST be present if CA certificates are available 2242 caCerts REQUIRED 2243 -- MUST be present if infoValue is present 2244 -- MUST be a sequence of CMPCertificate 2246 5.4.3. Get root CA certificate update 2248 This scheme can be used by an EE to request an update of an existing 2249 root CA Certificate by the EE. It utilizes the CAKeyUpdAnnContent 2250 structure as described in CMP Appendix E.4 [RFC4210] as response to a 2251 respective general message. 2253 An EE requests a root CA certificate update from the (L)RA/CA by 2254 sending a general message with OID id-it-caKeyUpdateInfo as infoType 2255 and no infoValue. The (L)RA/CA responds with a general response with 2256 the same OID that either contains the update of the root CA 2257 certificate consisting of up to three certificates, or with no 2258 content in case no update is available. 2260 These three certificates are described in more detail in section 2261 4.4.1, section 6.2, and Appendix E.3 of [RFC4210]. The newWithNew 2262 certificate is the new root CA certificates and is REQUIRED to be 2263 present in the response message. The newWithOld certificate 2264 RECOMMENDED to be present in the response message though it is 2265 required for those cases where the receiving entity trusts the old 2266 root CA certificate and whishes to gain trust in the new root CA 2267 certificate. The oldWithNew certificate is OPTIONAL though it is 2268 only needed in a scenario where the requesting entity already trusts 2269 the new root CA certificate and wants to gain trust in the old root 2270 certificate. 2272 The profile for this exchange is as given in Section 5.4.1, with the 2273 following specific content: 2275 1 the body MUST contain as infoType the OID id-it-caKeyUpdateInfo 2277 2 the infoValue of the request MUST be absent 2279 3 if present, the infoValue of the response MUST be a 2280 CAKeyUpdAnnContent structure 2282 The infoValue field of the general response containing the id-it- 2283 caKeyUpdateInfo extension looks like this: 2285 infoValue OPTIONAL 2286 -- MUST be absent if no update of the root CA certificate is 2287 available 2288 -- MUST be present if an update of the root CA certificate 2289 -- is available 2290 caKeyUpdateInfo REQUIRED 2291 -- MUST be present and be of type CAKeyUpdAnnContent 2292 oldWithNew OPTIONAL 2293 -- MUST be present if infoValue is present 2294 -- MUST contain an X.509 certificate containing the old public 2295 -- root CA key signed with the new private root CA key 2296 newWithOld RECOMMENDED 2297 -- MUST be present if infoValue is present 2298 -- MUST contain an X.509 certificate containing the new public 2299 -- root CA key signed with the old private root CA key 2300 newWithNew REQUIRED 2301 -- MUST be present if infoValue is present 2302 -- MUST contain the new root CA certificate 2304 5.4.4. Get certificate request parameters 2306 This scheme can be used by an EE to request configuration parameters 2307 for a planned certificate request transaction. 2309 An EE requests certificate request parameters from the (L)RA/CA by 2310 sending a general message with OID id-it-getCSRParam. The (L)RA/CA 2311 responds with a general response with the same OID that either 2312 contains the required fields, e.g., algorithm identifier for key pair 2313 generation or other attributes and extensions or with no content in 2314 case no specific requirements are made by the (L)RA/CA. 2316 < NOTE: The OID id-it-getCSRParam is not yet defined. It should be 2317 registered in the tree 1.3.6.1.5.5.7.4 (id-it) like other infoType 2318 OIDs, see CMP Appendix F [RFC4210] on page 92. > 2320 The EE SHOULD follow the requirements from the recieved CertTemplate 2321 and the optional RSA key length. In case a field is present but the 2322 value is absent, it means that this field is required but its content 2323 has to be provided by the EE. 2325 < TBD: There is some more explanation needed to explain how to 2326 prefill the certTemplate structure. Possibly an example will help to 2327 clarify this. > 2329 The profile for this exchange is as given in Section 5.4.1, with the 2330 following specific content: 2332 1 the body MUST contain as infoType the OID id-it-getCSRParam 2334 2 the infoValue of the request MUST be absent 2336 3 if present, the infoValue of the response MUST be a SEQUENCE of a 2337 certTemplate structure and an rsaKeyLen field of type INTEGER 2339 The infoValue field of the general response containing the id-it- 2340 getCSRParam OID looks like this: 2342 infoValue OPTIONAL 2343 -- MUST be absent if no requirements are available 2344 -- MUST be present if the (L)RA/CA has any requirements on the 2345 -- content of the certificates to be requested. 2346 certTemplate REQUIRED 2347 -- MUST be present if infoValue is present 2348 -- MUST contain the prefilled certTemplate structure 2349 rsaKeyLen OPTIONAL 2350 -- This field is of type INTEGER. Any reasonable RSA key length 2351 -- SHOULD be specified if the algorithm in the 2352 -- subjectPublicKeyInfo field of the certTemplate is of type 2353 -- rsaEncryption. 2355 5.4.5. Get certificate management configuration 2357 This scheme can be used by an EE to request the current certificate 2358 management configuration information by the EE in advance to a 2359 planned certificate management transaction, e.g., in case no out-of- 2360 band transport is available. Such certificate management 2361 configuration can consist of all information the EE needs to know to 2362 generate and deliver a proper certificate request, such as 2364 o algorithm, curve, and key length for key generation 2366 o various certificate attributes and extensions to be used for the 2367 certificate request 2369 o specific host name, port and path on the RA/LRA to send this CMP 2370 request to 2372 o Infrastructure Root CA Certificate, e.g., the root of the (L)RA 2373 TLS and CMP signer certificates. 2375 There is an overlap with Section 5.4.2 with regard to transport of CA 2376 certificates and with Section 5.4.4 with regard to key generation 2377 parameter and certificate request attributes and extensions. This 2378 profile offers to request a proprietary configuration file containing 2379 all information needed in one exchange. 2381 < TBD: Especially with section 5.4.4 there is some overlap regarding 2382 algorithms, attributes and, extensions of the certificate that will 2383 be requested. It needs to be decided if both variants have a right 2384 to exist next to the other or if one option should be removed from 2385 this document. > 2386 An EE requests certificate management configuration from the (L)RA/CA 2387 by sending a general message with the OID id-it-getCertMgtConfig. 2388 The (L)RA/CA responds with a general response with the same OID that 2389 either contains a certMgtConfig field containing the configuration 2390 file encoded as OCTET STRING or with no content in case no 2391 certificate management configuration is available. 2393 < NOTE: The OID id-it-getCertMgtConfig is not yet defined. It should 2394 be registered in the tree 1.3.6.1.5.5.7.4 (id-it) like other infoType 2395 OIDs, see CMP Appendix F [RFC4210] on page 92. > 2397 The EE SHOULD use the contents of this certMgtConfig to format and 2398 deliver the certificate request. The certificate management 2399 configuration may contain contact details, e.g., like an URI and 2400 issuing CA distinguished name, where to address the request messages 2401 to and may also contain certificate request parameters as described 2402 in Section 5.4.4. 2404 The certMgtConfig field may be of any format suitable for the EE, 2405 e.g., CMS [RFC5652], JWT [RFC7519] or, XML [W3C_XML]. The 2406 certMgtConfig contents MAY be signed, e.g., like CMS SignedData 2407 [RFC5652], JWS [RFC7515] or, XML-DSig [W3C_XML-Dsig]. For 2408 interoperability the format of the certMgtConfig field should be 2409 specified in detail if needed. 2411 The profile for this exchange is as given in Section 5.4.1, with the 2412 following specific content: 2414 1 the body MUST contain as infoType the OID id-it-getCertMgtConfig 2416 2 the infoValue of the request MUST be absent 2418 3 if present, the infoValue of the response MUST be a certMgtConfig 2419 structure 2421 The infoValue field of the general response containing the id-it- 2422 getCertMgtConfig extension looks like this: 2424 infoValue OPTIONAL 2425 -- MUST be absent if no certificate management configuration 2426 -- is available 2427 -- MUST be present if the (L)RA/CA provides any certificate 2428 -- management configuration 2429 certMgtConfig REQUIRED 2430 -- MUST be present if infoValue is present 2431 -- MUST contain the certificate management configuration as OCTET 2432 -- OCTET STRING 2434 5.4.6. Get enrollment voucher 2436 This scheme can be used by an EE to request an enrollment voucher 2437 containing the root certificate of a new, additional, or alternative 2438 PKI to establish trust in this PKI, e.g., in case no out-of-band 2439 transport is available. Such an enrollment voucher can be used in 2440 advance to an enrollment to this new environment. It may contain 2441 further information depending on the use case. 2443 An EE requests an enrollment voucher from the (L)RA/CA by sending a 2444 general message. The (L)RA/CA responds with a general response with 2445 the same OID that either contains the voucher or with no content in 2446 case no voucher is available. 2448 The (L)RA MAY use the content of the voucherRequest to get an 2449 enrollment voucher from other backend components, e.g., as described 2450 in BRSKI [I-D.ietf-anima-bootstrapping-keyinfra]. The EE SHOULD use 2451 the contents of the received enrollmentVoucher to authenticate the 2452 (L)RA/CA it is about to enroll to. The enrollment voucher may for 2453 example contain the Root CA certificate of the new PKI or the CMP 2454 signer certificate of the (L)RA. The general response message MUST 2455 be properly authenticated and the sender of this message MUST be 2456 authorized to install new root certificates. One example for an 2457 enrollment voucher is specified in RFC8366 [RFC8366]. 2459 The voucherRequest and enrollmentVoucher fields may be of any format 2460 suitable for the EE, e.g., CMS [RFC5652], JWT [RFC7519] or, XML 2461 [W3C_XML]. The voucherRequest and enrollmentVoucher contents MAY 2462 contain a signature, e.g., CMS SignedData [RFC5652], JWS [RFC7515] 2463 or, XML-DSig [W3C_XML-Dsig]. For interoperability the format of the 2464 voucherRequest and enrollmentVoucher field schould be specified in 2465 detail if needed, e.g., as defined in BRSKI 2466 [I-D.ietf-anima-bootstrapping-keyinfra] and RFC8366 [RFC8366]. 2468 < TBD: The vontent of the voucherRequest and enrollmentVoucher fields 2469 can also be linited to the specufucations in BRSKI 2470 [I-D.ietf-anima-bootstrapping-keyinfra] and RFC8366 [RFC8366]. > 2472 The profile for this exchange is as given in Section 5.4.1, with the 2473 following specific content: 2475 1 the body MUST contain as infoType the OID id-it- 2476 getEnrollmentVoucher 2478 2 if present, the infoValue of the request MUST be a voucherRequest 2479 structure 2481 3 if present, the infoValue of the response MUST be an 2482 enrollmentVoucher structure 2484 The infoValue field of the general message containing the id-it- 2485 getEnrollmentVoucher extension looks like this: 2487 infoValue OPTIONAL 2488 -- MUST be absent if no voucher request is available 2489 -- MUST be present if the EE provides the voucher request 2490 voucherRequest REQUIRED 2491 -- MUST be present if infoValue is present 2492 -- MUST contain the voucher request as OCTET STRING 2494 The infoValue field of the general response containing the id-it- 2495 getEnrollmentVoucher extension looks like this: 2497 infoValue OPTIONAL 2498 -- MUST be absent if no enrollment voucher is available 2499 -- MUST be present if the (L)RA/CA provides the enrollment 2500 -- voucher 2501 enrollmentVoucher REQUIRED 2502 -- MUST be present if infoValue is present 2503 -- MUST contain the enrollment voucher as OCTET STRING 2505 6. LRA and RA focused certificate management use cases 2507 This chapter focuses on the communication of PKI backend components 2508 with each other. Depending on the network and PKI solution design, 2509 these will either be an LRA, RA or CA. 2511 Typically, an (L)RA forwards messages from downstream, but it may 2512 also reply to them itself. Besides forwarding of received messages 2513 an (L)RA could also need to revoke certificates of EEs, report 2514 errors, or may need to manage its own certificates. 2516 < TBD: In CMP Updates [I-D.brockhaus-lamps-cmp-updates] additional 2517 extended key usages like id-kp-cmpRA will be defined to indicate that 2518 a key pair is entitled to be used for signature-based protection of a 2519 CMP message by an (L)RA/CA. > 2521 6.1. Forwarding of messages 2523 Each CMP request message (i.e., ir, cr, p10cr, kur, pollReq, or 2524 certConf) or error message coming from an EE or the previous 2525 (downstream) PKI component MUST be sent to the next (upstream) PKI 2526 component. This PKI component MUST forward response messages to the 2527 next (downstream) PKI component or EE. 2529 The (L)RA SHOULD verify the protection, the syntax, the required 2530 message fields, the message type, and if applicable the authorization 2531 and the proof-of-possession of the message. Additional checks or 2532 actions MAY be applied depending on the PKI solution requirements and 2533 concept. If one of these verification procedures fails, the (L)RA 2534 SHOULD respond with a negative response message and SHOULD not 2535 forward the message further upstream. General error conditions 2536 should be handled as described in Section 5.3 and Section 6.3. 2538 An (L)RA SHOULD not change the received message if not necessary. 2539 The (L)RA SHOULD only update the message protection if it is 2540 technically necessary. Concrete PKI system specifications may define 2541 in more detail if and when to do so. 2543 This is particularly relevant in the upstream communication of a 2544 request message. 2546 Each hop in a chain of PKI components has one or more 2547 functionalities, e.g., 2549 o An (L)RA may need to verify the identities of EEs or base 2550 authorization decisions for certification request processing on 2551 specific knowledge of the local setup, e.g., by consulting an 2552 inventory or asset management system. 2554 o An (L)RA may need to add fields to certificate request messages. 2556 o An (L)RA may need to store data from a message in a database for 2557 later usage or documentation purposes. 2559 o An (L)RA may provide traversal of a network boundary. 2561 o An (L)RA may need to double-check if the messages transferred back 2562 and forth are properly protected and well formed. 2564 o An (L)RA may provide a proof that it has performed all required 2565 checks. 2567 o An (L)RA may initiate a delayed enrollment due to offline upstream 2568 communication or registration officer interaction. 2570 o An (L)RA may grant the request of an EE to omit sending a 2571 confirmation message. 2573 o An RA can collect messages from different LRAs and forward them to 2574 the CA. 2576 Therefore, the decision if a message should be forwarded 2577 o unchanged with the original protection, 2579 o unchanged with a new protection, or 2581 o changed with a new protection 2583 depends on the PKI solution design and the associated security policy 2584 (CP/CPS [RFC3647]). 2586 < TBD: In [CMP Updates] different circumstances that require adding 2587 of an additional protection by an (L)RA or batching CMP messages at 2588 an (L)RA by using the nested messages is described. It needs to be 2589 decided which of these variants should be specified here. Finally, I 2590 guess they will all be OPTIONAL. > 2592 This section specifies the different options an (L)RA may implement 2593 and use. 2595 An (L)RA MAY update the protection of a message 2597 o if the (L)RA performs changes to the header or the body of the 2598 message, 2600 o if the (L)RA needs to prove checks or validations performed on the 2601 message to one of the next (upstream) PKI components, 2603 o if the (L)RA needs to protect the message using a key and 2604 certificate from a different PKI, or 2606 o if the (L)RA needs to replace a MAC based-protection. 2608 This is particularly relevant in the upstream communication of 2609 certificate request messages. 2611 The message protection covers only the header and the body and not 2612 the extraCerts. The (L)RA MAY change the extraCerts in any of the 2613 following message adaptations, e.g., to sort or add needed or to 2614 delete needless certificates to support the next hop. This may be 2615 particularly helpful to extend upstream messages with additional 2616 certificates or to reduce the number of certificates in downstream 2617 messages when forwarding to constrained devices. 2619 6.1.1. Not changing protection 2621 This message adaptation can be used by any (L)RA to forward an 2622 original CMP message without changing the header, body or protection. 2623 In any of these cases the (L)RA acts more like a proxy, e.g., on a 2624 network boundary, implementing no specific RA-like security 2625 functionality to the PKI. 2627 This message adaptation MUST be used for forwarding kur messages that 2628 must not be approved by the respective (L)RA. 2630 6.1.2. Replacing protection 2632 The following two message adaptations can be used by any (L)RA to 2633 forward a CMP message with or without changes, but providing its own 2634 protection using its CMP signer key providing approval of this 2635 message. In this case the (L)RA acts as an actual Registration 2636 Authority (RA), which implements important security functionality of 2637 the PKI. 2639 Before replacing the existing protection by a new protection, the 2640 (L)RA MUST verify the protection provided by the EE or by the 2641 previous PKI component and approve its content including any own 2642 modifications. For certificate requests the (L)RA MUST verify in 2643 particular the included proof-of-possession self-signature of the 2644 certTemplate using the public key of the requested certificate and 2645 MUST check that the EE, as authenticated by the message protection, 2646 is authorized to request a certificate with the subject as specified 2647 in the certTemplate. 2649 In case the received message has been protected by a CA or another 2650 (L)RA, the current (L)RA MUST verify its protection and approve its 2651 content including any own modifications. For certificate requests 2652 the (L)RA MUST check that the other (L)RA, as authenticated by the 2653 message protection, is authorized to issue or forward the request. 2655 These message adaptations MUST NOT be applied to kur request messages 2656 as described in Section 5.1.3 since their original protection using 2657 the key and certificate to be updated needs to be preserved, unless 2658 the regCtrl OldCertId is used to clearly identify the certificate to 2659 be updated. 2661 6.1.2.1. Keeping proof-of-possession 2663 This message adaptation can be used by any (L)RA to forward a CMP 2664 message with or without modifying the message header or body while 2665 preserving any included proof-of-possession. 2667 By replacing the existing protection using its own CMP signer key the 2668 (L)RA provides a proof of verifying and approving of the message as 2669 described above. 2671 In case the (L)RA modifies the certTemplate of an ir or cr message, 2672 the message adaptation in Section 6.1.2.2 needs to be applied 2673 instead. 2675 6.1.2.2. Breaking proof-of-possession 2677 This message adaptation can be used by any (L)RA to forward an ir or 2678 cr message with modifications of the certTemplate i.e., modification, 2679 addition, or removal of fields. Such changes will break the proof- 2680 of-possession provided by the EE in the original message. 2682 By replacing the existing or applying an initial protection using its 2683 own CMP signer key the (L)RA provides a proof of verifying and 2684 approving the new message as described above. 2686 In addition to the above the (L)RA MUST verify in particular the 2687 proof-of-possession contained in the original message as described 2688 above. If these checks were successfully performed the (L)RA MUST 2689 change the popo to raVerified. 2691 The popo field MUST contain the raVerified choice in the certReq 2692 structure of the modified message as follows: 2694 popo 2695 raVerified REQUIRED 2696 -- MUST have the value NULL and indicates that the (L)RA 2697 -- verified the popo of the original message. 2699 6.1.3. Adding Protection 2701 < TBD: In [CMP Updates] different circumstances that require adding 2702 of an additional protection by an (L)RA or batching CMP messages at 2703 an (L)RA by using the nested messages is described. It needs to be 2704 decided which of these variants should be specified here. Finally, I 2705 guess they will all be OPTIONAL. > 2707 6.1.4. Initiating delayed enrollment 2709 This message adaptation can be used by an (L)RA to initiate delayed 2710 enrollment. In this case a (L)RA/CA MUST add the status waiting in 2711 the response message. The (L)RA/CA MUST then reply to the pollReq 2712 messages as described in Section 5.1.7. 2714 6.2. Revoking certificates on behalf of another's entities 2716 This message sequence can be used by an (L)RA to revoke a certificate 2717 of any other entity. This revocation request message MUST be signed 2718 by the (L)RA using its own CMP signer key to prove to the PKI 2719 authorization to revoke the certificate on behalf of the EE. 2721 The general message flow for this profile is the same as given in 2722 section Section 5.2. 2724 Preconditions: 2726 1 the certificate to be revoked MUST be known to the (L)RA 2728 2 the (L)RA MUST have the authorization to revoke the certificates 2729 of other entities issued by the corresponding CA 2731 The profile for this exchange is identical to that given in section 2732 Section 5.2, with the following changes: 2734 1 it is not required that the certificate to be revoked is not yet 2735 expired or revoked 2737 2 the (L)RA acts as EE for this message exchange 2739 3 the rr messages MUST be signed using the CMP signer key of the 2740 (L)RA. 2742 6.3. Error reporting 2744 This functionality should be used by the (L)RA to report any error 2745 conditions downstream to the EE. Potential error reporting by the EE 2746 upstream to the (L)RA/CA is described in Section 5.3. 2748 In case the error condition is related to specific details of an ir, 2749 cr, p10cr, or kur request message it MUST be reported in the specific 2750 response message, i.e., an ip, cp, or kup with negative contents. 2752 General error conditions, e.g., problems with the message header, 2753 protection, or extraCerts, and negative feedback on rr, pollReq, 2754 certConf, or error messages MUST be reported in the form of an error 2755 message. 2757 In both situations the (L)RA reports the errors in the PKIStatusInfo 2758 structure of the respective message as described in Section 5.3. 2760 An EE receiving any such negative feedback SHOULD log the error 2761 appropriately and MUST terminate the current transaction. 2763 7. CMP message transport variants 2765 The CMP messages are designed to be self-contained, such that in 2766 principle any transport can be used. HTTP SHOULD be used for online 2767 transport while file-based transport MAY be used in case offline 2768 transport is required. In case HTTP transport is not desired or 2769 possible, CMP messages MAY also be piggybacked on any other reliable 2770 transport protocol, e.g., CoAP [RFC7252]. 2772 Independently of the means of transport it could happen that messages 2773 are lost, or a communication partner does not respond. In order to 2774 prevent waiting indefinitely, each CMP client component SHOULD use a 2775 configurable per-request timeout, and each CMP server component 2776 SHOULD use a configurable per-response timeout in case a further 2777 message is to be expected from the client side. In this way a 2778 hanging transaction can be closed cleanly with an error and related 2779 resources (for instance, any cached extraCerts) can be freed. 2781 7.1. HTTP transport 2783 This transport mechanism can be used by an EE and (L)RA/CA to 2784 transfer CMP messages over HTTP. If HTTP transport is used the 2785 specifications as described in [RFC6712] MUST be followed. 2787 Each PKI management entity supporting HTTP(S) transport MUST support 2788 the use of the path-prefix of '/.well-known/' as defined in [RFC5785] 2789 and the registered name of 'CMP' to ease interworking in a multi- 2790 vendor environment. 2792 PKI management operations MUST use the following URI path: 2794 +---------------------------------+----------------------+----------+ 2795 | PKI management operation | Path | Details | 2796 +---------------------------------+----------------------+----------+ 2797 | Enroll client to new PKI | /initialization | Section | 2798 | (REQUIRED) | | 5.1.1 | 2799 +---------------------------------+----------------------+----------+ 2800 | Enroll client to existing PKI | /certification | Section | 2801 | (OPTIONAL) | | 5.1.2 | 2802 +---------------------------------+----------------------+----------+ 2803 | Update client certificate | /keyupdate | Section | 2804 | (REQUIRED) | | 5.1.3 | 2805 +---------------------------------+----------------------+----------+ 2806 | Enroll client using PKCS#10 | /p10 | Section | 2807 | (OPTIONAL) | | 5.1.5 | 2808 +---------------------------------+----------------------+----------+ 2809 | Enroll client using central key | /serverkeygen | Section | 2810 | generation (OPTIONAL) | | 5.1.6 | 2811 +---------------------------------+----------------------+----------+ 2812 | Revoke client certificate | /revocation | Section | 2813 | (RECOMMENDED) | | 5.2 | 2814 +---------------------------------+----------------------+----------+ 2815 | Get CA certificates (OPTIONAL) | /getCAcert | Section | 2816 | | | 5.4.2 | 2817 +---------------------------------+----------------------+----------+ 2818 | Get root CA certificate update | /getRootCAcertUpdate | Section | 2819 | (OPTIONAL) | | 5.4.3 | 2820 +---------------------------------+----------------------+----------+ 2821 | Get certificate request | /getCSRparam | Section | 2822 | parameters (OPTIONAL) | | 5.4.4 | 2823 +---------------------------------+----------------------+----------+ 2824 | Get certificate management | /getCertMgtConfig | Section | 2825 | configuration (OPTIONAL) | | 5.4.5 | 2826 +---------------------------------+----------------------+----------+ 2827 | Get enrollment voucher | /getVoucher | Section | 2828 | (OPTIONAL) | | 5.4.6 | 2829 +---------------------------------+----------------------+----------+ 2831 Table 1: HTTP endpoints 2833 Subsequent certConf, error, and pollReq messages are sent to the URI 2834 of the respective PKI management operation. 2836 < TBD: It needs to be defined if specific path values for 2837 communication between PKI management entities as specified in section 2838 6 are needed, e.g., 'forward' or 'nested'.> 2840 7.2. HTTPS transport using certificates 2842 This transport mechanism can be used by an EE and (L)RA/CA to further 2843 protect the HTTP transport as described in Section 7.1 using TLS 1.2 2844 [RFC5246] or TLS 1.3 [RFC8446] as described in [RFC2818] with 2845 certificate-based authentication. Using this transport mechanism, 2846 the CMP transport via HTTPS MUST use TLS server authentication and 2847 SHOULD use TLS client authentication. 2849 EE: 2851 o The EE SHOULD use a TLS client certificate as far as available. 2852 If no dedicated TLS certificate is available the EE SHOULD use an 2853 already existing certificate identifying the EE (e.g., a 2854 manufacturer certificate). 2856 o If no TLS certificate is available at the EE, server-only 2857 authenticated TLS SHOULD be used. 2859 o The EE MUST validate the TLS server certificate of its 2860 communication partner. 2862 (L)RA: 2864 o Each (L)RA SHOULD use a TLS client certificate on its upstream 2865 (client) interface. 2867 o Each (L)RA SHOULD use a TLS server certificate on its downstream 2868 (server) interface. 2870 o Each (L)RA MUST validate the TLS certificate of its communication 2871 partner. 2873 NOTE: The requirements for checking certificates given in [RFC5280], 2874 [RFC5246] and [RFC8446] MUST be followed for the TLS layer. 2875 Certificate status checking SHOULD be used for the TLS certificates 2876 of communication partners. 2878 7.3. HTTPS transport using shared secrets 2880 This transport mechanism can be used by an EE and (L)RA/CA to further 2881 protect the HTTP transport as described in Section 7.1 using TLS 1.2 2882 [RFC5246] or TLS 1.3 [RFC8446] as described in [RFC2818] with mutual 2883 authentication based on shared secrets as described in [RFC5054]. 2885 EE: 2887 o The EE MUST use the shared symmetric key for authentication. 2889 (L)RA: 2891 o The (L)RA MUST use the shared symmetric key for authentication. 2893 7.4. File-based transport 2895 For offline transfer file-based transport MAY be used. Offline 2896 transport is typically used between LRA and RA nodes. 2898 Connection and error handling mechanisms like those specified for 2899 HTTP in [RFC6712] need to be implemented. 2901 < TBD: Details need to be defined later > 2903 7.5. CoAP transport 2905 In constrained environments where no HTTP transport is desired or 2906 possible, CoAP [RFC7252] MAY be used instead. Connection and error 2907 handling mechanisms like those specified for HTTP in [RFC6712] may 2908 need to be implemented. 2910 Such specification is out of scope of this document and would need to 2911 be specifies in a separate document. 2913 7.6. Piggybacking on other reliable transport 2915 For online transfer where no HTTP transport is desired or possible 2916 CMP messages MAY also be transported on some other reliable protocol. 2917 Connection and error handling mechanisms like those specified for 2918 HTTP in [RFC6712] need to be implemented. 2920 Such specification is out of scope of this document and would need to 2921 be specifies in a separate document, e.g., in the scope of the 2922 respective transport protocol used. 2924 8. IANA Considerations 2926 2928 9. Security Considerations 2930 2932 10. Acknowledgements 2934 We would like to thank the various reviewers of this CMP profile. 2936 11. References 2938 11.1. Normative References 2940 [I-D.brockhaus-lamps-cmp-updates] 2941 Brockhaus, H., "CMP Updates", draft-brockhaus-lamps-cmp- 2942 updates-01 (work in progress), November 2019. 2944 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 2945 Requirement Levels", BCP 14, RFC 2119, 2946 DOI 10.17487/RFC2119, March 1997, 2947 . 2949 [RFC2986] Nystrom, M. and B. Kaliski, "PKCS #10: Certification 2950 Request Syntax Specification Version 1.7", RFC 2986, 2951 DOI 10.17487/RFC2986, November 2000, 2952 . 2954 [RFC4086] Eastlake 3rd, D., Schiller, J., and S. Crocker, 2955 "Randomness Requirements for Security", BCP 106, RFC 4086, 2956 DOI 10.17487/RFC4086, June 2005, 2957 . 2959 [RFC4210] Adams, C., Farrell, S., Kause, T., and T. Mononen, 2960 "Internet X.509 Public Key Infrastructure Certificate 2961 Management Protocol (CMP)", RFC 4210, 2962 DOI 10.17487/RFC4210, September 2005, 2963 . 2965 [RFC4211] Schaad, J., "Internet X.509 Public Key Infrastructure 2966 Certificate Request Message Format (CRMF)", RFC 4211, 2967 DOI 10.17487/RFC4211, September 2005, 2968 . 2970 [RFC5280] Cooper, D., Santesson, S., Farrell, S., Boeyen, S., 2971 Housley, R., and W. Polk, "Internet X.509 Public Key 2972 Infrastructure Certificate and Certificate Revocation List 2973 (CRL) Profile", RFC 5280, DOI 10.17487/RFC5280, May 2008, 2974 . 2976 [RFC5652] Housley, R., "Cryptographic Message Syntax (CMS)", STD 70, 2977 RFC 5652, DOI 10.17487/RFC5652, September 2009, 2978 . 2980 [RFC5785] Nottingham, M. and E. Hammer-Lahav, "Defining Well-Known 2981 Uniform Resource Identifiers (URIs)", RFC 5785, 2982 DOI 10.17487/RFC5785, April 2010, 2983 . 2985 [RFC6712] Kause, T. and M. Peylo, "Internet X.509 Public Key 2986 Infrastructure -- HTTP Transfer for the Certificate 2987 Management Protocol (CMP)", RFC 6712, 2988 DOI 10.17487/RFC6712, September 2012, 2989 . 2991 11.2. Informative References 2993 [ETSI-3GPP] 2994 3GPP, "TS33.310; Network Domain Security (NDS); 2995 Authentication Framework (AF); Release 16; V16.1.0", 2996 December 2018, 2997 . 2999 [I-D.ietf-anima-bootstrapping-keyinfra] 3000 Pritikin, M., Richardson, M., Eckert, T., Behringer, M., 3001 and K. Watsen, "Bootstrapping Remote Secure Key 3002 Infrastructures (BRSKI)", draft-ietf-anima-bootstrapping- 3003 keyinfra-31 (work in progress), December 2019. 3005 [IEC62443-3-3] 3006 IEC, "Industrial communication networks - Network and 3007 system security - Part 3-3: System security requirements 3008 and security levels", IEC 62443-3-3, August 2013, 3009 . 3011 [IEEE802.1AR] 3012 IEEE, "802.1AR Secure Device Identifier", June 2018, 3013 . 3016 [NIST-CSFW] 3017 NIST, "Framework for Improving Critical Infrastructure 3018 Cybersecurity Version 1.1", April 2018, 3019 . 3022 [RFC2818] Rescorla, E., "HTTP Over TLS", RFC 2818, 3023 DOI 10.17487/RFC2818, May 2000, 3024 . 3026 [RFC3647] Chokhani, S., Ford, W., Sabett, R., Merrill, C., and S. 3027 Wu, "Internet X.509 Public Key Infrastructure Certificate 3028 Policy and Certification Practices Framework", RFC 3647, 3029 DOI 10.17487/RFC3647, November 2003, 3030 . 3032 [RFC5054] Taylor, D., Wu, T., Mavrogiannopoulos, N., and T. Perrin, 3033 "Using the Secure Remote Password (SRP) Protocol for TLS 3034 Authentication", RFC 5054, DOI 10.17487/RFC5054, November 3035 2007, . 3037 [RFC5246] Dierks, T. and E. Rescorla, "The Transport Layer Security 3038 (TLS) Protocol Version 1.2", RFC 5246, 3039 DOI 10.17487/RFC5246, August 2008, 3040 . 3042 [RFC7252] Shelby, Z., Hartke, K., and C. Bormann, "The Constrained 3043 Application Protocol (CoAP)", RFC 7252, 3044 DOI 10.17487/RFC7252, June 2014, 3045 . 3047 [RFC7515] Jones, M., Bradley, J., and N. Sakimura, "JSON Web 3048 Signature (JWS)", RFC 7515, DOI 10.17487/RFC7515, May 3049 2015, . 3051 [RFC7519] Jones, M., Bradley, J., and N. Sakimura, "JSON Web Token 3052 (JWT)", RFC 7519, DOI 10.17487/RFC7519, May 2015, 3053 . 3055 [RFC8366] Watsen, K., Richardson, M., Pritikin, M., and T. Eckert, 3056 "A Voucher Artifact for Bootstrapping Protocols", 3057 RFC 8366, DOI 10.17487/RFC8366, May 2018, 3058 . 3060 [RFC8446] Rescorla, E., "The Transport Layer Security (TLS) Protocol 3061 Version 1.3", RFC 8446, DOI 10.17487/RFC8446, August 2018, 3062 . 3064 [UNISIG] UNISIG, "Subset-137; ERTMS/ETCS On-line Key Management 3065 FFFIS; V1.0.0", December 2015, 3066 . 3068 [W3C_XML] W3C, "Extensible Markup Language (XML) 1.0", W3C XML, 3069 November 2008, . 3071 [W3C_XML-Dsig] 3072 W3C, "XML Signature Syntax and Processing Version 2.0", 3073 W3C XML-DSIG, July 2015, 3074 . 3076 Appendix A. Additional Stuff 3078 This becomes an Appendix. 3080 Authors' Addresses 3082 Hendrik Brockhaus 3083 Siemens AG 3084 Otto-Hahn-Ring 6 3085 Munich 81739 3086 Germany 3088 Email: hendrik.brockhaus@siemens.com 3089 URI: http://www.siemens.com/ 3091 Steffen Fries 3092 Siemens AG 3093 Otto-Hahn-Ring 6 3094 Munich 81739 3095 Germany 3097 Email: steffen.fries@siemens.com 3098 URI: http://www.siemens.com/ 3100 David von Oheimb 3101 Siemens AG 3102 Otto-Hahn-Ring 6 3103 Munich 81739 3104 Germany 3106 Email: david.von.oheimb@siemens.com 3107 URI: http://www.siemens.com/