idnits 2.17.1 draft-ietf-lamps-lightweight-cmp-profile-04.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 == The document seems to lack the recommended RFC 2119 boilerplate, even if it appears to use RFC 2119 keywords -- however, there's a paragraph with a matching beginning. Boilerplate error? (The document does seem to have the reference to RFC 2119 which the ID-Checklist requires). == 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: privateKey OPTIONAL -- MUST be an EnvelopedData structure as specified in -- CMS [RFC5652] section 6 version REQUIRED -- MUST be set to 2 recipientInfos REQUIRED -- MUST be exactly one RecipientInfo recipientInfo REQUIRED -- MUST be either KeyAgreeRecipientInfo (see section 5.1.5.1), -- KeyTransRecipientInfo (see section 5.1.5.2), or -- PasswordRecipientInfo (see section 5.1.5.3) is used -- If central key generation is supported, support of -- KeyAgreeRecipientInfo is REQUIRED and support of -- KeyTransRecipientInfo and PasswordRecipientInfo are OPTIONAL encryptedContentInfo REQUIRED contentType REQUIRED -- MUST be id-signedData contentEncryptionAlgorithm REQUIRED -- MUST be the algorithm identifier of the symmetric -- content-encryption algorithm used encryptedContent REQUIRED -- MUST be the signedData structure as specified in -- CMS [RFC5652] section 5 in encrypted form version REQUIRED -- MUST be set to 3 digestAlgorithms REQUIRED -- MUST be exactly one digestAlgorithm identifier digestAlgorithmIdentifier REQUIRED -- MUST be the OID of the digest algorithm used for generating -- the signature encapContentInfo REQUIRED -- MUST be the content that is to be signed contentType REQUIRED -- 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 AlgorithmIdentifier 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 (November 2, 2020) is 1272 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) -- Looks like a reference, but probably isn't: '3' on line 3380 -- Looks like a reference, but probably isn't: '5' on line 3383 -- Looks like a reference, but probably isn't: '6' on line 3404 -- Looks like a reference, but probably isn't: '9' on line 3413 -- Looks like a reference, but probably isn't: '2' on line 3418 -- Looks like a reference, but probably isn't: '7' on line 3419 -- Possible downref: Normative reference to a draft: ref. 'I-D.housley-lamps-crmf-update-algs' == Outdated reference: A later version (-15) exists of draft-ietf-lamps-cmp-algorithms-00 == 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 (~~), 10 warnings (==), 11 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 LAMPS Working Group H. Brockhaus, Ed. 3 Internet-Draft S. Fries 4 Intended status: Standards Track D. von Oheimb 5 Expires: May 6, 2021 Siemens 6 November 2, 2020 8 Lightweight CMP Profile 9 draft-ietf-lamps-lightweight-cmp-profile-04 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 use 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 May 6, 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 . . . . . . . . . . . . . . . . . . 6 63 1.4. Compatibility with existing CMP profiles . . . . . . . . 8 64 1.5. Scope of this document . . . . . . . . . . . . . . . . . 9 65 1.6. Structure of this document . . . . . . . . . . . . . . . 10 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 . . . . . . . . . . . . 13 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 . . . . . . . . . 15 74 2.4. CMP message transport . . . . . . . . . . . . . . . . . . 16 75 3. Generic parts of the PKI message . . . . . . . . . . . . . . 17 76 3.1. General description of the CMP message header . . . . . . 18 77 3.2. General description of the CMP message protection . . . . 20 78 3.3. General description of CMP message extraCerts . . . . . . 21 79 4. End Entity focused PKI management operations . . . . . . . . 21 80 4.1. Requesting a new certificate from a PKI . . . . . . . . . 22 81 4.1.1. Request a certificate from a new PKI with signature 82 protection . . . . . . . . . . . . . . . . . . . . . 23 83 4.1.2. Request a certificate from a trusted PKI with 84 signature protection . . . . . . . . . . . . . . . . 29 85 4.1.3. Update an existing certificate with signature 86 protection . . . . . . . . . . . . . . . . . . . . . 30 87 4.1.4. Request a certificate from a PKI with MAC protection 31 88 4.1.5. Request a certificate from a legacy PKI using PKCS#10 89 request . . . . . . . . . . . . . . . . . . . . . . . 33 90 4.1.6. Generate the key pair centrally at the PKI management 91 entity . . . . . . . . . . . . . . . . . . . . . . . 36 92 4.1.6.1. Using key agreement key management technique . . 41 93 4.1.6.2. Using key transport key management technique . . 42 94 4.1.6.3. Using password-based key management technique . . 43 95 4.1.7. Delayed enrollment . . . . . . . . . . . . . . . . . 44 96 4.2. Revoking a certificate . . . . . . . . . . . . . . . . . 48 97 4.3. Error reporting . . . . . . . . . . . . . . . . . . . . . 50 98 4.4. Support messages . . . . . . . . . . . . . . . . . . . . 52 99 4.4.1. Get CA certificates . . . . . . . . . . . . . . . . . 54 100 4.4.2. Get root CA certificate update . . . . . . . . . . . 55 101 4.4.3. Get certificate request template . . . . . . . . . . 56 102 5. LRA and RA focused PKI management operations . . . . . . . . 58 103 5.1. Forwarding of messages . . . . . . . . . . . . . . . . . 59 104 5.1.1. Not changing protection . . . . . . . . . . . . . . . 61 105 5.1.2. Replacing protection . . . . . . . . . . . . . . . . 61 106 5.1.2.1. Keeping proof-of-possession . . . . . . . . . . . 62 107 5.1.2.2. Breaking proof-of-possession . . . . . . . . . . 62 108 5.1.3. Adding Protection . . . . . . . . . . . . . . . . . . 63 109 5.1.3.1. Handling a single PKI management message . . . . 64 110 5.1.3.2. Handling a batch of PKI management messages . . . 64 111 5.1.4. Initiating delayed enrollment . . . . . . . . . . . . 65 112 5.2. Revoking certificates on behalf of another's entities . . 66 113 5.3. Error reporting . . . . . . . . . . . . . . . . . . . . . 66 114 6. CMP message transport variants . . . . . . . . . . . . . . . 67 115 6.1. HTTP transport . . . . . . . . . . . . . . . . . . . . . 67 116 6.2. HTTPS transport using certificates . . . . . . . . . . . 69 117 6.3. HTTPS transport using shared secrets . . . . . . . . . . 70 118 6.4. Offline transport . . . . . . . . . . . . . . . . . . . . 71 119 6.4.1. File-based transport . . . . . . . . . . . . . . . . 71 120 6.4.2. Other asynchronous transport protocols . . . . . . . 71 121 6.5. CoAP transport . . . . . . . . . . . . . . . . . . . . . 71 122 6.6. Piggybacking on other reliable transport . . . . . . . . 71 123 7. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 72 124 8. Security Considerations . . . . . . . . . . . . . . . . . . . 72 125 9. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 72 126 10. References . . . . . . . . . . . . . . . . . . . . . . . . . 72 127 10.1. Normative References . . . . . . . . . . . . . . . . . . 72 128 10.2. Informative References . . . . . . . . . . . . . . . . . 73 129 Appendix A. Example for CertReqTemplate . . . . . . . . . . . . 75 130 Appendix B. History of changes . . . . . . . . . . . . . . . . . 77 131 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 81 133 1. Introduction 135 [RFC Editor: please delete]:!!! The change history was moved to 136 Appendix B !!! 138 [RFC Editor: please delete]: The labels 'RFC-CMP-Alg' and 'RFC-CRMF- 139 Alg' in ASN.1 Syntax needs to be replaced with the RFC numbers of CMP 140 Algorithms [I-D.ietf-lamps-cmp-algorithms] and CRMF Algorithm 141 Requirements Update [I-D.housley-lamps-crmf-update-algs], when 142 available. 144 This document specifies PKI management operations supporting machine- 145 to-machine and IoT use cases. The focus lies on maximum automation 146 and interoperable implementation of all involved PKI entities from 147 end entities (EE) through an optional Local Registration Authority 148 (LRA) and the RA up to the CA. The profile makes use of the concepts 149 and syntax specified in CMP [RFC4210], CRMF [RFC4211], HTTP transfer 150 for CMP [RFC6712], and CMP Updates [I-D.ietf-lamps-cmp-updates]. 151 Especially CMP and CRMF are very feature-rich standards, while only a 152 limited subset of the specified functionality is needed in many 153 environments. Additionally, the standards are not always precise 154 enough on how to interpret and implement the described concepts. 155 Therefore, this document aims at tailoring and specifying in more 156 detail how to use these concepts to implement lightweight automated 157 certificate management. 159 1.1. Motivation for profiling CMP 161 CMP was standardized in 1999 and is implemented in several CA 162 products. In 2005 a completely reworked and enhanced version 2 of 163 CMP [RFC4210] and CRMF [RFC4211] has been published followed by a 164 document specifying a transfer mechanism for CMP messages using http 165 [RFC6712] in 2012. 167 Though CMP is a very solid and capable protocol it could be used more 168 widely. The most important reason for not more intense application 169 of CMP appears to be that the protocol is offering a large set of 170 features and options but being not always precise enough and leaving 171 room for interpretation. On the one hand, this makes CMP applicable 172 to a very wide range of scenarios, but on the other hand a full 173 implementation of all options is unrealistic because this would take 174 enormous effort. 176 Moreover, many details of the CMP protocol have been left open or 177 have not been specified in full preciseness. The profiles specified 178 in Appendix D and E of [RFC4210] offer some more detailed PKI 179 management operations. But the specific needs of highly automated 180 scenarios for a machine-to-machine communication are not covered 181 sufficiently. 183 As also ETSI and UNISIG already put across, profiling is a way of 184 coping with the challenges mentioned above. To profile means to take 185 advantage of the strengths of the given protocol, while explicitly 186 narrowing down the options it provides to exactly those needed for 187 the purpose(s) at hand and eliminating all identified ambiguities. 188 In this way all the general and applicable aspects of the protocol 189 can be taken over and only the peculiarities of the target scenario 190 need to be dealt with specifically. 192 Doing such a profiling for a new target environment can be a high 193 effort because the range of available options needs to be well 194 understood and the selected options need to be consistent with each 195 other and with the intended usage scenario. Since most industrial 196 PKI management use cases typically have much in common it is worth 197 sharing this effort, which is the aim of this document. Other 198 standardization bodies can then reference the needed PKI management 199 operations from this document and do not need to come up with 200 individual profiles. 202 1.2. Motivation for a lightweight profile for CMP 204 The profiles specified in Appendix D and E of CMP have been developed 205 in particular to manage certificates of human end entities. With the 206 evolution of distributed systems and client-server architectures, 207 certificates for machines and applications on them have become widely 208 used. This trend has strengthened even more in emerging industrial 209 and IoT scenarios. CMP is sufficiently flexible to support these 210 very well. 212 Today's IT security architectures for industrial solutions typically 213 use certificates for endpoint authentication within protocols like 214 IPSec, TLS, or SSH. Therefore, the security of these architectures 215 highly relies upon the security and availability of the implemented 216 certificate management procedures. 218 Due to increasing security in operational networks as well as 219 availability requirements, especially on critical infrastructures and 220 systems with a high volume of certificates, a state-of-the-art 221 certificate management must be constantly available and cost- 222 efficient, which calls for high automation and reliability. The NIST 223 Cyber Security Framework [NIST-CSFW] also refers to proper processes 224 for issuance, management, verification, revocation, and audit for 225 authorized devices, users and processes involving identity and 226 credential management. Such PKI operation according to commonly 227 accepted best practices is also required in IEC 62443-3-3 228 [IEC62443-3-3] for security level 2 and higher. 230 Further challenges in many industrial systems are network 231 segmentation and asynchronous communication, where PKI operation is 232 often not deployed on-site but in a more protected environment of a 233 data center or trust center. Certificate management must be able to 234 cope with such network architectures. CMP offers the required 235 flexibility and functionality, namely self-contained messages, 236 efficient polling, and support for asynchronous message transfer with 237 end-to-end security. 239 1.3. Existing CMP profiles 241 As already stated, CMP contains profiles with mandatory and optional 242 transactions in the Appendixes D and E of [RFC4210]. Those profiles 243 focus on management of human user certificates and do only partly 244 address the specific needs for certificate management automation for 245 unattended machine or application-oriented end entities. 247 [RFC4210] specifies in Appendix D the following mandatory PKI 248 management operations (all require support of algorithms was updated 249 by CMP Updates [I-D.ietf-lamps-cmp-updates] and CMP Algorithms 250 Appendix A.1 [I-D.ietf-lamps-cmp-algorithms]; all operations may 251 enroll up to two certificates, one for a locally generated and 252 another optional one for a centrally generated key pair; all require 253 use of certConf/pkiConf messages for confirmation): 255 o Initial registration/certification; an (uninitialized) end entity 256 requests a (first) certificate from a CA using shared secret based 257 message authentication. The content is similar to the PKI 258 management operation specified in Section 4.1.4 of this document. 260 o Certificate request; an (initialized) end entity requests another 261 certificate from a CA using signature or shared secret based 262 message authentication. The content is similar to the PKI 263 management operation specified in Section 4.1.2 of this document. 265 o Key update; an (initialized) end entity requests a certificate 266 from a CA (to update the key pair and/or corresponding certificate 267 that it already possesses) using signature or shared secret based 268 message authentication. The content is similar to the PKI 269 management operation specified in Section 4.1.3 of this document. 271 Due to the two certificates that may be enrolled and the shared 272 secret based authentication, these PKI management operations focus 273 more on the enrollment of human users at a PKI. 275 [RFC4210] specifies in Appendix E the following optional PKI 276 management operations (all require support of algorithms was updated 277 by CMP Updates [I-D.ietf-lamps-cmp-updates] and CMP Algorithms 278 Appendix A.1 [I-D.ietf-lamps-cmp-algorithms]): 280 o Root CA key update; a root CA updates its key pair and produces a 281 CA key update announcement message that can be made available (via 282 some transport mechanism) to the relevant end entities. This 283 operation only supports a push and no pull model. The content is 284 similar to the PKI management operation specified in Section 4.4.2 285 of this document. 287 o Information request/response; an end entity sends a general 288 message to the PKI requesting details that will be required for 289 later PKI management operations. The content is similar to the 290 PKI management operation specified in Section 4.4.3 of this 291 document. 293 o Cross-certification request/response (1-way); creation of a single 294 cross-certificate (i.e., not two at once). The requesting CA MAY 295 choose who is responsible for publication of the cross-certificate 296 created by the responding CA through use of the PKIPublicationInfo 297 control. 299 o In-band initialization using external identity certificate (this 300 PKI management operation may also enroll up to two certificates 301 and requires use of certConf/pkiConf messages for confirmation as 302 specified in Appendix D of [RFC4210]). An (uninitialized) end 303 entity wishes to initialize into the PKI with a CA, CA-1. It 304 uses, for authentication purposes, a pre-existing identity 305 certificate issued by another (external) CA, CA-X. A trust 306 relationship must already have been established between CA-1 and 307 CA-X so that CA-1 can validate the EE identity certificate signed 308 by CA-X. Furthermore, some mechanism must already have been 309 established within the Personal Security Environment (PSE) of the 310 EE that would allow it to authenticate and verify PKIMessages 311 signed by CA-1. The content is similar to the PKI management 312 operation specified in Section 4.1.1 of this document. 314 Both Appendixes focus on EE to CA/RA PKI management operations and do 315 not address further profiling of RA to CA communication as typically 316 used for full backend automation. 318 ETSI makes use of CMP [RFC4210] in its Technical Specification 133 319 310 [ETSI-TS133310] for automatic management of IPSec certificates in 320 UMTS, LTE, and 5G backbone networks. Since 2010 a dedicated CMP 321 profile for initial certificate enrollment and update operations 322 between EE and RA/CA is specified in that document. 324 UNISIG has included a CMP profile for certificate enrollment in the 325 subset 137 specifying the ETRAM/ECTS on-line key management for train 326 control systems [UNISIG-Subset137] in 2015. 328 Both standardization bodies use CMP [RFC4210], CRMF [RFC4211], and 329 HTTP transfer for CMP [RFC6712] to add tailored means for automated 330 PKI management operations for unattended machine or application- 331 oriented end entities. 333 1.4. Compatibility with existing CMP profiles 335 The profile specified in this document is compatible with CMP 336 [RFC4210] Appendixes D and E (PKI Management Message Profiles), with 337 the following exceptions: 339 o signature-based protection is the default protection; an initial 340 PKI management operation may also use HMAC, 342 o certification of a second key pair within the same PKI management 343 operation is not supported, 345 o proof-of-possession (POPO) with self-signature of the certTemplate 346 according to [RFC4211] section 4.1 clause 3 is the recommended 347 default POPO method (deviations are possible by EEs when 348 requesting central key generation and by (L)RAs when using 349 raVerified), 351 o confirmation of newly enrolled certificates may be omitted, and 353 o all PKI management operations consist of request-response message 354 pairs originating at the EE, i.e., announcement messages are 355 omitted. 357 The profile specified in this document is compatible with the CMP 358 profile for UMTS, LTE, and 5G network domain security and 359 authentication framework [ETSI-TS133310], except that: 361 o protection of initial PKI management operations may be HMAC-based, 363 o the subject field is mandatory in certificate templates, and 365 o confirmation of newly enrolled certificates may be omitted. 367 The profile specified in this document is compatible with the CMP 368 profile for on-line key management in rail networks as specified in 369 UNISIG Subset-137 [UNISIG-Subset137], except that: 371 o As stated in Section 4.1.1 a CMP message SHALL only consist of one 372 certificate request (CertReqMsg). As UNISIG Subset-137 Table 6 373 [UNISIG-Subset137] allows to transport more than one certificate 374 request message, this conflicts with this document. 376 o There is no automatic revocation specified in this document. As 377 UNISIG Subset-137 Section 6.3.2.1.2 [UNISIG-Subset137] request an 378 automatic certificate revocation by the CA in case of TCP 379 disconnection during certificate distribution, this conflicts with 380 this document. 382 o As of RFC 4210 [RFC4210] the messageTime is required to be 383 Greenwich Mean Time coded as generalizedTime As UNISIG Subset-137 384 Table 5 [UNISIG-Subset137] explicitly states that the messageTime 385 in required to be 'UTC time', it is not clear if this means a 386 coding as UTCTime or generalizedTime and if other time zones than 387 Greenwich Mean Time shall be allowed. Therefore, UNISIG 388 Subset-137 [UNISIG-Subset137] may conflict with RFC 4210 389 [RFC4210]. Both time formats are described in RFC 5280 390 Section 4.1.2.5 [RFC5280]. 392 o This profile requires usage of the same type of protection for all 393 messages of one PKI management operation. This means, in case the 394 request message is MAC protected, also the response, certConf, and 395 pkiConf messages have a MAC-based protection. As UNISIG 396 Subset-137 Table 5 [UNISIG-Subset137] specifies for the first 397 certificate request MAC protection for all messages send by the 398 client and signature protection for all messages send by the 399 server, this conflicts with this document. 401 o The usage of caPubs is mainly allowed in combination with MAC 402 protected PKI management operations. UNISIG Subset-137 Table 12 403 [UNISIG-Subset137] requires to use caPubs. When changing to 404 signature protection of the response using a certificate issued 405 under the root CA that is to be transported in the caPubs field, 406 this is not a secure delivery of this root CA certificate. 408 1.5. Scope of this document 410 This document specifies requirements on generating PKI management 411 messages on the sender side. It does not specify strictness of 412 verification on the receiving side and how in detail to handle error 413 cases. 415 Especially on the EE side this profile aims at a lightweight 416 implementation. This means that the number of PKI management 417 operations implementations must support are reduced to a reasonable 418 minimum to support most typical certificate management use cases in 419 industrial machine-to-machine environments. On the side EE side only 420 limited resources are expected, as on the of the PKI management 421 entities the profile accepts higher resources needed. 423 For the sake of robustness and preservation of security properties 424 implementations should, as far as security is not affected, adhere to 425 Postel's law: "Be conservative in what you do, be liberal in what you 426 accept from others" (often reworded as: "Be conservative in what you 427 send, be liberal in what you accept"). 429 When in Section 3, Section 4, and Section 5 a field of the ASN.1 430 syntax as defined in RFC 4210 [RFC4210] and RFC 4211 [RFC4211] is not 431 explicitly specified, it SHOULD not be used by the sending entity. 432 The receiving entity MUST NOT require its absence and if present MUST 433 gracefully handle its presence. 435 1.6. Structure of this document 437 Section 2 introduces the general PKI architecture and approach to 438 certificate management using CMP that is assumed in this document. 439 Then it enlists the PKI management operations specified in this 440 document and describes them in general words. The list of supported 441 PKI management operations is divided into mandatory, recommended, and 442 optional ones. 444 Section 3 profiles the CMP message header, protection, and extraCerts 445 section as they are general elements of CMP messages. 447 Section 4 profiles the exchange of CMP messages between an EE and the 448 first PKI management entities. There are various flavors of 449 certificate enrollment requests optionally with polling, revocation, 450 error handling, and general support PKI management operations. 452 Section 5 profiles the exchange between PKI management entities. 453 These are in the first place the forwarding of messages coming from 454 or going to an EE. This includes also initiating delayed delivery of 455 messages, which involves polling. Additionally, it specifies PKI 456 management operations where a PKI management entity manages 457 certificates on behalf of an EE or for itself. 459 Section 6 outlines different mechanisms for CMP message transfer, 460 namely http-based transfer as already specified in [RFC6712], using 461 an additional TLS layer, or offline file-based transport. CoAP 462 [RFC7252] and piggybacking CMP messages on other protocols is out of 463 scope and left for further documents. 465 1.7. Convention and Terminology 467 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 468 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 469 document are to be interpreted as described in BCP 14 [RFC2119] 470 [RFC8174] when, and only when, they appear in all capitals, as shown 471 here. 473 Technical terminology is used in conformance with RFC 4210 [RFC4210], 474 RFC 4211 [RFC4211], RFC 5280 [RFC5280], and IEEE 802.1AR 475 [IEEE802.1AR]. The following key words are used: 477 CA: Certification authority, which issues certificates. 479 RA: Registration authority, an optional system component to which a 480 CA delegates certificate management functions such as 481 authorization checks. 483 LRA: Local registration authority, an optional RA system component 484 with proximity to the end entities. 486 KGA: Key generation authority, an optional system component, 487 typically co-located with an LRA, RA, or CA, that offers key 488 generation services to end entities. 490 EE: End entity, a user, device, or service that holds a PKI 491 certificate. An identifier for the EE is given as the subject 492 of its certificate. 494 The following terminology is reused from RFC 4210 [RFC4210] and used 495 as follows: 497 PKI management operation: All CMP messages belonging to one 498 transaction context. The transaction is 499 identified in the transactionID field of 500 the message header. 502 PKI management entity: All central PKI entities like LRA, RA and 503 CA. 505 PKI entity: EEs and PKI management entities 507 2. Architecture and use cases 509 2.1. Solution architecture 511 In order to facilitate secure automatic certificate enrollment if the 512 device hosting an EE is equipped with a manufacturer issued 513 certificate during production. Such a manufacturer issued 514 certificate is installed during production to identify the device 515 throughout its lifetime. This manufacturer certificate can be used 516 to protect the initial enrollment of operational certificates after 517 installation of the EE on site in its operational environment. An 518 operational certificate is issued by the owner or operator of the 519 device to identify the device during operation, e.g., within a 520 security protocol like IPSec, TLS, or SSH. In IEEE 802.1AR 521 [IEEE802.1AR] a manufacturer certificate is called IDevID certificate 522 and an operational certificate is called LDevID certificate. 524 All certificate management transactions specified in this document 525 are initiated by the EE. The EE creates a CMP request message, 526 protects it using some asymmetric or symmetric credential, as far as 527 available, and sends it to its locally reachable PKI component. This 528 PKI component may be an LRA, RA, or the CA, which checks the request, 529 responds to it itself, or forwards the request upstream to the next 530 PKI component. In case an (L)RA changes the CMP request message 531 header or body or wants to prove a successful verification or 532 authorization, it can apply a protection of its own. Especially the 533 communication between an LRA and RA can be performed synchronously or 534 asynchronously. Synchronous communication describes a timely 535 uninterrupted communication between two communication partners, while 536 asynchronous communication is not performed in a timely consistent 537 manner, e.g., because of a delayed message delivery. 539 +-----+ +-----+ +-----+ +-----+ 540 | | | | | | | | 541 | EE |<---------->| LRA |<-------------->| RA |<---------->| CA | 542 | | | | | | | | 543 +-----+ +-----+ +-----+ +-----+ 545 synchronous (a)synchronous (a)synchronous 546 +----connection----+------connection------+----connection----+ 548 on site at operators service partner 549 +----------plant---------+-----backend services-----+-trust center-+ 551 Figure 1: Certificate management on site 553 In operation environments a layered LRA-RA-CA architecture can be 554 deployed, e.g., with LRAs bundling requests from multiple EEs at 555 dedicated locations and one (or more than one) central RA aggregating 556 the requests from multiple LRAs. Every (L)RA in this scenario 557 typically has a shared key for password-based protection or a CMP 558 signer key and certificate containing an extended key usage as 559 specified in CMP Updates [I-D.ietf-lamps-cmp-updates] allowing it to 560 protect CMP messages it processes. The figure above shows an 561 architecture using one LRA and one RA. It is also possible to have 562 only an RA or multiple LRAs and/or RAs. Depending on the network 563 infrastructure, the communication between different PKI management 564 entities may be synchronous online communication, delayed 565 asynchronous communication, or even offline file transfer. 567 This profile focusses on specifying the pull model, where the EE 568 always requests a specific PKI management operation. 570 Note: CMP response messages, especially in case of central key 571 generation, as described in Section 4.1.6, could also be used 572 proactively to implement the push model towards the EE. 574 Third-party CAs typically implement different variants of CMP or even 575 use proprietary interfaces for certificate management. Therefore, 576 the LRA or the RA may need to adapt the exchanged CMP messages to the 577 flavor of communication required by the CA. 579 2.2. Basic generic CMP message content 581 Section 3 specifies the generic parts of the CMP messages as used 582 later in Section 4 and Section 5. 584 o Header of a CMP message; see Section 3.1. 586 o Protection of a CMP message; see Section 3.2. 588 o ExtraCerts field of a CMP message; see Section 3.3. 590 2.3. Supported PKI management operations 592 Following the outlined scope from Section 1.5, this section gives a 593 brief overview of the PKI management operations specified in 594 Section 4 and Section 5 and points out whether an implementation by 595 compliant EE or PKI management entities is mandatory, recommended or 596 optional. 598 2.3.1. Mandatory PKI management operations 600 The mandatory PKI management operations in this document shall limit 601 the overhead of certificate management. This minimal set of 602 operations may be helpful for keeping development effort low and for 603 use in memory-constrained devices. 605 +--------------------------------------------------------+----------+ 606 | PKI management operations | Section | 607 +--------------------------------------------------------+----------+ 608 | Request a certificate from a new PKI with signature | Section | 609 | protection | 4.1.1 | 610 +--------------------------------------------------------+----------+ 611 | Request to update an existing certificate with | Section | 612 | signature protection | 4.1.3 | 613 +--------------------------------------------------------+----------+ 614 | Error reporting | Section | 615 | | 4.3 | 616 +--------------------------------------------------------+----------+ 618 Table 1: Mandatory End Entity focused PKI management operations 620 +--------------------------------------------------------+----------+ 621 | PKI management operations | Section | 622 +--------------------------------------------------------+----------+ 623 | Forward messages without changes | Section | 624 | | 5.1.1 | 625 +--------------------------------------------------------+----------+ 626 | Forward messages with replaced protection and keeping | Section | 627 | the original proof-of-possession | 5.1.2.1 | 628 +--------------------------------------------------------+----------+ 629 | Forward messages with replaced protection and | Section | 630 | raVerified as proof-of-possession | 5.1.2.2 | 631 +--------------------------------------------------------+----------+ 632 | Error reporting | Section | 633 | | 5.3 | 634 +--------------------------------------------------------+----------+ 636 Table 2: Mandatory LRA and RA focused PKI management operations 638 2.3.2. Recommended PKI management operations 640 Additional recommended PKI management operations shall support some 641 more complex scenarios, that are considered beneficial for 642 environments with more specific boundary conditions. 644 +--------------------------------------------------------+----------+ 645 | PKI management operations | Section | 646 +--------------------------------------------------------+----------+ 647 | Request a certificate from a PKI with MAC protection | Section | 648 | | 4.1.4 | 649 +--------------------------------------------------------+----------+ 650 | Revoke an own certificate | Section | 651 | | 4.2 | 652 +--------------------------------------------------------+----------+ 654 Table 3: Recommended End Entity focused PKI management operations 656 +--------------------------------------------------------+----------+ 657 | PKI management operations | Section | 658 +--------------------------------------------------------+----------+ 659 | Revoke another's entities certificate | Section | 660 | | 5.2 | 661 +--------------------------------------------------------+----------+ 663 Table 4: Recommended LRA and RA focused PKI management operations 665 2.3.3. Optional PKI management operations 667 The optional PKI management operations support specific requirements 668 seen only in a subset of environments. 670 +---------------------------------------------------------+---------+ 671 | PKI management operations | Section | 672 +---------------------------------------------------------+---------+ 673 | Request a certificate from a trusted PKI with signature | Section | 674 | protection | 4.1.2 | 675 +---------------------------------------------------------+---------+ 676 | Request a certificate from a legacy PKI using a PKCS#10 | Section | 677 | [RFC2986] request | 4.1.5 | 678 +---------------------------------------------------------+---------+ 679 | Add central generation of a key pair to a certificate | Section | 680 | request. (If central key generation is supported, the | 4.1.6 | 681 | key agreement key management technique is REQUIRED to | | 682 | be supported, and the key transport and password-based | | 683 | key management techniques are OPTIONAL.) | | 684 +---------------------------------------------------------+---------+ 685 | Handle delayed enrollment due to asynchronous message | Section | 686 | delivery | 4.1.7 | 687 +---------------------------------------------------------+---------+ 688 | Additional support messages - distribution of CA | Section | 689 | certificates, update of a root CA certificate and | 4.4 | 690 | provisioning of certificate request template | | 691 +---------------------------------------------------------+---------+ 693 Table 5: Optional End Entity focused PKI management operations 695 +--------------------------------------------------------+----------+ 696 | PKI management operations | Section | 697 +--------------------------------------------------------+----------+ 698 | Forward messages with additional protection | Section | 699 | | 5.1.3 | 700 +--------------------------------------------------------+----------+ 701 | Initiate delayed enrollment due to asynchronous | Section | 702 | message delivery | 5.1.4 | 703 +--------------------------------------------------------+----------+ 705 Table 6: Optional LRA and RA focused PKI management operations 707 2.4. CMP message transport 709 On different links between PKI entities, e.g., EE<->RA and RA<->CA, 710 different transport MAY be used. As CMP has only very limited 711 requirement regarding the mechanisms used for message transport and 712 in different environments different transport mechanisms are 713 supported, e.g., HTTP, CoAP, or even offline files based, this 714 document requires no specific transport protocol to be supported by 715 all conforming implementations. 717 HTTP transfer is RECOMMENDED to use for all PKI entities, but there 718 is no transport specified as mandatory to be flexible for devices 719 with special constraints to choose whatever transport is suitable. 721 +--------------------------------------------------------+----------+ 722 | Transport | Section | 723 +--------------------------------------------------------+----------+ 724 | Transfer CMP messages using HTTP | Section | 725 | | 6.1 | 726 +--------------------------------------------------------+----------+ 728 Table 7: Recommended transport operations 730 +--------------------------------------------------------+----------+ 731 | Transport | Section | 732 +--------------------------------------------------------+----------+ 733 | Transfer CMP messages using HTTPS with certificate- | Section | 734 | based authentication | 6.2 | 735 +--------------------------------------------------------+----------+ 736 | Transfer CMP messages using HTTPS with shared-secret | Section | 737 | based protection | 6.3 | 738 +--------------------------------------------------------+----------+ 739 | Offline CMP message transport | Section | 740 | | 6.4 | 741 +--------------------------------------------------------+----------+ 742 | Transfer CMP messages using CoAP | Section | 743 | | 6.5 | 744 +--------------------------------------------------------+----------+ 746 Table 8: Optional transport operations 748 3. Generic parts of the PKI message 750 To reduce redundancy in the text and to ease implementation, the 751 contents of the header, protection, and extraCerts fields of the CMP 752 messages used in the transactions specified in Section 4 and 753 Section 5 are standardized to the maximum extent possible. 754 Therefore, the generic parts of a CMP message are described centrally 755 in this section. 757 As described in section 5.1 of [RFC4210], all CMP messages have the 758 following general structure: 760 +--------------------------------------------+ 761 | PKIMessage | 762 | +----------------------------------------+ | 763 | | header | | 764 | +----------------------------------------+ | 765 | +----------------------------------------+ | 766 | | body | | 767 | +----------------------------------------+ | 768 | +----------------------------------------+ | 769 | | protection (OPTIONAL) | | 770 | +----------------------------------------+ | 771 | +----------------------------------------+ | 772 | | extraCerts (OPTIONAL) | | 773 | +----------------------------------------+ | 774 +--------------------------------------------+ 776 Figure 2: CMP message structure 778 The general contents of the message header, protection, and 779 extraCerts fields are specified in the Section 3.1 to Section 3.3. 781 In case a specific CMP message needs different contents in the 782 header, protection, or extraCerts fields, the differences are 783 described in the respective message. 785 The CMP message body contains the message-specific information. It 786 is described in the context of Section 4 and Section 5. 788 The behavior in case an error occurs while handling a CMP message is 789 described in Section 5.3. 791 3.1. General description of the CMP message header 793 This section describes the generic header field of all CMP messages 794 with signature-based protection. The only variations described here 795 are in the fields recipient, transactionID, and recipNonce of the 796 first message of a PKI management operation. 798 In case a message has MAC-based protection the changes are described 799 in the respective section. The variations will affect the fields 800 sender, protectionAlg, and senderKID. 802 For requirements about proper random number generation please refer 803 to [RFC4086]. Any message-specific fields or variations are 804 described in the respective sections of this chapter. 806 header 807 pvno REQUIRED 808 -- MUST be set to 2 to indicate CMP V2 809 sender REQUIRED 810 -- MUST contain a name representing the originator of the message 811 -- SHOULD be the subject of the protection certificate, 812 -- the certificate for the private key used to sign the message 813 recipient REQUIRED 814 -- SHOULD be the name of the intended recipient and 815 -- MAY be a NULL-DN, i.e., has a zero-length SEQUENCE OF 816 -- RelativeDistinguishedNames, if the sender does not know the 817 -- DN of the recipient 818 -- If this is the first message of a transaction: SHOULD be the 819 -- subject of the issuing CA certificate 820 -- In all other messages: SHOULD be the same name as in the 821 -- sender field of the previous message in this transaction 822 messageTime RECOMMENDED 823 -- MUST be the time at which the message was produced, if 824 -- present 825 protectionAlg REQUIRED 826 -- MUST be the algorithm identifier of the signature algorithm or 827 -- id-PasswordBasedMac algorithm used for calculation of the 828 -- protection bits 829 -- The signature algorithm MUST be consistent with the 830 -- subjectPublicKeyInfo field of the signer's certificate 831 -- For more details on cryptographic algorithms to use, 832 -- see RFC-CMP-Alg 833 algorithm REQUIRED 834 -- MUST be the OID of the signature algorithm, like 835 -- sha256WithRSAEncryption or ecdsa-with-SHA256, or 836 -- id-PasswordBasedMac 837 senderKID RECOMMENDED 838 -- MUST be the SubjectKeyIdentifier, if available, of the 839 -- protection certificate 840 transactionID REQUIRED 841 -- If this is the first message of a transaction: 842 -- MUST be 128 bits of random data for the start of a 843 -- transaction to reduce the probability of having the 844 -- transactionID already in use at the server 845 -- In all other messages: 846 -- MUST be the value from the previous message in the same 847 -- transaction 848 senderNonce REQUIRED 849 -- MUST be cryptographically secure and fresh 128 random bits 850 recipNonce RECOMMENDED 851 -- If this is the first message of a transaction: SHOULD be 852 -- absent 853 -- In all other messages: MUST be present and contain the value 854 -- from senderNonce of the previous message in the same 855 -- transaction 856 generalInfo OPTIONAL 857 implicitConfirm OPTIONAL 858 -- The field is optional though it only applies to 859 -- ir/cr/kur/p10cr requests and ip/cp/kup response messages 860 -- Add to request messages to request omit sending certConf 861 -- message 862 -- See [RFC4210] Section 5.1.1.1. 863 -- Add to response messages to confirm omit sending certConf 864 -- message 865 ImplicitConfirmValue REQUIRED 866 -- ImplicitConfirmValue of the request message MUST be NULL if 867 -- the EE wants to request not to send a confirmation message 868 -- ImplicitConfirmValue MUST be set to NULL if the (L)RA/CA 869 -- wants to grant not sending a confirmation message 871 3.2. General description of the CMP message protection 873 This section describes the generic protection field of all CMP 874 messages with signature-based protection. The certificate for the 875 private key used to sign a CMP message is called 'protection 876 certificate'. 878 protection RECOMMENDED 879 -- MUST contain the signature calculated using the signature 880 -- algorithm specified in protectionAlg 882 Generally, CMP message protection is required for CMP messages, but 883 there are cases where protection of error messages as specified in 884 Section 4.3 and Section 5.3 is not possible and therefore MAY be 885 omitted. 887 For MAC-based protection as specified in Section 4.1.4 major 888 differences apply as described in the respective section. 890 The CMP message protection provides, if available, message origin 891 authentication and integrity protection for the CMP message header 892 and body. The CMP message extraCerts is not covered by this 893 protection. 895 NOTE: The extended key usages specified in CMP Updates 896 [I-D.ietf-lamps-cmp-updates] can be used for authorization of a 897 sending PKI management entity. 899 NOTE: The requirements for checking certificates given in [RFC5280] 900 MUST be followed for the CMP message protection. In case the CMP 901 signer certificate is not the CA certificate that signed the newly 902 issued certificate, certificate status checking SHOULD be used for 903 the CMP signer certificates of communication partners. 905 3.3. General description of CMP message extraCerts 907 This section describes the generic extraCerts field of all CMP 908 messages with signature-based protection. If extraCerts are 909 required, recommended, or optional is specified in the respective PKI 910 management operation. 912 extraCerts 913 -- SHOULD contain the protection certificate together with its 914 -- chain, if needed and the self-signed root certificate SHOULD 915 -- be omitted 916 -- If present, the first certificate in this field MUST 917 -- be the protection certificate and each following certificate 918 -- SHOULD directly certify the one immediately preceding it. 919 -- Self-signed certificates SHOULD be omitted from extraCerts 920 -- and MUST NOT be trusted based on the listing in extraCerts 921 -- in any case 923 Note: For maximum compatibility, all implementations SHOULD be 924 prepared to handle potentially additional and arbitrary orderings of 925 the certificates, except that the protection certificate is the first 926 certificate in extraCerts. 928 4. End Entity focused PKI management operations 930 This chapter focuses on the communication of the EE and the first PKI 931 management entities it talks to. Depending on the network and PKI 932 solution, this will either be the LRA, the RA or the CA. 934 The PKI management operations specified in this section cover the 935 following: 937 o Requesting a certificate from a PKI with variations like initial 938 requests and updating, central key generation and different 939 protection means 941 o Revocation of a certificate 943 o General messages for further support functions 945 These operations mainly specify the message body of the CMP messages 946 and utilize the specification of the message header, protection and 947 extraCerts as specified in Section 4. 949 The behavior in case an error occurs is described in Section 4.3. 951 This chapter is aligned to Appendix D and Appendix E of [RFC4210]. 952 The general rules for interpretation stated in Appendix D.1 in 953 [RFC4210] need to be applied here, too. 955 This document does not mandate any specific algorithms 956 implementations must or should support like [ETSI-TS133310] and 957 [UNISIG-Subset137] do. Using the message sequences described here 958 require agreement upon the algorithms to support. A set of 959 algorithms and the respective identifier to use with CMP is available 960 in CMP Algorithms [draft-ietf-lamps-cmp-algorithms]. 962 4.1. Requesting a new certificate from a PKI 964 There are different approaches to request a certificate from a PKI. 966 These approaches differ on the one hand in the way the EE can 967 authenticate itself to the PKI it wishes to get a new certificate 968 from and on the other hand in its capabilities to generate a proper 969 new key pair. The authentication means may be as follows: 971 o Using a certificate from a trusted PKI and the corresponding 972 private key, e.g., a manufacturer issued certificate 974 o Using the certificate to be updated and the corresponding private 975 key 977 o Using a shared secret known to the EE and the PKI 979 Typically, such EE requests a certificate from a CA. When the PKI 980 management entity responds with a message containing a certificate, 981 the EE MUST reply with a confirmation message. The PKI management 982 entity then MUST send confirmation back, closing the transaction. 984 The message sequences in this section allow the EE to request 985 certification of a locally generated public-private key pair. For 986 requirements about proper random number and key generation please 987 refer to [RFC4086]. The EE MUST provide a signature-based proof-of- 988 possession of the private key associated with the public key 989 contained in the certificate request as defined by [RFC4211] section 990 4.1 case 3. To this end it is assumed that the private key can 991 technically be used as signing key. The most commonly used 992 algorithms currentlyare RSA and ECDSA, which can technically be used 993 for signature calculation regardless of potentially intended 994 restrictions of the key usage. 996 The requesting EE provides the binding of the proof-of-possession to 997 its identity by signature-based or MAC-based protection of the CMP 998 request message containing that POPO. The PKI management entity 999 needs to verify whether this EE is authorized to obtain a certificate 1000 with the requested subject and other fields and extensions. 1001 Especially when removing the protection provided by the EE and 1002 applying a new protection, the PKI management entity MUST verify in 1003 particular the included proof-of-possession self-signature of the 1004 certTemplate using the public key of the requested certificate and 1005 MUST check that the EE, as authenticated by the message protection, 1006 is authorized to request a certificate with the subject as specified 1007 in the certTemplate (see Section 5.1.2). 1009 There are several ways to install the Root CA certificate of a new 1010 PKI on an EE. The installation can be performed in an out-of-band 1011 manner, using general messages, a voucher [RFC8366], or other formats 1012 for enrollment, or in-band of CMP by the caPubs field in the 1013 certificate response message. In case the installation of the new 1014 root CA certificate is performed using the caPubs field, the 1015 certificate response message MUST be properly authenticated, and the 1016 sender of this message MUST be authorized to install new root CA 1017 certificates on the EE. This authorization can be indicated by using 1018 pre-shared keys for the CMP message protection. 1020 4.1.1. Request a certificate from a new PKI with signature protection 1022 This PKI management operation should be used by an EE to request a 1023 certificate of a new PKI using an existing certificate from an 1024 external PKI, e.g., a manufacturer issued IDevID certificate 1025 [IEEE802.1AR], to prove its identity to the new PKI. The EE already 1026 has established trust in this new PKI it is about to enroll to, e.g., 1027 by voucher exchange or configuration means. The certificate request 1028 message is signature-protected using the existing certificate from 1029 the external PKI. 1031 Preconditions: 1033 1 The EE MUST have a certificate enrolled by an external PKI in 1034 advance to this PKI management operation to authenticate itself to 1035 the PKI management entity using signature-based protection, e.g., 1036 using a manufacturer issued certificate. 1038 2 The EE SHOULD know the subject name of the new CA it requests a 1039 certificate from; this name MAY be established using an enrollment 1040 voucher, the issuer field from a CertReqTemplate response message, 1041 or other configuration means. If the EE does not know the name of 1042 the CA, the PKI management entity MUST know where to route these 1043 requests to. 1045 3 The EE MUST authenticate responses from the PKI management entity; 1046 trust MAY be established using an enrollment voucher or other 1047 configuration means. 1049 4 The PKI management entity MUST trust the external PKI the EE uses 1050 to authenticate itself; trust MAY be established using some 1051 configuration means. 1053 The general message flow for this PKI management operation is like 1054 that given in [RFC4210] Appendix E.7. 1056 Message flow: 1058 Step# EE PKI management entity 1059 1 format ir 1060 2 -> ir -> 1061 3 handle, re-protect or 1062 forward ir 1063 4 format or receive ip 1064 5 possibly grant implicit 1065 confirm 1066 6 <- ip <- 1067 7 handle ip 1068 8 In case of status 1069 "rejection" in the 1070 ip message, no certConf 1071 and pkiConf are sent 1072 9 format certConf (optional) 1073 10 -> certConf -> 1074 11 handle, re-protect or 1075 forward certConf 1076 12 format or receive pkiConf 1077 13 <- pkiconf <- 1078 14 handle pkiConf (optional) 1080 For this PKI management operation, the EE MUST include exactly one 1081 single CertReqMsg in the ir. If more certificates are required, 1082 further requests MUST be sent using separate CMP messages. If the EE 1083 wants to omit sending a certificate confirmation message after 1084 receiving the ip to reduce the number of protocol messages exchanged 1085 in this PKI management operation, it MUST request this by including 1086 the implicitConfirm extension in the ir. 1088 If the CA accepts the certificate request it MUST return the new 1089 certificate in the certifiedKeyPair field of the ip message. If the 1090 EE requested to omit sending a certConf message after receiving the 1091 ip, the PKI management entity MAY confirm it by also including the 1092 implicitConfirm extension or MAY rejects it by omitting the 1093 implicitConfirm field in the ip. 1095 If the EE did not request implicit confirmation or the request was 1096 not granted by the PKI management entity the confirmation as follows 1097 MUST be performed. If the EE successfully receives the certificate 1098 and accepts it, the EE MUST send a certConf message, which MUST be 1099 answered by the PKI management entity with a pkiConf message. If the 1100 PKI management entity does not receive the expected certConf message 1101 in time it MUST handle this like a rejection by the EE. 1103 If the certificate request was rejected by the CA, the PKI management 1104 entity must return an ip message containing the status code 1105 "rejection" and no certifiedKeyPair field. Such an ip message MUST 1106 NOT be followed by the certConf and pkiConf messages and the 1107 transaction MUST be terminated. 1109 Detailed message description: 1111 Certification Request -- ir 1113 Field Value 1115 header 1116 -- As described in section 3.1 1118 body 1119 -- The request of the EE for a new certificate 1120 ir REQUIRED 1121 -- MUST be exactly one CertReqMsg 1122 -- If more certificates are required, further requests MUST be 1123 -- packaged in separate PKI Messages 1124 certReq REQUIRED 1125 certReqId REQUIRED 1126 -- MUST be set to 0 1127 certTemplate REQUIRED 1128 version OPTIONAL 1129 -- MUST be 2 if supplied. 1130 subject REQUIRED 1131 -- The EE subject name MUST be carried in the subject field 1132 -- and/or the subjectAltName extension. 1133 -- If subject name is present only in the subjectAltName 1134 -- extension, then the subject field MUST be a NULL-DN 1135 publicKey REQUIRED 1136 algorithm REQUIRED 1137 -- MUST include the subject public key algorithm ID and value 1138 -- In case a central key generation is requested, this field 1139 -- contains the algorithm and parameter preferences of the 1140 -- requesting entity regarding the to-be-generated key pair 1141 subjectPublicKey REQUIRED 1142 -- MUST contain the public key to be included into the requested 1143 -- certificate in case of local key-generation 1144 -- MUST contain a zero-length BIT STRING in case a central key 1145 -- generation is requested 1146 extensions OPTIONAL 1147 -- MAY include end-entity-specific X.509 extensions of the 1148 -- requested certificate like subject alternative name, 1149 -- key usage, and extended key usage 1150 -- The subjectAltName extension MUST be present if the EE 1151 -- subject name includes a subject alternative name. 1152 Popo REQUIRED 1153 POPOSigningKey OPTIONAL 1154 -- MUST be used in case subjectPublicKey contains a public key 1155 -- MUST be absent in case subjectPublicKey contains a 1156 -- zero-length BIT STRING 1157 poposkInput PROHIBITED 1158 -- MUST NOT be used because subject and publicKey are both 1159 -- present in the certTemplate 1160 algorithmIdentifier REQUIRED 1161 -- The signature algorithm MUST be consistent with the 1162 -- publicKey field of the certTemplate 1163 signature REQUIRED 1164 -- MUST be the signature computed over the DER-encoded 1165 -- certTemplate 1167 protection REQUIRED 1168 -- As described in section 3.2 1170 extraCerts REQUIRED 1171 -- As described in section 3.3 1173 Certification Response -- ip 1175 Field Value 1177 header 1178 -- As described in section 3.1 1180 body 1181 -- The response of the CA to the request as appropriate 1182 ip REQUIRED 1183 caPubs OPTIONAL 1184 -- MAY be used 1185 -- If used it MUST contain only the root certificate of the 1186 -- certificate contained in certOrEncCert 1187 response REQUIRED 1188 -- MUST be exactly one CertResponse 1189 certReqId REQUIRED 1190 -- MUST be set to 0 1191 status REQUIRED 1192 -- PKIStatusInfo structure MUST be present 1193 status REQUIRED 1194 -- positive values allowed: "accepted", "grantedWithMods" 1195 -- negative values allowed: "rejection" 1196 statusString OPTIONAL 1197 -- MAY be any human-readable text for debugging, logging or to 1198 -- display in a GUI 1199 failInfo OPTIONAL 1200 -- MUST be present if status is "rejection" 1201 -- MUST be absent if the status is "accepted" or 1202 -- "grantedWithMods" 1203 certifiedKeyPair OPTIONAL 1204 -- MUST be present if status is "accepted" or "grantedWithMods" 1205 -- MUST be absent if status is "rejection" 1206 certOrEncCert REQUIRED 1207 -- MUST be present when certifiedKeyPair is present 1208 certificate REQUIRED 1209 -- MUST be present when certifiedKeyPair is present 1210 -- MUST contain the newly enrolled X.509 certificate 1211 privateKey OPTIONAL 1212 -- MUST be absent in case of local key-generation 1213 -- MUST contain the encrypted private key in an EnvelopedData 1214 -- structure as specified in section 5.1.5 in case the private 1215 -- key was generated centrally 1217 protection REQUIRED 1218 -- As described in section 3.2 1220 extraCerts REQUIRED 1221 -- As described in section 3.3 1222 -- MUST contain the chain of the certificate present in 1223 -- certOrEncCert, the self-signed root certificate SHOULD be 1224 -- omitted 1225 -- Duplicate certificates MAY be omitted 1227 Certificate Confirmation -- certConf 1229 Field Value 1231 header 1232 -- As described in section 3.1 1234 body 1235 -- The message of the EE sends confirmation to the PKI 1236 -- management entity to accept or reject the issued certificates 1237 certConf REQUIRED 1238 -- MUST be exactly one CertStatus 1239 CertStatus REQUIRED 1240 certHash REQUIRED 1241 -- MUST be the hash of the certificate, using the same hash 1242 -- algorithm as used to create the certificate signature 1243 certReqId REQUIRED 1244 -- MUST be set to 0 1245 status RECOMMENDED 1246 -- PKIStatusInfo structure SHOULD be present 1247 -- Omission indicates acceptance of the indicated certificate 1248 status REQUIRED 1249 -- positive values allowed: "accepted" 1250 -- negative values allowed: "rejection" 1251 statusString OPTIONAL 1252 -- MAY be any human-readable text for debugging, logging, or to 1253 -- display in a GUI 1254 failInfo OPTIONAL 1255 -- MUST be present if status is "rejection" 1256 -- MUST be absent if the status is "accepted" 1258 protection REQUIRED 1259 -- As described in section 3.2 1260 -- MUST use the same certificate as for protection of the ir 1262 extraCerts RECOMMENDED 1263 -- SHOULD contain the protection certificate together with its 1264 -- chain, but MAY be omitted if the message size is critical and 1265 -- the PKI management entity did cash the extraCerts from the ir 1266 -- If present, the first certificate in this field MUST be the 1267 -- certificate used for signing this message 1268 -- Self-signed certificates SHOULD NOT be included in 1269 -- extraCerts and 1270 -- MUST NOT be trusted based on the listing in extraCerts in 1271 -- any case 1273 PKI Confirmation -- pkiconf 1275 Field Value 1277 header 1278 -- As described in section 3.1 1280 body 1281 pkiconf REQUIRED 1282 -- The content of this field MUST be NULL 1284 protection REQUIRED 1285 -- As described in section 3.2 1286 -- SHOULD use the same certificate as for protection of the ip 1288 extraCerts RECOMMENDED 1289 -- SHOULD contain the protection certificate together with its 1290 -- chain, but MAY be omitted if the message size is critical and 1291 -- the PKI management entity did cash the extraCerts from the ip 1292 -- If present, the first certificate in this field MUST be the 1293 -- certificate used for signing this message 1294 -- Self-signed certificates SHOULD NOT be included in extraCerts 1295 -- and 1296 -- MUST NOT be trusted based on the listing in extraCerts in 1297 -- any case 1299 4.1.2. Request a certificate from a trusted PKI with signature 1300 protection 1302 This PKI management operation should be used by an EE to request an 1303 additional certificate of the same PKI it already has certificates 1304 from. The EE uses one of these existing certificates to prove its 1305 identity. The certificate request message is signature-protected 1306 using this certificate. 1308 The general message flow for this PKI management operation is the 1309 same as given in Section 4.1.1. 1311 Preconditions: 1313 1 The EE MUST have a certificate enrolled by the PKI it requests 1314 another certificate from in advance to this PKI management 1315 operation to authenticate itself to the PKI management entity 1316 using signature-based protection. 1318 2 The EE SHOULD know the subject name of the CA it requests a 1319 certificate from; this name MAY be established using an enrollment 1320 voucher, the issuer field from a CertReqTemplate response message, 1321 or other configuration means. If the EE does not know the name of 1322 the CA, the PKI management entity MUST know where to route this 1323 request to. 1325 3 The EE MUST authenticate responses from the PKI management entity; 1326 trust MUST be established using an enrollment voucher or other 1327 configuration means. 1329 4 The PKI management entity MUST trust the current PKI; trust MAY be 1330 established using some configuration means. 1332 The message sequence for this PKI management operation is like that 1333 given in [RFC4210] Appendix D.5. 1335 The message sequence for this PKI management operation is identical 1336 to that given in Section 4.1.1, with the following changes: 1338 1 The body of the first request and response MUST be cr and cp, 1339 respectively. 1341 2 The caPubs field in the cp message SHOULD be absent. 1343 4.1.3. Update an existing certificate with signature protection 1345 This PKI management operation should be used by an EE to request an 1346 update of one of the certificates it already has and that is still 1347 valid. The EE uses the certificate it wishes to update to prove its 1348 identity. The certificate request message is signature-protected 1349 using this certificate. 1351 The general message flow for this PKI management operation is the 1352 same as given in Section 4.1.1. 1354 Preconditions: 1356 1 The certificate the EE wishes to update MUST NOT be expired or 1357 revoked. 1359 2 A new public-private key pair SHOULD be used. 1361 The message sequence for this PKI management operation is like that 1362 given in [RFC4210] Appendix D.6. 1364 The message sequence for this PKI management operation is identical 1365 to that given in Section 4.1.1, with the following changes: 1367 1 The body of the first request and response MUST be kur and kup, 1368 respectively. 1370 2 Protection of the kur MUST be performed using the certificate to 1371 be updated. 1373 3 The subject field and/or the subjectAltName extension of the 1374 CertTemplate MUST contain the EE subject name of the existing 1375 certificate to be updated, without modifications. 1377 4 The CertTemplate SHOULD contain the subject and publicKey of the 1378 EE only. 1380 5 The oldCertId control SHOULD be used to make clear which 1381 certificate is to be updated. 1383 6 The caPubs field in the kup message MUST be absent. 1385 As part of the certReq structure of the kur the control is added 1386 right after the certTemplate. 1388 controls 1389 type RECOMMENDED 1390 -- MUST be the value id-regCtrl-oldCertID, if present 1391 value 1392 issuer REQUIRED 1393 serialNumber REQUIRED 1394 -- MUST contain the issuer and serialNumber of the certificate 1395 -- to be updated 1397 4.1.4. Request a certificate from a PKI with MAC protection 1399 This PKI management operation should be used by an EE to request a 1400 certificate of a new PKI without having a certificate to prove its 1401 identity to the target PKI, but there is a shared secret established 1402 between the EE and the PKI. Therefore, the initialization request is 1403 MAC-protected using this shared secret. The PKI management entity 1404 checking the MAC-protection SHOULD replace this protection according 1405 to Section 5.1.2 in case the next hop does not know the shared 1406 secret. 1408 For requirements with regard to proper random number and key 1409 generation please refer to [RFC4086]. 1411 The general message flow for this PKI management operation is the 1412 same as given in Section 4.1.1. 1414 Preconditions: 1416 1 The EE and the PKI management entity MUST share a symmetric key, 1417 this MAY be established by a service technician during initial 1418 local configuration. 1420 2 The EE SHOULD know the subject name of the new CA it requests a 1421 certificate from; this name MAY be established using an enrollment 1422 voucher, the issuer field from a CertReqTemplate response message, 1423 or other configuration means. If the EE does not know the name of 1424 the CA, the PKI management entity MUST know where to route this 1425 request to. 1427 3 The EE MUST authenticate responses from the PKI management entity; 1428 trust MAY be established using the shared symmetric key. 1430 The message sequence for this PKI management operation is like that 1431 given in [RFC4210] Appendix D.4. 1433 The message sequence for this PKI management operation is identical 1434 to that given in Section 4.1.1, with the following changes: 1436 1 The protection of all messages MUST be calculated using Message 1437 Authentication Code (MAC); the protectionAlg field MUST be id- 1438 PasswordBasedMac as described in section 5.1.3.1 of [RFC4210]. 1440 2 The sender MUST contain a name representing the originator of the 1441 message. The senderKID MUST contain a reference all participating 1442 entities can use to identify the symmetric key used for the 1443 protection, e.g., the username of the EE. 1445 3 The extraCerts of the ir, certConf, and pkiConf messages MUST be 1446 absent. 1448 4 The extraCerts of the ip message MUST contain the chain of the 1449 issued certificate and root certificates SHOULD not be included 1450 and MUST NOT be directly trusted in any case. 1452 Part of the protectionAlg structure, where the algorithm identifier 1453 MUST be id-PasswordBasedMac, is a PBMParameter sequence. The fields 1454 of PBMParameter SHOULD remain constant for message protection 1455 throughout this PKI management operation to reduce the computational 1456 overhead. 1458 PBMParameter REQUIRED 1459 salt REQUIRED 1460 -- MUST be the random value to salt the secret key 1461 owf REQUIRED 1462 -- MUST be the algorithm identifier for the one-way function 1463 -- used 1464 -- For more details on cryptographic algorithms to use, see 1465 -- RFC-CMP-Alg and RFC-CRMF-Alg 1466 iterationCount REQUIRED 1467 -- MUST be a limited number of times the one-way function is 1468 -- applied 1469 -- To prevent brute force and dictionary attacks a reasonable 1470 -- high number SHOULD be used 1471 mac REQUIRED 1472 -- MUST be the algorithm identifier of the MAC algorithm used 1473 -- For more details on cryptographic algorithms to use, see 1474 -- RFC-CMP-Alg and RFC-CRMF-Alg 1476 4.1.5. Request a certificate from a legacy PKI using PKCS#10 request 1478 This PKI management operation should be used by an EE to request a 1479 certificate of a legacy PKI only capable to process PKCS#10 [RFC2986] 1480 certification requests. The EE can prove its identity to the target 1481 PKI by using various protection means as described in Section 4.1.1 1482 or Section 4.1.4. 1484 In contrast to the other PKI management operations described in 1485 Section 4.1, this transaction uses PKCS#10 [RFC2986] instead of CRMF 1486 [RFC4211] for the certificate request for compatibility reasons with 1487 legacy CA systems that require a PKCS#10 certificate request and 1488 cannot process CRMF [RFC4211] requests. In such case the PKI 1489 management entity MUST extract the PKCS#10 certificate request from 1490 the p10cr and provides it separately to the CA. 1492 The general message flow for this PKI management operation is the 1493 same as given in Section 4.1.1, but the public key is contained in 1494 the subjectPKInfo of the PKCS#10 certificate request. 1496 Preconditions: 1498 1 The EE MUST either have a certificate enrolled from this or any 1499 other accepted PKI, or a shared secret known to the PKI and the EE 1500 to authenticate itself to the RA. 1502 2 The EE SHOULD know the subject name of the CA it requests a 1503 certificate from; this name MAY be established using an enrollment 1504 voucher, the issuer field from a CertReqTemplate response message, 1505 or other configuration means. If the EE does not know the name of 1506 the CA, the RA MUST know where to route this request to. 1508 3 The EE MUST authenticate responses from the RA; trust MAY be 1509 established by an available root certificate, using an enrollment 1510 voucher, or other configuration means. 1512 4 The RA MUST trust the current or the PKI the EE uses to 1513 authenticate itself; trust MAY be established by a corresponding 1514 available root certificate or using some configuration means. 1516 The message sequence for this PKI management operation is identical 1517 to that given in Section 4.1.1, with the following changes: 1519 1 The body of the first request and response MUST be p10cr and cp, 1520 respectively. 1522 2 The certReqId in the cp message MUST be 0. 1524 3 The caPubs field in the cp message SHOULD be absent. 1526 Detailed description of the p10cr message: 1528 Certification Request -- p10cr 1530 Field Value 1532 header 1533 -- As described in section 3.1 1535 body 1536 -- The request of the EE for a new certificate using a PKCS#10 1537 -- certificate request 1538 p10cr REQUIRED 1539 certificationRequestInfo REQUIRED 1540 version REQUIRED 1541 -- MUST be set to 0 to indicate PKCS#10 V1.7 1542 subject REQUIRED 1543 -- The EE subject name MUST be carried in the subject field 1544 -- and/or the subjectAltName extension. 1545 -- If subject name is present only in the subjectAltName 1546 -- extension, then the subject field MUST be a NULL-DN 1547 subjectPKInfo REQUIRED 1548 algorithm REQUIRED 1549 -- MUST include the subject public key algorithm ID 1550 subjectPublicKey REQUIRED 1551 -- MUST include the subject public key algorithm value 1552 attributes OPTIONAL 1553 -- MAY include end-entity-specific X.509 extensions of the 1554 -- requested certificate like subject alternative name, 1555 -- key usage, and extended key usage. 1556 -- The subjectAltName extension MUST be present if the EE 1557 -- subject name includes a subject alternative name. 1558 signatureAlgorithm REQUIRED 1559 -- The signature algorithm MUST be consistent with the 1560 -- subjectPKInfo field. 1561 signature REQUIRED 1562 -- MUST containing the self-signature for proof-of-possession 1564 protection REQUIRED 1565 -- As described in section 3.2 1567 extraCerts REQUIRED 1568 -- As described in section 3.3 1570 4.1.6. Generate the key pair centrally at the PKI management entity 1572 This functional extension can be applied in combination with 1573 certificate enrollment as described in Section 4.1.1, Section 4.1.2, 1574 and Section 4.1.4. The functional extension can be used in case an 1575 EE is not able or is not willing to generate its new public-private 1576 key pair itself. It is a matter of the local implementation which 1577 PKI management entity will act as Key Generation Authority (KGA) and 1578 perform the key generation. This PKI management entity MUST have a 1579 certificate containing the additional extended key usage extension 1580 id-kp-cmKGA to be identified by the EE as a legitimate key-generation 1581 authority. In case the KGA generated the new key pair on behalf of 1582 the EE, it can use Section 4.1.1, Section 4.1.2, or Section 4.1.4 to 1583 request the certificate for this key pair as usual. 1585 Generally speaking, in a machine-to-machine scenario it is strongly 1586 preferable to generate public-private key pairs locally at the EE. 1587 Together with proof-of-possession of the private key in the 1588 certification request, this is to make sure that only the entity 1589 identified in the newly issued certificate is the only entity who 1590 ever holt the private key. 1592 There are some cases where an EE is not able or not willing to 1593 locally generate the new key pair. Reasons for this may be the 1594 following: 1596 o Lack of sufficient initial entropy. 1598 Note: Good random numbers are not only needed for key generation, but 1599 also for session keys and nonces in any security protocol. 1600 Therefore, a decent security architecture should anyways support good 1601 random number generation on the EE side or provide enough entropy for 1602 the RNG seed to guarantee good initial pseudo-random number 1603 generation. May be this is not the case at the time of requesting a 1604 certificate during manufacturing. 1606 o Due to lack of computational resources, e.g., in case of RSA keys. 1608 Note: As key generation could be performed in advance to the 1609 certificate enrollment communication, it is often not time critical. 1611 Note: As mentioned in Section 2.1 central key generation may be 1612 required in a push model, where the certificate response message is 1613 transferred by the PKI management entity to the EE without receiving 1614 a previous request message. 1616 If the EE wishes to request central key generation, it MUST fill the 1617 subjectPublicKey field in the certTemplate structure of the request 1618 message with a zero-length BIT STRING. This indicates to the PKI 1619 management entity that a new key pair shall be generated centrally on 1620 behalf of the EE. 1622 Note: As the protection of centrally generated keys in the response 1623 message is being extended from EncryptedValue to EncryptedKey by CMP 1624 Updates [I-D.ietf-lamps-cmp-updates], also the alternative 1625 EnvelopedData can be used. In CRMF Section 2.1.9 [RFC4211] the use 1626 of EncryptedValue has been deprecated in favor of the EnvelopedData 1627 structure. Therefore, this profile specifies using EnvelopedData as 1628 specified in CMS Section 6 [RFC5652]. 1630 +----------------------------------+ 1631 | EnvelopedData | 1632 | [RFC5652] section 6 | 1633 | +------------------------------+ | 1634 | | SignedData | | 1635 | | [RFC5652] section 5 | | 1636 | | +--------------------------+ | | 1637 | | | AsymmetricKeyPackage | | | 1638 | | | [RFC5958] | | | 1639 | | | +----------------------+ | | | 1640 | | | | privateKey | | | | 1641 | | | | OCTET STRING | | | | 1642 | | | +----------------------+ | | | 1643 | | +--------------------------+ | | 1644 | +------------------------------+ | 1645 +----------------------------------+ 1647 Figure 3: Encrypted private key container 1649 The PKI management entity delivers the private key in the privateKey 1650 field in the certifiedKeyPair structure of the response message also 1651 containing the newly issued certificate. 1653 The private key MUST be provided as an AsymmetricKeyPackage structure 1654 as defined in RFC 5958 [RFC5958]. 1656 This AsymmetricKeyPackage structure MUST be wrapped in a SignedData 1657 structure, as specified in CMS Section 5 [RFC5652], signed by the KGA 1658 generating the key pair. The signature MUST be performed using a CMP 1659 signer certificate asserting the extended key usage kp-id-cmKGA as 1660 described in CMP Updates [I-D.ietf-lamps-cmp-updates] to show the 1661 authorization to generate key pairs on behalf of an EE. 1663 Note: In case of using password-based key management technique as 1664 described in Section 4.1.6.3 it may not be possible or meaningful to 1665 the EE to validate the KGA signature in the SignedData structure as 1666 shares secrets are used for initial authentication. In this case the 1667 EE MAY omit this signature validation. 1669 This SignedData structure MUST be wrapped in an EnvelopedData 1670 structure, as specified in CMS Section 6 [RFC5652], encrypting it 1671 using a newly generated symmetric content-encryption key. 1673 Note: Instead of the specification in CMP Appendix D 4.4 [RFC4210] 1674 this content-encryption key is not generated on the EE side. As we 1675 just mentioned, central key generation should only be used in this 1676 profile in case of lack of randomness on the EE. 1678 As part of the EnvelopedData structure this content-encryption key 1679 MUST be securely provided to the EE using one of three key management 1680 techniques. The choice of the key management technique to be used by 1681 the PKI management entity depends on the authentication mechanism the 1682 EE choose to protect the request message, see CMP Updates section 3.4 1683 [I-D.ietf-lamps-cmp-updates] for more details on which key management 1684 technique to use. 1686 o Signature protected request message: 1688 * Using a certificate that contains a key usage extension 1689 asserting keyAgreement: The content-encryption key SHALL be 1690 protected using the key agreement key management technique, see 1691 Section 4.1.6.1, if the certificate used by the EE for signing 1692 the respective request message contains the key usage 1693 keyAgreement. If the certificate also contains the key usage 1694 keyEncipherment, the key transport key management technique 1695 SHALL NOT be used. 1697 * Using a certificate that contains a key usage extension 1698 asserting keyEncipherment: The content-encryption key SHALL be 1699 protected using the key transport key management technique, see 1700 Section 4.1.6.2, if the certificate used by the EE for signing 1701 the respective request message contains the key usage 1702 keyEncipherment and not keyAgreement. 1704 o MAC protected request message: The content-encryption key SHALL be 1705 protected using the password-based key management technique, see 1706 Section 4.1.6.3, only if the EE used MAC protection for the 1707 respected request message. 1709 The key agreement key management technique can be supported by most 1710 signature algorithms, as key transport key management technique can 1711 only be supported by a very limited number of algorithms. The 1712 password-based key management technique shall only be used in 1713 combination with MAC protection, which is a side-line in this 1714 document. Therefore, if central key generation is supported, the 1715 support of the key agreement key management technique is REQUIRED and 1716 the support of key transport and password-based key management 1717 techniques are OPTIONAL. 1719 For details on algorithms to be used, please see CMP Algorithms 1720 Section 4 and 5 [I-D.ietf-lamps-cmp-algorithms]. 1722 For encrypting the SignedData structure containing the private key a 1723 fresh content-encryption key MUST be generated with enough entropy 1724 with regard to the used symmetric key-encryption algorithm. 1726 Note: Depending on the lifetime of the certificate and the 1727 criticality of the generated private key, it is advisable to use the 1728 strongest available symmetric encryption algorithm. 1730 The detailed description of the privateKey field looks like this: 1732 privateKey OPTIONAL 1733 -- MUST be an EnvelopedData structure as specified in 1734 -- CMS [RFC5652] section 6 1735 version REQUIRED 1736 -- MUST be set to 2 1737 recipientInfos REQUIRED 1738 -- MUST be exactly one RecipientInfo 1739 recipientInfo REQUIRED 1740 -- MUST be either KeyAgreeRecipientInfo (see section 5.1.5.1), 1741 -- KeyTransRecipientInfo (see section 5.1.5.2), or 1742 -- PasswordRecipientInfo (see section 5.1.5.3) is used 1743 -- If central key generation is supported, support of 1744 -- KeyAgreeRecipientInfo is REQUIRED and support of 1745 -- KeyTransRecipientInfo and PasswordRecipientInfo are OPTIONAL 1746 encryptedContentInfo 1747 REQUIRED 1748 contentType REQUIRED 1749 -- MUST be id-signedData 1750 contentEncryptionAlgorithm 1751 REQUIRED 1752 -- MUST be the algorithm identifier of the symmetric 1753 -- content-encryption algorithm used 1754 encryptedContent REQUIRED 1755 -- MUST be the signedData structure as specified in 1756 -- CMS [RFC5652] section 5 in encrypted form 1757 version REQUIRED 1758 -- MUST be set to 3 1759 digestAlgorithms 1760 REQUIRED 1761 -- MUST be exactly one digestAlgorithm identifier 1762 digestAlgorithmIdentifier 1763 REQUIRED 1764 -- MUST be the OID of the digest algorithm used for generating 1765 -- the signature 1766 encapContentInfo 1767 REQUIRED 1768 -- MUST be the content that is to be signed 1769 contentType REQUIRED 1770 -- MUST be id-ct-KP-aKeyPackage as specified in [RFC5958] 1771 content REQUIRED 1772 AsymmetricKeyPackage 1773 REQUIRED 1774 OneAsymmetricKey 1775 REQUIRED 1776 -- MUST be exactly one asymmetric key package 1777 version REQUIRED 1778 -- The version MUST be v2 1779 privateKeyAlgorithm 1780 REQUIRED 1781 -- The privateKeyAlgorithm field MUST contain 1782 -- the OID of the asymmetric key pair algorithm 1783 privateKey 1784 REQUIRED 1785 -- The privateKey MUST be in the privateKey field 1786 Attributes 1787 OPTIONAL 1788 -- The attributes field SHOULD not be used 1789 publicKey 1790 REQUIRED 1791 -- The publicKey MUST be in the publicKey field 1792 certificates REQUIRED 1793 -- SHOULD contain the certificate, for the private key used 1794 -- to sign the content, together with its chain 1795 -- If present, the first certificate in this field MUST 1796 -- be the certificate used for signing this content 1797 -- Self-signed certificates SHOULD NOT be included 1798 -- and MUST NOT be trusted based on the listing in any case 1799 crls OPTIONAL 1800 -- MAY be present to provide status information on the signer or 1801 -- its CA certificates 1802 signerInfos REQUIRED 1803 -- MUST be exactly one signerInfo 1804 version REQUIRED 1805 -- MUST be set to 3 1806 sid REQUIRED 1807 subjectKeyIdentifier 1808 REQUIRED 1809 -- MUST be the subjectKeyIdentifier of the signer's certificate 1810 digestAlgorithm 1811 REQUIRED 1812 -- MUST be the same OID as in digest AlgorithmIdentifier 1813 signatureAlgorithm 1814 REQUIRED 1815 -- MUST be the algorithm identifier of the signature algorithm 1816 -- used for calculation of the signature bits, 1817 -- like sha256WithRSAEncryption or ecdsa-with-SHA256 1818 -- The signature algorithm MUST be consistent with the 1819 -- subjectPublicKeyInfo field of the signer's certificate 1820 signature REQUIRED 1821 -- MUST be the result of the digital signature generation 1823 4.1.6.1. Using key agreement key management technique 1825 This key management technique can be applied in combination with the 1826 PKI management operations specified in Section 4.1.1 to Section 4.1.3 1827 using signature-based protected CMP messages. The public key of the 1828 EE certificate used for the signature-based protection of the request 1829 message MUST also be used for the Ephemeral-Static Diffie-Hellmann 1830 key establishment of the content-encryption key. To use this key 1831 management technique the KeyAgreeRecipientInfo structure MUST be used 1832 in the contentInfo field. 1834 The KeyAgreeRecipientInfo structure included into the EnvelopedData 1835 structure is specified in CMS Section 6.2.2 [RFC5652]. 1837 The detailed description of the KeyAgreeRecipientInfo structure looks 1838 like this: 1840 recipientInfo REQUIRED 1841 -- MUST be KeyAgreeRecipientInfo as specified in 1842 version REQUIRED 1843 -- MUST be set to 3 1844 originator REQUIRED 1845 -- MUST contain the originatorKey sequence 1846 algorithm REQUIRED 1847 -- MUST be the algorithm identifier of the 1848 -- static-ephemeral Diffie-Hellmann algorithm 1849 publicKey REQUIRED 1850 -- MUST be the ephemeral public key of the sending party 1851 ukm OPTIONAL 1852 -- MUST be used when 1-pass ECMQV is used 1853 keyEncryptionAlgorithm 1854 REQUIRED 1855 -- MUST be the same as in the contentEncryptionAlgorithm field 1856 recipientEncryptedKeys 1857 REQUIRED 1858 -- MUST be exactly one RecipientEncryptedKey element 1859 recipientEncryptedKey 1860 REQUIRED 1861 rid REQUIRED 1862 rKeyId REQUIRED 1863 subjectKeyID 1864 REQUIRED 1865 -- MUST contain the same value as the senderKID in the 1866 -- respective request messages 1867 encryptedKey 1868 REQUIRED 1869 -- MUST be the encrypted content-encryption key 1871 4.1.6.2. Using key transport key management technique 1873 This key management technique can be applied in combination with the 1874 PKI management operations specified in Section 4.1.1 to Section 4.1.3 1875 using signature-based protected CMP messages. The public key of the 1876 EE certificate used for the signature-based protection of the request 1877 message MUST also be used for key encipherment of the content- 1878 encryption key. To use this key management technique the 1879 KeyTransRecipientInfo structure MUST be used in the contentInfo 1880 field. 1882 The KeyTransRecipientInfo structure included into the EnvelopedData 1883 structure is specified in CMS Section 6.2.1 [RFC5652]. 1885 The detailed description of the KeyTransRecipientInfo structure looks 1886 like this: 1888 recipientInfo REQUIRED 1889 -- MUST be KeyTransRecipientInfo as specified in 1890 -- CMS section 6.2.1 [RFC5652] 1891 version REQUIRED 1892 -- MUST be set to 2 1893 rid REQUIRED 1894 subjectKeyIdentifier 1895 REQUIRED 1896 -- MUST contain the same value as the senderKID in the respective 1897 -- request messages 1898 keyEncryptionAlgorithm 1899 REQUIRED 1900 -- MUST contain the key encryption algorithm identifier used for 1901 -- public key encryption 1902 encryptedKey REQUIRED 1903 -- MUST be the encrypted content-encryption key 1905 4.1.6.3. Using password-based key management technique 1907 This key management technique can be applied in combination with the 1908 PKI management operation specified in Section 4.1.4 using MAC 1909 protected CMP messages. The shared secret used for the MAC 1910 protection MUST also be used for the encryption of the content- 1911 encryption key but with a different key derivation algorithm. To use 1912 this key management technique the PasswordRecipientInfo structure 1913 MUST be used in the contentInfo field. 1915 The PasswordRecipientInfo structure included into the EnvelopedData 1916 structure is specified in CMS Section 6.2.4 [RFC5652]. 1918 The detailed description of the PasswordRecipientInfo structure looks 1919 like this: 1921 recipientInfo REQUIRED 1922 -- MUST be PasswordRecipientInfo as specified in 1923 -- CMS section 6.2.4 [RFC5652] 1924 version REQUIRED 1925 -- MUST be set to 0 1926 keyDerivationAlgorithm 1927 REQUIRED 1928 -- A key derivation algorithm as specified in RFC-CMP-Alg 1929 -- SHOULD be used 1931 4.1.7. Delayed enrollment 1933 This functional extension can be applied in combination with 1934 certificate enrollment as described in Section 4.1.1 to 1935 Section 4.1.5. The functional extension can be used in case a PKI 1936 management entity cannot respond to the certificate request in a 1937 timely manner, e.g., due to offline upstream communication or 1938 required registration officer interaction. Depending on the PKI 1939 architecture, it is not necessary that the PKI management entity 1940 directly communicating with the EE initiates the delayed enrollment. 1942 The PKI management entity initiating the delayed enrollment MUST 1943 include the status "waiting" in the response and this response MUST 1944 NOT contain a newly issued certificate. When receiving a response 1945 with status "waiting" the EE MUST send a poll request to the PKI 1946 management entity. The PKI management entity that initiated the 1947 delayed enrollment MUST answers with a poll response containing a 1948 checkAfter time. This value indicates the minimum number of seconds 1949 that must elapse before the EE sends another poll request. As soon 1950 as the PKI management entity can provide the final response message 1951 for the initial request of the EE, it MUST provide this in response 1952 to a poll request. After receiving this response, the EE can 1953 continue the original PKI management operation as described in the 1954 respective section of this document, e.g., send a certConf message. 1956 Typically, intermediate PKI management entities SHOULD NOT change the 1957 sender and recipient nonce even in case an intermediate PKI 1958 management entity modifies a request or a response message. In the 1959 special case of polling between EE and LRA with offline transport 1960 between an LRA and RA, see Section 5.1.4, an exception occurs. The 1961 EE and LRA exchange pollReq and pollRep messages handle the nonce 1962 words as described. When, after pollRep, the final response from the 1963 CA arrives at the LRA, the next response will contain the recipNonce 1964 set to the value of the senderNonce in the original request message 1965 (copied by the CA). The LRA needs to replace the recipNonce in this 1966 case with the senderNonce of the last pollReq because the EE will 1967 validate it in this way. 1969 < TBD: I would appreciate any feedback specifically addressing the 1970 nonce handling in case an offline LRA responding and not forwarding 1971 the pollReq messages. > 1972 Message flow: 1974 Step# EE PKI management entity 1975 1 format ir/cr/p10cr/kur 1976 As described in the 1977 respective section 1978 in this document 1979 2 ->ir/cr/p10cr/kur-> 1980 3 handle request as described 1981 in the respective section 1982 in this document 1983 4 in case no immediate final 1984 response is possible, 1985 receive or format ip, cp 1986 or kup message containing 1987 status "waiting" 1988 5 <- ip/cp/kup <- 1989 6 handle ip/cp/kup 1990 7 format pollReq 1991 8 -> pollReq -> 1992 9 handle, re-protect or 1993 forward pollReq 1994 10 in case the requested 1995 certificate or a 1996 corresponding response 1997 message is available, 1998 receive or format ip, cp, 1999 or kup containing the 2000 issued certificate, or 2001 format or receive pollRep 2002 with appropriate 2003 checkAfter value 2004 11 <- pollRep <- 2005 12 handle pollRep 2006 13 let checkAfter 2007 time elapse 2008 14 continue with line 7 2010 Detailed description of the first ip/cp/kup: 2012 Response with status 'waiting' -- ip/cp/kup 2014 Field Value 2016 header 2017 -- MUST contain a header as described for the first response 2018 -- message of the respective PKI management operation 2020 body 2021 -- The response of the PKI management entity to the request in 2022 -- case no immediate appropriate response can be sent 2023 ip/cp/kup REQUIRED 2024 response REQUIRED 2025 -- MUST be exactly one CertResponse 2026 certReqId REQUIRED 2027 -- MUST be set to 0 2028 status REQUIRED 2029 -- PKIStatusInfo structure MUST be present 2030 status REQUIRED 2031 -- MUST be set to "waiting" 2032 statusString OPTIONAL 2033 -- MAY be any human-readable text for debugging, logging or to 2034 -- display in a GUI 2035 failInfo PROHIBITED 2036 certifiedKeyPair PROHIBITED 2038 protection REQUIRED 2039 -- MUST contain protection as described for the first response 2040 -- message of the respective PKI management operation, but 2041 -- MUST use the protection key of the PKI management entity 2042 -- initiating the delayed enrollment and creating this response 2043 -- message 2045 extraCerts REQUIRED 2046 -- MUST contain certificates as described for the first response 2047 -- message of the respective PKI management operation. 2048 -- As no new certificate is issued yet, no respective certificate 2049 -- chain is included 2051 Polling Request -- pollReq 2053 Field Value 2055 header 2056 -- MUST contain a header as described for the certConf message 2057 -- of the respective PKI management operation 2059 body 2060 -- The message of the EE asks for the final response or for a 2061 -- time to check again 2062 pollReq REQUIRED 2063 certReqId REQUIRED 2064 -- MUST be exactly one value 2065 -- MUST be set to 0 2067 protection REQUIRED 2068 -- MUST contain protection as described for the certConf message 2069 -- of the respective PKI management operation 2071 extraCerts OPTIONAL 2072 -- If present, it MUST contain certificates as described for the 2073 -- certConf message of the respective PKI management operation 2075 Polling Response -- pollRep 2077 Field Value 2079 header 2080 -- MUST contain a header as described for the pkiConf message 2081 -- of the respective PKI management operation 2083 body 2084 -- The message indicated the time to after which the EE may 2085 -- send another pollReq messaged for this transaction 2086 pollRep REQUIRED 2087 -- MUST be exactly one set of the following values 2088 certReqId REQUIRED 2089 -- MUST be set to 0 2090 checkAfter REQUIRED 2091 -- time in seconds to elapse before a new pollReq may be sent by 2092 -- the EE 2094 protection REQUIRED 2095 -- MUST contain protection as described for the pkiConf message 2096 -- of the respective profile, but 2097 -- MUST use the protection key of the PKI management entity that 2098 -- initiated the delayed enrollment and is creating this response 2099 -- message 2101 extraCerts OPTIONAL 2102 -- If present, it MUST contain certificates as described for the 2103 -- pkiConf message of the respective PKI management operation. 2105 Final response -- ip/cp/kup 2107 Field Value 2109 header 2110 -- MUST contain a header as described for the first 2111 -- response message of the respective PKI management operation, 2112 -- but the recipNonce MUST be the senderNonce of the last 2113 -- pollReq message 2115 body 2116 -- The response of the PKI management entity to the initial 2117 -- request as described in the respective PKI management 2118 -- operation 2120 protection REQUIRED 2121 -- MUST contain protection as described for the first response 2122 -- message of the respective PKI management operation, but 2123 -- MUST use the protection key of the PKI management entity that 2124 -- initiated the delayed enrollment and forwarding the response 2125 -- message 2127 extraCerts REQUIRED 2128 -- MUST contain certificates as described for the first 2129 -- response message of the respective PKI management operation 2131 4.2. Revoking a certificate 2133 This PKI management operation should be used by an entity to request 2134 the revocation of a certificate. Here the revocation request is used 2135 by an EE to revoke one of its own certificates. A PKI management 2136 entity could also act as an EE to revoke one of its own certificates. 2138 The revocation request message MUST be signed using the certificate 2139 that is to be revoked to prove the authorization to revoke to the 2140 PKI. The revocation request message is signature-protected using 2141 this certificate. 2143 An EE requests the revocation of an own certificate at the CA that 2144 issued this certificate. The PKI management entity responds with a 2145 message that contains the status of the revocation from the CA. 2147 Preconditions: 2149 1 The certificate the EE wishes to revoke is not yet expired or 2150 revoked. 2152 Message flow: 2154 Step# EE PKI management entity 2155 1 format rr 2156 2 -> rr -> 2157 3 handle, re-protect or 2158 forward rr 2159 4 receive rp 2160 5 <- rp <- 2161 6 handle rp 2163 For this PKI management operation, the EE MUST include exactly one 2164 RevDetails structure in the rr message body. In case no error 2165 occurred the response to the rr MUST be a rp message. The PKI 2166 management entity MUST produce a rp containing a status field with a 2167 single set of values. 2169 Detailed message description: 2171 Revocation Request -- rr 2173 Field Value 2175 header 2176 -- As described in section 3.1 2178 body 2179 -- The request of the EE to revoke its certificate 2180 rr REQUIRED 2181 -- MUST contain exactly one element of type RevDetails 2182 -- If more revocations are desired, further requests MUST be 2183 -- packaged in separate PKI Messages 2184 certDetails REQUIRED 2185 -- MUST be present and is of type CertTemplate 2186 serialNumber REQUIRED 2187 -- MUST contain the certificate serialNumber attribute of the 2188 -- X.509 certificate to be revoked 2189 issuer REQUIRED 2190 -- MUST contain the issuer attribute of the X.509 certificate to 2191 -- be revoked 2192 crlEntryDetails REQUIRED 2193 -- MUST contain exactly one reasonCode of type CRLReason (see 2194 -- [RFC5280] section 5.3.1) 2195 -- If the reason for this revocation is not known or shall not be 2196 -- published the reasonCode MUST be 0 = unspecified 2198 protection REQUIRED 2199 -- As described in section 3.2 and the private key related to the 2200 -- certificate to be revoked 2202 extraCerts REQUIRED 2203 -- As described in section 3.3 2205 Revocation Response -- rp 2207 Field Value 2209 header 2210 -- As described in section 3.1 2212 body 2213 -- The responds of the PKI management entity to the request as 2214 -- appropriate 2215 rp REQUIRED 2216 status REQUIRED 2217 -- MUST contain exactly one element of type PKIStatusInfo 2218 status REQUIRED 2219 -- positive value allowed: "accepted" 2220 -- negative value allowed: "rejection" 2221 statusString OPTIONAL 2222 -- MAY be any human-readable text for debugging, logging or to 2223 -- display in a GUI 2224 failInfo OPTIONAL 2225 -- MAY be present if and only if status is "rejection" 2227 protection REQUIRED 2228 -- As described in section 3.2 2230 extraCerts REQUIRED 2231 -- As described in section 3.3 2233 4.3. Error reporting 2235 This functionality should be used by an EE to report any error 2236 conditions upstream to the PKI management entity. Error reporting by 2237 a PKI management entity downstream to the EE is described in 2238 Section 5.3. 2240 In case the error condition is related to specific details of an ip, 2241 cp, or kup response message and a confirmation is expected the error 2242 condition MUST be reported in the respective certConf message with 2243 negative contents. 2245 General error conditions, e.g., problems with the message header, 2246 protection, or extraCerts, and negative feedback on rp, pollRep, or 2247 pkiConf messages MAY be reported in the form of an error message. 2249 In both situations the EE reports error in the PKIStatusInfo 2250 structure of the respective message. 2252 Depending on the PKI architecture, the PKI management entity MUST 2253 forward the error message (upstream) to the next PKI management 2254 entity and MUST terminate this PKI management operation. 2256 The PKIStatusInfo structure is used to report errors. The 2257 PKIStatusInfo structure SHOULD consist of the following fields: 2259 o status: Here the PKIStatus value "rejection" is the only one 2260 allowed. 2262 o statusString: Here any human-readable valid value for logging or 2263 to display in a GUI SHOULD be added. 2265 o failInfo: Here the PKIFailureInfo values MAY be used in the 2266 following way. For explanation of the reason behind a specific 2267 value, please refer to [RFC4210] Appendix F. 2269 * transactionIdInUse: This is sent by a PKI management entity in 2270 case the received request contains a transaction ID that is 2271 already in use for another transaction. An EE receiving such 2272 error message SHOULD resend the request in a new transaction 2273 using a different transaction ID. 2275 * systemUnavail or systemFailure: This is sent by a PKI 2276 management entity in case a back-end system is not available or 2277 currently not functioning correctly. An EE receiving such 2278 error message SHOULD resend the request in a new transaction 2279 after some time. 2281 Detailed error message description: 2283 Error Message -- error 2285 Field Value 2287 header 2288 -- As described in section 3.1 2290 body 2291 -- The message sent by the EE or the (L)RA/CA to indicate an 2292 -- error that occurred 2293 error REQUIRED 2294 pKIStatusInfo REQUIRED 2295 status REQUIRED 2296 -- MUST have the value "rejection" 2297 statusString RECOMMENDED 2298 -- SHOULD be any human-readable text for debugging, logging 2299 -- or to display in a GUI 2300 failInfo OPTIONAL 2301 -- MAY be present 2303 protection REQUIRED 2304 -- As described in section 3.2 2306 extraCerts OPTIONAL 2307 -- As described in section 3.3 2309 4.4. Support messages 2311 The following support messages offer on demand in-band transport of 2312 content that may be provided by the PKI management entity and 2313 relevant to the EE. The general messages and general response are 2314 used for this purpose. Depending on the environment, these requests 2315 may be answered by the LRA, RA, or CA. 2317 The general message and general response transport InfoTypeAndValue 2318 structures. In addition to those infoType values defined in CMP 2319 [RFC4210] further OIDs MAY be defined to define new PKI management 2320 operations, or general-purpose support messages as needed in a 2321 specific environment. 2323 Content specified in this document is describs the following: 2325 o Request of CA certificates 2327 o Update of Root CA certificates 2328 o Parameters needed for a planned certificate request message 2330 The PKI management operation is similar to that given in CMP 2331 Appendix E.5 [RFC4210]. In this section the general message (genm) 2332 and general response (genp) are described. The specific 2333 InfoTypeAndValue structures are described in the following sections. 2335 The behavior in case an error occurs is described in Section 4.3. 2337 Message flow: 2339 Step# EE PKI management entity 2340 1 format genm 2341 2 -> genm -> 2342 3 handle, re-protect or 2343 forward genm 2344 4 format or receive genp 2345 5 <- genp <- 2346 6 handle genp 2348 Detailed message description: 2350 General Message -- genm 2352 Field Value 2354 header 2355 -- As described in section 3.1 2357 body 2358 -- The request of the EE to receive information 2359 genm REQUIRED 2360 -- MUST contain exactly one element of type 2361 -- InfoTypeAndValue 2362 infoType REQUIRED 2363 -- MUST be the OID identifying the specific PKI 2364 -- management operation described below 2365 infoValue OPTIONAL 2366 -- MUST be as described in the specific PKI 2367 -- management operation described below 2369 protection REQUIRED 2370 -- As described in section 3.2 2372 extraCerts REQUIRED 2373 -- As described in section 3.3 2375 General Response -- genp 2377 Field Value 2379 header 2380 -- As described in section 3.1 2382 body 2383 -- The response of the PKI management entity to the 2384 -- information request 2385 genp REQUIRED 2386 -- MUST contain exactly one element of type 2387 -- InfoTypeAndValue 2388 infoType REQUIRED 2389 -- MUST be the OID identifying the specific PKI 2390 -- management operation described below 2391 infoValue OPTIONAL 2392 -- MUST be as described in the specific PKI 2393 -- management operation described below 2395 protection REQUIRED 2396 -- As described in section 3.2 2398 extraCerts REQUIRED 2399 -- As described in section 3.3 2401 < TBD: May be we should not restrict the number of ITAV elements in 2402 the response message to one. > 2404 4.4.1. Get CA certificates 2406 This PKI management operation can be used by an EE to request CA 2407 certificates from the PKI management entity. 2409 An EE requests CA certificates from the PKI management entity by 2410 sending a general message with OID id-it-caCerts as specified in CMP 2411 Updates [I-D.ietf-lamps-cmp-updates]. The PKI management entity 2412 responds with a general response with the same OID that either 2413 contains a SEQUENCE of certificates populated with the available CA 2414 intermediate and issuing CA certificates or with no content in case 2415 no CA certificate is available. 2417 The message sequence for this PKI management operation is as given in 2418 Section 4.4, with the following specific content: 2420 1 the body MUST contain as infoType the OID id-it-caCerts 2422 2 the infoValue of the request MUST be absent 2423 3 if present, the infoValue of the response MUST be caCerts field 2425 The infoValue field of the general response containing the id-it- 2426 caCerts OID looks like this: 2428 infoValue OPTIONAL 2429 -- MUST be absent if no CA certificate is available 2430 -- MUST be present if CA certificates are available 2431 -- MUST be a sequence of CMPCertificate 2433 4.4.2. Get root CA certificate update 2435 This PKI management operation can be used by an EE to request an 2436 update of an existing root CA Certificate by the EE. 2438 An EE requests a root CA certificate update from the PKI management 2439 entity by sending a general message with OID id-it-rootCaKeyUpdate as 2440 specified in CMP Updates [I-D.ietf-lamps-cmp-updates]. The PKI 2441 management entity responds with a general response with the same OID 2442 that either contains the update of the root CA certificate consisting 2443 of up to three certificates, or with no content in case no update is 2444 available. 2446 The newWithNew certificate is the new root CA certificates and is 2447 REQUIRED to be present in the response message. The newWithOld 2448 certificate is RECOMMENDED to be present in the response message 2449 though it is needed for those cases where the receiving entity trusts 2450 the old root CA certificate and wishes to gain trust in the new root 2451 CA certificate. The oldWithNew certificate is OPTIONAL though it is 2452 only needed in a scenario where the requesting entity already trusts 2453 the new root CA certificate and wants to gain trust in the old root 2454 certificate. 2456 The message sequence for this PKI management operation is as given in 2457 Section 4.4, with the following specific content: 2459 1 the body MUST contain as infoType the OID id-it-rootCaKeyUpdate 2461 2 the infoValue of the request MUST be absent 2463 3 if present, the infoValue of the response MUST be a 2464 RootCaKeyUpdate structure 2466 The infoValue field of the general response containing the id-it- 2467 rootCaKeyUpdate extension looks like this: 2469 infoValue OPTIONAL 2470 -- MUST be absent if no update of the root CA certificate is 2471 -- available 2472 -- MUST be present if an update of the root CA certificate 2473 -- is available and MUST be of type RootCaKeyUpdate 2474 newWithNew REQUIRED 2475 -- MUST be present if infoValue is present 2476 -- MUST contain the new root CA certificate 2477 newWithOld RECOMMENDED 2478 -- SHOULD be present if infoValue is present 2479 -- MUST contain an X.509 certificate containing the new public 2480 -- root CA key signed with the old private root CA key 2481 oldWithNew OPTIONAL 2482 -- MAY be present if infoValue is present 2483 -- MUST contain an X.509 certificate containing the old public 2484 -- root CA key signed with the new private root CA key 2486 < TBD: In case the PKI management entity serves for different Root 2487 CAs. There are three different options to handle this: - The EE 2488 specifies by means of a respective lable in the http endpoint for 2489 which Root CA certificate the update is requested. - The EE transfers 2490 the oldWithOld certificate in the InfoValue of the request. - The PKI 2491 management entity provides RootCaKeyUpdate element all Root CAs an 2492 update is available. > 2494 4.4.3. Get certificate request template 2496 This PKI management operation can be used by an EE to request a 2497 template with parameters for a future certificate request operation. 2499 An EE requests certificate request parameter from the PKI management 2500 entity by sending a general message with OID id-it-certReqTemplate as 2501 specified in CMP Updates [I-D.ietf-lamps-cmp-updates]. The PKI 2502 management entity responds with a general response with the same OID 2503 that either contains a certificate template containing requirements 2504 on certificate fields and extensions and optionally a sequence of 2505 control fields containing requirements on algorithm identifier or RSA 2506 key lengths for key pair generation, or with no content in case no 2507 specific requirements are made by the PKI. 2509 The EE SHOULD follow the requirements from the received CertTemplate 2510 and the optional control fields, by filling in all the fields 2511 requested and taking over all the field values provided. The EE 2512 SHOULD NOT add further CertTemplate fields, Name components, and 2513 extensions or their (sub-)components. 2515 Note: We deliberately do not use 'MUST' or 'MUST NOT' here in order 2516 to allow more flexibility in case the rules given here are not 2517 sufficient for specific scenarios. The EE can populate the 2518 certificate request as wanted and ignore any of the requirements 2519 contained in the CertReqTemplate response message. On the other 2520 hand, a PKI management entity is free to ignore or replace the 2521 content of the certificate request provided by the EE. The 2522 CertReqTemplate PKI management operation offers means to ease a joint 2523 understanding which fields should be used. 2525 In case a field of type Name, e.g., issuer or subject, is present in 2526 the CertTemplate but has the value NULL-DN (i.e., has an empty list 2527 of RDN components) the field SHOULD be included with content provided 2528 by the EE. Similarly, in case an X.509v3 extension is present but 2529 its extnValue is empty this means that the extension SHOULD be 2530 included with content provided by the EE. In case a Name component, 2531 for instance a common name or serial number, is given but has an 2532 empty string value the EE SHOULD fill in a value. Similarly, in case 2533 an extension has sub-components (e.g., an IP address in a 2534 SubjectAltName field) with empty value, the EE SHOULD fill in a 2535 value. 2537 The EE MUST ignore (i.e., not include and fill in) empty fields, 2538 extensions, and sub-components that it does not understand or does 2539 not know suitable values to be filled in. 2541 The publicKey field of type SubjectPublicKeyInfo in the CertTemplate 2542 MUST NOT be used and MUST contain no algorithm ID in the algorithm 2543 field and a zero-length BIT STRING in the subjectPublicKey field. In 2544 case the PKI management entity wishes to make stipulation on 2545 supported algorithms the EE may use for key generation, this MUST be 2546 specified using the control fields. 2548 The control with the OID id-regCtrl-algId, as specified in CMP 2549 Updates [I-D.ietf-lamps-cmp-updates], specifies algorithms other that 2550 RSA. The algorithm field in SubjectPublicKeyInfo specifies the type 2551 of the public key to request a certificate for. The algorithm field 2552 contains the key type OID of the public key. For EC keys the full 2553 curve information MUST be specified as described in the respective 2554 standard documents. The algorithm field MUST be followed by a zero- 2555 length BIT STRING for the subjectPublicKey. 2557 The control with the OID id-regCtrl-rsaKeyLen, as specified in CMP 2558 Updates [I-D.ietf-lamps-cmp-updates], specifies RSA keys of the 2559 specified key length. In case several control fields are present the 2560 EE is free to choose one of the specified algorithms for key pair 2561 generation. In case no control field is not present the EE is free 2562 to choose the public key type and parameters. 2564 In the certTemplate structure the serialNumber, signingAlg, 2565 publicKey, issuerUID, and subjectUID fields MUST be omitted. 2567 The message sequence for this PKI management operation is as given in 2568 Section 4.4, with the following specific content: 2570 1 the body MUST contain as infoType the OID id-it-certReqTemplate 2572 2 the infoValue of the request MUST be absent 2574 3 if present, the infoValue of the response MUST be a certTemplate 2575 structure and an optional SEQUENCE of AttributeTypeAndValue of 2576 type id-regCtrl-algId or id-regCtrl-rsaKeyLen 2578 The infoValue field of the general response containing the id-it- 2579 certReqTemplate OID looks like this: 2581 InfoValue OPTIONAL 2582 -- MUST be absent if no requirements are available 2583 -- MUST be present if the PKI management entity has any 2584 -- requirements on the content of the certificates template 2585 certTemplate REQUIRED 2586 -- MUST be present if infoValue is present 2587 -- MUST contain the prefilled certTemplate structure elements 2588 -- The SubjectPublicKeyInfo MUST contain no algorithm ID in the 2589 -- algorithm field and a zero-length BIT STRING in the 2590 -- subjectPublicKey field 2591 controls OPTIONAL 2592 -- MUST be absent if no requirements on algorithms are available 2593 -- MUST be present if the PKI management entity has any 2594 -- requirements on the algorithms to be used for key generation 2595 -- MUST contain one AttributeTypeAndValue per supported algorithm 2596 -- with attribute id-regCtrl-algId or id-regCtrl-rsaKeyLen 2598 5. LRA and RA focused PKI management operations 2600 This chapter focuses on the communication among different PKI 2601 management entities. Depending on the network and PKI solution 2602 design, these will either be an LRA, RA or CA. 2604 Typically, a PKI management entity forwards messages from downstream, 2605 but it may also reply to them itself. Besides forwarding of received 2606 messages a PKI management entity could also need to revoke 2607 certificates of EEs, report errors, or may need to manage its own 2608 certificates. 2610 5.1. Forwarding of messages 2612 Each CMP request message (i.e., ir, cr, p10cr, kur, pollReq, or 2613 certConf) or error message coming from an EE or the previous 2614 (downstream) PKI management entity MUST be sent to the next 2615 (upstream) PKI management entity. This PKI management entity MUST 2616 forward response messages to the next (downstream) PKI management 2617 entity or EE. 2619 The PKI management entity SHOULD verify the protection, the syntax, 2620 the required message fields, the message type, and if applicable the 2621 authorization and the proof-of-possession of the message. Additional 2622 checks or actions MAY be applied depending on the PKI solution 2623 requirements and concept. If one of these verification procedures 2624 fails, the (L)RA SHOULD respond with a negative response message and 2625 SHOULD not forward the message further upstream. General error 2626 conditions should be handled as described in Section 4.3 and 2627 Section 5.3. 2629 A PKI management entity SHOULD not change the received message if not 2630 necessary. The PKI management entity SHOULD only update the message 2631 protection if it is technically necessary. Concrete PKI system 2632 specifications may define in more detail if and when to do so. 2634 This is particularly relevant in the upstream communication of a 2635 request message. 2637 Each hop in a chain of PKI management entity has one or more 2638 functionalities, e.g., a PKI management entity 2640 o may need to verify the identities of EEs or base authorization 2641 decisions for certification request processing on specific 2642 knowledge of the local setup, e.g., by consulting an inventory or 2643 asset management system, 2645 o may need to add fields to certificate request messages, 2647 o may need to store data from a message in a database for later 2648 usage or documentation purposes, 2650 o may provide traversal of a network boundary, 2652 o may need to double-check if the messages transferred back and 2653 forth are properly protected and well formed, 2655 o may provide a proof that it has performed all required checks, 2656 o may initiate a delayed enrollment due to offline upstream 2657 communication or registration officer interaction, 2659 o may grant the request of an EE to omit sending a confirmation 2660 message, or 2662 o can collect messages from different LRAs and forward them to the 2663 CA. 2665 Therefore, the decision if a message should be forwarded 2667 o unchanged with the original protection, 2669 o unchanged with a new protection, or 2671 o changed with a new protection 2673 depends on the PKI solution design and the associated security policy 2674 (CP/CPS [RFC3647]). 2676 This section specifies the different options a PKI management entity 2677 may implement and use. 2679 A PKI management entity MAY update the protection of a message 2681 o if it performs changes to the header or the body of the message, 2683 o if it needs to prove checks or validations performed on the 2684 message to one of the next (upstream) PKI components, 2686 o if it needs to protect the message using a key and certificate 2687 from a different PKI, or 2689 o if it needs to replace or produce a MAC based-protection. 2691 This is particularly relevant in the upstream communication of 2692 certificate request messages. 2694 The message protection covers only the header and the body and not 2695 the extraCerts. The PKI management entity MAY change the extraCerts 2696 in any of the following message adaptations, e.g., to sort or add 2697 needed or to delete needless certificates to support the next hop. 2698 This may be particularly helpful to extend upstream messages with 2699 additional certificates or to reduce the number of certificates in 2700 downstream messages when forwarding to constrained devices. 2702 5.1.1. Not changing protection 2704 This alternative to forward a message can be used by any PKI 2705 management entity to forward an original CMP message without changing 2706 the header, body or protection. In any of these cases the PKI 2707 management entity acts more like a proxy, e.g., on a network 2708 boundary, implementing no specific RA-like security functionality to 2709 the PKI. 2711 This alternative to forward a message MUST be used for forwarding kur 2712 messages that must not be approved by the respective PKI management 2713 entity. 2715 5.1.2. Replacing protection 2717 The following two alternatives to forward a message can be used by 2718 any PKI management entity to forward a CMP message with or without 2719 changes, but providing its own protection using its CMP signer key to 2720 assert approval of this message. In this case the PKI management 2721 entity acts as an actual Registration Authority (RA), which 2722 implements important security functionality of the PKI. 2724 Before replacing the existing protection by a new protection, the PKI 2725 management entity MUST verify the protection provided by the EE or by 2726 the previous PKI management entity and approve its content including 2727 any own modifications. For certificate requests the PKI management 2728 entity MUST verify (except in case of central key generation) the 2729 presence and contents of the proof-of-possession self-signature of 2730 the certTemplate using the public key of the requested certificate 2731 and MUST check that the EE, as authenticated by the message 2732 protection, is authorized to request a certificate with the subject 2733 as specified in the certTemplate. 2735 In case the received message has been protected by a CA or another 2736 PKI management entity, the current PKI management entity MUST verify 2737 its protection and approve its content including any own 2738 modifications. For request messages the PKI management entity MUST 2739 check that the other PKI management entity, as authenticated by the 2740 protection of the incoming message, was authorized to issue or 2741 forward the request. 2743 These message adaptations MUST NOT be applied to kur request messages 2744 as described in Section 4.1.3 since their original protection using 2745 the key and certificate to be updated needs to be preserved, unless 2746 the regCtrl OldCertId is used to clearly identify the certificate to 2747 be updated. 2749 These message adaptations MUST NOT be applied to certificate request 2750 messages as described in Section 4.1.6requesting key generation by a 2751 Key Generation Authority since their original protection using the 2752 key and certificate for signature protection or the shared secret for 2753 MAC-protection needs to be preserved up to the Key Generation 2754 Authority. 2756 In both cases, kur and central key generation, an additional 2757 signature of a PKI management entity to the original certificate 2758 request message MUST be provided using nested messages as specified 2759 in Section 5.1.3. 2761 5.1.2.1. Keeping proof-of-possession 2763 This alternative to forward a message can be used by any PKI 2764 management entity to forward a CMP message with or without modifying 2765 the message header or body while preserving any included proof-of- 2766 possession. 2768 By replacing the existing protection using its own CMP signer key the 2769 PKI management entity provides a proof of verifying and approving of 2770 the message as described above. 2772 In case the PKI management entity modifies the certTemplate of an ir 2773 or cr message, the message adaptation in Section 5.1.2.2 needs to be 2774 applied instead. 2776 5.1.2.2. Breaking proof-of-possession 2778 This alternative to forward a message can be used by any PKI 2779 management entity to forward an ir or cr message with modifications 2780 of the certTemplate i.e., modification, addition, or removal of 2781 fields. Such changes will break the proof-of-possession provided by 2782 the EE in the original message. 2784 By replacing the existing using its own CMP signer key the PKI 2785 management entity provides a proof of verifying and approving the new 2786 message as described above. 2788 In addition to the above the PKI management entity MUST verify in 2789 particular the proof-of-possession contained in the original message 2790 as described above. If these checks were successfully performed the 2791 PKI management entity MUST change the popo to raVerified. 2793 The popo field MUST contain the raVerified choice in the certReq 2794 structure of the modified message as follows: 2796 popo 2797 raVerified REQUIRED 2798 -- MUST have the value NULL and indicates that the PKI 2799 -- management entity verified the popo of the original 2800 -- message 2802 5.1.3. Adding Protection 2804 This PKI management operation can be used by a PKI management entity 2805 to add another protection to one or several PKI management messages. 2806 Applying an additional protection is specifically important when 2807 forwarding certificate request messages requesting a key update or a 2808 central key generation to preserve the original protection of the EE. 2810 The nested message is a PKI management message containing a 2811 PKIMessages sequence as its body containing one or more CMP messages. 2813 As specified in the updated Section 5.1.3.4 of RFC4210 [RFC4210] (see 2814 CMP Updates [I-D.ietf-lamps-cmp-updates]) there are different use 2815 case for adding another protection by a PKI management entity. 2816 Specific procedures are described in more detail in the following 2817 sections. 2819 The behavior in case an error occurs is described in Section 4.3. 2821 Message flow: 2823 Step# PKI management entity PKI management entity 2824 1 format nested 2825 2 -> nested -> 2826 3 handle, re-protect or 2827 forward nested 2828 4 format or receive nested 2829 5 <- nested <- 2830 6 handle nested 2832 Detailed message description: 2834 Nested Message - nested 2836 Field Value 2838 header 2839 -- As described in section 3.1 2841 body 2842 -- Container to provide additional protection to original 2843 -- messages and to bundle request or response messages 2844 PKIMessages REQUIRED 2845 -- MUST be a sequence of one or more CMP messages 2847 protection REQUIRED 2848 -- As described in section 3.2 using the CMP signer key of 2849 -- the PKI management entity 2851 extraCerts REQUIRED 2852 -- As described in section 3.3 2854 5.1.3.1. Handling a single PKI management message 2856 A PKI management entity may indicate successful validation and 2857 authorization of a PKI management message by adding an additional 2858 signature to the original PKI management message. 2860 A PKI management entity SHALL wrap the original PKI management 2861 messages in a nested message structure. The additional signature as 2862 prove of verification and authorization by the PKI management entity 2863 MUST be applies as signature-based message protection of the nested 2864 message. 2866 5.1.3.2. Handling a batch of PKI management messages 2868 A PKI management entity MAY bundle any number of PKI management 2869 messages for batch processing or to transfer a bulk of PKI management 2870 messages via an offline interface using the nested message structure. 2871 Nested messages can be used on the upstream interface towards the 2872 next PKI management entity and/or on the downstream interface from 2873 the PKI management entity towards the EE. 2875 This PKI management operation is typically used on the interface 2876 between LRA and RA to bundle several PKI management messages for 2877 offline transport. In this case the LRA needs to initiate delayed 2878 enrollment as described in Section 5.1.4. If the RA may need 2879 different routing information per nested PKI management message a 2880 suitable mechanism may need to be implemented. This mechanism 2881 strongly depends on the requirements of the target architecture; 2882 therefore, it is out of scope of this document. 2884 An initial nested message is generated locally at the PKI management 2885 entity. For the initial nested message, the PKI management entity 2886 acts as a protocol end point and therefore a fresh transactionId and 2887 a fresh senderNonce MUST be used in the header of the nested message. 2888 The recipient field MUST identify the PKI management entity that is 2889 expected to unpack the nested message. An initial nested message 2890 should contain only request messages, e.g., ir, cr, p10cr, kur, 2891 certConf, rr, or genm. While building the initial nested message the 2892 PKI management entity SHOULD store the transactionIds and the 2893 senderNonces of all bundled messages together with the transactionId 2894 of the initial nested message. 2896 Such an initial nested message is sent to the next PKI management 2897 entity and SHOULD be answered with a responding nested message. This 2898 responding message SHOULD use the transactionId of the initial nested 2899 message and return the senderNonce of the initial nested message as 2900 recipNonce of the responding nested message. The responding nested 2901 message SHOULD bundle one response message (e.g. ip, cp, kup, 2902 pkiconf, rp, genp, error) for each request message (i.e., for each 2903 transactionId) in the initial nested message. While unbundling the 2904 responding nested message it is possible to determine lost and 2905 unexpected responses based on the previously stored transactionIds 2906 and senderNonces. While forwarding the unbundled responses, odd 2907 messages SHOULD be dropped, and lost messages should be replaced by 2908 an error message to inform the EE about the failed certificate 2909 management operation. 2911 The PKI management entity building the nested message applies a 2912 signature-based protection using its CMP-signer key as transport 2913 protection. This protection SHALL NOT be regarded as prove of 2914 verification or authorization of the bundled PKI management messages. 2916 5.1.4. Initiating delayed enrollment 2918 This functional extension can be used by a PKI management entity to 2919 initiate delayed enrollment. In this case a PKI management entity 2920 MUST add the status waiting in the response message. The PKI 2921 management entity MUST then reply to the pollReq messages as 2922 described in Section 4.1.7. 2924 5.2. Revoking certificates on behalf of another's entities 2926 This PKI management operation can be used by a PKI management entity 2927 to revoke a certificate of any other entity. This revocation request 2928 message MUST be signed by the PKI management entity using its own CMP 2929 signer key to prove to the PKI authorization to revoke the 2930 certificate on behalf of the EE. 2932 Preconditions: 2934 1 the certificate to be revoked MUST be known to the PKI management 2935 entity 2937 2 the PKI management entity MUST have the authorization to revoke 2938 the certificates of other entities issued by the corresponding CA 2940 The message sequence for this PKI management operation is identical 2941 to that given in Section 4.2, with the following changes: 2943 1 it is not required that the certificate to be revoked is not yet 2944 expired or revoked 2946 2 the PKI management entity acts as EE for this message exchange 2948 3 the rr messages MUST be signed using the CMP signer key of the PKI 2949 management entity. 2951 5.3. Error reporting 2953 This functionality should be used by the PKI management entity to 2954 report any error conditions downstream to the EE. Potential error 2955 reporting by the EE upstream to the PKI management entity is 2956 described in Section 4.3. 2958 In case the error condition is related to specific details of an ir, 2959 cr, p10cr, or kur request message it MUST be reported in the specific 2960 response message, i.e., an ip, cp, or kup with negative contents. 2962 General error conditions, e.g., problems with the message header, 2963 protection, or extraCerts, and negative feedback on rr, pollReq, 2964 certConf, or error messages MUST be reported in the form of an error 2965 message. 2967 In both situations the PKI management entity reports the errors in 2968 the PKIStatusInfo structure of the respective message as described in 2969 Section 4.3. 2971 An EE receiving any such negative feedback SHOULD log the error 2972 appropriately and MUST terminate the current transaction. 2974 6. CMP message transport variants 2976 The CMP messages are designed to be self-contained, such that in 2977 principle any transport can be used. HTTP SHOULD be used for online 2978 transport while file-based transport MAY be used in case offline 2979 transport is required. In case HTTP transport is not desired or 2980 possible, CMP messages MAY also be piggybacked on any other reliable 2981 transport protocol, e.g., CoAP [RFC7252]. 2983 Independently of the means of transport it could happen that messages 2984 are lost, or a communication partner does not respond. In order to 2985 prevent waiting indefinitely, each CMP client component SHOULD use a 2986 configurable per-request timeout, and each CMP server component 2987 SHOULD use a configurable per-response timeout in case a further 2988 message is to be expected from the client side. In this way a 2989 hanging transaction can be closed cleanly with an error and related 2990 resources (for instance, any cached extraCerts) can be freed. 2992 When conveying a CMP messages in HTTP or MIME-based transport 2993 protocols the internet media type "application/pkixcmp" MUST be set 2994 for transport encoding as specified in RFC2510 in Section 5.3 2995 [RFC2510] and RFC6712 in Section 3.4 [RFC7712]. 2997 6.1. HTTP transport 2999 This transport mechanism can be used by a PKI entity to transfer CMP 3000 messages over HTTP. If HTTP transport is used the specifications as 3001 described in [RFC6712] and updated by CMP Updates 3002 [I-D.ietf-lamps-cmp-updates] MUST be followed. 3004 PKI management operations SHOULD use the following URI path: 3006 +----------------------------------+---------------------+----------+ 3007 | PKI management operation | Path | Details | 3008 +----------------------------------+---------------------+----------+ 3009 | Enroll client to new PKI | /initialization | Section | 3010 | (REQUIRED) | | 4.1.1 | 3011 +----------------------------------+---------------------+----------+ 3012 | Enroll client to existing PKI | /certification | Section | 3013 | (OPTIONAL) | | 4.1.2 | 3014 +----------------------------------+---------------------+----------+ 3015 | Update client certificate | /keyupdate | Section | 3016 | (REQUIRED) | | 4.1.3 | 3017 +----------------------------------+---------------------+----------+ 3018 | Enroll client using PKCS#10 | /p10 | Section | 3019 | (OPTIONAL) | | 4.1.5 | 3020 +----------------------------------+---------------------+----------+ 3021 | Enroll client using central key | /serverkeygen | Section | 3022 | generation (OPTIONAL) | | 4.1.6 | 3023 +----------------------------------+---------------------+----------+ 3024 | Revoke client certificate | /revocation | Section | 3025 | (RECOMMENDED) | | 4.2 | 3026 +----------------------------------+---------------------+----------+ 3027 | Get CA certificates (OPTIONAL) | /getcacert | Section | 3028 | | | 4.4.1 | 3029 +----------------------------------+---------------------+----------+ 3030 | Get root CA certificate update | /getrootupdate | Section | 3031 | (OPTIONAL) | | 4.4.2 | 3032 +----------------------------------+---------------------+----------+ 3033 | Get certificate request template | /getcertreqtemplate | Section | 3034 | (OPTIONAL) | | 4.4.3 | 3035 +----------------------------------+---------------------+----------+ 3036 | Additional protection (OPTIONAL) | /nested | Section | 3037 | | | 5.1.3 | 3038 +----------------------------------+---------------------+----------+ 3040 Table 9: HTTP endpoints 3042 Subsequent certConf, error, and pollReq messages are sent to the URI 3043 of the respective PKI management operation. 3045 The discovery mechanism as described in CMP Updates 3046 [I-D.ietf-lamps-cmp-updates] SHOULD be used to query information on 3047 the supported PKI management operations, certificate profiles and 3048 CAs. 3050 As it is very likely, that a CA supports different certification 3051 profiles or that the RA offers PKI management operations for 3052 different issuing CAs, the discovery can also be used to provide the 3053 information about these options. The second example listing contains 3054 the supported PKI management operations for three different 3055 certificate profiles. The supported CA hierarchy consists of one 3056 root CA and two issuing CAs. 3058 Detailed message description: 3060 REQ: GET /.well-known/cmp 3062 RES: Content 3063 ;ct=pkixcmp 3064 ;ct=pkixcmp 3065 ;ct=pkixcmp 3066 ;ct=pkixcmp 3067 ;ct=pkixcmp 3068 ;ct=pkixcmp 3069 ;ct=pkixcmp 3070 ;ct=pkixcmp 3071 ;ct=pkixcmp 3072 ;ct=pkixcmp 3073 ;ct=pkixcmp 3074 ;ct=pkixcmp 3075 ;ct=pkixcmp 3076 ;ct=pkixcmp 3077 ;ct=pkixcmp 3078 ;ct=pkixcmp 3079 ;ct=pkixcmp 3080 ;ct=pkixcmp 3081 ;ct=pkixcmp 3083 There are different options in the handling of the naming. The PKI 3084 management entity either needs to offer the certprofile or CA labels 3085 the EE expects. Alternatively, a mechanism is required to configure 3086 this information to the EE beforehand. 3088 6.2. HTTPS transport using certificates 3090 This transport mechanism can be used by a PKI entity to further 3091 protect the HTTP transport as described in Section 6.1 using TLS 1.2 3092 [RFC5246] or TLS 1.3 [RFC8446] as described in [RFC2818] with 3093 certificate-based authentication. Using this transport mechanism, 3094 the CMP transport via HTTPS MUST use TLS server authentication and 3095 SHOULD use TLS client authentication. 3097 EE: 3099 o The EE SHOULD use a TLS client certificate as far as available. 3100 If no dedicated TLS certificate is available, the EE SHOULD use an 3101 already existing certificate identifying the EE (e.g., a 3102 manufacturer certificate). 3104 o If no TLS certificate is available at the EE, server-only 3105 authenticated TLS SHOULD be used. 3107 o The EE MUST validate the TLS server certificate of its 3108 communication partner. 3110 PKI management entity: 3112 o Each PKI management entity SHOULD use a TLS client certificate on 3113 its upstream (client) interface. 3115 o Each PKI management entity MUST use a TLS server certificate on 3116 its downstream (server) interface. 3118 o Each PKI management entity MUST validate the TLS certificate of 3119 its communication partners. 3121 NOTE: The requirements for checking certificates given in [RFC5280], 3122 [RFC5246] and [RFC8446] MUST be followed for the TLS layer. 3123 Certificate status checking SHOULD be used for the TLS certificates 3124 of communication partners. 3126 6.3. HTTPS transport using shared secrets 3128 This transport mechanism can be used by a PKI entity to further 3129 protect the HTTP transport as described in Section 6.1 using TLS 1.2 3130 [RFC5246] or TLS 1.3 [RFC8446] as described in [RFC2818] with mutual 3131 authentication based on shared secrets as described in [RFC5054]. 3133 EE: 3135 o The EE MUST use the shared symmetric key for authentication. 3137 PKI management entity: 3139 o The PKI management entity MUST use the shared symmetric key for 3140 authentication. 3142 < TBD: It needs to be clarified which cipher suite shall be 3143 recommended as there seems to be no support for TLS-SRP un JavaSE. > 3145 6.4. Offline transport 3147 For transporting CMP messages between PKI entities any mechanism can 3148 be used that is able to store and forward binary objects of 3149 sufficient length and with sufficient reliability while preserving 3150 the order of messages. 3152 The transport mechanism SHOULD be able to indicate message loss, 3153 excessive delay, and possibly other transmission errors. In such 3154 cases the PKI entities using this mechanism SHOULD report an error as 3155 specified in Section 4.3. 3157 6.4.1. File-based transport 3159 CMP messages MAY be transferred between PKI entities using file- 3160 system-based mechanisms, for instance when an off-line end entity or 3161 a PKI management entity performs delayed enrollment. Each file MUST 3162 contain the ASN.1 DER encoding of one CMP message only. There MUST 3163 be no extraneous header or trailer information in the file. The file 3164 type extensions ".PKI" SHOULD be used. 3166 6.4.2. Other asynchronous transport protocols 3168 Other asynchronous transport protocols, e.g., email or website 3169 up-/download, MAY transfer CMP messages between PKI entities. A MIME 3170 wrapping is defined for those environments that are MIME native. The 3171 MIME wrapping in this section is specified in [RFC8551], section 3.1. 3173 The ASN.1 DER encoding of the CMP messages MUST be transferred using 3174 the "application/pkixcmp" content type and base64-encoded content- 3175 transfer-encoding as specified in [RFC2510], section 5.3. A filename 3176 MUST be included either in a content-type or a content-disposition 3177 statement. The extension for the file MUST be ".PKI". 3179 6.5. CoAP transport 3181 In constrained environments where no HTTP transport is desired or 3182 possible, CoAP [RFC7252] as specified in 3183 [I-D.msahni-tbd-cmpv2-coap-transport] MAY be used instead. 3185 6.6. Piggybacking on other reliable transport 3187 For online transfer where no HTTP transport is desired or possible 3188 CMP messages MAY also be transported on some other reliable protocol. 3189 Connection and error handling mechanisms like those specified for 3190 HTTP in [RFC6712] need to be implemented. 3192 Such specification is out of scope of this document and would need to 3193 be specifies in a separate document, e.g., in the scope of the 3194 respective transport protocol used. 3196 7. IANA Considerations 3198 8. Security Considerations 3200 < TBD: Add any security considerations > 3202 9. Acknowledgements 3204 We would like to thank the various reviewers of this document. 3206 10. References 3208 10.1. Normative References 3210 [I-D.housley-lamps-crmf-update-algs] 3211 Housley, R., "Algorithm Requirements Update to the 3212 Internet X.509 Public Key Infrastructure Certificate 3213 Request Message Format (CRMF)", draft-housley-lamps-crmf- 3214 update-algs-01 (work in progress), October 2020. 3216 [I-D.ietf-lamps-cmp-algorithms] 3217 Brockhaus, H., "CMP Algorithms", draft-ietf-lamps-cmp- 3218 algorithms-00 (work in progress), October 2020. 3220 [I-D.ietf-lamps-cmp-updates] 3221 Brockhaus, H., "CMP Updates", draft-ietf-lamps-cmp- 3222 updates-05 (work in progress), September 2020. 3224 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 3225 Requirement Levels", BCP 14, RFC 2119, 3226 DOI 10.17487/RFC2119, March 1997, 3227 . 3229 [RFC2986] Nystrom, M. and B. Kaliski, "PKCS #10: Certification 3230 Request Syntax Specification Version 1.7", RFC 2986, 3231 DOI 10.17487/RFC2986, November 2000, 3232 . 3234 [RFC4086] Eastlake 3rd, D., Schiller, J., and S. Crocker, 3235 "Randomness Requirements for Security", BCP 106, RFC 4086, 3236 DOI 10.17487/RFC4086, June 2005, 3237 . 3239 [RFC4210] Adams, C., Farrell, S., Kause, T., and T. Mononen, 3240 "Internet X.509 Public Key Infrastructure Certificate 3241 Management Protocol (CMP)", RFC 4210, 3242 DOI 10.17487/RFC4210, September 2005, 3243 . 3245 [RFC4211] Schaad, J., "Internet X.509 Public Key Infrastructure 3246 Certificate Request Message Format (CRMF)", RFC 4211, 3247 DOI 10.17487/RFC4211, September 2005, 3248 . 3250 [RFC5280] Cooper, D., Santesson, S., Farrell, S., Boeyen, S., 3251 Housley, R., and W. Polk, "Internet X.509 Public Key 3252 Infrastructure Certificate and Certificate Revocation List 3253 (CRL) Profile", RFC 5280, DOI 10.17487/RFC5280, May 2008, 3254 . 3256 [RFC5652] Housley, R., "Cryptographic Message Syntax (CMS)", STD 70, 3257 RFC 5652, DOI 10.17487/RFC5652, September 2009, 3258 . 3260 [RFC5958] Turner, S., "Asymmetric Key Packages", RFC 5958, 3261 DOI 10.17487/RFC5958, August 2010, 3262 . 3264 [RFC6712] Kause, T. and M. Peylo, "Internet X.509 Public Key 3265 Infrastructure -- HTTP Transfer for the Certificate 3266 Management Protocol (CMP)", RFC 6712, 3267 DOI 10.17487/RFC6712, September 2012, 3268 . 3270 [RFC8174] Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC 3271 2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174, 3272 May 2017, . 3274 10.2. Informative References 3276 [ETSI-TS133310] 3277 ETSI, "TS 133 310; Network Domain Security (NDS); 3278 Authentication Framework (AF); Release 16; V16.4.0", 3279 August 2020, . 3282 [I-D.msahni-tbd-cmpv2-coap-transport] 3283 Sahni, M., "CoAP Transport for CMPV2", draft-msahni-tbd- 3284 cmpv2-coap-transport-00 (work in progress), June 2020. 3286 [IEC62443-3-3] 3287 IEC, "Industrial communication networks - Network and 3288 system security - Part 3-3: System security requirements 3289 and security levels", IEC 62443-3-3, August 2013, 3290 . 3292 [IEEE802.1AR] 3293 IEEE, "802.1AR Secure Device Identifier", June 2018, 3294 . 3297 [NIST-CSFW] 3298 NIST, "Framework for Improving Critical Infrastructure 3299 Cybersecurity Version 1.1", April 2018, 3300 . 3303 [RFC2510] Adams, C. and S. Farrell, "Internet X.509 Public Key 3304 Infrastructure Certificate Management Protocols", 3305 RFC 2510, DOI 10.17487/RFC2510, March 1999, 3306 . 3308 [RFC2818] Rescorla, E., "HTTP Over TLS", RFC 2818, 3309 DOI 10.17487/RFC2818, May 2000, 3310 . 3312 [RFC3647] Chokhani, S., Ford, W., Sabett, R., Merrill, C., and S. 3313 Wu, "Internet X.509 Public Key Infrastructure Certificate 3314 Policy and Certification Practices Framework", RFC 3647, 3315 DOI 10.17487/RFC3647, November 2003, 3316 . 3318 [RFC5054] Taylor, D., Wu, T., Mavrogiannopoulos, N., and T. Perrin, 3319 "Using the Secure Remote Password (SRP) Protocol for TLS 3320 Authentication", RFC 5054, DOI 10.17487/RFC5054, November 3321 2007, . 3323 [RFC5246] Dierks, T. and E. Rescorla, "The Transport Layer Security 3324 (TLS) Protocol Version 1.2", RFC 5246, 3325 DOI 10.17487/RFC5246, August 2008, 3326 . 3328 [RFC7252] Shelby, Z., Hartke, K., and C. Bormann, "The Constrained 3329 Application Protocol (CoAP)", RFC 7252, 3330 DOI 10.17487/RFC7252, June 2014, 3331 . 3333 [RFC7712] Saint-Andre, P., Miller, M., and P. Hancke, "Domain Name 3334 Associations (DNA) in the Extensible Messaging and 3335 Presence Protocol (XMPP)", RFC 7712, DOI 10.17487/RFC7712, 3336 November 2015, . 3338 [RFC8366] Watsen, K., Richardson, M., Pritikin, M., and T. Eckert, 3339 "A Voucher Artifact for Bootstrapping Protocols", 3340 RFC 8366, DOI 10.17487/RFC8366, May 2018, 3341 . 3343 [RFC8446] Rescorla, E., "The Transport Layer Security (TLS) Protocol 3344 Version 1.3", RFC 8446, DOI 10.17487/RFC8446, August 2018, 3345 . 3347 [RFC8551] Schaad, J., Ramsdell, B., and S. Turner, "Secure/ 3348 Multipurpose Internet Mail Extensions (S/MIME) Version 4.0 3349 Message Specification", RFC 8551, DOI 10.17487/RFC8551, 3350 April 2019, . 3352 [UNISIG-Subset137] 3353 UNISIG, "Subset-137; ERTMS/ETCS On-line Key Management 3354 FFFIS; V1.0.0", December 2015, 3355 . 3357 Appendix A. Example for CertReqTemplate 3359 < TBD: This Appendix must be updated to reflect the change from using 3360 rsaKeyLen to controles. > 3362 This Section provides a concrete example for the content of an 3363 infoValue used of type id-it-certReqTemplate as described in 3364 Section 4.4.3. 3366 Suppose the server requires that the certTemplate contains the issuer 3367 field with a value to be filled in by the EE, the subject field with 3368 a common name to be filled in by the EE and two organizational unit 3369 fields with given values "myDept" and "myGroup", the publicKey field 3370 with an RSA public key of length 2048, the subjectAltName extension 3371 with DNS name "www.myServer.com" and an IP address to be filled in, 3372 the keyUsage extension marked critical with the value 3373 digitalSignature and keyAgreement, and the extKeyUsage extension with 3374 values to be filled in by the EE. Then the infoValue with 3375 certTemplate and rsaKeyLen returned to the EE must be encoded as 3376 follows: 3378 SEQUENCE { 3379 SEQUENCE { 3380 [3] { 3381 SEQUENCE {} 3382 } 3383 [5] { 3384 SEQUENCE { 3385 SET { 3386 SEQUENCE { 3387 OBJECT IDENTIFIER commonName (2 5 4 3) 3388 UTF8String '' 3389 } 3390 } 3391 SEQUENCE { 3392 OBJECT IDENTIFIER organizationalUnitName (2 5 4 11) 3393 UTF8String 'myDept' 3394 } 3395 } 3396 SET { 3397 SEQUENCE { 3398 OBJECT IDENTIFIER organizationalUnitName (2 5 4 11) 3399 UTF8String 'myGroup' 3400 } 3401 } 3402 } 3403 } 3404 [6] { 3405 SEQUENCE { 3406 OBJECT IDENTIFIER rsaEncryption (1 2 840 113549 1 1 1) 3407 NULL 3408 } 3409 BIT STRING, encapsulates { 3410 SEQUENCE {} 3411 } 3412 } 3413 [9] { 3414 SEQUENCE { 3415 OBJECT IDENTIFIER subjectAltName (2 5 29 17) 3416 OCTET STRING, encapsulates { 3417 SEQUENCE { 3418 [2] 'www.myServer.com' 3419 [7] '' 3420 } 3421 } 3422 } 3423 SEQUENCE { 3424 OBJECT IDENTIFIER keyUsage (2 5 29 15) 3425 BOOLEAN TRUE 3426 OCTET STRING, encapsulates { 3427 BIT STRING 3 unused bits 3428 '10001'B 3430 } 3431 } 3432 SEQUENCE { 3433 OBJECT IDENTIFIER extKeyUsage (2 5 29 37) 3434 OCTET STRING, encapsulates { 3435 SEQUENCE {} 3436 } 3437 } 3438 } 3439 } 3440 INTEGER 2048 3441 } 3443 Appendix B. History of changes 3445 Note: This appendix will be deleted in the final version of the 3446 document. 3448 From version 03 -> 04: 3450 o Deleted normative text sections on algorithms and refer to CMP 3451 Algorithms and CRMF Algorithm Requirements Update instead 3453 o Some clarifications and changes in wording 3455 From version 02 -> 03: 3457 o Updated the interoperability with [UNISIG-Subset137] in 3458 Section 1.4. 3460 o Changed Section 2.3 to a tabular layout to enhanced readability 3462 o Added a ToDo to section 3.1 on aligning with the CMP Algorithms 3463 draft that will be set up as decided in IETF 108 3465 o Updated section 4.1.6 to add the AsymmetricKey Package structure 3466 to transport a newly generated private key as decided in IETF 108 3468 o Added a ToDo to section 4.1.7 on required review of the nonce 3469 handling in case an offline LRA responds and not forwards the 3470 pollReq messages 3472 o Updated Section 4 due to the definition of the new ITAV OIDs in 3473 CMP Updates 3475 o Updated Section 4.4.4 to utilize controls instead of rsaKeyLen 3476 (see thread "dtaft-ietf-lamps-cmp-updates and rsaKeyLen") 3478 o Deleted the section on definition and discovery of HTTP URIs and 3479 copied the text to the HTTP transport section and to CMP Updates 3480 section 3.2 3482 o Added some explanation to Section 5.1.2 and Section 5.1.3 on using 3483 nested messages when a protection by the RA is required. 3485 o Deleted the section on HTTP URI definition and discovery as some 3486 content was moved to CMP Updates. The rest of the content was 3487 moved back to the HTTP transport section 3489 o Deleted the ASN.1 module after moving the new OIDs id-it-caCerts, 3490 id-it-rootCaKeyUpdate, and id-it-certReqTemplate to CMP Updates 3492 o Minor changes in wording and addition of some open ToDos 3494 From version 01 -> 02: 3496 o Extend Section 1.4 with regard to conflicts with UNISIG Subset- 3497 137. 3499 o Minor clarifications on extraCerts in Section 3.3 and 3500 Section 4.1.1. 3502 o Complete specification of requesting a certificate from a trusted 3503 PKI with signature protection in Section 4.1.2. 3505 o Changed from symmetric key-encryption to password-based key 3506 management technique in section Section 4.1.6.3 as discussed on 3507 the mailing list (see thread "draft-ietf-lamps-lightweight-cmp- 3508 profile-01, section 5.1.6.1") 3510 o Changed delayed enrollment described in Section 4.1.7 from 3511 recommended to optional as decided at IETF 107 3513 o Introduced the new RootCAKeyUpdate structure for root CA 3514 certificate update in Section 4.4.2 as decided at IETF 107 (also 3515 see email thread "draft-ietf-lamps-lightweight-cmp-profile-01, 3516 section 5.4.3") 3518 o Extend the description of the CertReqTemplate PKI management 3519 operation, including an example added in the Appendix. Keep 3520 rsaKeyLen as a single integer value in Section 4.4.3 as discussed 3521 on the mailing list (see thread "draft-ietf-lamps-lightweight-cmp- 3522 profile-01, section 5.4.4") 3524 o Deleted Sections "Get certificate management configuration" and 3525 "Get enrollment voucher" as decided at IETF 107 3527 o Complete specification of adding an additional protection by an 3528 PKI management entity in Section 5.1.3. 3530 o Added a section on HTTP URI definition and discovery and extended 3531 Section 6.1 on definition and discovery of supported HTTP URIs and 3532 content types, add a path for nested messages as specified in 3533 Section 5.1.3 and delete the paths for /getCertMgtConfig and 3534 /getVoucher 3536 o Changed Section 6.4 to address offline transport and added more 3537 detailed specification file-based transport of CMP 3539 o Added a reference to the new I-D of Mohit Sahni on "CoAP Transport 3540 for CMPV2" in Section 6.5; thanks to Mohit supporting the effort 3541 to ease utilization of CMP 3543 o Moved the change history to the Appendix 3545 o Minor changes in wording 3547 From version 00 -> 01: 3549 o Harmonize terminology with CMP [RFC4210], e.g., 3551 * transaction, message sequence, exchange, use case -> PKI 3552 management operation 3554 * PKI component, (L)RA/CA -> PKI management entity 3556 o Minor changes in wording 3558 From draft-brockhaus-lamps-lightweight-cmp-profile-03 -> draft-ietf- 3559 lamps-lightweight-cmp-profile-00: 3561 o Changes required to reflect WG adoption 3563 o Minor changes in wording 3565 From version 02 -> 03: 3567 o Added a short summary of [RFC4210] Appendix D and E in 3568 Section 1.3. 3570 o Clarified some references to different sections and added some 3571 clarification in response to feedback from Michael Richardson and 3572 Tomas Gustavsson. 3574 o Added an additional label to the operational path to address 3575 multiple CAs or certificate profiles in Section 6.1. 3577 From version 01 -> 02: 3579 o Added some clarification on the key management techniques for 3580 protection of centrally generated keys in Section 4.1.6. 3582 o Added some clarifications on the certificates for root CA 3583 certificate update in Section 4.4.2. 3585 o Added a section to specify the usage of nested messages for RAs to 3586 add an additional protection for further discussion, see 3587 Section 5.1.3. 3589 o Added a table containing endpoints for HTTP transport in 3590 Section 6.1 to simplify addressing PKI management entities. 3592 o Added some ToDos resulting from discussion with Tomas Gustavsson. 3594 o Minor clarifications and changes in wording. 3596 From version 00 -> 01: 3598 o Added a section to specify the enrollment with an already trusted 3599 PKI for further discussion, see Section 4.1.2. 3601 o Complete specification of requesting a certificate from a legacy 3602 PKI using a PKCS#10 [RFC2986] request in Section 4.1.5. 3604 o Complete specification of adding central generation of a key pair 3605 on behalf of an end entity in Section 4.1.6. 3607 o Complete specification of handling delayed enrollment due to 3608 asynchronous message delivery in Section 4.1.7. 3610 o Complete specification of additional support messages, e.g., to 3611 update a Root CA certificate or to request an RFC 8366 [RFC8366] 3612 voucher, in Section 4.4. 3614 o Minor changes in wording. 3616 From draft-brockhaus-lamps-industrial-cmp-profile-00 -> draft- 3617 brockhaus-lamps-lightweight-cmp-profile-00: 3619 o Change focus from industrial to more multi-purpose use cases and 3620 lightweight CMP profile. 3622 o Incorporate the omitted confirmation into the header specified in 3623 Section 3.1 and described in the standard enrollment use case in 3624 Section 4.1.1 due to discussion with Tomas Gustavsson. 3626 o Change from OPTIONAL to RECOMMENDED for use case 'Revoke another's 3627 entities certificate' in Section 5.2, because it is regarded as 3628 important functionality in many environments to enable the 3629 management station to revoke EE certificates. 3631 o Complete the specification of the revocation message flow in 3632 Section 4.2 and Section 5.2. 3634 o The CoAP based transport mechanism and piggybacking of CMP 3635 messages on top of other reliable transport protocols is out of 3636 scope of this document and would need to be specified in another 3637 document. 3639 o Further minor changes in wording. 3641 Authors' Addresses 3643 Hendrik Brockhaus (editor) 3644 Siemens AG 3646 Email: hendrik.brockhaus@siemens.com 3648 Steffen Fries 3649 Siemens AG 3651 Email: steffen.fries@siemens.com 3653 David von Oheimb 3654 Siemens AG 3656 Email: david.von.oheimb@siemens.com