idnits 2.17.1 draft-ietf-lamps-lightweight-cmp-profile-05.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 for recipientInfo type KeyAgreeRecipientInfo -- and KeyTransRecipientInfo -- MUST be set to 0 for recipientInfo type PasswordRecipientInfo recipientInfos REQUIRED -- MUST be exactly one RecipientInfo recipientInfo REQUIRED -- MUST be either KeyAgreeRecipientInfo (see section 4.1.6.1), -- KeyTransRecipientInfo (see section 4.1.6.2), or -- PasswordRecipientInfo (see section 4.1.6.3) -- 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 specify the algorithm OID of the algorithm used for -- content encryption -- The algorithm MUST be a PROT_SYM_ALG as specified in -- RFC-CMP-Alg Section 5 encryptedContent REQUIRED -- MUST be the SignedData structure as specified in -- CMS Section 5 [RFC5652] in encrypted form version REQUIRED -- MUST be set to 3 if X.509 V3 certificates are included digestAlgorithms REQUIRED -- MUST be exactly one digestAlgorithm OID digestAlgorithmIdentifier REQUIRED -- MUST be the OID of the digest algorithm used for generating -- the signature and match the signature algorithm specified in -- signatureAlgorithm encapContentInfo REQUIRED -- MUST contain the content that is to be signed eContentType REQUIRED -- MUST be id-ct-KP-aKeyPackage as specified in [RFC5958] eContent REQUIRED AsymmetricKeyPackage REQUIRED -- MUST contain exactly one OneAsymmetricKey element OneAsymmetricKey REQUIRED version REQUIRED -- MUST be set to 1 privateKeyAlgorithm REQUIRED -- The privateKeyAlgorithm field MUST contain -- the OID of the asymmetric key pair algorithm privateKey REQUIRED -- MUST contain the new private key attributes OPTIONAL -- The attributes field SHOULD not be used publicKey REQUIRED -- MUST contain the public key corresponding to the private key -- for simplicity and consistency with V2 of OneAsymmetricKey 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 protecting this content -- Self-signed certificates SHOULD NOT be included -- and MUST NOT be trusted based on their inclusion in any case crls OPTIONAL -- MAY be present to provide status information on the protection -- certificate 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 protection certificate digestAlgorithm REQUIRED -- MUST be the same as in digestAlgorithmIdentifier signedAttrs REQUIRED -- MUST contain an id-contentType attribute containing the same -- value as eContentType -- MUST contain an id-messageDigest attribute containing the -- message digest of eContent -- MAY contain an id-signingTime attribute containing the time of -- signature -- For details on the signed attributes see CMS Section 5.3 -- and Section 11 [RFC5652] signatureAlgorithm REQUIRED -- MUST be the algorithm OID of the signature algorithm used for -- calculation of the signature bits -- The signature algorithm MUST be a MSG_SIG_ALG as specified in -- RFC-CMP-Alg Section 3 and MUST be consistent with the -- subjectPublicKeyInfo field of the CMP KGA 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: A PKI management entity SHOULD not change the received message unless necessary. The PKI management entity SHOULD only update the message protection if this is technically necessary. Concrete PKI system specifications may define in more detail when to do so. -- The document date (22 February 2021) is 1152 days in the past. Is this intentional? Checking references for intended status: Proposed Standard ---------------------------------------------------------------------------- (See RFCs 3967 and 4897 for information about using normative references to lower-maturity documents in RFCs) == Missing Reference: 'RFC8419' is mentioned on line 1874, but not defined -- Looks like a reference, but probably isn't: '3' on line 3445 -- Looks like a reference, but probably isn't: '5' on line 3448 -- Looks like a reference, but probably isn't: '6' on line 3468 -- Looks like a reference, but probably isn't: '9' on line 3477 -- Looks like a reference, but probably isn't: '2' on line 3482 -- Looks like a reference, but probably isn't: '7' on line 3483 == Outdated reference: A later version (-15) exists of draft-ietf-lamps-cmp-algorithms-02 == Outdated reference: A later version (-23) exists of draft-ietf-lamps-cmp-updates-08 == Outdated reference: A later version (-07) exists of draft-ietf-lamps-crmf-update-algs-04 ** Downref: Normative reference to an Informational RFC: RFC 2986 == Outdated reference: A later version (-10) exists of draft-ietf-ace-cmpv2-coap-transport-00 -- 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 (~~), 12 warnings (==), 10 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: 26 August 2021 Siemens 6 22 February 2021 8 Lightweight Certificate Management Protocol (CMP) Profile 9 draft-ietf-lamps-lightweight-cmp-profile-05 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 26 August 2021. 42 Copyright Notice 44 Copyright (c) 2021 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 (https://trustee.ietf.org/ 49 license-info) in effect on the date of publication of this document. 50 Please review these documents carefully, as they describe your rights 51 and restrictions with respect to this document. Code Components 52 extracted from this document must include Simplified BSD License text 53 as described in Section 4.e of the Trust Legal Provisions and are 54 provided without warranty as described in the Simplified BSD License. 56 Table of Contents 58 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 3 59 1.1. Motivation for profiling CMP . . . . . . . . . . . . . . 4 60 1.2. Motivation for a lightweight profile for CMP . . . . . . 5 61 1.3. Existing CMP profiles . . . . . . . . . . . . . . . . . . 6 62 1.4. Compatibility with existing CMP profiles . . . . . . . . 8 63 1.5. Scope of this document . . . . . . . . . . . . . . . . . 9 64 1.6. Structure of this document . . . . . . . . . . . . . . . 10 65 1.7. Convention and Terminology . . . . . . . . . . . . . . . 11 66 2. Architecture and use cases . . . . . . . . . . . . . . . . . 11 67 2.1. Solution architecture . . . . . . . . . . . . . . . . . . 12 68 2.2. Basic generic CMP message content . . . . . . . . . . . . 13 69 2.3. Supported PKI management operations . . . . . . . . . . . 13 70 2.3.1. Mandatory PKI management operations . . . . . . . . . 14 71 2.3.2. Recommended PKI management operations . . . . . . . . 14 72 2.3.3. Optional PKI management operations . . . . . . . . . 15 73 2.4. CMP message transport . . . . . . . . . . . . . . . . . . 16 74 3. Generic parts of the PKI message . . . . . . . . . . . . . . 17 75 3.1. General description of the CMP message header . . . . . . 18 76 3.2. General description of the CMP message protection . . . . 20 77 3.3. General description of CMP message extraCerts . . . . . . 21 78 4. End Entity PKI management operations . . . . . . . . . . . . 21 79 4.1. Requesting a new certificate from a PKI . . . . . . . . . 22 80 4.1.1. Requesting a certificate from a new PKI with signature 81 protection . . . . . . . . . . . . . . . . . . . . . 24 82 4.1.2. Requesting a certificate from a trusted PKI with 83 signature protection . . . . . . . . . . . . . . . . 30 84 4.1.3. Updating an existing certificate with signature 85 protection . . . . . . . . . . . . . . . . . . . . . 31 86 4.1.4. Requesting a certificate from a PKI with MAC 87 protection . . . . . . . . . . . . . . . . . . . . . 32 88 4.1.5. Requesting a certificate from a legacy PKI using 89 PKCS#10 request . . . . . . . . . . . . . . . . . . . 33 90 4.1.6. Generateing the key pair centrally at the PKI 91 management 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 . . 43 94 4.1.6.3. Using password-based key management technique . . 43 96 4.1.7. Delayed enrollment . . . . . . . . . . . . . . . . . 44 97 4.2. Revoking a certificate . . . . . . . . . . . . . . . . . 48 98 4.3. Error reporting . . . . . . . . . . . . . . . . . . . . . 50 99 4.4. Support messages . . . . . . . . . . . . . . . . . . . . 52 100 4.4.1. Get CA certificates . . . . . . . . . . . . . . . . . 54 101 4.4.2. Get root CA certificate update . . . . . . . . . . . 55 102 4.4.3. Get certificate request template . . . . . . . . . . 56 103 5. LRA and RA PKI management operations . . . . . . . . . . . . 59 104 5.1. Forwarding messages . . . . . . . . . . . . . . . . . . . 59 105 5.1.1. Not changing protection . . . . . . . . . . . . . . . 61 106 5.1.2. Replacing protection . . . . . . . . . . . . . . . . 61 107 5.1.2.1. Keeping proof-of-possession . . . . . . . . . . . 62 108 5.1.2.2. Breaking proof-of-possession . . . . . . . . . . 63 109 5.1.3. Adding Protection . . . . . . . . . . . . . . . . . . 63 110 5.1.3.1. Handling a single PKI management message . . . . 64 111 5.1.3.2. Handling a batch of PKI management messages . . . 65 112 5.1.4. Initiating delayed enrollment . . . . . . . . . . . . 66 113 5.2. Revoking certificates on behalf of another's PKI 114 entities . . . . . . . . . . . . . . . . . . . . . . . . 66 115 5.3. Error reporting . . . . . . . . . . . . . . . . . . . . . 67 116 6. CMP message transport mechanisms . . . . . . . . . . . . . . 67 117 6.1. HTTP transport . . . . . . . . . . . . . . . . . . . . . 68 118 6.2. HTTPS transport using certificates . . . . . . . . . . . 69 119 6.3. HTTPS transport using shared secrets . . . . . . . . . . 70 120 6.4. Offline transport . . . . . . . . . . . . . . . . . . . . 70 121 6.4.1. File-based transport . . . . . . . . . . . . . . . . 71 122 6.4.2. Other asynchronous transport protocols . . . . . . . 71 123 6.5. CoAP transport . . . . . . . . . . . . . . . . . . . . . 71 124 6.6. Piggybacking on other reliable transport . . . . . . . . 71 125 7. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 71 126 8. Security Considerations . . . . . . . . . . . . . . . . . . . 71 127 9. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 72 128 10. References . . . . . . . . . . . . . . . . . . . . . . . . . 72 129 10.1. Normative References . . . . . . . . . . . . . . . . . . 72 130 10.2. Informative References . . . . . . . . . . . . . . . . . 73 131 Appendix A. Example CertReqTemplate . . . . . . . . . . . . . . 75 132 Appendix B. History of changes . . . . . . . . . . . . . . . . . 77 133 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 81 135 1. Introduction 137 [RFC Editor: please delete]:!!! The change history was moved to 138 Appendix B !!! 140 [RFC Editor: please delete]: The labels 'RFC-CMP-Updates', 'RFC-CMP- 141 Alg', and 'RFC-CRMF-Alg' in ASN.1 Syntax needs to be replaced with 142 the RFC numbers of CMP Updates [I-D.ietf-lamps-cmp-updates], CMP 143 Algorithms [I-D.ietf-lamps-cmp-algorithms] and CRMF Algorithm 144 Requirements Update [I-D.ietf-lamps-crmf-update-algs], when 145 available. 147 This document specifies PKI management operations supporting machine- 148 to-machine and IoT use cases. The focus lies on maximum automation 149 and interoperable implementation of all involved PKI entities from 150 end entities (EE) through an optional Local Registration Authority 151 (LRA) and the RA up to the CA. The profile makes use of the concepts 152 and syntax specified in CMP [RFC4210], CRMF [RFC4211], HTTP transfer 153 for CMP [RFC6712], and CMP Updates [I-D.ietf-lamps-cmp-updates]. 154 Especially CMP and CRMF are very feature-rich standards, while in 155 most environments only a limited subset of the specified 156 functionality is needed. Additionally, the standards are not always 157 precise enough on how to interpret and implement the described 158 concepts. Therefore, this document aims at tailoring and specifying 159 in more detail how to use these concepts to implement lightweight 160 automated certificate management. 162 1.1. Motivation for profiling CMP 164 CMP was standardized in 1999 and is implemented in several PKI 165 products. In 2005 a completely reworked and enhanced version 2 of 166 CMP [RFC4210] and CRMF [RFC4211] has been published followed by a 167 document specifying a transfer mechanism for CMP messages using HTTP 168 [RFC6712] in 2012. 170 Though CMP is a very solid and capable protocol it is so far not used 171 very widely. The most important reason appears to be that the 172 protocol offers a too large set of features and options. On the one 173 hand, this makes CMP applicable to a very wide range of scenarios, 174 but on the other hand a full implementation of all options is not 175 realistic because this would take undue effort. 177 Moreover, many details of the CMP protocol have been left open or 178 have not been specified in full preciseness. The profiles specified 179 in Appendix D and E of [RFC4210] define some more detailed PKI 180 management operations. Yet the specific needs of highly automated 181 scenarios for a machine-to-machine communication are not covered 182 sufficiently. 184 As also 3GPP and UNISIG already put across, profiling is a way of 185 coping with the challenges mentioned above. To profile means to take 186 advantage of the strengths of the given protocol, while explicitly 187 narrowing down the options it provides to those needed for the 188 purpose(s) at hand and eliminating all identified ambiguities. In 189 this way all the general and applicable aspects of the general 190 protocol are taken over and only the peculiarities of the target 191 scenario need to be dealt with specifically. 193 Defining such a profile for a new target environment take a high 194 effort because the range of available options needs to be well 195 understood and the selected options need to be consistent with each 196 other and with the intended usage scenario. Since most industrial 197 PKI management use cases typically have much in common it is worth 198 sharing this effort, which is the aim of this document. Other 199 standardization bodies can reference this document and do not need to 200 come up with individual profiles. 202 1.2. Motivation for a lightweight profile for CMP 204 The profiles specified in Appendix D and E of RFC 4210 [RFC4210] have 205 been developed particularly for managing certificates of human end 206 entities. With the evolution of distributed systems and client- 207 server architectures, certificates for machines and applications on 208 them have become widely used. This trend has strengthened even more 209 in emerging industrial and IoT scenarios. CMP is sufficiently 210 flexible to support them 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 needs 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 Framework for Improving Critical Infrastructure Cybersecurity 224 [NIST.CSWP.04162018] also refers to proper processes for issuance, 225 management, verification, revocation, and audit for authorized 226 devices, users and processes involving identity and credential 227 management. Such PKI operation according to commonly accepted best 228 practices is also required in IEC 62443-3-3 [IEC.62443-3-3] for 229 security level 2 and higher. 231 Further challenges in many industrial systems are network 232 segmentation and asynchronous communication, while PKI operation 233 typically is not deployed on-site but in a more protected environment 234 of a data center or trust center. Certificate management must be 235 able to cope with such network architectures. CMP offers the 236 required flexibility and functionality, namely self-contained 237 messages, efficient polling, and support for asynchronous message 238 transfer while retaining end-to-end security. 240 1.3. Existing CMP profiles 242 As already stated, RFC 4210 [RFC4210] contains profiles with 243 mandatory and optional PKI management operations in Appendix D and E. 244 Those profiles focus on management of human user certificates and do 245 only partly address the specific needs for certificate management 246 automation for unattended machines or application-oriented end 247 entities. 249 RFC 4210 [RFC4210] specifies in Appendix D the following mandatory 250 PKI management operations. All requirements regarding algorithm 251 support have been updated by CMP Algorithms Section 7.2 252 [I-D.ietf-lamps-cmp-algorithms], all operations may enroll up to two 253 certificates, one for a locally generated and optionally another one 254 for a centrally generated key pair, and all require use of certConf/ 255 pkiConf messages for confirmation. 257 * Initial registration/certification; an (uninitialized) end entity 258 requests a (first) certificate from a CA using shared secret based 259 message authentication. The content is similar to the PKI 260 management operation specified in Section 4.1.4 of this document. 262 * Certificate request; an (initialized) end entity requests another 263 certificate from a CA using signature-based or shared secret-based 264 message authentication. The content is similar to the PKI 265 management operation specified in Section 4.1.2 of this document. 267 * Key update; an (initialized) end entity requests a certificate 268 from a CA (to update the key pair and/or corresponding certificate 269 that it already possesses) using signature-based or shared secret- 270 based message authentication. The content is similar to the PKI 271 management operation specified in Section 4.1.3 of this document. 273 Two certificates may be enrolled and authentication is based on 274 shared secrets because these PKI management operations focus on the 275 enrollment of certificates of humans. 277 RFC 4210 [RFC4210] specifies in Appendix E the following optional PKI 278 management operations. All requirements regarding algorithm support 279 have been updated by CMP Algorithms Section 7.2 280 [I-D.ietf-lamps-cmp-algorithms]. 282 * Root CA key update; a root CA updates its key pair and produces a 283 CA key update announcement message, which can be made available 284 (via some transport mechanism) to the relevant end entities. This 285 operation only supports a push model. The content is similar to 286 the PKI management operation supporting the pull model specified 287 in Section 4.4.2 of this document. 289 * Information request/response; an end entity sends a general 290 message to the PKI requesting details that will be required for 291 later PKI management operations. The content is similar to the 292 PKI management operation specified in Section 4.4.3 of this 293 document. 295 * Cross-certification request/response (1-way); creation of a single 296 cross-certificate (i.e., not two at once). The requesting CA MAY 297 choose who is responsible for publication of the cross-certificate 298 created by the responding CA through use of the PKIPublicationInfo 299 control. 301 * In-band initialization using an external identity certificate 302 (this PKI management operation may also enroll up to two 303 certificates and requires use of certConf/pkiConf messages for 304 confirmation as specified in Appendix D of RFC 4210 [RFC4210]). 305 An (uninitialized) end entity wishes to initialize into the PKI 306 with a CA, CA-1. It uses, for authentication purposes, a pre- 307 existing identity certificate issued by another (external) CA, CA- 308 X. A trust relationship must already have been established 309 already between CA-1 and CA-X so that CA-1 can validate the EE's 310 identity certificate signed by CA-X. Furthermore, some mechanism 311 must already have been established within the Personal Security 312 Environment (PSE) of the EE enabling it to authenticate and verify 313 PKIMessages signed by CA-1. The content is similar to the PKI 314 management operation specified in Section 4.1.1 of this document. 316 Both these Appendixes D and E focus on EE-to-CA/RA PKI management 317 operations and do not address further profiling of RA to CA 318 communication as typically needed for full backend automation. 320 3GPP makes use of CMP [RFC4210] in its Technical Specification 33.310 321 [ETSI-3GPP.33.310] for automatic management of IPSec certificates in 322 3G, LTE, and 5G backbone networks. Since 2010 a dedicated CMP 323 profile for initial certificate enrollment and certificate update 324 operations between EE and RA/CA is specified in that document. 326 UNISIG has included a CMP profile for certificate enrollment in the 327 subset 137 specifying the ETRAM/ECTS on-line key management for train 328 control systems [UNISIG.Subset-137] in 2015. 330 Both standardization bodies use CMP [RFC4210], CRMF [RFC4211], and 331 HTTP transfer for CMP [RFC6712] to add tailored means for automated 332 PKI management operations for unattended devices and services. 334 1.4. Compatibility with existing CMP profiles 336 The profile specified in this document is compatible with RFC 4210 337 Appendixes D and E (PKI Management Message Profiles) [RFC4210], with 338 the following exceptions: 340 * signature-based protection is the default protection; an initial 341 PKI management operation may also use MAC-based protection, 343 * certification of a second key pair within the same PKI management 344 operation is not supported, 346 * proof-of-possession (POPO) with self-signature of the certTemplate 347 according to RFC 4210 Section 4.1 [RFC4210] clause 3 is the 348 recommended default POPO method (deviations are possible for EEs 349 when requesting central key generation, for (L)RAs when using 350 raVerified, and if the newly generated keypair is technically not 351 capable to generate digital signatures), 353 * confirmation of newly enrolled certificates may be omitted, and 355 * all PKI management operations consist of request-response message 356 pairs originating at the EE, i.e., announcement messages 357 (requiring the push model) are omitted. 359 The profile specified in this document is compatible with the CMP 360 profile for 3G, LTE, and 5G network domain security and 361 authentication framework [ETSI-3GPP.33.310], except that: 363 * protection of initial PKI management operations may be MAC-based, 365 * the subject field is mandatory in certificate templates, and 367 * confirmation of newly enrolled certificates may be omitted. 369 The profile specified in this document is compatible with the CMP 370 profile for on-line key management in rail networks as specified in 371 UNISIG Subset-137 [UNISIG.Subset-137], except that: 373 * A certificate enrollment request message consists of only one 374 certificate request (CertReqMsg). As UNISIG Subset-137 Table 6 375 [UNISIG.Subset-137] allows to transport more than one certificate 376 request message, this conflicts with this document. 378 * As of RFC 4210 [RFC4210] the messageTime is required to be 379 Greenwich Mean Time coded as generalizedTime As UNISIG Subset-137 380 Table 5 [UNISIG.Subset-137] explicitly states that the messageTime 381 in required to be 'UTC time', it is not clear if this means a 382 coding as UTCTime or generalizedTime and if other time zones than 383 Greenwich Mean Time shall be allowed. Therefore, UNISIG 384 Subset-137 [UNISIG.Subset-137] may conflict with RFC 4210 385 [RFC4210]. Both time formats are described in RFC 5280 386 Section 4.1.2.5 [RFC5280]. 388 * This profile requires usage of the same type of protection for all 389 messages of one PKI management operation. This means, in case the 390 request message is MAC protected, also the response, certConf, and 391 pkiConf messages have a MAC-based protection. As UNISIG 392 Subset-137 Table 5 [UNISIG.Subset-137] specifies for the first 393 certificate request MAC protection for all messages send by the 394 client and signature protection for all messages send by the 395 server, this conflicts with this document. 397 * Use of caPubs is not required but typically allowed in combination 398 with MAC-based protected PKI management operations. On the other 399 hand UNISIG Subset-137 Table 12 [UNISIG.Subset-137] requires using 400 caPubs. Note that in case the protection of the response is 401 changed to signature-based protection using a certificate issued 402 under the root CA that is to be transported in the caPubs field, 403 this is not a secure delivery of the root CA certificate. 405 * This profile requires that the certConf message has one CertStatus 406 element where the statusInfo field is recommended. In contrast, 407 UNISIG Subset-137 Table 18 [UNISIG.Subset-137] requires that the 408 certConf message has one CertStatus element where the statusInfo 409 field must be absent. This precludes sending a negative certConf 410 message in case the EE rejects the newly enrolled certificate. 411 This results in violating the general rule that a certificate 412 request transaction must include a certConf message (since 413 moreover using implicitConfirm is not allowed there, neither). 415 1.5. Scope of this document 417 This document specifies requirements on generating PKI management 418 messages on the sender side. It does not specify strictness of 419 verification on the receiving side and how in detail to handle error 420 cases. 422 Especially on the EE side this profile aims at a lightweight 423 implementation. This means that the number of PKI management 424 operations that implementations must support are reduced to a 425 reasonable minimum to support most typical certificate management use 426 cases in industrial machine-to-machine environments. On the EE side 427 only limited resources are expected, while on the side of the PKI 428 management entities the profile accepts higher resources needed. 430 For the sake of robustness and preservation of security properties 431 implementations should, as far as security is not affected, adhere to 432 Postel's law: "Be conservative in what you do, be liberal in what you 433 accept from others" (often reworded as: "Be conservative in what you 434 send, be liberal in what you accept"). 436 When in Section 3, Section 4, and Section 5 a field of the ASN.1 437 syntax as defined in RFC 4210 [RFC4210] and RFC 4211 [RFC4211] is not 438 explicitly specified, it SHOULD not be used by the sending entity. 439 The receiving entity MUST NOT require its absence and if present MUST 440 gracefully handle its presence. 442 1.6. Structure of this document 444 Section 2 introduces the general PKI architecture and approach to 445 certificate management using CMP that is assumed in this document. 446 Then it enlists the PKI management operations specified in this 447 document and describes them in general words. The list of supported 448 PKI management operations is divided into mandatory, recommended, and 449 optional ones. 451 Section 3 profiles the CMP message header, protection, and extraCerts 452 fields as they are general elements of CMP messages. 454 Section 4 profiles the exchange of CMP messages between an EE and the 455 first PKI management entity. There are various flavors of 456 certificate enrollment requests, optionally with polling, revocation, 457 error handling, and general support PKI management operations. 459 Section 5 profiles the message exchange between PKI management 460 entities. In the first place this consists of forwarding messages 461 coming from or going to an EE. This may include delayed delivery of 462 messages, which involves polling for certificate responses. 463 Additionally, it specifies operations where a PKI management entity 464 manages certificates on behalf of an EE or for itself. 466 Section 6 outlines several mechanisms for CMP message transfer, 467 namely HTTP-based transfer as already specified in RFC 6712 468 [RFC6712], using an additional TLS layer, or offline file-based 469 transport. CoAP [RFC7252] and piggybacking CMP messages 471 1.7. Convention and Terminology 473 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 474 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 475 document are to be interpreted as described in BCP 14 [RFC2119] 476 [RFC8174] when, and only when, they appear in all capitals, as shown 477 here. 479 Technical terminology is used in conformance with RFC 4210 [RFC4210], 480 RFC 4211 [RFC4211], RFC 5280 [RFC5280], and IEEE 802.1AR 481 [IEEE.802.1AR_2018]. The following key words are used: 483 CA: Certification authority, which issues certificates. 485 RA: Registration authority, an optional PKI component to which a CA 486 delegates certificate management functions such as 487 authorization checks. 489 LRA: Local registration authority, an optional RA system component 490 with proximity to the end entities. 492 KGA: Key generation authority, an optional system component, 493 typically co-located with an LRA, RA, or CA, that offers key 494 generation services to end entities. 496 EE: End entity, a user, device, or service that holds public- 497 private key pair for which it manages a public-key certificate. 498 An identifier for the EE is given as the subject of its 499 certificate. 501 The following terminology is reused from RFC 4210 [RFC4210] and used 502 as follows: 504 PKI management operation: All CMP messages belonging to one 505 transaction context. The transaction is 506 identified in the transactionID field of 507 the message header. 509 PKI management entity: All non-EE PKI entities such as LRA, RA, 510 and CA. 512 PKI entity: EEs and PKI management entities 514 2. Architecture and use cases 515 2.1. Solution architecture 517 In order to facilitate secure automatic certificate enrollment if the 518 device hosting an EE is equipped with a manufacturer issued 519 certificate during production. Such a manufacturer issued 520 certificate is installed during production to identify the device 521 throughout its lifetime. This manufacturer certificate can be used 522 to protect the initial enrollment of operational certificates after 523 installation of the EE on site in its operational environment. An 524 operational certificate is issued by the owner or operator of the 525 device to identify the device during operation for use, e.g., in a 526 security protocol like IPSec, TLS, or SSH. In IEEE 802.1AR 527 [IEEE.802.1AR_2018] a manufacturer certificate is called IDevID 528 certificate and an operational certificate is called LDevID 529 certificate. 531 Note: According to IEEE 802.1AR [IEEE.802.1AR_2018] a DevID comprises 532 the triplet of the certificate and the corresponding private key as 533 well as certificate chain up to the root certificate. 535 All certificate management transactions specified in this document 536 are initiated by the EE. The EE creates a CMP request message, 537 protects it using some asymmetric credential or shared secret 538 information, as far as available, and sends it to its locally 539 reachable PKI component. This PKI component may be an LRA, RA, or 540 the CA, which checks the request, responds to it itself, or forwards 541 the request upstream to the next PKI component. In case an (L)RA 542 changes the CMP request message header or body or wants to prove a 543 successful verification or authorization, it can apply a protection 544 of its own. Especially the communication between an LRA and RA can 545 be performed synchronously or asynchronously. Synchronous 546 communication describes a timely uninterrupted communication between 547 two communication partners, while asynchronous communication is not 548 performed in a timely consistent manner, e.g., because of a delayed 549 message delivery. 551 +-----+ +-----+ +-----+ +-----+ 552 | | | | | | | | 553 | EE |<---------->| LRA |<-------------->| RA |<---------->| CA | 554 | | | | | | | | 555 +-----+ +-----+ +-----+ +-----+ 557 synchronous (a)synchronous (a)synchronous 558 +----connection----+------connection------+----connection----+ 560 on site at operators service partner 561 +----------plant---------+-----backend services-----+-trust center-+ 562 Figure 1: Certificate management on site 564 In operation environments a layered LRA-RA-CA architecture can be 565 deployed, e.g., with LRAs bundling requests from multiple EEs at 566 dedicated locations and one (or more than one) central RA aggregating 567 the requests from multiple LRAs. Every (L)RA in this scenario 568 typically has a shared secret information (one per EE) for password- 569 based protection or a CMP protection key and certificate containing 570 an extended key usage as specified in CMP Updates 571 [I-D.ietf-lamps-cmp-updates] allowing it to protect CMP messages it 572 processes. The figure above shows an architecture using one LRA and 573 one RA. It is also possible to have only an RA or multiple LRAs and/ 574 or RAs. Depending on the network infrastructure, the message 575 transfer between PKI management entities may be based on synchronous 576 online connections, delayed asynchronous connections, or even offline 577 (e.g., file-based) transfer. 579 This profile focusses on specifying the pull model, where the EE 580 always requests a specific PKI management operation. 582 Note: CMP response messages, especially in case of central key 583 generation, as described in Section 4.1.6, could also be used 584 proactively to implement the push model towards the EE. 586 Third-party CAs typically implement other variants of CMP, different 587 standardized protocols, or even proprietary interfaces for 588 certificate management. Therefore, the LRA or the RA may need to 589 adapt the exchanged CMP messages to the flavor of certificate 590 management interaction required by the CA. 592 2.2. Basic generic CMP message content 594 Section 3 specifies the generic parts of the CMP messages as used 595 later in Section 4 and Section 5. 597 * Header of a CMP message; see Section 3.1. 599 * Protection of a CMP message; see Section 3.2. 601 * ExtraCerts field of a CMP message; see Section 3.3. 603 2.3. Supported PKI management operations 605 Following the scope outlined in Section 1.5, this section gives a 606 brief overview of the PKI management operations specified in 607 Section 4 and Section 5 and states whether implementation by 608 compliant EE or PKI management entities is mandatory, recommended, or 609 optional. 611 2.3.1. Mandatory PKI management operations 613 The mandatory PKI management operations in this document limit the 614 overhead of certificate management. This minimal set of operations 615 may be helpful for keeping development effort low and for use in 616 memory-constrained devices. 618 +=======================================+=========+ 619 | PKI management operations | Section | 620 +=======================================+=========+ 621 | Request a certificate from a new PKI | Section | 622 | with signature protection | 4.1.1 | 623 +---------------------------------------+---------+ 624 | Request to update an existing | Section | 625 | certificate with signature protection | 4.1.3 | 626 +---------------------------------------+---------+ 627 | Error reporting | Section | 628 | | 4.3 | 629 +---------------------------------------+---------+ 631 Table 1: Mandatory End Entity PKI management 632 operations 634 +===============================================+===============+ 635 | PKI management operations | Section | 636 +===============================================+===============+ 637 | Forward messages without changes | Section 5.1.1 | 638 +-----------------------------------------------+---------------+ 639 | Forward messages with replaced protection and | Section | 640 | keeping the original proof-of-possession | 5.1.2.1 | 641 +-----------------------------------------------+---------------+ 642 | Forward messages with replaced protection and | Section | 643 | setting raVerified as proof-of-possession | 5.1.2.2 | 644 +-----------------------------------------------+---------------+ 645 | Error reporting | Section 5.3 | 646 +-----------------------------------------------+---------------+ 648 Table 2: Mandatory LRA and RA PKI management operations 650 2.3.2. Recommended PKI management operations 652 Additional recommended PKI management operations shall support some 653 more complex scenarios, that are considered beneficial for 654 environments with more specific boundary conditions. 656 +======================================================+=========+ 657 | PKI management operations | Section | 658 +======================================================+=========+ 659 | Request a certificate from a PKI with MAC protection | Section | 660 | | 4.1.4 | 661 +------------------------------------------------------+---------+ 662 | Revoke a certificate of its own | Section | 663 | | 4.2 | 664 +------------------------------------------------------+---------+ 666 Table 3: Recommended End Entity PKI management operations 668 +========================================+=============+ 669 | PKI management operations | Section | 670 +========================================+=============+ 671 | Revoke a certificate of another entity | Section 5.2 | 672 +----------------------------------------+-------------+ 674 Table 4: Recommended LRA and RA PKI management 675 operations 677 2.3.3. Optional PKI management operations 679 The optional PKI management operations support specific requirements 680 seen only in some environments with special requirements. 682 +========================================================+=========+ 683 | PKI management operations | Section | 684 +========================================================+=========+ 685 | Request a certificate from a trusted PKI with | Section | 686 | signature protection | 4.1.2 | 687 +--------------------------------------------------------+---------+ 688 | Request a certificate from a legacy PKI using a | Section | 689 | PKCS#10 [RFC2986] request | 4.1.5 | 690 +--------------------------------------------------------+---------+ 691 | Add central generation of a key pair to a certificate | Section | 692 | request. (If central key generation is supported, the | 4.1.6 | 693 | key agreement key management technique is REQUIRED to | | 694 | be supported, and the key transport and password-based | | 695 | key management techniques are OPTIONAL.) | | 696 +--------------------------------------------------------+---------+ 697 | Handle delayed enrollment due to asynchronous or | Section | 698 | offline message delivery | 4.1.7 | 699 +--------------------------------------------------------+---------+ 700 | Additional support messages - distribution of CA | Section | 701 | certificates, update of a root CA certificate and | 4.4 | 702 | provisioning of certificate request template | | 703 +--------------------------------------------------------+---------+ 705 Table 5: Optional End Entity PKI management operations 707 +=============================================+===============+ 708 | PKI management operations | Section | 709 +=============================================+===============+ 710 | Forward messages with additional protection | Section 5.1.3 | 711 +---------------------------------------------+---------------+ 712 | Initiate delayed enrollment due to | Section 5.1.4 | 713 | asynchronous or offline message delivery | | 714 +---------------------------------------------+---------------+ 716 Table 6: Optional LRA and RA PKI management operations 718 2.4. CMP message transport 720 On different links between PKI entities, e.g., EE-RA and RA-CA, 721 different transport MAY be used. As CMP does not have specific needs 722 regarding message transport, virtually any reliable transport 723 mechanism may be used, e.g., HTTP, CoAP, and offline file-based 724 transport. Therefore, this document does not require any specific 725 transport protocol to be supported by conforming implementations. 727 HTTP transfer is RECOMMENDED to use for all PKI entities, yet full 728 flexibility is retained to choose whatever transport is suitable, for 729 instance for devices with special constraints. 731 +==================================+=============+ 732 | Transport | Section | 733 +==================================+=============+ 734 | Transfer CMP messages using HTTP | Section 6.1 | 735 +----------------------------------+-------------+ 737 Table 7: Recommended transport mechanisms 739 +========================================+=========+ 740 | Transport | Section | 741 +========================================+=========+ 742 | Transfer CMP messages using HTTPS with | Section | 743 | certificate-based authentication | 6.2 | 744 +----------------------------------------+---------+ 745 | Transfer CMP messages using HTTPS with | Section | 746 | shared secret-based authentication | 6.3 | 747 +----------------------------------------+---------+ 748 | Offline CMP message transport | Section | 749 | | 6.4 | 750 +----------------------------------------+---------+ 751 | Transfer CMP messages using CoAP | Section | 752 | | 6.5 | 753 +----------------------------------------+---------+ 755 Table 8: Optional transport mechanisms 757 3. Generic parts of the PKI message 759 The generic parts of the CMP message profiles specified in Section 4 760 and Section 5 are standardized to the maximum extent possible and are 761 described centrally in this section to reduce redundancy in the 762 description and to ease implementation. 764 As described in section 5.1 of [RFC4210], all CMP messages have the 765 following general structure: 767 +--------------------------------------------+ 768 | PKIMessage | 769 | +----------------------------------------+ | 770 | | header | | 771 | +----------------------------------------+ | 772 | +----------------------------------------+ | 773 | | body | | 774 | +----------------------------------------+ | 775 | +----------------------------------------+ | 776 | | protection (OPTIONAL) | | 777 | +----------------------------------------+ | 778 | +----------------------------------------+ | 779 | | extraCerts (OPTIONAL) | | 780 | +----------------------------------------+ | 781 +--------------------------------------------+ 783 Figure 2: CMP message structure 785 The general contents of the message header, protection, and 786 extraCerts fields are specified in the following subsections. 788 In case a specific CMP message profile needs different contents in 789 the header, protection, or extraCerts fields, the differences are 790 described in the respective message profile. 792 The CMP message body contains the message-specific information. It 793 is described as part Section 4 and Section 5. 795 The behavior in case an error occurs while handling the generic parts 796 of a CMP message is described in Section 5.3. 798 3.1. General description of the CMP message header 800 This section describes the generic header field of all CMP messages 801 with signature-based protection. The only variations described here 802 are in the recipient, transactionID, and recipNonce fileds of the 803 first message of a PKI management operation. 805 In case a message has MAC-based protection the changes are described 806 in Section 4.1.4. The variations will affect the fields sender, 807 protectionAlg, and senderKID. 809 For requirements regarding proper random number generation please 810 refer to [RFC4086]. Any message-specific fields or variations are 811 described in Section 4 and Section 5. 813 header 814 pvno REQUIRED 815 -- MUST be set to 3 to indicate CMP V3 in all cases where 816 -- EnvelopedData is supported and expected to be used in this PKI 817 -- management operation 818 -- MUST be set to 2 to indicate CMP V2 in all other cases 819 -- For details on version negotiation see RFC-CMP-Updates 820 sender REQUIRED 821 -- MUST contain a name representing the originator of the message 822 -- SHOULD be the subject of the CMP protection certificate, i.e., 823 -- the certificate for the private key used to sign the message 824 recipient REQUIRED 825 -- SHOULD be the name of the intended recipient and 826 -- MAY be a NULL-DN, i.e., a zero-length SEQUENCE OF 827 -- RelativeDistinguishedNames, if the sender does not know the 828 -- DN of the recipient 829 -- If this is the first message of a transaction: SHOULD be the 830 -- subject of the issuing CA certificate 831 -- In all other messages: SHOULD be the same name as in the 832 -- sender field of the previous message in the same transaction 833 messageTime RECOMMENDED 834 -- MUST be the time at which the message was produced, if 835 -- present 836 protectionAlg REQUIRED 837 -- MUST be the algorithm OID of the algorithm used for 838 -- calculating the protection bits 839 -- The signature algorithm MUST be a MSG_SIG_ALG as specified in 840 -- RFC-CMP-Alg Section 3 and MUST be consistent with the 841 -- subjectPublicKeyInfo field of the protection certificate 842 -- The MAC algorithm MUST be a MSG_MAC_ALG as specified in 843 -- RFC-CMP-Alg Section 6 844 algorithm REQUIRED 845 -- MUST be the OID of the signature or MAC algorithm 846 senderKID RECOMMENDED 847 -- MUST be the SubjectKeyIdentifier of the CMP protection 848 -- certificate or a reference of the shared secret information 849 -- used for the protection 850 transactionID REQUIRED 851 -- If this is the first message of a transaction: 852 -- MUST be 128 bits of random data for the start of a 853 -- transaction, to minimize the probability of having the 854 -- transactionID already in use at the server 855 -- In all other messages: 856 -- MUST be the value from the previous message in the same 857 -- transaction 858 senderNonce REQUIRED 859 -- MUST be cryptographically secure and fresh 128 random bits 860 recipNonce RECOMMENDED 861 -- If this is the first message of a transaction: SHOULD be 862 -- absent 863 -- In all other messages: MUST be present and contain the value 864 -- of the senderNonce of the previous message in the same 865 -- transaction 866 generalInfo OPTIONAL 867 implicitConfirm OPTIONAL 868 -- The field is optional in ir/cr/kur/p10cr requests and 869 -- ip/cp/kup response messages and PROHIBTED in other types of 870 -- messages 871 -- Added to request messages to request omission of the certConf 872 -- message 873 -- See [RFC4210] Section 5.1.1.1. 874 -- Added to response messages to grant omission of the certConf 875 -- message 876 ImplicitConfirmValue REQUIRED 877 -- ImplicitConfirmValue of the request message MUST be NULL if 878 -- the EE wants to request not to send a confirmation message 879 -- ImplicitConfirmValue MUST be NULL if the PKI management 880 -- entity wants to grant not sending a confirmation message 882 3.2. General description of the CMP message protection 884 This section describes the generic protection field of all CMP 885 messages with signature-based protection. The certificate for the 886 private key used to sign a CMP message is called 'protection 887 certificate'. Any included keyUsage extension SHOULD allow 888 digitalSignature. 890 protection RECOMMENDED 891 -- MUST contain the signature calculated using the private key 892 -- of the entity protecting the message. The signature 893 -- algorithm used MUST be given in the protectionAlg field. 895 Generally, CMP message protection is required for CMP messages, but 896 there are cases where protection of error messages as specified in 897 Section 4.3 and Section 5.3 is not possible and therefore MAY be 898 omitted. 900 For MAC-based protection as specified in Section 4.1.4 major 901 differences apply as described in the respective section. 903 The CMP message protection provides, if available, message origin 904 authentication and integrity protection for the CMP message header 905 and body. The CMP message extraCerts field is not covered by this 906 protection. 908 Note: The extended key usages specified in CMP Updates 909 [I-D.ietf-lamps-cmp-updates] can be used for authorization of a 910 sending PKI management entity. 912 Note: The requirements for checking certificates given in [RFC5280] 913 MUST be the followed for signature-based CMP message protection. In 914 case the CMP protection certificate is not the CA certificate that 915 signed the newly issued certificate, certificate status checking 916 SHOULD be used for the CMP protection certificates of communication 917 partners. 919 3.3. General description of CMP message extraCerts 921 This section describes the generic extraCerts field of all CMP 922 messages with signature-based protection. If extraCerts are 923 required, recommended, or optional is specified in the respective PKI 924 management operation. 926 extraCerts 927 -- SHOULD contain the CMP protection certificate together with 928 -- its chain, if needed and the self-signed root certificate 929 -- SHOULD be omitted 930 -- If present, the first certificate in this field MUST be 931 -- the CMP protection certificate and each followed by its chain 932 -- where each element SHOULD directly certify the one 933 -- immediately preceding it. 934 -- Self-signed certificates SHOULD be omitted from extraCerts, 935 -- unless they are the same as the protection certificate and 936 -- MUST NOT be trusted based on their inclusion in any case 938 Note: For maximum compatibility, all implementations SHOULD be 939 prepared to handle potentially additional certificates and arbitrary 940 orderings of the certificates. 942 4. End Entity PKI management operations 944 This chapter focuses on the communication of the EE with the PKI 945 management entity it immediately talks to. Depending on the network 946 and PKI solution, this can be an LRA, RA, or directly a CA. 948 The PKI management operations specified in this section cover the 949 following: 951 * Requesting a certificate from a PKI with variations like initial 952 enrollment and updates, central key generation, and various 953 protection mechanisms 955 * Revocation of a certificate 957 * General messages for further support functions 959 These operations mainly specify the message body of the CMP messages 960 and utilize the specification of the message header, protection and 961 extraCerts as specified in Section 4. 963 The behavior in case an error occurs is described in Section 4.3. 965 This section is aligned with RFC 4210 [RFC4210]. The general rules 966 for interpretation stated in Appendix D.1 of RFC 4210 [RFC4210] shall 967 be applied here, too. 969 Guidelines as well as an algorithm use profile for this document are 970 available in CMP Algorithms [draft-ietf-lamps-cmp-algorithms]. 972 4.1. Requesting a new certificate from a PKI 974 There are various approaches for requesting a certificate from a PKI. 976 These approaches differ in the way the EE authenticates itself to the 977 PKI and in the way that the key pair to be certified is generated. 978 The authentication mechanisms may be as follows: 980 * Using a certificate from a trusted PKI and the corresponding 981 private key, e.g., a manufacturer issued certificate 983 * Using the certificate to be updated and the corresponding private 984 key 986 * Using shared secret information known to the EE and the PKI 988 An EE requests a certificate indirectly or directly from a CA. When 989 the PKI management entity responds with a message containing the 990 requested certificate, the EE MUST reply with a confirmation message. 991 The PKI management entity then MUST respond with a confirmation, 992 closing the transaction. 994 The message sequences in this section allow the EE to request 995 certification of a locally generated public-private key pair. For 996 requirements regarding proper random number and key generation please 997 refer to [RFC4086]. The EE SHOULD provide a signature-based proof- 998 of-possession of the private key associated with the public key 999 contained in the certificate request as defined by RFC 4211 1000 Section 4.1 [RFC4211] case 3. To this end it is assumed that the 1001 private key can technically be used for signing. This is the case 1002 for the most commonly used algorithms RSA and ECDSA, regardless of 1003 potentially intended restrictions of the key usage. 1005 Note: In conformance with NIST SP 800-57 Part 1 Section 8.1.5.1.1.2 1006 [NIST.SP.800-57p1r5] the newly generated private key MAY be used for 1007 self-signature, if technically possible, even if the keyUsage 1008 extension requested in the certificate request prohibits generation 1009 of digital signatures. 1011 The requesting EE provides the binding of the proof-of-possession to 1012 its identity by signature-based or MAC-based protection of the CMP 1013 request message containing that POPO. As will be detailed in 1014 Section 5.1.2, the targeted PKI management entity should verify 1015 whether this EE is authorized to obtain a certificate with the 1016 requested subject and other fields and extensions. Especially when 1017 removing the protection provided by the EE and applying a new 1018 protection, the PKI management entity MUST verify in particular the 1019 included proof-of-possession self-signature of the certTemplate or 1020 the PKCS#10 certificationRequestInfo using the public key of the 1021 requested certificate and MUST check that the EE, as authenticated by 1022 the message protection, is authorized to request a certificate with 1023 the subject as specified in the certTemplate. 1025 When an EE verifies the protection of a response message with 1026 signature-based protection it needs a trust anchor to verify the 1027 protection certificate. There are several ways to install the Root 1028 CA certificate of a new PKI on an EE. The installation can be 1029 performed in an out-of-band manner, using general messages, a voucher 1030 [RFC8366], or other formats for enrollment, or in-band of CMP by the 1031 caPubs field in the certificate response message. In case the 1032 installation of the new root CA certificate is performed using the 1033 caPubs field, the certificate response message MUST be properly 1034 authenticated, and the sender of this message MUST be authorized to 1035 install new root CA certificates on the EE. This authorization is 1036 typically indicated by using shared secret information, but it can 1037 also be indicated by using a private key with a certificate issued by 1038 another PKI authorized for this purpose, for the CMP message 1039 protection. 1041 4.1.1. Requesting a certificate from a new PKI with signature 1042 protection 1044 This PKI management operation should be used by an EE to request a 1045 certificate from a new PKI using an existing certificate from an 1046 external PKI, e.g., a manufacturer-issued IDevID certificate 1047 [IEEE.802.1AR_2018], to authenticate itself to the new PKI. The EE 1048 already has established trust in this new PKI it is about to enroll 1049 to, e.g., by voucher exchange or configuration means. The 1050 certificate request message is signature-protected using the existing 1051 certificate from the external PKI. 1053 Preconditions: 1055 1 The EE MUST have a certificate enrolled by an external PKI in 1056 advance to this PKI management operation to authenticate itself to 1057 the PKI management entity using signature-based protection, e.g., 1058 using a manufacturer issued certificate. 1060 2 The EE SHOULD know the subject name of the new CA it requests a 1061 certificate from; this name MAY be established using an enrollment 1062 voucher, the issuer field from a CertReqTemplate response message, 1063 or other configuration means. If the EE does not know the name of 1064 the CA, the PKI management entity MUST know where to route these 1065 requests to. 1067 3 The EE MUST authenticate responses from the PKI management entity; 1068 trust MAY be established using an enrollment voucher or other 1069 configuration means. 1071 4 The PKI management entity MUST trust the external PKI the EE uses 1072 to authenticate itself; trust MAY be established using some 1073 configuration means. 1075 The general message flow for this PKI management operation is like 1076 that given in RFC 4210 Appendix E.7 [RFC4210]. 1078 Message flow: 1080 Step# EE PKI management entity 1081 1 format ir 1082 2 -> ir -> 1083 3 handle, re-protect or 1084 forward ir 1085 4 format or receive ip 1086 5 possibly grant implicit 1087 confirm 1088 6 <- ip <- 1089 7 handle ip 1090 8 In case of status 1091 "rejection" in the 1092 ip message, no certConf 1093 and pkiConf are sent 1094 9 format certConf (optional) 1095 10 -> certConf -> 1096 11 handle, re-protect or 1097 forward certConf 1098 12 format or receive pkiConf 1099 13 <- pkiconf <- 1100 14 handle pkiConf (optional) 1102 For this PKI management operation, the EE MUST include exactly one 1103 single CertReqMsg in the ir. If more certificates are required, 1104 further requests MUST be sent using separate PKI management 1105 operation. If the EE wants to omit sending a certificate 1106 confirmation message after receiving the ip, e.g., to reduce the 1107 number of protocol messages exchanged in this PKI management 1108 operation, it MUST request this by including the implicitConfirm 1109 extension in the header of the ir message, see Section 3.1. 1111 If the request was accepted and a new certificate was issued by the 1112 CA, the PKI management entity MUST return the new certificate in the 1113 certifiedKeyPair field of the ip message. If the EE requested 1114 omission of the certConf message, the PKI management entity MAY grant 1115 this by including the implicitConfirm extension, else this is 1116 rejected by not including the implicitConfirm field in the ip 1117 message. 1119 If the EE did not request implicit confirmation or the request was 1120 not granted by the PKI management entity, certificate confirmation 1121 MUST be performed as follows. If the EE successfully received the 1122 certificate and accepts it, the EE MUST send a certConf message, 1123 which the PKI management entity must respond using a pkiConf message. 1124 If the PKI management entity does not receive the expected certConf 1125 message in time it MUST handle this like a rejection by the EE. In 1126 this case the PKI management entity SHALL terminate the PKI 1127 management operation. The PKI MAY revoke the newly issued 1128 certificates depending on the local policy. 1130 If the certificate request was rejected by the CA, the PKI management 1131 entity must return an ip message containing the status code 1132 "rejection" as described in Section 5.3 and no certifiedKeyPair 1133 field. The EE MUST NOT react to such an ip message with a certConf 1134 message and the PKI management operation MUST be terminated. 1136 Detailed message description: 1138 Certification Request -- ir 1140 Field Value 1142 header 1143 -- As described in Section 3.1 1145 body 1146 -- The request of the EE for a new certificate 1147 ir REQUIRED 1148 -- MUST be exactly one CertReqMsg 1149 -- If more certificates are required, further requests MUST be 1150 -- packaged in separate PKI Messages 1151 certReq REQUIRED 1152 certReqId REQUIRED 1153 -- MUST be set to 0 1154 certTemplate REQUIRED 1155 version OPTIONAL 1156 -- MUST be 2 if supplied. 1157 subject REQUIRED 1158 -- The EE subject name MUST be carried in the subject field 1159 -- and/or the subjectAltName extension. 1160 -- If subject name is present only in the subjectAltName 1161 -- extension, then the subject field MUST be a NULL-DN 1162 publicKey REQUIRED 1163 algorithm REQUIRED 1164 -- MUST include the subject public key algorithm OID and valueany 1165 -- parameters 1166 -- In case a central key generation is requested, this field 1167 -- contains the algorithm and parameter preferences of the 1168 -- requesting entity regarding the to-be-generated key pair 1169 subjectPublicKey REQUIRED 1170 -- MUST contain the public key to be certified in case of 1171 -- local key generation 1172 -- MUST contain a zero-length BIT STRING in case a central key 1173 -- generation is requested 1174 extensions OPTIONAL 1175 -- MAY include end-entity-specific X.509 extensions of the 1176 -- requested certificate like subject alternative name, 1177 -- key usage, and extended key usage 1178 -- The subjectAltName extension MUST be present if the EE 1179 -- subject name includes a subject alternative name. 1180 Popo REQUIRED 1181 POPOSigningKey OPTIONAL 1182 -- MUST be used in case subjectPublicKey contains a public key 1183 -- MUST be absent in case subjectPublicKey contains a 1184 -- zero-length BIT STRING 1185 poposkInput PROHIBITED 1186 -- MUST NOT be used; it is not needed because subject and 1187 -- publicKey are both present in the certTemplate 1188 algorithmIdentifier REQUIRED 1189 -- The signature algorithm MUST be consistent with the 1190 -- publicKey field of the certTemplate 1191 signature REQUIRED 1192 -- MUST be the signature computed over the DER-encoded 1193 -- certTemplate 1195 protection REQUIRED 1196 -- As described in Section 3.2 1198 extraCerts REQUIRED 1199 -- As described in Section 3.3 1201 Certification Response -- ip 1203 Field Value 1205 header 1206 -- As described in Section 3.1 1208 body 1209 -- The response of the CA to the request as appropriate 1210 ip REQUIRED 1211 caPubs OPTIONAL 1212 -- MAY be used 1213 -- If used it MUST contain only the root certificate of the 1214 -- certificate contained in certOrEncCert 1215 response REQUIRED 1216 -- MUST be exactly one CertResponse 1217 certReqId REQUIRED 1218 -- MUST be set to 0 1219 status REQUIRED 1220 -- PKIStatusInfo structure MUST be present 1221 status REQUIRED 1222 -- positive values allowed: "accepted", "grantedWithMods" 1223 -- negative values allowed: "rejection" 1224 statusString OPTIONAL 1225 -- MAY be any human-readable text for debugging, logging or to 1226 -- display in a GUI 1227 failInfo OPTIONAL 1228 -- MUST be present if status is "rejection" 1229 -- MUST be absent if the status is "accepted" or 1230 -- "grantedWithMods" 1231 certifiedKeyPair OPTIONAL 1232 -- MUST be present if status is "accepted" or "grantedWithMods" 1233 -- MUST be absent if status is "rejection" 1234 certOrEncCert REQUIRED 1235 -- MUST be present when certifiedKeyPair is present 1236 certificate REQUIRED 1237 -- MUST be present when certifiedKeyPair is present 1238 -- MUST contain the newly enrolled X.509 certificate 1239 privateKey OPTIONAL 1240 -- MUST be absent in case of local key-generation 1241 -- MUST contain the encrypted private key in an EnvelopedData 1242 -- structure as specified in section 5.1.5 in case the private 1243 -- key was generated centrally 1245 protection REQUIRED 1246 -- As described in Section 3.2 1248 extraCerts REQUIRED 1249 -- As described in Section 3.3 1250 -- MUST contain the chain of the certificate present in 1251 -- certOrEncCert 1252 -- Self-signed root certificate SHOULD be omitted 1253 -- Duplicate certificates MAY be omitted 1255 Certificate Confirmation -- certConf 1257 Field Value 1259 header 1260 -- As described in Section 3.1 1262 body 1263 -- The message of the EE sends confirmation to the PKI 1264 -- management entity to accept or reject the issued certificates 1265 certConf REQUIRED 1266 -- MUST be exactly one CertStatus 1267 CertStatus REQUIRED 1268 certHash REQUIRED 1269 -- MUST be the hash of the certificate, using the same hash 1270 -- algorithm as used to create the certificate signature 1271 certReqId REQUIRED 1272 -- MUST be set to 0 1273 statusInfo RECOMMENDED 1274 -- PKIStatusInfo structure SHOULD be present 1275 -- Omission indicates acceptance of the indicated certificate 1276 status REQUIRED 1277 -- positive values allowed: "accepted" 1278 -- negative values allowed: "rejection" 1279 statusString OPTIONAL 1280 -- MAY be any human-readable text for debugging, logging, or to 1281 -- display in a GUI 1282 failInfo OPTIONAL 1283 -- MUST be present if status is "rejection" 1284 -- MUST be absent if the status is "accepted" 1286 protection REQUIRED 1287 -- As described in Section 3.2 1288 -- MUST use the same certificate as for protecting the ir 1290 extraCerts RECOMMENDED 1291 -- As described in Section 3.3 1292 -- Any certificates in extraCerts MAY be omitted if the message 1293 -- size is critical and the PKI management entity caches the 1294 -- extraCerts from the ir 1296 PKI Confirmation -- pkiconf 1298 Field Value 1300 header 1301 -- As described in Section 3.1 1303 body 1304 pkiconf REQUIRED 1305 -- The content of this field MUST be NULL 1307 protection REQUIRED 1308 -- As described in Section 3.2 1309 -- MUST use the same certificate as for protecting the ip 1311 extraCerts RECOMMENDED 1312 -- As described in Section 3.3 1313 -- Any certificates in extraCerts MAY be omitted if the message 1314 -- size is critical and the EE has cached the extraCerts from the 1315 -- ip 1317 4.1.2. Requesting a certificate from a trusted PKI with signature 1318 protection 1320 This PKI management operation should be used by an EE to request an 1321 additional certificate of the same PKI it already has certificates 1322 from. The EE uses one of these existing certificates to authenticate 1323 itself by signing its request messages using the respective private 1324 key. 1326 The general message flow for this PKI management operation is the 1327 same as given in Section 4.1.1. 1329 Preconditions: 1331 1 The EE MUST have a certificate enrolled by the PKI it requests 1332 another certificate from in advance to this PKI management 1333 operation to authenticate itself to the PKI management entity 1334 using signature-based protection. 1336 2 The EE SHOULD know the subject name of the CA it requests a 1337 certificate from; this name MAY be established using an enrollment 1338 voucher, the issuer field from a CertReqTemplate response message, 1339 or other configuration means. If the EE does not know the name of 1340 the CA, the PKI management entity MUST know where to route this 1341 request to. 1343 3 The EE MUST authenticate responses from the PKI management entity; 1344 trust MAY be established using an enrollment voucher or other 1345 configuration means. 1347 4 The PKI management entity MUST trust the current PKI; trust MAY be 1348 established using some configuration means. 1350 The message sequence for this PKI management operation is like that 1351 given in [RFC4210] Appendix D.5. 1353 The message sequence for this PKI management operation is identical 1354 to that given in Section 4.1.1, with the following changes: 1356 1 The body of the first request and response MUST be cr and cp, 1357 respectively. 1359 2 The caPubs field in the cp message SHOULD be absent. 1361 4.1.3. Updating an existing certificate with signature protection 1363 This PKI management operation should be used by an EE to request an 1364 update for one of its certificates that is still valid. The EE uses 1365 the certificate it wishes to update to authenticate itself and for 1366 proving ownership of the certificate to be updated by signing its 1367 request messages with the corresponding private key. 1369 The general message flow for this PKI management operation is the 1370 same as given in Section 4.1.1. 1372 Preconditions: 1374 1 The certificate the EE wishes to update MUST NOT be expired or 1375 revoked. 1377 2 A new public-private key pair SHOULD be used. 1379 The message sequence for this PKI management operation is like that 1380 given in [RFC4210] Appendix D.6. 1382 The message sequence for this PKI management operation is identical 1383 to that given in Section 4.1.1, with the following changes: 1385 1 The body of the first request and response MUST be kur and kup, 1386 respectively. 1388 2 Protection of the kur MUST be performed using the certificate to 1389 be updated. 1391 3 The subject field and/or the subjectAltName extension of the 1392 CertTemplate MUST contain the EE subject name of the existing 1393 certificate to be updated, without modifications. 1395 4 The CertTemplate SHOULD contain the subject and publicKey of the 1396 EE only. 1398 5 The oldCertId control SHOULD be used to make clear which 1399 certificate is to be updated. 1401 6 The caPubs field in the kup message MUST be absent. 1403 As part of the certReq structure of the kur the oldCertId control is 1404 added right after the certTemplate. 1406 controls 1407 type RECOMMENDED 1408 -- MUST be the value id-regCtrl-oldCertID, if present 1409 value 1410 issuer REQUIRED 1411 serialNumber REQUIRED 1412 -- MUST contain the issuer and serialNumber of the certificate 1413 -- to be updated 1415 4.1.4. Requesting a certificate from a PKI with MAC protection 1417 This PKI management operation should be used by an EE to request a 1418 certificate of a new PKI without having a certificate to prove its 1419 identity to the target PKI, but there is shared secret information 1420 established between the EE and the PKI. Therefore, the 1421 initialization request is MAC-protected using this shared secret 1422 information. The PKI management entity checking the MAC-based 1423 protection SHOULD replace this protection according to Section 5.1.2 1424 in case the next hop does not know the shared secret information. 1426 For requirements regarding proper random number and key generation 1427 please refer to [RFC4086]. 1429 The general message flow for this PKI management operation is the 1430 same as given in Section 4.1.1. 1432 Preconditions: 1434 1 The EE and the PKI management entity MUST share secret 1435 information, this MAY be established by a service technician 1436 during initial local configuration. 1438 2 The EE SHOULD know the subject name of the new CA it requests a 1439 certificate from; this name MAY be established using an enrollment 1440 voucher, the issuer field from a CertReqTemplate response message, 1441 or other configuration means. If the EE does not know the name of 1442 the CA, the PKI management entity MUST know where to route this 1443 request to. 1445 3 The EE MUST authenticate responses from the PKI management entity; 1446 trust is established using the shared secret information. 1448 The message sequence for this PKI management operation is like that 1449 given in [RFC4210] Appendix D.4. 1451 The message sequence for this PKI management operation is identical 1452 to that given in Section 4.1.1, with the following changes: 1454 1 The protection of all messages MUST be calculated using Message 1455 Authentication Code (MAC). 1457 2 The sender MUST contain a name representing the originator of the 1458 message. The senderKID MUST contain a reference all participating 1459 entities can use to identify the shared secret information used 1460 for the protection, e.g., the username of the EE. 1462 3 The extraCerts of the ir, certConf, and pkiConf messages MUST be 1463 absent. 1465 4 The extraCerts of the ip message MUST contain the chain of the 1466 issued certificate and root certificates SHOULD not be included 1467 and MUST NOT be directly trusted in any case. 1469 See Section 6 of CMP Algorithms [I-D.ietf-lamps-cmp-algorithms] for 1470 details on message authentication code algorithms (MSG_MAC_ALG) to 1471 use. Typically, parameters are part of the protectionAlg structure, 1472 e.g., used for key derivation, like a salt and an iteration count. 1473 Such fields SHOULD remain constant for message protection throughout 1474 this PKI management operation to reduce the computational overhead. 1476 4.1.5. Requesting a certificate from a legacy PKI using PKCS#10 request 1478 This PKI management operation can be used by an EE to request a 1479 certificate using a legacy PKCS#10 [RFC2986] request instead of CRMF 1480 [RFC4211]. The EE can prove its identity to the target PKI by using 1481 various protection means as described in Section 4.1.1 or 1482 Section 4.1.4. 1484 This operation should be used only for compatibility reasons if the 1485 other PKI management operations described in Section 4.1 are not 1486 possible, for instance because a legacy component of the EE only 1487 produces PKCS#10 requests or a legacy CA system can handle only 1488 PKCS#10 requests. In such case the PKI management entity MUST 1489 extract the PKCS#10 certificate request from the p10cr and provids it 1490 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 and all further 1494 certificate template date is contained in the subjectPKInfo and other 1495 certificationRequestInfo fields of the PKCS#10 certificate request. 1497 Preconditions: 1499 1 The EE MUST either have a certificate enrolled from this or any 1500 other accepted PKI, or shared secret information known to the PKI 1501 and the EE to authenticate itself to the RA. 1503 2 The EE SHOULD know the subject name of the CA it requests a 1504 certificate from; this name MAY be established using an enrollment 1505 voucher, the issuer field from a CertReqTemplate response message, 1506 or other configuration means. If the EE does not know the name of 1507 the CA, the RA MUST know where to route this request to. 1509 3 The EE MUST authenticate responses from the RA; trust MAY be 1510 established by an available root certificate, using an enrollment 1511 voucher, or other configuration means. 1513 4 The addressed PKI management entity MUST trust the PKI the EE uses 1514 to authenticate itself when using the signature protection; trust 1515 MAY be established by a corresponding available root certificate 1516 or using some configuration means. When using MAC-based 1517 protection the EE and PKI must share secret information. 1519 The message sequence for this PKI management operation is identical 1520 to that given in Section 4.1.1, with the following changes: 1522 1 The body of the first request and response MUST be p10cr and cp, 1523 respectively. 1525 2 The certReqId in the cp message MUST be 0. 1527 3 The caPubs field in the cp message SHOULD be absent. 1529 Detailed description of the p10cr message: 1531 Certification Request -- p10cr 1533 Field Value 1535 header 1536 -- As described in Section 3.1 1538 body 1539 -- The request of the EE for a new certificate using a PKCS#10 1540 -- certificate request 1541 p10cr REQUIRED 1542 certificationRequestInfo REQUIRED 1543 version REQUIRED 1544 -- MUST be set to 0 to indicate PKCS#10 V1.7 1545 subject REQUIRED 1546 -- The EE subject name MUST be carried in the subject field 1547 -- and/or the subjectAltName extension. 1548 -- If subject name is present only in the subjectAltName 1549 -- extension, then the subject field MUST be a NULL-DN 1550 subjectPKInfo REQUIRED 1551 algorithm REQUIRED 1552 -- MUST include the subject public key algorithm ID 1553 subjectPublicKey REQUIRED 1554 -- MUST include the public key to be certified 1555 attributes OPTIONAL 1556 -- MAY include end-entity-specific X.509 extensions of the 1557 -- requested certificate like subject alternative name, 1558 -- key usage, and extended key usage. 1559 -- The subjectAltName extension MUST be present if the EE 1560 -- subject name includes a subject alternative name. 1561 signatureAlgorithm REQUIRED 1562 -- The signature algorithm MUST be consistent with the 1563 -- subjectPKInfo field. 1564 signature REQUIRED 1565 -- MUST containing the self-signature for proof-of-possession 1567 protection REQUIRED 1568 -- As described in Section 3.2 1570 extraCerts REQUIRED 1571 -- As described in Section 3.3 1573 4.1.6. Generateing the key pair centrally at the PKI management entity 1575 This functional extension can be applied in combination with 1576 certificate enrollment as described in Section 4.1.1, Section 4.1.2, 1577 and Section 4.1.4. The functional extension can be used in case an 1578 EE is not able to generate its new public-private key pair itself or 1579 central generation the EE key material is preferred. It is a matter 1580 of the local implementation which PKI management entity will act as 1581 Key Generation Authority (KGA) and perform the key generation. This 1582 PKI management entity MUST have a certificate containing the 1583 additional extended key usage extension id-kp-cmKGA in order to be 1584 accepted by the EE as a legitimate key generation authority. The KGA 1585 can use one of the PKI management operations described in the 1586 sections above to request the certificate for this key pair on behalf 1587 of the EE. 1589 Generally speaking, in machine-to-machine scenarios it is strongly 1590 preferable to generate public-private key pairs locally at the EE. 1591 Together with proof-of-possession of the private key in the 1592 certification request, this helps a lot to make sure that the entity 1593 identified in the newly issued certificate is the only entity that 1594 knows the private key. 1596 Reasons for central key generation may include the following: 1598 * Lack of sufficient initial entropy. 1600 Note: Good random numbers are needed not only for key generation but 1601 also for session keys and nonces in any security protocol. 1602 Therefore, a decent security architecture should anyways support good 1603 random number generation on the EE side or provide enough initial 1604 entropy for the RNG seed to guarantee good pseudo-random number 1605 generation. Yet maybe this is not the case at the time of requesting 1606 an initial certificate during manufacturing. 1608 * Lack of computational resources, e.g., in case of RSA key 1609 generation. 1611 Note: Since key generation could be performed in advance to the 1612 certificate enrollment communication, it is often not time critical. 1614 Note: As mentioned in Section 2.1 central key generation may be 1615 required in a push model, where the certificate response message is 1616 transferred by the PKI management entity to the EE without a previous 1617 request message. 1619 If the EE wishes to request central key generation, it MUST fill the 1620 subjectPublicKey field in the certTemplate structure of the request 1621 message with a zero-length BIT STRING. This indicates to the PKI 1622 management entity that a new key pair shall be generated centrally on 1623 behalf of the EE. 1625 Note: As the protection of centrally generated keys in the response 1626 message is being extended from EncryptedValue to EncryptedKey by CMP 1627 Updates [I-D.ietf-lamps-cmp-updates], also the alternative 1628 EnvelopedData can be used. In CRMF Section 2.1.9 [RFC4211] the use 1629 of EncryptedValue has been deprecated in favor of the EnvelopedData 1630 structure. Therefore, this profile requires using EnvelopedData as 1631 specified in CMS Section 6 [RFC5652]. When EnvelopedData is to be 1632 used in a transaction, CMP V3 MUST be indicated in the message 1633 header, see CMP Updates [I-D.ietf-lamps-cmp-updates]. 1635 +----------------------------------+ 1636 | EnvelopedData | 1637 | [RFC5652] section 6 | 1638 | +------------------------------+ | 1639 | | SignedData | | 1640 | | [RFC5652] section 5 | | 1641 | | +--------------------------+ | | 1642 | | | AsymmetricKeyPackage | | | 1643 | | | [RFC5958] | | | 1644 | | | +----------------------+ | | | 1645 | | | | privateKey | | | | 1646 | | | | OCTET STRING | | | | 1647 | | | +----------------------+ | | | 1648 | | +--------------------------+ | | 1649 | +------------------------------+ | 1650 +----------------------------------+ 1652 Figure 3: Encrypted private key container 1654 The PKI management entity delivers the private key in the privateKey 1655 field in the certifiedKeyPair structure of the response message also 1656 containing the newly issued certificate. 1658 The private key MUST be provided as an AsymmetricKeyPackage structure 1659 as defined in RFC 5958 [RFC5958]. 1661 This AsymmetricKeyPackage structure MUST be wrapped in a SignedData 1662 structure, as specified in CMS Section 5 [RFC5652], signed by the KGA 1663 generating the key pair. The signature MUST be performed using a 1664 private key related to a certificate asserting the extended key usage 1665 kp-id-cmKGA as described in CMP Updates [I-D.ietf-lamps-cmp-updates] 1666 in order to show the authorization to generate key pairs on behalf of 1667 an EE. 1669 Note: When of using password-based key management technique as 1670 described in Section 4.1.6.3 it may not be possible or meaningful to 1671 the EE to validate the KGA signature in the SignedData structure 1672 since shared secret information is used for initial authentication. 1673 In this case the EE MAY omit this signature validation. 1675 This SignedData structure MUST be wrapped in an EnvelopedData 1676 structure, as specified in CMS Section 6 [RFC5652], encrypting it 1677 using a newly generated symmetric content-encryption key. 1679 This content-encryption key MUST be securely provided as part of the 1680 EnvelopedData structure to the EE using one of three key management 1681 techniques. The choice of the key management technique to be used by 1682 the PKI management entity depends on the authentication mechanism the 1683 EE choose to protect the request message. See CMP Updates section 1684 3.4 [I-D.ietf-lamps-cmp-updates] for more details on which key 1685 management technique to use. 1687 * Signature-protected request message: 1689 - The content-encryption key SHALL be protected using the key 1690 agreement key management technique, see Section 4.1.6.1, if the 1691 certificate used by the EE for protecting the request message 1692 allows the key usage keyAgreement. If the certificate also 1693 allows the key usage keyEncipherment, the key transport key 1694 management technique SHALL NOT be used. 1696 - The content-encryption key SHALL be protected using the key 1697 transport key management technique, see Section 4.1.6.2, if the 1698 certificate used by the EE for protecting the respective 1699 request message allows the key usage keyEncipherment but not 1700 keyAgreement. 1702 * MAC-protected request message: 1704 - The content-encryption key SHALL be protected using the 1705 password-based key management technique, see Section 4.1.6.3, 1706 if and only if the EE used MAC protection for the request 1707 message. 1709 If central key generation is supported, support of the key agreement 1710 key management technique is REQUIRED and support of key transport and 1711 password-based key management techniques are OPTIONAL. This is due 1712 to two reasons: The key agreement key management technique is 1713 supported by most asymmetric algorithms, while the key transport key 1714 management technique is supported only by a very few asymmetric 1715 algorithms. And as mentioned the password-based key management 1716 technique shall only be used in combination with MAC protection, 1717 which is a sideline in this document. 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 sufficient 1724 entropy for the symmetric encryption algorithm used. 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 as follows: 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 for recipientInfo type KeyAgreeRecipientInfo 1737 -- and KeyTransRecipientInfo 1738 -- MUST be set to 0 for recipientInfo type PasswordRecipientInfo 1739 recipientInfos REQUIRED 1740 -- MUST be exactly one RecipientInfo 1741 recipientInfo REQUIRED 1742 -- MUST be either KeyAgreeRecipientInfo (see section 4.1.6.1), 1743 -- KeyTransRecipientInfo (see section 4.1.6.2), or 1744 -- PasswordRecipientInfo (see section 4.1.6.3) 1745 -- If central key generation is supported, support of 1746 -- KeyAgreeRecipientInfo is REQUIRED and support of 1747 -- KeyTransRecipientInfo and PasswordRecipientInfo are OPTIONAL 1748 encryptedContentInfo 1749 REQUIRED 1750 contentType REQUIRED 1751 -- MUST be id-signedData 1752 contentEncryptionAlgorithm 1753 REQUIRED 1754 -- MUST specify the algorithm OID of the algorithm used for 1755 -- content encryption 1756 -- The algorithm MUST be a PROT_SYM_ALG as specified in 1757 -- RFC-CMP-Alg Section 5 1758 encryptedContent REQUIRED 1759 -- MUST be the SignedData structure as specified in 1760 -- CMS Section 5 [RFC5652] in encrypted form 1761 version REQUIRED 1762 -- MUST be set to 3 if X.509 V3 certificates are included 1763 digestAlgorithms 1764 REQUIRED 1765 -- MUST be exactly one digestAlgorithm OID 1766 digestAlgorithmIdentifier 1767 REQUIRED 1768 -- MUST be the OID of the digest algorithm used for generating 1769 -- the signature and match the signature algorithm specified in 1770 -- signatureAlgorithm 1771 encapContentInfo 1772 REQUIRED 1773 -- MUST contain the content that is to be signed 1774 eContentType REQUIRED 1775 -- MUST be id-ct-KP-aKeyPackage as specified in [RFC5958] 1776 eContent REQUIRED 1777 AsymmetricKeyPackage 1778 REQUIRED 1779 -- MUST contain exactly one OneAsymmetricKey element 1780 OneAsymmetricKey 1781 REQUIRED 1782 version REQUIRED 1783 -- MUST be set to 1 1784 privateKeyAlgorithm 1785 REQUIRED 1786 -- The privateKeyAlgorithm field MUST contain 1787 -- the OID of the asymmetric key pair algorithm 1788 privateKey 1789 REQUIRED 1790 -- MUST contain the new private key 1791 attributes 1792 OPTIONAL 1793 -- The attributes field SHOULD not be used 1794 publicKey 1795 REQUIRED 1796 -- MUST contain the public key corresponding to the private key 1797 -- for simplicity and consistency with V2 of OneAsymmetricKey 1798 certificates REQUIRED 1799 -- SHOULD contain the certificate, for the private key used 1800 -- to sign the content, together with its chain 1801 -- If present, the first certificate in this field MUST 1802 -- be the certificate used for protecting this content 1803 -- Self-signed certificates SHOULD NOT be included 1804 -- and MUST NOT be trusted based on their inclusion in any case 1805 crls OPTIONAL 1806 -- MAY be present to provide status information on the protection 1807 -- certificate or its CA certificates 1808 signerInfos REQUIRED 1809 -- MUST be exactly one signerInfo 1810 version REQUIRED 1811 -- MUST be set to 3 1812 sid REQUIRED 1813 subjectKeyIdentifier 1814 REQUIRED 1815 -- MUST be the subjectKeyIdentifier of the protection certificate 1816 digestAlgorithm 1817 REQUIRED 1818 -- MUST be the same as in digestAlgorithmIdentifier 1819 signedAttrs REQUIRED 1820 -- MUST contain an id-contentType attribute containing the same 1821 -- value as eContentType 1822 -- MUST contain an id-messageDigest attribute containing the 1823 -- message digest of eContent 1824 -- MAY contain an id-signingTime attribute containing the time of 1825 -- signature 1826 -- For details on the signed attributes see CMS Section 5.3 1827 -- and Section 11 [RFC5652] 1828 signatureAlgorithm 1829 REQUIRED 1830 -- MUST be the algorithm OID of the signature algorithm used for 1831 -- calculation of the signature bits 1832 -- The signature algorithm MUST be a MSG_SIG_ALG as specified in 1833 -- RFC-CMP-Alg Section 3 and MUST be consistent with the 1834 -- subjectPublicKeyInfo field of the CMP KGA certificate 1835 signature REQUIRED 1836 -- MUST be the result of the digital signature generation 1838 NOTE: As defined in Section 1.5 any field of the ASN.1 syntax as 1839 defined in RFC 5652 [RFC5652] not explicitly specified here, SHOULD 1840 NOT be used by the sending entity. 1842 4.1.6.1. Using key agreement key management technique 1844 This key management technique can be applied in combination with the 1845 PKI management operations specified in Section 4.1.1 to Section 4.1.3 1846 using signature-based protected CMP messages. The public key of the 1847 EE certificate used for the signature-based protection of the request 1848 message MUST also be used for the key establishment of the content- 1849 encryption key. To use this key management technique the 1850 KeyAgreeRecipientInfo structure MUST be used in the contentInfo 1851 field. 1853 The KeyAgreeRecipientInfo structure included into the EnvelopedData 1854 structure is specified in CMS Section 6.2.2 [RFC5652]. 1856 The detailed description of the KeyAgreeRecipientInfo structure looks 1857 like this: 1859 recipientInfo REQUIRED 1860 -- MUST be KeyAgreeRecipientInfo as specified in 1861 version REQUIRED 1862 -- MUST be set to 3 1863 originator REQUIRED 1864 -- MUST contain the originatorKey choice 1865 algorithm REQUIRED 1866 -- MUST be the algorithm OID of the key agreement algorithm 1867 -- The algorithm MUST be a KM_KA_ALG as specified in 1868 -- RFC-CMP-Alg Section 4.1 1869 publicKey REQUIRED 1870 -- MUST be the ephemeral public key of the sending party 1871 ukm RECOMMENDED 1872 -- MUST be used when 1-pass ECMQV is used 1873 -- SHOULD be present to ensure uniqueness of the key 1874 -- encryption key, see [RFC8419] 1875 keyEncryptionAlgorithm 1876 REQUIRED 1877 -- MUST be the algorithm OID of the key wrap algorithm 1878 -- The algorithm MUST be a KM_KW_ALG as specified in 1879 -- RFC-CMP-Alg Section 4.3 1880 recipientEncryptedKeys 1881 REQUIRED 1882 -- MUST contain exactly one RecipientEncryptedKey element 1883 rid REQUIRED 1884 -- MUST contain the rKeyId choice 1885 rKeyId REQUIRED 1886 subjectKeyIdentifier 1887 REQUIRED 1888 -- MUST contain the same value as the senderKID in the 1889 -- respective request messages 1890 encryptedKey 1891 REQUIRED 1892 -- MUST be the encrypted content-encryption key 1894 4.1.6.2. Using key transport key management technique 1896 This key management technique can be applied in combination with the 1897 PKI management operations specified in Section 4.1.1 to Section 4.1.3 1898 using signature-based protected CMP messages. The public key of the 1899 EE certificate used for the signature-based protection of the request 1900 message MUST also be used for key encipherment of the content- 1901 encryption key. To use this key management technique the 1902 KeyTransRecipientInfo structure MUST be used in the contentInfo 1903 field. 1905 The KeyTransRecipientInfo structure included into the EnvelopedData 1906 structure is specified in CMS Section 6.2.1 [RFC5652]. 1908 The detailed description of the KeyTransRecipientInfo structure looks 1909 like this: 1911 recipientInfo REQUIRED 1912 -- MUST be KeyTransRecipientInfo as specified in 1913 -- CMS section 6.2.1 [RFC5652] 1914 version REQUIRED 1915 -- MUST be set to 2 1916 rid REQUIRED 1917 -- MUST contain the subjectKeyIdentifier choice 1918 subjectKeyIdentifier 1919 REQUIRED 1920 -- MUST contain the same value as the senderKID in the respective 1921 -- request messages 1922 keyEncryptionAlgorithm 1923 REQUIRED 1924 -- MUST be the algorithm OID of the key transport algorithm 1925 -- The algorithm MUST be a KM_KT_ALG as specified in RFC-CMP-Alg 1926 -- Section 4.2 1927 encryptedKey REQUIRED 1928 -- MUST be the encrypted content-encryption key 1930 4.1.6.3. Using password-based key management technique 1932 This key management technique can be applied in combination with the 1933 PKI management operation specified in Section 4.1.4 using MAC-based 1934 protected CMP messages. The shared secret information used for the 1935 MAC-based protection MUST also be used for the encryption of the 1936 content-encryption key but with a different salt value applied in the 1937 key derivation algorithm as used for the MAC-based protection . To 1938 use this key management technique the PasswordRecipientInfo structure 1939 MUST be used in the contentInfo field. 1941 The PasswordRecipientInfo structure included into the EnvelopedData 1942 structure is specified in CMS Section 6.2.4 [RFC5652]. 1944 The detailed description of the PasswordRecipientInfo structure looks 1945 like this: 1947 recipientInfo REQUIRED 1948 -- MUST be PasswordRecipientInfo as specified in 1949 -- CMS section 6.2.4 [RFC5652] 1950 version REQUIRED 1951 -- MUST be set to 0 1952 keyDerivationAlgorithm 1953 REQUIRED 1954 -- MUST be the algorithm OID of the key derivation algorithm 1955 -- The algorithm MUST be a KM_KD_ALG as specified in RFC-CMP-Alg 1956 -- Section 4.4 1957 keyEncryptionAlgorithm 1958 REQUIRED 1959 -- MUST be the algorithm OID of the key wrap algorithm 1960 -- The algorithm MUST be a KM_KW_ALG as specified in RFC-CMP-Alg 1961 -- Section 4.3 1962 encryptedKey REQUIRED 1963 -- MUST be the encrypted content-encryption key 1965 4.1.7. Delayed enrollment 1967 This functional extension can be applied in combination with 1968 certificate enrollment as described in Section 4.1.1 to 1969 Section 4.1.5. The functional extension can be used in case a PKI 1970 management entity cannot respond to the certificate request in a 1971 timely manner, e.g., due to offline upstream communication or 1972 required registration officer interaction. Depending on the PKI 1973 architecture, the entity initiating delayed enrollment is not 1974 necessarily the PKI management entity directly addressed by the EE. 1976 Note: According to CMP Updates [I-D.ietf-lamps-cmp-updates] polling 1977 is also possible for PKI management operations starting with a p10cr 1978 request message. 1980 The PKI management entity initiating the delayed enrollment MUST 1981 respond with an ip/cp/kup message including the status "waiting". 1982 When receiving a response with status "waiting" the EE MUST send a 1983 poll request to the same PKI management entity as before. The PKI 1984 management entity that initiated the delayed enrollment MUST answer 1985 with a poll response containing a checkAfter time. This value 1986 indicates the minimum number of seconds that should elapse before the 1987 EE sends another poll request. This is repeated as long as no final 1988 response is available or any party involved gives up on the current 1989 transaction. When the PKI management entity that initiated delayed 1990 enrollment can provide the final ip/cp/kup message for the initial 1991 request of the EE, it MUST provide this message in response to a poll 1992 request. After receiving this response, the EE can continue the 1993 original PKI management operation as described in the respective 1994 section of this document, e.g., sending a certConf message. 1996 Message flow: 1998 Step# EE PKI management entity 1999 1 format ir/cr/p10cr/kur 2000 As described in the 2001 respective section 2002 in this document 2003 2 ->ir/cr/p10cr/kur-> 2004 3 handle request as described 2005 in the respective section 2006 in this document 2007 4 in case no immediate final 2008 response is possible, 2009 receive or format ip, cp 2010 or kup message containing 2011 status "waiting" 2012 5 <- ip/cp/kup <- 2013 6 handle ip/cp/kup with status "waiting" 2014 7 format pollReq 2015 8 -> pollReq -> 2016 9 handle, re-protect or 2017 forward pollReq 2018 10 in case the requested 2019 certificate or a 2020 corresponding response 2021 message is available, 2022 receive or format ip, cp, 2023 or kup containing the 2024 issued certificate, else 2025 format or receive pollRep 2026 with appropriate 2027 checkAfter value 2028 11 <- pollRep <- 2029 12 handle pollRep 2030 13 let checkAfter 2031 time elapse 2032 14 continue with line 7 2034 Detailed description of the first ip/cp/kup: 2036 Response with status 'waiting' -- ip/cp/kup 2038 Field Value 2040 header 2041 -- MUST contain a header as described for the first response 2042 -- message of the respective PKI management operation 2044 body 2045 -- The response of the PKI management entity to the request in 2046 -- case no immediate appropriate response can be sent 2047 ip/cp/kup REQUIRED 2048 response REQUIRED 2049 -- MUST contain exactly one CertResponse 2050 certReqId REQUIRED 2051 -- MUST be 0 2052 status REQUIRED 2053 -- PKIStatusInfo structure MUST be present 2054 status REQUIRED 2055 -- MUST be "waiting" 2056 statusString OPTIONAL 2057 -- MAY be any human-readable text for debugging, logging or to 2058 -- display in a GUI 2059 failInfo PROHIBITED 2060 certifiedKeyPair PROHIBITED 2062 protection REQUIRED 2063 -- MUST contain protection as described for the first response 2064 -- message of the respective PKI management operation, except 2065 -- that the PKI management entity that initiated the delayed 2066 -- enrollment and created this response MUST apply its own 2067 -- protection 2069 extraCerts REQUIRED 2070 -- MUST contain certificates as described for the first response 2071 -- message of the respective PKI management operation. Yet since 2072 -- no new certificate is included yet, no respective certificate 2073 -- chain is included 2075 Polling Request -- pollReq 2077 Field Value 2079 header 2080 -- MUST contain a header as described for the certConf message 2081 -- of the respective PKI management operation 2083 body 2084 -- The message of the EE asks for the final response or for a 2085 -- time to check again 2086 pollReq REQUIRED 2087 -- MUST contain exactly one element 2088 certReqId REQUIRED 2089 -- MUST be 0 2091 protection REQUIRED 2092 -- MUST contain protection as described for the certConf message 2093 -- of the respective PKI management operation 2095 extraCerts OPTIONAL 2096 -- MUST be as described for the certConf message of the 2097 -- respective PKI management operation 2099 Polling Response -- pollRep 2101 Field Value 2103 header 2104 -- MUST contain a header as described for the pkiConf message 2105 -- of the respective PKI management operation 2107 body 2108 -- The message indicates the delay after which the EE may send 2109 -- another pollReq message for this transaction 2110 pollRep REQUIRED 2111 -- MUST contain exactly one entry 2112 certReqId REQUIRED 2113 -- MUST be 0 2114 checkAfter REQUIRED 2115 -- time in seconds to elapse before a new pollReq should be sent 2116 reason OPTIONAL 2117 -- MAY be any human-readable text for debugging, logging or to 2118 -- display in a GUI 2120 protection REQUIRED 2121 -- MUST contain protection as described for the pkiConf message 2122 -- of the respective profile, except that the PKI management 2123 -- entity that initiated the delayed enrollment and created this 2124 -- response MUST apply its own protection 2126 extraCerts OPTIONAL 2127 -- If present, it MUST contain certificates as described for the 2128 -- pkiConf message of the respective PKI management operation. 2130 Final response -- ip/cp/kup 2132 Field Value 2134 header 2135 -- MUST contain a header as described for the first 2136 -- except that the PKI management entity that initiated the 2137 -- delayed enrollment MUST replace the recipNonce by be the 2138 -- senderNonce of the last pollReq message 2140 body 2141 -- The response of the PKI management entity to the initial 2142 -- request as described in the respective PKI management 2143 -- operation 2145 protection REQUIRED 2146 -- MUST contain protection as described for the first response 2147 -- message of the respective PKI management operation, except 2148 -- that the PKI management entity that initiated the delayed 2149 -- enrollment MUST re-protect the response message 2151 extraCerts REQUIRED 2152 -- MUST contain certificates as described for the first 2153 -- response message of the respective PKI management operation 2155 4.2. Revoking a certificate 2157 This PKI management operation should be used by an entity to request 2158 revocation of a certificate. Here the revocation request is used by 2159 an EE to revoke one of its own certificates. A PKI management entity 2160 could also act as an EE to revoke one of its own certificates. 2162 The revocation request message MUST be signed using the certificate 2163 that is to be revoked to prove the authorization to revoke. The 2164 revocation request message is signature-protected using this 2165 certificate. 2167 An EE requests the revocation of an own certificate at the CA that 2168 issued this certificate. The PKI management entity responds with a 2169 message that contains the status of the revocation from the CA. 2171 Preconditions: 2173 1 The certificate the EE wishes to revoke is not yet expired or 2174 revoked. 2176 Message flow: 2178 Step# EE PKI management entity 2179 1 format rr 2180 2 -> rr -> 2181 3 handle, re-protect or 2182 forward rr 2183 4 format or receive rp 2184 5 <- rp <- 2185 6 handle rp 2187 For this PKI management operation, the EE MUST include exactly one 2188 RevDetails structure in the rr message body. In case no error 2189 occurred the response to the rr MUST be an rp message containing a 2190 status field with a single set of values. 2192 Detailed message description: 2194 Revocation Request -- rr 2196 Field Value 2198 header 2199 -- As described in Section 3.1 2201 body 2202 -- The request of the EE to revoke its certificate 2203 rr REQUIRED 2204 -- MUST contain exactly one element of type RevDetails 2205 -- If more revocations are desired, further requests MUST be 2206 -- packaged in separate PKI Messages 2207 certDetails REQUIRED 2208 -- MUST be present and be of type CertTemplate 2209 serialNumber REQUIRED 2210 -- MUST contain the certificate serialNumber attribute of the 2211 -- X.509 certificate to be revoked 2212 issuer REQUIRED 2213 -- MUST contain the issuer attribute of the X.509 certificate to 2214 -- be revoked 2215 crlEntryDetails REQUIRED 2216 -- MUST contain exactly one reasonCode of type CRLReason (see 2217 -- [RFC5280] section 5.3.1) 2218 -- If the reason for this revocation is not known or shall not be 2219 -- published the reasonCode MUST be 0 = unspecified 2221 protection REQUIRED 2222 -- As described in Section 3.2 and using the private key related 2223 -- to the certificate to be revoked 2225 extraCerts REQUIRED 2226 -- As described in Section 3.3 2228 Revocation Response -- rp 2230 Field Value 2232 header 2233 -- As described in Section 3.1 2235 body 2236 -- The responds of the PKI management entity to the request as 2237 -- appropriate 2238 rp REQUIRED 2239 status REQUIRED 2240 -- MUST contain exactly one element of type PKIStatusInfo 2241 status REQUIRED 2242 -- positive value allowed: "accepted" 2243 -- negative value allowed: "rejection" 2244 statusString OPTIONAL 2245 -- MAY be any human-readable text for debugging, logging or to 2246 -- display in a GUI 2247 failInfo OPTIONAL 2248 -- MAY be present if and only if status is "rejection" 2250 protection REQUIRED 2251 -- As described in section 3.2 2253 extraCerts REQUIRED 2254 -- As described in section 3.3 2256 4.3. Error reporting 2258 This functionality should be used by an EE to report error conditions 2259 upstream to the PKI management entity such that the involved PKI 2260 management entities can immediately free their resources related to 2261 the current transaction. Error reporting by a PKI management entity 2262 downstream to the EE is described in Section 5.3. 2264 In case the error condition is related to specific details of an ip, 2265 cp, or kup response message and a confirmation is expected the error 2266 condition MUST be reported in the respective certConf message with 2267 negative contents. 2269 General error conditions, e.g., problems with the message header, 2270 protection, or extraCerts, and negative feedback on rp, pollRep, or 2271 pkiConf messages MUST be reported in the form of an error message. 2273 In both situations the EE reports the status "rejection" in the 2274 PKIStatusInfo structure of the respective message. 2276 Depending on the PKI architecture, the addressed PKI management 2277 entity MUST forward the error message (upstream) to the next PKI 2278 management entity and MUST terminate this PKI management operation on 2279 receiving any response. 2281 The PKIStatusInfo structure is used to report errors. The 2282 PKIStatusInfo structure consists of the following fields: 2284 * status: Here the PKIStatus value "rejection" is the only one 2285 allowed. 2287 * statusString: Here any human-readable valid value for logging or 2288 to display in a GUI SHOULD be added. 2290 * failInfo: Here the PKIFailureInfo values MAY be used in the way 2291 explained in Appendix F of RFC 4210 [RFC4210]. The following 2292 PKIFailureInfo values have specific usage and therefore are 2293 described in detail here: 2295 - transactionIdInUse: This is sent by a PKI management entity in 2296 case the received request contains a transaction ID that has 2297 already been used for another transaction. An EE receiving 2298 such error message SHOULD resend the request in a new 2299 transaction using a different transaction ID. 2301 - systemUnavail or systemFailure: This is sent by a PKI 2302 management entity in case a back-end system is not available or 2303 currently not functioning correctly. An EE receiving such 2304 error message SHOULD resend the request in a new transaction 2305 after some time. 2307 Detailed error message description: 2309 Error Message -- error 2311 Field Value 2313 header 2314 -- As described in Section 3.1 2316 body 2317 -- The message sent by the EE or the (L)RA/CA to indicate an 2318 -- error that occurred 2319 error REQUIRED 2320 pKIStatusInfo REQUIRED 2321 status REQUIRED 2322 -- MUST have the value "rejection" 2323 statusString RECOMMENDED 2324 -- SHOULD be any human-readable text for debugging, logging 2325 -- or to display in a GUI 2326 failInfo OPTIONAL 2327 -- MAY be present 2329 protection REQUIRED 2330 -- As described in Section 3.2 2332 extraCerts OPTIONAL 2333 -- As described in Section 3.3 2335 4.4. Support messages 2337 The following support messages offer on demand in-band transport of 2338 content relevant to the EE that may be provided by the PKI management 2339 entity. CMP general messages and general response are used for this 2340 purpose. Depending on the environment, these requests may be 2341 answered by an LRA, RA, or CA. 2343 The general messages and general response messages transport 2344 InfoTypeAndValue structures. In addition to those infoType values 2345 defined in RFC 4210 [RFC4210] further OIDs MAY be used to define new 2346 PKI management operations or new general-purpose support messages as 2347 needed in specific environments. 2349 The following contents are specified in this document: 2351 * Get CA certificates 2353 * Get root CA certificate updates 2355 * PGet certificate request templates 2356 The PKI management operation is similar to that given in Appendix E.5 2357 of RFC 4210 [RFC4210]. In this section the aspects common to all 2358 general messages (genm) and to all general responses (genp) are 2359 described. 2361 The behavior in case an error occurs is described in Section 4.3. 2363 Message flow: 2365 Step# EE PKI management entity 2366 1 format genm 2367 2 -> genm -> 2368 3 handle, re-protect or 2369 forward genm 2370 4 format or receive genp 2371 5 <- genp <- 2372 6 handle genp 2374 Detailed message description: 2376 General Message -- genm 2378 Field Value 2380 header 2381 -- As described in Section 3.1 2383 body 2384 -- A request by the EE to receive information 2385 genm 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 General Response -- genp 2402 Field Value 2404 header 2405 -- As described in Section 3.1 2407 body 2408 -- The response of the PKI management entity to an 2409 -- information request 2410 genp REQUIRED 2411 -- MUST contain exactly one element of type 2412 -- InfoTypeAndValue 2413 infoType REQUIRED 2414 -- MUST be the OID identifying the specific PKI 2415 -- management operation described below 2416 infoValue OPTIONAL 2417 -- MUST be as described in the specific PKI 2418 -- management operation described below 2420 protection REQUIRED 2421 -- As described in Section 3.2 2423 extraCerts REQUIRED 2424 -- As described in Section 3.3 2426 4.4.1. Get CA certificates 2428 This PKI management operation can be used by an EE to request CA 2429 certificates from the PKI management entity. 2431 An EE requests CA certificates from the PKI management entity by 2432 sending a general message with OID id-it-caCerts as specified in CMP 2433 Updates [I-D.ietf-lamps-cmp-updates]. The PKI management entity 2434 responds with a general response with the same OID that either 2435 contains a SEQUENCE of certificates populated with the available CA 2436 intermediate and issuing CA certificates or with no content in case 2437 no CA certificate is available. 2439 The message sequence for this PKI management operation is as given in 2440 Section 4.4, with the following specific content: 2442 1 the body MUST contain as infoType the OID id-it-caCerts 2444 2 the infoValue of the request MUST be absent 2446 3 if present, the infoValue of the response MUST contain a sequence 2447 of certificates 2449 The infoValue field of the general response containing the id-it- 2450 caCerts OID looks like this: 2452 infoValue OPTIONAL 2453 -- MUST be absent if no CA certificate is available 2454 -- MUST be present if CA certificates are available 2455 -- MUST be a sequence of CMPCertificate 2457 4.4.2. Get root CA certificate update 2459 This PKI management operation can be used by an EE to retrieve any 2460 updated root CA Certificate as described in Section 4.4 of RFC 4210 2461 [RFC4210]. 2463 An EE requests a root CA certificate update from the PKI management 2464 entity by sending a general message with OID id-it-rootCaKeyUpdate as 2465 specified in CMP Updates [I-D.ietf-lamps-cmp-updates]. The PKI 2466 management entity responds with a general response with the same OID 2467 that either contains the update of the root CA certificate consisting 2468 of up to three certificates, or with no content in case no update is 2469 available. 2471 The newWithNew certificate is the new root CA certificate and is 2472 REQUIRED to be present in the response message. The newWithOld 2473 certificate is RECOMMENDED to be present in the response message, 2474 because it is needed for those cases where the receiving entity 2475 trusts the old root CA certificate and wishes to gain trust in the 2476 new root CA certificate. It MAY be omitted if the PKI management 2477 entity that performed the message protection of the response message 2478 is authorization to update the trust store of the EE. The oldWithNew 2479 certificate is OPTIONAL, because it is only needed in a scenario 2480 where the requesting entity does not have an own certificate under 2481 the new root CA and wishes to authenticate to entities not trusting 2482 the old root CA. 2484 The message sequence for this PKI management operation is as given in 2485 Section 4.4, with the following specific content: 2487 1 the body MUST contain as infoType the OID id-it-rootCaKeyUpdate 2489 2 the infoValue of the request MUST be absent 2491 3 if present, the infoValue of the response MUST be a 2492 RootCaKeyUpdate structure 2494 The infoValue field of the general response containing the id-it- 2495 rootCaKeyUpdate extension looks like this: 2497 infoValue OPTIONAL 2498 -- MUST be absent if no update of the root CA certificate is 2499 -- available 2500 -- MUST be present if an update of the root CA certificate 2501 -- is available and MUST be of type RootCaKeyUpdate 2502 newWithNew REQUIRED 2503 -- MUST be present if infoValue is present 2504 -- MUST contain the new root CA certificate 2505 newWithOld RECOMMENDED 2506 -- SHOULD be present if infoValue is present 2507 -- MUST contain a certificate containing the new public 2508 -- root CA key signed with the old private root CA key 2509 oldWithNew OPTIONAL 2510 -- MAY be present if infoValue is present 2511 -- MUST contain a certificate containing the old public 2512 -- root CA key signed with the new private root CA key 2514 < TBD: In case the PKI management entity serves for more than one 2515 Root CA. There are three different options to handle this: - The EE 2516 specifies by means of a respective label in the HTTP endpoint for 2517 which Root CA certificate the update is requested. - The EE transfers 2518 the oldWithOld certificate or its S/N+issuer in the InfoValue of the 2519 request. - The PKI management entity provides several 2520 InfoTypeAndValue pairs in the response containing a RootCaKeyUpdate 2521 element for each Root CA where an update is available. > 2523 4.4.3. Get certificate request template 2525 This PKI management operation can be used by an EE to request a 2526 template with parameters for a future certificate requests. 2528 An EE requests certificate request parameters from the PKI management 2529 entity by sending a general message with OID id-it-certReqTemplate as 2530 specified in CMP Updates [I-D.ietf-lamps-cmp-updates]. The PKI 2531 management entity responds with a general response with the same OID 2532 that either contains a certificate template containing requirements 2533 on certificate fields and extensions and optionally a keySpec field 2534 containing requirements on algorithms acceptable for key pair 2535 generation, or with no content in case no specific requirements are 2536 imposed by the PKI. 2538 The EE SHOULD follow the requirements from the received CertTemplate 2539 and the optional keySpec field, by including in the certTemplate of 2540 certificate requests all the fields requested, taking over all the 2541 field values provided and filling in any remaining fields values. 2542 The EE SHOULD NOT add further CertTemplate fields, Name components, 2543 and extensions or their (sub-)components. 2545 Note: We deliberately do not use 'MUST' or 'MUST NOT' here in order 2546 to allow more flexibility in case the rules given here are not 2547 sufficient for specific scenarios. The EE can populate the 2548 certificate request as wanted and ignore any of the requirements 2549 contained in the CertReqTemplate response message. On the other 2550 hand, a PKI management entity is free to ignore or replace any parts 2551 of the content of the certificate request provided by the EE. The 2552 CertReqTemplate PKI management operation offers means to ease a joint 2553 understanding which fields and/or which field values should be used. 2555 In case a field of type Name, e.g., issuer or subject, is present in 2556 the CertTemplate but has the value NULL-DN (i.e., has an empty list 2557 of RDN components) the field SHOULD be included in the certTemplate 2558 and filled with content provided by the EE. Similarly, in case an 2559 X.509v3 extension is present but its extnValue is empty this means 2560 that the extension SHOULD be included and filled with content 2561 provided by the EE. In case a Name component, for instance a common 2562 name or serial number, is given but has an empty string value the EE 2563 SHOULD fill in a value. Similarly, in case an extension has sub- 2564 components (e.g., an IP address in a SubjectAltName field) with empty 2565 value, the EE SHOULD fill in a value. 2567 The EE MUST ignore (i.e., not include and fill in) empty fields, 2568 extensions, and sub-components that it does not understand or does 2569 not know suitable values to be filled in. 2571 The publicKey field of type SubjectPublicKeyInfo in the CertTemplate 2572 MUST be omitted. In case the PKI management entity wishes to make 2573 stipulation on supported algorithms the EE may use for key 2574 generation, this MUST be specified using the control fields as 2575 specified in CMP Updates [I-D.ietf-lamps-cmp-updates]. 2577 The keySpec field, if present, specifies the public key types and 2578 lengths for which a certificate may be requested. 2580 The value of a keySpec with the OID id-regCtrl-algId, as specified in 2581 CMP Updates [I-D.ietf-lamps-cmp-updates], MUST be of type 2582 AlgorithmIdentitier and gives an algorithm other than RSA. For EC 2583 keys the full curve information MUST be specified as described in the 2584 respective standard documents. 2586 The value of a keySpec with the OID id-regCtrl-rsaKeyLen, as 2587 specified in CMP Updates [I-D.ietf-lamps-cmp-updates], MUST be of 2588 type Integer and gives an RSA key length. 2590 The PKI management entity responds with a general response with the 2591 same OID that either contains a certificate template containing 2592 requirements on certificate fields and extensions and optionally a 2593 keySpec field containing requirements on algorithms acceptable for 2594 key pair generation, or with no content in case no specific 2595 requirements are imposed by the PKI. 2597 The EE SHOULD follow the requirements from the received CertTemplate 2598 and the optional keySpec field, by including in the certTemplate of 2599 certificate requests all the fields requested, taking over all the 2600 field values provided and filling in any remaining fields values. 2601 The EE SHOULD NOT add further CertTemplate fields, name components, 2602 and extensions or their (sub-)components. In case several keySpec 2603 elements are present the EE can choose one of the specified 2604 algorithms for key pair generation. In case the keySpec field is 2605 absent the EE is free to choose any public key type including 2606 parameters. 2608 In the CertTemplate structure the serialNumber, signingAlg, 2609 publicKey, issuerUID, and subjectUID fields MUST be omitted. 2611 The message sequence for this PKI management operation is as given in 2612 Section 4.4, with the following specific content: 2614 1 the body MUST contain as infoType the OID id-it-certReqTemplate 2616 2 the infoValue of the request MUST be absent 2618 3 if present, the infoValue of the response MUST be a CertTemplate 2619 structure and an optional SEQUENCE of AttributeTypeAndValue with 2620 attribute type id-regCtrl-algId or id-regCtrl-rsaKeyLen 2622 The infoValue field of the general response containing the id-it- 2623 certReqTemplate OID looks like this: 2625 InfoValue OPTIONAL 2626 -- MUST be absent if no requirements are available 2627 -- MUST be present if the PKI management entity has any 2628 -- requirements on the content of the certificates template 2629 certTemplate REQUIRED 2630 -- MUST be present if infoValue is present 2631 -- MUST contain the prefilled CertTemplate structure elements 2632 -- The SubjectPublicKeyInfo MUST contain no algorithm ID i.e., 2633 -- the null OBJECT IDENTIFIER) in the algorithm field and a 2634 -- zero-length BIT STRING in the subjectPublicKey field 2635 keySpec OPTIONAL 2636 -- MUST be absent if no requirements on the public key are 2637 -- available MUST be present if the PKI management entity has any 2638 -- requirements on the key generation 2639 -- MUST contain one AttributeTypeAndValue per supported algorithm 2640 -- with attribute id-regCtrl-algId or id-regCtrl-rsaKeyLen 2642 < TBD: In case the PKI management entity offers for more than one set 2643 of certificate request parameters. There are three different options 2644 to handle this: - The EE specifies by means of a respective label in 2645 the HTTP endpoint for which set of certificate request parameters is 2646 requested the template. - The EE neame of the set of certificate 2647 request parameters in the InfoValue of the request. - The PKI 2648 management entity provides several InfoTypeAndValue pairs in the 2649 response containing a set of certificate request parameter in each 2650 InfoTypeAndValue pairs. > 2652 5. LRA and RA PKI management operations 2654 This section focuses on the communication among PKI management 2655 entities. Depending on the network and PKI solution design, these 2656 can be LRAs, RAs, and CAs. 2658 A PKI management entity typically forwards request messages from 2659 downstream, but it may also reply to them itself. Besides forwarding 2660 received messages, a PKI management entity may need to revoke 2661 certificates of EEs, report errors, or may need to manage its own 2662 certificates. 2664 5.1. Forwarding messages 2666 In case the PKI solution consists of several PKI management entities, 2667 each CMP request message (i.e., ir, cr, p10cr, kur, pollReq, or 2668 certConf) or error message coming from an EE or any other downstream 2669 PKI management entity MUST be sent to the next (upstream) PKI 2670 management entity. Any received response message MUST be forwarded 2671 downstream to the next PKI management entity or EE. 2673 The PKI management entity SHOULD verify the protection, the syntax, 2674 the required message fields, the message type, and if applicable the 2675 authorization and the proof-of-possession of the message. Additional 2676 checks or actions MAY be applied depending on the PKI solution 2677 requirements and concept. If one of these verification procedures 2678 fails, the (L)RA SHOULD switch to the operation described in 2679 Section 5.3, i.e., respond with a negative response message and then 2680 MUST NOT forward the request message further upstream. 2682 A PKI management entity SHOULD not change the received message unless 2683 necessary. The PKI management entity SHOULD only update the message 2684 protection if this is technically necessary. Concrete PKI system 2685 specifications may define in more detail when to do so. 2687 This is particularly relevant in the upstream communication of a 2688 request message. 2690 Each hop in a chain of PKI management entity has one or more 2691 functionalities, e.g., a PKI management entity may 2693 * verify the identities of EEs or base authorization decisions for 2694 certification request processing on specific knowledge of the 2695 local setup, e.g., by consulting an inventory or asset management 2696 system, 2698 * add fields to certificate request messages, 2700 * store data from a message in a database for later usage or audit 2701 purposes, 2703 * provide traversal of a network boundary, 2705 * replace a MAC-based protection by a signature-based protection 2706 that can be verified also further upstream, 2708 * double-check if the messages transferred back and forth are 2709 properly protected and well-formed, 2711 * provide an authentic indication that it has performed all required 2712 checks, 2714 * initiate a delayed enrollment due to offline upstream 2715 communication or registration officer interaction, 2717 * grant the request of an EE to omit sending a confirmation message, 2718 or 2720 * collect messages from ultiple LRAs and forward them jointly. 2722 Therefore, the decision if a message should be forwarded 2724 * unchanged with the original protection, 2726 * unchanged with a new protection, or 2728 * changed with a new protection 2730 depends on the PKI solution design and the associated security policy 2731 (CP/CPS [RFC3647]). 2733 This section specifies the options a PKI management entity may 2734 implement and use. 2736 A PKI management entity MAY update the protection of a message if it 2737 * performs changes to the header or the body of the message, 2739 * needs to securely indicate that it has done checks or validations 2740 on the message to one of the next (upstream) PKI components, 2742 * needs to protect the message using a key and certificate from a 2743 different PKI, or 2745 * needs to replace or produce a MAC-based protection. 2747 This is particularly relevant in the upstream communication of 2748 certificate request messages. 2750 Note that the message protection covers only the header and the body 2751 and not the extraCerts. The PKI management entity MAY change the 2752 extraCerts in any of the following message adaptations, e.g., to 2753 sort, add, or delete certificates to support the next hop. This may 2754 be particularly helpful to augment upstream messages with additional 2755 certificates or to reduce the number of certificates in downstream 2756 messages when forwarding to constrained devices. 2758 5.1.1. Not changing protection 2760 This variant means that a PKI management entity forwards a CMP 2761 message without changing the header, body, or protection. In this 2762 case the PKI management entity acts more like a proxy, e.g., on a 2763 network boundary, implementing no specific RA-like security 2764 functionality that require an authentic indication to the PKI. Still 2765 the PKI management entity might implement checks that result in 2766 refusing to forward the request message and instead responding with 2767 an error message as specified in Section 5.3. 2769 This variant of forwarding a message SHOULD be used for kur messages 2770 because their protection (using the certificate to be updated) MUST 2771 NOT be changed. If the respective PKI management entity really needs 2772 approve such a request it MUST use a nested message as described in 2773 Section 5.1.3. 2775 5.1.2. Replacing protection 2777 The following two alternatives to forwarding a message can be used by 2778 any PKI management entity forwarding a CMP message with or without 2779 changes, while providing its own protection asserting approval of 2780 messages. In this case the PKI management entity acts as an actual 2781 Registration Authority (RA), which implements important security 2782 functionality of the PKI. 2784 Before replacing the existing protection by a new protection, the PKI 2785 management entity MUST verify the protection provided and approve its 2786 content including any own modifications. For certificate requests 2787 the PKI management entity MUST verify (except in case of central key 2788 generation) the presence and contents of the proof-of-possession 2789 self-signature of the certTemplate using the public key of the 2790 requested certificate and MUST check that the EE, as authenticated by 2791 the message protection, is authorized to request a certificate with 2792 the subject as specified in the certTemplate. 2794 In case the received message has been protected by a CA or another 2795 PKI management entity, the current PKI management entity MUST verify 2796 its protection and approve its content including any own 2797 modifications. For request messages the PKI management entity MUST 2798 check that the other PKI management entity, as authenticated by the 2799 protection of the incoming message, was authorized to issue or 2800 forward the request. 2802 These message adaptations MUST NOT be applied to kur request messages 2803 as described in Section 4.1.3 since their original protection using 2804 the key and certificate to be updated needs to be preserved, unless 2805 the regCtrl OldCertId is used to strongly identify the certificate to 2806 be updated. 2808 These message adaptations MUST NOT be applied to certificate request 2809 messages as described in Section 4.1.6since their original protection 2810 needs to be preserved up to the Key Generation Authority, which needs 2811 to use it for encrypting the new private key for the EE. 2813 In both the kur and central key generation cases, if a PKI management 2814 entity needs to state its approval of the original request message it 2815 MUST provide this using a nested message as specified in 2816 Section 5.1.3. 2818 When an intermediate PKI management entity modifies a message, it 2819 SHOULD NOT change the transactionID nor the sender and recipient 2820 nonce except as stated for delayed enrollment in Section 4.1.7. 2821 Section 4.1.7. 2823 5.1.2.1. Keeping proof-of-possession 2825 This variant of forwarding a message means that a PKI management 2826 entity forwards a CMP message with or without modifying the message 2827 header or body while preserving any included proof-of-possession. 2829 By replacing the existing protection using its own CMP protecting key 2830 the PKI management entity provides a proof of verifying and approving 2831 of the message as described above. 2833 In case the PKI management entity modifies the certTemplate of an ir 2834 or cr message, the message adaptation in Section 5.1.2.2 needs to be 2835 applied instead. 2837 5.1.2.2. Breaking proof-of-possession 2839 This variant of forwarding a message means that a PKI management 2840 entity forwards an ir or cr message with modifications of the 2841 certTemplate, i.e., modification, addition, or removal of fields. 2842 Such changes will break the signature-based proof-of-possession 2843 provided by the EE in the original message. 2845 By replacing the existing protection and using its own CMP protection 2846 key the PKI management entity provides a proof of verifying and 2847 approving the request message as described above. 2849 In addition, the PKI management entity MUST verify the proof-of- 2850 possession contained in the original message as described above. If 2851 these checks were successful, the PKI management entity MUST change 2852 the popo to raVerified. 2854 The popo field MUST contain the raVerified choice in the certReq 2855 structure of the modified message as follows: 2857 popo 2858 raVerified REQUIRED 2859 -- MUST have the value NULL and indicates that the PKI 2860 -- management entity verified the popo of the original 2861 -- message 2863 5.1.3. Adding Protection 2865 This variant of forwarding a message means that a PKI management 2866 entity adds another protection to PKI management messages before 2867 forwarding them. Applying an additional protection is specifically 2868 relevant when forwarding a message that requests a certificate update 2869 or a central key generation. This is because the original protection 2870 of the EE must be preserved while adding an indication of approval. 2872 The nested message is a PKI management message containing a 2873 PKIMessages sequence as its body containing one or more CMP messages. 2875 As specified in the updated Section 5.1.3.4 of RFC4210 [RFC4210] (see 2876 CMP Updates [I-D.ietf-lamps-cmp-updates]) there are various use case 2877 for adding another protection by a PKI management entity. Specific 2878 procedures are described in more detail in the following sections. 2880 The behavior in case an error occurs is described in Section 4.3. 2882 Message flow: 2884 Step# PKI management entity PKI management entity 2885 1 format nested 2886 2 -> nested -> 2887 3 handle, re-protect or 2888 forward nested 2889 4 format or receive nested 2890 5 <- nested <- 2891 6 handle nested 2893 Detailed message description: 2895 Nested Message - nested 2897 Field Value 2899 header 2900 -- As described in Section 3.1 2902 body 2903 -- Container to provide additional protection to original 2904 -- messages and to bundle request messages or alternatively 2905 -- response messages 2906 PKIMessages REQUIRED 2907 -- MUST be a sequence of one or more CMP messages 2909 protection REQUIRED 2910 -- As described in Section 3.2 using the CMP protection key of 2911 -- the PKI management entity 2913 extraCerts REQUIRED 2914 -- As described in Section 3.3 2916 5.1.3.1. Handling a single PKI management message 2918 A PKI management entity may authentically indicate successful 2919 validation and authorization of a PKI management message by adding an 2920 additional signature to the original PKI management message. 2922 A PKI management entity SHALL wrap the original PKI management 2923 messages in a nested message structure. The additional signature as 2924 prove of verification and authorization by the PKI management entity 2925 MUST be applied as signature-based message protection of the nested 2926 message. 2928 5.1.3.2. Handling a batch of PKI management messages 2930 A PKI management entity MAY bundle any number of PKI management 2931 messages for batch processing or to transfer a bulk of PKI management 2932 messages via an offline interface using the nested message structure. 2933 Nested messages can be used on the upstream interface towards the 2934 next PKI management entity and/or on the downstream interface from 2935 the PKI management entity towards the EE. 2937 This PKI management operation is typically used on the interface 2938 between LRA and RA to bundle several PKI management messages for 2939 offline transport. In this case the LRA needs to initiate delayed 2940 enrollment as described in Section 5.1.4. If the RA may need 2941 different routing information per nested PKI management message a 2942 suitable mechanism may need to be implemented. This mechanism 2943 strongly depends on the requirements of the target architecture. 2944 Therefore, it is out of scope of this document. 2946 An initial nested message is generated locally at the PKI management 2947 entity. For the initial nested message, the PKI management entity 2948 acts as a protocol end point and therefore a fresh transactionId and 2949 a fresh senderNonce MUST be used in the header of the nested message. 2950 The recipient field MUST identify the PKI management entity that is 2951 expected to unpack the nested message. An initial nested message may 2952 contain request messages, e.g., ir, cr, p10cr, kur, certConf, rr, or 2953 genm. While building the initial nested message the PKI management 2954 entity SHOULD store the transactionIds and the senderNonces of all 2955 bundled messages together with the transactionId of the initial 2956 nested message. 2958 Such an initial nested message is sent to the next PKI management 2959 entity, which MUST unbundle the included request messages and handle 2960 each of them as usual. It SHOULD answer with a responding nested 2961 message. This responding message MUST use the transactionId of the 2962 initial nested message and return the senderNonce of the initial 2963 nested message as recipNonce of the responding nested message. The 2964 responding nested message SHOULD bundle the individual response 2965 messages (e.g., ip, cp, kup, pkiconf, rp, genp, error) for all 2966 original request messages of the initial nested message. While 2967 unbundling the responding nested message, the former PKI management 2968 entity can determine lost and unexpected responses based on the 2969 previously stored transactionIds and senderNonces. When it forwards 2970 the unbundled responses, any extra messages SHOULD be dropped, and 2971 any missing message SHOULD be replaced by an error message to inform 2972 the respective EE about the failed certificate management operation. 2974 The PKI management entity building the nested message applies a 2975 signature-based protection using its CMP protection key as transport 2976 protection. This protection SHALL NOT be regarded as an indication 2977 of verification or approval of the bundled PKI request messages. 2979 5.1.4. Initiating delayed enrollment 2981 This functional extension can be used by a PKI management entity to 2982 initiate delayed enrollment. In this case a PKI management entity 2983 MUST set the status "waiting" in the response message. The PKI 2984 management entity MUST then reply to the pollReq messages as 2985 described in Section 4.1.7. 2987 Typically, as stated in Section 5.1.2, an intermediate PKI management 2988 entity SHOULD NOT change the sender and recipient nonces even in case 2989 it modifies a request or a response message. In the special case of 2990 polling initiated by an intermediate PKI management entity, for 2991 example by an LRA with offline transport to an upstream RA, there is 2992 an exception. Between the EE and that entity, pollReq and pollRep 2993 messages are exchanged handling the nonces as usual. Yet when, after 2994 some pollRep, the final response from upstream arrives at that PKI 2995 management entity, this response contains the recipNonce set to the 2996 value copied (as usual) from the senderNonce in the original request 2997 message. The mentioned entity needs to replace the recipNonce in the 2998 response message with the senderNonce of the last received pollReq 2999 because the downstream entities, including the EE, will expect it in 3000 this way. 3002 5.2. Revoking certificates on behalf of another's PKI entities 3004 This PKI management operation can be used by a PKI management entity 3005 to revoke a certificate of another PKI entity. This revocation 3006 request message MUST be signed by the PKI management entity using its 3007 own CMP protection key to prove to the PKI authorization to revoke 3008 the certificate on behalf of that PKI entity. 3010 Preconditions: 3012 1 the certificate to be revoked MUST be known to the PKI management 3013 entity 3015 2 the PKI management entity MUST have the authorization to revoke 3016 the certificates of other entities issued by the corresponding CA 3018 The message sequence for this PKI management operation is identical 3019 to that given in Section 4.2, with the following changes: 3021 1 it is not required that the certificate to be revoked is not yet 3022 expired or revoked 3024 2 the PKI management entity acts as EE for this message exchange 3026 3 the rr message MUST be signed using the CMP protection key of the 3027 PKI management entity. 3029 5.3. Error reporting 3031 This functionality should be used by the PKI management entity to 3032 report any arising error conditions downstream to the EE. Note that 3033 error reporting by the EE upstream to the PKI management entity is 3034 described in Section 4.3. 3036 In case the error condition is related to specific details of an ir, 3037 cr, p10cr, or kur request message it MUST be reported in the specific 3038 response message, i.e., an ip, cp, or kup with negative contents. 3040 General error conditions, e.g., problems with the message header, 3041 protection, or extraCerts, and negative feedback on rr, pollReq, 3042 certConf, or error messages MUST be reported in the form of an error 3043 message. 3045 In both situations the PKI management entity reports the errors in 3046 the PKIStatusInfo structure of the respective message as described in 3047 Section 4.3. 3049 An EE receiving any such negative feedback SHOULD log the error 3050 appropriately and MUST terminate the current transaction. 3052 6. CMP message transport mechanisms 3054 The CMP messages are designed to be self-contained, such that in 3055 principle any transport can be used. HTTP SHOULD be used for online 3056 transport while file-based transport MAY be used in case offline 3057 transport is required. In case HTTP transport is not desired or 3058 possible, CMP messages MAY also be piggybacked on any other reliable 3059 transport protocol such as CoAP [RFC7252]. 3061 Independently of the means of transport it can happen that messages 3062 are lost or that a communication partner does not respond. To 3063 prevent waiting indefinitely, each CMP client component SHOULD use a 3064 configurable per-request timeout, and each CMP server component 3065 SHOULD use a configurable per-response timeout in case a further 3066 message is to be expected from the client side. In this way a 3067 hanging transaction can be closed cleanly with an error and related 3068 resources (for instance, any cached extraCerts) can be freed. 3070 When conveying a CMP messages in HTTP or MIME-based transport 3071 protocols the internet media type "application/pkixcmp" MUST be set 3072 for transport encoding as specified in Section 5.3 of RFC 2510 3073 [RFC2510] and Section 3.4 of RFC 6712 [RFC6712]. 3075 Note: When using TCP as reliable transport layer protocol, which is 3076 typical in conjunction with HTTP, there is the option to keep the 3077 connection open over the lifetime of transactions containing multiple 3078 request-response message pairs. This may improve efficiency but is 3079 not required from a security point of view. 3081 6.1. HTTP transport 3083 This transport mechanism can be used by a PKI entity to transfer CMP 3084 messages over HTTP. If HTTP transport is used the specifications as 3085 described in [RFC6712] and updated by CMP Updates 3086 [I-D.ietf-lamps-cmp-updates] MUST be followed. 3088 PKI management operations SHOULD use the following URI path: 3090 +=================================+=====================+=========+ 3091 | PKI management operation | Path | Details | 3092 +=================================+=====================+=========+ 3093 | Enroll client to new PKI | /initialization | Section | 3094 | | | 4.1.1 | 3095 +---------------------------------+---------------------+---------+ 3096 | Enroll client to existing PKI | /certification | Section | 3097 | | | 4.1.2 | 3098 +---------------------------------+---------------------+---------+ 3099 | Update client certificate | /keyupdate | Section | 3100 | | | 4.1.3 | 3101 +---------------------------------+---------------------+---------+ 3102 | Enroll client using PKCS#10 | /p10 | Section | 3103 | | | 4.1.5 | 3104 +---------------------------------+---------------------+---------+ 3105 | Enroll client using central key | /serverkeygen | Section | 3106 | generation | | 4.1.6 | 3107 | | | | 3108 | Note: This path element MAY | | | 3109 | also be appended to each of the | | | 3110 | path elements listed above. | | | 3111 +---------------------------------+---------------------+---------+ 3112 | Revoke client certificate | /revocation | Section | 3113 | | | 4.2 | 3114 +---------------------------------+---------------------+---------+ 3115 | Get CA certificates | /getcacert | Section | 3116 | | | 4.4.1 | 3117 +---------------------------------+---------------------+---------+ 3118 | Get root CA certificate update | /getrootupdate | Section | 3119 | | | 4.4.2 | 3120 +---------------------------------+---------------------+---------+ 3121 | Get certificate request | /getcertreqtemplate | Section | 3122 | template | | 4.4.3 | 3123 +---------------------------------+---------------------+---------+ 3124 | Additional protection | /nested | Section | 3125 | | | 5.1.3 | 3126 | Note: This path element is | | | 3127 | applicable only between PKI | | | 3128 | management entities. | | | 3129 +---------------------------------+---------------------+---------+ 3131 Table 9: HTTP endpoints 3133 Subsequent certConf, error, and pollReq messages are sent to the URI 3134 of the respective PKI management operation. 3136 The PKI entity will recognize by the HTTP response status code if a 3137 configured URI is supported by the PKI management entity by sending a 3138 request to its preferred enrollment endpoint. 3140 6.2. HTTPS transport using certificates 3142 This transport mechanism can be used by a PKI entity to further 3143 protect the HTTP transport described in Section 6.1 using TLS 1.2 3144 [RFC5246] or TLS 1.3 [RFC8446] with certificate-based authentication 3145 as described in [RFC2818]. Using this transport mechanism, the CMP 3146 transport via HTTPS MUST use TLS server authentication and SHOULD use 3147 TLS client authentication. 3149 TLS client: 3151 * The client SHOULD use a TLS client certificate as far as 3152 available. If no dedicated TLS certificate is available on an EE 3153 side, this EE SHOULD use an already existing certificate 3154 identifying the EE (e.g., a manufacturer issued certificate). 3155 Each PKI management entity SHOULD use a dedicated TLS client 3156 certificate on its upstream (client) interface. 3158 * If no usable client certificate is available at the client, 3159 server-only authenticated TLS MUST be used. 3161 * The client MUST validate the TLS server certificate of its 3162 communication partner. 3164 TLS server: 3166 * The server MUST use a TLS server certificate. 3168 * The server MUST validate the TLS certificate of its clients if 3169 client authentication is available. 3171 Note: The requirements for checking certificates given in [RFC5280], 3172 [RFC5246] and [RFC8446] MUST be followed for the TLS layer. 3173 Certificate status checking SHOULD be used for the TLS certificates 3174 of communication partners. 3176 6.3. HTTPS transport using shared secrets 3178 This transport mechanism can be used by a PKI entity to further 3179 protect the HTTP transport as described in Section 6.1 using TLS 1.2 3180 [RFC5246] or TLS 1.3 [RFC8446] as described in [RFC2818] with mutual 3181 authentication based on shared secret information as described in 3182 [RFC5054]. 3184 < TBD: Add an appropriate shared secret-based mechanism for TLS 1.3. 3185 > 3187 TLS client: 3189 * The client MUST use its shared secret information for 3190 authentication. 3192 TLS server: 3194 * The server MUST use a suitable shared secret information for 3195 authentication. 3197 < TBD: It needs to be clarified which cipher suite shall be 3198 recommended as there seems to be no support for TLS-SRP un JavaSE. > 3200 6.4. Offline transport 3202 For transporting CMP messages between PKI entities any mechanism can 3203 be used that is able to store and forward binary objects of 3204 sufficient length and with sufficient reliability while preserving 3205 the order of messages for each transaction. 3207 The transport mechanism SHOULD be able to indicate message loss, 3208 excessive delay, and possibly other transmission errors. In such 3209 cases the PKI entities using this mechanism SHOULD report an error as 3210 specified in Section 4.3 as fare as possible. 3212 6.4.1. File-based transport 3214 CMP messages MAY be transferred between PKI entities using file- 3215 system-based mechanisms, for instance when an off-line end entity or 3216 a PKI management entity performs delayed enrollment. Each file MUST 3217 contain the ASN.1 DER encoding of one CMP message only, which may be 3218 nested. There MUST be no extraneous header or trailer information in 3219 the file. The file name extension ".PKI" MUST be used. 3221 6.4.2. Other asynchronous transport protocols 3223 Other asynchronous transport protocols, e.g., email or website 3224 up-/download, MAY transfer CMP messages between PKI entities. A MIME 3225 wrapping is defined for those environments that are MIME native. The 3226 MIME wrapping in this section is specified in [RFC8551], section 3.1. 3228 The ASN.1 DER encoding of the CMP messages MUST be transferred using 3229 the "application/pkixcmp" content type and base64-encoded content- 3230 transfer-encoding as specified in [RFC2510], section 5.3. A filename 3231 MUST be included either in a content-type or a content-disposition 3232 statement. The file name extension ".PKI" MUST be used. 3234 6.5. CoAP transport 3236 In constrained environments where no HTTP transport is desired or 3237 possible, CoAP [RFC7252] as specified in 3238 [I-D.ietf-ace-cmpv2-coap-transport] MAY be used. 3240 6.6. Piggybacking on other reliable transport 3242 For online transfer where no HTTP transport is desired or possible 3243 CMP messages MAY also be transported on some other reliable protocol. 3244 Connection and error handling mechanisms like those specified for 3245 HTTP in [RFC6712] need to be implemented. 3247 A more detailed specification is out of scope of this document and 3248 would need to be given in a separate document, for instance in the 3249 scope of the transport protocol used. 3251 7. IANA Considerations 3253 8. Security Considerations 3255 < TBD: Add any security considerations > 3257 9. Acknowledgements 3259 We thank the various reviewers of this document. 3261 10. References 3263 10.1. Normative References 3265 [I-D.ietf-lamps-cmp-algorithms] 3266 Brockhaus, H., Aschauer, H., Ounsworth, M., and S. Mister, 3267 "CMP Algorithms", Work in Progress, Internet-Draft, draft- 3268 ietf-lamps-cmp-algorithms-02, 20 January 2021, 3269 . 3272 [I-D.ietf-lamps-cmp-updates] 3273 Brockhaus, H. and D. V. Oheimb, "Certificate Management 3274 Protocol (CMP) Updates", Work in Progress, Internet-Draft, 3275 draft-ietf-lamps-cmp-updates-08, 22 February 2021, 3276 . 3279 [I-D.ietf-lamps-crmf-update-algs] 3280 Housley, R., "Algorithm Requirements Update to the 3281 Internet X.509 Public Key Infrastructure Certificate 3282 Request Message Format (CRMF)", Work in Progress, 3283 Internet-Draft, draft-ietf-lamps-crmf-update-algs-04, 19 3284 February 2021, . 3287 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 3288 Requirement Levels", BCP 14, RFC 2119, 3289 DOI 10.17487/RFC2119, March 1997, 3290 . 3292 [RFC2986] Nystrom, M. and B. Kaliski, "PKCS #10: Certification 3293 Request Syntax Specification Version 1.7", RFC 2986, 3294 DOI 10.17487/RFC2986, November 2000, 3295 . 3297 [RFC4086] Eastlake 3rd, D., Schiller, J., and S. Crocker, 3298 "Randomness Requirements for Security", BCP 106, RFC 4086, 3299 DOI 10.17487/RFC4086, June 2005, 3300 . 3302 [RFC4210] Adams, C., Farrell, S., Kause, T., and T. Mononen, 3303 "Internet X.509 Public Key Infrastructure Certificate 3304 Management Protocol (CMP)", RFC 4210, 3305 DOI 10.17487/RFC4210, September 2005, 3306 . 3308 [RFC4211] Schaad, J., "Internet X.509 Public Key Infrastructure 3309 Certificate Request Message Format (CRMF)", RFC 4211, 3310 DOI 10.17487/RFC4211, September 2005, 3311 . 3313 [RFC5280] Cooper, D., Santesson, S., Farrell, S., Boeyen, S., 3314 Housley, R., and W. Polk, "Internet X.509 Public Key 3315 Infrastructure Certificate and Certificate Revocation List 3316 (CRL) Profile", RFC 5280, DOI 10.17487/RFC5280, May 2008, 3317 . 3319 [RFC5652] Housley, R., "Cryptographic Message Syntax (CMS)", STD 70, 3320 RFC 5652, DOI 10.17487/RFC5652, September 2009, 3321 . 3323 [RFC5958] Turner, S., "Asymmetric Key Packages", RFC 5958, 3324 DOI 10.17487/RFC5958, August 2010, 3325 . 3327 [RFC6712] Kause, T. and M. Peylo, "Internet X.509 Public Key 3328 Infrastructure -- HTTP Transfer for the Certificate 3329 Management Protocol (CMP)", RFC 6712, 3330 DOI 10.17487/RFC6712, September 2012, 3331 . 3333 [RFC8174] Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC 3334 2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174, 3335 May 2017, . 3337 10.2. Informative References 3339 [ETSI-3GPP.33.310] 3340 3GPP, "Network Domain Security (NDS); Authentication 3341 Framework (AF)", 3GPP TS 33.310 16.6.0, 16 December 2020. 3343 [I-D.ietf-ace-cmpv2-coap-transport] 3344 Sahni, M. and S. Tripathi, "CoAP Transport for CMPV2", 3345 Work in Progress, Internet-Draft, draft-ietf-ace-cmpv2- 3346 coap-transport-00, 21 February 2021, 3347 . 3350 [IEC.62443-3-3] 3351 IEC, "Industrial communication networks - Network and 3352 system security - Part 3-3: System security requirements 3353 and security levels", IEC 62443-3-3, August 2013, 3354 . 3356 [IEEE.802.1AR_2018] 3357 IEEE, "IEEE Standard for Local and metropolitan area 3358 networks - Secure Device Identity", IEEE 802.1AR-2018, 3359 DOI 10.1109/IEEESTD.2018.8423794, 2 August 2018, 3360 . 3362 [NIST.CSWP.04162018] 3363 National Institute of Standards and Technology (NIST), 3364 "Framework for Improving Critical Infrastructure 3365 Cybersecurity, Version 1.1", NIST NIST CSWP 04162018, 3366 DOI 10.6028/NIST.CSWP.04162018, April 2018, 3367 . 3370 [NIST.SP.800-57p1r5] 3371 Barker, E B., "Recommendation for key management, part 1 3372 :general", NIST NIST.SP.800-57pt1r5, 3373 DOI 10.6028/NIST.SP.800-57pt1r5, 2020, 3374 . 3376 [RFC2510] Adams, C. and S. Farrell, "Internet X.509 Public Key 3377 Infrastructure Certificate Management Protocols", 3378 RFC 2510, DOI 10.17487/RFC2510, March 1999, 3379 . 3381 [RFC2818] Rescorla, E., "HTTP Over TLS", RFC 2818, 3382 DOI 10.17487/RFC2818, May 2000, 3383 . 3385 [RFC3647] Chokhani, S., Ford, W., Sabett, R., Merrill, C., and S. 3386 Wu, "Internet X.509 Public Key Infrastructure Certificate 3387 Policy and Certification Practices Framework", RFC 3647, 3388 DOI 10.17487/RFC3647, November 2003, 3389 . 3391 [RFC5054] Taylor, D., Wu, T., Mavrogiannopoulos, N., and T. Perrin, 3392 "Using the Secure Remote Password (SRP) Protocol for TLS 3393 Authentication", RFC 5054, DOI 10.17487/RFC5054, November 3394 2007, . 3396 [RFC5246] Dierks, T. and E. Rescorla, "The Transport Layer Security 3397 (TLS) Protocol Version 1.2", RFC 5246, 3398 DOI 10.17487/RFC5246, August 2008, 3399 . 3401 [RFC7252] Shelby, Z., Hartke, K., and C. Bormann, "The Constrained 3402 Application Protocol (CoAP)", RFC 7252, 3403 DOI 10.17487/RFC7252, June 2014, 3404 . 3406 [RFC8366] Watsen, K., Richardson, M., Pritikin, M., and T. Eckert, 3407 "A Voucher Artifact for Bootstrapping Protocols", 3408 RFC 8366, DOI 10.17487/RFC8366, May 2018, 3409 . 3411 [RFC8446] Rescorla, E., "The Transport Layer Security (TLS) Protocol 3412 Version 1.3", RFC 8446, DOI 10.17487/RFC8446, August 2018, 3413 . 3415 [RFC8551] Schaad, J., Ramsdell, B., and S. Turner, "Secure/ 3416 Multipurpose Internet Mail Extensions (S/MIME) Version 4.0 3417 Message Specification", RFC 8551, DOI 10.17487/RFC8551, 3418 April 2019, . 3420 [UNISIG.Subset-137] 3421 UNISIG, "Subset-137; ERTMS/ETCS On-line Key Management 3422 FFFIS; V1.0.0", December 2015, 3423 . 3425 Appendix A. Example CertReqTemplate 3427 This section provides a concrete example for the content of an 3428 infoValue used of type id-it-certReqTemplate as described in 3429 Section 4.4.3. 3431 Suppose the server requires that the certTemplate contains the issuer 3432 field with a value to be filled in by the EE, the subject field with 3433 a common name to be filled in by the EE and two organizational unit 3434 fields with given values "myDept" and "myGroup", the publicKey field 3435 with an ECC key on curve secp256r1 or RSA public key of length 2048, 3436 the subjectAltName extension with DNS name "www.myServer.com" and an 3437 IP address to be filled in, the keyUsage extension marked critical 3438 with the value digitalSignature and keyAgreement, and the extKeyUsage 3439 extension with values to be filled in by the EE. Then the infoValue 3440 with certTemplate and keySpec returned to the EE must be encoded as 3441 follows: 3443 SEQUENCE { 3444 SEQUENCE { 3445 [3] { 3446 SEQUENCE {} 3447 } 3448 [5] { 3449 SEQUENCE { 3450 SET { 3451 SEQUENCE { 3452 OBJECT IDENTIFIER commonName (2 5 4 3) 3453 UTnF8String '' 3454 } 3455 } 3456 SEQUENCE { 3457 OBJECT IDENTIFIER organizationalUnitName (2 5 4 11) 3458 UTF8String 'myDept' 3459 } 3460 } 3461 SET { 3462 SEQUENCE { 3463 OBJECT IDENTIFIER organizationalUnitName (2 5 4 11) 3464 UTF8String 'myGroup' 3465 } 3466 } 3467 } 3468 [6] { 3469 SEQUENCE { 3470 null 3471 NULL 3472 } 3473 BIT STRING, encapsulates { 3474 SEQUENCE {} 3475 } 3476 } 3477 [9] { 3478 SEQUENCE { 3479 OBJECT IDENTIFIER subjectAltName (2 5 29 17) 3480 OCTET STRING, encapsulates { 3481 SEQUENCE { 3482 [2] 'www.myServer.com' 3483 [7] '' 3484 } 3485 } 3486 } 3487 SEQUENCE { 3488 OBJECT IDENTIFIER keyUsage (2 5 29 15) 3489 BOOLEAN TRUE 3490 OCTET STRING, encapsulates { 3491 BIT STRING 3 unused bits 3492 '10001'B 3493 } 3494 } 3495 SEQUENCE { 3496 OBJECT IDENTIFIER extKeyUsage (2 5 29 37) 3497 OCTET STRING, encapsulates { 3498 SEQUENCE {} 3499 } 3500 } 3501 } 3502 } 3503 SEQUENCE { 3504 SEQUENCE { 3505 OBJECT IDENTIFIER aldId (1 3 6 1 5 5 7 5 1 TBD3) 3506 SEQUENCE { 3507 OBJECT IDENTIFIER ecPublicKey (1 2 840 10045 2 1) 3508 OBJECT IDENTIFIER secp256r1 (1 2 840 10045 3 1 7) 3509 } 3510 } 3511 SEQUENCE { 3512 OBJECT IDENTIFIER rsaKeyLen (1 3 6 1 5 5 7 5 1 TBD4) 3513 INTEGER 2048 3514 } 3515 } 3516 } 3518 Appendix B. History of changes 3520 Note: This appendix will be deleted in the final version of the 3521 document. 3523 From version 04 -> 05: 3525 * Changed to XML V3 3526 * Added algorithm names introducted in CMP Algorithms Section 7.3 to 3527 Section 4 of this document 3528 * Updates Syntax in Section 4.4.3 due to changes made in CMP Updates 3529 * Deleted the text on HTTP-based discovery as discussed in 3530 Section 6.1 3531 * Updates Appendix A due to change syntax in Section 4.4.3 3532 * Many clarifications and changes in wording thanks to David's 3533 extensive review 3535 From version 03 -> 04: 3537 * Deleted normative text sections on algorithms and refer to CMP 3538 Algorithms and CRMF Algorithm Requirements Update instead 3540 * Some clarifications and changes in wording 3542 From version 02 -> 03: 3544 * Updated the interoperability with [UNISIG.Subset-137] in 3545 Section 1.4. 3546 * Changed Section 2.3 to a tabular layout to enhanced readability 3547 * Added a ToDo to section 3.1 on aligning with the CMP Algorithms 3548 draft that will be set up as decided in IETF 108 3549 * Updated section 4.1.6 to add the AsymmetricKey Package structure 3550 to transport a newly generated private key as decided in IETF 108 3551 * Added a ToDo to section 4.1.7 on required review of the nonce 3552 handling in case an offline LRA responds and not forwards the 3553 pollReq messages 3554 * Updated Section 4 due to the definition of the new ITAV OIDs in 3555 CMP Updates 3556 * Updated Section 4.4.4 to utilize controls instead of rsaKeyLen 3557 (see thread "dtaft-ietf-lamps-cmp-updates and rsaKeyLen") 3558 * Deleted the section on definition and discovery of HTTP URIs and 3559 copied the text to the HTTP transport section and to CMP Updates 3560 section 3.2 3561 * Added some explanation to Section 5.1.2 and Section 5.1.3 on using 3562 nested messages when a protection by the RA is required. 3563 * Deleted the section on HTTP URI definition and discovery as some 3564 content was moved to CMP Updates. The rest of the content was 3565 moved back to the HTTP transport section 3566 * Deleted the ASN.1 module after moving the new OIDs id-it-caCerts, 3567 id-it-rootCaKeyUpdate, and id-it-certReqTemplate to CMP Updates 3568 * Minor changes in wording and addition of some open ToDos 3570 From version 01 -> 02: 3572 * Extend Section 1.4 with regard to conflicts with UNISIG Subset- 3573 137. 3574 * Minor clarifications on extraCerts in Section 3.3 and 3575 Section 4.1.1. 3576 * Complete specification of requesting a certificate from a trusted 3577 PKI with signature protection in Section 4.1.2. 3578 * Changed from symmetric key-encryption to password-based key 3579 management technique in section Section 4.1.6.3 as discussed on 3580 the mailing list (see thread "draft-ietf-lamps-lightweight-cmp- 3581 profile-01, section 5.1.6.1") 3582 * Changed delayed enrollment described in Section 4.1.7 from 3583 recommended to optional as decided at IETF 107 3584 * Introduced the new RootCAKeyUpdate structure for root CA 3585 certificate update in Section 4.4.2 as decided at IETF 107 (also 3586 see email thread "draft-ietf-lamps-lightweight-cmp-profile-01, 3587 section 5.4.3") 3589 * Extend the description of the CertReqTemplate PKI management 3590 operation, including an example added in the Appendix. Keep 3591 rsaKeyLen as a single integer value in Section 4.4.3 as discussed 3592 on the mailing list (see thread "draft-ietf-lamps-lightweight-cmp- 3593 profile-01, section 5.4.4") 3594 * Deleted Sections "Get certificate management configuration" and 3595 "Get enrollment voucher" as decided at IETF 107 3596 * Complete specification of adding an additional protection by an 3597 PKI management entity in Section 5.1.3. 3598 * Added a section on HTTP URI definition and discovery and extended 3599 Section 6.1 on definition and discovery of supported HTTP URIs and 3600 content types, add a path for nested messages as specified in 3601 Section 5.1.3 and delete the paths for /getCertMgtConfig and 3602 /getVoucher 3603 * Changed Section 6.4 to address offline transport and added more 3604 detailed specification file-based transport of CMP 3605 * Added a reference to the new I-D of Mohit Sahni on "CoAP Transport 3606 for CMPV2" in Section 6.5; thanks to Mohit supporting the effort 3607 to ease utilization of CMP 3608 * Moved the change history to the Appendix 3609 * Minor changes in wording 3611 From version 00 -> 01: 3613 * Harmonize terminology with CMP [RFC4210], e.g., 3614 - transaction, message sequence, exchange, use case -> PKI 3615 management operation 3616 - PKI component, (L)RA/CA -> PKI management entity 3617 * Minor changes in wording 3619 From draft-brockhaus-lamps-lightweight-cmp-profile-03 -> draft-ietf- 3620 lamps-lightweight-cmp-profile-00: 3622 * Changes required to reflect WG adoption 3623 * Minor changes in wording 3625 From version 02 -> 03: 3627 * Added a short summary of [RFC4210] Appendix D and E in 3628 Section 1.3. 3629 * Clarified some references to different sections and added some 3630 clarification in response to feedback from Michael Richardson and 3631 Tomas Gustavsson. 3632 * Added an additional label to the operational path to address 3633 multiple CAs or certificate profiles in Section 6.1. 3635 From version 01 -> 02: 3637 * Added some clarification on the key management techniques for 3638 protection of centrally generated keys in Section 4.1.6. 3639 * Added some clarifications on the certificates for root CA 3640 certificate update in Section 4.4.2. 3641 * Added a section to specify the usage of nested messages for RAs to 3642 add an additional protection for further discussion, see 3643 Section 5.1.3. 3644 * Added a table containing endpoints for HTTP transport in 3645 Section 6.1 to simplify addressing PKI management entities. 3646 * Added some ToDos resulting from discussion with Tomas Gustavsson. 3647 * Minor clarifications and changes in wording. 3649 From version 00 -> 01: 3651 * Added a section to specify the enrollment with an already trusted 3652 PKI for further discussion, see Section 4.1.2. 3653 * Complete specification of requesting a certificate from a legacy 3654 PKI using a PKCS#10 [RFC2986] request in Section 4.1.5. 3655 * Complete specification of adding central generation of a key pair 3656 on behalf of an end entity in Section 4.1.6. 3657 * Complete specification of handling delayed enrollment due to 3658 asynchronous message delivery in Section 4.1.7. 3659 * Complete specification of additional support messages, e.g., to 3660 update a Root CA certificate or to request an RFC 8366 [RFC8366] 3661 voucher, in Section 4.4. 3662 * Minor changes in wording. 3664 From draft-brockhaus-lamps-industrial-cmp-profile-00 -> draft- 3665 brockhaus-lamps-lightweight-cmp-profile-00: 3667 * Change focus from industrial to more multi-purpose use cases and 3668 lightweight CMP profile. 3669 * Incorporate the omitted confirmation into the header specified in 3670 Section 3.1 and described in the standard enrollment use case in 3671 Section 4.1.1 due to discussion with Tomas Gustavsson. 3672 * Change from OPTIONAL to RECOMMENDED for use case 'Revoke another's 3673 entities certificate' in Section 5.2, because it is regarded as 3674 important functionality in many environments to enable the 3675 management station to revoke EE certificates. 3676 * Complete the specification of the revocation message flow in 3677 Section 4.2 and Section 5.2. 3678 * The CoAP based transport mechanism and piggybacking of CMP 3679 messages on top of other reliable transport protocols is out of 3680 scope of this document and would need to be specified in another 3681 document. 3682 * Further minor changes in wording. 3684 Authors' Addresses 3686 Hendrik Brockhaus (editor) 3687 Siemens AG 3689 Email: hendrik.brockhaus@siemens.com 3691 Steffen Fries 3692 Siemens AG 3694 Email: steffen.fries@siemens.com 3696 David von Oheimb 3697 Siemens AG 3699 Email: david.von.oheimb@siemens.com