idnits 2.17.1 draft-ietf-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 : ---------------------------------------------------------------------------- == There are 2 instances of lines with non-RFC6890-compliant IPv4 addresses in the document. If these are example addresses, they should be changed. 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 3, Section 4, and Section 5 a field of the ASN.1 syntax as defined in RFC 4210 [RFC4210] and RFC 4211 [RFC4211] is not explicitly specified, it SHOULD not be used by the sending entity. The receiving entity MUST NOT require its absence and if present MUST gracefully handle its presence. == Using lowercase 'not' together with uppercase 'MUST', 'SHALL', 'SHOULD', or 'RECOMMENDED' is not an accepted usage according to RFC 2119. Please use uppercase 'NOT' together with RFC 2119 keywords (if that is what you mean). Found 'SHOULD not' in this paragraph: 4 The extraCerts of the ip message MUST contain the chain of the issued certificate and root certificates SHOULD not be included and MUST NOT be directly 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 'SHOULD not' in this paragraph: -- MUST be id-ct-KP-aKeyPackage as specified in [RFC5958] content REQUIRED AsymmetricKeyPackage REQUIRED OneAsymmetricKey REQUIRED -- MUST be exactly one asymmetric key package version REQUIRED -- The version MUST be v2 privateKeyAlgorithm REQUIRED -- The privateKeyAlgorithm field MUST contain -- the OID of the asymmetric key pair algorithm privateKey REQUIRED -- The privateKey MUST be in the privateKey field Attributes OPTIONAL -- The attributes field SHOULD not be used publicKey REQUIRED -- The publicKey MUST be in the publicKey field certificates REQUIRED -- SHOULD contain the certificate, for the private key used -- to sign the content, together with its chain -- If present, the first certificate in this field MUST -- be the certificate used for signing this content -- Self-signed certificates SHOULD NOT be included -- and MUST NOT be trusted based on the listing in any case crls OPTIONAL -- MAY be present to provide status information on the signer or -- its CA certificates signerInfos REQUIRED -- MUST be exactly one signerInfo version REQUIRED -- MUST be set to 3 sid REQUIRED subjectKeyIdentifier REQUIRED -- MUST be the subjectKeyIdentifier of the signer's certificate digestAlgorithm REQUIRED -- MUST be the same OID as in digest algorithm signatureAlgorithm REQUIRED -- MUST be the algorithm identifier of the signature algorithm -- used for calculation of the signature bits, -- like sha256WithRSAEncryption or ecdsa-with-SHA256 -- The signature algorithm MUST be consistent with the -- subjectPublicKeyInfo field of the signer's certificate signature REQUIRED -- MUST be the result of the digital signature generation == 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 PKI management entity SHOULD verify the protection, the syntax, the required message fields, the message type, and if applicable the authorization and the proof-of-possession of the message. Additional checks or actions MAY be applied depending on the PKI solution requirements and concept. If one of these verification procedures fails, the (L)RA SHOULD respond with a negative response message and SHOULD not forward the message further upstream. General error conditions should be handled as described in Section 4.3 and Section 5.3. == Using lowercase 'not' together with uppercase 'MUST', 'SHALL', 'SHOULD', or 'RECOMMENDED' is not an accepted usage according to RFC 2119. Please use uppercase 'NOT' together with RFC 2119 keywords (if that is what you mean). Found 'SHOULD not' in this paragraph: A PKI management entity SHOULD not change the received message if not necessary. The PKI management entity 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 (October 2, 2020) is 1273 days in the past. Is this intentional? Checking references for intended status: Proposed Standard ---------------------------------------------------------------------------- (See RFCs 3967 and 4897 for information about using normative references to lower-maturity documents in RFCs) == Missing Reference: 'RFC8018' is mentioned on line 1940, but not defined -- Looks like a reference, but probably isn't: '3' on line 3383 -- Looks like a reference, but probably isn't: '5' on line 3386 -- Looks like a reference, but probably isn't: '6' on line 3407 -- Looks like a reference, but probably isn't: '9' on line 3416 -- Looks like a reference, but probably isn't: '2' on line 3421 -- Looks like a reference, but probably isn't: '7' on line 3422 == Outdated reference: A later version (-23) exists of draft-ietf-lamps-cmp-updates-05 ** Downref: Normative reference to an Informational RFC: RFC 2986 -- Obsolete informational reference (is this intentional?): RFC 2510 (Obsoleted by RFC 4210) -- Obsolete informational reference (is this intentional?): RFC 2818 (Obsoleted by RFC 9110) -- Obsolete informational reference (is this intentional?): RFC 5246 (Obsoleted by RFC 8446) Summary: 1 error (**), 0 flaws (~~), 9 warnings (==), 10 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 LAMPS Working Group H. Brockhaus 3 Internet-Draft S. Fries 4 Intended status: Standards Track D. von Oheimb 5 Expires: April 5, 2021 Siemens 6 October 2, 2020 8 Lightweight CMP Profile 9 draft-ietf-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, 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 operations are specified as mandatory. To foster interoperability 22 in more complex scenarios, other types of operations are specified as 23 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 April 5, 2021. 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. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 3 60 1.1. Motivation for profiling CMP . . . . . . . . . . . . . . 4 61 1.2. Motivation for a lightweight profile for CMP . . . . . . 5 62 1.3. Existing CMP profiles . . . . . . . . . . . . . . . . . . 5 63 1.4. Compatibility with existing CMP profiles . . . . . . . . 7 64 1.5. Scope of this document . . . . . . . . . . . . . . . . . 9 65 1.6. Structure of this document . . . . . . . . . . . . . . . 9 66 1.7. Convention and Terminology . . . . . . . . . . . . . . . 10 67 2. Architecture and use cases . . . . . . . . . . . . . . . . . 11 68 2.1. Solution architecture . . . . . . . . . . . . . . . . . . 11 69 2.2. Basic generic CMP message content . . . . . . . . . . . . 12 70 2.3. Supported PKI management operations . . . . . . . . . . . 13 71 2.3.1. Mandatory PKI management operations . . . . . . . . . 13 72 2.3.2. Recommended PKI management operations . . . . . . . . 14 73 2.3.3. Optional PKI management operations . . . . . . . . . 14 74 2.4. CMP message transport . . . . . . . . . . . . . . . . . . 15 75 3. Generic parts of the PKI message . . . . . . . . . . . . . . 16 76 3.1. General description of the CMP message header . . . . . . 17 77 3.2. General description of the CMP message protection . . . . 19 78 3.3. General description of CMP message extraCerts . . . . . . 20 79 4. End Entity focused PKI management operations . . . . . . . . 20 80 4.1. Requesting a new certificate from a PKI . . . . . . . . . 21 81 4.1.1. Request a certificate from a new PKI with signature 82 protection . . . . . . . . . . . . . . . . . . . . . 22 83 4.1.2. Request a certificate from a trusted PKI with 84 signature protection . . . . . . . . . . . . . . . . 28 85 4.1.3. Update an existing certificate with signature 86 protection . . . . . . . . . . . . . . . . . . . . . 29 87 4.1.4. Request a certificate from a PKI with MAC protection 30 88 4.1.5. Request a certificate from a legacy PKI using PKCS#10 89 request . . . . . . . . . . . . . . . . . . . . . . . 32 90 4.1.6. Generate the key pair centrally at the PKI management 91 entity . . . . . . . . . . . . . . . . . . . . . . . 34 92 4.1.6.1. Using key agreement key management technique . . 40 93 4.1.6.2. Using key transport key management technique . . 41 94 4.1.6.3. Using password-based key management technique . . 42 95 4.1.7. Delayed enrollment . . . . . . . . . . . . . . . . . 43 96 4.2. Revoking a certificate . . . . . . . . . . . . . . . . . 48 97 4.3. Error reporting . . . . . . . . . . . . . . . . . . . . . 50 98 4.4. Support messages . . . . . . . . . . . . . . . . . . . . 52 99 4.4.1. General message and response . . . . . . . . . . . . 53 100 4.4.2. Get CA certificates . . . . . . . . . . . . . . . . . 54 101 4.4.3. Get root CA certificate update . . . . . . . . . . . 55 102 4.4.4. Get certificate request template . . . . . . . . . . 56 103 5. LRA and RA focused PKI management operations . . . . . . . . 58 104 5.1. Forwarding of messages . . . . . . . . . . . . . . . . . 59 105 5.1.1. Not changing protection . . . . . . . . . . . . . . . 61 106 5.1.2. Replacing protection . . . . . . . . . . . . . . . . 61 107 5.1.2.1. Keeping proof-of-possession . . . . . . . . . . . 62 108 5.1.2.2. Breaking proof-of-possession . . . . . . . . . . 62 109 5.1.3. Adding Protection . . . . . . . . . . . . . . . . . . 63 110 5.1.3.1. Handling a single PKI management message . . . . 64 111 5.1.3.2. Handling a batch of PKI management messages . . . 64 112 5.1.4. Initiating delayed enrollment . . . . . . . . . . . . 65 113 5.2. Revoking certificates on behalf of another's entities . . 66 114 5.3. Error reporting . . . . . . . . . . . . . . . . . . . . . 66 115 6. CMP message transport variants . . . . . . . . . . . . . . . 67 116 6.1. HTTP transport . . . . . . . . . . . . . . . . . . . . . 67 117 6.2. HTTPS transport using certificates . . . . . . . . . . . 69 118 6.3. HTTPS transport using shared secrets . . . . . . . . . . 70 119 6.4. Offline transport . . . . . . . . . . . . . . . . . . . . 71 120 6.4.1. File-based transport . . . . . . . . . . . . . . . . 71 121 6.4.2. Other asynchronous transport protocols . . . . . . . 71 122 6.5. CoAP transport . . . . . . . . . . . . . . . . . . . . . 71 123 6.6. Piggybacking on other reliable transport . . . . . . . . 71 124 7. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 72 125 8. Security Considerations . . . . . . . . . . . . . . . . . . . 72 126 9. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 72 127 10. References . . . . . . . . . . . . . . . . . . . . . . . . . 72 128 10.1. Normative References . . . . . . . . . . . . . . . . . . 72 129 10.2. Informative References . . . . . . . . . . . . . . . . . 73 130 Appendix A. Example for CertReqTemplate . . . . . . . . . . . . 75 131 Appendix B. History of changes . . . . . . . . . . . . . . . . . 76 132 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 80 134 1. Introduction 136 !!! The change history was moved to Appendix B !!! 138 This document specifies PKI management operations supporting machine- 139 to-machine and IoT use cases. The focus lies on maximum automation 140 and interoperable implementation of all involved PKI entities from 141 end entities (EE) through an optional Local Registration Authority 142 (LRA) and the RA up to the CA. The profile makes use of the concepts 143 and syntax specified in CMP [RFC4210], CRMF [RFC4211], HTTP transfer 144 for CMP [RFC6712], and CMP Updates [I-D.ietf-lamps-cmp-updates]. 146 Especially CMP and CRMF are very feature-rich standards, while only a 147 limited subset of the specified functionality is needed in many 148 environments. Additionally, the standards are not always precise 149 enough on how to interpret and implement the described concepts. 150 Therefore, this document aims at tailoring and specifying in more 151 detail how to use these concepts to implement lightweight automated 152 certificate management. 154 1.1. Motivation for profiling CMP 156 CMP was standardized in 1999 and is implemented in several CA 157 products. In 2005 a completely reworked and enhanced version 2 of 158 CMP [RFC4210] and CRMF [RFC4211] has been published followed by a 159 document specifying a transfer mechanism for CMP messages using http 160 [RFC6712] in 2012. 162 Though CMP is a very solid and capable protocol it could be used more 163 widely. The most important reason for not more intense application 164 of CMP appears to be that the protocol is offering a large set of 165 features and options but being not always precise enough and leaving 166 room for interpretation. On the one hand, this makes CMP applicable 167 to a very wide range of scenarios, but on the other hand a full 168 implementation of all options is unrealistic because this would take 169 enormous effort. 171 Moreover, many details of the CMP protocol have been left open or 172 have not been specified in full preciseness. The profiles specified 173 in Appendix D and E of [RFC4210] offer some more detailed PKI 174 management operations. But the specific needs of highly automated 175 scenarios for a machine-to-machine communication are not covered 176 sufficiently. 178 As also ETSI and UNISIG already put across, profiling is a way of 179 coping with the challenges mentioned above. To profile means to take 180 advantage of the strengths of the given protocol, while explicitly 181 narrowing down the options it provides to exactly those needed for 182 the purpose(s) at hand and eliminating all identified ambiguities. 183 In this way all the general and applicable aspects of the protocol 184 can be taken over and only the peculiarities of the target scenario 185 need to be dealt with specifically. 187 Doing such a profiling for a new target environment can be a high 188 effort because the range of available options needs to be well 189 understood and the selected options need to be consistent with each 190 other and with the intended usage scenario. Since most industrial 191 PKI management use cases typically have much in common it is worth 192 sharing this effort, which is the aim of this document. Other 193 standardization bodies can then reference the needed PKI management 194 operations from this document and do not need to come up with 195 individual profiles. 197 1.2. Motivation for a lightweight profile for CMP 199 The profiles specified in Appendix D and E of CMP have been developed 200 in particular to manage certificates of human end entities. With the 201 evolution of distributed systems and client-server architectures, 202 certificates for machines and applications on them have become widely 203 used. This trend has strengthened even more in emerging industrial 204 and IoT scenarios. CMP is sufficiently flexible to support these 205 very well. 207 Today's IT security architectures for industrial solutions typically 208 use certificates for endpoint authentication within protocols like 209 IPSec, TLS, or SSH. Therefore, the security of these architectures 210 highly relies upon the security and availability of the implemented 211 certificate management procedures. 213 Due to increasing security in operational networks as well as 214 availability requirements, especially on critical infrastructures and 215 systems with a high volume of certificates, a state-of-the-art 216 certificate management must be constantly available and cost- 217 efficient, which calls for high automation and reliability. The NIST 218 Cyber Security Framework [NIST-CSFW] also refers to proper processes 219 for issuance, management, verification, revocation, and audit for 220 authorized devices, users and processes involving identity and 221 credential management. Such PKI operation according to commonly 222 accepted best practices is also required in IEC 62443-3-3 223 [IEC62443-3-3] for security level 2 up to security level 4. 225 Further challenges in many industrial systems are network 226 segmentation and asynchronous communication, where PKI operation is 227 often not deployed on-site but in a more protected environment of a 228 data center or trust center. Certificate management must be able to 229 cope with such network architectures. CMP offers the required 230 flexibility and functionality, namely self-contained messages, 231 efficient polling, and support for asynchronous message transfer with 232 end-to-end security. 234 1.3. Existing CMP profiles 236 As already stated, CMP contains profiles with mandatory and optional 237 transactions in the Appendixes D and E of [RFC4210]. Those profiles 238 focus on management of human user certificates and do only partly 239 address the specific needs for certificate management automation for 240 unattended machine or application-oriented end entities. 242 [RFC4210] specifies in Appendix D the following mandatory PKI 243 management operations (all require support of, in the meantime 244 outdated, algorithms, e.g., SHA-1 and 3-DES; all operations may 245 enroll up to two certificates, one for a locally generated and 246 another optional one for a centrally generated key pair; all require 247 use of certConf/pkiConf messages for confirmation): 249 o Initial registration/certification; an (uninitialized) end entity 250 requests a (first) certificate from a CA using shared secret based 251 message authentication. The content is similar to the PKI 252 management operation specified in Section 4.1.4 of this document. 254 o Certificate request; an (initialized) end entity requests another 255 certificate from a CA using signature or shared secret based 256 message authentication. The content is similar to the PKI 257 management operation specified in Section 4.1.2 of this document. 259 o Key update; an (initialized) end entity requests a certificate 260 from a CA (to update the key pair and/or corresponding certificate 261 that it already possesses) using signature or shared secret based 262 message authentication. The content is similar to the PKI 263 management operation specified in Section 4.1.3 of this document. 265 Due to the two certificates that may be enrolled and the shared 266 secret based authentication, these PKI management operations focus 267 more on the enrollment of human users at a PKI. 269 [RFC4210] specifies in Appendix E the following optional PKI 270 management operations (all require support of, in the meantime 271 outdated, algorithms, e.g., SHA-1 and 3-DES): 273 o Root CA key update; a root CA updates its key pair and produces a 274 CA key update announcement message that can be made available (via 275 some transport mechanism) to the relevant end entities. This 276 operation only supports a push and no pull model. The content is 277 similar to the PKI management operation specified in Section 4.4.3 278 of this document. 280 o Information request/response; an end entity sends a general 281 message to the PKI requesting details that will be required for 282 later PKI management operations. The content is similar to the 283 PKI management operation specified in Section 4.4.4 of this 284 document. 286 o Cross-certification request/response (1-way); creation of a single 287 cross-certificate (i.e., not two at once). The requesting CA MAY 288 choose who is responsible for publication of the cross-certificate 289 created by the responding CA through use of the PKIPublicationInfo 290 control. 292 o In-band initialization using external identity certificate (this 293 PKI management operation may also enroll up to two certificates 294 and requires use of certConf/pkiConf messages for confirmation as 295 specified in Appendix D of [RFC4210]). An (uninitialized) end 296 entity wishes to initialize into the PKI with a CA, CA-1. It 297 uses, for authentication purposes, a pre-existing identity 298 certificate issued by another (external) CA, CA-X. A trust 299 relationship must already have been established between CA-1 and 300 CA-X so that CA-1 can validate the EE identity certificate signed 301 by CA-X. Furthermore, some mechanism must already have been 302 established within the Personal Security Environment (PSE) of the 303 EE that would allow it to authenticate and verify PKIMessages 304 signed by CA-1. The content is similar to the PKI management 305 operation specified in Section 4.1.1 of this document. 307 Both Appendixes focus on EE to CA/RA PKI management operations and do 308 not address further profiling of RA to CA communication as typically 309 used for full backend automation. 311 ETSI makes use of CMP [RFC4210] in its Technical Specification 133 312 310 [ETSI-TS133310] for automatic management of IPSec certificates in 313 UMTS, LTE, and 5G backbone networks. Since 2010 a dedicated CMP 314 profile for initial certificate enrollment and update operations 315 between EE and RA/CA is specified in that document. 317 UNISIG has included a CMP profile for certificate enrollment in the 318 subset 137 specifying the ETRAM/ECTS on-line key management for train 319 control systems [UNISIG-Subset137] in 2015. 321 Both standardization bodies use CMP [RFC4210], CRMF [RFC4211], and 322 HTTP transfer for CMP [RFC6712] to add tailored means for automated 323 PKI management operations for unattended machine or application- 324 oriented end entities. 326 1.4. Compatibility with existing CMP profiles 328 The profile specified in this document is compatible with CMP 329 [RFC4210] Appendixes D and E (PKI Management Message Profiles), with 330 the following exceptions: 332 o signature-based protection is the default protection; an initial 333 PKI management operation may also use HMAC, 335 o certification of a second key pair within the same PKI management 336 operation is not supported, 338 o proof-of-possession (POPO) with self-signature of the certTemplate 339 according to [RFC4211] section 4.1 clause 3 is the recommended 340 default POPO method (deviations are possible by EEs when 341 requesting central key generation and by (L)RAs when using 342 raVerified), 344 o confirmation of newly enrolled certificates may be omitted, and 346 o all PKI management operations consist of request-response message 347 pairs originating at the EE, i.e., announcement messages are 348 omitted. 350 The profile specified in this document is compatible with the CMP 351 profile for UMTS, LTE, and 5G network domain security and 352 authentication framework [ETSI-TS133310], except that: 354 o protection of initial PKI management operations may be HMAC-based, 356 o the subject field is mandatory in certificate templates, and 358 o confirmation of newly enrolled certificates may be omitted. 360 The profile specified in this document is compatible with the CMP 361 profile for on-line key management in rail networks as specified in 362 UNISIG Subset-137 [UNISIG-Subset137], except that: 364 o As stated in Section 4.1.1 a CMP message SHALL only consist of one 365 certificate request (CertReqMsg). As UNISIG Subset-137 Table 6 366 [UNISIG-Subset137] allows to transport more than one certificate 367 request message, this conflicts with this document. 369 o There is no automatic revocation specified in this document. As 370 UNISIG Subset-137 Section 6.3.2.1.2 [UNISIG-Subset137] request an 371 automatic certificate revocation by the CA in case of TCP 372 disconnection during certificate distribution, this conflicts with 373 this document. 375 o As of RFC 4210 [RFC4210] the messageTime is required to be 376 Greenwich Mean Time coded as generalizedTime As UNISIG Subset-137 377 Table 5 [UNISIG-Subset137] explicitly states that the messageTime 378 in required to be 'UTC time', it is not clear if this means a 379 coding as UTCTime or generalizedTime and if other time zones than 380 Greenwich Mean Time shall be allowed. Therefore, UNISIG 381 Subset-137 [UNISIG-Subset137] conflicts with RFC 4210 [RFC4210]. 382 Both time formats are described in RFC 5280 Section 4.1.2.5 383 [RFC5280]. 385 o This profile requires usage of the same type of protection for all 386 messages of one PKI management operation. This means, in case the 387 request message is MAC protected, also the response, certConf, and 388 pkiConf messages have a MAC-based protection. As UNISIG 389 Subset-137 Table 5 [UNISIG-Subset137] specifies for the first 390 certificate request MAC protection for all messages send by the 391 client and signature protection for all messages send by the 392 server, this conflicts with this document. 394 o The usage of caPubs is mainly allowed in combination with MAC 395 protected PKI management operations. UNISIG Subset-137 Table 12 396 [UNISIG-Subset137] requires to use caPubs. When changing to 397 signature protection of the response using a certificate issued 398 under the root CA that is to be transported in the caPubs field, 399 this is not a secure delivery of this root CA certificate. 401 1.5. Scope of this document 403 This document specifies requirements on generating PKI management 404 messages on the sender side. It does not specify strictness of 405 verification on the receiving side and how in detail to handle error 406 cases. 408 Especially on the EE side this profile aims at a lightweight protocol 409 that can be implemented on more constrained devices. On the side of 410 the central PKI management entities the profile accepts higher 411 resources needed. 413 For the sake of robustness and preservation of security properties 414 implementations should, as far as security is not affected, adhere to 415 Postel's law: "Be conservative in what you do, be liberal in what you 416 accept from others" (often reworded as: "Be conservative in what you 417 send, be liberal in what you accept"). 419 When in Section 3, Section 4, and Section 5 a field of the ASN.1 420 syntax as defined in RFC 4210 [RFC4210] and RFC 4211 [RFC4211] is not 421 explicitly specified, it SHOULD not be used by the sending entity. 422 The receiving entity MUST NOT require its absence and if present MUST 423 gracefully handle its presence. 425 1.6. Structure of this document 427 Section 2 introduces the general PKI architecture and approach to 428 certificate management using CMP that is assumed in this document. 429 Then it enlists the PKI management operations specified in this 430 document and describes them in general words. The list of supported 431 PKI management operations is divided into mandatory, recommended, and 432 optional ones. 434 Section 3 profiles the CMP message header, protection, and extraCerts 435 section as they are general elements of CMP messages. 437 Section 4 profiles the exchange of CMP messages between an EE and the 438 first PKI management entities. There are various flavors of 439 certificate enrollment requests optionally with polling, revocation, 440 error handling, and general support PKI management operations. 442 Section 5 profiles the exchange between PKI management entities. 443 These are in the first place the forwarding of messages coming from 444 or going to an EE. This includes also initiating delayed delivery of 445 messages, which involves polling. Additionally, it specifies PKI 446 management operations where a PKI management entity manages 447 certificates on behalf of an EE or for itself. 449 Section 6 outlines different mechanisms for CMP message transfer, 450 namely http-based transfer as already specified in [RFC6712], using 451 an additional TLS layer, or offline file-based transport. CoAP 452 [RFC7252] and piggybacking CMP messages on other protocols is out of 453 scope and left for further documents. 455 1.7. Convention and Terminology 457 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 458 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 459 document are to be interpreted as described in RFC 2119 [RFC2119]. 461 In this document, these words will appear with that interpretation 462 only when in ALL CAPS. Lower case use of these words are not to be 463 interpreted as carrying significance described in RFC 2119. 465 Technical terminology is used in conformance with RFC 4210 [RFC4210], 466 RFC 4211 [RFC4211], RFC 5280 [RFC5280], and IEEE 802.1AR 467 [IEEE802.1AR]. The following key words are used: 469 CA: Certification authority, which issues certificates. 471 RA: Registration authority, an optional system component to which a 472 CA delegates certificate management functions such as 473 authorization checks. 475 LRA: Local registration authority, an optional RA system component 476 with proximity to the end entities. 478 KGA: Key generation authority, an optional system component, 479 typically co-located with an LRA, RA, or CA, that offers key 480 generation services to end entities. 482 EE: End entity, a user, device, or service that holds a PKI 483 certificate. An identifier for the EE is given as the subject 484 of its certificate. 486 The following terminology is reused from RFC 4210 [RFC4210] and used 487 as follows: 489 PKI management operation: All CMP messages belonging to one 490 transaction context. The transaction is 491 identified in the transactionID field of 492 the message header. 494 PKI management entity: All central PKI entities like LRA, RA and 495 CA. 497 PKI entity: EEs and PKI management entities 499 2. Architecture and use cases 501 2.1. Solution architecture 503 Typically, a machine EE will be equipped with a manufacturer issued 504 certificate during production. Such a manufacturer issued 505 certificate is installed during production to identify the device 506 throughout its lifetime. This manufacturer certificate can be used 507 to protect the initial enrollment of operational certificates after 508 installation of the EE in a plant or industrial network. An 509 operational certificate is issued by the owner or operator of the 510 device to identify the device during operation, e.g., within a 511 security protocol like IPSec, TLS, or SSH. In IEEE 802.1AR 512 [IEEE802.1AR] a manufacturer certificate is called IDevID certificate 513 and an operational certificate is called LDevID certificate. 515 All certificate management transactions specified in this document 516 are initiated by the EE. The EE creates a CMP request message, 517 protects it using its manufacturer or operational certificate, if 518 available, and sends it to its locally reachable PKI component. This 519 PKI component may be an LRA, RA, or the CA, which checks the request, 520 responds to it itself, or forwards the request upstream to the next 521 PKI component. In case an (L)RA changes the CMP request message 522 header or body or wants to prove a successful verification or 523 authorization, it can apply a protection of its own. Especially the 524 communication between an LRA and RA can be performed synchronously or 525 asynchronously. Synchronous communication describes a timely 526 uninterrupted communication between two communication partners, while 527 asynchronous communication is not performed in a timely consistent 528 manner, e.g., because of a delayed message delivery. 530 +-----+ +-----+ +-----+ +-----+ 531 | | | | | | | | 532 | EE |<---------->| LRA |<-------------->| RA |<---------->| CA | 533 | | | | | | | | 534 +-----+ +-----+ +-----+ +-----+ 536 synchronous (a)synchronous (a)synchronous 537 +----connection----+------connection------+----connection----+ 539 on site at operators service partner 540 +----------plant---------+-----backend services-----+-trust center-+ 542 Figure 1: Certificate management on site 544 In operation environments a layered LRA-RA-CA architecture can be 545 deployed, e.g., with LRAs bundling requests from multiple EEs at 546 dedicated locations and one (or more than one) central RA aggregating 547 the requests from multiple LRAs. Every (L)RA in this scenario will 548 have its own dedicated certificate containing an extended key usage 549 as specified in CMP Updates [I-D.ietf-lamps-cmp-updates] and private 550 key allowing it to protect CMP messages it processes (CMP signing 551 key/certificate). The figure above shows an architecture using one 552 LRA and one RA. It is also possible to have only an RA or multiple 553 LRAs and/or RAs. Depending on the network infrastructure, the 554 communication between different PKI management entities may be 555 synchronous online communication, delayed asynchronous communication, 556 or even offline file transfer. 558 This profile focusses on specifying the pull model, where the EE 559 always requests a specific PKI management operation. CMP response 560 messages, especially in case of central key generation, as described 561 in Section 4.1.6, could also be used proactively to implement the 562 push model towards the EE. 564 Third-party CAs typically implement different variants of CMP or even 565 use proprietary interfaces for certificate management. Therefore, 566 the LRA or the RA may need to adapt the exchanged CMP messages to the 567 flavor of communication required by the CA. 569 2.2. Basic generic CMP message content 571 Section 3 specifies the generic parts of the CMP messages as used 572 later in Section 4 and Section 5. 574 o Header of a CMP message; see Section 3.1. 576 o Protection of a CMP message; see Section 3.2. 578 o ExtraCerts field of a CMP message; see Section 3.3. 580 2.3. Supported PKI management operations 582 Following the outlined scope from Section 1.5, this section gives a 583 brief overview of the PKI management operations specified in 584 Section 4 and Section 5 and points out whether an implementation by 585 compliant EE or PKI management entities is mandatory, recommended or 586 optional. 588 2.3.1. Mandatory PKI management operations 590 The mandatory PKI management operations in this document shall limit 591 the overhead of certificate management for more constrained devices 592 to the most crucial types of operations. 594 +--------------------------------------------------------+----------+ 595 | PKI management operations | Section | 596 +--------------------------------------------------------+----------+ 597 | Request a certificate from a new PKI with signature | Section | 598 | protection | 4.1.1 | 599 +--------------------------------------------------------+----------+ 600 | Request to update an existing certificate with | Section | 601 | signature protection | 4.1.3 | 602 +--------------------------------------------------------+----------+ 603 | Error reporting | Section | 604 | | 4.3 | 605 +--------------------------------------------------------+----------+ 607 Table 1: Mandatory End Entity focused PKI management operations 609 +--------------------------------------------------------+----------+ 610 | PKI management operations | Section | 611 +--------------------------------------------------------+----------+ 612 | Forward messages without changes | Section | 613 | | 5.1.1 | 614 +--------------------------------------------------------+----------+ 615 | Forward messages with replaced protection and keeping | Section | 616 | the original proof-of-possession | 5.1.2.1 | 617 +--------------------------------------------------------+----------+ 618 | Forward messages with replaced protection and | Section | 619 | raVerified as proof-of-possession | 5.1.2.2 | 620 +--------------------------------------------------------+----------+ 621 | Error reporting | Section | 622 | | 5.3 | 623 +--------------------------------------------------------+----------+ 625 Table 2: Mandatory LRA and RA focused PKI management operations 627 2.3.2. Recommended PKI management operations 629 Additional recommended PKI management operations shall support some 630 more complex scenarios, that are considered as beneficial for 631 environments with more specific boundary conditions. 633 +--------------------------------------------------------+----------+ 634 | PKI management operations | Section | 635 +--------------------------------------------------------+----------+ 636 | Request a certificate from a PKI with MAC protection | Section | 637 | | 4.1.4 | 638 +--------------------------------------------------------+----------+ 639 | Revoke an own certificate | Section | 640 | | 4.2 | 641 +--------------------------------------------------------+----------+ 643 Table 3: Recommended End Entity focused PKI management operations 645 +--------------------------------------------------------+----------+ 646 | PKI management operations | Section | 647 +--------------------------------------------------------+----------+ 648 | Revoke another's entities certificate | Section | 649 | | 5.2 | 650 +--------------------------------------------------------+----------+ 652 Table 4: Recommended LRA and RA focused PKI management operations 654 2.3.3. Optional PKI management operations 656 The optional PKI management operations support specific requirements 657 seen only in a subset of environments. 659 +---------------------------------------------------------+---------+ 660 | PKI management operations | Section | 661 +---------------------------------------------------------+---------+ 662 | Request a certificate from a trusted PKI with signature | Section | 663 | protection | 4.1.2 | 664 +---------------------------------------------------------+---------+ 665 | Request a certificate from a legacy PKI using a PKCS#10 | Section | 666 | [RFC2986] request | 4.1.5 | 667 +---------------------------------------------------------+---------+ 668 | Add central generation of a key pair to a certificate | Section | 669 | request. (If central key generation is supported, the | 4.1.6 | 670 | key agreement key management technique is REQUIRED to | | 671 | be supported, and the key transport and password-based | | 672 | key management techniques are OPTIONAL.) | | 673 +---------------------------------------------------------+---------+ 674 | Handle delayed enrollment due to asynchronous message | Section | 675 | delivery | 4.1.7 | 676 +---------------------------------------------------------+---------+ 677 | Additional support messages - distribution of CA | Section | 678 | certificates, update of a root CA certificate and | 4.4 | 679 | provisioning of certificate request template | | 680 +---------------------------------------------------------+---------+ 682 Table 5: Optional End Entity focused PKI management operations 684 +--------------------------------------------------------+----------+ 685 | PKI management operations | Section | 686 +--------------------------------------------------------+----------+ 687 | Forward messages with additional protection | Section | 688 | | 5.1.3 | 689 +--------------------------------------------------------+----------+ 690 | Initiate delayed enrollment due to asynchronous | Section | 691 | message delivery | 5.1.4 | 692 +--------------------------------------------------------+----------+ 694 Table 6: Optional LRA and RA focused PKI management operations 696 2.4. CMP message transport 698 On different links between PKI entities, e.g., EE<->RA and RA<->CA, 699 different transport MAY be used. As CMP has only very limited 700 requirement regarding the mechanisms used for message transport and 701 in different environments different transport mechanisms are 702 supported, e.g., HTTP, CoAP, or even offline files based, this 703 document requires no specific transport protocol to be supported by 704 all conforming implementations. 706 HTTP transfer is RECOMMENDED to use for all PKI entities, but there 707 is no transport specified as mandatory to be flexible for devices 708 with special constraints to choose whatever transport is suitable. 710 +--------------------------------------------------------+----------+ 711 | Transport | Section | 712 +--------------------------------------------------------+----------+ 713 | Transfer CMP messages using HTTP | Section | 714 | | 6.1 | 715 +--------------------------------------------------------+----------+ 717 Table 7: Recommended transport operations 719 +--------------------------------------------------------+----------+ 720 | Transport | Section | 721 +--------------------------------------------------------+----------+ 722 | Transfer CMP messages using HTTPS with certificate- | Section | 723 | based authentication | 6.2 | 724 +--------------------------------------------------------+----------+ 725 | Transfer CMP messages using HTTPS with shared-secret | Section | 726 | based protection | 6.3 | 727 +--------------------------------------------------------+----------+ 728 | Offline CMP message transport | Section | 729 | | 6.4 | 730 +--------------------------------------------------------+----------+ 731 | Transfer CMP messages using CoAP | Section | 732 | | 6.5 | 733 +--------------------------------------------------------+----------+ 735 Table 8: Optional transport operations 737 3. Generic parts of the PKI message 739 To reduce redundancy in the text and to ease implementation, the 740 contents of the header, protection, and extraCerts fields of the CMP 741 messages used in the transactions specified in Section 4 and 742 Section 5 are standardized to the maximum extent possible. 743 Therefore, the generic parts of a CMP message are described centrally 744 in this section. 746 As described in section 5.1 of [RFC4210], all CMP messages have the 747 following general structure: 749 +--------------------------------------------+ 750 | PKIMessage | 751 | +----------------------------------------+ | 752 | | header | | 753 | +----------------------------------------+ | 754 | +----------------------------------------+ | 755 | | body | | 756 | +----------------------------------------+ | 757 | +----------------------------------------+ | 758 | | protection (OPTIONAL) | | 759 | +----------------------------------------+ | 760 | +----------------------------------------+ | 761 | | extraCerts (OPTIONAL) | | 762 | +----------------------------------------+ | 763 +--------------------------------------------+ 765 Figure 2: CMP message structure 767 The general contents of the message header, protection, and 768 extraCerts fields are specified in the Section 3.1 to Section 3.3. 770 In case a specific CMP message needs different contents in the 771 header, protection, or extraCerts fields, the differences are 772 described in the respective message. 774 The CMP message body contains the message-specific information. It 775 is described in the context of Section 4 and Section 5. 777 The behavior in case an error occurs while handling a CMP message is 778 described in Section 5.3. 780 3.1. General description of the CMP message header 782 This section describes the generic header field of all CMP messages 783 with signature-based protection. The only variations described here 784 are in the fields recipient, transactionID, and recipNonce of the 785 first message of a PKI management operation. 787 In case a message has MAC-based protection the changes are described 788 in the respective section. The variations will affect the fields 789 sender, protectionAlg, and senderKID. 791 For requirements about proper random number generation please refer 792 to [RFC4086]. Any message-specific fields or variations are 793 described in the respective sections of this chapter. 795 header 796 pvno REQUIRED 797 -- MUST be set to 2 to indicate CMP V2 798 sender REQUIRED 799 -- MUST contain a name representing the originator of the message 800 -- SHOULD be the subject of the protection certificate, 801 -- the certificate for the private key used to sign the message 802 recipient REQUIRED 803 -- SHOULD be the name of the intended recipient and 804 -- MAY be a NULL-DN, i.e., has a zero-length SEQUENCE OF 805 -- RelativeDistinguishedNames, if the sender does not know the 806 -- DN of the recipient 807 -- If this is the first message of a transaction: SHOULD be the 808 -- subject of the issuing CA certificate 809 -- In all other messages: SHOULD be the same name as in the 810 -- sender field of the previous message in this transaction 811 messageTime RECOMMENDED 812 -- MUST be the time at which the message was produced, if 813 -- present 814 protectionAlg REQUIRED 815 -- MUST be the algorithm identifier of the signature algorithm or 816 -- id-PasswordBasedMac algorithm used for calculation of the 817 -- protection bits 818 -- The signature algorithm MUST be consistent with the 819 -- subjectPublicKeyInfo field of the signer's certificate 820 -- The hash algorithm used SHOULD be SHA-256 821 algorithm REQUIRED 822 -- MUST be the OID of the signature algorithm, like 823 -- sha256WithRSAEncryption or ecdsa-with-SHA256, or 824 -- id-PasswordBasedMac 825 senderKID RECOMMENDED 826 -- MUST be the SubjectKeyIdentifier, if available, of the 827 -- protection certificate 828 transactionID REQUIRED 829 -- If this is the first message of a transaction: 830 -- MUST be 128 bits of random data for the start of a 831 -- transaction to reduce the probability of having the 832 -- transactionID already in use at the server 833 -- In all other messages: 834 -- MUST be the value from the previous message in the same 835 -- transaction 836 senderNonce REQUIRED 837 -- MUST be cryptographically secure and fresh 128 random bits 838 recipNonce RECOMMENDED 839 -- If this is the first message of a transaction: SHOULD be 840 -- absent 841 -- In all other messages: MUST be present and contain the value 842 -- from senderNonce of the previous message in the same 843 -- transaction 844 generalInfo OPTIONAL 845 implicitConfirm OPTIONAL 846 -- The field is optional though it only applies to 847 -- ir/cr/kur/p10cr requests and ip/cp/kup response messages 848 -- Add to request messages to request omit sending certConf 849 -- message 850 -- See [RFC4210] Section 5.1.1.1. 851 -- Add to response messages to confirm omit sending certConf 852 -- message 853 ImplicitConfirmValue REQUIRED 854 -- ImplicitConfirmValue of the request message MUST be NULL if 855 -- the EE wants to request not to send a confirmation message 856 -- ImplicitConfirmValue MUST be set to NULL if the (L)RA/CA 857 -- wants to grant not sending a confirmation message 859 < TBD: As discussed at IETF 108, the normative naming of specific 860 algorithms, e.g., like SHA-256 in the protectionAlg field should be 861 moved to a CMP Algorithms Draft. > 863 3.2. General description of the CMP message protection 865 This section describes the generic protection field of all CMP 866 messages with signature-based protection. The certificate for the 867 private key used to sign a CMP message is called 'protection 868 certificate'. 870 protection RECOMMENDED 871 -- MUST contain the signature calculated using the signature 872 -- algorithm specified in protectionAlg 874 Generally, CMP message protection is required for CMP messages, but 875 there are cases where protection of error messages as specified in 876 Section 4.3 and Section 5.3 is not possible and therefore MAY be 877 omitted. 879 For MAC-based protection as specified in Section 4.1.4 major 880 differences apply as described in the respective section. 882 The CMP message protection provides, if available, message origin 883 authentication and integrity protection for the CMP message header 884 and body. The CMP message extraCerts is not covered by this 885 protection. 887 NOTE: The extended key usages specified in CMP Updates 888 [I-D.ietf-lamps-cmp-updates] can be used for authorization of a 889 sending PKI management entity. 891 NOTE: The requirements for checking certificates given in [RFC5280] 892 MUST be followed for the CMP message protection. In case the CMP 893 signer certificate is not the CA certificate that signed the newly 894 issued certificate, certificate status checking SHOULD be used for 895 the CMP signer certificates of communication partners. 897 3.3. General description of CMP message extraCerts 899 This section describes the generic extraCerts field of all CMP 900 messages with signature-based protection. If extraCerts are 901 required, recommended, or optional is specified in the respective PKI 902 management operation. 904 extraCerts 905 -- SHOULD contain the protection certificate together with its 906 -- chain, if needed and the self-signed root certificate SHOULD 907 -- be omitted 908 -- If present, the first certificate in this field MUST 909 -- be the protection certificate and each following certificate 910 -- SHOULD directly certify the one immediately preceding it. 911 -- Self-signed certificates SHOULD be omitted from extraCerts 912 -- and MUST NOT be trusted based on the listing in extraCerts 913 -- in any case 915 Note: For maximum compatibility, all implementations SHOULD be 916 prepared to handle potentially additional and arbitrary orderings of 917 the certificates, except that the protection certificate is the first 918 certificate in extraCerts. 920 4. End Entity focused PKI management operations 922 This chapter focuses on the communication of the EE and the first PKI 923 management entities it talks to. Depending on the network and PKI 924 solution, this will either be the LRA, the RA or the CA. 926 Profiles of the Certificate Management Protocol (CMP) [RFC4210] 927 handled in this section cover the following PKI management 928 operations: 930 o Requesting a certificate from a PKI with variations like initial 931 requests and updating, central key generation and different 932 protection means 934 o Revocation of a certificate 936 o General messages for further support functions 937 These operations mainly specify the message body of the CMP messages 938 and utilize the specification of the message header, protection and 939 extraCerts as specified in Section 4. 941 The behavior in case an error occurs is described in Section 4.3. 943 This chapter is aligned to Appendix D and Appendix E of [RFC4210]. 944 The general rules for interpretation stated in Appendix D.1 in 945 [RFC4210] need to be applied here, too. 947 This document does not mandate any specific supported algorithms like 948 Appendix D.2 of [RFC4210], [ETSI-TS133310], and [UNISIG-Subset137] 949 do. Using the message sequences described here require agreement 950 upon the algorithms to support and thus the algorithm identifiers for 951 the specific target environment. 953 4.1. Requesting a new certificate from a PKI 955 There are different approaches to request a certificate from a PKI. 957 These approaches differ on the one hand in the way the EE can 958 authenticate itself to the PKI it wishes to get a new certificate 959 from and on the other hand in its capabilities to generate a proper 960 new key pair. The authentication means may be as follows: 962 o Using a certificate from a trusted PKI and the corresponding 963 private key, e.g., a manufacturer issued certificate 965 o Using the certificate to be updated and the corresponding private 966 key 968 o Using a shared secret known to the EE and the PKI 970 Typically, such EE requests a certificate from a CA. When the PKI 971 management entity responds with a message containing a certificate, 972 the EE MUST reply with a confirmation message. The PKI management 973 entity then MUST send confirmation back, closing the transaction. 975 The message sequences in this section allow the EE to request 976 certification of a locally generated public-private key pair. For 977 requirements about proper random number and key generation please 978 refer to [RFC4086]. The EE MUST provide a signature-based proof-of- 979 possession of the private key associated with the public key 980 contained in the certificate request as defined by [RFC4211] section 981 4.1 case 3. To this end it is assumed that the private key can 982 technically be used as signing key. The most commonly used 983 algorithms are RSA and ECDSA, which can technically be used for 984 signature calculation regardless of potentially intended restrictions 985 of the key usage. 987 The requesting EE provides the binding of the proof-of-possession to 988 its identity by signature-based or MAC-based protection of the CMP 989 request message containing that POPO. The PKI management entity 990 needs to verify whether this EE is authorized to obtain a certificate 991 with the requested subject and other fields and extensions. 992 Especially when removing the protection provided by the EE and 993 applying a new protection, the PKI management entity MUST verify in 994 particular the included proof-of-possession self-signature of the 995 certTemplate using the public key of the requested certificate and 996 MUST check that the EE, as authenticated by the message protection, 997 is authorized to request a certificate with the subject as specified 998 in the certTemplate (see Section 5.1.2). 1000 There are several ways to install the Root CA certificate of a new 1001 PKI on an EE. The installation can be performed in an out-of-band 1002 manner, using general messages, a voucher [RFC8366], or other formats 1003 for enrollment, or in-band of CMP by the caPubs field in the 1004 certificate response message. In case the installation of the new 1005 root CA certificate is performed using the caPubs field, the 1006 certificate response message MUST be properly authenticated, and the 1007 sender of this message MUST be authorized to install new root CA 1008 certificates on the EE. This authorization can be indicated by using 1009 pre-shared keys for the CMP message protection. 1011 4.1.1. Request a certificate from a new PKI with signature protection 1013 This PKI management operation should be used by an EE to request a 1014 certificate of a new PKI using an existing certificate from an 1015 external PKI, e.g., a manufacturer issued IDevID certificate 1016 [IEEE802.1AR], to prove its identity to the new PKI. The EE already 1017 has established trust in this new PKI it is about to enroll to, e.g., 1018 by voucher exchange or configuration means. The certificate request 1019 message is signature-protected using the existing certificate from 1020 the external PKI. 1022 Preconditions: 1024 1 The EE MUST have a certificate enrolled by an external PKI in 1025 advance to this PKI management operation to authenticate itself to 1026 the PKI management entity using signature-based protection, e.g., 1027 using a manufacturer issued certificate. 1029 2 The EE SHOULD know the subject name of the new CA it requests a 1030 certificate from; this name MAY be established using an enrollment 1031 voucher, the issuer field from a CertReqTemplate response message, 1032 or other configuration means. If the EE does not know the name of 1033 the CA, the PKI management entity MUST know where to route this 1034 request to. 1036 3 The EE MUST authenticate responses from the PKI management entity; 1037 trust MAY be established using an enrollment voucher or other 1038 configuration means. 1040 4 The PKI management entity MUST trust the external PKI the EE uses 1041 to authenticate itself; trust MAY be established using some 1042 configuration means. 1044 This PKI management operation is like that given in [RFC4210] 1045 Appendix E.7. 1047 Message flow: 1049 Step# EE PKI management entity 1050 1 format ir 1051 2 -> ir -> 1052 3 handle, re-protect or 1053 forward ir 1054 4 format or receive ip 1055 5 possibly grant implicit 1056 confirm 1057 6 <- ip <- 1058 7 handle ip 1059 8 In case of status 1060 "rejection" in the 1061 ip message, no certConf 1062 and pkiConf are sent 1063 9 format certConf (optional) 1064 10 -> certConf -> 1065 11 handle, re-protect or 1066 forward certConf 1067 12 format or receive pkiConf 1068 13 <- pkiconf <- 1069 14 handle pkiConf (optional) 1071 For this PKI management operation, the EE MUST include exactly one 1072 single CertReqMsg in the ir. If more certificates are required, 1073 further requests MUST be sent using separate CMP messages. If the EE 1074 wants to omit sending a certificate confirmation message after 1075 receiving the ip to reduce the number of protocol messages exchanged 1076 in this PKI management operation, it MUST request this by including 1077 the implicitConfirm extension in the ir. 1079 If the CA accepts the certificate request it MUST return the new 1080 certificate in the certifiedKeyPair field of the ip message. If the 1081 EE requested to omit sending a certConf message after receiving the 1082 ip, the PKI management entity MAY confirm it by also including the 1083 implicitConfirm extension or MAY rejects it by omitting the 1084 implicitConfirm field in the ip. 1086 If the EE did not request implicit confirmation or the request was 1087 not granted by the PKI management entity the confirmation as follows 1088 MUST be performed. If the EE successfully receives the certificate 1089 and accepts it, the EE MUST send a certConf message, which MUST be 1090 answered by the PKI management entity with a pkiConf message. If the 1091 PKI management entity does not receive the expected certConf message 1092 in time it MUST handle this like a rejection by the EE. 1094 If the certificate request was refused by the CA, the PKI management 1095 entity must return an ip message containing the status code 1096 "rejection" and no certifiedKeyPair field. Such an ip message MUST 1097 NOT be followed by the certConf and pkiConf messages. 1099 Detailed message description: 1101 Certification Request -- ir 1103 Field Value 1105 header 1106 -- As described in section 3.1 1108 body 1109 -- The request of the EE for a new certificate 1110 ir REQUIRED 1111 -- MUST be exactly one CertReqMsg 1112 -- If more certificates are required, further requests MUST be 1113 -- packaged in separate PKI Messages 1114 certReq REQUIRED 1115 certReqId REQUIRED 1116 -- MUST be set to 0 1117 certTemplate REQUIRED 1118 version OPTIONAL 1119 -- MUST be 2 if supplied. 1120 subject REQUIRED 1121 -- The EE subject name MUST be carried in the subject field 1122 -- and/or the subjectAltName extension. 1123 -- If subject name is present only in the subjectAltName 1124 -- extension, then the subject field MUST be a NULL-DN 1125 publicKey REQUIRED 1126 algorithm REQUIRED 1128 -- MUST include the subject public key algorithm ID and value 1129 -- In case a central key generation is requested, this field 1130 -- contains the algorithm and parameter preferences of the 1131 -- requesting entity regarding the to-be-generated key pair 1132 subjectPublicKey REQUIRED 1133 -- MUST contain the public key to be included into the requested 1134 -- certificate in case of local key-generation 1135 -- MUST contain a zero-length BIT STRING in case a central key 1136 -- generation is requested 1137 extensions OPTIONAL 1138 -- MAY include end-entity-specific X.509 extensions of the 1139 -- requested certificate like subject alternative name, 1140 -- key usage, and extended key usage 1141 -- The subjectAltName extension MUST be present if the EE 1142 -- subject name includes a subject alternative name. 1143 Popo REQUIRED 1144 POPOSigningKey OPTIONAL 1145 -- MUST be used in case subjectPublicKey contains a public key 1146 -- MUST be absent in case subjectPublicKey contains a 1147 -- zero-length BIT STRING 1148 poposkInput PROHIBITED 1149 -- MUST NOT be used because subject and publicKey are both 1150 -- present in the certTemplate 1151 algorithmIdentifier REQUIRED 1152 -- The signature algorithm MUST be consistent with the 1153 -- publicKey field of the certTemplate 1154 -- The hash algorithm used SHOULD be SHA-256 1155 signature REQUIRED 1156 -- MUST be the signature computed over the DER-encoded 1157 -- certTemplate 1159 protection REQUIRED 1160 -- As described in section 3.2 1162 extraCerts REQUIRED 1163 -- As described in section 3.3 1165 Certification Response -- ip 1167 Field Value 1169 header 1170 -- As described in section 3.1 1172 body 1173 -- The response of the CA to the request as appropriate 1174 ip REQUIRED 1175 caPubs OPTIONAL 1176 -- MAY be used 1177 -- If used it MUST contain only the root certificate of the 1178 -- certificate contained in certOrEncCert 1179 response REQUIRED 1180 -- MUST be exactly one CertResponse 1181 certReqId REQUIRED 1182 -- MUST be set to 0 1183 status REQUIRED 1184 -- PKIStatusInfo structure MUST be present 1185 status REQUIRED 1186 -- positive values allowed: "accepted", "grantedWithMods" 1187 -- negative values allowed: "rejection" 1188 -- In case of rejection certConf and pkiConf messages MUST NOT 1189 -- be sent 1190 statusString OPTIONAL 1191 -- MAY be any human-readable text for debugging, logging or to 1192 -- display in a GUI 1193 failInfo OPTIONAL 1194 -- MUST be present if status is "rejection" and in this case 1195 -- the transaction MUST be terminated 1196 -- MUST be absent if the status is "accepted" or 1197 -- "grantedWithMods" 1198 certifiedKeyPair OPTIONAL 1199 -- MUST be present if status is "accepted" or "grantedWithMods" 1200 -- MUST be absent if status is "rejection" 1201 certOrEncCert REQUIRED 1202 -- MUST be present when certifiedKeyPair is present 1203 certificate REQUIRED 1204 -- MUST be present when certifiedKeyPair is present 1205 -- MUST contain the newly enrolled X.509 certificate 1206 privateKey OPTIONAL 1207 -- MUST be absent in case of local key-generation 1208 -- MUST contain the encrypted private key in an EnvelopedData 1209 -- structure as specified in section 5.1.5 in case the private 1210 -- key was generated centrally 1212 protection REQUIRED 1213 -- As described in section 3.2 1215 extraCerts REQUIRED 1216 -- As described in section 3.3 1217 -- MUST contain the chain of the certificate present in 1218 -- certOrEncCert, the self-signed root certificate SHOULD be 1219 -- omitted 1220 -- Duplicate certificates MAY be omitted 1222 Certificate Confirmation -- certConf 1224 Field Value 1226 header 1227 -- As described in section 3.1 1229 body 1230 -- The message of the EE sends confirmation to the PKI 1231 -- management entity to accept or reject the issued certificates 1232 certConf REQUIRED 1233 -- MUST be exactly one CertStatus 1234 CertStatus REQUIRED 1235 certHash REQUIRED 1236 -- MUST be the hash of the certificate, using the same hash 1237 -- algorithm as used to create the certificate signature 1238 certReqId REQUIRED 1239 -- MUST be set to 0 1240 status RECOMMENDED 1241 -- PKIStatusInfo structure SHOULD be present 1242 -- Omission indicates acceptance of the indicated certificate 1243 status REQUIRED 1244 -- positive values allowed: "accepted" 1245 -- negative values allowed: "rejection" 1246 statusString OPTIONAL 1247 -- MAY be any human-readable text for debugging, logging, or to 1248 -- display in a GUI 1249 failInfo OPTIONAL 1250 -- MUST be present if status is "rejection" 1251 -- MUST be absent if the status is "accepted" 1253 protection REQUIRED 1254 -- As described in section 3.2 1255 -- MUST use the same certificate as for protection of the ir 1257 extraCerts RECOMMENDED 1258 -- SHOULD contain the protection certificate together with its 1259 -- chain, but MAY be omitted if the message size is critical and 1260 -- the PKI management entity did cash the extraCerts from the ir 1261 -- If present, the first certificate in this field MUST be the 1262 -- certificate used for signing this message 1263 -- Self-signed certificates SHOULD NOT be included in 1264 -- extraCerts and 1265 -- MUST NOT be trusted based on the listing in extraCerts in 1266 -- any case 1268 PKI Confirmation -- pkiconf 1269 Field Value 1271 header 1272 -- As described in section 3.1 1274 body 1275 pkiconf REQUIRED 1276 -- The content of this field MUST be NULL 1278 protection REQUIRED 1279 -- As described in section 3.2 1280 -- SHOULD use the same certificate as for protection of the ip 1282 extraCerts RECOMMENDED 1283 -- SHOULD contain the protection certificate together with its 1284 -- chain, but MAY be omitted if the message size is critical and 1285 -- the PKI management entity did cash the extraCerts from the ip 1286 -- If present, the first certificate in this field MUST be the 1287 -- certificate used for signing this message 1288 -- Self-signed certificates SHOULD NOT be included in extraCerts 1289 -- and 1290 -- MUST NOT be trusted based on the listing in extraCerts in 1291 -- any case 1293 4.1.2. Request a certificate from a trusted PKI with signature 1294 protection 1296 This PKI management operation should be used by an EE to request an 1297 additional certificate of the same PKI it already has certificates 1298 from. The EE uses one of these existing certificates to prove its 1299 identity. The certificate request message is signature-protected 1300 using this certificate. 1302 The general message flow for this PKI management operation is the 1303 same as given in Section 4.1.1. 1305 Preconditions: 1307 1 The EE MUST have a certificate enrolled by the PKI it requests 1308 another certificate from in advance to this PKI management 1309 operation to authenticate itself to the PKI management entity 1310 using signature-based protection. 1312 2 The EE SHOULD know the subject name of the CA it requests a 1313 certificate from; this name MAY be established using an enrollment 1314 voucher, the issuer field from a CertReqTemplate response message, 1315 or other configuration means. If the EE does not know the name of 1316 the CA, the PKI management entity MUST know where to route this 1317 request to. 1319 3 The EE MUST authenticate responses from the PKI management entity; 1320 trust MUST be established using an enrollment voucher or other 1321 configuration means. 1323 4 The PKI management entity MUST trust the current PKI; trust MAY be 1324 established using some configuration means. 1326 The message sequence for this PKI management operation is like that 1327 given in [RFC4210] Appendix D.5. 1329 The message sequence for this PKI management operation is identical 1330 to that given in Section 4.1.1, with the following changes: 1332 1 The body of the first request and response MUST be cr and cp, 1333 respectively. 1335 2 The caPubs field in the cp message SHOULD be absent. 1337 4.1.3. Update an existing certificate with signature protection 1339 This PKI management operation should be used by an EE to request an 1340 update of one of the certificates it already has and that is still 1341 valid. The EE uses the certificate it wishes to update to prove its 1342 identity. The certificate request message is signature-protected 1343 using this certificate. 1345 The general message flow for this PKI management operation is the 1346 same as given in Section 4.1.1. 1348 Preconditions: 1350 1 The certificate the EE wishes to update MUST NOT be expired or 1351 revoked. 1353 2 A new public-private key pair SHOULD be used. 1355 The message sequence for this PKI management operation is like that 1356 given in [RFC4210] Appendix D.6. 1358 The message sequence for this PKI management operation is identical 1359 to that given in Section 4.1.1, with the following changes: 1361 1 The body of the first request and response MUST be kur and kup, 1362 respectively. 1364 2 Protection of the kur MUST be performed using the certificate to 1365 be updated. 1367 3 The subject field and/or the subjectAltName extension of the 1368 CertTemplate MUST contain the EE subject name of the existing 1369 certificate to be updated, without modifications. 1371 4 The CertTemplate SHOULD contain the subject and publicKey of the 1372 EE only. 1374 5 The oldCertId control SHOULD be used to make clear which 1375 certificate is to be updated. 1377 6 The caPubs field in the kup message MUST be absent. 1379 As part of the certReq structure of the kur the control is added 1380 right after the certTemplate. 1382 controls 1383 type RECOMMENDED 1384 -- MUST be the value id-regCtrl-oldCertID, if present 1385 value 1386 issuer REQUIRED 1387 serialNumber REQUIRED 1388 -- MUST contain the issuer and serialNumber of the certificate 1389 -- to be updated 1391 4.1.4. Request a certificate from a PKI with MAC protection 1393 This PKI management operation should be used by an EE to request a 1394 certificate of a new PKI without having a certificate to prove its 1395 identity to the target PKI, but there is a shared secret established 1396 between the EE and the PKI. Therefore, the initialization request is 1397 MAC-protected using this shared secret. The PKI management entity 1398 checking the MAC-protection SHOULD replace this protection according 1399 to Section 5.1.2 in case the next hop does not know the shared 1400 secret. 1402 For requirements with regard to proper random number and key 1403 generation please refer to [RFC4086]. 1405 The general message flow for this PKI management operation is the 1406 same as given in Section 4.1.1. 1408 Preconditions: 1410 1 The EE and the PKI management entity MUST share a symmetric key, 1411 this MAY be established by a service technician during initial 1412 local configuration. 1414 2 The EE SHOULD know the subject name of the new CA it requests a 1415 certificate from; this name MAY be established using an enrollment 1416 voucher, the issuer field from a CertReqTemplate response message, 1417 or other configuration means. If the EE does not know the name of 1418 the CA, the PKI management entity MUST know where to route this 1419 request to. 1421 3 The EE MUST authenticate responses from the PKI management entity; 1422 trust MAY be established using the shared symmetric key. 1424 The message sequence for this PKI management operation is like that 1425 given in [RFC4210] Appendix D.4. 1427 The message sequence for this PKI management operation is identical 1428 to that given in Section 4.1.1, with the following changes: 1430 1 The protection of all messages MUST be calculated using Message 1431 Authentication Code (MAC); the protectionAlg field MUST be id- 1432 PasswordBasedMac as described in section 5.1.3.1 of [RFC4210]. 1434 2 The sender MUST contain a name representing the originator of the 1435 message. The senderKID MUST contain a reference all participating 1436 entities can use to identify the symmetric key used for the 1437 protection, e.g., the username of the EE. 1439 3 The extraCerts of the ir, certConf, and pkiConf messages MUST be 1440 absent. 1442 4 The extraCerts of the ip message MUST contain the chain of the 1443 issued certificate and root certificates SHOULD not be included 1444 and MUST NOT be directly trusted in any case. 1446 Part of the protectionAlg structure, where the algorithm identifier 1447 MUST be id-PasswordBasedMac, is a PBMParameter sequence. The fields 1448 of PBMParameter SHOULD remain constant for message protection 1449 throughout this PKI management operation to reduce the computational 1450 overhead. 1452 PBMParameter REQUIRED 1453 salt REQUIRED 1454 -- MUST be the random value to salt the secret key 1455 owf REQUIRED 1456 -- MUST be the algorithm identifier for the one-way function 1457 -- used 1458 -- The one-way function SHA-1 MUST be supported due to 1459 -- [RFC4211] requirements, but SHOULD NOT be used any more 1460 -- SHA-256 SHOULD be used instead 1461 iterationCount REQUIRED 1462 -- MUST be a limited number of times the one-way function is 1463 -- applied 1464 -- To prevent brute force and dictionary attacks a reasonable 1465 -- high number SHOULD be used 1466 mac REQUIRED 1467 -- MUST be the algorithm identifier of the MAC algorithm used 1468 -- The MAC function HMAC-SHA1 MUST be supported due to 1469 -- [RFC4211] requirements, but SHOULD NOT be used any more 1470 -- HMAC-SHA-256 SHOULD be used instead 1472 4.1.5. Request a certificate from a legacy PKI using PKCS#10 request 1474 This PKI management operation should be used by an EE to request a 1475 certificate of a legacy PKI only capable to process PKCS#10 [RFC2986] 1476 certification requests. The EE can prove its identity to the target 1477 PKI by using various protection means as described in Section 4.1.1 1478 or Section 4.1.4. 1480 In contrast to the other PKI management operations described in 1481 Section 4.1, this transaction uses PKCS#10 [RFC2986] instead of CRMF 1482 [RFC4211] for the certificate request for compatibility reasons with 1483 legacy CA systems that require a PKCS#10 certificate request and 1484 cannot process CRMF [RFC4211] requests. In such case the PKI 1485 management entity MUST extract the PKCS#10 certificate request from 1486 the p10cr and provides it separately to the CA. 1488 The general message flow for this PKI management operation is the 1489 same as given in Section 4.1.1, but the public key is contained in 1490 the subjectPKInfo of the PKCS#10 certificate request. 1492 Preconditions: 1494 1 The EE MUST either have a certificate enrolled from this or any 1495 other accepted PKI, or a shared secret known to the PKI and the EE 1496 to authenticate itself to the RA. 1498 2 The EE SHOULD know the subject name of the CA it requests a 1499 certificate from; this name MAY be established using an enrollment 1500 voucher, the issuer field from a CertReqTemplate response message, 1501 or other configuration means. If the EE does not know the name of 1502 the CA, the RA MUST know where to route this request to. 1504 3 The EE MUST authenticate responses from the RA; trust MAY be 1505 established by an available root certificate, using an enrollment 1506 voucher, or other configuration means. 1508 4 The RA MUST trust the current or the PKI the EE uses to 1509 authenticate itself; trust MAY be established by a corresponding 1510 available root certificate or using some configuration means. 1512 The message sequence for this PKI management operation is identical 1513 to that given in Section 4.1.1, with the following changes: 1515 1 The body of the first request and response MUST be p10cr and cp, 1516 respectively. 1518 2 The certReqId in the cp message MUST be 0. 1520 3 The caPubs field in the cp message SHOULD be absent. 1522 Detailed description of the p10cr message: 1524 Certification Request -- p10cr 1526 Field Value 1528 header 1529 -- As described in section 3.1 1531 body 1532 -- The request of the EE for a new certificate using a PKCS#10 1533 -- certificate request 1534 p10cr REQUIRED 1535 certificationRequestInfo REQUIRED 1536 version REQUIRED 1537 -- MUST be set to 0 to indicate PKCS#10 V1.7 1538 subject REQUIRED 1539 -- MUST contain the suggested subject name of the EE 1540 subjectPKInfo REQUIRED 1541 algorithm REQUIRED 1542 -- MUST include the subject public key algorithm ID 1543 subjectPublicKey REQUIRED 1544 -- MUST include the subject public key algorithm value 1545 attributes OPTIONAL 1546 -- MAY contain a set of end-entity-specific fields or X.509 1547 -- extensions to be included in the requested certificate or used 1548 -- otherwise 1549 signatureAlgorithm REQUIRED 1550 -- The signature algorithm MUST be consistent with the 1551 -- subjectPKInfo field. The hash algorithm used SHOULD be SHA-256 1552 signature REQUIRED 1553 -- MUST containing the self-signature for proof-of-possession 1555 protection REQUIRED 1556 -- As described in section 3.2 1558 extraCerts REQUIRED 1559 -- As described in section 3.3 1561 4.1.6. Generate the key pair centrally at the PKI management entity 1563 This functional extension can be applied in combination with 1564 certificate enrollment as described in Section 4.1.1, Section 4.1.2, 1565 and Section 4.1.4. The functional extension can be used in case an 1566 EE is not able or is not willing to generate its new public-private 1567 key pair itself. It is a matter of the local implementation which 1568 PKI management entity will act as Key Generation Authority (KGA) and 1569 perform the key generation. This PKI management entity MUST have a 1570 certificate containing the additional extended key usage extension 1571 id-kp-cmKGA to be identified by the EE as a legitimate key-generation 1572 authority. In case the KGA generated the new key pair on behalf of 1573 the EE, it can use Section 4.1.1, Section 4.1.2, or Section 4.1.4 to 1574 request the certificate for this key pair as usual. 1576 Generally speaking, in a machine-to-machine scenario it is strongly 1577 preferable to generate public-private key pairs locally at the EE. 1578 Together with proof-of-possession of the private key in the 1579 certification request, this is to make sure that only the entity 1580 identified in the newly issued certificate is the only entity who 1581 ever holt the private key. 1583 There are some cases where an EE is not able or not willing to 1584 locally generate the new key pair. Reasons for this may be the 1585 following: 1587 o Lack of sufficient initial entropy. 1589 Note: Good random numbers are not only needed for key generation, but 1590 also for session keys and nonces in any security protocol. 1591 Therefore, a decent security architecture should anyways support good 1592 random number generation on the EE side or provide enough entropy for 1593 the RNG seed to guarantee good initial pseudo-random number 1594 generation. May be this is not the case at the time of requesting a 1595 certificate during manufacturing. 1597 o Due to lack of computational resources, e.g., in case of RSA keys. 1599 Note: As key generation could be performed in advance to the 1600 certificate enrollment communication, it is often not time critical. 1602 Note: As mentioned in Section 2.1 central key generation may be 1603 required in a push model, where the certificate response message is 1604 transferred by the PKI management entity to the EE without receiving 1605 a previous request message. 1607 If the EE wishes to request central key generation, it MUST fill the 1608 subjectPublicKey field in the certTemplate structure of the request 1609 message with a zero-length BIT STRING. This indicates to the PKI 1610 management entity that a new key pair shall be generated centrally on 1611 behalf of the EE. 1613 Note: As the protection of centrally generated keys in the response 1614 message is being extended from EncryptedValue to EncryptedKey by CMP 1615 Updates [I-D.ietf-lamps-cmp-updates], also the alternative 1616 EnvelopedData can be used. In CRMF Section 2.1.9 [RFC4211] the use 1617 of EncryptedValue has been deprecated in favor of the EnvelopedData 1618 structure. Therefore, this profile specifies using EnvelopedData as 1619 specified in CMS Section 6 [RFC5652]. 1621 +----------------------------------+ 1622 | EnvelopedData | 1623 | [RFC5652] section 6 | 1624 | +------------------------------+ | 1625 | | SignedData | | 1626 | | [RFC5652] section 5 | | 1627 | | +--------------------------+ | | 1628 | | | AsymmetricKeyPackage | | | 1629 | | | [RFC5958] | | | 1630 | | | +----------------------+ | | | 1631 | | | | privateKey | | | | 1632 | | | | OCTET STRING | | | | 1633 | | | +----------------------+ | | | 1634 | | +--------------------------+ | | 1635 | +------------------------------+ | 1636 +----------------------------------+ 1638 Figure 3: Encrypted private key container 1640 The PKI management entity delivers the private key in the privateKey 1641 field in the certifiedKeyPair structure of the response message also 1642 containing the newly issued certificate. 1644 The private key MUST be provided as an AsymmetricKeyPackage structure 1645 as defined in RFC 5958 [RFC5958]. 1647 This AsymmetricKeyPackage structure MUST be wrapped in a SignedData 1648 structure, as specified in CMS Section 5 [RFC5652], signed by the KGA 1649 generating the key pair. The signature MUST be performed using a CMP 1650 signer certificate asserting the extended key usage kp-id-cmKGA as 1651 described in CMP Updates [I-D.ietf-lamps-cmp-updates] to show the 1652 authorization to generate key pairs on behalf of an EE. 1654 Note: In case of using password-based key management technique as 1655 described in Section 4.1.6.3 it may not be possible or meaningful to 1656 the EE to validate the KGA signature in the SignedData structure as 1657 shares secrets are used for initial authentication. In this case the 1658 EE MAY omit this signature validation. 1660 This SignedData structure MUST be wrapped in an EnvelopedData 1661 structure, as specified in CMS Section 6 [RFC5652], encrypting it 1662 using a newly generated symmetric content-encryption key. 1664 Note: Instead of the specification in CMP Appendix D 4.4 [RFC4210] 1665 this content-encryption key is not generated on the EE side. As we 1666 just mentioned, central key generation should only be used in this 1667 profile in case of lack of randomness on the EE. 1669 As part of the EnvelopedData structure this content-encryption key 1670 MUST be securely provided to the EE using one of three key management 1671 techniques. The choice of the key management technique to be used by 1672 the PKI management entity depends on the authentication mechanism the 1673 EE choose to protect the request message, see CMP Updates section 3.4 1674 [I-D.ietf-lamps-cmp-updates] for more details on which key management 1675 technique to use. 1677 o Signature protected request message: 1679 * Using a certificate that contains a key usage extension 1680 asserting keyAgreement: The content-encryption key SHALL be 1681 protected using the key agreement key management technique, see 1682 Section 4.1.6.1, if the certificate used by the EE for signing 1683 the respective request message contains the key usage 1684 keyAgreement. If the certificate also contains the key usage 1685 keyEncipherment, the key transport key management technique 1686 SHALL NOT be used. 1688 * Using a certificate that contains a key usage extension 1689 asserting keyEncipherment: The content-encryption key SHALL be 1690 protected using the key transport key management technique, see 1691 Section 4.1.6.2, if the certificate used by the EE for signing 1692 the respective request message contains the key usage 1693 keyEncipherment and not keyAgreement. 1695 o MAC protected request message: The content-encryption key SHALL be 1696 protected using the password-based key management technique, see 1697 Section 4.1.6.3, only if the EE used MAC protection for the 1698 respected request message. 1700 The key agreement key management technique can be supported by most 1701 signature algorithms, as key transport key management technique can 1702 only be supported by a very limited number of algorithms. The 1703 password-based key management technique shall only be used in 1704 combination with MAC protection, which is a side-line in this 1705 document. Therefore, if central key generation is supported, the 1706 support of the key agreement key management technique is REQUIRED and 1707 the support of key transport and password-based key management 1708 techniques are OPTIONAL. 1710 For encrypting the SignedData structure containing the private key a 1711 fresh content-encryption key MUST be generated with enough entropy 1712 with regard to the used symmetric key-encryption algorithm. 1714 Note: Depending on the lifetime of the certificate and the 1715 criticality of the generated private key, it is advisable to use the 1716 strongest available symmetric encryption algorithm. Therefore, this 1717 specification recommends using at least AES-256. 1719 The detailed description of the privateKey field looks like this: 1721 privateKey OPTIONAL 1722 -- MUST be an EnvelopedData structure as specified in 1723 -- CMS [RFC5652] section 6 1724 version REQUIRED 1725 -- MUST be set to 2 1726 recipientInfos REQUIRED 1727 -- MUST be exactly one RecipientInfo 1728 recipientInfo REQUIRED 1729 -- MUST be either KeyAgreeRecipientInfo (see section 5.1.5.1), 1730 -- KeyTransRecipientInfo (see section 5.1.5.2), or 1731 -- PasswordRecipientInfo (see section 5.1.5.3) is used 1732 -- If central key generation is supported, support of 1733 -- KeyAgreeRecipientInfo is REQUIRED and support of 1734 -- KeyTransRecipientInfo and PasswordRecipientInfo are OPTIONAL 1735 encryptedContentInfo 1736 REQUIRED 1737 contentType REQUIRED 1738 -- MUST be id-signedData 1739 contentEncryptionAlgorithm 1740 REQUIRED 1741 -- MUST be the algorithm identifier of the symmetric 1742 -- content-encryption algorithm used 1743 -- As private keys need long-term protection, the use of AES-256 1744 -- or a stronger symmetric algorithm is RECOMMENDED 1745 encryptedContent REQUIRED 1746 -- MUST be the signedData structure as specified in 1747 -- CMS [RFC5652] section 5 in encrypted form 1748 version REQUIRED 1749 -- MUST be set to 3 1750 digestAlgorithms 1751 REQUIRED 1752 -- MUST be exactly one digestAlgorithm identifier 1753 digestAlgorithmIdentifier 1754 REQUIRED 1755 -- MUST be the OID of the digest algorithm used for generating 1756 -- the signature 1757 -- The hash algorithm used SHOULD be SHA-256 1758 encapContentInfo 1759 REQUIRED 1760 -- MUST be the content that is to be signed 1761 contentType REQUIRED 1763 -- MUST be id-ct-KP-aKeyPackage as specified in [RFC5958] 1764 content REQUIRED 1765 AsymmetricKeyPackage 1766 REQUIRED 1767 OneAsymmetricKey 1768 REQUIRED 1769 -- MUST be exactly one asymmetric key package 1770 version REQUIRED 1771 -- The version MUST be v2 1772 privateKeyAlgorithm 1773 REQUIRED 1774 -- The privateKeyAlgorithm field MUST contain 1775 -- the OID of the asymmetric key pair algorithm 1776 privateKey 1777 REQUIRED 1778 -- The privateKey MUST be in the privateKey field 1779 Attributes 1780 OPTIONAL 1781 -- The attributes field SHOULD not be used 1782 publicKey 1783 REQUIRED 1784 -- The publicKey MUST be in the publicKey field 1785 certificates REQUIRED 1786 -- SHOULD contain the certificate, for the private key used 1787 -- to sign the content, together with its chain 1788 -- If present, the first certificate in this field MUST 1789 -- be the certificate used for signing this content 1790 -- Self-signed certificates SHOULD NOT be included 1791 -- and MUST NOT be trusted based on the listing in any case 1792 crls OPTIONAL 1793 -- MAY be present to provide status information on the signer or 1794 -- its CA certificates 1795 signerInfos REQUIRED 1796 -- MUST be exactly one signerInfo 1797 version REQUIRED 1798 -- MUST be set to 3 1799 sid REQUIRED 1800 subjectKeyIdentifier 1801 REQUIRED 1802 -- MUST be the subjectKeyIdentifier of the signer's certificate 1803 digestAlgorithm 1804 REQUIRED 1805 -- MUST be the same OID as in digest algorithm 1806 signatureAlgorithm 1807 REQUIRED 1808 -- MUST be the algorithm identifier of the signature algorithm 1809 -- used for calculation of the signature bits, 1810 -- like sha256WithRSAEncryption or ecdsa-with-SHA256 1811 -- The signature algorithm MUST be consistent with the 1812 -- subjectPublicKeyInfo field of the signer's certificate 1813 signature REQUIRED 1814 -- MUST be the result of the digital signature generation 1816 4.1.6.1. Using key agreement key management technique 1818 This key management technique can be applied in combination with the 1819 PKI management operations specified in Section 4.1.1 to Section 4.1.3 1820 using signature-based protected CMP messages. The public key of the 1821 EE certificate used for the signature-based protection of the request 1822 message MUST also be used for the Ephemeral-Static Diffie-Hellmann 1823 key establishment of the content-encryption key. To use this key 1824 management technique the KeyAgreeRecipientInfo structure MUST be used 1825 in the contentInfo field. 1827 The KeyAgreeRecipientInfo structure included into the EnvelopedData 1828 structure is specified in CMS Section 6.2.2 [RFC5652]. 1830 The detailed description of the KeyAgreeRecipientInfo structure looks 1831 like this: 1833 recipientInfo REQUIRED 1834 -- MUST be KeyAgreeRecipientInfo as specified in 1835 version REQUIRED 1836 -- MUST be set to 3 1837 originator REQUIRED 1838 -- MUST contain the originatorKey sequence 1839 algorithm REQUIRED 1840 -- MUST be the algorithm identifier of the 1841 -- static-ephemeral Diffie-Hellmann algorithm 1842 publicKey REQUIRED 1843 -- MUST be the ephemeral public key of the sending party 1844 ukm OPTIONAL 1845 -- MUST be used when 1-pass ECMQV is used 1846 keyEncryptionAlgorithm 1847 REQUIRED 1848 -- MUST be the same as in the contentEncryptionAlgorithm field 1849 recipientEncryptedKeys 1850 REQUIRED 1851 -- MUST be exactly one recipientEncryptedKey sequence 1852 recipientEncryptedKey 1853 REQUIRED 1854 rid REQUIRED 1855 rKeyId REQUIRED 1856 subjectKeyID 1857 REQUIRED 1858 -- MUST contain the same value as the senderKID in the 1859 -- respective request messages 1860 encryptedKey 1861 REQUIRED 1862 -- MUST be the encrypted content-encryption key 1864 4.1.6.2. Using key transport key management technique 1866 This key management technique can be applied in combination with the 1867 PKI management operations specified in Section 4.1.1 to Section 4.1.3 1868 using signature-based protected CMP messages. The public key of the 1869 EE certificate used for the signature-based protection of the request 1870 message MUST also be used for key encipherment of the content- 1871 encryption key. To use this key management technique the 1872 KeyTransRecipientInfo structure MUST be used in the contentInfo 1873 field. 1875 The KeyTransRecipientInfo structure included into the EnvelopedData 1876 structure is specified in CMS Section 6.2.1 [RFC5652]. 1878 The detailed description of the KeyTransRecipientInfo structure looks 1879 like this: 1881 recipientInfo REQUIRED 1882 -- MUST be KeyTransRecipientInfo as specified in 1883 -- CMS section 6.2.1 [RFC5652] 1884 version REQUIRED 1885 -- MUST be set to 2 1886 rid REQUIRED 1887 subjectKeyIdentifier 1888 REQUIRED 1889 -- MUST contain the same value as the senderKID in the respective 1890 -- request messages 1891 keyEncryptionAlgorithm 1892 REQUIRED 1893 -- MUST contain the key encryption algorithm identifier used for 1894 -- public key encryption 1895 encryptedKey REQUIRED 1896 -- MUST be the encrypted content-encryption key 1898 4.1.6.3. Using password-based key management technique 1900 This key management technique can be applied in combination with the 1901 PKI management operation specified in Section 4.1.4 using MAC 1902 protected CMP messages. The shared secret used for the MAC 1903 protection MUST also be used for the encryption of the content- 1904 encryption key but with a different salt. To use this key management 1905 technique the PasswordRecipientInfo structure MUST be used in the 1906 contentInfo field. 1908 The PasswordRecipientInfo structure included into the EnvelopedData 1909 structure is specified in CMS Section 6.2.4 [RFC5652]. 1911 The detailed description of the PasswordRecipientInfo structure looks 1912 like this: 1914 recipientInfo REQUIRED 1915 -- MUST be PasswordRecipientInfo as specified in 1916 -- CMS section 6.2.4 [RFC5652] 1917 version REQUIRED 1918 -- MUST be set to 0 1919 keyDerivationAlgorithm 1920 REQUIRED 1921 -- MUST be set to id-PBKDF2 as specified in [RFC8018] 1922 -- The same shared secret MUST be used than used in 1923 -- PBMParameter data structure for the MAC protection in the 1924 -- header of this message 1925 salt REQUIRED 1926 -- MUST be the random value to salt the secret key 1927 -- MUST be a different value than used in the PBMParameter 1928 -- data structure of the CMP message protection in the 1929 -- header of this message 1930 iterationCount 1931 REQUIRED 1932 -- MUST be a limited number of times the OWF is applied 1933 -- To prevent brute force and dictionary attacks a reasonable 1934 -- high number SHOULD be used 1935 keyLength REQUIRED 1936 prf REQUIRED 1937 -- MUST be the algorithm identifier of the underlying 1938 -- pseudorandom function 1939 -- The pseudorandom function HMAC-SHA1 MUST be supported 1940 -- due to [RFC8018] requirements, but SHOULD NOT be used any 1941 -- more HMAC-SHA-256 SHOULD be used instead 1942 keyEncryptionAlgorithm 1943 REQUIRED 1944 -- MUST be the same as in the contentEncryptionAlgorithm field 1945 encryptedKey REQUIRED 1946 -- MUST be the encrypted content-encryption key 1948 4.1.7. Delayed enrollment 1950 This functional extension can be applied in combination with 1951 certificate enrollment as described in Section 4.1.1 to 1952 Section 4.1.5. The functional extension can be used in case a PKI 1953 management entity cannot respond to the certificate request in a 1954 timely manner, e.g., due to offline upstream communication or 1955 required registration officer interaction. Depending on the PKI 1956 architecture, it is not necessary that the PKI management entity 1957 directly communicating with the EE initiates the delayed enrollment. 1959 The PKI management entity initiating the delayed enrollment MUST 1960 include the status "waiting" in the response and this response MUST 1961 NOT contain a newly issued certificate. When receiving a response 1962 with status "waiting" the EE MUST send a poll request to the PKI 1963 management entity. The PKI management entity that initiated the 1964 delayed enrollment MUST answers with a poll response containing a 1965 checkAfter time. This value indicates the minimum number of seconds 1966 that must elapse before the EE sends another poll request. As soon 1967 as the PKI management entity can provide the final response message 1968 for the initial request of the EE, it MUST provide this in response 1969 to a poll request. After receiving this response, the EE can 1970 continue the original PKI management operation as described in the 1971 respective section of this document, e.g., send a certConf message. 1973 Typically, intermediate PKI management entities SHOULD NOT change the 1974 sender and recipient nonce even in case an intermediate PKI 1975 management entity modifies a request or a response message. In the 1976 special case of polling between EE and LRA with offline transport 1977 between an LRA and RA, see Section 5.1.4, an exception occurs. The 1978 EE and LRA exchange pollReq and pollRep messages handle the nonce 1979 words as described. When, after pollRep, the final response from the 1980 CA arrives at the LRA, the next response will contain the recipNonce 1981 set to the value of the senderNonce in the original request message 1982 (copied by the CA). The LRA needs to replace the recipNonce in this 1983 case with the senderNonce of the last pollReq because the EE will 1984 validate it in this way. 1986 < TBD: I would appreciate any feedback specifically addressing the 1987 nonce handling in case an offline LRA responding and not forwarding 1988 the pollReq messages. > 1989 Message flow: 1991 Step# EE PKI management entity 1992 1 format ir/cr/p10cr/kur 1993 As described in the 1994 respective section 1995 in this document 1996 2 ->ir/cr/p10cr/kur-> 1997 3 handle request as described 1998 in the respective section 1999 in this document 2000 4 in case no immediate final 2001 response is possible, 2002 receive or format ip, cp 2003 or kup message containing 2004 status "waiting" 2005 5 <- ip/cp/kup <- 2006 6 handle ip/cp/kup 2007 7 format pollReq 2008 8 -> pollReq -> 2009 9 handle, re-protect or 2010 forward pollReq 2011 10 in case the requested 2012 certificate or a 2013 corresponding response 2014 message is available, 2015 receive or format ip, cp, 2016 or kup containing the 2017 issued certificate, or 2018 format or receive pollRep 2019 with appropriate 2020 checkAfter value 2021 11 <- pollRep <- 2022 12 handle pollRep 2023 13 let checkAfter 2024 time elapse 2025 14 continue with line 7 2027 Detailed description of the first ip/cp/kup: 2029 Response with status 'waiting' -- ip/cp/kup 2031 Field Value 2033 header 2034 -- MUST contain a header as described for the first response 2035 -- message of the respective PKI management operation 2037 body 2038 -- The response of the PKI management entity to the request in 2039 -- case no immediate appropriate response can be sent 2040 ip/cp/kup REQUIRED 2041 response REQUIRED 2042 -- MUST be exactly one CertResponse 2043 certReqId REQUIRED 2044 -- MUST be set to 0 2045 status REQUIRED 2046 -- PKIStatusInfo structure MUST be present 2047 status REQUIRED 2048 -- MUST be set to "waiting" 2049 statusString OPTIONAL 2050 -- MAY be any human-readable text for debugging, logging or to 2051 -- display in a GUI 2052 failInfo PROHIBITED 2053 certifiedKeyPair PROHIBITED 2055 protection REQUIRED 2056 -- MUST contain protection as described for the first response 2057 -- message of the respective PKI management operation, but 2058 -- MUST use the protection key of the PKI management entity 2059 -- initiating the delayed enrollment and creating this response 2060 -- message 2062 extraCerts REQUIRED 2063 -- MUST contain certificates as described for the first response 2064 -- message of the respective PKI management operation. 2065 -- As no new certificate is issued yet, no respective certificate 2066 -- chain is included 2068 Polling Request -- pollReq 2070 Field Value 2072 header 2073 -- MUST contain a header as described for the certConf message 2074 -- of the respective PKI management operation 2076 body 2077 -- The message of the EE asks for the final response or for a 2078 -- time to check again 2079 pollReq REQUIRED 2080 certReqId REQUIRED 2081 -- MUST be exactly one value 2082 -- MUST be set to 0 2084 protection REQUIRED 2085 -- MUST contain protection as described for the certConf message 2086 -- of the respective PKI management operation 2088 extraCerts OPTIONAL 2089 -- If present, it MUST contain certificates as described for the 2090 -- certConf message of the respective PKI management operation 2092 Polling Response -- pollRep 2094 Field Value 2096 header 2097 -- MUST contain a header as described for the pkiConf message 2098 -- of the respective PKI management operation 2100 body 2101 -- The message indicated the time to after which the EE may 2102 -- send another pollReq messaged for this transaction 2103 pollRep REQUIRED 2104 -- MUST be exactly one set of the following values 2105 certReqId REQUIRED 2106 -- MUST be set to 0 2107 checkAfter REQUIRED 2108 -- time in seconds to elapse before a new pollReq may be sent by 2109 -- the EE 2111 protection REQUIRED 2112 -- MUST contain protection as described for the pkiConf message 2113 -- of the respective profile, but 2114 -- MUST use the protection key of the PKI management entity that 2115 -- initiated the delayed enrollment and is creating this response 2116 -- message 2118 extraCerts OPTIONAL 2119 -- If present, it MUST contain certificates as described for the 2120 -- pkiConf message of the respective PKI management operation. 2122 Final response -- ip/cp/kup 2124 Field Value 2126 header 2127 -- MUST contain a header as described for the first 2128 -- response message of the respective PKI management operation, 2129 -- but the recipNonce MUST be the senderNonce of the last 2130 -- pollReq message 2132 body 2133 -- The response of the PKI management entity to the initial 2134 -- request as described in the respective PKI management 2135 -- operation 2137 protection REQUIRED 2138 -- MUST contain protection as described for the first response 2139 -- message of the respective PKI management operation, but 2140 -- MUST use the protection key of the PKI management entity that 2141 -- initiated the delayed enrollment and forwarding the response 2142 -- message 2144 extraCerts REQUIRED 2145 -- MUST contain certificates as described for the first 2146 -- response message of the respective PKI management operation 2148 4.2. Revoking a certificate 2150 This PKI management operation should be used by an entity to request 2151 the revocation of a certificate. Here the revocation request is used 2152 by an EE to revoke one of its own certificates. A PKI management 2153 entity could also act as an EE to revoke one of its own certificates. 2155 The revocation request message MUST be signed using the certificate 2156 that is to be revoked to prove the authorization to revoke to the 2157 PKI. The revocation request message is signature-protected using 2158 this certificate. 2160 An EE requests the revocation of an own certificate at the CA that 2161 issued this certificate. The PKI management entity responds with a 2162 message that contains the status of the revocation from the CA. 2164 Preconditions: 2166 1 The certificate the EE wishes to revoke is not yet expired or 2167 revoked. 2169 Message flow: 2171 Step# EE PKI management entity 2172 1 format rr 2173 2 -> rr -> 2174 3 handle, re-protect or 2175 forward rr 2176 4 receive rp 2177 5 <- rp <- 2178 6 handle rp 2180 For this PKI management operation, the EE MUST include exactly one 2181 RevDetails structure in the rr message body. In case no error 2182 occurred the response to the rr MUST be a rp message. The PKI 2183 management entity MUST produce a rp containing a status field with a 2184 single set of values. 2186 Detailed message description: 2188 Revocation Request -- rr 2190 Field Value 2192 header 2193 -- As described in section 3.1 2195 body 2196 -- The request of the EE to revoke its certificate 2197 rr REQUIRED 2198 -- MUST contain exactly one element of type RevDetails 2199 -- If more revocations are desired, further requests MUST be 2200 -- packaged in separate PKI Messages 2201 certDetails REQUIRED 2202 -- MUST be present and is of type CertTemplate 2203 serialNumber REQUIRED 2204 -- MUST contain the certificate serialNumber attribute of the 2205 -- X.509 certificate to be revoked 2206 issuer REQUIRED 2207 -- MUST contain the issuer attribute of the X.509 certificate to 2208 -- be revoked 2209 crlEntryDetails REQUIRED 2210 -- MUST contain exactly one reasonCode of type CRLReason (see 2211 -- [RFC5280] section 5.3.1) 2212 -- If the reason for this revocation is not known or shall not be 2213 -- published the reasonCode MUST be 0 = unspecified 2215 protection REQUIRED 2216 -- As described in section 3.2 and the private key related to the 2217 -- certificate to be revoked 2219 extraCerts REQUIRED 2220 -- As described in section 3.3 2222 Revocation Response -- rp 2224 Field Value 2226 header 2227 -- As described in section 3.1 2229 body 2230 -- The responds of the PKI management entity to the request as 2231 -- appropriate 2232 rp REQUIRED 2233 status REQUIRED 2234 -- MUST contain exactly one element of type PKIStatusInfo 2235 status REQUIRED 2236 -- positive value allowed: "accepted" 2237 -- negative value allowed: "rejection" 2238 statusString OPTIONAL 2239 -- MAY be any human-readable text for debugging, logging or to 2240 -- display in a GUI 2241 failInfo OPTIONAL 2242 -- MAY be present if and only if status is "rejection" 2244 protection REQUIRED 2245 -- As described in section 3.2 2247 extraCerts REQUIRED 2248 -- As described in section 3.3 2250 4.3. Error reporting 2252 This functionality should be used by an EE to report any error 2253 conditions upstream to the PKI management entity. Error reporting by 2254 a PKI management entity downstream to the EE is described in 2255 Section 5.3. 2257 In case the error condition is related to specific details of an ip, 2258 cp, or kup response message and a confirmation is expected the error 2259 condition MUST be reported in the respective certConf message with 2260 negative contents. 2262 General error conditions, e.g., problems with the message header, 2263 protection, or extraCerts, and negative feedback on rp, pollRep, or 2264 pkiConf messages MAY be reported in the form of an error message. 2266 In both situations the EE reports error in the PKIStatusInfo 2267 structure of the respective message. 2269 Depending on the PKI architecture, the PKI management entity MUST 2270 forward the error message (upstream) to the next PKI management 2271 entity and MUST terminate this PKI management operation. 2273 The PKIStatusInfo structure is used to report errors. The 2274 PKIStatusInfo structure SHOULD consist of the following fields: 2276 o status: Here the PKIStatus value "rejection" is the only one 2277 allowed. 2279 o statusString: Here any human-readable valid value for logging or 2280 to display in a GUI SHOULD be added. 2282 o failInfo: Here the PKIFailureInfo values MAY be used in the 2283 following way. For explanation of the reason behind a specific 2284 value, please refer to [RFC4210] Appendix F. 2286 * transactionIdInUse: This is sent by a PKI management entity in 2287 case the received request contains a transaction ID that is 2288 already in use for another transaction. An EE receiving such 2289 error message SHOULD resend the request in a new transaction 2290 using a different transaction ID. 2292 * systemUnavail or systemFailure: This is sent by a PKI 2293 management entity in case a back-end system is not available or 2294 currently not functioning correctly. An EE receiving such 2295 error message SHOULD resend the request in a new transaction 2296 after some time. 2298 Detailed error message description: 2300 Error Message -- error 2302 Field Value 2304 header 2305 -- As described in section 3.1 2307 body 2308 -- The message sent by the EE or the (L)RA/CA to indicate an 2309 -- error that occurred 2310 error REQUIRED 2311 pKIStatusInfo REQUIRED 2312 status REQUIRED 2313 -- MUST have the value "rejection" 2314 statusString RECOMMENDED 2315 -- SHOULD be any human-readable text for debugging, logging 2316 -- or to display in a GUI 2317 failInfo OPTIONAL 2318 -- MAY be present 2320 protection REQUIRED 2321 -- As described in section 3.2 2323 extraCerts OPTIONAL 2324 -- As described in section 3.3 2326 4.4. Support messages 2328 The following support messages offer on demand in-band transport of 2329 content that may be provided by the PKI management entity and 2330 relevant to the EE. The general messages and general response are 2331 used for this purpose. Depending on the environment, these requests 2332 may be answered by the LRA, RA, or CA. 2334 The general message and general response transport InfoTypeAndValue 2335 structures. In addition to those infoType values defined in CMP 2336 [RFC4210] further OIDs MAY be defined to define new PKI management 2337 operations, or general-purpose support messages as needed in a 2338 specific environment. 2340 Content specified in this document is describs the following: 2342 o Request of CA certificates 2344 o Update of Root CA certificates 2345 o Parameters needed for a planned certificate request message 2347 4.4.1. General message and response 2349 The PKI management operation is similar to that given in CMP 2350 Appendix E.5 [RFC4210]. In this section the general message (genm) 2351 and general response (genp) are described. The specific 2352 InfoTypeAndValue structures are described in the following sections. 2354 The behavior in case an error occurs is described in Section 4.3. 2356 Message flow: 2358 Step# EE PKI management entity 2359 1 format genm 2360 2 -> genm -> 2361 3 handle, re-protect or 2362 forward genm 2363 4 format or receive genp 2364 5 <- genp <- 2365 6 handle genp 2367 Detailed message description: 2369 General Message -- genm 2371 Field Value 2373 header 2374 -- As described in section 3.1 2376 body 2377 -- The request of the EE to receive information 2378 genm REQUIRED 2379 -- MUST contain exactly one element of type 2380 -- InfoTypeAndValue 2381 infoType REQUIRED 2382 -- MUST be the OID identifying the specific PKI 2383 -- management operation described below 2384 infoValue OPTIONAL 2385 -- MUST be as described in the specific PKI 2386 -- management operation described below 2388 protection REQUIRED 2389 -- As described in section 3.2 2391 extraCerts REQUIRED 2392 -- As described in section 3.3 2394 General Response -- genp 2396 Field Value 2398 header 2399 -- As described in section 3.1 2401 body 2402 -- The response of the PKI management entity to the 2403 -- information request 2404 genp REQUIRED 2405 -- MUST contain exactly one element of type 2406 -- InfoTypeAndValue 2407 infoType REQUIRED 2408 -- MUST be the OID identifying the specific PKI 2409 -- management operation described below 2410 infoValue OPTIONAL 2411 -- MUST be as described in the specific PKI 2412 -- management operation described below 2414 protection REQUIRED 2415 -- As described in section 3.2 2417 extraCerts REQUIRED 2418 -- As described in section 3.3 2420 < TBD: May be we should not restrict the number of ITAV elements in 2421 the response message to one. > 2423 4.4.2. Get CA certificates 2425 This PKI management operation can be used by an EE to request CA 2426 certificates from the PKI management entity. 2428 An EE requests CA certificates from the PKI management entity by 2429 sending a general message with OID id-it-caCerts as specified in CMP 2430 Updates [I-D.ietf-lamps-cmp-updates]. The PKI management entity 2431 responds with a general response with the same OID that either 2432 contains a SEQUENCE of certificates populated with the available CA 2433 intermediate and issuing CA certificates or with no content in case 2434 no CA certificate is available. 2436 The message sequence for this PKI management operation is as given in 2437 Section 4.4.1, with the following specific content: 2439 1 the body MUST contain as infoType the OID id-it-caCerts 2441 2 the infoValue of the request MUST be absent 2442 3 if present, the infoValue of the response MUST be caCerts field 2444 The infoValue field of the general response containing the id-it- 2445 caCerts OID looks like this: 2447 infoValue OPTIONAL 2448 -- MUST be absent if no CA certificate is available 2449 -- MUST be present if CA certificates are available 2450 -- MUST be a sequence of CMPCertificate 2452 4.4.3. Get root CA certificate update 2454 This PKI management operation can be used by an EE to request an 2455 update of an existing root CA Certificate by the EE. 2457 An EE requests a root CA certificate update from the PKI management 2458 entity by sending a general message with OID id-it-rootCaKeyUpdate as 2459 specified in CMP Updates [I-D.ietf-lamps-cmp-updates]. The PKI 2460 management entity responds with a general response with the same OID 2461 that either contains the update of the root CA certificate consisting 2462 of up to three certificates, or with no content in case no update is 2463 available. 2465 The newWithNew certificate is the new root CA certificates and is 2466 REQUIRED to be present in the response message. The newWithOld 2467 certificate is RECOMMENDED to be present in the response message 2468 though it is REQUIRED for those cases where the receiving entity 2469 trusts the old root CA certificate and wishes to gain trust in the 2470 new root CA certificate. The oldWithNew certificate is OPTIONAL 2471 though it is only needed in a scenario where the requesting entity 2472 already trusts the new root CA certificate and wants to gain trust in 2473 the old root certificate. 2475 The message sequence for this PKI management operation is as given in 2476 Section 4.4.1, with the following specific content: 2478 1 the body MUST contain as infoType the OID id-it-rootCaKeyUpdate 2480 2 the infoValue of the request MUST be absent 2482 3 if present, the infoValue of the response MUST be a 2483 RootCaKeyUpdate structure 2485 The infoValue field of the general response containing the id-it- 2486 rootCaKeyUpdate extension looks like this: 2488 infoValue OPTIONAL 2489 -- MUST be absent if no update of the root CA certificate is 2490 -- available 2491 -- MUST be present if an update of the root CA certificate 2492 -- is available and MUST be of type RootCaKeyUpdate 2493 newWithNew REQUIRED 2494 -- MUST be present if infoValue is present 2495 -- MUST contain the new root CA certificate 2496 newWithOld RECOMMENDED 2497 -- SHOULD be present if infoValue is present 2498 -- MUST contain an X.509 certificate containing the new public 2499 -- root CA key signed with the old private root CA key 2500 oldWithNew OPTIONAL 2501 -- MAY be present if infoValue is present 2502 -- MUST contain an X.509 certificate containing the old public 2503 -- root CA key signed with the new private root CA key 2505 < TBD: In case the PKI management entity serves for different Root 2506 CAs. There are three different options to handle this: - The EE 2507 specifies by means of an respective lable in the http endpoint for 2508 which Root CA certificate the update is requested. - The EE transfers 2509 the oldWithOld certificate in the InfoValue of the request. - The PKI 2510 management entity provides RootCaKeyUpdate element all Root CAs an 2511 update is available. > 2513 4.4.4. Get certificate request template 2515 This PKI management operation can be used by an EE to request a 2516 template with parameters for a future certificate request operation. 2518 An EE requests certificate request parameter from the PKI management 2519 entity by sending a general message with OID id-it-certReqTemplate as 2520 specified in CMP Updates [I-D.ietf-lamps-cmp-updates]. The PKI 2521 management entity responds with a general response with the same OID 2522 that either contains a certificate template containing requirements 2523 on certificate fields and extensions and optionally a sequence of 2524 control fields containing requirements on algorithm identifier or RSA 2525 key lengths for key pair generation, or with no content in case no 2526 specific requirements are made by the PKI. 2528 The EE SHOULD follow the requirements from the received CertTemplate 2529 and the optional control fields, by filling in all the fields 2530 requested and taking over all the field values provided. The EE 2531 SHOULD NOT add further CertTemplate fields, Name components, and 2532 extensions or their (sub-)components. 2534 Note: We deliberately do not use 'MUST' or 'MUST NOT' here in order 2535 to allow more flexibility in case the rules given here are not 2536 sufficient for specific scenarios. The EE can populate the 2537 certificate request as wanted and ignore any of the requirements 2538 contained in the CertReqTemplate response message. On the other 2539 hand, a PKI management entity is free to ignore or replace the 2540 content of the certificate request provided by the EE. The 2541 CertReqTemplate PKI management operation offers means to ease a joint 2542 understanding which fields should be used. 2544 In case a field of type Name, e.g., issuer or subject, is present in 2545 the CertTemplate but has the value NULL-DN (i.e., has an empty list 2546 of RDN components) the field SHOULD be included with content provided 2547 by the EE. Similarly, in case an X.509v3 extension is present but 2548 its extnValue is empty this means that the extension SHOULD be 2549 included with content provided by the EE. In case a Name component, 2550 for instance a common name or serial number, is given but has an 2551 empty string value the EE SHOULD fill in a value. Similarly, in case 2552 an extension has sub-components (e.g., an IP address in a 2553 SubjectAltName field) with empty value, the EE SHOULD fill in a 2554 value. 2556 The EE MUST ignore (i.e., not include and fill in) empty fields, 2557 extensions, and sub-components that it does not know. 2559 The publicKey field of type SubjectPublicKeyInfo in the CertTemplate 2560 MUST no algorithm ID in the algorithm field and a zero-length BIT 2561 STRING in the subjectPublicKey field. In case the PKI management 2562 entity whishes to make stipulation on supported algorithms the EE may 2563 use for key generation, this MUST be specified using the control 2564 fields. 2566 The control with the OID id-regCtrl-algId, as specified in CMP 2567 Updates [I-D.ietf-lamps-cmp-updates], specifies algorithms other that 2568 RSA. The algorithm field in SubjectPublicKeyInfo specifies the type 2569 of the public key to request a certificate for. The algorithm field 2570 contains the key type OID of the public key. For EC keys the full 2571 curve information MUST be specified as described in the respective 2572 standard documents. The algorithm field MUST be followed by a zero- 2573 length BIT STRING for the subjectPublicKey. 2575 The control with the OID id-regCtrl-rsaKeyLen, as specified in CMP 2576 Updates [I-D.ietf-lamps-cmp-updates], specifies RSA keys of the 2577 specified key length. In case several control fields are present the 2578 EE is free to choose one of the specified algorithms for key pair 2579 generation. In case no control field is not present the EE is free 2580 to choose the public key type and parameters. 2582 In the certTemplate structure the serialNumber, signingAlg, 2583 issuerUID, and subjectUID fields MUST be omitted. 2585 The message sequence for this PKI management operation is as given in 2586 Section 4.4.1, with the following specific content: 2588 1 the body MUST contain as infoType the OID id-it-certReqTemplate 2590 2 the infoValue of the request MUST be absent 2592 3 if present, the infoValue of the response MUST be a certTemplate 2593 structure and an optional SEQUENCE of AttributeTypeAndValue of 2594 type id-regCtrl-algId or id-regCtrl-rsaKeyLen 2596 The infoValue field of the general response containing the id-it- 2597 certReqTemplate OID looks like this: 2599 InfoValue OPTIONAL 2600 -- MUST be absent if no requirements are available 2601 -- MUST be present if the PKI management entity has any 2602 -- requirements on the content of the certificates template 2603 certTemplate REQUIRED 2604 -- MUST be present if infoValue is present 2605 -- MUST contain the prefilled certTemplate structure elements 2606 -- The SubjectPublicKeyInfo MUST contain no algorithm ID in the 2607 -- algorithm field and a zero-length BIT STRING in the 2608 -- subjectPublicKey field 2609 controls OPTIONAL 2610 -- MUST be absent if no requirements on algorithms are available 2611 -- MUST be present if the PKI management entity has any 2612 -- requirements on the algorithms to be used for key generation 2613 -- MUST contain one AttributeTypeAndValue per supported algorithm 2614 -- MAY be of type id-regCtrl-algId or id-regCtrl-rsaKeyLen 2616 5. LRA and RA focused PKI management operations 2618 This chapter focuses on the communication among different PKI 2619 management entities. Depending on the network and PKI solution 2620 design, these will either be an LRA, RA or CA. 2622 Typically, a PKI management entity forwards messages from downstream, 2623 but it may also reply to them itself. Besides forwarding of received 2624 messages a PKI management entity could also need to revoke 2625 certificates of EEs, report errors, or may need to manage its own 2626 certificates. 2628 5.1. Forwarding of messages 2630 Each CMP request message (i.e., ir, cr, p10cr, kur, pollReq, or 2631 certConf) or error message coming from an EE or the previous 2632 (downstream) PKI management entity MUST be sent to the next 2633 (upstream) PKI management entity. This PKI management entity MUST 2634 forward response messages to the next (downstream) PKI management 2635 entity or EE. 2637 The PKI management entity SHOULD verify the protection, the syntax, 2638 the required message fields, the message type, and if applicable the 2639 authorization and the proof-of-possession of the message. Additional 2640 checks or actions MAY be applied depending on the PKI solution 2641 requirements and concept. If one of these verification procedures 2642 fails, the (L)RA SHOULD respond with a negative response message and 2643 SHOULD not forward the message further upstream. General error 2644 conditions should be handled as described in Section 4.3 and 2645 Section 5.3. 2647 A PKI management entity SHOULD not change the received message if not 2648 necessary. The PKI management entity SHOULD only update the message 2649 protection if it is technically necessary. Concrete PKI system 2650 specifications may define in more detail if and when to do so. 2652 This is particularly relevant in the upstream communication of a 2653 request message. 2655 Each hop in a chain of PKI management entity has one or more 2656 functionalities, e.g., a PKI management entity 2658 o may need to verify the identities of EEs or base authorization 2659 decisions for certification request processing on specific 2660 knowledge of the local setup, e.g., by consulting an inventory or 2661 asset management system, 2663 o may need to add fields to certificate request messages, 2665 o may need to store data from a message in a database for later 2666 usage or documentation purposes, 2668 o may provide traversal of a network boundary, 2670 o may need to double-check if the messages transferred back and 2671 forth are properly protected and well formed, 2673 o may provide a proof that it has performed all required checks, 2674 o may initiate a delayed enrollment due to offline upstream 2675 communication or registration officer interaction, 2677 o may grant the request of an EE to omit sending a confirmation 2678 message, or 2680 o can collect messages from different LRAs and forward them to the 2681 CA. 2683 Therefore, the decision if a message should be forwarded 2685 o unchanged with the original protection, 2687 o unchanged with a new protection, or 2689 o changed with a new protection 2691 depends on the PKI solution design and the associated security policy 2692 (CP/CPS [RFC3647]). 2694 This section specifies the different options a PKI management entity 2695 may implement and use. 2697 A PKI management entity MAY update the protection of a message 2699 o if it performs changes to the header or the body of the message, 2701 o if it needs to prove checks or validations performed on the 2702 message to one of the next (upstream) PKI components, 2704 o if it needs to protect the message using a key and certificate 2705 from a different PKI, or 2707 o if it needs to replace a MAC based-protection. 2709 This is particularly relevant in the upstream communication of 2710 certificate request messages. 2712 The message protection covers only the header and the body and not 2713 the extraCerts. The PKI management entity MAY change the extraCerts 2714 in any of the following message adaptations, e.g., to sort or add 2715 needed or to delete needless certificates to support the next hop. 2716 This may be particularly helpful to extend upstream messages with 2717 additional certificates or to reduce the number of certificates in 2718 downstream messages when forwarding to constrained devices. 2720 5.1.1. Not changing protection 2722 This alternative to forward a message can be used by any PKI 2723 management entity to forward an original CMP message without changing 2724 the header, body or protection. In any of these cases the PKI 2725 management entity acts more like a proxy, e.g., on a network 2726 boundary, implementing no specific RA-like security functionality to 2727 the PKI. 2729 This alternative to forward a message MUST be used for forwarding kur 2730 messages that must not be approved by the respective PKI management 2731 entity. 2733 5.1.2. Replacing protection 2735 The following two alternatives to forward a message can be used by 2736 any PKI management entity to forward a CMP message with or without 2737 changes, but providing its own protection using its CMP signer key to 2738 assert approval of this message. In this case the PKI management 2739 entity acts as an actual Registration Authority (RA), which 2740 implements important security functionality of the PKI. 2742 Before replacing the existing protection by a new protection, the PKI 2743 management entity MUST verify the protection provided by the EE or by 2744 the previous PKI management entity and approve its content including 2745 any own modifications. For certificate requests the PKI management 2746 entity MUST verify in particular the included proof-of-possession 2747 self-signature of the certTemplate using the public key of the 2748 requested certificate and MUST check that the EE, as authenticated by 2749 the message protection, is authorized to request a certificate with 2750 the subject as specified in the certTemplate. 2752 In case the received message has been protected by a CA or another 2753 PKI management entity, the current PKI management entity MUST verify 2754 its protection and approve its content including any own 2755 modifications. For certificate requests the PKI management entity 2756 MUST check that the other PKI management entity, as authenticated by 2757 the protection of the incoming message, was authorized to issue or 2758 forward the request. 2760 These message adaptations MUST NOT be applied to kur request messages 2761 as described in Section 4.1.3 since their original protection using 2762 the key and certificate to be updated needs to be preserved, unless 2763 the regCtrl OldCertId is used to clearly identify the certificate to 2764 be updated. 2766 These message adaptations MUST NOT be applied to certificate request 2767 messages as described in Section 4.1.6requesting key generation by a 2768 Key Generation Authority since their original protection using the 2769 key and certificate for signature protection or the shared secret for 2770 MAC-protection needs to be preserved up to the Key Generation 2771 Authority. 2773 In both cases, kur and central key generation, an additional 2774 signature of a PKI management entity to the original certificate 2775 request message MUST be provided using nested messages as specified 2776 in Section 5.1.3. 2778 5.1.2.1. Keeping proof-of-possession 2780 This alternative to forward a message can be used by any PKI 2781 management entity to forward a CMP message with or without modifying 2782 the message header or body while preserving any included proof-of- 2783 possession. 2785 By replacing the existing protection using its own CMP signer key the 2786 PKI management entity provides a proof of verifying and approving of 2787 the message as described above. 2789 In case the PKI management entity modifies the certTemplate of an ir 2790 or cr message, the message adaptation in Section 5.1.2.2 needs to be 2791 applied instead. 2793 5.1.2.2. Breaking proof-of-possession 2795 This alternative to forward a message can be used by any PKI 2796 management entity to forward an ir or cr message with modifications 2797 of the certTemplate i.e., modification, addition, or removal of 2798 fields. Such changes will break the proof-of-possession provided by 2799 the EE in the original message. 2801 By replacing the existing using its own CMP signer key the PKI 2802 management entity provides a proof of verifying and approving the new 2803 message as described above. 2805 In addition to the above the PKI management entity MUST verify in 2806 particular the proof-of-possession contained in the original message 2807 as described above. If these checks were successfully performed the 2808 PKI management entity MUST change the popo to raVerified. 2810 The popo field MUST contain the raVerified choice in the certReq 2811 structure of the modified message as follows: 2813 popo 2814 raVerified REQUIRED 2815 -- MUST have the value NULL and indicates that the PKI 2816 -- management entity verified the popo of the original 2817 -- message 2819 5.1.3. Adding Protection 2821 This PKI management operation can be used by a PKI management entity 2822 to add another protection to one or several PKI management messages. 2823 Applying an additional protection is specifically important when 2824 forwarding certificate request messages requesting a key update or a 2825 central key generation to preserve the original protection of the EE. 2827 The nested message is a PKI management message containing a 2828 PKIMessages sequence as its body containing one or more CMP messages. 2830 As specified in the updated Section 5.1.3.4 of RFC4210 [RFC4210] (see 2831 CMP Updates [I-D.ietf-lamps-cmp-updates]) there are different use 2832 case for adding another protection by a PKI management entity. 2833 Specific procedures are described in more detail in the following 2834 sections. 2836 The behavior in case an error occurs is described in Section 4.3. 2838 Message flow: 2840 Step# PKI management entity PKI management entity 2841 1 format nested 2842 2 -> nested -> 2843 3 handle, re-protect or 2844 forward nested 2845 4 format or receive nested 2846 5 <- nested <- 2847 6 handle nested 2849 Detailed message description: 2851 Nested Message - nested 2853 Field Value 2855 header 2856 -- As described in section 3.1 2858 body 2859 -- Container to provide additional protection to original 2860 -- messages and to bundle request or response messages 2861 PKIMessages REQUIRED 2862 -- MUST be a sequence of one or more CMP messages 2864 protection REQUIRED 2865 -- As described in section 3.2 using the CMP signer key of 2866 -- the PKI management entity 2868 extraCerts REQUIRED 2869 -- As described in section 3.3 2871 5.1.3.1. Handling a single PKI management message 2873 A PKI management entity may prove successful validation and 2874 authorization of a PKI management message by adding an additional 2875 signature to the original PKI management message. 2877 A PKI management entity SHALL wrap the original PKI management 2878 messages in a nested message structure. The additional signature as 2879 prove of verification and authorization by the PKI management entity 2880 MUST be applies as signature-based message protection of the nested 2881 message. 2883 5.1.3.2. Handling a batch of PKI management messages 2885 A PKI management entity MAY bundle any number of PKI management 2886 messages for batch processing or to transfer a bulk of PKI management 2887 messages via an offline interface using the nested message structure. 2888 The nested message can be either used on the upstream interface 2889 towards the next PKI management entity as well as on the downstream 2890 interface from the PKI management entity towards the EE. 2892 This PKI management operation is typically used on the interface 2893 between LRA and RA to bundle several PKI management messages for 2894 offline transport. In this case the EE needs to make use of delayed 2895 enrollment as described in Section 4.1.7. If the RA may need 2896 different routing information per nested PKI management message a 2897 suitable mechanism may need to be implemented. This mechanism 2898 strongly depends on the requirements of the target architecture; 2899 therefore, it is out of scope of this document. 2901 An initial nested message is generated locally at the PKI management 2902 entity. For the initial nested message, the PKI management entity 2903 acts as a protocol end point and therefore a fresh transactionId and 2904 a fresh senderNonce MUST be used in the header of the nested message. 2905 The recipient field MUST identify the PKI management entity that is 2906 expected to unpack the nested message. An initial nested message 2907 should contain only request messages, e.g., ir, cr, p10cr, kur, 2908 certConf, rr, or genm. While building the initial nested message the 2909 PKI management entity SHOULD store the transactionIds and the 2910 senderNonces of all bundled messages together with the transactionId 2911 of the initial nested message. 2913 Such an initial nested message is sent to the next PKI management 2914 entity and SHOULD be answered with a responding nested message. This 2915 responding message SHOULD use the transactionId of the initial nested 2916 message and return the senderNonce of the initial nested message as 2917 recipNonce of the responding nested message. The responding nested 2918 message SHOULD bundle one response message (e.g. ip, cp, kup, 2919 pkiconf, rp, genp, error) for each request message (i.e., for each 2920 transactionId) in the initial nested message. While unbundling the 2921 responding nested message it is possible to determine lost and 2922 unexpected responses based on the previously stored transactionIds 2923 and senderNonces. While forwarding the unbundled responses, odd 2924 messages SHOULD be dropped, and lost messages should be replaced by 2925 an error message to inform the EE about the failed certificate 2926 management operation. 2928 The PKI management entity building the nested message applies a 2929 signature-based protection using its CMP-signer key as transport 2930 protection. This protection SHALL NOT be regarded as prove of 2931 verification or authorization of the bundled PKI management messages. 2933 5.1.4. Initiating delayed enrollment 2935 This functional extension can be used by a PKI management entity to 2936 initiate delayed enrollment. In this case a PKI management entity 2937 MUST add the status waiting in the response message. The PKI 2938 management entity MUST then reply to the pollReq messages as 2939 described in Section 4.1.7. 2941 5.2. Revoking certificates on behalf of another's entities 2943 This PKI management operation can be used by a PKI management entity 2944 to revoke a certificate of any other entity. This revocation request 2945 message MUST be signed by the PKI management entity using its own CMP 2946 signer key to prove to the PKI authorization to revoke the 2947 certificate on behalf of the EE. 2949 Preconditions: 2951 1 the certificate to be revoked MUST be known to the PKI management 2952 entity 2954 2 the PKI management entity MUST have the authorization to revoke 2955 the certificates of other entities issued by the corresponding CA 2957 The message sequence for this PKI management operation is identical 2958 to that given in Section 4.2, with the following changes: 2960 1 it is not required that the certificate to be revoked is not yet 2961 expired or revoked 2963 2 the PKI management entity acts as EE for this message exchange 2965 3 the rr messages MUST be signed using the CMP signer key of the PKI 2966 management entity. 2968 5.3. Error reporting 2970 This functionality should be used by the PKI management entity to 2971 report any error conditions downstream to the EE. Potential error 2972 reporting by the EE upstream to the PKI management entity is 2973 described in Section 4.3. 2975 In case the error condition is related to specific details of an ir, 2976 cr, p10cr, or kur request message it MUST be reported in the specific 2977 response message, i.e., an ip, cp, or kup with negative contents. 2979 General error conditions, e.g., problems with the message header, 2980 protection, or extraCerts, and negative feedback on rr, pollReq, 2981 certConf, or error messages MUST be reported in the form of an error 2982 message. 2984 In both situations the PKI management entity reports the errors in 2985 the PKIStatusInfo structure of the respective message as described in 2986 Section 4.3. 2988 An EE receiving any such negative feedback SHOULD log the error 2989 appropriately and MUST terminate the current transaction. 2991 6. CMP message transport variants 2993 The CMP messages are designed to be self-contained, such that in 2994 principle any transport can be used. HTTP SHOULD be used for online 2995 transport while file-based transport MAY be used in case offline 2996 transport is required. In case HTTP transport is not desired or 2997 possible, CMP messages MAY also be piggybacked on any other reliable 2998 transport protocol, e.g., CoAP [RFC7252]. 3000 Independently of the means of transport it could happen that messages 3001 are lost, or a communication partner does not respond. In order to 3002 prevent waiting indefinitely, each CMP client component SHOULD use a 3003 configurable per-request timeout, and each CMP server component 3004 SHOULD use a configurable per-response timeout in case a further 3005 message is to be expected from the client side. In this way a 3006 hanging transaction can be closed cleanly with an error and related 3007 resources (for instance, any cached extraCerts) can be freed. 3009 When conveying a CMP messages in HTTP or MIME-based transport 3010 protocols the internet media type "application/pkixcmp" MUST be set 3011 for transport encoding as specified in RFC2510 in Section 5.3 3012 [RFC2510] and RFC6712 in Section 3.4 [RFC7712]. 3014 6.1. HTTP transport 3016 This transport mechanism can be used by a PKI entity to transfer CMP 3017 messages over HTTP. If HTTP transport is used the specifications as 3018 described in [RFC6712] and updated by CMP Updates 3019 [I-D.ietf-lamps-cmp-updates] MUST be followed. 3021 PKI management operations SHOULD use the following URI path: 3023 +----------------------------------+---------------------+----------+ 3024 | PKI management operation | Path | Details | 3025 +----------------------------------+---------------------+----------+ 3026 | Enroll client to new PKI | /initialization | Section | 3027 | (REQUIRED) | | 4.1.1 | 3028 +----------------------------------+---------------------+----------+ 3029 | Enroll client to existing PKI | /certification | Section | 3030 | (OPTIONAL) | | 4.1.2 | 3031 +----------------------------------+---------------------+----------+ 3032 | Update client certificate | /keyupdate | Section | 3033 | (REQUIRED) | | 4.1.3 | 3034 +----------------------------------+---------------------+----------+ 3035 | Enroll client using PKCS#10 | /p10 | Section | 3036 | (OPTIONAL) | | 4.1.5 | 3037 +----------------------------------+---------------------+----------+ 3038 | Enroll client using central key | /serverkeygen | Section | 3039 | generation (OPTIONAL) | | 4.1.6 | 3040 +----------------------------------+---------------------+----------+ 3041 | Revoke client certificate | /revocation | Section | 3042 | (RECOMMENDED) | | 4.2 | 3043 +----------------------------------+---------------------+----------+ 3044 | Get CA certificates (OPTIONAL) | /getcacert | Section | 3045 | | | 4.4.2 | 3046 +----------------------------------+---------------------+----------+ 3047 | Get root CA certificate update | /getrootupdate | Section | 3048 | (OPTIONAL) | | 4.4.3 | 3049 +----------------------------------+---------------------+----------+ 3050 | Get certificate request template | /getcertreqtemplate | Section | 3051 | (OPTIONAL) | | 4.4.4 | 3052 +----------------------------------+---------------------+----------+ 3053 | Additional protection (OPTIONAL) | /nested | Section | 3054 | | | 5.1.3 | 3055 +----------------------------------+---------------------+----------+ 3057 Table 9: HTTP endpoints 3059 Subsequent certConf, error, and pollReq messages are sent to the URI 3060 of the respective PKI management operation. 3062 The discovery mechanism as described in CMP Updates 3063 [I-D.ietf-lamps-cmp-updates] SHOULD be used to query information on 3064 the supported PKI management operations, certificate profiles and 3065 CAs. 3067 As it is very likely, that a CA supports different certification 3068 profiles or that the RA offers PKI management operations for 3069 different issuing CAs, the discovery can also be used to provide the 3070 information about these options. The second example listing contains 3071 the supported PKI management operations for three different 3072 certificate profiles. The supported CA hierarchy consists of one 3073 root CA and two issuing CAs. 3075 Detailed message description: 3077 REQ: GET /.well-known/cmp 3079 RES: Content 3080 ;ct=pkixcmp 3081 ;ct=pkixcmp 3082 ;ct=pkixcmp 3083 ;ct=pkixcmp 3084 ;ct=pkixcmp 3085 ;ct=pkixcmp 3086 ;ct=pkixcmp 3087 ;ct=pkixcmp 3088 ;ct=pkixcmp 3089 ;ct=pkixcmp 3090 ;ct=pkixcmp 3091 ;ct=pkixcmp 3092 ;ct=pkixcmp 3093 ;ct=pkixcmp 3094 ;ct=pkixcmp 3095 ;ct=pkixcmp 3096 ;ct=pkixcmp 3097 ;ct=pkixcmp 3098 ;ct=pkixcmp 3100 There are different options in the handling of the naming. The PKI 3101 management entity either needs to offer the certprofile or CA labels 3102 the EE expects. Alternatively, a mechanism is required to configure 3103 this information to the EE beforehand. 3105 6.2. HTTPS transport using certificates 3107 This transport mechanism can be used by a PKI entity to further 3108 protect the HTTP transport as described in Section 6.1 using TLS 1.2 3109 [RFC5246] or TLS 1.3 [RFC8446] as described in [RFC2818] with 3110 certificate-based authentication. Using this transport mechanism, 3111 the CMP transport via HTTPS MUST use TLS server authentication and 3112 SHOULD use TLS client authentication. 3114 EE: 3116 o The EE SHOULD use a TLS client certificate as far as available. 3117 If no dedicated TLS certificate is available, the EE SHOULD use an 3118 already existing certificate identifying the EE (e.g., a 3119 manufacturer certificate). 3121 o If no TLS certificate is available at the EE, server-only 3122 authenticated TLS SHOULD be used. 3124 o The EE MUST validate the TLS server certificate of its 3125 communication partner. 3127 PKI management entity: 3129 o Each PKI management entity SHOULD use a TLS client certificate on 3130 its upstream (client) interface. 3132 o Each PKI management entity MUST use a TLS server certificate on 3133 its downstream (server) interface. 3135 o Each PKI management entity MUST validate the TLS certificate of 3136 its communication partners. 3138 NOTE: The requirements for checking certificates given in [RFC5280], 3139 [RFC5246] and [RFC8446] MUST be followed for the TLS layer. 3140 Certificate status checking SHOULD be used for the TLS certificates 3141 of communication partners. 3143 6.3. HTTPS transport using shared secrets 3145 This transport mechanism can be used by a PKI entity to further 3146 protect the HTTP transport as described in Section 6.1 using TLS 1.2 3147 [RFC5246] or TLS 1.3 [RFC8446] as described in [RFC2818] with mutual 3148 authentication based on shared secrets as described in [RFC5054]. 3150 EE: 3152 o The EE MUST use the shared symmetric key for authentication. 3154 PKI management entity: 3156 o The PKI management entity MUST use the shared symmetric key for 3157 authentication. 3159 < TBD: It needs to be clarified which cipher suite shall be 3160 recommended as there seems to be no support for TLS-SRP un JavaSE. > 3162 6.4. Offline transport 3164 For transporting CMP messages between PKI entities any mechanism can 3165 be used that is able to store and forward binary objects of 3166 sufficient length and with sufficient reliability while preserving 3167 the order of messages. 3169 The transport mechanism SHOULD be able to indicate message loss, 3170 excessive delay, and possibly other transmission errors. In such 3171 cases the PKI entities using this mechanism SHOULD report an error as 3172 specified in Section 4.3. 3174 6.4.1. File-based transport 3176 CMP messages MAY be transferred between PKI entities using file- 3177 system-based mechanisms, for instance when an off-line end entity or 3178 a PKI management entity performs delayed enrollment. Each file MUST 3179 contain the ASN.1 DER encoding of one CMP message only. There MUST 3180 be no extraneous header or trailer information in the file. The file 3181 type extensions ".PKI" SHOULD be used. 3183 6.4.2. Other asynchronous transport protocols 3185 Other asynchronous transport protocols, e.g., email or website 3186 up-/download, MAY transfer CMP messages between PKI entities. A MIME 3187 wrapping is defined for those environments that are MIME native. The 3188 MIME wrapping in this section is specified in [RFC8551], section 3.1. 3190 The ASN.1 DER encoding of the CMP messages MUST be transferred using 3191 the "application/pkixcmp" content type and base64-encoded content- 3192 transfer-encoding as specified in [RFC2510], section 5.3. A filename 3193 MUST be included either in a content-type or a content-disposition 3194 statement. The extension for the file MUST be ".PKI". 3196 6.5. CoAP transport 3198 In constrained environments where no HTTP transport is desired or 3199 possible, CoAP [RFC7252] as specified in 3200 [I-D.msahni-tbd-cmpv2-coap-transport] MAY be used instead. 3202 6.6. Piggybacking on other reliable transport 3204 For online transfer where no HTTP transport is desired or possible 3205 CMP messages MAY also be transported on some other reliable protocol. 3206 Connection and error handling mechanisms like those specified for 3207 HTTP in [RFC6712] need to be implemented. 3209 Such specification is out of scope of this document and would need to 3210 be specifies in a separate document, e.g., in the scope of the 3211 respective transport protocol used. 3213 7. IANA Considerations 3215 8. Security Considerations 3217 < TBD: Add any security considerations > 3219 9. Acknowledgements 3221 We would like to thank the various reviewers of this document. 3223 10. References 3225 10.1. Normative References 3227 [I-D.ietf-lamps-cmp-updates] 3228 Brockhaus, H., "CMP Updates", draft-ietf-lamps-cmp- 3229 updates-05 (work in progress), September 2020. 3231 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 3232 Requirement Levels", BCP 14, RFC 2119, 3233 DOI 10.17487/RFC2119, March 1997, 3234 . 3236 [RFC2986] Nystrom, M. and B. Kaliski, "PKCS #10: Certification 3237 Request Syntax Specification Version 1.7", RFC 2986, 3238 DOI 10.17487/RFC2986, November 2000, 3239 . 3241 [RFC4086] Eastlake 3rd, D., Schiller, J., and S. Crocker, 3242 "Randomness Requirements for Security", BCP 106, RFC 4086, 3243 DOI 10.17487/RFC4086, June 2005, 3244 . 3246 [RFC4210] Adams, C., Farrell, S., Kause, T., and T. Mononen, 3247 "Internet X.509 Public Key Infrastructure Certificate 3248 Management Protocol (CMP)", RFC 4210, 3249 DOI 10.17487/RFC4210, September 2005, 3250 . 3252 [RFC4211] Schaad, J., "Internet X.509 Public Key Infrastructure 3253 Certificate Request Message Format (CRMF)", RFC 4211, 3254 DOI 10.17487/RFC4211, September 2005, 3255 . 3257 [RFC5280] Cooper, D., Santesson, S., Farrell, S., Boeyen, S., 3258 Housley, R., and W. Polk, "Internet X.509 Public Key 3259 Infrastructure Certificate and Certificate Revocation List 3260 (CRL) Profile", RFC 5280, DOI 10.17487/RFC5280, May 2008, 3261 . 3263 [RFC5652] Housley, R., "Cryptographic Message Syntax (CMS)", STD 70, 3264 RFC 5652, DOI 10.17487/RFC5652, September 2009, 3265 . 3267 [RFC5958] Turner, S., "Asymmetric Key Packages", RFC 5958, 3268 DOI 10.17487/RFC5958, August 2010, 3269 . 3271 [RFC6712] Kause, T. and M. Peylo, "Internet X.509 Public Key 3272 Infrastructure -- HTTP Transfer for the Certificate 3273 Management Protocol (CMP)", RFC 6712, 3274 DOI 10.17487/RFC6712, September 2012, 3275 . 3277 10.2. Informative References 3279 [ETSI-TS133310] 3280 ETSI, "TS 133 310; Network Domain Security (NDS); 3281 Authentication Framework (AF); Release 16; V16.4.0", 3282 August 2020, . 3285 [I-D.msahni-tbd-cmpv2-coap-transport] 3286 Sahni, M., "CoAP Transport for CMPV2", draft-msahni-tbd- 3287 cmpv2-coap-transport-00 (work in progress), June 2020. 3289 [IEC62443-3-3] 3290 IEC, "Industrial communication networks - Network and 3291 system security - Part 3-3: System security requirements 3292 and security levels", IEC 62443-3-3, August 2013, 3293 . 3295 [IEEE802.1AR] 3296 IEEE, "802.1AR Secure Device Identifier", June 2018, 3297 . 3300 [NIST-CSFW] 3301 NIST, "Framework for Improving Critical Infrastructure 3302 Cybersecurity Version 1.1", April 2018, 3303 . 3306 [RFC2510] Adams, C. and S. Farrell, "Internet X.509 Public Key 3307 Infrastructure Certificate Management Protocols", 3308 RFC 2510, DOI 10.17487/RFC2510, March 1999, 3309 . 3311 [RFC2818] Rescorla, E., "HTTP Over TLS", RFC 2818, 3312 DOI 10.17487/RFC2818, May 2000, 3313 . 3315 [RFC3647] Chokhani, S., Ford, W., Sabett, R., Merrill, C., and S. 3316 Wu, "Internet X.509 Public Key Infrastructure Certificate 3317 Policy and Certification Practices Framework", RFC 3647, 3318 DOI 10.17487/RFC3647, November 2003, 3319 . 3321 [RFC5054] Taylor, D., Wu, T., Mavrogiannopoulos, N., and T. Perrin, 3322 "Using the Secure Remote Password (SRP) Protocol for TLS 3323 Authentication", RFC 5054, DOI 10.17487/RFC5054, November 3324 2007, . 3326 [RFC5246] Dierks, T. and E. Rescorla, "The Transport Layer Security 3327 (TLS) Protocol Version 1.2", RFC 5246, 3328 DOI 10.17487/RFC5246, August 2008, 3329 . 3331 [RFC7252] Shelby, Z., Hartke, K., and C. Bormann, "The Constrained 3332 Application Protocol (CoAP)", RFC 7252, 3333 DOI 10.17487/RFC7252, June 2014, 3334 . 3336 [RFC7712] Saint-Andre, P., Miller, M., and P. Hancke, "Domain Name 3337 Associations (DNA) in the Extensible Messaging and 3338 Presence Protocol (XMPP)", RFC 7712, DOI 10.17487/RFC7712, 3339 November 2015, . 3341 [RFC8366] Watsen, K., Richardson, M., Pritikin, M., and T. Eckert, 3342 "A Voucher Artifact for Bootstrapping Protocols", 3343 RFC 8366, DOI 10.17487/RFC8366, May 2018, 3344 . 3346 [RFC8446] Rescorla, E., "The Transport Layer Security (TLS) Protocol 3347 Version 1.3", RFC 8446, DOI 10.17487/RFC8446, August 2018, 3348 . 3350 [RFC8551] Schaad, J., Ramsdell, B., and S. Turner, "Secure/ 3351 Multipurpose Internet Mail Extensions (S/MIME) Version 4.0 3352 Message Specification", RFC 8551, DOI 10.17487/RFC8551, 3353 April 2019, . 3355 [UNISIG-Subset137] 3356 UNISIG, "Subset-137; ERTMS/ETCS On-line Key Management 3357 FFFIS; V1.0.0", December 2015, 3358 . 3360 Appendix A. Example for CertReqTemplate 3362 < TBD: This Appendix must be updated to reflect the change from using 3363 rsaKeyLen to controles. > 3365 This Section provides a concrete example for the content of an 3366 infoValue used of type id-it-certReqTemplate as described in 3367 Section 4.4.4. 3369 Suppose the server requires that the certTemplate contains the issuer 3370 field with a value to be filled in by the EE, the subject field with 3371 a common name to be filled in by the EE and two organizational unit 3372 fields with given values "myDept" and "myGroup", the publicKey field 3373 with an RSA public key of length 2048, the subjectAltName extension 3374 with DNS name "www.myServer.com" and an IP address to be filled in, 3375 the keyUsage extension marked critical with the value 3376 digitalSignature and keyAgreement, and the extKeyUsage extension with 3377 values to be filled in by the EE. Then the infoValue with 3378 certTemplate and rsaKeyLen returned to the EE must be encoded as 3379 follows: 3381 SEQUENCE { 3382 SEQUENCE { 3383 [3] { 3384 SEQUENCE {} 3385 } 3386 [5] { 3387 SEQUENCE { 3388 SET { 3389 SEQUENCE { 3390 OBJECT IDENTIFIER commonName (2 5 4 3) 3391 UTF8String '' 3392 } 3393 } 3394 SEQUENCE { 3395 OBJECT IDENTIFIER organizationalUnitName (2 5 4 11) 3396 UTF8String 'myDept' 3397 } 3398 } 3399 SET { 3400 SEQUENCE { 3401 OBJECT IDENTIFIER organizationalUnitName (2 5 4 11) 3402 UTF8String 'myGroup' 3403 } 3404 } 3405 } 3406 } 3407 [6] { 3408 SEQUENCE { 3409 OBJECT IDENTIFIER rsaEncryption (1 2 840 113549 1 1 1) 3410 NULL 3411 } 3412 BIT STRING, encapsulates { 3413 SEQUENCE {} 3414 } 3415 } 3416 [9] { 3417 SEQUENCE { 3418 OBJECT IDENTIFIER subjectAltName (2 5 29 17) 3419 OCTET STRING, encapsulates { 3420 SEQUENCE { 3421 [2] 'www.myServer.com' 3422 [7] '' 3423 } 3424 } 3425 } 3426 SEQUENCE { 3427 OBJECT IDENTIFIER keyUsage (2 5 29 15) 3428 BOOLEAN TRUE 3429 OCTET STRING, encapsulates { 3430 BIT STRING 3 unused bits 3431 '10001'B 3432 } 3433 } 3434 SEQUENCE { 3435 OBJECT IDENTIFIER extKeyUsage (2 5 29 37) 3436 OCTET STRING, encapsulates { 3437 SEQUENCE {} 3438 } 3439 } 3440 } 3441 } 3442 INTEGER 2048 3443 } 3445 Appendix B. History of changes 3447 Note: This appendix will be deleted in the final version of the 3448 document. 3450 From version 02 -> 03: 3452 o Updated the interoperability with [UNISIG-Subset137] in 3453 Section 1.4. 3455 o Changed Section 2.3 to a tabular layout to enhanced readability 3457 o Added a ToDo to section 3.1 on aligning with the CMP Algorithms 3458 draft that will be set up as decided in IETF 108 3460 o Updated section 4.1.6 to add the AsymmetricKey Package structure 3461 to transport a newly generated private key as decided in IETF 108 3463 o Added a ToDo to section 4.1.7 on required review of the nonce 3464 handling in case an offline LRA responds and not forwards the 3465 pollReq messages 3467 o Updated Section 4 due to the definition of the new ITAV OIDs in 3468 CMP Updates 3470 o Updated Section 4.4.4 to utilize controls instead of rsaKeyLen 3471 (see thread "dtaft-ietf-lamps-cmp-updates and rsaKeyLen") 3473 o Deleted the section on definition and discovery of HTTP URIs and 3474 copied the text to the HTTP transport section and to CMP Updates 3475 section 3.2 3477 o Added some explanation to Section 5.1.2 and Section 5.1.3 on using 3478 nested messages when a protection by the RA is required. 3480 o Deleted the section on HTTP URI definition and discovery as some 3481 content was moved to CMP Updates. The rest of the content was 3482 moved back to the HTTP transport section 3484 o Deleted the ASN.1 module after moving the new OIDs id-it-caCerts, 3485 id-it-rootCaKeyUpdate, and id-it-certReqTemplate to CMP Updates 3487 o Minor changes in wording and addition of some open ToDos 3489 From version 01 -> 02: 3491 o Extend Section 1.4 with regard to conflicts with UNISIG Subset- 3492 137. 3494 o Minor clarifications on extraCerts in Section 3.3 and 3495 Section 4.1.1. 3497 o Complete specification of requesting a certificate from a trusted 3498 PKI with signature protection in Section 4.1.2. 3500 o Changed from symmetric key-encryption to password-based key 3501 management technique in section Section 4.1.6.3 as discussed on 3502 the mailing list (see thread "draft-ietf-lamps-lightweight-cmp- 3503 profile-01, section 5.1.6.1") 3505 o Changed delayed enrollment described in Section 4.1.7 from 3506 recommended to optional as decided at IETF 107 3508 o Introduced the new RootCAKeyUpdate structure for root CA 3509 certificate update in Section 4.4.3 as decided at IETF 107 (also 3510 see email thread "draft-ietf-lamps-lightweight-cmp-profile-01, 3511 section 5.4.3") 3513 o Extend the description of the CertReqTemplate PKI management 3514 operation, including an example added in the Appendix. Keep 3515 rsaKeyLen as a single integer value in Section 4.4.4 as discussed 3516 on the mailing list (see thread "draft-ietf-lamps-lightweight-cmp- 3517 profile-01, section 5.4.4") 3519 o Deleted Sections "Get certificate management configuration" and 3520 "Get enrollment voucher" as decided at IETF 107 3522 o Complete specification of adding an additional protection by an 3523 PKI management entity in Section 5.1.3. 3525 o Added a section on HTTP URI definition and discovery and extended 3526 Section 6.1 on definition and discovery of supported HTTP URIs and 3527 content types, add a path for nested messages as specified in 3528 Section 5.1.3 and delete the paths for /getCertMgtConfig and 3529 /getVoucher 3531 o Changed Section 6.4 to address offline transport and added more 3532 detailed specification file-based transport of CMP 3534 o Added a reference to the new I-D of Mohit Sahni on "CoAP Transport 3535 for CMPV2" in Section 6.5; thanks to Mohit supporting the effort 3536 to ease utilization of CMP 3538 o Moved the change history to the Appendix 3540 o Minor changes in wording 3542 From version 00 -> 01: 3544 o Harmonize terminology with CMP [RFC4210], e.g., 3546 * transaction, message sequence, exchange, use case -> PKI 3547 management operation 3549 * PKI component, (L)RA/CA -> PKI management entity 3551 o Minor changes in wording 3553 From draft-brockhaus-lamps-lightweight-cmp-profile-03 -> draft-ietf- 3554 lamps-lightweight-cmp-profile-00: 3556 o Changes required to reflect WG adoption 3558 o Minor changes in wording 3560 From version 02 -> 03: 3562 o Added a short summary of [RFC4210] Appendix D and E in 3563 Section 1.3. 3565 o Clarified some references to different sections and added some 3566 clarification in response to feedback from Michael Richardson and 3567 Tomas Gustavsson. 3569 o Added an additional label to the operational path to address 3570 multiple CAs or certificate profiles in Section 6.1. 3572 From version 01 -> 02: 3574 o Added some clarification on the key management techniques for 3575 protection of centrally generated keys in Section 4.1.6. 3577 o Added some clarifications on the certificates for root CA 3578 certificate update in Section 4.4.3. 3580 o Added a section to specify the usage of nested messages for RAs to 3581 add an additional protection for further discussion, see 3582 Section 5.1.3. 3584 o Added a table containing endpoints for HTTP transport in 3585 Section 6.1 to simplify addressing PKI management entities. 3587 o Added some ToDos resulting from discussion with Tomas Gustavsson. 3589 o Minor clarifications and changes in wording. 3591 From version 00 -> 01: 3593 o Added a section to specify the enrollment with an already trusted 3594 PKI for further discussion, see Section 4.1.2. 3596 o Complete specification of requesting a certificate from a legacy 3597 PKI using a PKCS#10 [RFC2986] request in Section 4.1.5. 3599 o Complete specification of adding central generation of a key pair 3600 on behalf of an end entity in Section 4.1.6. 3602 o Complete specification of handling delayed enrollment due to 3603 asynchronous message delivery in Section 4.1.7. 3605 o Complete specification of additional support messages, e.g., to 3606 update a Root CA certificate or to request an RFC 8366 [RFC8366] 3607 voucher, in Section 4.4. 3609 o Minor changes in wording. 3611 From draft-brockhaus-lamps-industrial-cmp-profile-00 -> draft- 3612 brockhaus-lamps-lightweight-cmp-profile-00: 3614 o Change focus from industrial to more multi-purpose use cases and 3615 lightweight CMP profile. 3617 o Incorporate the omitted confirmation into the header specified in 3618 Section 3.1 and described in the standard enrollment use case in 3619 Section 4.1.1 due to discussion with Tomas Gustavsson. 3621 o Change from OPTIONAL to RECOMMENDED for use case 'Revoke another's 3622 entities certificate' in Section 5.2, because it is regarded as 3623 important functionality in many environments to enable the 3624 management station to revoke EE certificates. 3626 o Complete the specification of the revocation message flow in 3627 Section 4.2 and Section 5.2. 3629 o The CoAP based transport mechanism and piggybacking of CMP 3630 messages on top of other reliable transport protocols is out of 3631 scope of this document and would need to be specified in another 3632 document. 3634 o Further minor changes in wording. 3636 Authors' Addresses 3638 Hendrik Brockhaus 3639 Siemens AG 3641 Email: hendrik.brockhaus@siemens.com 3642 Steffen Fries 3643 Siemens AG 3645 Email: steffen.fries@siemens.com 3647 David von Oheimb 3648 Siemens AG 3650 Email: david.von.oheimb@siemens.com