idnits 2.17.1 draft-brockhaus-lamps-lightweight-cmp-profile-03.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- No issues found here. Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- No issues found here. Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- No issues found here. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust and authors Copyright Line does not match the current year == Using lowercase 'not' together with uppercase 'MUST', 'SHALL', 'SHOULD', or 'RECOMMENDED' is not an accepted usage according to RFC 2119. Please use uppercase 'NOT' together with RFC 2119 keywords (if that is what you mean). Found 'SHOULD not' in this paragraph: When in Section 4, Section 5, and Section 6 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 (January 27, 2020) is 1544 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-02 -- 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-34 -- 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 30, 2020 Siemens 6 January 27, 2020 8 Lightweight CMP Profile 9 draft-brockhaus-lamps-lightweight-cmp-profile-03 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 30, 2020. 42 Copyright Notice 44 Copyright (c) 2020 IETF Trust and the persons identified as the 45 document authors. All rights reserved. 47 This document is subject to BCP 78 and the IETF Trust's Legal 48 Provisions Relating to IETF Documents 49 (https://trustee.ietf.org/license-info) in effect on the date of 50 publication of this document. Please review these documents 51 carefully, as they describe your rights and restrictions with respect 52 to this document. Code Components extracted from this document must 53 include Simplified BSD License text as described in Section 4.e of 54 the Trust Legal Provisions and are provided without warranty as 55 described in the Simplified BSD License. 57 Table of Contents 59 1. 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 . . . . . . . . 9 65 2.5. Scope of this document . . . . . . . . . . . . . . . . . 10 66 2.6. Structure of this document . . . . . . . . . . . . . . . 11 67 2.7. Convention and Terminology . . . . . . . . . . . . . . . 11 68 3. Architecture and use cases . . . . . . . . . . . . . . . . . 12 69 3.1. Solution architecture . . . . . . . . . . . . . . . . . . 12 70 3.2. Basic generic CMP message content . . . . . . . . . . . . 13 71 3.3. Supported use cases . . . . . . . . . . . . . . . . . . . 14 72 3.3.1. Mandatory use cases . . . . . . . . . . . . . . . . . 14 73 3.3.2. Recommended Use Cases . . . . . . . . . . . . . . . . 14 74 3.3.3. Optional use cases . . . . . . . . . . . . . . . . . 15 75 3.4. CMP message transport . . . . . . . . . . . . . . . . . . 15 76 4. Generic parts of the PKI message . . . . . . . . . . . . . . 16 77 4.1. General description of the CMP message header . . . . . . 17 78 4.2. General description of the CMP message protection . . . . 18 79 4.3. General description of CMP message extraCerts . . . . . . 19 80 5. End Entity focused certificate management use cases . . . . . 19 81 5.1. Requesting a new certificate from a PKI . . . . . . . . . 20 82 5.1.1. A certificate from a new PKI with signature 83 protection . . . . . . . . . . . . . . . . . . . . . 21 84 5.1.2. A certificate from a trusted PKI with signature 85 protection . . . . . . . . . . . . . . . . . . . . . 27 86 5.1.3. Update an existing certificate with signature 87 protection . . . . . . . . . . . . . . . . . . . . . 27 88 5.1.4. A certificate from a PKI with MAC protection . . . . 28 89 5.1.5. A certificate from a legacy PKI using PKCS#10 request 30 90 5.1.6. Generate the key pair centrally at the (L)RA/CA . . . 32 91 5.1.6.1. Using symmetric key-encryption key management 92 technique . . . . . . . . . . . . . . . . . . . . 37 93 5.1.6.2. Using key agreement key management technique . . 38 94 5.1.6.3. Using key transport key management technique . . 39 95 5.1.7. Delayed enrollment . . . . . . . . . . . . . . . . . 40 96 5.2. Revoking a certificate . . . . . . . . . . . . . . . . . 45 97 5.3. Error reporting . . . . . . . . . . . . . . . . . . . . . 47 98 5.4. Support messages . . . . . . . . . . . . . . . . . . . . 49 99 5.4.1. General message and response . . . . . . . . . . . . 49 100 5.4.2. Get CA certificates . . . . . . . . . . . . . . . . . 51 101 5.4.3. Get root CA certificate update . . . . . . . . . . . 51 102 5.4.4. Get certificate request parameters . . . . . . . . . 53 103 5.4.5. Get certificate management configuration . . . . . . 54 104 5.4.6. Get enrollment voucher . . . . . . . . . . . . . . . 56 105 6. LRA and RA focused certificate management use cases . . . . . 57 106 6.1. Forwarding of messages . . . . . . . . . . . . . . . . . 57 107 6.1.1. Not changing protection . . . . . . . . . . . . . . . 59 108 6.1.2. Replacing protection . . . . . . . . . . . . . . . . 60 109 6.1.2.1. Keeping proof-of-possession . . . . . . . . . . . 60 110 6.1.2.2. Breaking proof-of-possession . . . . . . . . . . 61 111 6.1.3. Adding Protection . . . . . . . . . . . . . . . . . . 61 112 6.1.4. Initiating delayed enrollment . . . . . . . . . . . . 61 113 6.2. Revoking certificates on behalf of another's entities . . 61 114 6.3. Error reporting . . . . . . . . . . . . . . . . . . . . . 62 115 7. CMP message transport variants . . . . . . . . . . . . . . . 63 116 7.1. HTTP transport . . . . . . . . . . . . . . . . . . . . . 63 117 7.2. HTTPS transport using certificates . . . . . . . . . . . 65 118 7.3. HTTPS transport using shared secrets . . . . . . . . . . 65 119 7.4. File-based transport . . . . . . . . . . . . . . . . . . 66 120 7.5. CoAP transport . . . . . . . . . . . . . . . . . . . . . 66 121 7.6. Piggybacking on other reliable transport . . . . . . . . 66 122 8. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 66 123 9. Security Considerations . . . . . . . . . . . . . . . . . . . 66 124 10. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 66 125 11. References . . . . . . . . . . . . . . . . . . . . . . . . . 67 126 11.1. Normative References . . . . . . . . . . . . . . . . . . 67 127 11.2. Informative References . . . . . . . . . . . . . . . . . 68 128 Appendix A. Additional Stuff . . . . . . . . . . . . . . . . . . 70 129 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 70 131 1. History of changes 133 Note: This section will be deleted in the final version of the 134 document. 136 From version 02 -> 03: 138 o Added a short summary of [RFC4210] Appendix D and E in 139 Section 2.3. 141 o Clarified some references to different sections and added some 142 clarification in response to feedback from Michael Richardson and 143 Tomas Gustavsson. 145 o Added an additional label to the operational path to address 146 multiple CAs or certificate profiles in Section 7.1. 148 From version 01 -> 02: 150 o Added some clarification on the key management techniques for 151 protection of centrally generated keys in Section 5.1.6. 153 o Added some clarifications on the certificates for root CA 154 certificate update in Section 5.4.3. 156 o Added a section to specify the usage of nested messages for RAs to 157 add an additional protection for further discussion, see 158 Section 6.1.3. 160 o Added a table containing endpoints for HTTP transport in 161 Section 7.1 to simplify addressing PKI management entities. 163 o Added some ToDos resulting from discussion with Tomas Gustavsson. 165 o Minor clarifications and changes in wording. 167 From version 00 -> 01: 169 o Added a section to specify the enrollment with a already trusted 170 PKI for further discussion, see Section 5.1.2. 172 o Complete specification of requesting a certificate from a legacy 173 PKI using a PKCS#10 [RFC2986] request in Section 5.1.5. 175 o Complete specification of adding central generation of a key pair 176 on behalf of an end entity in Section 5.1.6. 178 o Complete specification of handling delayed enrollment due to 179 asynchronous message delivery in Section 5.1.7. 181 o Complete specification of additional support messages, e.g., to 182 update a Root CA certificate or to request an RFC 8366 [RFC8366] 183 voucher, in Section 5.4. 185 o Minor changes in wording. 187 From version draft-brockhaus-lamps-industrial-cmp-profile-00 -> 188 brockhaus-lamps-lightweight-cmp-profile-00: 190 o Change focus from industrial to more multi-purpose use cases and 191 lightweight CMP profile. 193 o Incorporate the omitted confirmation into the header specified in 194 Section 4.1 and described in the standard enrollment use case in 195 Section 5.1.1 due to discussion with Tomas Gustavsson. 197 o Change from OPTIONAL to RECOMMENDED for use case 'Revoke another's 198 entities certificate' in Section 6.2, because it is regarded as 199 important functionality in many environments to enable the 200 management station to revoke EE certificates. 202 o Complete the specification of the revocation message flow in 203 Section 5.2 and Section 6.2. 205 o The CoAP based transport mechanism and piggybacking of CMP 206 messages on top of other reliable transport protocols is out of 207 scope of this document and would need to be specified in another 208 document. 210 o Further minor changes in wording. 212 2. Introduction 214 This document specifies PKI management operations supporting machine- 215 to-machine and IoT use cases. The focus lies on maximum automation 216 and interoperable implementation of all involved PKI entities from 217 end entities (EE) through an optional Local Registration Authority 218 (LRA) and the RA up to the CA. The profile makes use of the concepts 219 and syntax specified in CMP [RFC4210], CRMF [RFC4211], HTTP transfer 220 for CMP [RFC6712], and CMP Updates [I-D.brockhaus-lamps-cmp-updates]. 221 Especially CMP and CRMF are very feature-rich standards, while only a 222 limited subset of the specified functionality is needed in many 223 environments. Additionally, the standards are not always precise 224 enough on how to interpret and implement the described concepts. 225 Therefore, we aim at tailoring and specifying in more detail how to 226 use these concepts to implement lightweight automated certificate 227 management. 229 2.1. Motivation for profiling CMP 231 CMP was standardized in 1999 and is implemented in several CA 232 products. In 2005 a completely reworked and enhanced version 2 of 233 CMP [RFC4210] and CRMF [RFC4211] has been published followed by a 234 document specifying a transfer mechanism for CMP messages using http 235 [RFC6712] in 2012. 237 Though CMP is a very solid and capable protocol it could be used more 238 widely. The most important reason for not more intense application 239 of CMP appears to be that the protocol is offering a large set of 240 features and options but being not always precise enough and leaving 241 room for interpretation. On the one hand, this makes CMP applicable 242 to a very wide range of scenarios, but on the other hand a full 243 implementation of all options is unrealistic because this would take 244 enormous effort. 246 Moreover, many details of the CMP protocol have been left open or 247 have not been specified in full preciseness. The profiles specified 248 in Appendix D and E of [RFC4210] offer some more detailed certificate 249 use cases. But the specific needs of highly automated scenarios for 250 a machine-to-machine communication are not covered sufficiently. 252 As also 3GPP and UNISG already put across, profiling is a way of 253 coping with the challenges mentioned above. To profile means to take 254 advantage of the strengths of the given protocol, while explicitly 255 narrowing down the options it provides to exactly those needed for 256 the purpose(s) at hand and eliminating all identified ambiguities. 257 In this way all the general and applicable aspects of the protocol 258 can be taken over and only the peculiarities of the target scenario 259 need to be dealt with specifically. 261 Doing such a profiling for a new target environment can be a high 262 effort because the range of available options needs to be well 263 understood and the selected options need to be consistent with each 264 other and with the intended usage scenario. Since most industrial 265 use cases typically have much in common it is worth sharing this 266 effort, which is the aim of this document. Other standardization 267 bodies can then reference the profile from this document and do not 268 need to come up with individual profiles. 270 2.2. Motivation for a lightweight profile for CMP 272 The profiles specified in Appendix D and E of CMP have been developed 273 in particular to manage certificates of human end entities. With the 274 evolution of distributed systems and client-server architectures, 275 certificates for machines and applications on them have become widely 276 used. This trend has strengthened even more in emerging industrial 277 and IoT scenarios. CMP is sufficiently flexible to support these 278 very well. 280 Today's IT security architectures for industrial solutions typically 281 use certificates for endpoint authentication within protocols like 282 IPSec, TLS, or SSH. Therefore, the security of these architectures 283 highly relies upon the security and availability of the implemented 284 certificate management procedures. 286 Due to increasing security in operational networks as well as 287 availability requirements, especially on critical infrastructures and 288 systems with a high volume of certificates, a state-of-the-art 289 certificate management must be constantly available and cost- 290 efficient, which calls for high automation and reliability. The NIST 291 Cyber Security Framework [NIST-CSFW] also refers to proper processes 292 for issuance, management, verification, revocation, and audit for 293 authorized devices, users and processes involving identity and 294 credential management. Such PKI operation according to commonly 295 accepted best practices is also required in IEC 62443-3-3 296 [IEC62443-3-3] for security level 2 up to security level 4. 298 Further challenges in many industrial systems are network 299 segmentation and asynchronous communication, where PKI operation is 300 often not deployed on-site but in a more protected environment of a 301 data center or trust center. Certificate management must be able to 302 cope with such network architectures. CMP offers the required 303 flexibility and functionality, namely self-contained messages, 304 efficient polling, and support for asynchronous message transfer with 305 end-to-end security. 307 2.3. Existing CMP profiles 309 As already stated, CMP contains profiles with mandatory and optional 310 transactions in the Appendixes D and E of [RFC4210]. Those profiles 311 focus on management of human user certificates and do only partly 312 address the specific needs for certificate management automation for 313 unattended machine or application-oriented end entities. 315 [RFC4210] specifies in Appendix D the following mandatory PKI 316 management operations (all require support of, in the meantime 317 outdated, algorithms, e.g., SHA-1 and 3-DES; all operations may 318 enroll up to two certificates, one for a locally generated and 319 another optional one for a centrally generated key pair; all require 320 use of certConf/PKIConf messages for confirmation): 322 o Initial registration/certification; an (uninitialized) end entity 323 requests a (first) certificate from a CA using shared secret based 324 message authentication. The content is similar to PKI management 325 operation specified in Section 5.1.4 of this document. 327 o Certificate request; an (initialized) end entity requests a 328 certificate from a CA (for any reason) using signature or shared 329 secret based message authentication. The content is similar to 330 PKI management operation specified in Section 5.1.2 of this 331 document. 333 o Key update; an (initialized) end entity requests a certificate 334 from a CA (to update the key pair and/or corresponding certificate 335 that it already possesses) using signature or shared secret based 336 message authentication. The content is similar to PKI management 337 operation specified in Section 5.1.3 of this document. 339 Due to the two certificates that may be enrolled and the shared 340 secret based authentication, these PKI management operations focuss 341 more on the enrollment of a human users at a PKI. 343 [RFC4210] specifies in Appendix E the following optional transactions 344 (all require support of, in the meantime outdated, algorithms, e.g., 345 SHA-1 and 3-DES): 347 o Root CA key update; a root CA updates its key pair and produces a 348 CA key update announcement message that can be made available (via 349 some transport mechanism) to the relevant end entities. This 350 operation only supports a push and no pull model. The content is 351 similar to PKI management operation specified in Section 5.4.3 of 352 this document. 354 o Information request/response; an end entity sends a general 355 message to the PKI requesting details that will be required for 356 later PKI management operations. The content is similar to PKI 357 management operation specified in Section 5.4.4 and Section 5.4.5 358 of this document. 360 o Cross-certification request/response (1-way); creation of a single 361 cross-certificate (i.e., not two at once). The requesting CA MAY 362 choose who is responsible for publication of the cross-certificate 363 created by the responding CA through use of the PKIPublicationInfo 364 control. 366 o In-band initialization using external identity certificate (this 367 PKI management operation may also enroll up to two certificates 368 and requires use of certConf/PKIConf messages for confirmation as 369 specified in Appendix D of [RFC4210]). An (uninitialized) end 370 entity wishes to initialize into the PKI with a CA, CA-1. It 371 uses, for authentication purposes, a pre-existing identity 372 certificate issued by another (external) CA, CA-X. A trust 373 relationship must already have been established between CA-1 and 374 CA-X so that CA-1 can validate the EE identity certificate signed 375 by CA-X. Furthermore, some mechanism must already have been 376 established within the Personal Security Environment (PSE) of the 377 EE that would allow it to authenticate and verify PKIMessages 378 signed by CA-1. The content is similar to PKI management 379 operation specified in Section 5.1.1 of this document. The trust 380 establishment of the EE in CA-1 and of the CA/RA in CA-X can be 381 automized using, e.g., the exchange of a certificate management 382 configuration as specified in Section 5.4.5 or an enrollment 383 voucher as specified in Section 5.4.6 of this document. 385 Both Appendixes focus on EE to CA/RA PKI management operations and do 386 not address further profiling of RA to CA communication as typically 387 used for full backend automation. 389 3GPP makes use of CMP [RFC4210] in its Technical Specification 133 390 310 [ETSI-3GPP] for automatic management of IPSec certificates in 391 UMTS, LTE, and 5G backbone networks. Since 2010 a dedicated CMP 392 profile for initial certificate enrollment and update transactions 393 between end entities and the RA/CA is specified in the document. 395 UNISIG has included a CMP profile for certificate enrollment in the 396 subset 137 specifying the ETRAM/ECTS on-line key management for train 397 control systems [UNISIG] in 2015. 399 Both standardization bodies use CMP [RFC4210], CRMF [RFC4211], and 400 HTTP transfer for CMP [RFC6712] to add tailored means for automated 401 certificate management for unattended machine or application-oriented 402 end entities. 404 2.4. Compatibility with existing CMP profiles 406 The profile specified in this document is compatible with CMP 407 [RFC4210] Appendixes D and E (PKI Management Message Profiles), with 408 the following exceptions: 410 o signature-based protection is the default protection; initial 411 transactions may also use HMAC, 413 o certification of a second key pair within the same transaction is 414 not supported, 416 o proof-of-possession (POPO) with self-signature of the certTemplate 417 according to [RFC4211] section 4.1 clause 3 is the recommended 418 default POPO method (deviations are possible by EEs when 419 requesting central key generation and by (L)RAs when using 420 raVerified), 422 o confirmation of newly enrolled certificates may be omitted, and 424 o all transactions consist of request-response message pairs 425 originating at the EE, i.e., announcement messages are omitted. 427 The profile specified in this document is compatible with the CMP 428 profile for UMTS, LTE, and 5G network domain security and 429 authentication framework [ETSI-3GPP], except that: 431 o protection of initial transactions may be HMAC-based, 432 o the subject name is mandatory in certificate templates, and 434 o confirmation of newly enrolled certificates may be omitted. 436 The profile specified in this document is compatible with the CMP 437 profile for on-line key management in rail networks as specified in 438 UNISIG subset-137 [UNISIG], except that: 440 o as of RFC 4210 [RFC4210] the messageTime is required to be 441 Greenwich Mean Time coded as generalizedTime (Note: While UNISIG 442 explicitely states that the messageTime in required to be 'UTC 443 time', it is not clear if this means a coding as UTCTime or 444 generalizedTime and if other time zones than Greenwich Mean Time 445 shall be allowed. Therefore UNISG may be in conflict with 446 RFC 4210 [RFC4210]. Both time formats are described in RFC 5280 447 [RFC5280] section 4.1.2.5.), and 449 o in case the request message is MAC protected, also the response, 450 certConf, and PKIconf messages have a MAC-based protection (Note: 451 if changing to signature protection of the response the caPubs 452 field cannot be used securely anymore.). 454 2.5. Scope of this document 456 This document specifies requirements on generating messages on the 457 sender side. It does not specify strictness of verification on the 458 receiving side and how in detail to handle error cases. 460 Especially on the EE side this profile aims at a lightweight protocol 461 that can be implemented on more constrained devices. On the side of 462 the central PKI management entities the profile accepts higher 463 resource needed. 465 For the sake of robustness and preservation of security properties 466 implementations should, as far as security is not affected, adhere to 467 Postel's law: "Be conservative in what you do, be liberal in what you 468 accept from others" (often reworded as: "Be conservative in what you 469 send, be liberal in what you accept"). 471 When in Section 4, Section 5, and Section 6 a field of the ASN.1 472 syntax as defined in RFC 4210 [RFC4210] and RFC 4211 [RFC4211] is not 473 explicitly specified, it SHOULD not be used by the sending entity. 474 The receiving entity MUST NOT require its absence and if present MUST 475 gracefully handle its presence. 477 2.6. Structure of this document 479 Section 3 introduces the general PKI architecture and approach to 480 certificate management using CMP that is assumed in this document. 481 Then it enlists the PKI management opertations specified in this 482 document and describes them in general words. The list of supported 483 certificate management use cases is divided into mandatory, 484 recommended, and optional ones. 486 Section 4 profiles the CMP message header, protection, and extraCerts 487 section as they are general elements of CMP messages. 489 Section 5 profiles the exchange of CMP messages between an EE and the 490 first PKI management entities. There are various flavors of 491 certificate enrollment requests optionally with polling, revocation, 492 error handling, and general support transactions. 494 Section 6 profiles the exchange between PKI management entities. 495 These are in the first place the forwarding of messages coming from 496 or going to an EE. This includes also initiating delayed delivery of 497 messages, which involves polling. Additionally, it specifies 498 transactions where the PKI component manages certificates on behalf 499 of an EE or for itself. 501 Section 7 outlines different mechanisms for CMP message transfer, 502 namely http-based transfer as already specified in [RFC6712], using 503 an additional TLS layer, or offline file-based transport. CoAP 504 [RFC7252] and piggybacking CMP messages on other protocols is out of 505 scope and left for further documents. 507 2.7. Convention and Terminology 509 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 510 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 511 document are to be interpreted as described in RFC 2119 [RFC2119]. 513 In this document, these words will appear with that interpretation 514 only when in ALL CAPS. Lower case uses of these words are not to be 515 interpreted as carrying significance described in RFC 2119. 517 Technical terminology is used in conformance with RFC 4210 [RFC4210], 518 RFC 4211 [RFC4211], RFC 5280 [RFC5280], and IEEE 802.1AR 519 [IEEE802.1AR]. The following key words are used: 521 CA: Certification authority, which issues certificates. 523 RA: Registration authority, an optional system component to which a 524 CA delegates certificate management functions such as 525 authorization checks. 527 LRA: Local registration authority, an optional RA system component 528 with proximity to the end entities. 530 KGA: Key generation authority, an optional system component, 531 typically co-located with an LRA, RA, or CA, that offers key 532 generation services to end entities. 534 EE: End entity, a user, device, or service that holds a PKI 535 certificate. An identifier for the EE is given as the subject 536 of its certificate. 538 3. Architecture and use cases 540 3.1. Solution architecture 542 Typically, a machine EE will be equipped with a manufacturer issued 543 certificate during production. Such a manufacturer issued 544 certificate is installed during production to identify the device 545 throughout its lifetime. This manufacturer certificate can be used 546 to protect the initial enrollment of operational certificates after 547 installation of the EE in a plant or industrial network. An 548 operational certificate is issued by the owner or operator of the 549 device to identify the device during operation, e.g., within a 550 security protocol like IPSec, TLS, or SSH. In IEEE 802.1AR 551 [IEEE802.1AR] a manufacturer certificate is called IDevID certificate 552 and an operational certificate is called LDevID certificate. 554 All certificate management transactions are initiated by the EE. The 555 EE creates a CMP request message, protects it using its manufacturer 556 or operational certificate, if available, and sends it to its locally 557 reachable PKI component. This PKI component may be an LRA, RA, or 558 the CA, which checks the request, responds to it itself, or forwards 559 the request upstream to the next PKI component. In case an (L)RA 560 changes the CMP request message header or body or wants to prove a 561 successful verification or authorization, it can apply a protection 562 of its own. Especially the communication between an LRA and RA can 563 be performed synchronously or asynchronously. Synchronous 564 communication describes a timely uninterrupted communication between 565 two communication partners, as asynchronous communication is not 566 performed in a timely consistent manner, e.g., because of a delayed 567 message delivery. 569 +-----+ +-----+ +-----+ +-----+ 570 | | | | | | | | 571 | EE |<---------->| LRA |<-------------->| RA |<---------->| CA | 572 | | | | | | | | 573 +-----+ +-----+ +-----+ +-----+ 575 synchronous (a)synchronous synchronous 576 +----connection----+------connection------+----connection----+ 578 on site at operators service partner 579 +----------plant---------+-----backend services-----+-trust center-+ 581 Figure 1: Certificate management on site 583 In operation environments a layered LRA-RA-CA architecture can be 584 deployed, e.g., with LRAs bundling requests from multiple EEs at 585 dedicated locations and one (or more than one) central RA aggregating 586 the requests from multiple LRAs. Every (L)RA in this scenario will 587 have its own dedicated certificate containing an extended key usage 588 as specified in CMP Updates [I-D.brockhaus-lamps-cmp-updates] and 589 private key allowing it to protect CMP messages it processes (CMP 590 signing key/certificate). The figure above shows an architecture 591 using one LRA and one RA. It is also possible to have only an RA or 592 multiple LRAs and/or RAs. Depending on the network infrastructure, 593 the communication between different PKI components may be synchronous 594 online-communication, delayed asynchronous communication, or even 595 offline file transfer. 597 As this profile focusses on specifying the pull model, where the EE 598 always requests a specific PKI management operation. CMP response 599 messages, especially in case of central key generation, as described 600 in Section 5.1.6, can also be used to deliver proactively to the EE 601 to implement the push model. 603 Third-party CAs typically implement different variants of CMP or even 604 use proprietary interfaces for certificate management. Therefore, 605 the LRA or the RA may need to adapt the exchanged CMP messages to the 606 flavor of communication required by the CA. 608 3.2. Basic generic CMP message content 610 Section 4 specifies the generic parts of the CMP messages as used 611 later in Section 5 and Section 6. 613 o Header of a CMP message; see Section 4.1. 615 o Protection of a CMP message; see Section 4.2. 617 o ExtraCerts field of a CMP message; see Section 4.3. 619 3.3. Supported use cases 621 Following the outlined scope from Section 2.5, this section gives a 622 brief overview of the certificate management use cases specified in 623 Section 5 and Section 6 and points out, if an implementation by 624 compliant EE or PKI component is mandatory, recommended or optional. 626 3.3.1. Mandatory use cases 628 The mandatory uses case in this document shall limit the overhead of 629 certificate management for more constrained devices to the most 630 crucial types of transactions. 632 Section 5 - End Entity focused certificate management use cases 634 o Request a certificate from a new PKI with signature protection; 635 see Section 5.1.1. 637 o Request to update an existing certificate with signature 638 protection; see Section 5.1.3. 640 o Error reporting; see Section 5.3. 642 Section 6 - LRA and RA focused certificate management use cases 644 o Forward messages without changes; see Section 6.1.1. 646 o Forward messages with replaced protection and raVerified as proof- 647 of-possession; see Section 6.1.2.2. 649 o Error reporting; see Section 6.3. 651 3.3.2. Recommended Use Cases 653 Additional recommended use cases shall support some more complex 654 scenarios, that are considered as beneficial for environments with 655 more specific boundary conditions. 657 Section 5 - End Entity focused certificate management use cases 659 o Request a certificate from a PKI with MAC protection; see 660 Section 5.1.4. 662 o Handle delayed enrollment due to asynchronous message delivery; 663 see Section 5.1.7. 665 < TBD: There still some discussion ongoing if this should be 666 recommended or optional. > 668 o Revoke an own certificate. 670 Section 6 - LRA and RA focused certificate management use cases 672 o Revoke another's entities certificate. 674 3.3.3. Optional use cases 676 The optional use cases support specific requirements seen only in a 677 subset of environments. 679 Section 5 - End Entity focused certificate management use cases 681 o Request a certificate from a legacy PKI using a PKCS#10 [RFC2986] 682 request; see Section 5.1.5. 684 o Add central generation of a key pair to a certificate request; see 685 Section 5.1.6. If central key generation is supported, the key 686 agreement key management technique is REQUIRED to be supported, 687 and the key transport and symmetric key-encryption key management 688 techniques are OPTIONAL. 690 o Additional support messages, e.g., to update a Root CA certificate 691 or to request an RFC 8366 [RFC8366] voucher; see Section 5.4. 693 Section 6 - LRA and RA focused certificate management use cases 695 o Initiate delayed enrollment due to asynchronous message delivery; 696 see Section 6.1.4. 698 3.4. CMP message transport 700 On different links between PKI entities, e.g., EE<->RA and RA<->CA, 701 different transport MAY be used. As CMP has only very limited 702 requirement regarding the mechanisms used for message transport and 703 in different environments different transport mechanisms are 704 supported, e.g. HTTP, CoAP, or even offline files based, this 705 document requires no specific transport protocol to be supported by 706 all conforming implementations. 708 HTTP transfer is RESOMMENDED to use for all PKI entities, but there 709 is no transport specified as mandatory to be flexible for devices 710 with special constraines to choose whatever transport is suitable. 712 Recommended transport 713 o Transfer CMP messages using HTTP; see Section 7.1. 715 Optional transport 717 o Transfer CMP messages using HTTPS with certificate-based 718 authentication; see Section 7.2. 720 o Transfer CMP messages using HTTPS with shared-secret based 721 protection; see Section 7.3. 723 o File-based CMP message transport. 725 < TBD: Motivation see Section 7.4 > 727 < TBD: Michael Richardson proposed to also specify a CoAP based 728 message transport profile. If there is further support for this 729 profile and someone volunteering to provide the necessary input for 730 this section, I would add it to the document. > 732 4. Generic parts of the PKI message 734 To reduce redundancy in the text and to ease implementation, the 735 contents of the header, protection, and extraCerts fields of the CMP 736 messages used in the transactions specified in Section 5 and 737 Section 6 are standardized to the maximum extent possible. 738 Therefore, the generic parts of a CMP message are described centrally 739 in this section. 741 As described in section 5.1 of [RFC4210], all CMP messages have the 742 following general structure: 744 +--------------------------------------------+ 745 | PKIMessage | 746 | +----------------------------------------+ | 747 | | header | | 748 | +----------------------------------------+ | 749 | +----------------------------------------+ | 750 | | body | | 751 | +----------------------------------------+ | 752 | +----------------------------------------+ | 753 | | protection (OPTIONAL) | | 754 | +----------------------------------------+ | 755 | +----------------------------------------+ | 756 | | extraCerts (OPTIONAL) | | 757 | +----------------------------------------+ | 758 +--------------------------------------------+ 760 Figure 2: CMP message structure 762 The general contents of the message header, protection, and 763 extraCerts fields are specified in the Section 4.1 to Section 4.3. 765 In case a specific CMP message needs different contents in the 766 header, protection, or extraCerts fields, the differences are 767 described in the respective message. 769 The CMP message body contains the message-specific information. It 770 is described in the context of Section 5 and Section 6. 772 The behavior in case an error occurs while handling a CMP message is 773 described in Section 6.3. 775 4.1. General description of the CMP message header 777 This section describes the generic header field of all CMP messages 778 with signature-based protection. The only variations described here 779 are in the fields recipient, transactionID, and recipNonce of the 780 first message of a transaction. 782 In case a message has MAC-based protection the changes are described 783 in the respective section. The variations will affect the fields 784 sender, protectionAlg, and senderKID. 786 For requirements about proper random number generation please refer 787 to [RFC4086]. Any message-specific fields or variations are 788 described in the respective sections of this chapter. 790 header 791 pvno REQUIRED 792 -- MUST be set to 2 to indicate CMP V2 793 sender REQUIRED 794 -- MUST be the subject of the signing certificate used for 795 -- protection of this message 796 recipient REQUIRED 797 -- MUST be the name of the intended recipient 798 -- If this is the first message of a transaction: SHOULD be the 799 -- subject of the issuing CA certificate 800 -- In all other messages: SHOULD be the same name as in the 801 -- sender field of the previous message in this transaction 802 messageTime RECOMMENDED 803 -- MUST be the time at which the message was produced, if 804 -- present 805 protectionAlg REQUIRED 806 -- MUST be the algorithm identifier of the signature or algorithm 807 -- id-PasswordBasedMac algorithm used for calculation of the 808 -- protection bits 809 -- The signature algorithm MUST be consistent with the 810 -- SubjectPublicKeyInfo field of the signer's certificate 811 -- The hash algorithm used SHOULD be SHA-256 812 algorithm REQUIRED 813 -- MUST be the OID of the signature algorithm, like 814 -- sha256WithRSAEncryption or ecdsa-with-SHA256, or 815 -- id-PasswordBasedMac 816 senderKID RECOMMENDED 817 -- MUST be the SubjectKeyIdentifier, if available, of the 818 -- certificate used for protecting this message 819 transactionID REQUIRED 820 -- If this is the first message of a transaction: 821 -- MUST be 128 bits of random data for the start of a 822 -- transaction to reduce the probability of having the 823 -- transactionID already in use at the server 824 -- In all other messages: 825 -- MUST be the value from the previous message in the same 826 -- transaction 827 senderNonce REQUIRED 828 -- MUST be fresh 128 random bits 829 recipNonce RECOMMENDED 830 -- If this is the first message of a transaction: SHOULD be 831 -- absent 832 -- In all other messages: MUST be present and contain the value 833 -- from senderNonce of the previous message in the same 834 -- transaction 835 generalInfo OPTIONAL 836 implicitConfirm OPTIONAL 837 ImplicitConfirmValue REQUIRED 838 -- The field is optional though it only applies to 839 -- ir/cr/kur/p10cr requests and ip/cp/kup responses 840 -- ImplicitConfirmValue of the request message MUST be NULL if 841 -- the EE wants to request not to send a confirmation message 842 -- ImplicitConfirmValue MUST be set to NULL if the (L)RA/CA wants 843 -- to grant not sending a confirmation message 845 4.2. General description of the CMP message protection 847 This section describes the generic protection field of all CMP 848 messages with signature-based protection. 850 protection REQUIRED 851 -- MUST contain the signature calculated using the signature 852 -- algorithm specified in protectionAlg 854 Only for MAC-based protection major differences apply as described in 855 the respective message. 857 The CMP message protection provides, if available, message origin 858 authentication and integrity protection for the CMP message header 859 and body. The CMP message extraCerts is not covered by this 860 protection. 862 NOTE: The requirements for checking certificates given in [RFC5280] 863 MUST be followed for the CMP message protection. In case the CMP 864 signer certificates is not the CA certificate that signed the newly 865 issued certificate, certificate status checking SHOULD be used for 866 the CMP signer certificates of communication partners. 868 4.3. General description of CMP message extraCerts 870 This section describes the generic extraCerts field of all CMP 871 messages with signature-based protection. 873 extraCerts RECOMMENDED 874 -- SHOULD contain the signing certificate together with its 875 -- chain, if needed 876 -- If present, the first certificate in this field MUST 877 -- be the certificate used for signing this message 878 -- Self-signed certificates SHOULD NOT be included in 879 -- extraCerts and MUST NOT be trusted based on the listing in 880 -- extraCerts in any case 882 5. End Entity focused certificate management use cases 884 This chapter focuses on the communication of the EE and the first PKI 885 component it talks to. Depending on the network and PKI solution, 886 this will either be the LRA, the RA or the CA. 888 Profiles of the Certificate Management Protocol (CMP) [RFC4210] 889 handled in this chapter cover the following certificate management 890 use cases: 892 o Requesting a certificate from a PKI with variations like initial 893 requests and updating, central key generation and different 894 protection means 896 o Revocation of a certificate 898 o General messages for further support functions 900 The use cases mainly specify the message body of the CMP messages and 901 utilize the specification of the message header, protection and 902 extraCerts as specified in Section 5. 904 The behavior in case an error occurs is described in Section 5.3. 906 This chapter is aligned to Appendix D and Appendix E of [RFC4210]. 907 The general rules for interpretation stated in Appendix D.1 in 908 [RFC4210] need to be applied here, too. 910 This document does not mandate any specific supported algorithms like 911 Appendix D.2 of [RFC4210], [ETSI-3GPP], and [UNISIG] do. Using the 912 message sequences described here require agreement upon the 913 algorithms to support and thus the algorithm identifiers for the 914 specific target environment. 916 5.1. Requesting a new certificate from a PKI 918 There are different approaches to request a certificate from a PKI. 920 These approaches differ on the one hand in the way the EE can 921 authenticate itself to the PKI it wishes to get a new certificate 922 from and on the other hand in its capabilities to generate a proper 923 new key pair. The authentication means may be as follows: 925 o Using a certificate from a trusted PKI and the corresponding 926 private key, e.g., a manufacturer certificate 928 o Using the certificate to be updated and the corresponding private 929 key 931 o Using a shared secret known to the EE and the PKI 933 Typically, such EE requests a certificate from a CA. When the (L)RA/ 934 CA responds with a message containing a certificate, the EE MUST 935 reply with a confirmation message. The (L)RA/CA then MUST send 936 confirmation back, closing the transaction. 938 The message sequences in this section allow the EE to request 939 certification of a locally generated public-private key pair. For 940 requirements about proper random number and key generation please 941 refer to [RFC4086]. The EE MUST provide a signature-based proof-of- 942 possession of the private key associated with the public key 943 contained in the certificate request as defined by [RFC4211] section 944 4.1 case 3. To this end it is assumed that the private key can 945 technically be used as signing key. The most commonly used 946 algorithms are RSA and ECDSA, which can technically be used for 947 signature calculation regardless of potentially intended restrictions 948 of the key usage. 950 The requesting EE provides the binding of the proof-of-possession to 951 its identity by signature-based or MAC-based protection of the CMP 952 request message containing that POPO. The (L)RA/CA needs to verify 953 whether this EE is authorized to obtain a certificate with the 954 requested subject and other attributes and extensions. Especially 955 when removing the protection provided by the EE and applying a new 956 protection the (L)RA MUST verify in particular the included proof-of- 957 possession self-signature of the certTemplate using the public key of 958 the requested certificate and MUST check that the EE, as 959 authenticated by the message protection, is authorized to request a 960 certificate with the subject as specified in the certTemplate (see 961 Section 6.1.2). 963 There are several ways to install the Root CA certificate of a new 964 PKI on an EE. The installation can be performed in an out-of-band 965 manner, using general messages, a voucher [RFC8366], or other formats 966 for enrolment, or in-band of CMP by the caPubs field in the 967 certificate response message. In case the installation of the new 968 Root CA certificate is performed using the caPubs field, the 969 certificate response message MUST be properly authenticated, and the 970 sender of this message MUST be authorized to install new Root CA 971 certificates on the EE. This authorization MUST be indicated by the 972 extended key usage in the (L)RA/CA certificate as specified in CMP 973 Updates [I-D.brockhaus-lamps-cmp-updates]. 975 5.1.1. A certificate from a new PKI with signature protection 977 This message sequence should be used by an EE to request a 978 certificate of a new PKI using an existing certificate from an 979 external PKI, e.g., a manufacturer certificate, to prove its identity 980 to the new PKI. The EE already has established trust in this new PKI 981 it is about to enroll to, e.g., by configuration means. The 982 initialization request message is signature-protected using the 983 existing certificate. 985 Preconditions: 987 1 The EE MUST have a certificate enrolled by an external PKI in 988 advance to this transaction to authenticate itself to the (L)RA/CA 989 using signature-based protection, e.g., using a manufacturer 990 certificate. 992 2 The EE SHOULD know the subject name of the new CA it requests a 993 certificate from; this name MAY be established using an enrollment 994 voucher or other configuration means. If the EE does not know the 995 name of the CA, the (L)RA/CA MUST know where to route this request 996 to. 998 3 The EE MUST authenticate responses from the (L)RA/CA; trust MAY be 999 established using an enrollment voucher or other configuration 1000 means 1002 4 The (L)RA/CA MUST trust the external PKI the EE uses to 1003 authenticate itself; trust MAY be established using some 1004 configuration means 1006 This message sequence is like that given in [RFC4210] Appendix E.7. 1008 Message flow: 1010 Step# EE (L)RA/CA 1011 1 format ir 1012 2 -> ir -> 1013 3 handle, re-protect or 1014 forward ir 1015 4 format or receive ip 1016 5 possibly grant implicit 1017 confirm 1018 6 <- ip <- 1019 7 handle ip 1020 8 In case of status 1021 "rejection" in the 1022 ip message, no certConf 1023 and pkiConf are sent 1024 9 format certConf (optional) 1025 10 -> certConf -> 1026 11 handle, re-protect or 1027 forward certConf 1028 12 format or receive PKIConf 1029 13 <- pkiConf <- 1030 14 handle pkiConf (optional) 1032 For this message sequence the EE MUST include exactly one single 1033 CertReqMsg in the ir. If more certificates are required, further 1034 requests MUST be sent using separate CMP Messages. If the EE wants 1035 to omit sending a certificate confirmation message after receiving 1036 the ip to reduce the number of protocol messages exchanged in a 1037 transaction, it MUST request this by setting the implicitControlValue 1038 in the ir to NULL. 1040 If the CA accepts the request it MUST return the new certificate in 1041 the certifiedKeyPair field of the ip message. If the EE requested to 1042 omit sending a certConf message after receiving the ip, the (L)RA/CA 1043 MAY confirm this by also setting the implicitControlValue in the ip 1044 to NULL. 1046 If the EE did not request implicit confirmation or the request was 1047 not granted by the (L)RA/CA the confirmation as follows MUST be 1048 performed. If the EE successfully receives the certificate and 1049 accepts it, the EE MUST send a certConf message, which MUST be 1050 answered by the (L)RA/CA with a pkiConf message. If the (L)RA/CA 1051 does not receive the expected certConf message in time it MUST handle 1052 this like a rejection by the EE. 1054 If the certificate request was refused by the CA, the (L)RA/CA must 1055 return an ip message containing the status code "rejection" and no 1056 certifiedKeyPair field. Such an ip message MUST NOT be followed by 1057 the certConf and pkiConf messages. 1059 Detailed message description: 1061 Certification Request -- ir 1063 Field Value 1065 header 1066 -- As described in section 4.1 1068 body 1069 -- The request of the EE for a new certificate 1070 ir REQUIRED 1071 -- MUST be exactly one CertReqMsg 1072 -- If more certificates are required, further requests MUST be 1073 -- packaged in separate PKI Messages 1074 certReq REQUIRED 1075 certReqId REQUIRED 1076 -- MUST be set to 0 1077 certTemplate REQUIRED 1078 version OPTIONAL 1079 -- MUST be 2 if supplied. 1080 subject REQUIRED 1081 -- MUST contain the suggested subject name of the EE 1082 -- certificate 1083 publicKey REQUIRED 1084 algorithm REQUIRED 1085 -- MUST include the subject public key algorithm ID and value 1086 -- In case a central key generation is requested, this field 1087 -- contains the algorithm and parameter preferences of the 1088 -- requesting entity regarding the to-be-generated key pair 1089 subjectPublicKey REQUIRED 1090 -- MUST contain the public key to be included into the requested 1091 -- certificate in case of local key-generation 1092 -- MUST contain a zero-length BIT STRING in case a central key 1093 -- generation is requested 1094 -- MUST include the subject public key algorithm ID and value 1095 extensions OPTIONAL 1096 -- MAY include end-entity-specific X.509 extensions of the 1097 -- requested certificate like subject alternative name, 1098 -- key usage, and extended key usage 1099 Popo REQUIRED 1100 POPOSigningKey OPTIONAL 1101 -- MUST be used in case subjectPublicKey contains a public key 1102 -- MUST be absent in case subjectPublicKey contains a 1103 -- zero-length BIT STRING 1104 POPOSigningKey REQUIRED 1105 poposkInput PROHIBITED 1106 -- MUST NOT be used because subject and publicKey are both 1107 -- present in the certTemplate 1108 algorithmIdentifier REQUIRED 1109 -- The signature algorithm MUST be consistent with the 1110 -- publicKey field of the certTemplate 1111 -- The hash algorithm used SHOULD be SHA-256 1112 signature REQUIRED 1113 -- MUST be the signature computed over the DER-encoded 1114 -- certTemplate 1116 protection REQUIRED 1117 -- As described in section 4.2 1119 extraCerts REQUIRED 1120 -- As described in section 4.3 1122 Certification Response -- ip 1124 Field Value 1126 header 1127 -- As described in section 4.1 1129 body 1130 -- The response of the CA to the request as appropriate 1131 ip REQUIRED 1132 caPubs OPTIONAL 1133 -- MAY be used 1134 -- If used it MUST contain only the root certificate of the 1135 -- certificate contained in certOrEncCert 1136 response REQUIRED 1137 -- MUST be exactly one CertResponse 1138 certReqId REQUIRED 1139 -- MUST be set to 0 1140 status REQUIRED 1141 -- PKIStatusInfo structure MUST be present 1142 status REQUIRED 1143 -- positive values allowed: "accepted", "grantedWithMods" 1144 -- negative values allowed: "rejection" 1145 -- In case of rejection no certConf and pkiConf messages will 1146 -- be sent 1147 statusString OPTIONAL 1148 -- MAY be any human-readable text for debugging, logging or to 1149 -- display in a GUI 1150 failInfo OPTIONAL 1151 -- MUST be present if status is "rejection" and in this case 1152 -- the transaction MUST be terminated 1153 -- MUST be absent if the status is "accepted" or 1154 -- "grantedWithMods" 1155 certifiedKeyPair OPTIONAL 1156 -- MUST be present if status is "accepted" or "grantedWithMods" 1157 -- MUST be absent if status is "rejection" 1158 certOrEncCert REQUIRED 1159 -- MUST be present when certifiedKeyPair is present 1160 certificate REQUIRED 1161 -- MUST be present when certifiedKeyPair is present 1162 -- MUST contain the newly enrolled X.509 certificate 1163 privateKey OPTIONAL 1164 -- MUST be absent in case of local key-generation 1165 -- MUST contain the encrypted private key in an EnvelopedData 1166 -- structure as specified in section 5.1.5 in case the private 1167 -- key was generated centrally 1169 protection REQUIRED 1170 -- As described in section 4.2 1172 extraCerts REQUIRED 1173 -- As described in section 4.3 1174 -- MUST contain the chain of the issued certificate 1175 -- Duplicate certificates MAY be omitted 1177 Certificate Confirmation -- certConf 1179 Field Value 1181 header 1182 -- As described in section 4.1 1184 body 1185 -- The message of the EE sends confirmation to the (L)RA/CA 1186 -- to accept or reject the issued certificates 1187 certConf REQUIRED 1188 -- MUST be exactly one CertStatus 1189 CertStatus REQUIRED 1190 certHash REQUIRED 1191 -- MUST be the hash of the certificate, using the same hash 1192 -- algorithm as used to create the certificate signature 1193 certReqId REQUIRED 1194 -- MUST be set to 0 1195 status RECOMMENDED 1196 -- PKIStatusInfo structure SHOULD be present 1197 -- Omission indicates acceptance of the indicated certificate 1198 status REQUIRED 1199 -- positive values allowed: "accepted" 1200 -- negative values allowed: "rejection" 1201 statusString OPTIONAL 1202 -- MAY be any human-readable text for debugging or logging 1203 failInfo OPTIONAL 1204 -- MUST be present if status is "rejection" 1205 -- MUST be absent if the status is "accepted" 1207 protection REQUIRED 1208 -- As described in section 4.2 1209 -- MUST use the same certificate as for protection of the ir 1211 extraCerts RECOMMENDED 1212 -- SHOULD contain the protection certificate together with its 1213 -- chain 1214 -- If present, the first certificate in this field MUST be the 1215 -- certificate used for signing this message 1216 -- Self-signed certificates SHOULD NOT be included in 1217 -- extraCerts and 1218 -- MUST NOT be trusted based on the listing in extraCerts in 1219 -- any case 1221 PKI Confirmation -- pkiConf 1223 Field Value 1225 header 1226 -- As described in section 4.1 1228 body 1229 pkiConf REQUIRED 1230 -- The content of this field MUST be NULL 1232 protection REQUIRED 1233 -- As described in section 4.2 1234 -- SHOULD use the same certificate as for protection of the ip 1236 extraCerts RECOMMENDED 1237 -- SHOULD contain the protection certificate together with its 1238 -- chain 1239 -- If present, the first certificate in this field MUST be the 1240 -- certificate used for signing this message 1241 -- Self-signed certificates SHOULD NOT be included in extraCerts 1242 -- and 1243 -- MUST NOT be trusted based on the listing in extraCerts in 1244 -- any case 1246 5.1.2. A certificate from a trusted PKI with signature protection 1248 < TBD: In case the PKI is already trusted the cr/cp messages could be 1249 used instead of ir/ip. It needs to be decided, whether an additional 1250 section should be added here, or the previous section should be 1251 extended to also cover this use case. > 1253 5.1.3. Update an existing certificate with signature protection 1255 This message sequence should be used by an EE to request an update of 1256 one of the certificates it already has and that is still valid. The 1257 EE uses the certificate it wishes to update to prove its identity and 1258 possession of the private key for the certificate to be updated to 1259 the PKI. Therefore, the key update request message is signed using 1260 the certificate that is to be updated. 1262 The general message flow for this message sequence is the same as 1263 given in Section 5.1.1. 1265 Preconditions: 1267 1 The certificate the EE wishes to update MUST NOT be expired or 1268 revoked. 1270 2 A new public-private key pair SHOULD be used. 1272 The message sequence for this exchange is like that given in 1273 [RFC4210] Appendix D.6. 1275 The message sequence for this exchange is identical to that given in 1276 Section 5.1.1, with the following changes: 1278 1 The body of the first request and response MUST be kur and kup, 1279 respectively. 1281 2 Protection of the kur MUST be performed using the certificate to 1282 be updated. 1284 3 The subject field of the CertTemplate MUST contain the subject 1285 name of the existing certificate to be updated, without 1286 modifications. 1288 4 The CertTemplate MUST contain the subject, issuer and publicKey 1289 fields only. 1291 5 The regCtrl OldCertId SHOULD be used to make clear, even in case 1292 an (L)RA changes the message protection, which certificate is to 1293 be. 1295 6 The caPubs field in the kup message MUST be absent. 1297 As part of the certReq structure of the kur the control is added 1298 right after the certTemplate. 1300 controls 1301 type RECOMMENDED 1302 -- MUST be the value id-regCtrl-oldCertID, if present 1303 value 1304 issuer REQUIRED 1305 serialNumber REQUIRED 1306 -- MUST contain the issuer and serialNumber of the certificate 1307 -- to be updated 1309 5.1.4. A certificate from a PKI with MAC protection 1311 This message sequence should be used by an EE to request a 1312 certificate of a new PKI without having a certificate to prove its 1313 identity to the target PKI, but there is a shared secret established 1314 between the EE and the PKI. Therefore, the initialization request is 1315 MAC-protected using this shared secret. The (L)RA checking the MAC- 1316 protection SHOULD replace this protection according to Section 6.1.2 1317 in case the next hop does not know the shared secret. 1319 For requirements with regard to proper random number and key 1320 generation please refer to [RFC4086]. 1322 The general message flow for this message sequence is the same as 1323 given in Section 5.1.1. 1325 Preconditions: 1327 1 The EE and the (L)RA/CA MUST share a symmetric key, this MAY be 1328 established by a service technician during initial local 1329 configuration. 1331 2 The EE SHOULD know the subject name of the new CA it requests a 1332 certificate from; this name MAY be established using an enrollment 1333 voucher or other configuration means. If the EE does not know the 1334 name of the CA, the (L)RA/CA MUST know where to route this request 1335 to. 1337 3 The EE MUST authenticate responses from the (L)RA/CA; trust MAY be 1338 established using the shared symmetric key. 1340 The message sequence for this exchange is like that given in 1341 [RFC4210] Appendix D.4. 1343 The message sequence for this exchange is identical to that given in 1344 Section 5.1.1, with the following changes: 1346 1 The protection of all messages MUST be calculated using Message 1347 Authentication Code (MAC); the protectionAlg field MUST be id- 1348 PasswordBasedMac as described in section 5.1.3.1 of [RFC4210]. 1350 2 The sender MUST contain a name representing the originator of the 1351 message. The senderKID MUST contain a reference all participating 1352 entities can use to identify the symmetric key used for the 1353 protection. 1355 3 The extraCerts of the ir, certConf, and PKIConf messages MUST be 1356 absent. 1358 4 The extraCerts of the ip message MUST contain the chain of the 1359 issued certificate and root certificates SHOULD not be included 1360 and MUST NOT be trusted in any case. 1362 Part of the protectionAlg structure, where the algorithm identifier 1363 MUST be id-PasswordBasedMac, is a PBMParameter sequence. The fields 1364 of PBMParameter SHOULD remain constant for message protection 1365 throughout this certificate management transaction to reduce the 1366 computational overhead. 1368 PBMParameter REQUIRED 1369 salt REQUIRED 1370 -- MUST be the random value to salt the secret key 1371 owf REQUIRED 1372 -- MUST be the algorithm identifier for the one-way function 1373 -- used 1374 -- The one-way function SHA-1 MUST be supported due to 1375 -- [RFC4211] requirements, but SHOULD NOT be used any more 1376 -- SHA-256 SHOULD be used instead 1377 iterationCount REQUIRED 1378 -- MUST be a limited number of times the OWF is applied 1379 -- To prevent brute force and dictionary attacks a reasonable 1380 -- high number SHOULD be used 1381 mac REQUIRED 1382 -- MUST be the algorithm identifier of the MAC algorithm used 1383 -- The MAC function HMAC-SHA1 MUST be supported due to 1384 -- [RFC4211] requirements, but SHOULD NOT be used any more 1385 -- HMAC-SHA-256 SHOULD be used instead 1387 < TBD: SHA-1 is no collision resistant hash algorithm. Due to this 1388 fact the usage of SHA-1 has significantly decreased. Currently HMAC- 1389 SHA-1seems relatively secure, it is currently recommended by 1390 cryptographers to also depreciate the uses of SHA-1 in the context of 1391 HMAC calculation. Should we depreciate the support of SHA-1 here 1392 completely? > 1394 5.1.5. A certificate from a legacy PKI using PKCS#10 request 1396 This message sequence should be used by an EE to request a 1397 certificate of a legacy PKI only capable to process PKCS#10 [RFC2986] 1398 certification requests. The EE can prove its identity to the target 1399 PKI by using various protection means as described in Section 5.1.1 1400 or Section 5.1.4. 1402 In contrast to the other transactions described in Section 5.1, this 1403 transaction uses PKCS#10 [RFC2986] instead of CRMF [RFC4211] for the 1404 certificate request for compatibility reasons with legacy CA systems 1405 that require a PKCS#10 certificate request and cannot process CMP 1406 [RFC4210] or CRMF [RFC4211] messages. In such case the (L)RA must 1407 extract the PKCS#10 certificate request from the p10cr and provides 1408 it separately to the CA. 1410 The general message flow for this message sequence is the same as 1411 given in Section 5.1.1, but the public key is contained in the 1412 subjectPKInfo of the PKCS#10 certificate request. 1414 Preconditions: 1416 1 The EE MUST either have a certificate enrolled from this or any 1417 other accepted PKI, or a shared secret known to the PKI and the EE 1418 to authenticate itself to the (L)RA/CA. 1420 2 The EE SHOULD know the subject name of the CA it requests a 1421 certificate from; this name MAY be established using an enrollment 1422 voucher or other configuration means. If the EE does not know the 1423 name of the CA, the (L)RA/CA MUST know where to route this request 1424 to. 1426 3 The EE MUST authenticate responses from the (L)RA/CA; trust MAY be 1427 established by an available root certificate, using an enrollment 1428 voucher, or other configuration means. 1430 4 The (L)RA/CA MUST trust the current or the PKI the EE uses to 1431 authenticate itself; trust MAY be established by a corresponding 1432 available root certificate or using some configuration means. 1434 The profile for this exchange is identical to that given in 1435 Section 5.1.1, with the following changes: 1437 1 The body of the first request and response MUST be p10cr and cp, 1438 respectively. 1440 2 The subject name of the CA MUST be in the recipient field of the 1441 p10cr message header. 1443 3 The certReqId in the cp message MUST be 0. 1445 4 The caPubs field in the cp message SHOULD be absent. 1447 Detailed description of the p10cr message: 1449 Certification Request -- p10cr 1451 Field Value 1453 header 1454 -- As described in section 4.1 1456 body 1457 -- The request of the EE for a new certificate using a PKCS#10 1458 -- certificate request 1459 p10cr REQUIRED 1460 CertificationRequestInfo REQUIRED 1461 version REQUIRED 1462 -- MUST be set to 0 to indicate PKCS#10 V1.7 1463 subject REQUIRED 1464 -- MUST contain the suggested subject name of the EE 1465 subjectPKInfo REQUIRED 1466 -- MUST include the subject public key algorithm ID and value 1467 attributes OPTIONAL 1468 -- MAY contain a set of end-entity-specific attributes or X.509 1469 -- extensions to be included in the requested certificate or used 1470 -- otherwise 1471 signatureAlgorithm REQUIRED 1472 -- The signature algorithm MUST be consistent with the 1473 -- subjectPKInfo field. The hash algorithm used SHOULD be SHA-256 1474 signature REQUIRED 1475 -- MUST containing the self-signature for proof-of-possession 1477 protection REQUIRED 1478 -- As described in section 4.2 1480 extraCerts REQUIRED 1481 -- As described in section 4.3 1483 5.1.6. Generate the key pair centrally at the (L)RA/CA 1485 This functional extension can be applied in combination with 1486 certificate enrollment as described in Section 5.1.1 and 1487 Section 5.1.4. The functional extension can be used in case an EE is 1488 not abele or is not willing to generate is't new public-private key 1489 pair itself. It is a matter of the local implementation which 1490 central PKI components will perform the key generation. This 1491 component must have a proper (L)RA/CA certificate containing the 1492 additional extended key usage id-kp-cmcKGA to be identified by the EE 1493 as a legitimate key-generation instance. In case the (L)RA generated 1494 the new key pair for the EE, it can use Section 5.1.1 to 1495 Section 5.1.4 to request the certificate for this key pair as usual. 1497 Generally speaking, in a machine-to-machine scenario it is strongly 1498 preferable to generate public-private key pairs locally at the EE. 1499 Together with proof-of-possession of the private key in the 1500 certification request, this is to make sure that only the entity 1501 identified in the newly issued certificate is the only entity who 1502 ever hold the private key. 1504 There are some cases where an EE is not able or not willing to 1505 locally generate the new key pair. Reasons for this may be the 1506 following: 1508 o Lack of sufficient initial entropy. 1510 Note: Good random numbers are not only needed for key generation, but 1511 also for session keys and nonces in any security protocol. 1512 Therefore, we believe that a decent security architecture should 1513 anyways support good random number generation on the EE side or 1514 provide enough entropy for the RNG seed during manufacturing to 1515 guarantee good initial pseudo-random number generation. 1517 o Due to lack of computational resources, e.g., in case of RSA keys. 1519 Note: As key generation can be performed in advance to the 1520 certificate enrollment communication, it is typical not time 1521 critical. 1523 Note: Besides the initial enrollment right after the very first 1524 bootup of the device, where entropy available on the device may be 1525 insufficient, we do not see any good reason for central key 1526 generation. 1528 Note: As mentioned in Section 3.1 central key generation may be 1529 required in a push model, where the certificate response message is 1530 transfered by the (L)RA/CA to the EE without receiving a previos 1531 request message. 1533 If the EE wishes to request central key generation, it MUST fill the 1534 subjectPublicKey field in the certTemplate structure of the request 1535 message with a zero-length BIT STRING. This indicates to the (L)RA/ 1536 CA that a new key pair shall be generated centrally on behalf of the 1537 EE. 1539 Note: As the protection of centrally generated keys in the response 1540 message is being extended from EncryptedValue to EncryptedKey by CMP 1541 Updates [I-D.brockhaus-lamps-cmp-updates] also the alternative 1542 EnvelopedData can be used. In CRMF Section 2.1.9 [RFC4211] the use 1543 of EncryptedValue has been deprecated in favor of the EnvelopedData 1544 structure. Therefore, this profile specifies using EnvelopedData as 1545 specified in CMS Section 6 [RFC5652] to offer more crypto agility. 1547 +------------------------------+ 1548 | EnvelopedData | 1549 | [RFC5652] section 6 | 1550 | +--------------------------+ | 1551 | | SignedData | | 1552 | | [RFC5652] section 5 | | 1553 | | +----------------------+ | | 1554 | | | privateKey | | | 1555 | | | OCTET STRING | | | 1556 | | +----------------------+ | | 1557 | +--------------------------+ | 1558 +------------------------------+ 1560 Figure 3: Encrypted private key container 1562 The (L)RA/CA delivers the private key in the privateKey field in the 1563 certifiedKeyPair structure of the response message also containing 1564 the newly issued certificate. 1566 The private key MUST be wrapped in a SignedData structure, as 1567 specified in CMS Section 5 [RFC5652], signed by the KGA generating 1568 the key pair. The signature MUST be performed using a CMP signer 1569 certificate asserting the extended key usage kp-id-cmpKGA as 1570 described in CMP Updates [I-D.brockhaus-lamps-cmp-updates] to show 1571 the authorization to generate key pairs on behalf of an EE. 1573 This SignedData structure MUST be wrapped in an EnvelopedData 1574 structure, as specified in CMS Section 6 [RFC5652], encrypting it 1575 using a newly generated symmetric content-encryption key. 1577 Note: Instead of the specification in CMP Appendix D 4.4 [RFC4210] 1578 this content-encryption key is not generated on the EE side. As we 1579 just mentioned, central key generation should only be used in this 1580 profile in case of lack of randomness on the EE. 1582 As part of the EnvelopedData structure this content-encryption key 1583 MUST be securely provided to the EE using one of three key management 1584 techniques. The choice of the key management technique to be used by 1585 the (L)RA/CA depends on the authentication mechanism the EE choose to 1586 protect the request message, see CMP Updates section 3.4 1587 [I-D.brockhaus-lamps-cmp-updates] for more details on which key 1588 management technique to use. 1590 o MAC protected request message: The content-encryption key SHALL be 1591 protected using the symmetric key-encryption key management 1592 technique, see Section 5.1.6.1, only if the EE used MAC protection 1593 for the respected request message. 1595 o Signature protected request message using a certificate that 1596 contains a key usage extension asserting keyAgreement: The 1597 content-encryption key SHALL be protected using the key agreement 1598 key management technique, see Section 5.1.6.2, if the certificate 1599 used by the EE for signing the respective request message contains 1600 the key usage keyAgreement. If the certificate also contains the 1601 key usage keyEncipherment, the key transport key management 1602 technique SHALL NOT be used. 1604 o Signature protected request message using a certificate that 1605 contains a key usage extension asserting keyEncipherment: The 1606 content-encryption key SHALL be protected using the key transport 1607 key management technique, see Section 5.1.6.3, if the certificate 1608 used by the EE for signing the respective request message contains 1609 the key usage keyEncipherment and not keyAgreement. 1611 The key agreement key management technique can be supported by most 1612 signature algorithms, as key transport key management technique can 1613 only be supported by a very limited number of algorithms. The 1614 symmetric key-encryption key management technique shall only be used 1615 in combination with MAC protection, wich is a side-line in this 1616 profile. Therfore, this profile REQUIRES support of the key 1617 agreement key management technique and the key transport and 1618 symmetric key-encryption key management techniques are OPTIONAL. 1620 For encrypting the SignedData structure containing the private key a 1621 fresh content-encryption key MUST be generated with enough entropy 1622 with regard to the used symmetric encryption algorithm. 1624 Note: Depending on the lifetime of the certificate and the 1625 criticality of the generated private key, it is advisable to use the 1626 strongest possible symmetric encryption algorithm. Therefore, this 1627 specification recommends using at least AES-256. 1629 The detailed description of the privateKey field looks like this: 1631 privateKey OPTIONAL 1632 -- MUST be an envelopedData structure as specified in 1633 -- CMS [RFC5652] section 6 1634 version REQUIRED 1635 -- MUST be set to 2 1636 recipientInfos REQUIRED 1637 -- MUST be exactly one RecipientInfo 1638 recipientInfo REQUIRED 1639 -- MUST be either KEKRecipientInfo (see section 5.1.5.1), 1640 -- KeyAgreeRecipientInfo (see section 5.1.5.2), or 1641 -- KeyTransRecipientInfo (see section 5.1.5.3) is used 1642 encryptedContentInfo 1643 REQUIRED 1644 contentType REQUIRED 1645 -- MUST be id-signedData 1646 contentEncryptionAlgorithm 1647 REQUIRED 1648 -- MUST be the algorithm identifier of the symmetric 1649 -- content-encryption algorithm used 1650 -- As private keys need long-term protection, the use of AES-256 1651 -- or a stronger symmetric algorithm is RECOMMENDED 1652 encryptedContent REQUIRED 1653 -- MUST be the encrypted signedData structure as specified in 1654 -- CMS [RFC5652] section 5 1655 version REQUIRED 1656 -- MUST be set to 3 1657 digestAlgorithms 1658 REQUIRED 1659 -- MUST be exactly one digestAlgorithm identifier 1660 digestAlgorithmIdentifier 1661 REQUIRED 1662 -- MUST be the OID of the digest algorithm used for generating 1663 -- the signature 1664 -- The hash algorithm used SHOULD be SHA-256 1665 encapContentInfo 1666 REQUIRED 1667 -- MUST be the content that is to be signed 1668 contentType REQUIRED 1669 -- MUST be id-data 1670 content REQUIRED 1671 -- MUST be the privateKey as OCTET STRING 1672 certificates REQUIRED 1673 -- SHOULD contain the signing certificate together with its chain 1674 -- If present, the first certificate in this field MUST 1675 -- be the certificate used for signing this content 1676 -- Self-signed certificates SHOULD NOT be included 1677 -- and MUST NOT be trusted based on the listing in any case 1678 crls OPTIONAL 1679 -- MAY be present to provide status information on the signer or 1680 -- its CA certificates 1681 signerInfos REQUIRED 1682 -- MUST be exactly one signerInfo 1683 version REQUIRED 1684 -- MUST be set to 3 1685 sid REQUIRED 1686 subjectKeyIdentifier 1687 REQUIRED 1688 -- MUST be the subjectKeyIdentifier of the signer's certificate 1689 digest algorithm 1690 REQUIRED 1691 -- MUST be the same OID as in digest algorithm 1692 signatureAlgorithm 1693 REQUIRED 1694 -- MUST be the algorithm identifier of the signature algorithm 1695 -- used for calculation of the signature bits, 1696 -- like sha256WithRSAEncryption or ecdsa-with-SHA256 1697 -- The signature algorithm MUST be consistent with the 1698 -- SubjectPublicKeyInfo field of the signer's certificate 1699 signature REQUIRED 1700 -- MUST be the result of the digital signature generation 1702 5.1.6.1. Using symmetric key-encryption key management technique 1704 This key management technique can be applied in combination with the 1705 message flow specified in Section 5.1.4 using MAC protected CMP 1706 messages. The shared secret used for the MAC protection MUST also be 1707 used for the encryption of the content-encryption key but with a 1708 different seed in the PBMParameter sequence. To use this key 1709 management technique the KEKRecipientInfo structure MUST be used in 1710 the contentInfo field. 1712 The KEKRecipientInfo structure included into the envelopedData 1713 structure is specified in CMS Section 6.2.3 [RFC5652]. 1715 The detailed description of the KEKRecipientInfo structure looks like 1716 this: 1718 recipientInfo REQUIRED 1719 -- MUST be KEKRecipientInfo as specified in 1720 -- CMS section 6.2.3 [RFC5652] 1721 version REQUIRED 1722 -- MUST be set to 4 1723 kekid REQUIRED 1724 keyIdentifier REQUIRED 1725 -- MUST contain the same value as the senderKID in the respective 1726 -- request messages 1727 keyEncryptionAlgorithm 1728 REQUIRED 1729 -- MUST be id-PasswordBasedMac 1730 PBMParameter REQUIRED 1731 salt REQUIRED 1732 -- MUST be the random value to salt the secret key 1733 -- MUST be a different value than used in the PBMParameter 1734 -- data structure of the CMP message prtection in the 1735 -- header of this message 1736 owf REQUIRED 1737 -- MUST be the same value than used in the PBMParameter 1738 -- data structure in the header of this message 1739 iterationCount 1740 REQUIRED 1741 -- MUST be a limited number of times the OWF is applied 1742 -- To prevent brute force and dictionary attacks a reasonable 1743 -- high number SHOULD be used 1744 mac REQUIRED 1745 -- MUST be the same as in the contentEncryptionAlgorithm field 1746 encryptedKey REQUIRED 1747 -- MUST be the encrypted content-encryption key 1749 < TBD: To make use of a different symmetric keys for encrypting the 1750 private key and for MAC-protection of the CMP message, we derive 1751 another key using the same PBMParameter structure from CMP, even 1752 though from the perspective of field names, it is not intended to be 1753 used for deriving encryption keys. Does anyone sees a better 1754 solution here? > 1756 5.1.6.2. Using key agreement key management technique 1758 This key management technique can be applied in combination with the 1759 message flow specified in Section 5.1.1 using signature-based 1760 protected CMP messages. The public key of the EE certificate used 1761 for the signature-based protection of the request message MUST also 1762 be used for the Ephemeral-Static Diffie-Hellmann key establishment of 1763 the content-encryption key. To use this key management technique the 1764 KeyAgreeRecipientInfo structure MUST be used in the contentInfo 1765 field. 1767 The KeyAgreeRecipientInfo structure included into the envelopedData 1768 structure is specified in CMS Section 6.2.2 [RFC5652]. 1770 The detailed description of the KeyAgreeRecipientInfo structure looks 1771 like this: 1773 recipientInfo REQUIRED 1774 -- MUST be KeyAgreeRecipientInfo as specified in 1775 version REQUIRED 1776 -- MUST be set to 3 1777 originator REQUIRED 1778 -- MUST contain the originatorKey sequence 1779 algorithm REQUIRED 1780 -- MUST be the algorithm identifier of the 1781 -- static-ephemeral Diffie-Hellmann algorithm 1782 publicKey REQUIRED 1783 -- MUST be the ephemeral public key of the sending party 1784 ukm OPTIONAL 1785 -- MUST be used when 1-pass ECMQV is used 1786 keyEncryptionAlgorithm 1787 REQUIRED 1788 -- MUST be the same as in the contentEncryptionAlgorithm field 1789 recipientEncryptedKeys 1790 REQUIRED 1791 -- MUST be exactly one recipientEncryptedKey sequence 1792 recipientEncryptedKey 1793 REQUIRED 1794 rid REQUIRED 1795 rKeyId REQUIRED 1796 subjectKeyID 1797 REQUIRED 1798 -- MUST contain the same value as the senderKID in the respective 1799 -- request messages 1800 encryptedKey 1801 REQUIRED 1802 -- MUST be the encrypted content-encryption key 1804 5.1.6.3. Using key transport key management technique 1806 This key management technique can be applied in combination with the 1807 message flow specified in Section 5.1.1 using signature-based 1808 protected CMP messages. The public key of the EE certificate used 1809 for the signature-based protection of the request message MUST also 1810 be used for key encipherment of the content-encryption key. To use 1811 this key management technique the KeyTransRecipientInfo structure 1812 MUST be used in the contentInfo field. 1814 The KeyTransRecipientInfo structure included into the envelopedData 1815 structure is specified in CMS Section 6.2.1 [RFC5652]. 1817 The detailed description of the KeyTransRecipientInfo structure looks 1818 like this: 1820 recipientInfo REQUIRED 1821 -- MUST be KeyTransRecipientInfo as specified in 1822 -- CMS section 6.2.1 [RFC5652] 1823 version REQUIRED 1824 -- MUST be set to 2 1825 rid REQUIRED 1826 subjectKeyIdentifier 1827 REQUIRED 1828 -- MUST contain the same value as the senderKID in the respective 1829 -- request messages 1830 keyEncryptionAlgorithm 1831 REQUIRED 1832 -- MUST contain the key encryption algorithm identifier used for 1833 -- public key encryption 1834 encryptedKey REQUIRED 1835 -- MUST be the encrypted content-encryption key 1837 5.1.7. Delayed enrollment 1839 This functional extension can be applied in combination with 1840 certificate enrollment as described in Section 5.1.1 to 1841 Section 5.1.5. The functional extension can be used in case a (L)RA/ 1842 CA cannot respond to the certificate request in a timely manner, 1843 e.g., due to offline upstream communication or required registration 1844 officer interaction. Depending on the PKI architecture, it is not 1845 necessary that the PKI component directly communicating with the EE 1846 initiates the delayed enrollment. 1848 The PKI component initiating the delayed enrollment MUST include the 1849 status "waiting" in the response and this response MUST not contain 1850 the newly issued certificate. When receiving a response with status 1851 "waiting" the EE MUST send a poll request to the (L)RA/CA. The PKI 1852 component that initiated the delayed enrollment MUST answers with a 1853 poll response containing a checkAfter time. This value indicates the 1854 minimum number of seconds that must elapse before the EE sends 1855 another poll request. As soon as the (L)RA/CA can provide the final 1856 response message for the initial request of the EE, it MUST provide 1857 this in response to a poll request. After receiving this response, 1858 the EE can continue the original message sequence as described in the 1859 respective section of this document, e.g., send a certConf message. 1861 Typically, intermediate PKI entities SHOULD NOT change the sender and 1862 recipient nonce even in case an intermediate (L)RA modifies a request 1863 or a response message. In the special case of polling between EE and 1864 LRA with offline transport between an LRA and RA, see Section 6.1.4, 1865 an exception occurs. The EE and LRA exchange pollReq and pollRep 1866 messages handle the nonce words as described. When, after pollRep, 1867 the final response from the CA arrives at the LRA, the next response 1868 will contain the recipientNonce set to the value of the senderNonce 1869 in the original request message (copied by the CA). The LRA needs to 1870 replace the recipientNonce in this case with the senderNonce of the 1871 last pollReq because the EE will validate it in this way. 1873 Message flow: 1875 Step# EE (L)RA/CA 1876 1 format ir/cr/p10cr/kur 1877 As described in the 1878 respective section 1879 in this document 1880 2 ->ir/cr/p10cr/kur-> 1881 3 handle request as described 1882 in the respective section 1883 in this document 1884 4 in case no immediate final 1885 response is possible, 1886 receive or format ip, cp 1887 or kup message containing 1888 status "waiting" 1889 5 <- ip/cp/kup <- 1890 6 handle ip/cp/kup 1891 7 format pollReq 1892 8 -> pollReq -> 1893 9 handle, re-protect or 1894 forward pollReq 1895 10 in case the requested 1896 certificate or a 1897 corresponding response 1898 message is available, 1899 receive or format ip, cp, 1900 or kup containing the 1901 issued certificate, or 1902 format or receive pollRep 1903 with appropriate 1904 checkAfter value 1905 11 <- pollRep <- 1906 12 handle pollRep 1907 13 let checkAfter 1908 time elapse 1909 14 continue with line 7 1911 Detailed description of the first ip/cp/kup: 1913 Response with status 'waiting' -- ip/cp/kup 1915 Field Value 1917 header 1918 -- MUST contain a header as described for the first response 1919 -- message of the respective sheme 1921 body 1922 -- The response of the (L)RA/CA to the request in case no 1923 -- immediate appropriate response can be sent 1924 ip/cp/kup REQUIRED 1925 response REQUIRED 1926 -- MUST be exactly one CertResponse 1927 certReqId REQUIRED 1928 -- MUST be set to 0 1929 status REQUIRED 1930 -- PKIStatusInfo structure MUST be present 1931 status REQUIRED 1932 -- MUST be set to "waiting" 1933 statusString OPTIONAL 1934 -- MAY be any human-readable text for debugging, logging or to 1935 -- display in a GUI 1936 failInfo PROHIBITED 1937 certifiedKeyPair PROHIBITED 1939 protection REQUIRED 1940 -- MUST contain protection as described for the first response 1941 -- message of the respective profile, but 1942 -- MUST use the protection key of the (L)RA/CA initiating the 1943 -- delayed enrollment and creating this response message 1945 extraCerts REQUIRED 1946 -- MUST contain certificates as described for the first response 1947 -- message of the respective profile. 1948 -- As no new certificate is issued yet, no respective certificate 1949 -- chain is included. 1951 Polling Request -- pollReq 1953 Field Value 1955 header 1956 -- MUST contain a header as described for the certConf message 1957 -- of the respective sheme 1959 body 1960 -- The message of the EE asks for the final response or for a 1961 -- time to check again 1962 pollReq REQUIRED 1963 certReqId REQUIRED 1964 -- MUST be exactly one value 1965 -- MUST be set to 0 1967 protection REQUIRED 1968 -- MUST contain protection as described for the certConf message 1969 -- of the respective profile 1971 extraCerts OPTIONAL 1972 -- If present, it MUST contain certificates as described for the 1973 -- certConf message of the respective profile. 1975 Polling Response -- pollRep 1977 Field Value 1979 header 1980 -- MUST contain a header as described for the pkiConf message 1981 -- of the respective sheme 1983 body pollRep 1984 -- The message indicated the time to after which the EE may 1985 -- send another pollReq messaged for this transaction 1986 pollRep REQUIRED 1987 -- MUST be exactly one set of the following values 1988 certReqId REQUIRED 1989 -- MUST be set to 0 1990 checkAfter REQUIRED 1991 -- time in seconds to elapse before a new pollReq may be sent by 1992 -- the EE 1994 protection REQUIRED 1995 -- MUST contain protection as described for the pkiConf message 1996 -- of the respective profile, but 1997 -- MUST use the protection key of the (L)RA/CA that initiated the 1998 -- delayed enrollment and is creating this response message 2000 extraCerts OPTIONAL 2001 -- If present, it MUST contain certificates as described for the 2002 -- pkiConf message of the respective profile. 2004 Final response -- ip/cp/kup 2006 Field Value 2008 header 2009 -- MUST contain a header as described for the first 2010 -- response message of the respective sheme 2011 -- but the recipientNonce MUST be the senderNonce of the last 2012 -- pollReq message 2014 body 2015 -- The response of the (L)RA/CA to the initial request as 2016 -- described in the respective profile 2018 protection REQUIRED 2019 -- MUST contain protection as described for the first response 2020 -- message of the respective profile, but 2021 -- MUST use the protection key of the (L)RA/CA that initiated the 2022 -- delayed enrollment and forwarding the response message 2024 extraCerts REQUIRED 2025 -- MUST contain certificates as described for the first 2026 -- response message of the respective profile 2028 5.2. Revoking a certificate 2030 This message sequence should be used by an entity to request the 2031 revocation of a certificate. Here the revocation request is used by 2032 an EE to revoke one of its own certificates. A (L)RA could also act 2033 as an EE to revoke one of its own certificates. 2035 The revocation request message MUST be signed using the certificate 2036 that is to be revoked to prove the authorization to revoke to the 2037 PKI. The revocation request message is signature-protected using 2038 this certificate. 2040 An EE requests the revocation of an own certificate at the CA that 2041 issued this certificate. The (L)RA/CA responds with a message that 2042 contains the status of the revocation from the CA. 2044 Preconditions: 2046 1 The certificate the EE wishes to revoke is not yet expired or 2047 revoked. 2049 Message flow: 2051 Step# EE (L)RA/CA 2052 1 format rr 2053 2 -> rr -> 2054 3 handle, re-protect or 2055 forward rr 2056 4 receive rp 2057 5 <- rp <- 2058 6 handle rp 2060 For this profile, the EE MUST include exactly one RevDetails 2061 structure in the rr. In case no error occurred the response to the 2062 rr MUST be an rp message. The (L)RA/CA MUST produce a rp containing 2063 a status field with a single set of values. 2065 Detailed message description: 2067 Revocation Request -- rr 2069 Field Value 2071 header 2072 -- As described in section 4.1 2074 body 2075 -- The request of the EE to revoke its certificate 2076 rr REQUIRED 2077 -- MUST contain exactly one element of type RevDetails 2078 -- If more revocations are desired, further requests MUST be 2079 -- packaged in separate PKI Messages 2080 certDetails REQUIRED 2081 -- MUST be present and is of type CertTemplate 2082 serialNumber REQUIRED 2083 -- MUST contain the certificate serialNumber attribute of the 2084 -- X.509 certificate to be revoked 2085 issuer REQUIRED 2086 -- MUST contain the issuer attribute of the X.509 certificate to 2087 -- be revoked 2088 crlEntryDetails REQUIRED 2089 -- MUST contain exactly one reasonCode of type CRLReason (see 2090 -- [RFC5280] section 5.3.1) 2091 -- If the reason for this revocation is not known or shall not be 2092 -- published the reasonCode MUST be 0 = unspecified 2094 protection REQUIRED 2095 -- As described in section 4.2 and the private key related to the 2096 -- certificate to be revoked 2098 extraCerts REQUIRED 2099 -- As described in section 4.3 2101 Revocation Response -- rp 2103 Field Value 2105 header 2106 -- As described in section 4.1 2108 body 2109 -- The responds of the (L)RA/CA to the request as appropriate 2110 rp REQUIRED 2111 status REQUIRED 2112 -- MUST contain exactly one element of type PKIStatusInfo 2113 status REQUIRED 2114 -- positive value allowed: "accepted" 2115 -- negative value allowed: "rejection" 2116 statusString OPTIONAL 2117 -- MAY be any human-readable text for debugging, logging or to 2118 -- display in a GUI 2119 failInfo OPTIONAL 2120 -- MAY be present if and only if status is "rejection" 2122 protection REQUIRED 2123 -- As described in section 4.2 2125 extraCerts REQUIRED 2127 5.3. Error reporting 2129 This functionality should be used by an EE to report any error 2130 conditions upstream to the (L)RA/CA. Error reporting by the (L)RA 2131 downstream to the EE is described in Section 6.3. 2133 In case the error condition is related to specific details of an ip, 2134 cp, or kup response message and a confirmation is expected the error 2135 condition MUST be reported in the respective certConf message with 2136 negative contents. 2138 General error conditions, e.g., problems with the message header, 2139 protection, or extraCerts, and negative feedback on rp, pollRep, or 2140 pkiConf messages MAY be reported in the form of an error message. 2142 In both situations the error is reported in the PKIStatusInfo 2143 structure of the respective message. 2145 The (L)RA/CA MUST respond to an error message with a pkiConf message, 2146 or with another error message if any part of the header is not valid. 2147 Both sides MUST treat this message as the end of the current 2148 transaction. 2150 The PKIStatusInfo structure is used to report errors. The 2151 PKIStatusInfo structure SHOULD consist of the following fields: 2153 o status: Here the PKIStatus value rejection is the only one 2154 allowed. 2156 o statusString: Here any human-readable valid value for logging or 2157 to display in a GUI SHOULD be added. 2159 o failInfo: Here the PKIFailureInfo values MAY be used in the 2160 following way. For explanation of the reason behind a specific 2161 value, please refer to [RFC4210] Appendix F. 2163 * transactionIdInUse: This is sent in case the received request 2164 contains a transaction ID that is already in use for another 2165 transaction. An EE receiving such error message SHOULD resend 2166 the request in a new transaction using a different transaction 2167 ID. 2169 * systemUnavail or systemFailure: This is sent in case a back-end 2170 system is not available or currently not functioning correctly. 2171 An EE receiving such error message SHOULD resend the request in 2172 a new transaction after some time. 2174 Detailed error message description: 2176 Error Message -- error 2178 Field Value 2180 header 2181 -- As described in section 4.1 2183 body 2184 -- The message sent by the EE or the (L)RA/CA to indicate an 2185 -- error that occurred 2186 error REQUIRED 2187 pKIStatusInfo REQUIRED 2188 status REQUIRED 2189 -- MUST have the value "rejection" 2190 statusString RECOMMENDED 2191 -- SHOULD be any human-readable text for debugging, logging 2192 -- or to display in a GUI 2193 failInfo OPTIONAL 2194 -- MAY be present 2196 protection REQUIRED 2197 -- As described in section 4.2 2199 extraCerts OPTIONAL 2200 -- As described in section 4.3 2202 5.4. Support messages 2204 The following support messages offer on demand in-band transport of 2205 content that may be provided by the (L)RA/CA and relevant to the EE. 2206 The general messages and general response are used for this purpose. 2207 Depending on the environment, these requests are answered by the LRA, 2208 RA, or CA. 2210 The general message and general response transport InfoTypeAndValue 2211 structures. In addition to those infoType values defined in CMP 2212 [RFC4210] further OIDs MAY be defined to define new PKI management 2213 operations, or general-purpose messages as needed in a specific 2214 environment. 2216 Possible content described here address: 2218 o Request of CA certificates 2220 o Update of Root CA certificates 2222 o Parameters needed for a planned certificate request message 2224 o Voucher request and enrollment voucher exchange 2226 5.4.1. General message and response 2228 The general message transaction is similar to that given in CMP 2229 Appendix E.5 [RFC4210]. In this section the general message (genm) 2230 and general response (genp) are described. The specific 2231 InfoTypeAndValue structures are described in the following sections. 2233 The behavior in case an error occurs is described in Section 5.3. 2235 Message flow: 2237 Step# EE (L)RA/CA 2238 1 format genm 2239 2 -> genm -> 2240 3 handle, re-protect or 2241 forward genm 2242 4 format or receive genp 2243 5 <- genp <- 2244 6 handle genp 2246 Detailed message description: 2248 General Message -- genm 2249 Field Value 2251 header 2252 -- As described in section 4.1 2254 body 2255 -- The request of the EE to receive information 2256 genm REQUIRED 2257 -- MUST contain exactly one element of type 2258 -- InfoTypeAndValue 2259 infoType REQUIRED 2260 -- MUST be the OID identifying the specific scheme 2261 -- described below 2262 infoValue OPTIONAL 2263 -- MUST be as described in the specific scheme described 2264 -- below 2266 protection REQUIRED 2267 -- As described in section 4.2 2269 extraCerts REQUIRED 2270 -- As described in section 4.3 2272 General Response -- genp 2274 Field Value 2276 header 2277 -- As described in section 4.1 2279 body 2280 -- The response of the (L)RA/CA to the information request 2281 genp REQUIRED 2282 -- MUST contain exactly one element of type 2283 -- InfoTypeAndValue 2284 infoType REQUIRED 2285 -- MUST be the OID identifying the specific scheme 2286 -- described below 2287 infoValue OPTIONAL 2288 -- MUST be as described in the specific scheme described 2289 -- below 2291 protection REQUIRED 2292 -- As described in section 4.2 2294 extraCerts REQUIRED 2295 -- As described in section 4.3 2297 5.4.2. Get CA certificates 2299 This scheme can be used by an EE to request CA certificates from the 2300 (L)RA/CA. 2302 An EE requests CA certificates from the (L)RA/CA by sending a general 2303 message with OID id-it-getCaCerts. The (L)RA/CA responds with a 2304 general response with the same OID that either contains a SEQUENCE of 2305 certificates populated with the available CA intermediate and issuing 2306 CA certificates or with no content in case no CA certificate is 2307 available. 2309 < NOTE: The OID id-it-getCaCerts is not yet defined. It should be 2310 registered in the tree 1.3.6.1.5.5.7.4 (id-it) like other infoType 2311 OIDs, see CMP Appendix F [RFC4210] on page 92. > 2313 The profile for this exchange is as given in Section 5.4.1, with the 2314 following specific content: 2316 1 the body MUST contain as infoType the OID id-it-getCaCerts 2318 2 the infoValue of the request MUST be absent 2320 3 if present, the infoValue of the response MUST be caCerts field 2322 The infoValue field of the general response containing the id-it- 2323 getCaCerts OID looks like this: 2325 infoValue OPTIONAL 2326 -- MUST be absent if no CA certificate is available 2327 -- MUST be present if CA certificates are available 2328 caCerts REQUIRED 2329 -- MUST be present if infoValue is present 2330 -- MUST be a sequence of CMPCertificate 2332 5.4.3. Get root CA certificate update 2334 This scheme can be used by an EE to request an update of an existing 2335 root CA Certificate by the EE. It utilizes the CAKeyUpdAnnContent 2336 structure as described in CMP Appendix E.4 [RFC4210] as response to a 2337 respective general message. 2339 An EE requests a root CA certificate update from the (L)RA/CA by 2340 sending a general message with OID id-it-caKeyUpdateInfo as infoType 2341 and no infoValue. The (L)RA/CA responds with a general response with 2342 the same OID that either contains the update of the root CA 2343 certificate consisting of up to three certificates, or with no 2344 content in case no update is available. 2346 These three certificates are described in more detail in section 2347 4.4.1, section 6.2, and Appendix E.3 of [RFC4210]. The newWithNew 2348 certificate is the new root CA certificates and is REQUIRED to be 2349 present in the response message. The newWithOld certificate 2350 RECOMMENDED to be present in the response message though it is 2351 required for those cases where the receiving entity trusts the old 2352 root CA certificate and whishes to gain trust in the new root CA 2353 certificate. The oldWithNew certificate is OPTIONAL though it is 2354 only needed in a scenario where the requesting entity already trusts 2355 the new root CA certificate and wants to gain trust in the old root 2356 certificate. 2358 The profile for this exchange is as given in Section 5.4.1, with the 2359 following specific content: 2361 1 the body MUST contain as infoType the OID id-it-caKeyUpdateInfo 2363 2 the infoValue of the request MUST be absent 2365 3 if present, the infoValue of the response MUST be a 2366 CAKeyUpdAnnContent structure 2368 The infoValue field of the general response containing the id-it- 2369 caKeyUpdateInfo extension looks like this: 2371 infoValue OPTIONAL 2372 -- MUST be absent if no update of the root CA certificate is 2373 available 2374 -- MUST be present if an update of the root CA certificate 2375 -- is available 2376 caKeyUpdateInfo REQUIRED 2377 -- MUST be present and be of type CAKeyUpdAnnContent 2378 oldWithNew OPTIONAL 2379 -- MUST be present if infoValue is present 2380 -- MUST contain an X.509 certificate containing the old public 2381 -- root CA key signed with the new private root CA key 2382 newWithOld RECOMMENDED 2383 -- MUST be present if infoValue is present 2384 -- MUST contain an X.509 certificate containing the new public 2385 -- root CA key signed with the old private root CA key 2386 newWithNew REQUIRED 2387 -- MUST be present if infoValue is present 2388 -- MUST contain the new root CA certificate 2390 5.4.4. Get certificate request parameters 2392 This scheme can be used by an EE to request configuration parameters 2393 for a planned certificate request transaction. 2395 An EE requests certificate request parameters from the (L)RA/CA by 2396 sending a general message with OID id-it-getCSRParam. The (L)RA/CA 2397 responds with a general response with the same OID that either 2398 contains the required fields, e.g., algorithm identifier for key pair 2399 generation or other attributes and extensions or with no content in 2400 case no specific requirements are made by the (L)RA/CA. 2402 < NOTE: The OID id-it-getCSRParam is not yet defined. It should be 2403 registered in the tree 1.3.6.1.5.5.7.4 (id-it) like other infoType 2404 OIDs, see CMP Appendix F [RFC4210] on page 92. > 2406 The EE SHOULD follow the requirements from the recieved CertTemplate 2407 and the optional RSA key length. In case a field is present but the 2408 value is absent, it means that this field is required but its content 2409 has to be provided by the EE. 2411 < TBD: There is some more explanation needed to explain how to 2412 prefill the certTemplate structure. Possibly an example will help to 2413 clarify this. > 2415 The profile for this exchange is as given in Section 5.4.1, with the 2416 following specific content: 2418 1 the body MUST contain as infoType the OID id-it-getCSRParam 2420 2 the infoValue of the request MUST be absent 2422 3 if present, the infoValue of the response MUST be a SEQUENCE of a 2423 certTemplate structure and an rsaKeyLen field of type INTEGER 2425 The infoValue field of the general response containing the id-it- 2426 getCSRParam OID looks like this: 2428 infoValue OPTIONAL 2429 -- MUST be absent if no requirements are available 2430 -- MUST be present if the (L)RA/CA has any requirements on the 2431 -- content of the certificates to be requested. 2432 certTemplate REQUIRED 2433 -- MUST be present if infoValue is present 2434 -- MUST contain the prefilled certTemplate structure 2435 rsaKeyLen OPTIONAL 2436 -- This field is of type INTEGER. Any reasonable RSA key length 2437 -- SHOULD be specified if the algorithm in the 2438 -- subjectPublicKeyInfo field of the certTemplate is of type 2439 -- rsaEncryption. 2441 5.4.5. Get certificate management configuration 2443 This scheme can be used by an EE to request the current certificate 2444 management configuration information by the EE in advance to a 2445 planned certificate management transaction, e.g., in case no out-of- 2446 band transport is available. Such certificate management 2447 configuration can consist of all information the EE needs to know to 2448 generate and deliver a proper certificate request, such as 2450 o algorithm, curve, and key length for key generation 2452 o various certificate attributes and extensions to be used for the 2453 certificate request 2455 o specific host name, port and path on the RA/LRA to send this CMP 2456 request to 2458 o Infrastructure Root CA Certificate, e.g., the root of the (L)RA 2459 TLS and CMP signer certificates. 2461 There is an overlap with Section 5.4.2 with regard to transport of CA 2462 certificates and with Section 5.4.4 with regard to key generation 2463 parameter and certificate request attributes and extensions. This 2464 profile offers to request a proprietary configuration file containing 2465 all information needed in one exchange. 2467 < TBD: Especially with section 5.4.4 there is some overlap regarding 2468 algorithms, attributes and, extensions of the certificate that will 2469 be requested. It needs to be decided if both variants have a right 2470 to exist next to the other or if one option should be removed from 2471 this document. > 2472 An EE requests certificate management configuration from the (L)RA/CA 2473 by sending a general message with the OID id-it-getCertMgtConfig. 2474 The (L)RA/CA responds with a general response with the same OID that 2475 either contains a certMgtConfig field containing the configuration 2476 file encoded as OCTET STRING or with no content in case no 2477 certificate management configuration is available. 2479 < NOTE: The OID id-it-getCertMgtConfig is not yet defined. It should 2480 be registered in the tree 1.3.6.1.5.5.7.4 (id-it) like other infoType 2481 OIDs, see CMP Appendix F [RFC4210] on page 92. > 2483 The EE SHOULD use the contents of this certMgtConfig to format and 2484 deliver the certificate request. The certificate management 2485 configuration may contain contact details, e.g., like an URI and 2486 issuing CA distinguished name, where to address the request messages 2487 to and may also contain certificate request parameters as described 2488 in Section 5.4.4. 2490 The certMgtConfig field may be of any format suitable for the EE, 2491 e.g., CMS [RFC5652], JWT [RFC7519] or, XML [W3C_XML]. The 2492 certMgtConfig contents MAY be signed, e.g., like CMS SignedData 2493 [RFC5652], JWS [RFC7515] or, XML-DSig [W3C_XML-Dsig]. For 2494 interoperability the format of the certMgtConfig field should be 2495 specified in detail if needed. 2497 The profile for this exchange is as given in Section 5.4.1, with the 2498 following specific content: 2500 1 the body MUST contain as infoType the OID id-it-getCertMgtConfig 2502 2 the infoValue of the request MUST be absent 2504 3 if present, the infoValue of the response MUST be a certMgtConfig 2505 structure 2507 The infoValue field of the general response containing the id-it- 2508 getCertMgtConfig extension looks like this: 2510 infoValue OPTIONAL 2511 -- MUST be absent if no certificate management configuration 2512 -- is available 2513 -- MUST be present if the (L)RA/CA provides any certificate 2514 -- management configuration 2515 certMgtConfig REQUIRED 2516 -- MUST be present if infoValue is present 2517 -- MUST contain the certificate management configuration as OCTET 2518 -- OCTET STRING 2520 5.4.6. Get enrollment voucher 2522 This scheme can be used by an EE to request an enrollment voucher 2523 containing the root certificate of a new, additional, or alternative 2524 PKI to establish trust in this PKI, e.g., in case no out-of-band 2525 transport is available. Such an enrollment voucher can be used in 2526 advance to an enrollment to this new environment. It may contain 2527 further information depending on the use case. 2529 An EE requests an enrollment voucher from the (L)RA/CA by sending a 2530 general message. The (L)RA/CA responds with a general response with 2531 the same OID that either contains the voucher or with no content in 2532 case no voucher is available. 2534 The (L)RA MAY use the content of the voucherRequest to get an 2535 enrollment voucher from other backend components, e.g., as described 2536 in BRSKI [I-D.ietf-anima-bootstrapping-keyinfra]. The EE SHOULD use 2537 the contents of the received enrollmentVoucher to authenticate the 2538 (L)RA/CA it is about to enroll to. The enrollment voucher may for 2539 example contain the Root CA certificate of the new PKI or the CMP 2540 signer certificate of the (L)RA. The general response message MUST 2541 be properly authenticated and the sender of this message MUST be 2542 authorized to install new root certificates. One example for an 2543 enrollment voucher is specified in RFC8366 [RFC8366]. 2545 The voucherRequest and enrollmentVoucher fields may be of any format 2546 suitable for the EE, e.g., CMS [RFC5652], JWT [RFC7519] or, XML 2547 [W3C_XML]. The voucherRequest and enrollmentVoucher contents MAY 2548 contain a signature, e.g., CMS SignedData [RFC5652], JWS [RFC7515] 2549 or, XML-DSig [W3C_XML-Dsig]. For interoperability the format of the 2550 voucherRequest and enrollmentVoucher field schould be specified in 2551 detail if needed, e.g., as defined in BRSKI 2552 [I-D.ietf-anima-bootstrapping-keyinfra] and RFC8366 [RFC8366]. 2554 < TBD: The vontent of the voucherRequest and enrollmentVoucher fields 2555 can also be linited to the specufucations in BRSKI 2556 [I-D.ietf-anima-bootstrapping-keyinfra] and RFC8366 [RFC8366]. > 2558 The profile for this exchange is as given in Section 5.4.1, with the 2559 following specific content: 2561 1 the body MUST contain as infoType the OID id-it- 2562 getEnrollmentVoucher 2564 2 if present, the infoValue of the request MUST be a voucherRequest 2565 structure 2567 3 if present, the infoValue of the response MUST be an 2568 enrollmentVoucher structure 2570 The infoValue field of the general message containing the id-it- 2571 getEnrollmentVoucher extension looks like this: 2573 infoValue OPTIONAL 2574 -- MUST be absent if no voucher request is available 2575 -- MUST be present if the EE provides the voucher request 2576 voucherRequest REQUIRED 2577 -- MUST be present if infoValue is present 2578 -- MUST contain the voucher request as OCTET STRING 2580 The infoValue field of the general response containing the id-it- 2581 getEnrollmentVoucher extension looks like this: 2583 infoValue OPTIONAL 2584 -- MUST be absent if no enrollment voucher is available 2585 -- MUST be present if the (L)RA/CA provides the enrollment 2586 -- voucher 2587 enrollmentVoucher REQUIRED 2588 -- MUST be present if infoValue is present 2589 -- MUST contain the enrollment voucher as OCTET STRING 2591 6. LRA and RA focused certificate management use cases 2593 This chapter focuses on the communication of PKI backend components 2594 with each other. Depending on the network and PKI solution design, 2595 these will either be an LRA, RA or CA. 2597 Typically, an (L)RA forwards messages from downstream, but it may 2598 also reply to them itself. Besides forwarding of received messages 2599 an (L)RA could also need to revoke certificates of EEs, report 2600 errors, or may need to manage its own certificates. 2602 < TBD: In CMP Updates [I-D.brockhaus-lamps-cmp-updates] additional 2603 extended key usages like id-kp-cmpRA will be defined to indicate that 2604 a key pair is entitled to be used for signature-based protection of a 2605 CMP message by an (L)RA/CA. > 2607 6.1. Forwarding of messages 2609 Each CMP request message (i.e., ir, cr, p10cr, kur, pollReq, or 2610 certConf) or error message coming from an EE or the previous 2611 (downstream) PKI component MUST be sent to the next (upstream) PKI 2612 component. This PKI component MUST forward response messages to the 2613 next (downstream) PKI component or EE. 2615 The (L)RA SHOULD verify the protection, the syntax, the required 2616 message fields, the message type, and if applicable the authorization 2617 and the proof-of-possession of the message. Additional checks or 2618 actions MAY be applied depending on the PKI solution requirements and 2619 concept. If one of these verification procedures fails, the (L)RA 2620 SHOULD respond with a negative response message and SHOULD not 2621 forward the message further upstream. General error conditions 2622 should be handled as described in Section 5.3 and Section 6.3. 2624 An (L)RA SHOULD not change the received message if not necessary. 2625 The (L)RA SHOULD only update the message protection if it is 2626 technically necessary. Concrete PKI system specifications may define 2627 in more detail if and when to do so. 2629 This is particularly relevant in the upstream communication of a 2630 request message. 2632 Each hop in a chain of PKI components has one or more 2633 functionalities, e.g., 2635 o An (L)RA may need to verify the identities of EEs or base 2636 authorization decisions for certification request processing on 2637 specific knowledge of the local setup, e.g., by consulting an 2638 inventory or asset management system. 2640 o An (L)RA may need to add fields to certificate request messages. 2642 o An (L)RA may need to store data from a message in a database for 2643 later usage or documentation purposes. 2645 o An (L)RA may provide traversal of a network boundary. 2647 o An (L)RA may need to double-check if the messages transferred back 2648 and forth are properly protected and well formed. 2650 o An (L)RA may provide a proof that it has performed all required 2651 checks. 2653 o An (L)RA may initiate a delayed enrollment due to offline upstream 2654 communication or registration officer interaction. 2656 o An (L)RA may grant the request of an EE to omit sending a 2657 confirmation message. 2659 o An RA can collect messages from different LRAs and forward them to 2660 the CA. 2662 Therefore, the decision if a message should be forwarded 2663 o unchanged with the original protection, 2665 o unchanged with a new protection, or 2667 o changed with a new protection 2669 depends on the PKI solution design and the associated security policy 2670 (CP/CPS [RFC3647]). 2672 < TBD: In [CMP Updates] different circumstances that require adding 2673 of an additional protection by an (L)RA or batching CMP messages at 2674 an (L)RA by using the nested messages is described. It needs to be 2675 decided which of these variants should be specified here. Finally, I 2676 guess they will all be OPTIONAL. > 2678 This section specifies the different options an (L)RA may implement 2679 and use. 2681 An (L)RA MAY update the protection of a message 2683 o if the (L)RA performs changes to the header or the body of the 2684 message, 2686 o if the (L)RA needs to prove checks or validations performed on the 2687 message to one of the next (upstream) PKI components, 2689 o if the (L)RA needs to protect the message using a key and 2690 certificate from a different PKI, or 2692 o if the (L)RA needs to replace a MAC based-protection. 2694 This is particularly relevant in the upstream communication of 2695 certificate request messages. 2697 The message protection covers only the header and the body and not 2698 the extraCerts. The (L)RA MAY change the extraCerts in any of the 2699 following message adaptations, e.g., to sort or add needed or to 2700 delete needless certificates to support the next hop. This may be 2701 particularly helpful to extend upstream messages with additional 2702 certificates or to reduce the number of certificates in downstream 2703 messages when forwarding to constrained devices. 2705 6.1.1. Not changing protection 2707 This message adaptation can be used by any (L)RA to forward an 2708 original CMP message without changing the header, body or protection. 2709 In any of these cases the (L)RA acts more like a proxy, e.g., on a 2710 network boundary, implementing no specific RA-like security 2711 functionality to the PKI. 2713 This message adaptation MUST be used for forwarding kur messages that 2714 must not be approved by the respective (L)RA. 2716 6.1.2. Replacing protection 2718 The following two message adaptations can be used by any (L)RA to 2719 forward a CMP message with or without changes, but providing its own 2720 protection using its CMP signer key providing approval of this 2721 message. In this case the (L)RA acts as an actual Registration 2722 Authority (RA), which implements important security functionality of 2723 the PKI. 2725 Before replacing the existing protection by a new protection, the 2726 (L)RA MUST verify the protection provided by the EE or by the 2727 previous PKI component and approve its content including any own 2728 modifications. For certificate requests the (L)RA MUST verify in 2729 particular the included proof-of-possession self-signature of the 2730 certTemplate using the public key of the requested certificate and 2731 MUST check that the EE, as authenticated by the message protection, 2732 is authorized to request a certificate with the subject as specified 2733 in the certTemplate. 2735 In case the received message has been protected by a CA or another 2736 (L)RA, the current (L)RA MUST verify its protection and approve its 2737 content including any own modifications. For certificate requests 2738 the (L)RA MUST check that the other (L)RA, as authenticated by the 2739 message protection, is authorized to issue or forward the request. 2741 These message adaptations MUST NOT be applied to kur request messages 2742 as described in Section 5.1.3 since their original protection using 2743 the key and certificate to be updated needs to be preserved, unless 2744 the regCtrl OldCertId is used to clearly identify the certificate to 2745 be updated. 2747 6.1.2.1. Keeping proof-of-possession 2749 This message adaptation can be used by any (L)RA to forward a CMP 2750 message with or without modifying the message header or body while 2751 preserving any included proof-of-possession. 2753 By replacing the existing protection using its own CMP signer key the 2754 (L)RA provides a proof of verifying and approving of the message as 2755 described above. 2757 In case the (L)RA modifies the certTemplate of an ir or cr message, 2758 the message adaptation in Section 6.1.2.2 needs to be applied 2759 instead. 2761 6.1.2.2. Breaking proof-of-possession 2763 This message adaptation can be used by any (L)RA to forward an ir or 2764 cr message with modifications of the certTemplate i.e., modification, 2765 addition, or removal of fields. Such changes will break the proof- 2766 of-possession provided by the EE in the original message. 2768 By replacing the existing or applying an initial protection using its 2769 own CMP signer key the (L)RA provides a proof of verifying and 2770 approving the new message as described above. 2772 In addition to the above the (L)RA MUST verify in particular the 2773 proof-of-possession contained in the original message as described 2774 above. If these checks were successfully performed the (L)RA MUST 2775 change the popo to raVerified. 2777 The popo field MUST contain the raVerified choice in the certReq 2778 structure of the modified message as follows: 2780 popo 2781 raVerified REQUIRED 2782 -- MUST have the value NULL and indicates that the (L)RA 2783 -- verified the popo of the original message. 2785 6.1.3. Adding Protection 2787 < TBD: In [CMP Updates] different circumstances that require adding 2788 of an additional protection by an (L)RA or batching CMP messages at 2789 an (L)RA by using the nested messages is described. It needs to be 2790 decided which of these variants should be specified here. Finally, I 2791 guess they will all be OPTIONAL. > 2793 6.1.4. Initiating delayed enrollment 2795 This message adaptation can be used by an (L)RA to initiate delayed 2796 enrollment. In this case a (L)RA/CA MUST add the status waiting in 2797 the response message. The (L)RA/CA MUST then reply to the pollReq 2798 messages as described in Section 5.1.7. 2800 6.2. Revoking certificates on behalf of another's entities 2802 This message sequence can be used by an (L)RA to revoke a certificate 2803 of any other entity. This revocation request message MUST be signed 2804 by the (L)RA using its own CMP signer key to prove to the PKI 2805 authorization to revoke the certificate on behalf of the EE. 2807 The general message flow for this profile is the same as given in 2808 section Section 5.2. 2810 Preconditions: 2812 1 the certificate to be revoked MUST be known to the (L)RA 2814 2 the (L)RA MUST have the authorization to revoke the certificates 2815 of other entities issued by the corresponding CA 2817 The profile for this exchange is identical to that given in section 2818 Section 5.2, with the following changes: 2820 1 it is not required that the certificate to be revoked is not yet 2821 expired or revoked 2823 2 the (L)RA acts as EE for this message exchange 2825 3 the rr messages MUST be signed using the CMP signer key of the 2826 (L)RA. 2828 6.3. Error reporting 2830 This functionality should be used by the (L)RA to report any error 2831 conditions downstream to the EE. Potential error reporting by the EE 2832 upstream to the (L)RA/CA is described in Section 5.3. 2834 In case the error condition is related to specific details of an ir, 2835 cr, p10cr, or kur request message it MUST be reported in the specific 2836 response message, i.e., an ip, cp, or kup with negative contents. 2838 General error conditions, e.g., problems with the message header, 2839 protection, or extraCerts, and negative feedback on rr, pollReq, 2840 certConf, or error messages MUST be reported in the form of an error 2841 message. 2843 In both situations the (L)RA reports the errors in the PKIStatusInfo 2844 structure of the respective message as described in Section 5.3. 2846 An EE receiving any such negative feedback SHOULD log the error 2847 appropriately and MUST terminate the current transaction. 2849 7. CMP message transport variants 2851 The CMP messages are designed to be self-contained, such that in 2852 principle any transport can be used. HTTP SHOULD be used for online 2853 transport while file-based transport MAY be used in case offline 2854 transport is required. In case HTTP transport is not desired or 2855 possible, CMP messages MAY also be piggybacked on any other reliable 2856 transport protocol, e.g., CoAP [RFC7252]. 2858 Independently of the means of transport it could happen that messages 2859 are lost, or a communication partner does not respond. In order to 2860 prevent waiting indefinitely, each CMP client component SHOULD use a 2861 configurable per-request timeout, and each CMP server component 2862 SHOULD use a configurable per-response timeout in case a further 2863 message is to be expected from the client side. In this way a 2864 hanging transaction can be closed cleanly with an error and related 2865 resources (for instance, any cached extraCerts) can be freed. 2867 7.1. HTTP transport 2869 This transport mechanism can be used by an EE and (L)RA/CA to 2870 transfer CMP messages over HTTP. If HTTP transport is used the 2871 specifications as described in [RFC6712] MUST be followed. 2873 Each PKI management entity supporting HTTP(S) transport MUST support 2874 the use of the path-prefix of '/.well-known/' as defined in [RFC5785] 2875 and the registered name of 'cmp' to ease interworking in a multi- 2876 vendor environment. 2878 The CMP client MUST be configured with sufficient information to form 2879 the CMP server URI. This MUST be at least the authority portion of 2880 the URI, e.g., 'www.example.com:80', or the full operational path of 2881 the CA/RA. An additional arbitrary label, e.g., 'arbitraryLabel1', 2882 MAY be configured as a separate component or as part of the full 2883 operational path to provide further information to address multiple 2884 CAs or certificate profiles. A valid full operational path can look 2885 like this: 2887 1 http://www.example.com/.well-known/cmp/keyupdate 2889 2 http://www.example.com/.well-known/cmp/arbitraryLabel1/keyupdate 2890 PKI management operations MUST use the following URI path: 2892 +---------------------------------+----------------------+----------+ 2893 | PKI management operation | Path | Details | 2894 +---------------------------------+----------------------+----------+ 2895 | Enroll client to new PKI | /initialization | Section | 2896 | (REQUIRED) | | 5.1.1 | 2897 +---------------------------------+----------------------+----------+ 2898 | Enroll client to existing PKI | /certification | Section | 2899 | (OPTIONAL) | | 5.1.2 | 2900 +---------------------------------+----------------------+----------+ 2901 | Update client certificate | /keyupdate | Section | 2902 | (REQUIRED) | | 5.1.3 | 2903 +---------------------------------+----------------------+----------+ 2904 | Enroll client using PKCS#10 | /p10 | Section | 2905 | (OPTIONAL) | | 5.1.5 | 2906 +---------------------------------+----------------------+----------+ 2907 | Enroll client using central key | /serverkeygen | Section | 2908 | generation (OPTIONAL) | | 5.1.6 | 2909 +---------------------------------+----------------------+----------+ 2910 | Revoke client certificate | /revocation | Section | 2911 | (RECOMMENDED) | | 5.2 | 2912 +---------------------------------+----------------------+----------+ 2913 | Get CA certificates (OPTIONAL) | /getCAcert | Section | 2914 | | | 5.4.2 | 2915 +---------------------------------+----------------------+----------+ 2916 | Get root CA certificate update | /getRootCAcertUpdate | Section | 2917 | (OPTIONAL) | | 5.4.3 | 2918 +---------------------------------+----------------------+----------+ 2919 | Get certificate request | /getCSRparam | Section | 2920 | parameters (OPTIONAL) | | 5.4.4 | 2921 +---------------------------------+----------------------+----------+ 2922 | Get certificate management | /getCertMgtConfig | Section | 2923 | configuration (OPTIONAL) | | 5.4.5 | 2924 +---------------------------------+----------------------+----------+ 2925 | Get enrollment voucher | /getVoucher | Section | 2926 | (OPTIONAL) | | 5.4.6 | 2927 +---------------------------------+----------------------+----------+ 2929 Table 1: HTTP endpoints 2931 Subsequent certConf, error, and pollReq messages are sent to the URI 2932 of the respective PKI management operation. 2934 < TBD: It needs to be defined if specific path values for 2935 communication between PKI management entities as specified in section 2936 6 are needed, e.g., 'forward' or 'nested'.> 2938 7.2. HTTPS transport using certificates 2940 This transport mechanism can be used by an EE and (L)RA/CA to further 2941 protect the HTTP transport as described in Section 7.1 using TLS 1.2 2942 [RFC5246] or TLS 1.3 [RFC8446] as described in [RFC2818] with 2943 certificate-based authentication. Using this transport mechanism, 2944 the CMP transport via HTTPS MUST use TLS server authentication and 2945 SHOULD use TLS client authentication. 2947 EE: 2949 o The EE SHOULD use a TLS client certificate as far as available. 2950 If no dedicated TLS certificate is available the EE SHOULD use an 2951 already existing certificate identifying the EE (e.g., a 2952 manufacturer certificate). 2954 o If no TLS certificate is available at the EE, server-only 2955 authenticated TLS SHOULD be used. 2957 o The EE MUST validate the TLS server certificate of its 2958 communication partner. 2960 (L)RA: 2962 o Each (L)RA SHOULD use a TLS client certificate on its upstream 2963 (client) interface. 2965 o Each (L)RA SHOULD use a TLS server certificate on its downstream 2966 (server) interface. 2968 o Each (L)RA MUST validate the TLS certificate of its communication 2969 partner. 2971 NOTE: The requirements for checking certificates given in [RFC5280], 2972 [RFC5246] and [RFC8446] MUST be followed for the TLS layer. 2973 Certificate status checking SHOULD be used for the TLS certificates 2974 of communication partners. 2976 7.3. HTTPS transport using shared secrets 2978 This transport mechanism can be used by an EE and (L)RA/CA to further 2979 protect the HTTP transport as described in Section 7.1 using TLS 1.2 2980 [RFC5246] or TLS 1.3 [RFC8446] as described in [RFC2818] with mutual 2981 authentication based on shared secrets as described in [RFC5054]. 2983 EE: 2985 o The EE MUST use the shared symmetric key for authentication. 2987 (L)RA: 2989 o The (L)RA MUST use the shared symmetric key for authentication. 2991 7.4. File-based transport 2993 For offline transfer file-based transport MAY be used. Offline 2994 transport is typically used between LRA and RA nodes. 2996 Connection and error handling mechanisms like those specified for 2997 HTTP in [RFC6712] need to be implemented. 2999 < TBD: Details need to be defined later > 3001 7.5. CoAP transport 3003 In constrained environments where no HTTP transport is desired or 3004 possible, CoAP [RFC7252] MAY be used instead. Connection and error 3005 handling mechanisms like those specified for HTTP in [RFC6712] may 3006 need to be implemented. 3008 Such specification is out of scope of this document and would need to 3009 be specifies in a separate document. 3011 7.6. Piggybacking on other reliable transport 3013 For online transfer where no HTTP transport is desired or possible 3014 CMP messages MAY also be transported on some other reliable protocol. 3015 Connection and error handling mechanisms like those specified for 3016 HTTP in [RFC6712] need to be implemented. 3018 Such specification is out of scope of this document and would need to 3019 be specifies in a separate document, e.g., in the scope of the 3020 respective transport protocol used. 3022 8. IANA Considerations 3024 3026 9. Security Considerations 3028 3030 10. Acknowledgements 3032 We would like to thank the various reviewers of this CMP profile. 3034 11. References 3036 11.1. Normative References 3038 [I-D.brockhaus-lamps-cmp-updates] 3039 Brockhaus, H., "CMP Updates", draft-brockhaus-lamps-cmp- 3040 updates-02 (work in progress), December 2019. 3042 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 3043 Requirement Levels", BCP 14, RFC 2119, 3044 DOI 10.17487/RFC2119, March 1997, 3045 . 3047 [RFC2986] Nystrom, M. and B. Kaliski, "PKCS #10: Certification 3048 Request Syntax Specification Version 1.7", RFC 2986, 3049 DOI 10.17487/RFC2986, November 2000, 3050 . 3052 [RFC4086] Eastlake 3rd, D., Schiller, J., and S. Crocker, 3053 "Randomness Requirements for Security", BCP 106, RFC 4086, 3054 DOI 10.17487/RFC4086, June 2005, 3055 . 3057 [RFC4210] Adams, C., Farrell, S., Kause, T., and T. Mononen, 3058 "Internet X.509 Public Key Infrastructure Certificate 3059 Management Protocol (CMP)", RFC 4210, 3060 DOI 10.17487/RFC4210, September 2005, 3061 . 3063 [RFC4211] Schaad, J., "Internet X.509 Public Key Infrastructure 3064 Certificate Request Message Format (CRMF)", RFC 4211, 3065 DOI 10.17487/RFC4211, September 2005, 3066 . 3068 [RFC5280] Cooper, D., Santesson, S., Farrell, S., Boeyen, S., 3069 Housley, R., and W. Polk, "Internet X.509 Public Key 3070 Infrastructure Certificate and Certificate Revocation List 3071 (CRL) Profile", RFC 5280, DOI 10.17487/RFC5280, May 2008, 3072 . 3074 [RFC5652] Housley, R., "Cryptographic Message Syntax (CMS)", STD 70, 3075 RFC 5652, DOI 10.17487/RFC5652, September 2009, 3076 . 3078 [RFC5785] Nottingham, M. and E. Hammer-Lahav, "Defining Well-Known 3079 Uniform Resource Identifiers (URIs)", RFC 5785, 3080 DOI 10.17487/RFC5785, April 2010, 3081 . 3083 [RFC6712] Kause, T. and M. Peylo, "Internet X.509 Public Key 3084 Infrastructure -- HTTP Transfer for the Certificate 3085 Management Protocol (CMP)", RFC 6712, 3086 DOI 10.17487/RFC6712, September 2012, 3087 . 3089 11.2. Informative References 3091 [ETSI-3GPP] 3092 3GPP, "TS33.310; Network Domain Security (NDS); 3093 Authentication Framework (AF); Release 16; V16.1.0", 3094 December 2018, 3095 . 3097 [I-D.ietf-anima-bootstrapping-keyinfra] 3098 Pritikin, M., Richardson, M., Eckert, T., Behringer, M., 3099 and K. Watsen, "Bootstrapping Remote Secure Key 3100 Infrastructures (BRSKI)", draft-ietf-anima-bootstrapping- 3101 keyinfra-34 (work in progress), January 2020. 3103 [IEC62443-3-3] 3104 IEC, "Industrial communication networks - Network and 3105 system security - Part 3-3: System security requirements 3106 and security levels", IEC 62443-3-3, August 2013, 3107 . 3109 [IEEE802.1AR] 3110 IEEE, "802.1AR Secure Device Identifier", June 2018, 3111 . 3114 [NIST-CSFW] 3115 NIST, "Framework for Improving Critical Infrastructure 3116 Cybersecurity Version 1.1", April 2018, 3117 . 3120 [RFC2818] Rescorla, E., "HTTP Over TLS", RFC 2818, 3121 DOI 10.17487/RFC2818, May 2000, 3122 . 3124 [RFC3647] Chokhani, S., Ford, W., Sabett, R., Merrill, C., and S. 3125 Wu, "Internet X.509 Public Key Infrastructure Certificate 3126 Policy and Certification Practices Framework", RFC 3647, 3127 DOI 10.17487/RFC3647, November 2003, 3128 . 3130 [RFC5054] Taylor, D., Wu, T., Mavrogiannopoulos, N., and T. Perrin, 3131 "Using the Secure Remote Password (SRP) Protocol for TLS 3132 Authentication", RFC 5054, DOI 10.17487/RFC5054, November 3133 2007, . 3135 [RFC5246] Dierks, T. and E. Rescorla, "The Transport Layer Security 3136 (TLS) Protocol Version 1.2", RFC 5246, 3137 DOI 10.17487/RFC5246, August 2008, 3138 . 3140 [RFC7252] Shelby, Z., Hartke, K., and C. Bormann, "The Constrained 3141 Application Protocol (CoAP)", RFC 7252, 3142 DOI 10.17487/RFC7252, June 2014, 3143 . 3145 [RFC7515] Jones, M., Bradley, J., and N. Sakimura, "JSON Web 3146 Signature (JWS)", RFC 7515, DOI 10.17487/RFC7515, May 3147 2015, . 3149 [RFC7519] Jones, M., Bradley, J., and N. Sakimura, "JSON Web Token 3150 (JWT)", RFC 7519, DOI 10.17487/RFC7519, May 2015, 3151 . 3153 [RFC8366] Watsen, K., Richardson, M., Pritikin, M., and T. Eckert, 3154 "A Voucher Artifact for Bootstrapping Protocols", 3155 RFC 8366, DOI 10.17487/RFC8366, May 2018, 3156 . 3158 [RFC8446] Rescorla, E., "The Transport Layer Security (TLS) Protocol 3159 Version 1.3", RFC 8446, DOI 10.17487/RFC8446, August 2018, 3160 . 3162 [UNISIG] UNISIG, "Subset-137; ERTMS/ETCS On-line Key Management 3163 FFFIS; V1.0.0", December 2015, 3164 . 3166 [W3C_XML] W3C, "Extensible Markup Language (XML) 1.0", W3C XML, 3167 November 2008, . 3169 [W3C_XML-Dsig] 3170 W3C, "XML Signature Syntax and Processing Version 2.0", 3171 W3C XML-DSIG, July 2015, 3172 . 3174 Appendix A. Additional Stuff 3176 This becomes an Appendix. 3178 Authors' Addresses 3180 Hendrik Brockhaus 3181 Siemens AG 3182 Otto-Hahn-Ring 6 3183 Munich 81739 3184 Germany 3186 Email: hendrik.brockhaus@siemens.com 3187 URI: http://www.siemens.com/ 3189 Steffen Fries 3190 Siemens AG 3191 Otto-Hahn-Ring 6 3192 Munich 81739 3193 Germany 3195 Email: steffen.fries@siemens.com 3196 URI: http://www.siemens.com/ 3198 David von Oheimb 3199 Siemens AG 3200 Otto-Hahn-Ring 6 3201 Munich 81739 3202 Germany 3204 Email: david.von.oheimb@siemens.com 3205 URI: http://www.siemens.com/