idnits 2.17.1 draft-ietf-lamps-lightweight-cmp-profile-06.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 5 instances of lines with non-RFC6890-compliant IPv4 addresses in the document. If these are example addresses, they should be changed. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust and authors Copyright Line does not match the current year == Using lowercase 'not' together with uppercase 'MUST', 'SHALL', 'SHOULD', or 'RECOMMENDED' is not an accepted usage according to RFC 2119. Please use uppercase 'NOT' together with RFC 2119 keywords (if that is what you mean). Found 'SHOULD not' in this paragraph: When in Section 3, Section 4, and Section 5 a field of the ASN.1 syntax as defined in CMP [RFC4210], CRMF [RFC4211], CMS [RFC5652], and CMP Updates [I-D.ietf-lamps-cmp-updates] 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: header pvno REQUIRED -- MUST be 3 to indicate CMP v3 in all cases where EnvelopedData -- is supported and expected to be used in the current -- PKI management operation -- MUST be 3 to indicate CMP v3 in certConf messages when using -- the hashAlg field -- MUST be 2 to indicate CMP v2 in all other cases -- For details on version negotiation see RFC-CMP-Updates sender REQUIRED -- SHOULD contain a name representing the originator of the -- message; otherwise, the NULL-DN (a zero-length -- SEQUENCE OF RelativeDistinguishedNames) MUST be used -- SHOULD be the subject of the CMP protection certificate, i.e., -- the certificate for the private key used to sign the message -- In a multi-hop scenario, the receiving entity SHOULD not rely -- on the correctness of the sender field. recipient REQUIRED -- SHOULD be the name of the intended recipient; otherwise, the -- NULL-DN MUST be used -- In the first message of a PKI management operation: -- SHOULD be the subject DN of the CA the PKI management -- operation is requested from -- In all other messages: -- SHOULD contain the value of the sender field of the previous -- message in the same PKI management operation -- The recipient field SHALL be handled gracefully by the -- receiving entity, because in a multi-hop scenario its -- correctness cannot be guaranteed. messageTime RECOMMENDED -- MUST be the time at which the message was produced, if present protectionAlg REQUIRED -- MUST be an algorithm identifier indicating the algorithm -- used for calculating the protection bits -- If it is a signature algorithm its type MUST be a -- MSG_SIG_ALG as specified in [RFC-CMP-Alg] Section 3 and -- MUST be consistent with the subjectPublicKeyInfo field of -- the protection certificate -- If it is a MAC algorithm its type MUST be a MSG_MAC_ALG as -- specified in [RFC-CMP-Alg] Section 6.1 senderKID RECOMMENDED -- MUST be the SubjectKeyIdentifier of the CMP protection -- certificate transactionID REQUIRED -- In the first message of a PKI management operation: == Using lowercase 'not' together with uppercase 'MUST', 'SHALL', 'SHOULD', or 'RECOMMENDED' is not an accepted usage according to RFC 2119. Please use uppercase 'NOT' together with RFC 2119 keywords (if that is what you mean). Found 'MUST not' in this paragraph: Upstream PKI management entities will not receive any CMP message to learn that the PKI management operation has been terminated. In case they expect a further message from the EE, a connection interruption or timeout will occur. Then they also MUST regard the current PKI management operation as terminated with failure and MUST not attempt to send an error message downstream. == Using lowercase 'not' together with uppercase 'MUST', 'SHALL', 'SHOULD', or 'RECOMMENDED' is not an accepted usage according to RFC 2119. Please use uppercase 'NOT' together with RFC 2119 keywords (if that is what you mean). Found 'MUST not' in this paragraph: If the error condition is on an upstream nested message containing batched requests, it MUST not attempt to respond to the individual requests included in it. == 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 'SHALL not' in this paragraph: Note: The entropy of the shared secret information is crucial for the level of protection when using a password-based key management technique. For centrally generated key pairs, the entropy of the shared secret information SHALL not be less than the security strength of the centrally generated key pair. Further guidance is available in Section 8. == 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 'SHALL not' in this paragraph: For the case of centrally generated key pairs, the entropy of the shared secret information SHALL not be less than the security strength of the centrally generated key pair; if the shared secret information is re-used for different key pairs, the entropy and the security of the underlying cryptographic mechanisms SHOULD exceed the security strength of the key pairs. == 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 'SHALL not' in this paragraph: For the case of a PKI management operation that delivers a new trust anchor, e.g., a root CA certificate, using caPubs, (a) that is not concluded in a timely manner or (b) where the shared secret information is re-used for several key management operations, the entropy of the shared secret information SHALL not be less than the security strength of the key material being managed by the operation. -- The document date (9 July 2021) is 1015 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: 'RFC-CMP-Alg' is mentioned on line 820, but not defined == Missing Reference: 'RFC-CMP-Updates' is mentioned on line 863, but not defined == Missing Reference: 'RFC8419' is mentioned on line 2157, but not defined -- Looks like a reference, but probably isn't: '3' on line 3890 -- Looks like a reference, but probably isn't: '5' on line 3893 -- Looks like a reference, but probably isn't: '9' on line 3915 -- Looks like a reference, but probably isn't: '2' on line 3920 -- Looks like a reference, but probably isn't: '7' on line 3921 == Outdated reference: A later version (-10) exists of draft-ietf-ace-cmpv2-coap-transport-02 == Outdated reference: A later version (-15) exists of draft-ietf-lamps-cmp-algorithms-05 == Outdated reference: A later version (-23) exists of draft-ietf-lamps-cmp-updates-10 ** Downref: Normative reference to an Informational RFC: RFC 2986 == Outdated reference: A later version (-05) exists of draft-ietf-anima-brski-async-enroll-03 -- 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 (~~), 16 warnings (==), 9 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: 10 January 2022 Siemens 6 9 July 2021 8 Lightweight Certificate Management Protocol (CMP) Profile 9 draft-ietf-lamps-lightweight-cmp-profile-06 11 Abstract 13 This document aims at simple, interoperable, and automated PKI 14 management operations covering typical use cases of industrial and 15 IoT scenarios. This is achieved by profiling the Certificate 16 Management Protocol (CMP), the related Certificate Request Message 17 Format (CRMF), and HTTP-based or CoAP-based transport in a succinct 18 but sufficiently detailed and self-contained way. To make secure 19 certificate management for simple scenarios and constrained devices 20 as lightweight as possible, only the most crucial types of operations 21 and options are specified as mandatory. More special and complex use 22 cases are supported as well, by features specified as recommended or 23 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 10 January 2022. 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 . . . . . . . . . . . . . . . . . . . . . . . . 4 59 1.1. How to Read This Document . . . . . . . . . . . . . . . . 4 60 1.2. Motivation for a lightweight profile of CMP . . . . . . . 4 61 1.3. Special requirements of industrial and IoT scenarios . . 5 62 1.4. Existing CMP profiles . . . . . . . . . . . . . . . . . . 6 63 1.5. Compatibility with existing CMP profiles . . . . . . . . 7 64 1.6. Scope of this document . . . . . . . . . . . . . . . . . 8 65 1.7. Structure of this document . . . . . . . . . . . . . . . 9 66 1.8. Convention and Terminology . . . . . . . . . . . . . . . 10 67 2. Architecture and use cases . . . . . . . . . . . . . . . . . 11 68 2.1. Solution architecture . . . . . . . . . . . . . . . . . . 11 69 2.2. Supported PKI management operations . . . . . . . . . . . 13 70 2.2.1. Mandatory PKI management operations . . . . . . . . . 13 71 2.2.2. Recommended PKI management operations . . . . . . . . 13 72 2.2.3. Optional PKI management operations . . . . . . . . . 14 73 2.3. CMP message transport . . . . . . . . . . . . . . . . . . 16 74 3. Generic aspects of the PKI message . . . . . . . . . . . . . 16 75 3.1. General description of the CMP message header . . . . . . 17 76 3.2. General description of the CMP message protection . . . . 19 77 3.3. General description of CMP message extraCerts . . . . . . 20 78 3.4. Generic PKI management operation prerequisites . . . . . 20 79 3.5. Generic validation of a PKI message . . . . . . . . . . . 22 80 3.6. Error handling . . . . . . . . . . . . . . . . . . . . . 24 81 3.6.1. Reporting error conditions upstream . . . . . . . . . 24 82 3.6.2. Reporting error conditions downstream . . . . . . . . 25 83 3.6.3. Handling error conditions on nested messages used for 84 batching . . . . . . . . . . . . . . . . . . . . . . 25 85 3.6.4. Reporting error conditions . . . . . . . . . . . . . 25 86 4. End Entity PKI management operations . . . . . . . . . . . . 27 87 4.1. Requesting a new certificate from a PKI . . . . . . . . . 30 88 4.1.1. Requesting a certificate from a new PKI with 89 signature-based protection . . . . . . . . . . . . . 31 90 4.1.2. Requesting an additional certificate with 91 signature-based protection . . . . . . . . . . . . . 37 92 4.1.3. Updating an existing certificate with signature 93 protection . . . . . . . . . . . . . . . . . . . . . 38 95 4.1.4. Requesting a certificate from a PKI with MAC-based 96 protection . . . . . . . . . . . . . . . . . . . . . 39 97 4.1.5. Requesting a certificate from a legacy PKI using a 98 PKCS#10 request . . . . . . . . . . . . . . . . . . . 40 99 4.1.6. Adding central key pair generation to a certificate 100 request . . . . . . . . . . . . . . . . . . . . . . . 42 101 4.1.6.1. Using key agreement key management technique . . 47 102 4.1.6.2. Using key transport key management technique . . 48 103 4.1.6.3. Using password-based key management technique . . 49 104 4.1.7. Handling delayed enrollment . . . . . . . . . . . . . 50 105 4.2. Revoking a certificate . . . . . . . . . . . . . . . . . 55 106 4.3. Support messages . . . . . . . . . . . . . . . . . . . . 57 107 4.3.1. Get CA certificates . . . . . . . . . . . . . . . . . 59 108 4.3.2. Get root CA certificate update . . . . . . . . . . . 60 109 4.3.3. Get certificate request template . . . . . . . . . . 61 110 5. PKI management entity operations . . . . . . . . . . . . . . 63 111 5.1. Responding to requests . . . . . . . . . . . . . . . . . 64 112 5.1.1. Responding to a certificate request . . . . . . . . . 64 113 5.1.2. Initiating delayed enrollment . . . . . . . . . . . . 65 114 5.1.3. Responding to a confirmation message . . . . . . . . 66 115 5.1.4. Responding to a revocation request . . . . . . . . . 66 116 5.1.5. Responding to a support message . . . . . . . . . . . 66 117 5.2. Forwarding messages . . . . . . . . . . . . . . . . . . . 66 118 5.2.1. Not changing protection . . . . . . . . . . . . . . . 68 119 5.2.2. Adding protection and batching of messages . . . . . 69 120 5.2.2.1. Adding protection to a request message . . . . . 69 121 5.2.2.2. Batching messages . . . . . . . . . . . . . . . . 71 122 5.2.3. Replacing protection . . . . . . . . . . . . . . . . 72 123 5.2.3.1. Not changing any included proof-of-possession . . 73 124 5.2.3.2. Breaking proof-of-possession . . . . . . . . . . 73 125 5.3. Acting on behalf of other PKI entities . . . . . . . . . 74 126 5.3.1. Requesting certificates . . . . . . . . . . . . . . . 74 127 5.3.2. Revoking a certificate . . . . . . . . . . . . . . . 75 128 6. CMP message transport mechanisms . . . . . . . . . . . . . . 75 129 6.1. HTTP transport . . . . . . . . . . . . . . . . . . . . . 76 130 6.2. CoAP transport . . . . . . . . . . . . . . . . . . . . . 78 131 6.3. Piggybacking on other reliable transport . . . . . . . . 80 132 6.4. Offline transport . . . . . . . . . . . . . . . . . . . . 80 133 6.4.1. File-based transport . . . . . . . . . . . . . . . . 80 134 6.4.2. Other asynchronous transport protocols . . . . . . . 81 135 7. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 81 136 8. Security Considerations . . . . . . . . . . . . . . . . . . . 81 137 9. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 82 138 10. References . . . . . . . . . . . . . . . . . . . . . . . . . 82 139 10.1. Normative References . . . . . . . . . . . . . . . . . . 82 140 10.2. Informative References . . . . . . . . . . . . . . . . . 83 141 Appendix A. Example CertReqTemplate . . . . . . . . . . . . . . 85 142 Appendix B. History of changes . . . . . . . . . . . . . . . . . 87 143 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 91 145 1. Introduction 147 [RFC Editor: please delete]: The labels "RFC-CMP-Updates" and "RFC- 148 CMP-Alg" in ASN.1 Syntax needs to be replaced with the RFC numbers of 149 CMP Updates [I-D.ietf-lamps-cmp-updates] and CMP Algorithms 150 [I-D.ietf-lamps-cmp-algorithms], when available. 152 This document specifies PKI management operations supporting machine- 153 to-machine and IoT use cases. Its focus is to maximize automation 154 and interoperability between all involved PKI entities, ranging from 155 end entities (EE) over any number of intermediate PKI management 156 entities such as Registration Authorities (RA) to the CMP endpoints 157 of Certification Authority (CA) systems. This profile makes use of 158 the concepts and syntax specified in CMP [RFC4210], CRMF [RFC4211], 159 CMS [RFC5652], HTTP transfer for CMP [RFC6712], CoAP transfer for CMP 160 [I-D.ietf-ace-cmpv2-coap-transport], CRMF Algorithm Requirements 161 Update [RFC9045], CMP Updates [I-D.ietf-lamps-cmp-updates], and CMP 162 Algorithms [I-D.ietf-lamps-cmp-algorithms]. Especially CMP, CRMF, 163 and CMS are very feature-rich standards, while in most application 164 scenarios only a limited subset of the specified functionality is 165 needed. Additionally, the standards are not always precise enough on 166 how to interpret and implement the described concepts. Therefore, 167 this document aims at tailoring the available options and specifying 168 at an adequate detail how to use them to make the implementation of 169 interoperable automated certificate management as straightforward and 170 lightweight as possible. 172 1.1. How to Read This Document 174 This document has become longer than the authors would have liked it 175 to be. Yet apart from studying Section 3, which contains general 176 requirements, the reader does not have to work through the whole 177 document but can use the guidance in Section 1.7, Section 2.2, and 178 Section 2.3 to figure out which parts of Section 4 to Section 6 are 179 relevant, depending on the PKI management operations and options of 180 interest. 182 1.2. Motivation for a lightweight profile of CMP 184 CMP was standardized in 1999 and is implemented in several PKI 185 products. In 2005, a completely reworked and enhanced version 2 of 186 CMP [RFC4210] and CRMF [RFC4211] has been published, followed by a 187 document specifying a transfer mechanism for CMP messages using HTTP 188 [RFC6712] in 2012. 190 Though CMP is a solid and very capable protocol it is so far not used 191 very widely. The most important reason appears to be that the 192 protocol offers a too large set of features and options. On the one 193 hand, this makes CMP applicable to a very wide range of scenarios, 194 but on the other hand, a full implementation supporting all options 195 is not realistic because this would take undue effort. 197 Moreover, many details of the CMP protocol have been left open or 198 have not been specified in full preciseness. The profiles specified 199 in Appendix D and E of [RFC4210] define some more detailed PKI 200 management operations. Yet the specific needs of highly automated 201 scenarios for a machine-to-machine communication are not covered 202 sufficiently. 204 As also 3GPP and UNISIG already put across, profiling is a way of 205 coping with the challenges mentioned above. To profile means to take 206 advantage of the strengths of the given protocol, while explicitly 207 narrowing down the options it provides to those needed for the 208 purpose(s) at hand and eliminating all identified ambiguities. In 209 this way all the general and applicable aspects of the general 210 protocol are taken over and only the peculiarities of the target 211 scenarios need to be dealt with specifically. 213 Defining a profile for a new target environment takes high effort 214 because the range of available options needs to be well understood 215 and the selected options need to be consistent with each other and 216 suitably cover the intended application scenario. Since most 217 industrial PKI management use cases typically have much in common it 218 is worth sharing this effort, which is the aim of this document. 219 Other standardization bodies can reference this document and do not 220 need to come up with individual profiles from scratch. 222 1.3. Special requirements of industrial and IoT scenarios 224 The profiles specified in Appendix D and E of RFC 4210 [RFC4210] have 225 been developed particularly for managing certificates of human end 226 entities. With the evolution of distributed systems and client- 227 server architectures, certificates for machines and applications on 228 them have become widely used. This trend has strengthened even more 229 in emerging industrial and IoT scenarios. CMP is sufficiently 230 flexible to support them well. 232 Today's IT security architectures for industrial solutions typically 233 use certificates for endpoint authentication within protocols like 234 IPSec, TLS, or SSH. Therefore, the security of these architectures 235 highly relies upon the security and availability of the implemented 236 certificate management operations. 238 Due to increasing security needs in operational networks as well as 239 availability requirements, especially on critical infrastructures and 240 systems with a high number of certificates, a state-of-the-art 241 certificate management system must be constantly available and cost- 242 efficient, which calls for high automation and reliability. 243 Consequently, the NIST Framework for Improving Critical 244 Infrastructure Cybersecurity [NIST.CSWP.04162018] refers to proper 245 processes for issuance, management, verification, revocation, and 246 audit for authorized devices, users, and processes involving identity 247 and credential management. Such PKI management operations according 248 to commonly accepted best practices are also required in 249 IEC 62443-3-3 [IEC.62443-3-3] for security level 2 and higher. 251 Further challenges in many industrial systems are network 252 segmentation and asynchronous communication, while PKI management 253 entities like Certification Authorities (CA) typically are not 254 deployed on-site but in a more protected environment of a data center 255 or trust center. Certificate management must be able to cope with 256 such network architectures. CMP offers the required flexibility and 257 functionality, namely self-contained messages, efficient polling, and 258 support for asynchronous message transfer while retaining end-to-end 259 security. 261 1.4. Existing CMP profiles 263 As already stated, RFC 4210 [RFC4210] contains profiles with 264 mandatory and optional PKI management operations in Appendix D and E. 265 Those profiles focus on management of human user certificates and 266 only partly address the specific needs of certificate management 267 automation for unattended devices or machine-to-machine application 268 scenarios. 270 Both Appendixes D and E focus on EE-to-RA/CA PKI management 271 operations and do not address further profiling of RA-to-CA 272 communication as typically needed for full backend automation. All 273 requirements regarding algorithm support for RFC 4210 Appendix D and 274 E [RFC4210] have been updated by CMP Algorithms Section 7.1 275 [I-D.ietf-lamps-cmp-algorithms]. 277 3GPP makes use of CMP [RFC4210] in its Technical Specification 33.310 278 [ETSI-3GPP.33.310] for automatic management of IPSec certificates in 279 3G, LTE, and 5G backbone networks. Since 2010, a dedicated CMP 280 profile for initial certificate enrollment and certificate update 281 operations between EE and RA/CA is specified in that document. 283 UNISIG has included a CMP profile for enrollment of TLS certificates 284 in the Subset-137 specifying the ETRAM/ETCS on-line key management 285 for train control systems [UNISIG.Subset-137] in 2015. 287 Both standardization bodies tailor CMP [RFC4210], CRMF [RFC4211], and 288 HTTP transfer for CMP [RFC6712] for highly automated and reliable PKI 289 management operations for unattended devices and services. 291 1.5. Compatibility with existing CMP profiles 293 The profile specified in this document is compatible with RFC 4210 294 Appendixes D and E (PKI Management Message Profiles) [RFC4210], with 295 the following exceptions: 297 * signature-based protection is the default protection; an initial 298 PKI management operation may also use MAC-based protection, 300 * certification of a second key pair within the same PKI management 301 operation is not supported, 303 * proof-of-possession (POPO) with self-signature of the certTemplate 304 according to RFC 4211 Section 4.1 [RFC4211] clause 3 is the 305 recommended default POPO method (deviations are possible for EEs 306 when requesting central key generation, for RAs when using 307 raVerified, and if the newly generated keypair is technically not 308 capable to generate digital signatures), 310 * confirmation of newly enrolled certificates may be omitted, and 312 * all PKI management operations consist of request-response message 313 pairs originating at the EE, i.e., announcement messages 314 (requiring the push model, a CMP server on the EE) are excluded in 315 favor of a lightweight implementation on the EE. 317 The profile specified in this document is compatible with the CMP 318 profile for 3G, LTE, and 5G network domain security and 319 authentication framework [ETSI-3GPP.33.310], except that: 321 * protection of initial PKI management operations may be MAC-based, 323 * the subject field is mandatory in certificate templates, and 325 * confirmation of newly enrolled certificates may be omitted. 327 The profile specified in this document is compatible with the CMP 328 profile for on-line key management in rail networks as specified in 329 UNISIG Subset-137 [UNISIG.Subset-137], except that: 331 * A certificate enrollment request message consists of only one 332 certificate request (CertReqMsg). 334 * RFC 4210 [RFC4210] requires that the messageTime is Greenwich Mean 335 Time coded as generalizedTime. 337 Note: As UNISIG Subset-137 Table 5 [UNISIG.Subset-137] explicitly 338 states that the messageTime in required to be "UTC time", it is 339 not clear if this means a coding as UTCTime or generalizedTime and 340 if other time zones than Greenwich Mean Time shall be allowed. 341 Both time formats are described in RFC 5280 Section 4.1.2.5 342 [RFC5280]. 344 * The same type of protection is required to be used for all 345 messages of one PKI management operation. This means, in case the 346 request message protection is MAC-based, also the response, 347 certConf, and pkiConf messages must have a MAC-based protection. 349 * Use of caPubs is not required but typically allowed in combination 350 with MAC-based protected PKI management operations. On the other 351 hand UNISIG Subset-137 Table 12 [UNISIG.Subset-137] requires using 352 caPubs. 354 Note: In case of UNISIG Subset-137 the response to a MAC-protected 355 request shall be signature-based. The signature-based protection 356 uses a certificate issued under the same root CA that is to be 357 transported in the caPubs field. This is not a secure delivery of 358 the root CA certificate. 360 * This profile requires that the certConf message has one CertStatus 361 element where the statusInfo field is recommended. 363 Note: In contrast, UNISIG Subset-137 Table 18 [UNISIG.Subset-137] 364 requires that the certConf message has one CertStatus element 365 where the statusInfo field must be absent. This precludes sending 366 a negative certConf message in case the EE rejects the newly 367 enrolled certificate. This results in violating the general rule 368 that a certificate request transaction must include a certConf 369 message (since moreover, using implicitConfirm is not allowed 370 there, neither). 372 1.6. Scope of this document 374 To minimize ambiguity and complexity through needless variety, this 375 document specifies exhaustive requirements on generating PKI 376 management messages on the sender side. On the other hand, it gives 377 only minimal requirements on checks by the receiving side and how to 378 handle error cases. 380 Especially on the EE side this profile aims at a lightweight 381 implementation. This means that the number of PKI management 382 operations implementations are reduced to a reasonable minimum to 383 support typical certificate management use cases in industrial 384 machine-to-machine environments. On the EE side only limited 385 resources are expected, while on the side of the PKI management 386 entities the profile accepts higher requirements. 388 For the sake of interoperability and robustness, implementations 389 should, as far as security is not affected, adhere to Postel's law: 390 "Be conservative in what you do, be liberal in what you accept from 391 others" (often reworded as: "Be conservative in what you send, be 392 liberal in what you receive"). 394 When in Section 3, Section 4, and Section 5 a field of the ASN.1 395 syntax as defined in CMP [RFC4210], CRMF [RFC4211], CMS [RFC5652], 396 and CMP Updates [I-D.ietf-lamps-cmp-updates] is not explicitly 397 specified, it SHOULD not be used by the sending entity. The 398 receiving entity MUST NOT require its absence and if present MUST 399 gracefully handle its presence. 401 1.7. Structure of this document 403 Section 2 introduces the general PKI architecture and approach to 404 certificate management that is assumed in this document. Then it 405 lists the PKI management operations specified in this document, 406 partitioning them into mandatory, recommended, and optional ones. 408 Section 3 profiles the generic aspects of the PKI management 409 operations specified in detail in Section 4 and Section 5 to minimize 410 redundancy in the description and to ease implementation. This 411 covers the general structure and protection of messages, as well as 412 generic prerequisites, validation, and error handling. 414 Section 4 profiles the exchange of CMP messages between an EE and the 415 PKI management entity. There are various flavors of certificate 416 enrollment requests, optionally with polling, central key generation, 417 revocation, and general support PKI management operations. 419 Section 5 profiles responding to requests, exchange between PKI 420 management entities, and operations on behalf of other PKI entities. 421 This may include delayed delivery of messages, which involves polling 422 for certificate responses, and nesting of messages. 424 Section 6 outlines several mechanisms for CMP message transfer, 425 including HTTP-based transfer as already specified in RFC 6712 426 [RFC6712] optionally using TLS, and offline file-based transport. 427 CoAP-based transport as specified in 428 [I-D.ietf-ace-cmpv2-coap-transport] and piggybacking CMP messages are 429 also briefly addressed. 431 1.8. Convention and Terminology 433 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 434 "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and 435 "OPTIONAL" in this document are to be interpreted as described in BCP 436 14 [RFC2119] [RFC8174] when, and only when, they appear in all 437 capitals, as shown here. 439 Technical terminology is used in conformance with RFC 4210 [RFC4210], 440 RFC 4211 [RFC4211], RFC 5280 [RFC5280], and IEEE 802.1AR 441 [IEEE.802.1AR_2018]. The following key words are used: 443 CA: Certification authority, which issues certificates. 445 RA: Registration authority, an optional PKI component to which a CA 446 delegates certificate management functions such as end entity 447 authentication and authorization checks for incoming requests. 448 An RA can also provide conversion between various certificate 449 management protocols and other protocols providing some 450 operations related to certificate management. 452 LRA: Local registration authority, a specific form of RA with 453 proximity to the end entities. 455 Note: For ease of reading, this document uses the term "RA" 456 also for LRAs in all cases where the difference is not 457 relevant. 459 KGA: Key generation authority, an optional system component, 460 typically co-located with an RA or CA, that offers key 461 generation services to end entities. 463 EE: End entity, typically a device or service that holds public- 464 private key pair for which it manages a public-key certificate. 465 An identifier for the EE is given as the subject of its 466 certificate. 468 The following terminology is reused from RFC 4210 [RFC4210], as 469 follows: 471 PKI management operation: All CMP messages belonging to a single 472 transaction. The transaction is 473 identified by the transactionID field of 474 the message headers. 476 PKI management entity: A non-EE PKI entity, i.e., RA or CA. 478 PKI entity: An EE or PKI management entity. 480 2. Architecture and use cases 482 2.1. Solution architecture 484 To facilitate secure automatic certificate enrollment, the device 485 hosting an EE is typically equipped with a manufacturer-issued device 486 certificate. Such a certificate is typically installed during 487 production and is meant to identify the device throughout its 488 lifetime. This certificate can be used to protect the initial 489 enrollment of operational certificates after installation of the EE 490 in its operational environment. In contrast to the manufacturer- 491 issued device certificate, operational certificates are issued by the 492 owner or operator of the device to identify the device or one of its 493 components for operational use, e.g., in a security protocol like 494 IPSec, TLS, or SSH. In IEEE 802.1AR [IEEE.802.1AR_2018] a 495 manufacturer-issued device certificate is called IDevID certificate 496 and an operational certificate is called LDevID certificate. 498 Note: According to IEEE 802.1AR [IEEE.802.1AR_2018] a DevID comprises 499 the triple of the certificate, the corresponding private key, and the 500 certificate chain. 502 All certificate management operations specified in this document 503 follow the pull model, i.e., are initiated by an EE (or by an RA 504 acting as an EE). The EE creates a CMP request message, protects it 505 using some asymmetric credential or shared secret information and 506 sends it to its locally reachable PKI management entity. This PKI 507 management entity may be a CA or more typically an RA, which checks 508 the request, responds to it itself, or forwards the request upstream 509 to the next PKI management entity. In case an RA changes the CMP 510 request message header or body or wants to demonstrate successful 511 verification or authorization, it can apply a protection of its own. 512 Especially the communication between an LRA and RA can be performed 513 synchronously or asynchronously. Synchronous communication describes 514 a timely uninterrupted communication between two communication 515 partners, while asynchronous communication is not performed in a 516 timely consistent manner, e.g., because of a delayed message 517 delivery. 519 +-----+ +-----+ +-----+ +-----+ 520 | | | | | | | | 521 | EE |<---------->| LRA |<-------------->| RA |<---------->| CA | 522 | | | | | | | | 523 +-----+ +-----+ +-----+ +-----+ 525 synchronous (a)synchronous (a)synchronous 526 +----connection----+------connection------+----connection----+ 528 operators service partner 529 +---------on site--------+----back-end services-----+-trust center-+ 531 Figure 1: Certificate management architecture example 533 In operational environments the certificate management architecture 534 can have multiple LRAs bundling requests from multiple EEs at 535 dedicated locations and one (or more than one) central RA aggregating 536 the requests from the LRAs. Every LRA in this scenario has shared 537 secret information (one per EE) for MAC-based protection or a CMP 538 protection key and certificate allowing it to (re-)protect CMP 539 messages it processes. The figure above shows an architecture 540 example with at least one LRA, RA, and CA. It is also possible not 541 to have an RA or LRA or that there is no CA with a CMP interface. 542 Depending on the network infrastructure, the message transfer between 543 PKI management entities may be based on synchronous online 544 connections, delayed asynchronous connections, or even offline (e.g., 545 file-based) transfer. 547 Note: CMP response messages could also be used proactively to 548 implement the push model towards the EE. In this case the EE acts as 549 receiver, not initiating the interaction with the PKI. Also, when 550 using a commissioning tool or a registrar agent as described in: 551 Support of asynchronous Enrollment in Bootstrapping Remote Secure Key 552 Infrastructures (BRSKI) [I-D.ietf-anima-brski-async-enroll], 553 certificate enrollment in a push model is needed. CMP in general and 554 the messages specified in this profile offer all required 555 capabilities, but the message flow and state machine as described in 556 Section 4 must be adapted to implement a push model. 558 Third-party CAs may implement other variants of CMP, different 559 standardized protocols, or even proprietary interfaces for 560 certificate management. Therefore, the RA may need to adapt the 561 exchanged CMP messages to the flavor of certificate management 562 interaction required by the CA. 564 2.2. Supported PKI management operations 566 Following the scope outlined in Section 1.6, this section gives a 567 brief overview of the PKI management operations specified in 568 Section 4 and Section 5 and states whether implementation by 569 compliant EEs or PKI management entities is mandatory, recommended, 570 or optional. 572 2.2.1. Mandatory PKI management operations 574 The set of mandatory PKI management operations in this document is 575 intentionally lean to help for keeping development effort low and to 576 enable use in memory-constrained devices. 578 +=====================================+=========+ 579 | PKI management operations | Section | 580 +=====================================+=========+ 581 | Requesting a certificate from a new | Section | 582 | PKI with signature-based protection | 4.1.1 | 583 +-------------------------------------+---------+ 584 | Updating an existing certificate | Section | 585 | with signature-based protection | 4.1.3 | 586 +-------------------------------------+---------+ 588 Table 1: Mandatory End Entity PKI management 589 operations 591 +===============================================+=================+ 592 | PKI management operations | Section | 593 +===============================================+=================+ 594 | Responding to a certificate request | Section 5.1 | 595 +-----------------------------------------------+-----------------+ 596 | Responding to a confirmation message | Section 5.1.3 | 597 +-----------------------------------------------+-----------------+ 598 | Forwarding messages - not changing protection | Section 5.2.1 | 599 +-----------------------------------------------+-----------------+ 600 | Adding protection to a request message | Section 5.2.2.1 | 601 +-----------------------------------------------+-----------------+ 603 Table 2: Mandatory PKI management entity operations 605 2.2.2. Recommended PKI management operations 607 Additional recommended PKI management operations support some more 608 complex scenarios, that are considered beneficial for environments 609 with more specific demand or boundary conditions. 611 +=================================+=========+ 612 | PKI management operations | Section | 613 +=================================+=========+ 614 | Requesting a certificate from a | Section | 615 | PKI with MAC-based protection | 4.1.4 | 616 +---------------------------------+---------+ 617 | Revoking a certificate | Section | 618 | | 4.2 | 619 +---------------------------------+---------+ 621 Table 3: Recommended End Entity PKI 622 management operations 624 +====================================+===============+ 625 | PKI management operations | Section | 626 +====================================+===============+ 627 | Responding to a revocation request | Section 5.1.4 | 628 +------------------------------------+---------------+ 629 | Acting on behalf of other PKI | Section 5.3.2 | 630 | entities - revoking a certificate | | 631 +------------------------------------+---------------+ 633 Table 4: Recommended PKI management entity operations 635 2.2.3. Optional PKI management operations 637 The optional PKI management operations support specific scenarios 638 seen only in some environments with special requirements. 640 +========================================================+=========+ 641 | PKI management operations | Section | 642 +========================================================+=========+ 643 | Requesting an additional certificate with signature- | Section | 644 | based protection | 4.1.2 | 645 +--------------------------------------------------------+---------+ 646 | Requesting a certificate from a legacy PKI using a | Section | 647 | PKCS#10 request | 4.1.5 | 648 +--------------------------------------------------------+---------+ 649 | Adding central key generation to a certificate | Section | 650 | request. (If central key generation is supported, the | 4.1.6 | 651 | key agreement key management technique is REQUIRED to | | 652 | be supported, and the key transport and password-based | | 653 | key management techniques are OPTIONAL.) | | 654 +--------------------------------------------------------+---------+ 655 | Handling delayed enrollment | Section | 656 | | 4.1.7 | 657 +--------------------------------------------------------+---------+ 658 | Support messages - get CA certificates, get a trust | Section | 659 | anchor updates, e.g., root CA certificate updates, and | 4.3 | 660 | get a certificate request template | | 661 +--------------------------------------------------------+---------+ 662 | Acting on behalf of other PKI entities - requesting | Section | 663 | certificates | 5.3.1 | 664 +--------------------------------------------------------+---------+ 666 Table 5: Optional End Entity PKI management operations 668 +===============================================+=========+ 669 | PKI management operations | Section | 670 +===============================================+=========+ 671 | Forwarding messages - replacing protection, | Section | 672 | not changing any included proof-of-possession | 5.2.3.1 | 673 +-----------------------------------------------+---------+ 674 | Forwarding messages - replacing protection, | Section | 675 | breaking proof-of-possession | 5.2.3.2 | 676 +-----------------------------------------------+---------+ 677 | Batching messages | Section | 678 | | 5.2.2.2 | 679 +-----------------------------------------------+---------+ 680 | Initiating delayed enrollment | Section | 681 | | 5.1.2 | 682 +-----------------------------------------------+---------+ 684 Table 6: Optional PKI management entity operations 686 2.3. CMP message transport 688 On different links between PKI entities, e.g., EE-RA and RA-CA, 689 different transport MAY be used. As CMP does not have specific needs 690 regarding message transport, virtually any reliable transport 691 mechanism can be used, e.g., HTTP, CoAP, and offline file-based 692 transport. Therefore, this document does not require any specific 693 transport protocol to be supported by conforming implementations. 695 HTTP transfer is RECOMMENDED to use for all PKI entities, yet full 696 flexibility is retained to choose whatever transport is suitable, for 697 instance for devices and system architectures with special 698 constraints. 700 +================+=============+ 701 | Transport | Section | 702 +================+=============+ 703 | HTTP transport | Section 6.1 | 704 +----------------+-------------+ 706 Table 7: Recommended 707 transport mechanisms 709 +==========================================+=============+ 710 | Transport | Section | 711 +==========================================+=============+ 712 | Offline transport | Section 6.4 | 713 +------------------------------------------+-------------+ 714 | CoAP transport | Section 6.2 | 715 +------------------------------------------+-------------+ 716 | Piggybacking on other reliable transport | Section 6.3 | 717 +------------------------------------------+-------------+ 719 Table 8: Optional transport mechanisms 721 3. Generic aspects of the PKI message 723 This section covers the generic aspects of the PKI management 724 operations specified in Section 4 and Section 5 as upfront general 725 requirements to minimize redundancy in the description and to ease 726 implementation. 728 As described in Section 5.1 of RFC 4210 [RFC4210], all CMP messages 729 have the following general structure: 731 +--------------------------------------------+ 732 | PKIMessage | 733 | +----------------------------------------+ | 734 | | header | | 735 | +----------------------------------------+ | 736 | +----------------------------------------+ | 737 | | body | | 738 | +----------------------------------------+ | 739 | +----------------------------------------+ | 740 | | protection (OPTIONAL) | | 741 | +----------------------------------------+ | 742 | +----------------------------------------+ | 743 | | extraCerts (OPTIONAL) | | 744 | +----------------------------------------+ | 745 +--------------------------------------------+ 747 Figure 2: CMP message structure 749 The general contents of the message header, protection, and 750 extraCerts fields are specified in the following three subsections. 752 In case a specific PKI management operation needs different contents 753 in the header, protection, or extraCerts fields, the differences are 754 described in the respective subsections. 756 The CMP message body contains the PKI management operation-specific 757 information. It is described in Section 4 and Section 5. 759 The generic prerequisites needed by the PKI entities in order to be 760 able to perform PKI management operations are described in 761 Section 3.4. 763 The generic validation steps to be performed by PKI entities on 764 receiving a CMP message are described in Section 3.5. 766 The generic aspects of handling and reporting errors are described in 767 Section 3.6. 769 3.1. General description of the CMP message header 771 This section describes the generic header fields of all CMP messages 772 with signature-based protection. 774 In case a message has MAC-based protection the changes are described 775 in Section 4.1.4. The variations will affect the fields sender, 776 protectionAlg, and senderKID. 778 Any PKI management operation-specific fields or variations are 779 described in Section 4 and 5. 781 header 782 pvno REQUIRED 783 -- MUST be 3 to indicate CMP v3 in all cases where EnvelopedData 784 -- is supported and expected to be used in the current 785 -- PKI management operation 786 -- MUST be 3 to indicate CMP v3 in certConf messages when using 787 -- the hashAlg field 788 -- MUST be 2 to indicate CMP v2 in all other cases 789 -- For details on version negotiation see RFC-CMP-Updates 790 sender REQUIRED 791 -- SHOULD contain a name representing the originator of the 792 -- message; otherwise, the NULL-DN (a zero-length 793 -- SEQUENCE OF RelativeDistinguishedNames) MUST be used 794 -- SHOULD be the subject of the CMP protection certificate, i.e., 795 -- the certificate for the private key used to sign the message 796 -- In a multi-hop scenario, the receiving entity SHOULD not rely 797 -- on the correctness of the sender field. 798 recipient REQUIRED 799 -- SHOULD be the name of the intended recipient; otherwise, the 800 -- NULL-DN MUST be used 801 -- In the first message of a PKI management operation: 802 -- SHOULD be the subject DN of the CA the PKI management 803 -- operation is requested from 804 -- In all other messages: 805 -- SHOULD contain the value of the sender field of the previous 806 -- message in the same PKI management operation 807 -- The recipient field SHALL be handled gracefully by the 808 -- receiving entity, because in a multi-hop scenario its 809 -- correctness cannot be guaranteed. 810 messageTime RECOMMENDED 811 -- MUST be the time at which the message was produced, if present 812 protectionAlg REQUIRED 813 -- MUST be an algorithm identifier indicating the algorithm 814 -- used for calculating the protection bits 815 -- If it is a signature algorithm its type MUST be a 816 -- MSG_SIG_ALG as specified in [RFC-CMP-Alg] Section 3 and 817 -- MUST be consistent with the subjectPublicKeyInfo field of 818 -- the protection certificate 819 -- If it is a MAC algorithm its type MUST be a MSG_MAC_ALG as 820 -- specified in [RFC-CMP-Alg] Section 6.1 821 senderKID RECOMMENDED 822 -- MUST be the SubjectKeyIdentifier of the CMP protection 823 -- certificate 824 transactionID REQUIRED 825 -- In the first message of a PKI management operation: 827 -- MUST be 128 bits of random data, to minimize the probability 828 -- of having the transactionID already in use at the server 829 -- In all other messages: 830 -- MUST be the value from the previous message in the same 831 -- PKI management operation 832 senderNonce REQUIRED 833 -- MUST be cryptographically secure and fresh 128 random bits 834 recipNonce RECOMMENDED 835 -- If this is the first message of a transaction: SHOULD be 836 -- absent 837 -- In all other messages: MUST be present and contain the value 838 -- of the senderNonce of the previous message in the same 839 -- transaction 840 generalInfo OPTIONAL 841 implicitConfirm OPTIONAL 842 -- The extension is optional in ir/cr/kur/p10cr requests and 843 -- ip/cp/kup response messages and PROHIBTED in other types of 844 -- messages 845 -- Added to request messages to request omission of the certConf 846 -- message 847 -- Added to response messages to grant omission of the certConf 848 -- message 849 -- See [RFC4210] Section 5.1.1.1. 850 ImplicitConfirmValue REQUIRED 851 -- ImplicitConfirmValue MUST be NULL 852 rootCaCert OPTIONAL 853 -- MAY be present in genm messages of type id-it-rootCaKeyUpdate 854 -- MUST be omitted in all other messages 855 -- See [RFC-CMP-Updates] 856 RootCaCertValue REQUIRED 857 -- contains the root CA certificate for which an update is 858 -- requested 859 certProfile OPTIONAL 860 -- MAY be present in ir/cr/kur/p10cr and in genm messages of type 861 -- id-it-certReqTemplate 862 -- MUST be omitted in all other messages 863 -- See [RFC-CMP-Updates] 864 CertProfileValue REQUIRED 865 -- MUST contain exactly one UTF8String element 866 -- MUST contain the name of a certificate profile 868 3.2. General description of the CMP message protection 870 This section describes the generic protection field contents of all 871 CMP messages with signature-based protection. The private key used 872 to sign a CMP message is called "protection key" and the related 873 certificate is called "protection certificate". Any included 874 keyUsage extension SHOULD allow digitalSignature. 876 protection RECOMMENDED 877 -- MUST contain the signature calculated using the private key 878 -- of the entity protecting the message. The signature 879 -- algorithm used MUST be given in the protectionAlg field. 881 Generally, CMP message protection is required for CMP messages, but 882 there are cases where protection of error messages specified in 883 Section 3.6 is not possible and therefore MAY be omitted. 885 For MAC-based protection as specified in Section 4.1.4 major 886 differences apply as described there. 888 The CMP message protection provides, if available, message origin 889 authentication and integrity protection for the header and body. The 890 CMP message extraCerts field is not covered by this protection. 892 Note: The extended key usages described in CMP Updates 893 [I-D.ietf-lamps-cmp-updates] can be used for authorization of a 894 sending PKI management entity. 896 3.3. General description of CMP message extraCerts 898 This section describes the generic extraCerts field of all CMP 899 messages with signature-based protection. Any specific requirements 900 on the extraCerts are specified in the respective PKI management 901 operation. 903 extraCerts 904 -- SHOULD contain the CMP protection certificate together with 905 -- its chain, if needed 906 -- If present, the first certificate in this field MUST be 907 -- the CMP protection certificate followed by its chain 908 -- where each element SHOULD directly certify the one 909 -- immediately preceding it. 910 -- Self-signed certificates SHOULD be omitted from extraCerts, 911 -- unless they are the same as the protection certificate and 912 -- MUST NOT be trusted based on their inclusion in any case 914 Note: For maximum compatibility, all implementations SHOULD be 915 prepared to handle potentially additional certificates and arbitrary 916 orderings of the certificates. 918 3.4. Generic PKI management operation prerequisites 920 This subsection describes what is generally needed by the PKI 921 entities to be able to perform PKI management operations. 923 Identification of PKI entities: 925 * Each EE SHOULD know its own identity to fill the sender field. 927 * Each EE SHOULD know the intended recipient of its requests to fill 928 the recipient field, e.g., the name of the addressed CA. 930 Note: This name may be established using an enrollment voucher, 931 e.g., [RFC8366], the issuer field from a CertReqTemplate response 932 message content, or by other configuration means. 934 Routing of CMP messages: 936 * Each PKI entity sending messages upstream MUST know the address 937 needed for transporting messages to the next PKI management 938 entity. 940 Note: This address may depend on the recipient, the certificate 941 profile, and on the used transport mechanism. 943 Authentication of PKI entities: 945 * Each PKI entity MUST have credentials to authenticate itself. For 946 signature-based protection it MUST have a private key and the 947 corresponding certificate along with its chain. 949 * Each PKI entity MUST be able to establish trust in PKI it receives 950 responses from. When signature-based protection is used, it MUST 951 have the trust anchor(s) and any certificate status information 952 needed to perform path validation of CMP protection certificates 953 used for signature-based protection. 955 Note: A trust anchor usually is a root certificate of the PKI 956 addressed by the requesting EE. It may be established by 957 configuration or in an out-of-band manner. For an EE it may be 958 established using an enrollment voucher [RFC8366] or in-band of 959 CMP by the caPubs field in a certificate response message. 961 Authorization of PKI management operations: 963 * Each EE or RA MUST have sufficient information to be able to 964 authorize the PKI management entity for performing the upstream 965 PKI management operation. 967 Note: This may be achieved for example by using the cmcRA extended 968 key usage in server certificates, by local configuration such as 969 specific name patterns for subject DN or SAN portions that may 970 identify an RA, and/or by having a dedicated PKI Infrastructure 971 root CA usable only for authenticating PKI management entities. 973 * Each PKI management entity MUST have sufficient information to be 974 able to authorize the downstream PKI entity requesting the PKI 975 management operation. 977 Note: For authorizing an RA the same examples apply as above. The 978 authorization of EEs can be very specific to the application 979 domain and may involve information from configuration or inventory 980 database. It may involve, e.g., the issuer information of the EE 981 certificate, specific contents of the CMP protection certificate 982 used by the EE such as name patterns of subject DN or SAN 983 portions, shared secret information, and other types of 984 credentials and evidence potentially communicated out-of-band. 986 3.5. Generic validation of a PKI message 988 This section describes generic validation steps of each PKI entity 989 receiving a PKI request or response message before any further 990 processing or forwarding. If a PKI management entity decides to 991 terminate a PKI management operation because a check failed, it MUST 992 send a negative response or an error message as described in 993 Section 3.6. The PKIFailureInfo bits given below in parentheses MAY 994 be used in the failInfo field of the PKIStatusInfo as described in 995 Section 3.6.4, see also RFC 4210 Appendix F [RFC4210]. 997 All PKI message header fields not mentioned in this section like the 998 recipient and generalInfo fields SHOULD be handled gracefully on 999 reception. 1001 The following list describes the basic set of message input 1002 validation steps. Without these checks the protocol becomes 1003 dysfunctional. 1005 * The formal ASN.1 syntax of the whole message MUST be compliant 1006 with the definitions given in CMP [RFC4210], CRMF [RFC4211], 1007 RFC 5652 [RFC5652], and CMP Updates [I-D.ietf-lamps-cmp-updates]. 1008 (failInfo: badDataFormat) 1010 * The pvno MUST be cmp2000(2) or cmp2021(3). (failInfo bit: 1011 unsupportedVersion) 1013 * The transactionID MUST be present. (failInfo bit: badDataFormat) 1015 * The PKI message body type MUST be one of the message types 1016 supported by the receiving PKI entity and MUST be allowed in the 1017 current state of the PKI management operation identified by the 1018 given transactionID. (failInfo bit: badRequest) 1020 The following list describes the set of message input validation 1021 steps required to ensure secure protocol operation: 1023 * The senderNonce MUST be present and MUST contain at least 128 bits 1024 of data. (failInfo bit: badSenderNonce) 1026 * Unless the PKI message is the first message of a PKI management 1027 operation, 1029 - the recipNonce MUST be present and MUST equal the senderNonce 1030 of the previous message. (failInfo bit: badRecipientNonce) 1032 * The message protection MUST be validated: 1034 - The protection MUST be signature-based except if MAC-based 1035 protection is used as described in Section 4.1.4and for some 1036 error messages as described in Section 3.6.4. (failInfo bit: 1037 wrongIntegrity) 1039 - The senderKID SHOULD identify the key material used for 1040 verifying the message protection. (failInfo bit: 1041 badMessageCheck) 1043 - The protection, if present, MUST be validated successfully. If 1044 signature-based protection is used, the CMP protection 1045 certificate MUST be successfully validated including path 1046 validation using a trust anchor and MUST be authorized 1047 according to local policies. If the keyUsage extension is 1048 present in the CMP protection certificate the digitalSignature 1049 bit SHOULD be set. (failInfo bit: badAlg, badMessageCheck, or 1050 signerNotTrusted) 1052 - The sender of a request message MUST be authorized for 1053 requesting the operation according to PKI policies. (failInfo 1054 bit: notAuthorized) 1056 Note: The requirements for checking certificates given in RFC 5280 1057 [RFC5280] MUST be followed for signature-based CMP message 1058 protection. Unless the message is a positive ip/cp/kup where the 1059 issuing CA certificate of the newly enrolled certificate is the same 1060 as the CMP protection certificate of that message, certificate status 1061 checking SHOULD be performed on the CMP protection certificates. 1063 Depending on local policies, one or more of the input validation 1064 checks described below need to be implemented: 1066 * If signature-based protection is used, the sender field SHOULD 1067 match the subject of the CMP protection certificate. (failInfo 1068 bit: badMessageCheck) 1070 * If the messageTime is present, it SHOULD be close to the current 1071 time. (failInfo bit: badTime) 1073 3.6. Error handling 1075 This section describes how a PKI entity handles error conditions on 1076 messages it receives. Each error condition SHOULD be logged 1077 appropriately. 1079 3.6.1. Reporting error conditions upstream 1081 An EE SHALL NOT send error messages. PKI management entities SHALL 1082 NOT send error messages in upstream direction, either. 1084 In case an EE rejects a newly issued certificate contained in an ip, 1085 cp, or kup message and implicit confirmation has not been granted, 1086 the EE MUST report this using a certConf message with "rejection" 1087 status and await the pkiConf response as described in Section 4.1.1. 1089 On all other error conditions regarding response messages, the EE or 1090 PKI management entity MUST regard the current PKI management 1091 operation as terminated with failure. The error conditions include 1093 * invalid response message header, body type, protection, or 1094 extraCerts according to the checks described in Section 3.5, 1096 * any issue detected with response message contents, 1098 * receipt of an error message from upstream, 1100 * timeout occurred while waiting for a response, 1102 * rejection of a newly issued certificate while implicit 1103 confirmation has been granted. 1105 Upstream PKI management entities will not receive any CMP message to 1106 learn that the PKI management operation has been terminated. In case 1107 they expect a further message from the EE, a connection interruption 1108 or timeout will occur. Then they also MUST regard the current PKI 1109 management operation as terminated with failure and MUST not attempt 1110 to send an error message downstream. 1112 3.6.2. Reporting error conditions downstream 1114 In case the PKI management entity detects an error condition, e.g., 1115 rejecting the request due to policy decision, in the body of an ir, 1116 cr, p10cr, kur, or rr message received from downstream, it SHOULD 1117 report the error in the specific response message, i.e., an ip, cp, 1118 kup, or rp with "rejection" status, as described in Section 4.1.1 and 1119 Section 4.2. This can also happen in case of polling. 1121 In case the PKI management entity detects any other error condition 1122 on requests, including pollReq, certConf, genm, and nested messages, 1123 received from downstream and on responses received from upstream, 1124 such as invalid message header, body type, protection, or extraCerts 1125 according to the checks described in Section 3.5 it MUST report them 1126 downstream in the form of an error message as described in 1127 Section 3.6.4. 1129 3.6.3. Handling error conditions on nested messages used for batching 1131 Batching of messages using nested messages as described in 1132 Section 5.2.2.2 requires special error handling. 1134 If the error condition is on an upstream nested message containing 1135 batched requests, it MUST not attempt to respond to the individual 1136 requests included in it. 1138 In case a PKI management entity receives an error message in response 1139 to a nested message, it must propagate the error by responding with 1140 an error message to each of the request messages contained in the 1141 nested message. 1143 In case a PKI management entity detects an error condition on the 1144 downstream nested message received in response to a nested message 1145 sent before, it MAY ignore this error condition and handle the 1146 response as described in Section 5.2.2.2. Otherwise, it MUST 1147 propagate the error by responding with an error message to each of 1148 the requests contained in the nested message it sent originally. 1150 3.6.4. Reporting error conditions 1152 When sending any kind of negative response, including error messages, 1153 a PKI entity MUST indicate the error condition in the PKIStatusInfo 1154 structure of the respective message as described below. It then MUST 1155 regard the current PKI management operation as terminated with 1156 failure. 1158 The PKIStatusInfo structure is used to report errors. It may be part 1159 of various message types, in particular: certConf, ip, cp, kup, and 1160 error. The PKIStatusInfo structure consists of the following fields: 1162 * status: Here the PKIStatus value "rejection" MUST be used. 1164 * statusString: Here any human-readable valid value for logging or 1165 to display via a user interface SHOULD be added. 1167 * failInfo: Here the PKIFailureInfo bits MAY be used in the way 1168 explained in Appendix F of RFC 4210 [RFC4210]. PKIFailureInfo 1169 bits regarding the validation described in Section 3.5 are 1170 referenced there. The PKIFailureInfo bits referenced in 1171 Section 5.1 and Section 6 are described here: 1173 - badCertId: A kur, certConf, or rr message references an unknown 1174 certificate 1176 - badPOP: An ir/cr/p10cr/kur contains an invalid proof-of- 1177 possession 1179 - certRevoked: Revocation requested for a certificate already 1180 revoked 1182 - badCertTemplate: The contents of a certificate request are not 1183 accepted, e.g., a field is missing or has a non-acceptable 1184 value or the given public key is already in use in some other 1185 certificate (depending on policy). 1187 - transactionIdInUse: This is sent by a PKI management entity in 1188 case the received request contains a transaction ID that has 1189 already been used for another transaction. An EE receiving 1190 such error message SHOULD resend the request in a new 1191 transaction using a different transaction ID. 1193 - notAuthorized: The sender of a request message is not 1194 authorized for requesting the operation. 1196 - systemUnavail: This is sent by a PKI management entity in case 1197 a back-end system is not available. 1199 - systemFailure: This is sent by a PKI management entity in case 1200 a back-end system is currently not functioning correctly. 1202 An EE receiving a systemUnavail or systemFailure failInfo SHOULD 1203 resend the request in a new transaction after some time. 1205 Detailed error message description: 1207 Error Message -- error 1209 Field Value 1211 header 1212 -- As described in Section 3.1 1214 body 1215 -- The message sent by an PKI management entity error that 1216 -- occurred 1217 error REQUIRED 1218 pKIStatusInfo REQUIRED 1219 status REQUIRED 1220 -- MUST have the value "rejection" 1221 statusString RECOMMENDED 1222 -- SHOULD be any human-readable text for debugging, logging 1223 -- or to display in a GUI 1224 failInfo OPTIONAL 1225 -- MAY be present and contain the relevant PKIFailureInfo bits 1227 protection REQUIRED 1228 -- As described in Section 3.2 1230 extraCerts OPTIONAL 1231 -- As described in Section 3.3 1233 4. End Entity PKI management operations 1235 This chapter focuses on the communication of an EE with the PKI 1236 management entity it directly talks to. Depending on the network and 1237 PKI solution, this can be an RA or directly a CA. Handling of a 1238 message by a PKI management entity is described in Section 5. 1240 The PKI management operations specified in this section cover the 1241 following: 1243 * Requesting a certificate with variations like initial enrollment, 1244 certificate updates, central key generation, and MAC-based 1245 protection 1247 * Revoking a certificate 1249 * Support messages 1251 These operations mainly specify the message body of the CMP messages 1252 and utilize the specification of the message header, protection and 1253 extraCerts as specified in Section 3. 1255 The following diagram shows the EE state machine covering all PKI 1256 management operations described in this section including negative 1257 responses, while no generic error messages are shown. 1259 On receiving messages from upstream, the EE MUST perform the general 1260 validation checks described in Section 3.5. The behavior in case an 1261 error occurs is described in Section 3.6. 1263 State machine: 1265 Start 1266 | 1267 +---------+--------------------+ 1268 | | 1269 | send ir/cr/p10cr/kur | send 1270 | | rr/genm 1271 v v 1272 Waiting for ip/cp/kup Waiting for rp/genp 1273 | | 1274 | ip/cp/kup received | rp/genp 1275 +-------------------+------------------+ | received 1276 | | \ \ 1277 | with status | with status \ \ 1278 | "accepted" or | "waiting" \ \ 1279 | "grantedWithMods" | \ \ 1280 | and certificate | \ \ 1281 | v | \ 1282 | +---------> Polling | \ 1283 | | | | | 1284 | | pollRep | send | with status | 1285 | | received | pollReq | "rejection" | 1286 | | v | | 1287 | | Waiting for pollRep/ip/cp/kup | | 1288 | | | | | | | 1289 | +---+ | ip/cp/kup | ip/cp/kup | | 1290 | | with certificate | with status | | 1291 | | received | "rejection" | | 1292 v v | received | | 1293 certificate received | | | 1294 | | | | 1295 +-----------+-----+ | | | 1296 | | | | | 1297 | implicitConfirm | implicitConfirm | | | 1298 | granted | not granted | | | 1299 | | | | | 1300 | | send certConf | | | 1301 | v | | | 1302 | Waiting for pkiConf | | | 1303 | | | | | 1304 | | pkiConf | | | 1305 | | received | | | 1306 +-----------------+--------------------+-------------+-------------+ 1307 | 1308 v 1309 End 1311 Note: All CMP messages belonging to the same PKI management operation 1312 MUST have the same transactionID because the message receiver 1313 identifies the elements of the operation in this way. 1315 This section is aligned with CMP [RFC4210], CMP Updates 1316 [I-D.ietf-lamps-cmp-updates], and CMP Algorithms 1317 [I-D.ietf-lamps-cmp-algorithms]. 1319 Guidelines as well as an algorithm use profile for this document are 1320 available in CMP Algorithms [I-D.ietf-lamps-cmp-algorithms]. 1322 4.1. Requesting a new certificate from a PKI 1324 There are various approaches for requesting a certificate from a PKI. 1326 These approaches differ in the way the EE authenticates itself to the 1327 PKI, in the form of the request being used, and how the key pair to 1328 be certified is generated. The authentication mechanisms may be as 1329 follows: 1331 * Using a certificate from an external PKI, e.g., a manufacturer- 1332 issued device certificate, and the corresponding private key 1334 * Using a private key and certificate issued from the same PKI that 1335 is addressed for requesting a certificate 1337 * Using the certificate to be updated and the corresponding private 1338 key 1340 * Using shared secret information known to the EE and the PKI 1341 management entity 1343 An EE requests a certificate indirectly or directly from a CA. When 1344 the PKI management entity handles the request as described in 1345 Section 5.1.1 and responds with a message containing the requested 1346 certificate, the EE MUST reply with a confirmation message unless 1347 implicitConfirm was granted. The PKI management entity then MUST 1348 handle it as described in Section 5.1.3 and respond with a 1349 confirmation, closing the PKI management operation. 1351 The message sequences described in this section allow the EE to 1352 request certification of a locally or centrally generated public- 1353 private key pair. Typically, the EE provides a signature-based 1354 proof-of-possession of the private key associated with the public key 1355 contained in the certificate request as defined by RFC 4211 1356 Section 4.1 [RFC4211] case 3. To this end it is assumed that the 1357 private key can technically be used for signing. This is the case 1358 for the most common algorithms RSA and ECDSA, regardless of 1359 potentially intended restrictions of the key usage. 1361 Note: In conformance with NIST SP 800-57 Part 1 Section 8.1.5.1.1.2 1362 [NIST.SP.800-57p1r5] the newly generated private key MAY be used for 1363 self-signature, if technically possible, even if the keyUsage 1364 extension requested in the certificate request prohibits generation 1365 of digital signatures. 1367 The requesting EE provides the binding of the proof-of-possession to 1368 its identity by signature-based or MAC-based protection of the CMP 1369 request message containing that POP. As detailed in Section 5.1.1 1370 and Section 5.1.2, an upstream PKI management entity should verify 1371 whether this EE is authorized to obtain a certificate with the 1372 requested subject and other fields and extensions. 1374 The EE MAY indicate the certificate profile to use in the certProfile 1375 extension of the generalInfo field in the PKIHeader of the 1376 certificate request message as described in Section 3.1. 1378 In case a new trust anchor, e.g., a root CA certificate, is to be 1379 installed that has been received in the caPubs field of an ip or cp 1380 message, the EE MUST properly authenticate the message and authorize 1381 its sender as trusted source of the new trust anchor certificate. 1382 This authorization is typically indicated by using shared secret 1383 information, but it can also be indicated by using a private key with 1384 a certificate issued by another PKI explicitly authorized for this 1385 purpose, for the CMP message protection. 1387 4.1.1. Requesting a certificate from a new PKI with signature-based 1388 protection 1390 This PKI management operation should be used by an EE to request a 1391 certificate from a new PKI using an existing certificate from an 1392 external PKI, e.g., a manufacturer-issued IDevID certificate 1393 [IEEE.802.1AR_2018], to authenticate itself to the new PKI. 1395 Specific prerequisites augmenting the prerequisites in Section 3.4: 1397 * The certificate of the EE MUST have been enrolled by an external 1398 PKI, e.g., a manufacturer-issued device certificate. 1400 * The PKI management entity MUST have the trust anchor of the 1401 external PKI. 1403 * When using the generalInfo field certProfile, the EE MUST know the 1404 identifier needed to indicate the requested certificate profile. 1406 Message flow: 1408 Step# EE PKI management entity 1409 1 format ir 1410 2 -> ir -> 1411 3 handle or 1412 forward ir 1413 4 format or receive ip 1414 5 possibly grant 1415 implicitConfirm 1416 6 <- ip <- 1417 7 handle ip 1419 ----------------- if implicitConfirm not granted ----------------- 1421 8 format certConf 1422 9 -> certConf -> 1423 10 handle or 1424 forward certConf 1425 11 format or receive pkiConf 1426 12 <- pkiConf <- 1427 13 handle pkiConf 1429 For this PKI management operation, the EE MUST include exactly one 1430 CertReqMsg in the ir. If more certificates are required, further 1431 requests MUST be sent using separate PKI management operation. If 1432 the EE wants to omit sending a certificate confirmation message after 1433 receiving the ip, e.g., to reduce the number of protocol messages 1434 exchanged in this PKI management operation, it MUST request this by 1435 including the implicitConfirm extension in the header of the ir 1436 message, see Section 3.1. 1438 If the EE did not request implicit confirmation or the request was 1439 not granted by the PKI management entity, certificate confirmation 1440 MUST be performed as follows. If the EE successfully received the 1441 certificate, it MUST send a certConf message in due time. On 1442 receiving a certConf message, the PKI management entity MUST respond 1443 with a pkiConf message. If the PKI management entity does not 1444 receive the expected certConf message in time it MUST handle this 1445 like a rejection by the EE. In case of rejection the PKI management 1446 entity SHALL terminate the PKI management operation, and the PKI MAY 1447 revoke the newly issued certificate. 1449 If the EE did not request implicit confirmation or the request was 1450 not granted by the PKI management entity, certificate confirmation 1451 MUST be performed as follows. If the EE successfully received the 1452 certificate and accepts it, the EE MUST send a certConf message, 1453 which the PKI management entity must respond using a pkiConf message. 1454 If the PKI management entity does not receive the expected certConf 1455 message in time it MUST handle this like a rejection by the EE. In 1456 this case the PKI management entity SHALL terminate the PKI 1457 management operation. The PKI MAY revoke the newly issued 1458 certificates depending on the local policy. 1460 If the certificate request was rejected by the CA, the PKI management 1461 entity must return an ip message containing the status code 1462 "rejection" as described in Section 3.6 and no certifiedKeyPair 1463 field. The EE MUST NOT react to such an ip message with a certConf 1464 message and the PKI management operation MUST be terminated. 1466 Detailed message description: 1468 Initialization Request -- ir 1470 Field Value 1472 header 1473 -- As described in Section 3.1 1475 body 1476 -- The request of the EE for a new certificate 1477 ir REQUIRED 1478 -- MUST contain exactly one CertReqMsg 1479 -- If more certificates are required, further PKI management 1480 -- operations MUST be initiated 1481 certReq REQUIRED 1482 certReqId REQUIRED 1483 -- MUST be 0 1484 certTemplate REQUIRED 1485 version OPTIONAL 1486 -- MUST be 2 if supplied 1487 subject REQUIRED 1488 -- The EE subject name MUST be carried in the subject field 1489 -- and/or the subjectAltName extension. 1490 -- If subject name is present only in the subjectAltName 1491 -- extension, then the subject field MUST be a NULL-DN 1492 publicKey REQUIRED 1493 algorithm REQUIRED 1494 -- MUST include the subject public key algorithm identifier 1495 subjectPublicKey REQUIRED 1496 -- MUST contain the public key to be certified in case of local 1497 -- key generation 1498 extensions OPTIONAL 1499 -- MAY include end-entity-specific X.509 extensions of the 1500 -- requested certificate like subject alternative name, key 1501 -- usage, and extended key usage 1502 -- The subjectAltName extension MUST be present if the EE subject 1503 -- name includes a subject alternative name. 1504 popo OPTIONAL 1505 -- MUST be present if local key generation is used 1506 -- MUST be absent if central key generation is requested 1507 signature RECOMMENDED 1508 -- MUST be used by an EE if the key can be used for signing and 1509 -- has the type POPOSigningKey 1510 poposkInput PROHIBITED 1511 -- MUST NOT be used; it is not needed because subject and 1512 -- publicKey are both present in the certTemplate 1513 algorithmIdentifier REQUIRED 1514 -- The signature algorithm MUST be consistent with the publicKey 1515 -- algorithm field of the certTemplate 1516 signature REQUIRED 1517 -- MUST contain the signature value computed over the DER-encoded 1518 -- certTemplate 1519 raVerified OPTIONAL 1520 -- MAY be used by an RA after verifying the proof-of-possession 1521 -- provided by the EE 1523 protection REQUIRED 1524 -- As described in Section 3.2 1526 extraCerts REQUIRED 1527 -- As described in Section 3.3 1529 Initialization Response -- ip 1531 Field Value 1533 header 1534 -- As described in Section 3.1 1536 body 1537 -- The response of the CA to the request as appropriate 1538 ip REQUIRED 1539 caPubs OPTIONAL 1540 -- MAY be used if the certifiedKeyPair field is present 1541 -- If used it MUST contain only a trust anchor, e.g. root 1542 -- certificate, of the certificate contained in certOrEncCert 1543 response REQUIRED 1544 -- MUST contain exactly one CertResponse 1545 certReqId REQUIRED 1546 -- MUST be 0 1547 status REQUIRED 1548 -- PKIStatusInfo structure MUST be present 1549 status REQUIRED 1550 -- positive values allowed: "accepted", "grantedWithMods" 1551 -- negative values allowed: "rejection" 1552 statusString OPTIONAL 1553 -- MAY be any human-readable text for debugging, logging or to 1554 -- display in a GUI 1555 failInfo OPTIONAL 1556 -- MAY be present if status is "rejection" 1557 -- MUST be absent if status is "accepted" or "grantedWithMods" 1558 certifiedKeyPair OPTIONAL 1559 -- MUST be present if status is "accepted" or "grantedWithMods" 1560 -- MUST be absent if status is "rejection" 1561 certOrEncCert REQUIRED 1562 -- MUST be present if status is "accepted" or "grantedWithMods" 1563 certificate REQUIRED 1564 -- MUST be present when certifiedKeyPair is present 1565 -- MUST contain the newly enrolled X.509 certificate 1566 privateKey OPTIONAL 1567 -- MUST be absent in case of local key generation or "rejection" 1568 -- MUST contain the encrypted private key in an EnvelopedData 1569 -- structure as specified in Section 4.1.6 in case the private 1570 -- key was generated centrally 1572 protection REQUIRED 1573 -- As described in Section 3.2 1575 extraCerts REQUIRED 1576 -- As described in Section 3.3 1577 -- MUST contain the chain of the certificate present in 1578 -- certOrEncCert 1579 -- Self-signed certificates SHOULD be omitted 1580 -- Duplicate certificates MAY be omitted 1582 Certificate Confirmation -- certConf 1584 Field Value 1586 header 1587 -- As described in Section 3.1 1589 body 1590 -- The message of the EE sends confirmation to the PKI 1591 -- management entity to accept or reject the issued certificates 1592 certConf REQUIRED 1593 -- MUST contain exactly one CertStatus 1594 CertStatus REQUIRED 1595 hashAlg OPTIONAL 1596 -- The hash algorithm to use for calculating certHash 1597 -- SHOULD NOT be used in all cases where the AlgorithmIdentifier 1598 -- of the certificate signature specifies a hash algorithm 1599 -- If used, the pvno field in the header MUST be cmp2021 (3) 1600 certHash REQUIRED 1601 -- MUST be the hash of the certificate, using the hash algorithm 1602 -- indicated in hashAlg or the same one as used to create the 1603 -- certificate signature 1604 certReqId REQUIRED 1605 -- MUST be 0 1606 statusInfo RECOMMENDED 1607 -- PKIStatusInfo structure SHOULD be present 1608 -- Omission indicates acceptance of the indicated certificate 1609 status REQUIRED 1610 -- positive values allowed: "accepted" 1611 -- negative values allowed: "rejection" 1612 statusString OPTIONAL 1613 -- MAY be any human-readable text for debugging, logging, or to 1614 -- display in a GUI 1615 failInfo OPTIONAL 1616 -- MAY be present if status is "rejection" 1617 -- MUST be absent if status is "accepted" 1619 protection REQUIRED 1620 -- As described in Section 3.2 1621 -- MUST use the same credentials as in the first request message 1622 -- of this PKI management operation 1624 extraCerts RECOMMENDED 1625 -- As described in Section 3.3 1626 -- MAY be omitted if the message size is critical and 1627 -- the PKI management entity caches the extraCerts from the 1628 -- first request message of this PKI management operation 1630 PKI Confirmation -- pkiConf 1632 Field Value 1634 header 1635 -- As described in Section 3.1 1637 body 1638 pkiconf REQUIRED 1639 -- The content of this field MUST be NULL 1641 protection REQUIRED 1642 -- As described in Section 3.2 1643 -- MUST use the same credentials as in the first response 1644 -- message of this PKI management operation 1646 extraCerts RECOMMENDED 1647 -- As described in Section 3.3 1648 -- MAY be omitted if the message size is critical and the EE has 1649 -- cached the extraCerts from the first response message of 1650 -- this PKI management operation 1652 4.1.2. Requesting an additional certificate with signature-based 1653 protection 1655 This PKI management operation should be used by an EE to request an 1656 additional certificate of the same PKI it already has certificates 1657 from. The EE uses one of these existing certificates to authenticate 1658 itself by signing its request messages using the respective private 1659 key. 1661 Specific prerequisites augmenting the prerequisites in Section 3.4: 1663 * The certificate used by the EE MUST have been enrolled by the PKI 1664 it requests another certificate from. 1666 * When using the generalInfo field certProfile, the EE MUST know the 1667 identifier needed to indicate the requested certificate profile. 1669 The message sequence for this PKI management operation is identical 1670 to that given in Section 4.1.1, with the following changes: 1672 1 The body of the first request and response SHOULD be cr and cp, 1673 respectively. 1675 Note: Since the difference between ir/ip and cr/cp is 1676 syntactically not essential, an ir/ip MAY be used in this PKI 1677 management operation. 1679 2 The caPubs field in the certificate response message SHOULD be 1680 absent. 1682 4.1.3. Updating an existing certificate with signature protection 1684 This PKI management operation should be used by an EE to request an 1685 update for one of its certificates that is still valid. The EE uses 1686 the certificate it wishes to update as the protection certificate. 1687 Both for authenticating itself and for proving ownership of the 1688 certificate to be updated, it signs the request messages with the 1689 corresponding private key. 1691 Specific prerequisites augmenting the prerequisites in Section 3.4: 1693 * The certificate the EE wishes to update MUST NOT be expired or 1694 revoked and MUST have been issued by the addressed CA. 1696 * A new public-private key pair SHOULD be used. 1698 * When using the generalInfo field certProfile, the EE MUST know the 1699 identifier needed to indicate the requested certificate profile. 1701 The message sequence for this PKI management operation is identical 1702 to that given in Section 4.1.1, with the following changes: 1704 1 The body of the first request and response MUST be kur and kup, 1705 respectively. 1707 2 Protection of the kur MUST be performed using the certificate to 1708 be updated. 1710 3 The subject field and/or the subjectAltName extension of the 1711 certTemplate MUST contain the EE subject name of the existing 1712 certificate to be updated, without modifications. 1714 4 The certTemplate SHOULD contain the subject and/or subjectAltName 1715 extension and publicKey of the EE only. 1717 5 The oldCertId control MAY be used to make clear which certificate 1718 is to be updated. 1720 6 The caPubs field in the kup message MUST be absent. 1722 As part of the certReq structure of the kur the oldCertId control is 1723 added after the certTemplate field. 1725 controls 1726 type RECOMMENDED 1727 -- MUST be the value id-regCtrl-oldCertID, if present 1728 value 1729 issuer REQUIRED 1730 serialNumber REQUIRED 1731 -- MUST contain the issuer and serialNumber of the certificate 1732 -- to be updated 1734 4.1.4. Requesting a certificate from a PKI with MAC-based protection 1736 This PKI management operation should be used by an EE to request a 1737 certificate of a new PKI in case it does not have a certificate to 1738 prove its identity to the target PKI, but has some secret information 1739 shared with the PKI management entity. Therefore, the request and 1740 response messages are MAC-protected using this shared secret 1741 information. The PKI management entity checking the MAC-based 1742 protection SHOULD replace this protection according to Section 5.2.3 1743 in case the next hop does not know the shared secret information. 1745 Note: The entropy of the shared secret information is crucial for the 1746 level of protection when using MAC-based protection. Further 1747 guidance is available in Section 8. 1749 Specific prerequisites augmenting the prerequisites in Section 3.4: 1751 * Rather than using private keys, certificates, and trust anchors, 1752 the EE and the PKI management entity MUST share secret 1753 information. 1755 Note: The shared secret information MUST be established out-of- 1756 band, e.g., by a service technician during initial local 1757 configuration. 1759 * When using the generalInfo field certProfile, the EE MUST know the 1760 identifier needed to indicate the requested certificate profile. 1762 The message sequence for this PKI management operation is identical 1763 to that given in Section 4.1.1, with the following changes: 1765 1 The protection of all messages MUST be MAC-based. 1767 2 The senderKID MUST contain a reference the recipient can use to 1768 identify the shared secret information used for the protection, 1769 e.g., the username of the EE. 1771 3 The extraCerts of all messages does not contain CMP protection 1772 certs and associated chains. 1774 See Section 6 of CMP Algorithms [I-D.ietf-lamps-cmp-algorithms] for 1775 details on message authentication code algorithms (MSG_MAC_ALG) to 1776 use. Typically, parameters are part of the protectionAlg field, 1777 e.g., used for key derivation, like a salt and an iteration count. 1778 Such fields SHOULD remain constant for message protection throughout 1779 this PKI management operation to reduce the computational overhead. 1781 4.1.5. Requesting a certificate from a legacy PKI using a PKCS#10 1782 request 1784 This PKI management operation can be used by an EE to request a 1785 certificate using a legacy PKCS#10 [RFC2986] request instead of CRMF 1786 [RFC4211]. This offers a variation of the PKI management operations 1787 specified in Section 4.1.1 to Section 4.1.4. 1789 In this PKI management operation the public key and all further 1790 certificate template data MUST be contained in the subjectPKInfo and 1791 other certificationRequestInfo fields of the PKCS#10 structure. 1793 The prerequisites are the same as given in Section 4.1.1, 1794 Section 4.1.2, Section 4.1.3, or Section 4.1.4. 1796 The message sequence for this PKI management operation is identical 1797 to that given in Section 4.1.1 to Section 4.1.4, with the following 1798 changes: 1800 1 The body of the first request and response MUST be p10cr and cp, 1801 respectively. 1803 2 The certReqId in the cp message MUST be 0. 1805 3 The caPubs field in the cp message SHOULD be absent. 1807 Detailed description of the p10cr message: 1809 Certification Request -- p10cr 1811 Field Value 1813 header 1814 -- As described in Section 3.1 1816 body 1817 -- The request of the EE for a new certificate using a PKCS#10 1818 -- certificate request 1819 p10cr REQUIRED 1820 certificationRequestInfo REQUIRED 1821 version REQUIRED 1822 -- MUST be 0 to indicate PKCS#10 V1.7 1823 subject REQUIRED 1824 -- The EE subject name MUST be carried in the subject field 1825 -- and/or the subjectAltName extension. 1826 -- If subject name is present only in the subjectAltName 1827 -- extension, then the subject field MUST be a NULL-DN 1828 subjectPKInfo REQUIRED 1829 algorithm REQUIRED 1830 -- MUST include the subject public key algorithm identifier 1831 subjectPublicKey REQUIRED 1832 -- MUST include the public key to be certified 1833 attributes OPTIONAL 1834 -- MAY include end-entity-specific X.509 extensions of the 1835 -- requested certificate like subject alternative name, 1836 -- key usage, and extended key usage 1837 -- The subjectAltName extension MUST be present if the EE 1838 -- subject name includes a subject alternative name. 1839 signatureAlgorithm REQUIRED 1840 -- The signature algorithm MUST be consistent with the 1841 -- subjectPKInfo field. 1842 signature REQUIRED 1843 -- MUST contain the self-signature for proof-of-possession 1845 protection REQUIRED 1846 -- As described for the underlying PKI management operation 1848 extraCerts REQUIRED 1849 -- As described for the underlying PKI management operation 1851 4.1.6. Adding central key pair generation to a certificate request 1853 This functional extension can combined with certificate enrollment as 1854 described in Section 4.1.1 to Section 4.1.4. It needs to be used in 1855 case an EE is not able to generate its new public-private key pair 1856 itself or central generation of the EE key material is preferred. It 1857 is a matter of the local implementation which PKI management entity 1858 will act as Key Generation Authority (KGA) and perform the key 1859 generation. This PKI management entity MUST use a certificate 1860 containing the additional extended key usage extension id-kp-cmKGA in 1861 order to be accepted by the EE as a legitimate key generation 1862 authority. 1864 As described in Section 5.3.1, the KGA can use one of the PKI 1865 management operations described in the sections above to request the 1866 certificate for this key pair on behalf of the EE. 1868 Generally speaking, in machine-to-machine scenarios it is strongly 1869 preferable to generate public-private key pairs locally at the EE. 1870 Together with proof-of-possession of the private key in the 1871 certificate request, this is advisable to make sure that the entity 1872 identified in the newly issued certificate is the only entity that 1873 knows the private key. 1875 Reasons for central key generation may include the following: 1877 * Lack of sufficient initial entropy. 1879 Note: Good random numbers are needed not only for key generation 1880 but also for session keys and nonces in any security protocol. 1881 Therefore, a decent security architecture should anyways support 1882 good random number generation on the EE side or provide enough 1883 initial entropy for the RNG seed to guarantee good pseudo-random 1884 number generation. Yet maybe this is not the case at the time of 1885 requesting an initial certificate during manufacturing. 1887 * Lack of computational resources, in particular for RSA key 1888 generation. 1890 Note: Since key generation could be performed in advance to the 1891 certificate enrollment communication, it is often not time 1892 critical. 1894 Note: As mentioned in Section 2.1, central key generation may be 1895 required in a push model, where the certificate response message is 1896 transferred by the PKI management entity to the EE without a previous 1897 request message. 1899 The EE requesting central key generation MUST omit the publicKey 1900 field from the certTemplate or, in case it has a preference on the 1901 key type to be generated, provide it in the algorithm sub-field and 1902 fill the subjectPublicKey sub-field with a zero-length BIT STRING. 1903 Both variants indicate to the PKI management entity that a new key 1904 pair shall be generated centrally on behalf of the EE. 1906 Note: As the protection of centrally generated keys in the response 1907 message has been extended to EncryptedKey by CMP Updates 1908 [I-D.ietf-lamps-cmp-updates], EnvelopedData is the preferred 1909 alternative to EncryptedValue. In CRMF Section 2.1.9 [RFC4211] the 1910 use of EncryptedValue has been deprecated in favor of the 1911 EnvelopedData structure. Therefore, this profile requires using 1912 EnvelopedData as specified in CMS Section 6 [RFC5652]. When 1913 EnvelopedData is to be used in a PKI management operation, CMP v3 1914 MUST be indicated in the message header already for the initial 1915 request message, see Section 7 of CMP Updates 1916 [I-D.ietf-lamps-cmp-updates]. 1918 +----------------------------------+ 1919 | EnvelopedData | 1920 | [RFC5652] section 6 | 1921 | +------------------------------+ | 1922 | | SignedData | | 1923 | | [RFC5652] section 5 | | 1924 | | +--------------------------+ | | 1925 | | | AsymmetricKeyPackage | | | 1926 | | | [RFC5958] | | | 1927 | | | +----------------------+ | | | 1928 | | | | privateKey | | | | 1929 | | | | OCTET STRING | | | | 1930 | | | +----------------------+ | | | 1931 | | +--------------------------+ | | 1932 | +------------------------------+ | 1933 +----------------------------------+ 1935 Figure 3: Encrypted private key container 1937 The PKI management entity delivers the private key in the privateKey 1938 field in the certifiedKeyPair structure of the response message also 1939 containing the newly issued certificate. 1941 The private key MUST be provided as an AsymmetricKeyPackage structure 1942 as defined in RFC 5958 [RFC5958]. 1944 This AsymmetricKeyPackage structure MUST be wrapped in a SignedData 1945 structure, as specified in CMS Section 5 [RFC5652], signed by the KGA 1946 generating the key pair. The signature MUST be performed using a 1947 private key related to a certificate asserting the extended key usage 1948 id-kp-cmKGA as described in CMP Updates [I-D.ietf-lamps-cmp-updates] 1949 to demonstrate authorization to generate key pairs on behalf of an 1950 EE. The EE SHOULD verify the presence of this extended key usage in 1951 the SignedData structure. 1953 Note: When using password-based key management technique as described 1954 in Section 4.1.6.3 it may not be possible or meaningful to the EE to 1955 validate the KGA signature in the SignedData structure since shared 1956 secret information is used for initial authentication. In this case 1957 the EE MAY omit this signature validation. 1959 The SignedData structure MUST be wrapped in an EnvelopedData 1960 structure, as specified in CMS Section 6 [RFC5652], encrypting it 1961 using a newly generated symmetric content-encryption key. 1963 This content-encryption key MUST be securely provided as part of the 1964 EnvelopedData structure to the EE using one of three key management 1965 techniques. The choice of the key management technique to be used by 1966 the PKI management entity depends on the authentication mechanism the 1967 EE chose to protect the request message. See CMP Updates section 2.8 1968 [I-D.ietf-lamps-cmp-updates] for more details on which key management 1969 technique to use. 1971 * Signature-based protection of the request message: 1973 - The content-encryption key SHALL be protected using the key 1974 agreement key management technique, see Section 4.1.6.1, if the 1975 certificate used by the EE for protecting the request message 1976 allows the key usage keyAgreement. If the certificate also 1977 allows the key usage keyEncipherment, the key transport key 1978 management technique SHALL NOT be used. 1980 - The content-encryption key SHALL be protected using the key 1981 transport key management technique, see Section 4.1.6.2, if the 1982 certificate used by the EE for protecting the respective 1983 request message allows the key usage keyEncipherment but not 1984 keyAgreement. 1986 * MAC-based protected of the request message: 1988 - The content-encryption key SHALL be protected using the 1989 password-based key management technique, see Section 4.1.6.3, 1990 if and only if the EE used MAC-based protection for the request 1991 message. 1993 If central key generation is supported, support of the key agreement 1994 key management technique is REQUIRED and support of key transport and 1995 password-based key management techniques are OPTION, for two reasons: 1996 The key agreement key management technique is supported by most 1997 asymmetric algorithms, while the key transport key management 1998 technique is supported only by a very few of them. The password- 1999 based key management technique shall only be used in combination with 2000 MAC-based protection, which is a sideline in this document. 2002 Specific prerequisites augmenting those of the respective certificate 2003 enrollment PKI management operations: 2005 * If signature-based protection is used, the EE MUST be able to 2006 authenticate and authorize the KGA, using suitable information, 2007 which includes a trust anchor. 2009 * If MAC-based protection is used, the KGA MUST also know the shared 2010 secret information to protect the encrypted transport of the newly 2011 generated key pair. Consequently, the EE can also authorize the 2012 KGA. 2014 * The PKI management entity MUST have a certificate containing the 2015 additional extended key usage extension id-kp-cmKGA for signing 2016 the SignedData structure containing the private key package. 2018 * For encrypting the SignedData structure a fresh content-encryption 2019 key to be used by the symmetric encryption algorithm MUST be 2020 generated with sufficient entropy. 2022 Note: The security strength of the protection of the generated 2023 private key should be similar or higher than the security strength 2024 of the generated private key. 2026 The detailed description of the privateKey field as follows: 2028 privateKey OPTIONAL 2029 -- MUST be an EnvelopedData structure as specified in CMS 2030 -- Section 6 [RFC5652] 2031 version REQUIRED 2032 -- MUST be 2 for recipientInfo type KeyAgreeRecipientInfo and 2033 -- KeyTransRecipientInfo 2034 -- MUST be 0 for recipientInfo type PasswordRecipientInfo 2035 recipientInfos REQUIRED 2036 -- MUST contain exactly one RecipientInfo, which MUST be 2037 -- kari of type KeyAgreeRecipientInfo (see section 4.1.6.1), 2038 -- ktri of type KeyTransRecipientInfo (see section 4.1.6.2), or 2039 -- pwri of type PasswordRecipientInfo (see section 4.1.6.3) 2040 encryptedContentInfo 2041 REQUIRED 2042 contentType REQUIRED 2043 -- MUST be id-signedData 2044 contentEncryptionAlgorithm 2045 REQUIRED 2046 -- MUST be the algorithm identifier of the algorithm used for 2047 -- content encryption 2048 -- The algorithm type MUST be a PROT_SYM_ALG as specified in 2049 -- RFC-CMP-Alg Section 5 2050 encryptedContent REQUIRED 2051 -- MUST be the SignedData structure as specified in CMS 2052 -- Section 5 [RFC5652] in encrypted form 2053 version REQUIRED 2054 -- MUST be 3 2055 digestAlgorithms 2056 REQUIRED 2057 -- MUST contain exactly one AlgorithmIdentifier element 2058 -- MUST be the algorithm identifier of the digest algorithm 2059 -- used for generating the signature and match the signature 2060 -- algorithm specified in signatureAlgorithm 2061 encapContentInfo 2062 REQUIRED 2063 -- MUST contain the content that is to be signed 2064 eContentType REQUIRED 2065 -- MUST be id-ct-KP-aKeyPackage as specified in [RFC5958] 2066 eContent REQUIRED 2067 -- MUST be of type AsymmetricKeyPackage and 2068 -- MUST contain exactly one OneAsymmetricKey element 2069 version REQUIRED 2070 -- MUST be 1 (indicating v2) 2071 privateKeyAlgorithm 2072 REQUIRED 2073 -- The privateKeyAlgorithm field MUST contain the algorithm 2074 -- identifier of the asymmetric key pair algorithm 2075 privateKey 2076 REQUIRED 2077 publicKey 2078 REQUIRED 2079 -- MUST contain the public key corresponding to the private key 2080 -- for simplicity and consistency with v2 of OneAsymmetricKey 2081 certificates REQUIRED 2082 -- MUST contain the certificate for the private key used to sign 2083 -- the signedData content, together with its chain 2084 -- The first certificate in this field MUST be the KGA 2085 -- certificate used for protecting this content 2086 -- Self-signed certificates SHOULD NOT be included and MUST NOT 2087 -- be trusted based on their inclusion in any case 2088 signerInfos REQUIRED 2090 -- MUST contain exactly one SignerInfo element 2091 version REQUIRED 2092 -- MUST be 3 2093 sid REQUIRED 2094 subjectKeyIdentifier 2095 REQUIRED 2096 -- MUST be the subjectKeyIdentifier of the KGA certificate 2097 digestAlgorithm 2098 REQUIRED 2099 -- MUST be the same as in digestAlgorithmIdentifier 2100 signedAttrs REQUIRED 2101 -- MUST contain an id-contentType attribute containing the value 2102 -- id-ct-KP-aKeyPackage 2103 -- MUST contain an id-messageDigest attribute containing the 2104 -- message digest of eContent 2105 -- MAY contain an id-signingTime attribute containing the time 2106 -- of signature 2107 -- For details on the signed attributes see CMS Section 5.3 and 2108 -- Section 11 [RFC5652] 2109 signatureAlgorithm 2110 REQUIRED 2111 -- MUST be the algorithm identifier of the signature algorithm 2112 -- used for calculation of the signature bits 2113 -- The signature algorithm type MUST be a MSG_SIG_ALG as 2114 -- specified in RFC-CMP-Alg Section 3 and MUST be consistent 2115 -- with the subjectPublicKeyInfo field of the KGA certificate 2116 signature REQUIRED 2117 -- MUST be the digital signature of the encapContentInfo 2119 NOTE: As stated in Section 1.5, all fields of the ASN.1 syntax that 2120 are defined in RFC 5652 [RFC5652] but are not explicitly specified 2121 here SHOULD NOT be used. 2123 4.1.6.1. Using key agreement key management technique 2125 This variant can be applied in combination with the PKI management 2126 operations specified in Section 4.1.1 to Section 4.1.3 using 2127 signature-based protection of CMP messages. The EE certificate used 2128 for the signature-based protection of the request message MUST allow 2129 for the key usage "keyAgreement" and therefore, the related key pair 2130 MUST be used for establishment of the content-encryption key. For 2131 this key management technique the KeyAgreeRecipientInfo structure 2132 MUST be used in the contentInfo field. 2134 The KeyAgreeRecipientInfo structure included into the EnvelopedData 2135 structure is specified in CMS Section 6.2.2 [RFC5652]. 2137 The detailed description of the KeyAgreeRecipientInfo structure looks 2138 like this: 2140 kari REQUIRED 2141 -- MUST be a KeyAgreeRecipientInfo as specified in CMS Section 2142 -- 6.2.2 [RFC5652] 2143 version REQUIRED 2144 -- MUST be 3 2145 originator REQUIRED 2146 -- MUST contain the originatorKey choice 2147 algorithm REQUIRED 2148 -- MUST be the algorithm identifier of the key agreement 2149 -- algorithm 2150 -- The algorithm type MUST be a KM_KA_ALG as specified in 2151 -- RFC-CMP-Alg Section 4.1 2152 publicKey REQUIRED 2153 -- MUST be the ephemeral public key of the sending party 2154 ukm RECOMMENDED 2155 -- MUST be used when 1-pass ECMQV is used 2156 -- SHOULD be present to ensure uniqueness of the key 2157 -- encryption key, see [RFC8419] 2158 keyEncryptionAlgorithm 2159 REQUIRED 2160 -- MUST be the algorithm identifier of the key wrap algorithm 2161 -- The algorithm type MUST be a KM_KW_ALG as specified in 2162 -- RFC-CMP-Alg Section 4.3 2163 recipientEncryptedKeys 2164 REQUIRED 2165 -- MUST contain exactly one RecipientEncryptedKey element 2166 rid REQUIRED 2167 -- MUST contain the rKeyId choice 2168 rKeyId REQUIRED 2169 subjectKeyIdentifier 2170 REQUIRED 2171 -- MUST contain the same value as the senderKID in the 2172 -- respective request message header 2173 encryptedKey 2174 REQUIRED 2175 -- MUST be the encrypted content-encryption key 2177 4.1.6.2. Using key transport key management technique 2179 This variant can be applied in combination with the PKI management 2180 operations specified in Section 4.1.1 to Section 4.1.3 using 2181 signature-based protection of CMP messages. The EE certificate used 2182 for the signature-based protection of the request message MUST allow 2183 for the key usage "keyEncipherment" and not for "keyAgreement". 2184 Therefore, the related key pair MUST be used for encipherment of the 2185 content-encryption key. For this key management technique the 2186 KeyTransRecipientInfo structure MUST be used in the contentInfo 2187 field. 2189 The KeyTransRecipientInfo structure included into the EnvelopedData 2190 structure is specified in CMS Section 6.2.1 [RFC5652]. 2192 The detailed description of the KeyTransRecipientInfo structure looks 2193 like this: 2195 ktri REQUIRED 2196 -- MUST be a KeyTransRecipientInfo as specified in CMS 2197 -- Section 6.2.1 [RFC5652] 2198 version REQUIRED 2199 -- MUST be 2 2200 rid REQUIRED 2201 -- MUST contain the subjectKeyIdentifier choice 2202 subjectKeyIdentifier 2203 REQUIRED 2204 -- MUST contain the same value as the senderKID in the 2205 -- respective request message header 2206 keyEncryptionAlgorithm 2207 REQUIRED 2208 -- MUST be the algorithm identifier of the key transport 2209 -- algorithm 2210 -- The algorithm type MUST be a KM_KT_ALG as specified in 2211 -- RFC-CMP-Alg Section 4.2 2212 encryptedKey REQUIRED 2213 -- MUST be the encrypted content-encryption key 2215 4.1.6.3. Using password-based key management technique 2217 This variant can be applied in combination with the PKI management 2218 operation specified in Section 4.1.4 using MAC-based protection of 2219 CMP messages. The shared secret information used for the MAC-based 2220 protection MUST also be used for the encryption of the content- 2221 encryption key but with a different salt value applied in the key 2222 derivation algorithm. For this key management technique the 2223 PasswordRecipientInfo structure MUST be used in the contentInfo 2224 field. 2226 Note: The entropy of the shared secret information is crucial for the 2227 level of protection when using a password-based key management 2228 technique. For centrally generated key pairs, the entropy of the 2229 shared secret information SHALL not be less than the security 2230 strength of the centrally generated key pair. Further guidance is 2231 available in Section 8. 2233 The PasswordRecipientInfo structure included into the EnvelopedData 2234 structure is specified in CMS Section 6.2.4 [RFC5652]. 2236 The detailed description of the PasswordRecipientInfo structure looks 2237 like this: 2239 pwri REQUIRED 2240 -- MUST be a PasswordRecipientInfo as specified in CMS 2241 -- Section 6.2.4 [RFC5652] 2242 version REQUIRED 2243 -- MUST be 0 2244 keyDerivationAlgorithm 2245 REQUIRED 2246 -- MUST be the algorithm identifier of the key derivation 2247 -- algorithm 2248 -- The algorithm type MUST be a KM_KD_ALG as specified in 2249 -- RFC-CMP-Alg Section 4.4 2250 keyEncryptionAlgorithm 2251 REQUIRED 2252 -- MUST be the algorithm identifier of the key wrap algorithm 2253 -- The algorithm type MUST be a KM_KW_ALG as specified in 2254 -- RFC-CMP-Alg Section 4.3 2255 encryptedKey REQUIRED 2256 -- MUST be the encrypted content-encryption key 2258 4.1.7. Handling delayed enrollment 2260 This functional extension can be applied in combination with 2261 certificate enrollment as described in Section 4.1.1 to 2262 Section 4.1.5, optionally including central key generation. The 2263 functional extension can be used in case a PKI management entity 2264 cannot respond to the certificate request in a timely manner, e.g., 2265 due to offline upstream communication or required human interaction. 2266 Depending on the PKI architecture, the entity initiating delayed 2267 enrollment (see also Section 5.1.2) is not necessarily the PKI 2268 management entity addressed by the EE. 2270 Note: According to CMP Updates [I-D.ietf-lamps-cmp-updates] delayed 2271 enrollment is also possible for PKI management operations starting 2272 with a p10cr request message. 2274 The PKI management entity initiating the delayed enrollment MUST 2275 respond with an ip/cp/kup message including the status "waiting". 2276 When receiving a response with status "waiting" the EE MUST send a 2277 poll request. The PKI management entity that initiated the delayed 2278 enrollment MUST answer with a poll response containing a checkAfter 2279 time. This value indicates the minimum number of seconds that SHOULD 2280 elapse before the EE sends another poll request. This is repeated as 2281 long as no final response is available or any party involved gives up 2282 on the current PKI management operation. When the PKI management 2283 entity that initiated delayed enrollment can provide the final ip/cp/ 2284 kup message for the initial request of the EE, it MUST provide this 2285 message in response to a poll request. After receiving this 2286 response, the EE can continue the original PKI management operation 2287 as described in the respective section of this document, i.e., 2288 sending a certConf message if required. 2290 No specific prerequisites apply in addition to those of the 2291 respective certificate enrollment. 2293 Message flow: 2295 Step# EE PKI management entity 2296 1 format ir/cr/p10cr/kur 2297 2 ->ir/cr/p10cr/kur-> 2298 3 handle or forward request 2299 4 in case no immediate final 2300 response is possible, 2301 format or receive ip/cp/ 2302 kup with status "waiting" 2303 5 <- ip/cp/kup <- 2304 6 handle ip/cp/kup with status "waiting" 2306 -------------------------- start polling ------------------------- 2308 7 format pollReq 2309 8 -> pollReq -> 2310 9 handle or forward pollReq 2311 10 in case the requested 2312 certificate or a 2313 corresponding response 2314 message is available, 2315 continue with step 14 2316 otherwise, format or 2317 receive pollRep with 2318 checkAfter value 2319 11 <- pollRep <- 2320 12 handle pollRep 2321 13 let checkAfter 2322 time elapse and 2323 continue with step 7 2325 ----------------- end polling, continue as usual ----------------- 2327 14 format or receive 2328 ip/cp/kup 2329 15 possibly grant implicit 2330 confirm 2331 16 <- ip/cp/kup <- 2332 17 handle ip/cp/kup 2334 ----------------- if implicitConfirm not granted ----------------- 2336 18 format certConf 2337 19 -> certConf -> 2338 20 handle or forward certConf 2339 21 format or receive pkiConf 2340 22 <- pkiConf <- 2341 23 handle pkiConf 2342 Detailed description of the first ip/cp/kup: 2344 Response with status "waiting" -- ip/cp/kup 2346 Field Value 2348 header 2349 -- MUST be as described for the first response message of the 2350 -- respective PKI management operation 2352 body 2353 -- The response of the PKI management entity to the request in 2354 -- case no immediate final response can be sent 2355 ip/cp/kup REQUIRED 2356 response REQUIRED 2357 -- MUST contain exactly one CertResponse 2358 certReqId REQUIRED 2359 -- MUST be 0 2360 status REQUIRED 2361 -- PKIStatusInfo structure MUST be present 2362 status REQUIRED 2363 -- MUST be "waiting" 2364 statusString OPTIONAL 2365 -- MAY be any human-readable text for debugging, logging or to 2366 -- display in a GUI 2367 failInfo PROHIBITED 2368 certifiedKeyPair PROHIBITED 2370 protection REQUIRED 2371 -- MUST be as described for the first response message of the 2372 -- respective PKI management operation, except that the PKI 2373 -- management entity that initiated the delayed enrollment and 2374 -- created this response MUST apply its own protection 2376 extraCerts REQUIRED 2377 -- MUST be as described for the first response message of the 2378 -- respective PKI management operation. Yet since no newly 2379 -- enrolled certificate is available yet, no respective 2380 -- certificate chain is included 2382 Polling Request -- pollReq 2384 Field Value 2386 header 2387 -- MUST contain a header as described for the certConf message 2388 -- of the respective PKI management operation 2390 body 2391 -- The message of the EE asks for the final response or for a 2392 -- time to check again 2393 pollReq REQUIRED 2394 -- MUST contain exactly one PollReqContent element 2395 certReqId REQUIRED 2396 -- MUST be 0 2398 protection REQUIRED 2399 -- MUST be as described for the certConf message of the 2400 -- respective PKI management operation 2402 extraCerts OPTIONAL 2403 -- MUST be as described for the certConf message of the 2404 -- respective PKI management operation 2406 Polling Response -- pollRep 2408 Field Value 2410 header 2411 -- MUST contain a header as described for the pkiConf message 2412 -- of the respective PKI management operation 2414 body 2415 -- The message indicates the delay after which the EE SHOULD 2416 -- send another pollReq message for this transaction 2417 pollRep REQUIRED 2418 -- MUST contain exactly one PollRepContent entry 2419 certReqId REQUIRED 2420 -- MUST be 0 2421 checkAfter REQUIRED 2422 -- time in seconds to elapse before a new pollReq SHOULD be sent 2423 reason OPTIONAL 2424 -- MAY be any human-readable text for debugging, logging or to 2425 -- display in a GUI 2427 protection REQUIRED 2428 -- MUST be as described for the pkiConf message of the 2429 -- respectiveprofile, except that the PKI management entity that 2430 -- initiated the delayed enrollment and created this response 2431 -- MUST apply its own protection 2433 extraCerts OPTIONAL 2434 -- If present, it MUST be as described for the pkiConf message 2435 -- of the respective PKI management operation. 2437 Final response -- ip/cp/kup 2439 Field Value 2441 header 2442 -- MUST be as described for the first response except that the 2443 -- PKI management entity that initiated the delayed enrollment 2444 -- MUST use as recipNonce the senderNonce of the last pollReq 2445 -- message 2447 body 2448 -- The response of the PKI management entity to the initial 2449 -- request as described in the respective PKI management 2450 -- operation 2452 protection REQUIRED 2453 -- MUST be as described for the first response message of this 2454 -- PKI management operation, except that the PKI management 2455 -- entity that initiated the delayed enrollment MUST re-protect 2456 -- the response message 2458 extraCerts REQUIRED 2459 -- MUST be as described for the first response message of the 2460 -- respective PKI management operation 2462 4.2. Revoking a certificate 2464 This PKI management operation should be used by an entity to request 2465 revocation of a certificate. Here the revocation request is used by 2466 an EE to revoke one of its own certificates. 2468 The revocation request message MUST be signed using the certificate 2469 that is to be revoked to prove the authorization to revoke. The 2470 revocation request message is signature-protected using this 2471 certificate. 2473 An EE requests the revocation of an own certificate at the CA that 2474 issued this certificate. The PKI management entity handles the 2475 request as described in Section 5.1.4 and responds with a message 2476 that contains the status of the revocation from the CA. 2478 Specific prerequisites augmenting the prerequisites in Section 3.4: 2480 * The certificate the EE wishes to revoke is not yet expired or 2481 revoked. 2483 Message flow: 2485 Step# EE PKI management entity 2486 1 format rr 2487 2 -> rr -> 2488 3 handle or forward rr 2489 4 format or receive rp 2490 5 <- rp <- 2491 6 handle rp 2493 For this PKI management operation, the EE MUST include exactly one 2494 RevDetails structure in the rr message body. In case no generic 2495 error occurred the response to the rr MUST be an rp message 2496 containing a single status field. 2498 Detailed message description: 2500 Revocation Request -- rr 2502 Field Value 2504 header 2505 -- As described in Section 3.1 2507 body 2508 -- The request of the EE to revoke its certificate 2509 rr REQUIRED 2510 -- MUST contain exactly one element of type RevDetails 2511 -- If more revocations are desired, further PKI management 2512 -- operations MUST be initiated 2513 certDetails REQUIRED 2514 -- MUST be present and is of type CertTemplate 2515 serialNumber REQUIRED 2516 -- MUST contain the certificate serialNumber attribute of the 2517 -- certificate to be revoked 2518 issuer REQUIRED 2519 -- MUST contain the issuer attribute of the certificate to be 2520 -- revoked 2521 crlEntryDetails REQUIRED 2522 -- MUST contain exactly one reasonCode of type CRLReason (see 2523 -- [RFC5280] section 5.3.1) 2524 -- If the reason for this revocation is not known or shall not 2525 -- be published the reasonCode MUST be 0 = unspecified 2527 protection REQUIRED 2528 -- As described in Section 3.2 and using the private key related 2529 -- to the certificate to be revoked 2531 extraCerts REQUIRED 2532 -- As described in Section 3.3 2534 Revocation Response -- rp 2536 Field Value 2538 header 2539 -- As described in Section 3.1 2541 body 2542 -- The responds of the PKI management entity to the request as 2543 -- appropriate 2544 rp REQUIRED 2545 status REQUIRED 2546 -- MUST contain exactly one element of type PKIStatusInfo 2547 status REQUIRED 2548 -- positive value allowed: "accepted" 2549 -- negative value allowed: "rejection" 2550 statusString OPTIONAL 2551 -- MAY be any human-readable text for debugging, logging or to 2552 -- display in a GUI 2553 failInfo OPTIONAL 2554 -- MAY be present if status is "rejection" 2555 -- MUST be absent if the status is "accepted" 2557 protection REQUIRED 2558 -- As described in section 3.2 2560 extraCerts REQUIRED 2561 -- As described in section 3.3 2563 4.3. Support messages 2565 The following support messages offer on demand in-band transport of 2566 content relevant to the EE that may be provided by the PKI management 2567 entity. CMP general messages and general response are used for this 2568 purpose. Depending on the environment, these requests may be 2569 answered by an RA or CA (see also Section 5.1.5). 2571 The general messages and general response messages transport 2572 InfoTypeAndValue structures. In addition to those infoType values 2573 defined in RFC 4210 [RFC4210] and CMP Updates 2574 [I-D.ietf-lamps-cmp-updates] further OIDs MAY be used to define new 2575 PKI management operations or new general-purpose support messages as 2576 needed in specific environments. 2578 The following contents are specified in this document: 2580 * Get CA certificates 2581 * Get root CA certificate update 2583 * Get certificate request template 2585 In the following the aspects common to all general messages (genm) 2586 and general response (genp) messages are described. 2588 Message flow: 2590 Step# EE PKI management entity 2591 1 format genm 2592 2 -> genm -> 2593 3 handle or forward genm 2594 4 format or receive genp 2595 5 <- genp <- 2596 6 handle genp 2598 Detailed message description: 2600 General Message -- genm 2602 Field Value 2604 header 2605 -- As described in Section 3.1 2607 body 2608 -- A request by the EE to receive information 2609 genm REQUIRED 2610 -- MUST contain exactly one element of type InfoTypeAndValue 2611 infoType REQUIRED 2612 -- MUST be the OID identifying one of the specific PKI 2613 -- management operations described below 2614 infoValue OPTIONAL 2615 -- MUST be as described in the specific PKI management 2616 -- operation described below 2618 protection REQUIRED 2619 -- As described in Section 3.2 2621 extraCerts REQUIRED 2622 -- As described in Section 3.3 2624 General Response -- genp 2626 Field Value 2627 header 2628 -- As described in Section 3.1 2630 body 2631 -- The response of the PKI management entity on an information 2632 -- request 2633 genp REQUIRED 2634 -- MUST contain exactly one element of type InfoTypeAndValue 2635 infoType REQUIRED 2636 -- MUST be the OID identifying the specific PKI management 2637 -- operation described below 2638 infoValue OPTIONAL 2639 -- MUST be as described in the specific PKI management operation 2640 -- described below 2642 protection REQUIRED 2643 -- As described in Section 3.2 2645 extraCerts REQUIRED 2646 -- As described in Section 3.3 2648 4.3.1. Get CA certificates 2650 This PKI management operation can be used by an EE to request CA 2651 certificates from the PKI management entity. 2653 An EE requests CA certificates, e.g., for chain construction, from an 2654 PKI management entity by sending a general message with OID id-it- 2655 caCerts as specified in CMP Updates [I-D.ietf-lamps-cmp-updates]. 2656 The PKI management entity responds with a general response with the 2657 same OID that either contains a SEQUENCE of certificates populated 2658 with the available intermediate and issuing CA certificates or with 2659 no content in case no CA certificate is available. 2661 No specific prerequisites apply in addition to those specified in 2662 Section 3.4. 2664 The message sequence for this PKI management operation is as given 2665 above, with the following specific content: 2667 1 the infoType OID to use is id-it-caCerts 2669 2 the infoValue of the request MUST be absent 2671 3 if present, the infoValue of the response MUST contain a sequence 2672 of certificates 2674 The infoValue field of the general response containing the id-it- 2675 caCerts OID looks like this: 2677 infoValue OPTIONAL 2678 -- MUST be absent if no CA certificate is available 2679 -- MUST be present if CA certificates are available 2680 -- MUST be a sequence of CMPCertificate 2682 4.3.2. Get root CA certificate update 2684 This PKI management operation can be used by an EE to request an 2685 updated root CA Certificate as described in Section 4.4 of RFC 4210 2686 [RFC4210]. 2688 An EE requests a root CA certificate update from the PKI management 2689 entity by sending a general message with OID id-it-rootCaKeyUpdate, 2690 optionally including the certificate to be updated in the rootCaCert 2691 generalInfo field, as specified in CMP Updates 2692 [I-D.ietf-lamps-cmp-updates]. The PKI management entity responds 2693 with a general response with the same OID that either contains the 2694 update of the root CA certificate consisting of up to three 2695 certificates, or with no content in case no update is available. 2697 The newWithNew certificate is the new root CA certificate and is 2698 REQUIRED to be present if available. The newWithOld certificate is 2699 REQUIRED to be present in the response message because it is needed 2700 for the receiving entity trusting the old root CA certificate to gain 2701 trust in the new root CA certificate. The oldWithNew certificate is 2702 OPTIONAL because it is only needed in rare scenarios where entities 2703 do not already trust the old root CA. 2705 No specific prerequisites apply in addition to those specified in 2706 Section 3.4. 2708 The message sequence for this PKI management operation is as given 2709 above, with the following specific content: 2711 1 the infoType OID to use is id-it-rootCaKeyUpdate 2713 2 the rootCaCert general info field in the header of the request MAY 2714 contain the root CA certificate the update is requested for 2716 3 the infoValue of the request MUST be absent 2718 4 if present, the infoValue of the response MUST be a 2719 RootCaKeyUpdateContent structure 2721 The infoValue field of the general response containing the id-it- 2722 rootCaKeyUpdate extension looks like this: 2724 infoValue OPTIONAL 2725 -- MUST be absent if no update of the root CA certificate is 2726 -- available 2727 -- MUST be present if an update of the root CA certificate 2728 -- is available and MUST be of type RootCaKeyUpdate 2729 newWithNew REQUIRED 2730 -- MUST be present if infoValue is present 2731 -- MUST contain the new root CA certificate 2732 newWithOld REQUIRED 2733 -- MUST be present if infoValue is present 2734 -- MUST contain a certificate containing the new public 2735 -- root CA key signed with the old private root CA key 2736 oldWithNew OPTIONAL 2737 -- MAY be present if infoValue is present 2738 -- MUST contain a certificate containing the old public 2739 -- root CA key signed with the new private root CA key 2741 4.3.3. Get certificate request template 2743 This PKI management operation can be used by an EE to request a 2744 template with parameters for a future certificate requests. 2746 An EE requests certificate request parameters from the PKI management 2747 entity by sending a general message with OID id-it-certReqTemplate as 2748 specified in CMP Updates [I-D.ietf-lamps-cmp-updates]. The EE MAY 2749 indicate the certificate profile to use in the certProfile extension 2750 of the generalInfo field in the PKIHeader of the general message as 2751 described in Section 3.1. The PKI management entity responds with a 2752 general response with the same OID that either contains requirements 2753 on the certificate request template, or with no content in case no 2754 specific requirements are imposed by the PKI. The 2755 CertReqTemplateValue contains requirements on certificate fields and 2756 extensions in a certTemplate. Optionally it contains a keySpec field 2757 containing requirements on algorithms acceptable for key pair 2758 generation. 2760 The EE SHOULD follow the requirements from the received CertTemplate, 2761 by including in the certificate requests all the fields requested, 2762 taking over all the field values provided and filling in any 2763 remaining fields values. The EE SHOULD NOT add further fields, name 2764 components, and extensions or their (sub-)components. 2766 Note: We deliberately do not use "MUST" or "MUST NOT" here in order 2767 to allow more flexibility in case the rules given here are not 2768 sufficient for specific scenarios. The EE can populate the 2769 certificate request as wanted and ignore any of the requirements 2770 contained in the CertReqTemplateValue. On the other hand, a PKI 2771 management entity is free to ignore or replace any parts of the 2772 content of the certificate request provided by the EE. The 2773 CertReqTemplate PKI management operation offers means to ease a joint 2774 understanding which fields and/or which field values should be used. 2775 An example is provided in Appendix A. 2777 In case a field of type Name, e.g., subject, is present in the 2778 CertTemplate but has the value NULL-DN (i.e., has an empty list of 2779 RDN components), the field SHOULD be included in the certificate 2780 request and filled with content provided by the EE. Similarly, in 2781 case an X.509v3 extension is present but its extnValue is empty, this 2782 means that the extension SHOULD be included and filled with content 2783 provided by the EE. In case a Name component, for instance a common 2784 name or serial number, is given but has an empty string value, the EE 2785 SHOULD fill in a value. Similarly, in case an extension has sub- 2786 components (e.g., an IP address in a SubjectAltName field) with empty 2787 value, the EE SHOULD fill in a value. 2789 The EE MUST ignore (i.e., not include and fill in) empty fields, 2790 extensions, and sub-components that it does not understand or does 2791 not know suitable values to be filled in. 2793 The publicKey field of type SubjectPublicKeyInfo in the CertTemplate 2794 of the CertReqTemplateValue MUST be omitted. In case the PKI 2795 management entity wishes to make stipulation on algorithms the EE may 2796 use for key generation, this MUST be specified using the keySpec 2797 field as specified in CMP Updates [I-D.ietf-lamps-cmp-updates]. 2799 The keySpec field, if present, specifies the public key types 2800 optionally with parameters, and/or RSA key lengths for which a 2801 certificate may be requested. 2803 The value of a keySpec element with the OID id-regCtrl-algId, as 2804 specified in CMP Updates [I-D.ietf-lamps-cmp-updates], MUST be of 2805 type AlgorithmIdentifier and give an algorithm other than RSA. For 2806 EC keys the curve information MUST be specified as described in the 2807 respective standard documents. 2809 The value of a keySpec element with the OID id-regCtrl-rsaKeyLen, as 2810 specified in CMP Updates [I-D.ietf-lamps-cmp-updates], MUST be of 2811 type Integer and give an RSA key length. 2813 In the CertTemplate of the CertReqTemplateValue the serialNumber, 2814 signingAlg, issuerUID, and subjectUID fields MUST be omitted. 2816 Specific prerequisites augmenting the prerequisites in Section 3.4: 2818 * When using the generalInfo field certProfile, the EE MUST know the 2819 identifier needed to indicate the requested certificate profile. 2821 The message sequence for this PKI management operation is as given 2822 above, with the following specific content: 2824 1 the infoType OID to use is id-it-certReqTemplate 2826 2 the certProfile generalInfo field in the header of the request MAY 2827 contain the name of the requested certificate request template 2829 3 the infoValue of the request MUST be absent 2831 4 if present, the infoValue of the response MUST be a 2832 CertReqTemplateValue containing a CertTemplate structure and an 2833 optional keySpec field 2835 The infoValue field of the general response containing the id-it- 2836 certReqTemplate OID looks like this: 2838 InfoValue OPTIONAL 2839 -- MUST be absent if no requirements are available 2840 -- MUST be present if the PKI management entity has any 2841 -- requirements on the contents of the certificate template 2842 certTemplate REQUIRED 2843 -- MUST be present if infoValue is present 2844 -- MUST contain the required CertTemplate structure elements 2845 -- The SubjectPublicKeyInfo field MUST be absent 2846 keySpec OPTIONAL 2847 -- MUST be absent if no requirements on the public key are 2848 -- available 2849 -- MUST be present if the PKI management entity has any 2850 -- requirements on the keys generated 2851 -- MUST contain one AttributeTypeAndValue per supported 2852 -- algorithm with attribute id-regCtrl-algId or 2853 -- id-regCtrl-rsaKeyLen 2855 5. PKI management entity operations 2857 This section focuses on request processing by a PKI management 2858 entity. Depending on the network and PKI solution design, this can 2859 be an RA or CA, any of which may include protocol conversion or 2860 central key generation (i.e., acting as a KGA). 2862 A PKI management entity may directly respond to request messages from 2863 downstream and report errors. In case the PKI management entity is 2864 an RA it typically forwards the received request messages upstream 2865 after checking them and forwards respective response messages 2866 downstream. Besides responding to messages or forwarding them, a PKI 2867 management entity may request or revoke certificates on behalf of 2868 EEs. A PKI management entity may also need to manage its own 2869 certificates and thus act as an EE using the PKI management 2870 operations specified in Section 4. 2872 5.1. Responding to requests 2874 The PKI management entity terminating the PKI management operation at 2875 CMP level MUST respond to all received requests by returning a 2876 related CMP response message or an error. Any intermediate PKI 2877 management entity MAY respond depending on the PKI configuration and 2878 policy. 2880 In addition to the checks described in Section 3.5, the responding 2881 PKI management entity SHOULD check that a request that initiates a 2882 new PKI management operation does not use a transactionID that is 2883 currently in useThe failInfo bit value to use on reporting failure as 2884 described in Section 3.6.4 is transactionIdInUse. If any of these 2885 verification steps or any of the essential checks described in the 2886 below subsections fails, the PKI management entity MUST proceed as 2887 described in Section 3.6. 2889 The responding PKI management entity SHOULD copy the sender field of 2890 the request to the recipient field of the response, MUST copy the 2891 senderNonce of the request to the recipNonce of the response, and 2892 MUST use the same transactionID for the response. 2894 5.1.1. Responding to a certificate request 2896 An ir/cr/p10cr/kur message is used to request a certificate as 2897 described in Section 4.1. The responding PKI management entity MUST 2898 proceed as follows unless it initiates delayed enrollment as 2899 described in Section 5.1.2. 2901 The PKI management entity SHOULD check the message body according to 2902 the applicable requirements from Section 4.1. Possible failInfo bit 2903 values used for error reporting in case a check failed include 2904 badCertId and badCertTemplate. It MUST verify the presence and value 2905 of the proof-of-possession (failInfo bit: badPOP), unless central key 2906 generation is requested. In case the special POP value "raVerified" 2907 is given, it SHOULD check that the request message was signed using a 2908 certificate containing the cmcRA extended key usage (failInfo bit: 2909 notAuthorized). The PKI management entity SHOULD perform also any 2910 further checks on the certTemplate contents (failInfo: 2911 badCertTemplate) according to any applicable PKI policy and 2912 certificate profile. 2914 If the requested certificate is available, the PKI management entity 2915 MUST respond with a positive ip/cp/kup message as described in 2916 Section 4.1. 2918 Note: If central key generation is performed by the responding PKI 2919 management entity, the responding PKI management entity MUST include 2920 in the response the privateKey field as specified in Section 4.1.6. 2921 It may have issued the certificate for the newly generated key pair 2922 itself if it is a CA, or have requested the certificate on behalf of 2923 the EE as described in Section 5.3.1, or have received it by other 2924 means from a CA. 2926 The prerequisites of the respective PKI management operation as 2927 specified in Section 4.1 apply. 2929 Note: If the EE requested omission of the certConf message, the PKI 2930 management entity SHOULD handle it as described in Section 4.1.1 and 2931 therfore MAY grant this by including the implicitConfirm extension in 2932 the response header. 2934 5.1.2. Initiating delayed enrollment 2936 This functional extension can be used by a PKI management entity to 2937 initiate delayed enrollment. In this case a PKI management entity 2938 MUST use the status "waiting" in the response message as described in 2939 Section 4.1.7 and then MUST reply to pollReq messages as described 2940 there. 2942 Typically, as stated in Section 5.2.3, an intermediate PKI management 2943 entity SHOULD NOT change the sender and recipient nonces even in case 2944 it modifies a request or a response message. In the special case of 2945 delayed enrollment initiated by an intermediate PKI management 2946 entity, for example by an LRA with offline transport to an upstream 2947 RA, there is an exception. Between the EE and this PKI management 2948 entity, pollReq and pollRep messages are exchanged handling the 2949 nonces as usual. Yet when, after some pollRep, the final response 2950 from upstream arrives at the PKI management entity, this response 2951 contains the recipNonce copied (as usual) from the senderNonce in the 2952 original request message. The PKI management entity that initiated 2953 the delayed enrollment MUST replace the recipNonce in the response 2954 message with the senderNonce of the last received pollReq because the 2955 downstream entities, including the EE, will expect it in this way. 2957 The prerequisites of the respective PKI management operation as 2958 specified in Section 4.1.7 apply. 2960 5.1.3. Responding to a confirmation message 2962 A PKI management entity MUST handle a certConf message if it has 2963 responded before with a positive ip/cp/kup message not granting 2964 implicit confirmation. It SHOULD check the message body according to 2965 the requirements given in Section 4.1.1 (failInfo bit: badCertId) and 2966 react as described there. 2968 The prerequisites of the respective PKI management operation as 2969 specified in Section 4.1 apply. 2971 5.1.4. Responding to a revocation request 2973 An rr message is used to request revocation of a certificate. The 2974 responding PKI management entity SHOULD check the message body 2975 according to the requirements in Section 4.2. It MUST make sure that 2976 the referenced certificate exists (failInfo bit: badCertId), has been 2977 issued by the addressed CA, and is not already expired or revoked 2978 (failInfo bit: certRevoked). On success it MUST respond with a 2979 positive rp message as described in Section 4.2. 2981 No specific prerequisites apply in addition to those specified in 2982 Section 3.4. 2984 5.1.5. Responding to a support message 2986 A genm message is used to retrieve extra content. The responding PKI 2987 management entity SHOULD check the message body according to the 2988 applicable requirements in Section 4.3 and perform any further checks 2989 depending on the PKI policy. On success it MUST respond with a genp 2990 message as described there. 2992 No specific prerequisites apply in addition to those specified in 2993 Section 3.4. 2995 5.2. Forwarding messages 2997 In case the PKI solution consists of intermediate PKI management 2998 entities (i.e., LRA or RA), each CMP request message coming from an 2999 EE or any other downstream PKI management entity SHOULD be forwarded 3000 to the next (upstream) PKI management entity as described in this 3001 section and otherwise MUST be answered as described in Section 5.1. 3002 Any received response message or error message MUST be forwarded to 3003 the next (downstream) PKI entity. 3005 In addition to the checks described in Section 3.5, the forwarding 3006 PKI management entity MAY verify the proof-of-possession for 3007 ir/cr/p10cr/kur messages. If one of these verification procedures 3008 fails, the RA proceeds as described in Section 3.6. 3010 A PKI management entity SHOULD NOT change the received message unless 3011 necessary. The PKI management entity SHOULD only update the message 3012 protection and the certificate template in a certificate request 3013 message if this is technically necessary. Concrete PKI system 3014 specifications may define in more detail when to do so. 3016 This is particularly relevant in the upstream communication of a 3017 request message. 3019 Each forwarding PKI management entity has one or more 3020 functionalities. It may 3022 * verify the identities of EEs and make authorization decisions for 3023 certification request processing based on specific knowledge of 3024 the local setup, e.g., by consulting an inventory or asset 3025 management system, 3027 * add or modify fields of certificate request messages, 3029 * store data from a message in a database for later usage or audit 3030 purposes, 3032 * provide traversal of a network boundary, 3034 * replace a MAC-based protection by a signature-based protection 3035 that can be verified also further upstream, 3037 * double-check if the messages transferred back and forth are 3038 properly protected and well-formed, 3040 * provide an authentic indication that it has performed all required 3041 checks, 3043 * initiate a delayed enrollment due to offline upstream 3044 communication or human interaction, or 3046 * collect messages from multiple RAs and forward them jointly. 3048 The decision if a message should be forwarded 3050 * unchanged with the original protection, 3052 * unchanged with a new protection, or 3053 * changed with a new protection 3055 depends on the PKI solution design and the associated security policy 3056 (CP/CPS [RFC3647]). 3058 A PKI management entity MUST replace or add a protection of a message 3059 if it 3061 * needs to securely indicate that it has done checks or validations 3062 on the message to one of the next (upstream) PKI management entity 3063 or 3065 * needs to protect the message using a key and certificate from a 3066 different PKI. 3068 A PKI management entity MUST replace a protection of a message if it 3070 * performs changes to the header or the body of the message or 3072 * needs to convert from or to a MAC-based protection. 3074 This is particularly relevant in the upstream communication of 3075 certificate request messages. 3077 Note that the message protection covers only the header and the body 3078 and not the extraCerts. The PKI management entity MAY change the 3079 extraCerts in any of the following message adaptations, e.g., to 3080 sort, add, or delete certificates to support subsequent PKI entities. 3081 This may be particularly helpful to augment upstream messages with 3082 additional certificates or to reduce the number of certificates in 3083 downstream messages when forwarding to constrained devices. 3085 5.2.1. Not changing protection 3087 This variant means that a PKI management entity forwards a CMP 3088 message without changing the header, body, or protection. In this 3089 case the PKI management entity acts more like a proxy, e.g., on a 3090 network boundary, implementing no specific RA-like security 3091 functionality that requires an authentic indication to the PKI. 3092 Still the PKI management entity might implement checks that result in 3093 refusing to forward the request message and instead responding as 3094 specified in Section 3.6. 3096 This variant of forwarding a message or the one described in 3097 Section 5.2.2.1 SHOULD be used for kur messages and for central key 3098 generation. 3100 No specific prerequisites apply in addition to those specified in 3101 Section 3.4. 3103 5.2.2. Adding protection and batching of messages 3105 This variant of forwarding a message means that a PKI management 3106 entity adds another protection to PKI management messages before 3107 forwarding them. 3109 The nested message is a PKI management message containing a 3110 PKIMessages sequence as its body containing one or more CMP messages. 3112 As specified in the updated Section 5.1.3.4 of RFC4210 [RFC4210] (see 3113 CMP Updates [I-D.ietf-lamps-cmp-updates]) there are various use cases 3114 for adding another protection by a PKI management entity. Specific 3115 procedures are described in more detail in the following sections. 3117 Detailed message description: 3119 Nested Message - nested 3121 Field Value 3123 header 3124 -- As described in Section 3.1 3126 body 3127 -- Container to provide additional protection to original 3128 -- messages and to bundle request messages or alternatively 3129 -- response messages 3130 PKIMessages REQUIRED 3131 -- MUST be a sequence of one or more CMP messages 3133 protection REQUIRED 3134 -- As described in Section 3.2 using the CMP protection key of 3135 -- the PKI management entity 3137 extraCerts REQUIRED 3138 -- As described in Section 3.3 3140 5.2.2.1. Adding protection to a request message 3142 A PKI management entity may authentically indicate successful 3143 validation and approval of a request message by adding an extra 3144 signature to the original message. 3146 By adding a protection using its own CMP protecting key the PKI 3147 management entity provides a proof of verifying and approving the 3148 message as described above. Thus, the PKI management entity acts as 3149 an actual Registration Authority (RA), which implements important 3150 security functionality of the PKI. Applying an additional protection 3151 is specifically relevant when forwarding a message that requests a 3152 certificate update or central key generation. This is because the 3153 original protection of the EE must be preserved while adding an 3154 indication of approval by the PKI management entity. 3156 The PKI management entity wrapping the original request message in a 3157 nested message structure MUST take over the recipient, recipNonce, 3158 and transactionID of the original message to the nested message and 3159 apply signature-based protection. The additional signature serves as 3160 proof of verification and authorization by this PKI management 3161 entity. 3163 The PKI management entity receiving such a nested message that 3164 contains a single request message MUST validate the additional 3165 protection signature on the nested message and check the 3166 authorization for the approval it implies. 3168 The PKI management entity responding to the request contained in the 3169 nested message sends the response message as described in 3170 Section 5.1, without wrapping it in a nested message. 3172 Note: This form of nesting messages is characterized by the fact that 3173 the transactionID in the header of the nested message is the same as 3174 the one used in the included message. 3176 Specific prerequisites augmenting the prerequisites in Section 3.4: 3178 * The PKI management entity MUST have the authorization to perform 3179 the validation and approval of the respective request according to 3180 the PKI policies. 3182 Message flow: 3184 Step# PKI management entity PKI management entity 3185 1 format nested 3186 2 -> nested -> 3187 3 handle or forward nested 3188 4 format or receive response 3189 5 <- response <- 3190 6 forward response 3192 5.2.2.2. Batching messages 3194 A PKI management entity MAY bundle any number of PKI management 3195 messages for batch processing or to transfer a bulk of PKI management 3196 messages using the nested message structure. In this use case, 3197 nested messages are used both on the upstream interface towards the 3198 next PKI management entity and on the downstream interface from the 3199 PKI management entity towards the EE. 3201 This PKI management operation is typically used on the interface 3202 between an LRA and an RA to bundle several messages for offline 3203 transport. In this case the LRA needs to initiate delayed enrollment 3204 as described in Section 5.1.2. If the RA needs different routing 3205 information per nested PKI management message a suitable mechanism 3206 may need to be implemented. Since this mechanism strongly depends on 3207 the requirements of the target architecture, it is out of scope of 3208 this document. 3210 A nested message containing requests is generated locally at the PKI 3211 management entity. For the upstream nested message, the PKI 3212 management entity acts as a protocol end point and therefore a fresh 3213 transactionID and a fresh senderNonce MUST be used in the header of 3214 the nested message. An upstream nested message may contain request 3215 messages, e.g., ir, cr, p10cr, kur, pollReq, certConf, rr, or genm. 3216 While building the upstream nested message the PKI management entity 3217 SHOULD store the sender, transactionID, and senderNonce fields of all 3218 bundled messages together with the transactionID of the upstream 3219 nested message. 3221 Such an upstream nested message is sent to the next PKI management 3222 entity. The upstream PKI management entity that unbundles it MUST 3223 handle each of the included request messages as usual. It MUST 3224 answer with a downstream nested message. This downstream nested 3225 message MUST use the transactionID of the upstream nested message and 3226 return the senderNonce of the upstream nested message as the 3227 recipNonce of the downstream nested message. The downstream nested 3228 message SHOULD bundle the individual response messages (e.g., ip, cp, 3229 kup, pollRep, pkiConf, rp, genp, error) for all original request 3230 messages of the upstream nested message. While unbundling the 3231 downstream nested message, the former PKI management entity can 3232 determine lost and unexpected responses based on the previously 3233 stored transactionIDs. When it forwards the unbundled responses, any 3234 extra messages SHOULD be dropped, and any missing response message 3235 (failInfo bit: systemUnavail) MUST be answered with an error message 3236 to inform the respective requester about the failed certificate 3237 management operation. 3239 Note: This form of nesting messages is characterized by the fact that 3240 the transactionID in the header of the nested message is different to 3241 those used in the included messages. 3243 The protection of the nested messages SHOULD NOT be regarded as an 3244 indication of verification or approval of the bundled PKI request 3245 messages. 3247 No specific prerequisites apply in addition to those specified in 3248 Section 3.4. 3250 Message flow: 3252 Step# PKI management entity PKI management entity 3253 1 format nested 3254 2 -> nested -> 3255 3 handle or forward nested 3256 4 format or receive nested 3257 5 <- nested <- 3258 6 handle nested 3260 5.2.3. Replacing protection 3262 The following two alternatives can be used by any PKI management 3263 entity forwarding a CMP message with or without changes while 3264 providing its own protection and in this way asserting approval of 3265 the message. 3267 By replacing the existing protection using its own CMP protecting key 3268 the PKI management entity provides a proof of verifying and approving 3269 the message as described above. Thus, the PKI management entity acts 3270 as an actual Registration Authority (RA), which implements important 3271 security functionality of the PKI. 3273 Before replacing the existing protection by a new protection, the PKI 3274 management entity MUST verify the protection provided and approve its 3275 content, including any modifications that it may perform. It MUST 3276 also check that the sender, as authenticated by the message 3277 protection, is authorized for the given operation. 3279 These message adaptations MUST NOT be applied to kur messages 3280 described in Section 4.1.3 since their original protection using the 3281 key and certificate to be updated needs to be preserved, unless the 3282 regCtrl OldCertId is used to strongly identify the certificate to be 3283 updated. 3285 These message adaptations MUST NOT be applied to certificate request 3286 messages described in for central key generation Section 4.1.6 since 3287 their original protection needs to be preserved up to the Key 3288 Generation Authority, which needs to use it for encrypting the new 3289 private key for the EE. 3291 In both the kur and central key generation cases, if a PKI management 3292 entity needs to state its approval of the original request message it 3293 MUST provide this using a nested message as specified in 3294 Section 5.2.2.1. 3296 When an intermediate PKI management entity modifies a message, it 3297 SHOULD NOT change the transactionID nor the sender and recipient 3298 nonces except as stated for delayed enrollment in Section 4.1.7 and 3299 Section 5.1.2. 3301 5.2.3.1. Not changing any included proof-of-possession 3303 This variant of forwarding a message means that a PKI management 3304 entity forwards a CMP message with or without modifying the message 3305 header or body while preserving any included proof-of-possession. 3307 In case the PKI management entity breaks an existing proof-of- 3308 possession, the message adaptation described in Section 5.2.3.2 needs 3309 to be applied instead. 3311 Specific prerequisites augmenting the prerequisites in Section 3.4: 3313 * The PKI management entity MUST have the authorization to perform 3314 the validation and approval of the respective request according to 3315 the PKI policies. 3317 5.2.3.2. Breaking proof-of-possession 3319 This variant of forwarding a message needs to be used if a PKI 3320 management entity breaks a signature-based proof-of-possession in a 3321 certificate request message, for instance because it forwards an ir 3322 or cr message with modifications of the certTemplate, i.e., 3323 modification, addition, or removal of fields. 3325 The PKI management entity MUST verify the proof-of-possession 3326 contained in the original message using the included public key. If 3327 successful, the PKI management entity MUST change the popo field 3328 value to raVerified. 3330 Specific prerequisites augmenting the prerequisites in Section 3.4: 3332 * The PKI management entity MUST have the authorization to verify 3333 the proof-of-possession. 3335 * The PKI management entity MUST have the authorization to perform 3336 the validation and approval of the respective request according to 3337 the PKI policies. 3339 The new popo field MUST contain the raVerified choice in the certReq 3340 structure of the modified message as follows: 3342 popo 3343 raVerified REQUIRED 3344 -- MUST have the value NULL and indicates that the PKI 3345 -- management entity verified the popo of the original message 3347 5.3. Acting on behalf of other PKI entities 3349 A PKI management entity may need to request a PKI management 3350 operation on behalf of another PKI entity. In this case the PKI 3351 management entity initiates the respective PKI management operation 3352 as described in Section 4 acting in the role of the EE. 3354 5.3.1. Requesting certificates 3356 A PKI management entity may use on of the PKI management operations 3357 described in Section 4.1 to request a certificate on behalf of 3358 another PKI entity. It either generates the key pair itself and 3359 inserts the new public key in the subjectPublicKey field of the 3360 request certTemplate, or it uses a certificate request received from 3361 downstream, e.g., by means of a different protocol. In the latter 3362 case it SHOULD verify the received proof-of-possession. 3364 No specific prerequisites apply in addition to those specified in 3365 Section 4.1. 3367 Note: An upstream PKI management entity will not be able to 3368 differentiate this PKI management operation from the one described in 3369 Section 5.2.3. 3371 The message sequence for this PKI management operation is identical 3372 to the respective PKI management operation given in Section 4.1, with 3373 the following changes: 3375 1 The request messages MUST be signed using the CMP protection key 3376 of the PKI management entity taking the role of the EE in this 3377 operation. 3379 2 If inclusion of a proper proof-of-possession is not possible the 3380 PKI management entity MUST verify the POP provided from downstream 3381 and use "raVerified" in its upstream request. 3383 5.3.2. Revoking a certificate 3385 A PKI management entity may use the PKI management operation 3386 described in Section 4.2 to revoke a certificate of another PKI 3387 entity. This revocation request message MUST be signed by the PKI 3388 management entity using its own CMP protection key to prove to the 3389 PKI authorization to revoke the certificate on behalf of that PKI 3390 entity. 3392 No specific prerequisites apply in addition to those specified in 3393 Section 4.2. 3395 Note: An upstream PKI management entity will not be able to 3396 differentiate this PKI management operation from the ones described 3397 in Section 5.2.3. 3399 The message sequence for this PKI management operation is identical 3400 to that given in Section 4.2, with the following changes: 3402 1 The rr message MUST be signed using the CMP protection key of the 3403 PKI management entity taking the role of the EE in this operation. 3405 6. CMP message transport mechanisms 3407 The CMP messages are designed to be self-contained, such that in 3408 principle any transport can be used. HTTP SHOULD be used for online 3409 transport while file-based transport MAY be used in case offline 3410 transport is required. In case HTTP transport is not desired or 3411 possible, CMP messages MAY also be piggybacked on any other reliable 3412 transport protocol such as CoAP [RFC7252]. 3414 Independently of the means of transport, it can happen that messages 3415 are lost or that a communication partner does not respond. To 3416 prevent waiting indefinitely, each CMP client component SHOULD use a 3417 configurable per-request timeout, and each CMP server component 3418 SHOULD use a configurable per-response timeout in case a further 3419 Request message is to be expected from the client side within the 3420 same transaction. In this way a hanging transaction can be closed 3421 cleanly with an error as described in Section 3.6 (failInfo bit: 3422 systemUnavail) and related resources (for instance, any cached 3423 extraCerts) can be freed. 3425 When conveying a CMP messages in HTTP, CoAP, or MIME-based transport 3426 protocols, the internet media type "application/pkixcmp" MUST be set 3427 for transport encoding as specified in Section 5.3 of RFC 2510 3428 [RFC2510], Section 2.4 of CMP over CoAP 3429 [I-D.ietf-ace-cmpv2-coap-transport], and Section 3.4 of CMP over HTTP 3430 [RFC6712]. 3432 Note: When using TCP as reliable transport layer protocol, which is 3433 typical in conjunction with HTTP, there is the option to keep the 3434 connection open over the lifetime of the PKI management operation 3435 containing multiple request-response message pairs. This may improve 3436 efficiency but is not required from a security point of view. 3438 6.1. HTTP transport 3440 This transport mechanism can be used by a PKI entity to transfer CMP 3441 messages over HTTP. If HTTP transport is used the specifications as 3442 described in [RFC6712] and updated by CMP Updates 3443 [I-D.ietf-lamps-cmp-updates] MUST be followed. 3445 PKI management operations SHOULD use the following URI paths. When a 3446 single request message is nested as described in Section 5.2.2.1, the 3447 endpoint to use is the same as for the underlying request message. 3449 For MAC-based protection the endpoint of the respective message body 3450 SHALL be used, e.g, use /initialization for ir messages. 3452 +=================================+=====================+=========+ 3453 | PKI management operation | Path | Details | 3454 +=================================+=====================+=========+ 3455 | Enroll client to new PKI | /initialization | Section | 3456 | | | 4.1.1 | 3457 +---------------------------------+---------------------+---------+ 3458 | Enroll client to existing PKI | /certification | Section | 3459 | | | 4.1.2 | 3460 +---------------------------------+---------------------+---------+ 3461 | Update client certificate | /keyupdate | Section | 3462 | | | 4.1.3 | 3463 +---------------------------------+---------------------+---------+ 3464 | Enroll client using PKCS#10 | /p10 | Section | 3465 | | | 4.1.5 | 3466 +---------------------------------+---------------------+---------+ 3467 | Enroll client using central key | /serverkeygen | Section | 3468 | generation | | 4.1.6 | 3469 | | | | 3470 | Note: This path element MAY | | | 3471 | also be appended to each of the | | | 3472 | path elements listed above. | | | 3473 +---------------------------------+---------------------+---------+ 3474 | Revoke client certificate | /revocation | Section | 3475 | | | 4.2 | 3476 +---------------------------------+---------------------+---------+ 3477 | Get CA certificates | /getcacert | Section | 3478 | | | 4.3.1 | 3479 +---------------------------------+---------------------+---------+ 3480 | Get root CA certificate update | /getrootupdate | Section | 3481 | | | 4.3.2 | 3482 +---------------------------------+---------------------+---------+ 3483 | Get certificate request | /getcertreqtemplate | Section | 3484 | template | | 4.3.3 | 3485 +---------------------------------+---------------------+---------+ 3486 | Batching messages | /nested | Section | 3487 | | | 5.2.2.2 | 3488 | Note: This path element is | | | 3489 | applicable only between PKI | | | 3490 | management entities. | | | 3491 +---------------------------------+---------------------+---------+ 3493 Table 9: HTTP endpoints 3495 Subsequent certConf and pollReq messages are sent to the URI of the 3496 first request message of the respective PKI management operation. 3498 By sending a request to its preferred enrollment endpoint, the PKI 3499 entity will recognize via the HTTP response status code whether a 3500 configured URI is supported by the PKI management entity. 3502 In case a PKI management entity receives an unexpected HTTP status 3503 code from upstream, it MUST respond downstream with an error message 3504 as described in Section 3.6 using a failInfo bit corresponding to the 3505 status code, e.g., systemFailure. 3507 For certificate management the major security goal is integrity and 3508 data origin authentication. For delivery of centrally generated 3509 keys, also confidentiality is a must. These goals are sufficiently 3510 achieved by CMP itself, also in an end-to-end fashion. If a second 3511 line of defense is required or general privacy concerns exist, TLS 3512 can be used to provide confidentiality on a hop-by-hop basis. 3514 TLS SHOULD be used with certificate-based authentication to further 3515 protect the HTTP transport as described in [RFC2818]. The CMP 3516 transport via HTTPS MUST use TLS server authentication and SHOULD use 3517 TLS client authentication. 3519 Note: The requirements for checking certificates given in [RFC5280], 3520 [RFC5246], and [RFC8446] MUST be followed for the TLS layer. 3521 Certificate status checking SHOULD be used for the TLS certificates 3522 of all communication partners. 3524 TLS with mutual authentication based on shared secret information MAY 3525 be used in case no suitable certificates for certificate-based 3526 authentication are available, e.g., a PKI management operation with 3527 MAC-based protection is used. 3529 Note: The entropy of the shared secret information is crucial for the 3530 level of protection available using shard secret information-based 3531 TLS authentication. A pre-shared key (PSK) mechanism is acceptable 3532 using shared secret information with an entropy of at least 128 bits. 3533 Otherwise a password-authenticated key exchange (PAKE) protocol is 3534 RECOMMENDED. 3536 6.2. CoAP transport 3538 This transport mechanism can be used by a PKI entity to transfer CMP 3539 messages over CoAP [RFC7252], e.g., in constrained environments. If 3540 CoAP transport is used the specifications as described in CMP over 3541 CoAP [I-D.ietf-ace-cmpv2-coap-transport] MUST be followed. 3543 PKI management operations SHOULD use the following URI paths. When a 3544 single request message is nested as described in Section 5.2.2.1, the 3545 path to use is the same as for the underlying request message. For 3546 MAC-based protection the path of the respective message body SHALL be 3547 used, e.g., use /ir for ir messages. 3549 +==============================================+=======+=========+ 3550 | PKI management operation | Path | Details | 3551 +==============================================+=======+=========+ 3552 | Enroll client to new PKI | /ir | Section | 3553 | | | 4.1.1 | 3554 +----------------------------------------------+-------+---------+ 3555 | Enroll client to existing PKI | /cr | Section | 3556 | | | 4.1.2 | 3557 +----------------------------------------------+-------+---------+ 3558 | Update client certificate | /kur | Section | 3559 | | | 4.1.3 | 3560 +----------------------------------------------+-------+---------+ 3561 | Enroll client using PKCS#10 | /p10 | Section | 3562 | | | 4.1.5 | 3563 +----------------------------------------------+-------+---------+ 3564 | Enroll client using central key generation | /ckg | Section | 3565 | | | 4.1.6 | 3566 | Note: This path element MAY also be appended | | | 3567 | to each of the path elements listed above. | | | 3568 +----------------------------------------------+-------+---------+ 3569 | Revoke client certificate | /rr | Section | 3570 | | | 4.2 | 3571 +----------------------------------------------+-------+---------+ 3572 | Get CA certificates | /crts | Section | 3573 | | | 4.3.1 | 3574 +----------------------------------------------+-------+---------+ 3575 | Get root CA certificate update | /rcu | Section | 3576 | | | 4.3.2 | 3577 +----------------------------------------------+-------+---------+ 3578 | Get certificate request template | /att | Section | 3579 | | | 4.3.3 | 3580 +----------------------------------------------+-------+---------+ 3581 | Batching messages | /nest | Section | 3582 | | | 5.2.2.2 | 3583 | Note: This path element is applicable only | | | 3584 | between PKI management entities. | | | 3585 +----------------------------------------------+-------+---------+ 3587 Table 10: CoAP endpoints 3589 Subsequent certConf and pollReq messages are sent to the URI of the 3590 first request message of the respective PKI management operation. 3592 By sending a request to its preferred enrollment endpoint, the PKI 3593 entity will recognize via the CoAP response status code whether a 3594 configured URI is supported by the PKI management entity. The CoAP- 3595 inherent discovery mechanisms MAY also be used. 3597 In case a PKI management entity receives an unexpected CoAP status 3598 code from upstream, it MUST respond downstream with an error message 3599 as described in Section 3.6 using a failInfo bit corresponding to the 3600 status code, e.g., systemFailure. 3602 Like for HTTP transport, to offer a second line of defense or to 3603 provide hop-by-hop privacy protection, DTLS MAY be utilized as 3604 described in CMP over CoAP [I-D.ietf-ace-cmpv2-coap-transport]. 3606 6.3. Piggybacking on other reliable transport 3608 CMP messages MAY also be transported on some other reliable protocol. 3609 Connection and error handling mechanisms similar to those specified 3610 for HTTP in Section 6.1 need to be implemented. 3612 A more detailed specification is out of scope of this document and 3613 would need to be given for instance in the scope of the transport 3614 protocol used. 3616 6.4. Offline transport 3618 For transporting CMP messages between PKI entities, any mechanism can 3619 be used that is able to store and forward binary objects of 3620 sufficient length and with sufficient reliability while preserving 3621 the order of messages for each transaction. 3623 The transport mechanism SHOULD be able to indicate message loss, 3624 excessive delay, and possibly other transmission errors. In such 3625 cases the PKI entities SHOULD report an error as specified in 3626 Section 3.6 as far as possible. 3628 6.4.1. File-based transport 3630 CMP messages MAY be transferred between PKI entities using file-based 3631 mechanisms, for instance when an offline EE or a PKI management 3632 entity performs delayed enrollment. Each file MUST contain the ASN.1 3633 DER encoding of one CMP message only, where the message may be 3634 nested. There MUST be no extraneous header or trailer information in 3635 the file. The file name extension ".PKI" MUST be used. 3637 6.4.2. Other asynchronous transport protocols 3639 Other asynchronous transport protocols, e.g., email or website 3640 up-/download, MAY transfer CMP messages between PKI entities. A MIME 3641 wrapping is defined for those environments that are MIME-native. The 3642 MIME wrapping in this section is specified in [RFC8551], section 3.1. 3644 The ASN.1 DER encoding of the CMP messages MUST be transferred using 3645 the "application/pkixcmp" content type and base64-encoded content 3646 transfer encoding as specified in [RFC2510], section 5.3. A filename 3647 MUST be included either in a "content-type" or a "content- 3648 disposition" statement. The file name extension ".PKI" MUST be used. 3650 7. IANA Considerations 3652 8. Security Considerations 3654 For requirements regarding proper random number and key generation 3655 please refer to [RFC4086]. 3657 For the case of centrally generated key pairs, the entropy of the 3658 shared secret information SHALL not be less than the security 3659 strength of the centrally generated key pair; if the shared secret 3660 information is re-used for different key pairs, the entropy and the 3661 security of the underlying cryptographic mechanisms SHOULD exceed the 3662 security strength of the key pairs. 3664 For the case of a PKI management operation that delivers a new trust 3665 anchor, e.g., a root CA certificate, using caPubs, (a) that is not 3666 concluded in a timely manner or (b) where the shared secret 3667 information is re-used for several key management operations, the 3668 entropy of the shared secret information SHALL not be less than the 3669 security strength of the key material being managed by the operation. 3671 For other cases, it is recommended to (a) either use a shared secret 3672 information of possibly low entropy (e.g., a password) only for a 3673 single PKI management operation or (b) use a shared secret 3674 information with an entropy that matches the security strength of the 3675 key material being managed by the operation. 3677 Further recommendations on algorithms to use with shared secret 3678 information is available in CMP Algorithms 3679 [I-D.ietf-lamps-cmp-algorithms]. 3681 For TLS using shared secret information-based authentication both PSK 3682 and PAKE provide the same amount of protection against a real-time 3683 authentication attack which is directly the amount of entropy in the 3684 shared secret. The difference between a pre-shared key (PSK) and a 3685 password-authenticated key exchange (PAKE) protocols is in the level 3686 of long-term confidentiality of the TLS messages against brute-force 3687 decryption, where a PSK-based cipher suite only provides security 3688 according to the entropy of the shared secret, while a PAKE-based 3689 cipher suite provides full security independent of the entropy of the 3690 shared secret. 3692 < TBD: Add any security considerations > 3694 9. Acknowledgements 3696 We thank the various reviewers of this document. 3698 10. References 3700 10.1. Normative References 3702 [I-D.ietf-ace-cmpv2-coap-transport] 3703 Sahni, M. and S. Tripathi, "CoAP Transport for Certificate 3704 Management Protocol", Work in Progress, Internet-Draft, 3705 draft-ietf-ace-cmpv2-coap-transport-02, 25 May 2021, 3706 . 3709 [I-D.ietf-lamps-cmp-algorithms] 3710 Brockhaus, H., Aschauer, H., Ounsworth, M., and J. Gray, 3711 "Certificate Management Protocol (CMP) Algorithms", Work 3712 in Progress, Internet-Draft, draft-ietf-lamps-cmp- 3713 algorithms-05, 7 May 2021, 3714 . 3717 [I-D.ietf-lamps-cmp-updates] 3718 Brockhaus, H. and D. V. Oheimb, "Certificate Management 3719 Protocol (CMP) Updates", Work in Progress, Internet-Draft, 3720 draft-ietf-lamps-cmp-updates-10, 4 May 2021, 3721 . 3724 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 3725 Requirement Levels", BCP 14, RFC 2119, 3726 DOI 10.17487/RFC2119, March 1997, 3727 . 3729 [RFC2986] Nystrom, M. and B. Kaliski, "PKCS #10: Certification 3730 Request Syntax Specification Version 1.7", RFC 2986, 3731 DOI 10.17487/RFC2986, November 2000, 3732 . 3734 [RFC4086] Eastlake 3rd, D., Schiller, J., and S. Crocker, 3735 "Randomness Requirements for Security", BCP 106, RFC 4086, 3736 DOI 10.17487/RFC4086, June 2005, 3737 . 3739 [RFC4210] Adams, C., Farrell, S., Kause, T., and T. Mononen, 3740 "Internet X.509 Public Key Infrastructure Certificate 3741 Management Protocol (CMP)", RFC 4210, 3742 DOI 10.17487/RFC4210, September 2005, 3743 . 3745 [RFC4211] Schaad, J., "Internet X.509 Public Key Infrastructure 3746 Certificate Request Message Format (CRMF)", RFC 4211, 3747 DOI 10.17487/RFC4211, September 2005, 3748 . 3750 [RFC5280] Cooper, D., Santesson, S., Farrell, S., Boeyen, S., 3751 Housley, R., and W. Polk, "Internet X.509 Public Key 3752 Infrastructure Certificate and Certificate Revocation List 3753 (CRL) Profile", RFC 5280, DOI 10.17487/RFC5280, May 2008, 3754 . 3756 [RFC5652] Housley, R., "Cryptographic Message Syntax (CMS)", STD 70, 3757 RFC 5652, DOI 10.17487/RFC5652, September 2009, 3758 . 3760 [RFC5958] Turner, S., "Asymmetric Key Packages", RFC 5958, 3761 DOI 10.17487/RFC5958, August 2010, 3762 . 3764 [RFC6712] Kause, T. and M. Peylo, "Internet X.509 Public Key 3765 Infrastructure -- HTTP Transfer for the Certificate 3766 Management Protocol (CMP)", RFC 6712, 3767 DOI 10.17487/RFC6712, September 2012, 3768 . 3770 [RFC8174] Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC 3771 2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174, 3772 May 2017, . 3774 [RFC9045] Housley, R., "Algorithm Requirements Update to the 3775 Internet X.509 Public Key Infrastructure Certificate 3776 Request Message Format (CRMF)", RFC 9045, 3777 DOI 10.17487/RFC9045, June 2021, 3778 . 3780 10.2. Informative References 3782 [ETSI-3GPP.33.310] 3783 3GPP, "Network Domain Security (NDS); Authentication 3784 Framework (AF)", 3GPP TS 33.310 16.6.0, 16 December 2020. 3786 [I-D.ietf-anima-brski-async-enroll] 3787 Fries, S., Brockhaus, H., Lear, E., and T. Werner, 3788 "Support of asynchronous Enrollment in BRSKI (BRSKI-AE)", 3789 Work in Progress, Internet-Draft, draft-ietf-anima-brski- 3790 async-enroll-03, 24 June 2021, 3791 . 3794 [IEC.62443-3-3] 3795 IEC, "Industrial communication networks - Network and 3796 system security - Part 3-3: System security requirements 3797 and security levels", IEC 62443-3-3, August 2013, 3798 . 3800 [IEEE.802.1AR_2018] 3801 IEEE, "IEEE Standard for Local and metropolitan area 3802 networks - Secure Device Identity", IEEE 802.1AR-2018, 3803 DOI 10.1109/IEEESTD.2018.8423794, 2 August 2018, 3804 . 3806 [NIST.CSWP.04162018] 3807 National Institute of Standards and Technology (NIST), 3808 "Framework for Improving Critical Infrastructure 3809 Cybersecurity, Version 1.1", NIST NIST CSWP 04162018, 3810 DOI 10.6028/NIST.CSWP.04162018, April 2018, 3811 . 3814 [NIST.SP.800-57p1r5] 3815 Barker, E B., "Recommendation for key management, part 1 3816 :general", NIST NIST.SP.800-57pt1r5, 3817 DOI 10.6028/NIST.SP.800-57pt1r5, 2020, 3818 . 3820 [RFC2510] Adams, C. and S. Farrell, "Internet X.509 Public Key 3821 Infrastructure Certificate Management Protocols", 3822 RFC 2510, DOI 10.17487/RFC2510, March 1999, 3823 . 3825 [RFC2818] Rescorla, E., "HTTP Over TLS", RFC 2818, 3826 DOI 10.17487/RFC2818, May 2000, 3827 . 3829 [RFC3647] Chokhani, S., Ford, W., Sabett, R., Merrill, C., and S. 3830 Wu, "Internet X.509 Public Key Infrastructure Certificate 3831 Policy and Certification Practices Framework", RFC 3647, 3832 DOI 10.17487/RFC3647, November 2003, 3833 . 3835 [RFC5246] Dierks, T. and E. Rescorla, "The Transport Layer Security 3836 (TLS) Protocol Version 1.2", RFC 5246, 3837 DOI 10.17487/RFC5246, August 2008, 3838 . 3840 [RFC7252] Shelby, Z., Hartke, K., and C. Bormann, "The Constrained 3841 Application Protocol (CoAP)", RFC 7252, 3842 DOI 10.17487/RFC7252, June 2014, 3843 . 3845 [RFC8366] Watsen, K., Richardson, M., Pritikin, M., and T. Eckert, 3846 "A Voucher Artifact for Bootstrapping Protocols", 3847 RFC 8366, DOI 10.17487/RFC8366, May 2018, 3848 . 3850 [RFC8446] Rescorla, E., "The Transport Layer Security (TLS) Protocol 3851 Version 1.3", RFC 8446, DOI 10.17487/RFC8446, August 2018, 3852 . 3854 [RFC8551] Schaad, J., Ramsdell, B., and S. Turner, "Secure/ 3855 Multipurpose Internet Mail Extensions (S/MIME) Version 4.0 3856 Message Specification", RFC 8551, DOI 10.17487/RFC8551, 3857 April 2019, . 3859 [UNISIG.Subset-137] 3860 UNISIG, "Subset-137; ERTMS/ETCS On-line Key Management 3861 FFFIS; V1.0.0", December 2015, 3862 . 3864 Appendix A. Example CertReqTemplate 3866 Suppose the server requires that the certTemplate contains 3868 * the issuer field with a value to be filled in by the EE, 3870 * the subject field with a common name to be filled in by the EE and 3871 two organizational unit fields with given values "myDept" and 3872 "myGroup", 3874 * the publicKey field contains an ECC key on curve secp256r1 or an 3875 RSA public key of length 2048, 3877 * the subjectAltName extension with DNS name "www.myServer.com" and 3878 an IP address to be filled in, 3880 * the keyUsage extension marked critical with the value 3881 digitalSignature and keyAgreement, and 3883 * the extKeyUsage extension with values to be filled in by the EE. 3885 Then the infoValue with certTemplate and keySpec fields returned to 3886 the EE will be encoded as follows: 3888 SEQUENCE { 3889 SEQUENCE { 3890 [3] { 3891 SEQUENCE {} 3892 } 3893 [5] { 3894 SEQUENCE { 3895 SET { 3896 SEQUENCE { 3897 OBJECT IDENTIFIER commonName (2 5 4 3) 3898 UTF8String "" 3899 } 3900 } 3901 SET { 3902 SEQUENCE { 3903 OBJECT IDENTIFIER organizationalUnitName (2 5 4 11) 3904 UTF8String "myDept" 3905 } 3906 } 3907 SET { 3908 SEQUENCE { 3909 OBJECT IDENTIFIER organizationalUnitName (2 5 4 11) 3910 UTF8String "myGroup" 3911 } 3912 } 3913 } 3914 } 3915 [9] { 3916 SEQUENCE { 3917 OBJECT IDENTIFIER subjectAltName (2 5 29 17) 3918 OCTET STRING, encapsulates { 3919 SEQUENCE { 3920 [2] "www.myServer.com" 3921 [7] "" 3922 } 3923 } 3925 } 3926 SEQUENCE { 3927 OBJECT IDENTIFIER keyUsage (2 5 29 15) 3928 BOOLEAN TRUE 3929 OCTET STRING, encapsulates { 3930 BIT STRING 3 unused bits 3931 "10001"B 3932 } 3933 } 3934 SEQUENCE { 3935 OBJECT IDENTIFIER extKeyUsage (2 5 29 37) 3936 OCTET STRING, encapsulates { 3937 SEQUENCE {} 3938 } 3939 } 3940 } 3941 } 3942 SEQUENCE { 3943 SEQUENCE { 3944 OBJECT IDENTIFIER aldId (1 3 6 1 5 5 7 5 1 TBD3) 3945 SEQUENCE { 3946 OBJECT IDENTIFIER ecPublicKey (1 2 840 10045 2 1) 3947 OBJECT IDENTIFIER secp256r1 (1 2 840 10045 3 1 7) 3948 } 3949 } 3950 SEQUENCE { 3951 OBJECT IDENTIFIER rsaKeyLen (1 3 6 1 5 5 7 5 1 TBD4) 3952 INTEGER 2048 3953 } 3954 } 3955 } 3957 Appendix B. History of changes 3959 Note: This appendix will be deleted in the final version of the 3960 document. 3962 From version 05 -> 06: 3964 * Changed in Section 2.3 the normative requirement in of adding 3965 protection to a single message to mandatory and replacing 3966 protection to optional 3967 * Added Section 3.4 specifying generic prerequisites to PKI 3968 management operations 3969 * Added Section 3.5 specifying generic message validation 3970 * Added Section 3.6 on generic error reporting. This section 3971 replaces the former error handling section from Section 4 and 5. 3972 * Added reference to using hashAlg 3973 * Updates Section 4.3.2 and Section 4.3.3 to align with CMP Updates 3974 * Added Section 5.1 specifying the behavior of PKI management 3975 entities when responding to requests 3976 * Reworked Section 5.2.3. on usage of nested messages 3977 * Updates Section 5.3 on performing PKI management operation on 3978 behalf of another entity 3979 * Updates Section 6.2 on HTTPS transport of CMP messages as 3980 discusses at IETF 110 and email thread "I-D Action: draft-ietf- 3981 lamps-lightweight-cmp-profile-05.txt" 3982 * Added CoAP endpoints to Section 6.4 3983 * Added security considerations on usage of shared secret 3984 information 3985 * Updated the example in Appendix A 3986 * Added newly registered OIDs to the example in Appendix A 3987 * Updated new RFC numbers for I-D.ietf-lamps-crmf-update-algs 3988 * Multiple language corrections, clarifications, and changes in 3989 wording 3991 From version 04 -> 05: 3993 * Changed to XML V3 3994 * Added algorithm names introduced in CMP Algorithms Section 7.3 to 3995 Section 4 of this document 3996 * Updates Syntax in Section 4.4.3 due to changes made in CMP Updates 3997 * Deleted the text on HTTP-based discovery as discussed in 3998 Section 6.1 3999 * Updates Appendix A due to change syntax in Section 4.4.3 4000 * Many clarifications and changes in wording thanks to David's 4001 extensive review 4003 From version 03 -> 04: 4005 * Deleted normative text sections on algorithms and refer to CMP 4006 Algorithms and CRMF Algorithm Requirements Update instead 4007 * Some clarifications and changes in wording 4009 From version 02 -> 03: 4011 * Updated the interoperability with [UNISIG.Subset-137] in 4012 Section 1.4. 4013 * Changed Section 2.3 to a tabular layout to enhanced readability 4014 * Added a ToDo to section 3.1 on aligning with the CMP Algorithms 4015 draft that will be set up as decided in IETF 108 4016 * Updated section 4.1.6 to add the AsymmetricKey Package structure 4017 to transport a newly generated private key as decided in IETF 108 4018 * Added a ToDo to section 4.1.7 on required review of the nonce 4019 handling in case an offline LRA responds and not forwards the 4020 pollReq messages 4022 * Updated Section 4 due to the definition of the new ITAV OIDs in 4023 CMP Updates 4024 * Updated Section 4.4.4 to utilize controls instead of rsaKeyLen 4025 (see thread "dtaft-ietf-lamps-cmp-updates and rsaKeyLen") 4026 * Deleted the section on definition and discovery of HTTP URIs and 4027 copied the text to the HTTP transport section and to CMP Updates 4028 section 3.2 4029 * Added some explanation to Section 5.1.2 and Section 5.1.3 on using 4030 nested messages when a protection by the RA is required. 4031 * Deleted the section on HTTP URI definition and discovery as some 4032 content was moved to CMP Updates. The rest of the content was 4033 moved back to the HTTP transport section 4034 * Deleted the ASN.1 module after moving the new OIDs id-it-caCerts, 4035 id-it-rootCaKeyUpdate, and id-it-certReqTemplate to CMP Updates 4036 * Minor changes in wording and addition of some open ToDos 4038 From version 01 -> 02: 4040 * Extend Section 1.5 with regard to conflicts with UNISIG Subset- 4041 137. 4042 * Minor clarifications on extraCerts in Section 3.3 and 4043 Section 4.1.1. 4044 * Complete specification of requesting a certificate from a trusted 4045 PKI with signature protection in Section 4.1.2. 4046 * Changed from symmetric key-encryption to password-based key 4047 management technique in section Section 4.1.6.3 as discussed on 4048 the mailing list (see thread "draft-ietf-lamps-lightweight-cmp- 4049 profile-01, section 5.1.6.1") 4050 * Changed delayed enrollment described in Section 4.1.7 from 4051 recommended to optional as decided at IETF 107 4052 * Introduced the new RootCAKeyUpdate structure for root CA 4053 certificate update in Section 4.3.2 as decided at IETF 107 (also 4054 see email thread "draft-ietf-lamps-lightweight-cmp-profile-01, 4055 section 5.4.3") 4056 * Extend the description of the CertReqTemplate PKI management 4057 operation, including an example added in the Appendix. Keep 4058 rsaKeyLen as a single integer value in Section 4.3.3 as discussed 4059 on the mailing list (see thread "draft-ietf-lamps-lightweight-cmp- 4060 profile-01, section 5.4.4") 4061 * Deleted Sections "Get certificate management configuration" and 4062 "Get enrollment voucher" as decided at IETF 107 4063 * Complete specification of adding an additional protection by an 4064 PKI management entity in Section 5.2.2. 4065 * Added a section on HTTP URI definition and discovery and extended 4066 Section 6.1 on definition and discovery of supported HTTP URIs and 4067 content types, add a path for nested messages as specified in 4068 Section 5.2.2 and delete the paths for /getCertMgtConfig and 4069 /getVoucher 4071 * Changed Section 6.4 to address offline transport and added more 4072 detailed specification file-based transport of CMP 4073 * Added a reference to the new I-D of Mohit Sahni on "CoAP Transport 4074 for CMPV2" in Section 6.2; thanks to Mohit supporting the effort 4075 to ease utilization of CMP 4076 * Moved the change history to the Appendix 4077 * Minor changes in wording 4079 From version 00 -> 01: 4081 * Harmonize terminology with CMP [RFC4210], e.g., 4082 - transaction, message sequence, exchange, use case -> PKI 4083 management operation 4084 - PKI component, (L)RA/CA -> PKI management entity 4085 * Minor changes in wording 4087 From draft-brockhaus-lamps-lightweight-cmp-profile-03 -> draft-ietf- 4088 lamps-lightweight-cmp-profile-00: 4090 * Changes required to reflect WG adoption 4091 * Minor changes in wording 4093 From version 02 -> 03: 4095 * Added a short summary of [RFC4210] Appendix D and E in 4096 Section 1.4. 4097 * Clarified some references to different sections and added some 4098 clarification in response to feedback from Michael Richardson and 4099 Tomas Gustavsson. 4100 * Added an additional label to the operational path to address 4101 multiple CAs or certificate profiles in Section 6.1. 4103 From version 01 -> 02: 4105 * Added some clarification on the key management techniques for 4106 protection of centrally generated keys in Section 4.1.6. 4107 * Added some clarifications on the certificates for root CA 4108 certificate update in Section 4.3.2. 4109 * Added a section to specify the usage of nested messages for RAs to 4110 add an additional protection for further discussion, see 4111 Section 5.2.2. 4112 * Added a table containing endpoints for HTTP transport in 4113 Section 6.1 to simplify addressing PKI management entities. 4114 * Added some ToDos resulting from discussion with Tomas Gustavsson. 4115 * Minor clarifications and changes in wording. 4117 From version 00 -> 01: 4119 * Added a section to specify the enrollment with an already trusted 4120 PKI for further discussion, see Section 4.1.2. 4121 * Complete specification of requesting a certificate from a legacy 4122 PKI using a PKCS#10 [RFC2986] request in Section 4.1.5. 4123 * Complete specification of adding central generation of a key pair 4124 on behalf of an end entity in Section 4.1.6. 4125 * Complete specification of handling delayed enrollment due to 4126 asynchronous message delivery in Section 4.1.7. 4127 * Complete specification of additional support messages, e.g., to 4128 update a Root CA certificate or to request an RFC 8366 [RFC8366] 4129 voucher, in Section 4.3. 4130 * Minor changes in wording. 4132 From draft-brockhaus-lamps-industrial-cmp-profile-00 -> draft- 4133 brockhaus-lamps-lightweight-cmp-profile-00: 4135 * Change focus from industrial to more multi-purpose use cases and 4136 lightweight CMP profile. 4137 * Incorporate the omitted confirmation into the header specified in 4138 Section 3.1 and described in the standard enrollment use case in 4139 Section 4.1.1 due to discussion with Tomas Gustavsson. 4140 * Change from OPTIONAL to RECOMMENDED for use case 'Revoke another's 4141 entities certificate' in Section 5.3.2, because it is regarded as 4142 important functionality in many environments to enable the 4143 management station to revoke EE certificates. 4144 * Complete the specification of the revocation message flow in 4145 Section 4.2 and Section 5.3.2. 4146 * The CoAP based transport mechanism and piggybacking of CMP 4147 messages on top of other reliable transport protocols is out of 4148 scope of this document and would need to be specified in another 4149 document. 4150 * Further minor changes in wording. 4152 Authors' Addresses 4154 Hendrik Brockhaus (editor) 4155 Siemens AG 4157 Email: hendrik.brockhaus@siemens.com 4159 Steffen Fries 4160 Siemens AG 4162 Email: steffen.fries@siemens.com 4163 David von Oheimb 4164 Siemens AG 4166 Email: david.von.oheimb@siemens.com