idnits 2.17.1 draft-ietf-lamps-cmp-updates-22.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 7 instances of lines with non-RFC6890-compliant IPv4 addresses in the document. If these are example addresses, they should be changed. -- The draft header indicates that this document updates RFC6712, but the abstract doesn't seem to directly say this. It does mention RFC6712 though, so this could be OK. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust and authors Copyright Line does not match the current year (Using the creation date from RFC4210, updated by this document, for RFC5378 checks: 2000-03-07) -- The document seems to lack a disclaimer for pre-RFC5378 work, but may have content which was first submitted before 10 November 2008. If you have contacted all the original authors and they are all willing to grant the BCP78 rights to the IETF Trust, then this is fine, and you can ignore this comment. If not, you may need to add the pre-RFC5378 disclaimer. (See the Legal Provisions document at https://trustee.ietf.org/license-info for more information.) -- The document date (26 June 2022) is 670 days in the past. Is this intentional? Checking references for intended status: Proposed Standard ---------------------------------------------------------------------------- (See RFCs 3967 and 4897 for information about using normative references to lower-maturity documents in RFCs) -- Looks like a reference, but probably isn't: '0' on line 3011 -- Looks like a reference, but probably isn't: '1' on line 2884 -- Looks like a reference, but probably isn't: '2' on line 2775 -- Looks like a reference, but probably isn't: '3' on line 2527 -- Looks like a reference, but probably isn't: '4' on line 2528 -- Looks like a reference, but probably isn't: '5' on line 2529 -- Looks like a reference, but probably isn't: '6' on line 2530 -- Looks like a reference, but probably isn't: '7' on line 2531 -- Looks like a reference, but probably isn't: '8' on line 2532 == Missing Reference: 'RFCXXXX' is mentioned on line 3028, but not defined -- Looks like a reference, but probably isn't: '9' on line 2533 -- Looks like a reference, but probably isn't: '10' on line 2534 -- Looks like a reference, but probably isn't: '11' on line 2535 -- Looks like a reference, but probably isn't: '12' on line 2536 -- Looks like a reference, but probably isn't: '13' on line 2537 -- Looks like a reference, but probably isn't: '14' on line 2538 -- Looks like a reference, but probably isn't: '15' on line 2539 -- Looks like a reference, but probably isn't: '16' on line 2540 -- Looks like a reference, but probably isn't: '17' on line 2541 -- Looks like a reference, but probably isn't: '18' on line 2542 -- Looks like a reference, but probably isn't: '19' on line 2543 -- Looks like a reference, but probably isn't: '20' on line 2544 -- Looks like a reference, but probably isn't: '21' on line 2545 -- Looks like a reference, but probably isn't: '22' on line 2546 -- Looks like a reference, but probably isn't: '23' on line 2547 -- Looks like a reference, but probably isn't: '24' on line 2548 -- Looks like a reference, but probably isn't: '25' on line 2549 -- Looks like a reference, but probably isn't: '26' on line 2550 == Unused Reference: 'RFC2510' is defined on line 1580, but no explicit reference was found in the text == Outdated reference: A later version (-10) exists of draft-ietf-ace-cmpv2-coap-transport-04 ** Obsolete normative reference: RFC 2510 (Obsoleted by RFC 4210) ** Downref: Normative reference to an Informational RFC: RFC 2985 ** Downref: Normative reference to an Informational RFC: RFC 2986 == Outdated reference: A later version (-21) exists of draft-ietf-lamps-lightweight-cmp-profile-12 Summary: 3 errors (**), 0 flaws (~~), 6 warnings (==), 30 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 D. von Oheimb 4 Updates: 4210, 5912, 6712 (if approved) Siemens 5 Intended status: Standards Track J. Gray 6 Expires: 28 December 2022 Entrust 7 26 June 2022 9 Certificate Management Protocol (CMP) Updates 10 draft-ietf-lamps-cmp-updates-22 12 Abstract 14 This document contains a set of updates to the syntax and transfer of 15 Certificate Management Protocol (CMP) version 2. This document 16 updates RFC 4210, RFC 5912, and RFC 6712. 18 The aspects of CMP updated in this document are using EnvelopedData 19 instead of EncryptedValue, clarifying the handling of p10cr messages, 20 improving the crypto agility, as well as adding new general message 21 types, extended key usages to identify certificates for use with CMP, 22 and well-known URI path segments. 24 CMP version 3 is introduced to enable signaling support of 25 EnvelopedData instead of EncryptedValue and signaling the use of an 26 explicit hash AlgorithmIdentifier in certConf messages, as far as 27 needed. 29 Status of This Memo 31 This Internet-Draft is submitted in full conformance with the 32 provisions of BCP 78 and BCP 79. 34 Internet-Drafts are working documents of the Internet Engineering 35 Task Force (IETF). Note that other groups may also distribute 36 working documents as Internet-Drafts. The list of current Internet- 37 Drafts is at https://datatracker.ietf.org/drafts/current/. 39 Internet-Drafts are draft documents valid for a maximum of six months 40 and may be updated, replaced, or obsoleted by other documents at any 41 time. It is inappropriate to use Internet-Drafts as reference 42 material or to cite them other than as "work in progress." 44 This Internet-Draft will expire on 28 December 2022. 46 Copyright Notice 48 Copyright (c) 2022 IETF Trust and the persons identified as the 49 document authors. All rights reserved. 51 This document is subject to BCP 78 and the IETF Trust's Legal 52 Provisions Relating to IETF Documents (https://trustee.ietf.org/ 53 license-info) in effect on the date of publication of this document. 54 Please review these documents carefully, as they describe your rights 55 and restrictions with respect to this document. Code Components 56 extracted from this document must include Revised BSD License text as 57 described in Section 4.e of the Trust Legal Provisions and are 58 provided without warranty as described in the Revised BSD License. 60 Table of Contents 62 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 3 63 1.1. Convention and Terminology . . . . . . . . . . . . . . . 4 64 2. Updates to RFC 4210 - Certificate Management Protocol 65 (CMP) . . . . . . . . . . . . . . . . . . . . . . . . . . 5 66 2.1. New Section 1.1. - Changes Since RFC 4210 . . . . . . . . 5 67 2.2. New Section 4.5 - Extended Key Usage . . . . . . . . . . 6 68 2.3. Update Section 5.1.1. - PKI Message Header . . . . . . . 7 69 2.4. New Section 5.1.1.3. - CertProfile . . . . . . . . . . . 8 70 2.5. Update Section 5.1.3.1. - Shared Secret Information . . . 9 71 2.6. Replace Section 5.1.3.4 - Multiple Protection . . . . . . 9 72 2.7. Replace Section 5.2.2. - Encrypted Values . . . . . . . . 10 73 2.8. New Section 5.2.9 - GeneralizedTime . . . . . . . . . . . 12 74 2.9. Update Section 5.3.4. - Certification Response . . . . . 12 75 2.10. Update Section 5.3.18. - Certificate Confirmation 76 Content . . . . . . . . . . . . . . . . . . . . . . . . 13 77 2.11. Update Section 5.3.19.2. - Signing Key Pair Types . . . . 14 78 2.12. Update Section 5.3.19.3. - Encryption/Key Agreement Key 79 Pair Types . . . . . . . . . . . . . . . . . . . . . . . 14 80 2.13. Replace Section 5.3.19.9. - Revocation Passphrase . . . . 14 81 2.14. New Section 5.3.19.14 - CA Certificates . . . . . . . . . 15 82 2.15. New Section 5.3.19.15 - Root CA Certificate Update . . . 15 83 2.16. New Section 5.3.19.16 - Certificate Request Template . . 16 84 2.17. New Section 5.3.19.17 - CRL Update Retrieval . . . . . . 17 85 2.18. Update Section 5.3.21 - Error Message Content . . . . . . 18 86 2.19. Replace Section 5.3.22 - Polling Request and Response . . 18 87 2.20. Update Section 7 - Version Negotiation . . . . . . . . . 23 88 2.21. Update Section 7.1.1. - Clients Talking to RFC 2510 89 Servers . . . . . . . . . . . . . . . . . . . . . . . . 24 90 2.22. Add Section 8.4 - Private Keys for Certificate Signing and 91 CMP Message Protection . . . . . . . . . . . . . . . . . 24 92 2.23. Add Section 8.5 - Entropy of Random Numbers, Key Pairs, and 93 Shared Secret Information . . . . . . . . . . . . . . . 24 95 2.24. Add Section 8.6 - Trust Anchor Provisioning Using CMP 96 Messages . . . . . . . . . . . . . . . . . . . . . . . . 25 97 2.25. Update Section 9 - IANA Considerations . . . . . . . . . 26 98 2.26. Update Appendix B - The Use of Revocation Passphrase . . 28 99 2.27. Update Appendix C - Request Message Behavioral 100 Clarifications . . . . . . . . . . . . . . . . . . . . . 28 101 2.28. Update Appendix D.1. - General Rules for Interpretation of 102 These Profiles . . . . . . . . . . . . . . . . . . . . . 29 103 2.29. Update Appendix D.2. - Algorithm Use Profile . . . . . . 30 104 2.30. Update Appendix D.4. - Initial Registration/Certification 105 (Basic Authenticated Scheme) . . . . . . . . . . . . . . 30 106 3. Updates to RFC 6712 - HTTP Transfer for the Certificate 107 Management Protocol (CMP) . . . . . . . . . . . . . . . . 30 108 3.1. Update Section 1. - Introduction . . . . . . . . . . . . 30 109 3.2. New Section 1.1. - Changes Since RFC 6712 . . . . . . . . 31 110 3.3. Replace Section 3.6. - HTTP Request-URI . . . . . . . . . 31 111 3.4. Update Section 6. - IANA Considerations . . . . . . . . . 32 112 4. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 33 113 5. Security Considerations . . . . . . . . . . . . . . . . . . . 35 114 6. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 35 115 7. References . . . . . . . . . . . . . . . . . . . . . . . . . 35 116 7.1. Normative References . . . . . . . . . . . . . . . . . . 35 117 7.2. Informative References . . . . . . . . . . . . . . . . . 37 118 Appendix A. ASN.1 Modules . . . . . . . . . . . . . . . . . . . 39 119 A.1. Update to RFC4210 - 1988 ASN.1 Module . . . . . . . . . . 39 120 A.2. Update to RFC5912 - 2002 ASN.1 Module . . . . . . . . . . 52 121 Appendix B. History of Changes . . . . . . . . . . . . . . . . . 66 122 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 72 124 1. Introduction 126 [RFC Editor: 128 Please perform the following substitution. 130 * RFCXXXX --> the assigned numerical RFC value for this draft 132 Please update the following references to associated drafts in 133 progress to reflect their final RFC assignments, if possible: 135 * I-D.ietf-lamps-cmp-algorithms 137 * I-D.ietf-lamps-lightweight-cmp-profile 139 * I-D.ietf-ace-cmpv2-coap-transport 141 ] 142 While using CMP [RFC4210] in industrial and IoT environments and 143 developing the Lightweight CMP Profile 144 [I-D.ietf-lamps-lightweight-cmp-profile] some limitations were 145 identified in the original CMP specification. This document updates 146 RFC 4210 [RFC4210] and RFC 6712 [RFC6712] to overcome these 147 limitations. 149 Among others, this document improves the crypto agility of CMP, which 150 means to be flexible to react on future advances in cryptography. 152 This document also introduces new extended key usages to identify CMP 153 endpoints on registration and certification authorities. 155 As the main content of RFC 4210 [RFC4210] and RFC 6712 [RFC6712] 156 stays unchanged, this document lists all sections that are updated, 157 replaced, or added to the current text of the respective RFCs. 159 The authors acknowledge that the style of the document is hard to 160 read because the original RFCs must be read along with this document 161 to get the complete content. The working group decided to use this 162 approach in order to keep the changes to RFC 4210 [RFC4210] and 163 RFC 6712 [RFC6712] to the required minimum. This was meant to speed 164 up the editorial process and to minimize the effort spent on 165 reviewing the whole text of the original documents. 167 1.1. Convention and Terminology 169 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 170 "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and 171 "OPTIONAL" in this document are to be interpreted as described in BCP 172 14 [RFC2119] [RFC8174] when, and only when, they appear in all 173 capitals, as shown here. 175 Technical terminology is used in conformance with RFC 4210 [RFC4210], 176 RFC 4211 [RFC4211], and RFC 5280 [RFC5280]. The following key words 177 are used: 179 CA: Certification authority, which issues certificates. 181 RA: Registration authority, an optional system component to which a 182 CA delegates certificate management functions such as 183 authorization checks. 185 KGA: Key generation authority, which generates key pairs on behalf 186 of an EE. The KGA could be co-located with an RA or a CA. 188 EE: End entity, a user, device, or service that holds a PKI 189 certificate. An identifier for the EE is given as its subject 190 of the certificate. 192 2. Updates to RFC 4210 - Certificate Management Protocol (CMP) 194 2.1. New Section 1.1. - Changes Since RFC 4210 196 The following subsection describes feature updates to RFC 4210 197 [RFC4210]. They are always related to the base specification. 198 Hence, references to the original sections in RFC 4210 [RFC4210] are 199 used whenever possible. 201 Insert this section at the end of the current Section 1: 203 1.1. Changes Since RFC 4210 205 The following updates are made in this document: 207 * Add new extended key usages for various CMP server types, e.g., 208 registration authority and certification authority, to express the 209 authorization of the entity identified in the certificate 210 containing the respective extended key usage extension to act as 211 the indicated PKI management entity. 213 * Extend the description of multiple protection to cover additional 214 use cases, e.g., batch processing of messages. 216 * Offering EnvelopedData as the preferred choice next to 217 EncryptedValue to better support crypto agility in CMP. Note that 218 according to RFC 4211 [RFC4211] section 2.1. point 9 the use of 219 the EncryptedValue structure has been deprecated in favor of the 220 EnvelopedData structure. RFC 4211 [RFC4211] offers the 221 EncryptedKey structure, a choice of EncryptedValue and 222 EnvelopedData for migration to EnvelopedData. For reasons of 223 completeness and consistency the type EncryptedValue has been 224 exchanged in all occurrences in RFC 4210 [RFC4210]. This includes 225 the protection of centrally generated private keys, encryption of 226 certificates, and protection of revocation passphrases. To 227 properly differentiate the support of EnvelopedData instead of 228 EncryptedValue, the CMP version 3 is introduced in case a 229 transaction is supposed to use EnvelopedData. 231 * Offering an optional hashAlg field in CertStatus supporting 232 confirmation of certificates signed with signature algorithms, 233 e.g., EdDSA, not directly indicating a specific hash algorithm to 234 use to compute the certHash. 236 * Adding new general message types to request CA certificates, a 237 root CA update, a certificate request template, or a CRL update. 239 * Extend the usage of polling to p10cr, certConf, rr, genm, and 240 error messages. 242 * Delete the mandatory algorithm profile in RFC 4210 Appendix D.2 243 [RFC4210] and refer to CMP Algorithms Section 7 244 [I-D.ietf-lamps-cmp-algorithms]. 246 2.2. New Section 4.5 - Extended Key Usage 248 The following subsection introduces a new extended key usage for CMP 249 servers authorized to centrally generate key pairs on behalf of end 250 entities. 252 Insert this section at the end of the current Section 4: 254 4.5. Extended Key Usage 256 The Extended Key Usage (EKU) extension indicates the purposes for 257 which the certified key pair may be used. It therefore restricts the 258 use of a certificate to specific applications. 260 A CA may want to delegate parts of its duties to other PKI management 261 entities. This section provides a mechanism to both prove this 262 delegation and enable an automated means for checking the 263 authorization of this delegation. Such delegation may also be 264 expressed by other means, e.g., explicit configuration. 266 To offer automatic validation for the delegation of a role by a CA to 267 another entity, the certificates used for CMP message protection or 268 signed data for central key generation MUST be issued by the 269 delegating CA and MUST contain the respective EKUs. This proves the 270 authorization of this entity by the delegating CA to act in the given 271 role as described below. 273 The OIDs to be used for these EKUs are: 275 id-kp-cmcCA OBJECT IDENTIFIER ::= { 276 iso(1) identified-organization(3) dod(6) internet(1) 277 security(5) mechanisms(5) pkix(7) kp(3) 27 } 279 id-kp-cmcRA OBJECT IDENTIFIER ::= { 280 iso(1) identified-organization(3) dod(6) internet(1) 281 security(5) mechanisms(5) pkix(7) kp(3) 28 } 283 id-kp-cmKGA OBJECT IDENTIFIER ::= { 284 iso(1) identified-organization(3) dod(6) internet(1) 285 security(5) mechanisms(5) pkix(7) kp(3) 32 } 287 Note: RFC 6402 section 2.10 [RFC6402] specifies OIDs for a CMC CA and 288 a CMC RA. As the functionality of a CA and RA is not specific to 289 using CMC or CMP as the certificate management protocol, these EKUs 290 are re-used by CMP. 292 The meaning of the id-kp-cmKGA EKU is as follows: 294 CMP KGA: CMP Key Generation Authorities are CAs or are identified by 295 the id-kp-cmKGA extended key usage. The CMP KGA knows the 296 private key it generated on behalf of the end entity. This 297 is a very sensitive service and needs specific 298 authorization, which by default is with the CA certificate 299 itself. The CA may delegate its authorization by placing 300 the id-kp-cmKGA extended key usage in the certificate used 301 to authenticate the origin of the generated private key. 302 The authorization may also be determined through local 303 configuration of the end entity. 305 2.3. Update Section 5.1.1. - PKI Message Header 307 Section 5.1.1 of RFC 4210 [RFC4210] describes the PKI message header. 308 This document introduces the new version 3 indicating support of 309 EnvelopedData as specified in Section 2.7. 311 Replace the ASN.1 Syntax of PKIHeader and the subsequent description 312 of pvno with the following text: 314 PKIHeader ::= SEQUENCE { 315 pvno INTEGER { cmp1999(1), cmp2000(2), 316 cmp2021(3) }, 317 sender GeneralName, 318 recipient GeneralName, 319 messageTime [0] GeneralizedTime OPTIONAL, 320 protectionAlg [1] AlgorithmIdentifier{ALGORITHM, {...}} 321 OPTIONAL, 322 senderKID [2] KeyIdentifier OPTIONAL, 323 recipKID [3] KeyIdentifier OPTIONAL, 324 transactionID [4] OCTET STRING OPTIONAL, 325 senderNonce [5] OCTET STRING OPTIONAL, 326 recipNonce [6] OCTET STRING OPTIONAL, 327 freeText [7] PKIFreeText OPTIONAL, 328 generalInfo [8] SEQUENCE SIZE (1..MAX) OF 329 InfoTypeAndValue OPTIONAL 330 } 332 PKIFreeText ::= SEQUENCE SIZE (1..MAX) OF UTF8String 334 The usage of pvno values is described in Section 7. 336 2.4. New Section 5.1.1.3. - CertProfile 338 Section 5.1.1 of RFC 4210 [RFC4210] defines the PKIHeader and id-it 339 OIDs to be used in the generalInfo field. This section introduces 340 id-it-certProfile. 342 Insert this section after Section 5.1.1.2: 344 5.1.1.3. CertProfile 346 This is used by the EE to indicate specific certificate profiles, 347 e.g., when requesting a new certificate or a certificate request 348 template, see Section 5.3.19.16. 350 id-it-certProfile OBJECT IDENTIFIER ::= {id-it 21} 351 CertProfileValue ::= SEQUENCE SIZE (1..MAX) OF UTF8String 353 When used in an ir/cr/kur/genm, the value MUST NOT contain more 354 elements than the number of CertReqMsg or InfoTypeAndValue elements 355 and the certificate profile names refer to the elements in the given 356 order. 358 When used in a p10cr, the value MUST NOT contain multiple certificate 359 profile names. 361 2.5. Update Section 5.1.3.1. - Shared Secret Information 363 Section 5.1.3.1 of RFC 4210 [RFC4210] describes the MAC based 364 protection of a PKIMessage using the algorithm id-PasswordBasedMac. 366 Replace the first paragraph with the following text: 368 In this case, the sender and recipient share secret information with 369 sufficient entropy (established via out-of-band means or from a 370 previous PKI management operation). PKIProtection will contain a MAC 371 value and the protectionAlg MAY be one of the options described in 372 CMP Algorithms [I-D.ietf-lamps-cmp-algorithms]. The PasswordBasedMac 373 is specified as follows (see also [RFC4211] and [RFC9045]): 375 Replace the last paragraph with the following text (Note: This fixes 376 Errata ID 2616): 378 Note: It is RECOMMENDED that the fields of PBMParameter remain 379 constant throughout the messages of a single transaction (e.g., 380 ir/ip/certConf/pkiConf) to reduce the overhead associated with 381 PasswordBasedMac computation. 383 2.6. Replace Section 5.1.3.4 - Multiple Protection 385 Section 5.1.3.4 of RFC 4210 [RFC4210] describes the nested message. 386 This document enables using nested messages also for batch-delivery 387 transport of PKI messages between PKI management entities and with 388 mixed body types. 390 Replace the text of the section with the following text: 392 5.1.3.4. Multiple Protection 394 When receiving a protected PKI message, a PKI management entity such 395 as an RA MAY forward that message adding its own protection (which is 396 a MAC or a signature, depending on the information and certificates 397 shared between the RA and the CA). Additionally, multiple PKI 398 messages MAY be aggregated. There are several use cases for such 399 messages. 401 * The RA confirms having validated and authorized a message and 402 forwards the original message unchanged. 404 * The RA modifies the message(s) in some way (e.g., adds or modifies 405 particular field values or adds new extensions) before forwarding 406 them, then it MAY create its own desired PKIBody. If the changes 407 made by the RA to PKIMessage break the POP of a certificate 408 request, the RA MUST set the popo field to RAVerified. It MAY 409 include the original PKIMessage from the EE in the generalInfo 410 field of PKIHeader of a nested message (to accommodate, for 411 example, cases in which the CA wishes to check POP or other 412 information on the original EE message). The infoType to be used 413 in this situation is {id-it 15} (see Section 5.3.19 for the value 414 of id-it) and the infoValue is PKIMessages (contents MUST be in 415 the same order as the message in PKIBody). 417 * A PKI management entity collects several messages that are to be 418 forwarded in the same direction and forwards them in a batch. 419 Request messages can be transferred as batch upstream (towards the 420 CA); response or announce messages can be transferred as batch 421 downstream (towards an RA, but not to the EE). This can for 422 instance be used when bridging an off-line connection between two 423 PKI management entities. 425 These use cases are accomplished by nesting the messages within a new 426 PKI message. The structure used is as follows: 428 NestedMessageContent ::= PKIMessages 430 2.7. Replace Section 5.2.2. - Encrypted Values 432 Section 5.2.2 of RFC 4210 [RFC4210] describes the use of 433 EncryptedValue to transport encrypted data. This document extends 434 the encryption of data to preferably use EnvelopedData. 436 Replace the text of the section with the following text: 438 5.2.2. Encrypted Values 440 Where encrypted data (in this specification, private keys, 441 certificates, or revocation passphrase) are sent in PKI messages, the 442 EncryptedKey data structure is used. 444 EncryptedKey ::= CHOICE { 445 encryptedValue EncryptedValue, -- deprecated 446 envelopedData [0] EnvelopedData } 448 See CRMF [RFC4211] for EncryptedKey and EncryptedValue syntax and CMS 449 [RFC5652] for EnvelopedData syntax. Using the EncryptedKey data 450 structure offers the choice to either use EncryptedValue (for 451 backward compatibility only) or EnvelopedData. The use of the 452 EncryptedValue structure has been deprecated in favor of the 453 EnvelopedData structure. Therefore, it is RECOMMENDED to use 454 EnvelopedData. 456 Note: The EncryptedKey structure defined in CRMF [RFC4211] is reused 457 here, which makes the update backward compatible. Using the new 458 syntax with the untagged default choice EncryptedValue is bits-on- 459 the-wire compatible with the old syntax. 461 To indicate support for EnvelopedData the pvno cmp2021 has been 462 introduced. Details on the usage of pvno values is described in 463 Section 7. 465 The EncryptedKey data structure is used in CMP to transport a private 466 key, certificate, or revocation passphrase in encrypted form. 468 EnvelopedData is used as follows: 470 * It contains only one RecipientInfo structure because the content 471 is encrypted only for one recipient. 473 * It may contain a private key in the AsymmetricKeyPackage structure 474 as defined in RFC 5958 [RFC5958] wrapped in a SignedData structure 475 as specified in CMS section 5 [RFC5652] and [RFC8933] signed by 476 the Key Generation Authority. 478 * It may contain a certificate or revocation passphrase directly in 479 the encryptedContent field. 481 The content of the EnvelopedData structure, as specified in CMS 482 section 6 [RFC5652], MUST be encrypted using a newly generated 483 symmetric content-encryption key. This content-encryption key MUST 484 be securely provided to the recipient using one of three key 485 management techniques. 487 The choice of the key management technique to be used by the sender 488 depends on the credential available at the recipient: 490 * Recipient's certificate that contains a key usage extension 491 asserting keyAgreement: The content-encryption key will be 492 protected using the key agreement key management technique, as 493 specified in CMS section 6.2.2 [RFC5652]. This is the preferred 494 technique. 496 * Recipient's certificate that contains a key usage extension 497 asserting keyEncipherment: The content-encryption key will be 498 protected using the key transport key management technique, as 499 specified in CMS section 6.2.1 [RFC5652]. 501 * A password or shared secret: The content-encryption key will be 502 protected using the password-based key management technique, as 503 specified in CMS section 6.2.4 [RFC5652]. 505 2.8. New Section 5.2.9 - GeneralizedTime 507 The following subsection point implementers to [RFC5280] regarding 508 usage of GeneralizedTime. 510 Insert this section after Section 5.2.8.4: 512 5.2.9 GeneralizedTime 514 GeneralizedTime is a standard ASN.1 type and SHALL be used as 515 specified in RFC 5280 Section 4.1.2.5.2 [RFC5280]. 517 2.9. Update Section 5.3.4. - Certification Response 519 Section 5.3.4 of RFC 4210 [RFC4210] describes the Certification 520 Response. This document updates the syntax by using the parent 521 structure EncryptedKey instead of EncryptedValue as described in 522 Section 2.7 above. Additionally, it clarifies the certReqId to be 523 used in response to a p10cr message. 525 Replace the ASN.1 syntax with the following text (Note: This also 526 fixes Errata ID 3949 and 4078): 528 CertRepMessage ::= SEQUENCE { 529 caPubs [1] SEQUENCE SIZE (1..MAX) OF CMPCertificate 530 OPTIONAL, 531 response SEQUENCE OF CertResponse 532 } 534 CertResponse ::= SEQUENCE { 535 certReqId INTEGER, 536 status PKIStatusInfo, 537 certifiedKeyPair CertifiedKeyPair OPTIONAL, 538 rspInfo OCTET STRING OPTIONAL 539 -- analogous to the id-regInfo-utf8Pairs string defined 540 -- for regInfo in CertReqMsg [RFC4211] 541 } 543 CertifiedKeyPair ::= SEQUENCE { 544 certOrEncCert CertOrEncCert, 545 privateKey [0] EncryptedKey OPTIONAL, 546 -- see [RFC4211] for comment on encoding 547 publicationInfo [1] PKIPublicationInfo OPTIONAL 548 } 550 CertOrEncCert ::= CHOICE { 551 certificate [0] CMPCertificate, 552 encryptedCert [1] EncryptedKey 553 } 555 Add the following as a new paragraph right after the ASN.1 syntax: 557 A p10cr message contains exactly one CertificationRequestInfo data 558 structure as specified in PKCS#10 [RFC2986] but no certReqId. 559 Therefore, the certReqId in the corresponding certification response 560 (cp) message MUST be set to -1. 562 Add the following as new paragraphs to the end of the section: 564 The use of EncryptedKey is described in Section 5.2.2. 566 Note: To indicate support for EnvelopedData the pvno cmp2021 has been 567 introduced. Details on the usage of different pvno values are 568 described in Section 7. 570 2.10. Update Section 5.3.18. - Certificate Confirmation Content 572 This section introduces an optional hashAlg field to the CertStatus 573 type used in certConf messages to explicitly specify the hash 574 algorithm for those certificates where no hash algorithm is specified 575 in the signatureAlgorithm field. 577 Replace the ASN.1 Syntax of CertStatus with the following text: 579 CertStatus ::= SEQUENCE { 580 certHash OCTET STRING, 581 certReqId INTEGER, 582 statusInfo PKIStatusInfo OPTIONAL, 583 hashAlg [0] AlgorithmIdentifier{DIGEST-ALGORITHM, {...}} 584 OPTIONAL 585 } 587 The hashAlg field SHOULD be used only in exceptional cases where the 588 signatureAlgorithm of the certificate to be confirmed does not 589 specify a hash algorithm in the OID or in the parameters. In such 590 cases, e.g., for EdDSA, the hashAlg MUST be used to specify the hash 591 algorithm to be used for calculating the certHash value. Otherwise, 592 the certHash value SHALL be computed using the same hash algorithm as 593 used to create and verify the certificate signature. If hashAlg is 594 used, the CMP version indicated by the certConf message header must 595 be cmp2021(3). 597 2.11. Update Section 5.3.19.2. - Signing Key Pair Types 599 The following section clarifies the usage of the Signing Key Pair 600 Types on referencing EC curves. 602 Insert this note at the end of Section 5.3.19.2: 604 Note: In case several EC curves are supported, several id-ecPublicKey 605 elements need to be given, one per named curve. 607 2.12. Update Section 5.3.19.3. - Encryption/Key Agreement Key Pair 608 Types 610 The following section clarifies the use of the Encryption/Key 611 Agreement Key Pair Types on referencing EC curves. 613 Insert this note at the end of Section 5.3.19.3: 615 Note: In case several EC curves are supported, several id-ecPublicKey 616 elements need to be given, one per named curve. 618 2.13. Replace Section 5.3.19.9. - Revocation Passphrase 620 Section 5.3.19.9 of RFC 4210 [RFC4210] describes the provisioning of 621 a revocation passphrase for authenticating a later revocation 622 request. This document updates the handling by using the parent 623 structure EncryptedKey instead of EncryptedValue to transport this 624 information as described in Section 2.7 above. 626 Replace the text of the section with the following text: 628 5.3.19.9. Revocation Passphrase 630 This MAY be used by the EE to send a passphrase to a CA/RA for the 631 purpose of authenticating a later revocation request (in the case 632 that the appropriate signing private key is no longer available to 633 authenticate the request). See Appendix B for further details on the 634 use of this mechanism. 636 GenMsg: {id-it 12}, EncryptedKey 637 GenRep: {id-it 12}, < absent > 639 The use of EncryptedKey is described in Section 5.2.2. 641 2.14. New Section 5.3.19.14 - CA Certificates 643 The following subsection describes PKI general messages using id-it- 644 caCerts. The intended use is specified in Lightweight CMP Profile 645 Section 4.3 [I-D.ietf-lamps-lightweight-cmp-profile]. 647 Insert this section after Section 5.3.19.13: 649 2.3.19.14 CA Certificates 651 This MAY be used by the client to get CA certificates. 653 GenMsg: {id-it 17}, < absent > 654 GenRep: {id-it 17}, SEQUENCE SIZE (1..MAX) OF 655 CMPCertificate | < absent > 657 2.15. New Section 5.3.19.15 - Root CA Certificate Update 659 The following subsection describes PKI general messages using id-it- 660 rootCaCert and id-it-rootCaKeyUpdate. The use is specified in 661 Lightweight CMP Profile Section 4.3 662 [I-D.ietf-lamps-lightweight-cmp-profile]. 664 Insert this section after new Section 5.3.19.14: 666 5.3.19.15. Root CA Certificate Update 668 This MAY be used by the client to get an update of a root CA 669 certificate, which is provided in the body of the request message. 670 In contrast to the ckuann message this approach follows the request/ 671 response model. 673 The EE SHOULD reference its current trust anchor in a TrustAnchor 674 structure in the request body, giving the root CA certificate if 675 available, otherwise the public key value of the trust anchor. 677 GenMsg: {id-it 20}, RootCaCertValue | < absent > 678 GenRep: {id-it 18}, RootCaKeyUpdateContent | < absent > 680 RootCaCertValue ::= CMPCertificate 682 RootCaKeyUpdateValue ::= RootCaKeyUpdateContent 684 RootCaKeyUpdateContent ::= SEQUENCE { 685 newWithNew CMPCertificate, 686 newWithOld [0] CMPCertificate OPTIONAL, 687 oldWithNew [1] CMPCertificate OPTIONAL 688 } 690 Note: In contrast to CAKeyUpdAnnContent, this type offers omitting 691 newWithOld and oldWithNew in the GenRep message, depending on the 692 needs of the EE. 694 2.16. New Section 5.3.19.16 - Certificate Request Template 696 The following subsection introduces the PKI general message using id- 697 it-certReqTemplate. Details are specified in the Lightweight CMP 698 Profile Section 4.3 [I-D.ietf-lamps-lightweight-cmp-profile]. 700 Insert this section after new Section 5.3.19.15: 702 5.3.19.16. Certificate Request Template 704 This MAY be used by the client to get a template containing 705 requirements for certificate request attributes and extensions. The 706 controls id-regCtrl-algId and id-regCtrl-rsaKeyLen MAY contain 707 details on the types of subject public keys the CA is willing to 708 certify. 710 The id-regCtrl-algId control MAY be used to identify a cryptographic 711 algorithm, see RFC 5280 Section 4.1.2.7 [RFC5280], other than 712 rsaEncryption. The algorithm field SHALL identify a cryptographic 713 algorithm. The contents of the optional parameters field will vary 714 according to the algorithm identified. For example, when the 715 algorithm is set to id-ecPublicKey, the parameters identify the 716 elliptic curve to be used, see [RFC5480]. 718 The id-regCtrl-rsaKeyLen control SHALL be used for algorithm 719 rsaEncryption and SHALL contain the intended modulus bit length of 720 the RSA key. 722 GenMsg: {id-it 19}, < absent > 723 GenRep: {id-it 19}, CertReqTemplateContent | < absent > 725 CertReqTemplateValue ::= CertReqTemplateContent 727 CertReqTemplateContent ::= SEQUENCE { 728 certTemplate CertTemplate, 729 keySpec Controls OPTIONAL } 731 Controls ::= SEQUENCE SIZE (1..MAX) OF AttributeTypeAndValue 733 id-regCtrl-algId OBJECT IDENTIFIER ::= { iso(1) 734 identified-organization(3) dod(6) internet(1) security(5) 735 mechanisms(5) pkix(7) pkip(5) regCtrl(1) 11 } 737 AlgIdCtrl ::= AlgorithmIdentifier{ALGORITHM, {...}} 739 id-regCtrl-rsaKeyLen OBJECT IDENTIFIER ::= { iso(1) 740 identified-organization(3) dod(6) internet(1) security(5) 741 mechanisms(5) pkix(7) pkip(5) regCtrl(1) 12 } 743 RsaKeyLenCtrl ::= INTEGER (1..MAX) 745 The CertReqTemplateValue contains the prefilled certTemplate to be 746 used for a future certificate request. The publicKey field in the 747 certTemplate MUST NOT be used. In case the PKI management entity 748 wishes to specify supported public-key algorithms, the keySpec field 749 MUST be used. One AttributeTypeAndValue per supported algorithm or 750 RSA key length MUST be used. 752 Note: The Controls ASN.1 type is defined in CRMF Section 6 [RFC4211] 754 2.17. New Section 5.3.19.17 - CRL Update Retrieval 756 The following subsection introduces the PKI general message using id- 757 it-crlStatusList and id-it-crls. Details are specified in the 758 Lightweight CMP Profile Section 4.3 759 [I-D.ietf-lamps-lightweight-cmp-profile]. Insert this section after 760 new Section 5.3.19.16: 762 5.3.19.17. CRL Update Retrieval 764 This MAY be used by the client to get new CRLs, specifying the source 765 of the CRLs and the thisUpdate value of the latest CRL it already 766 has, if available. A CRL source is given either by a 767 DistributionPointName or the GeneralNames of the issuing CA. The 768 DistributionPointName should be treated as an internal pointer to 769 identify a CRL that the server already has and not as a way to ask 770 the server to fetch CRLs from external locations. The server shall 771 provide only those CRLs that are more recent than the ones indicated 772 by the client. 774 GenMsg: {id-it 22}, SEQUENCE SIZE (1..MAX) OF CRLStatus 775 GenRep: {id-it 23}, SEQUENCE SIZE (1..MAX) OF 776 CertificateList | < absent > 778 CRLSource ::= CHOICE { 779 dpn [0] DistributionPointName, 780 issuer [1] GeneralNames } 782 CRLStatus ::= SEQUENCE { 783 source CRLSource, 784 thisUpdate Time OPTIONAL } 786 2.18. Update Section 5.3.21 - Error Message Content 788 Section 5.3.21 of RFC 4210 [RFC4210] describes the regular use of 789 error messages. This document adds a use by a PKI management entity 790 to initiate delayed delivery in response to certConf, rr, and genm 791 requests and to error messages. 793 Replace the first sentence of the first paragraph with the following 794 one: 796 This data structure MAY be used by EE, CA, or RA to convey error info 797 and by a PKI management entity to initiate delayed delivery of 798 responses. 800 Replace the second paragraph with the following text: 802 This message MAY be generated at any time during a PKI transaction. 803 If the client sends this request, the server MUST respond with a 804 PKIConfirm response, or another ErrorMsg if any part of the header is 805 not valid. In case a PKI management entity sends an error message to 806 the EE with the pKIStatusInfo field containing the status "waiting", 807 the EE will initiate polling as described in Section 5.3.22. 808 Otherwise, both sides MUST treat this message as the end of the 809 transaction (if a transaction is in progress). 811 2.19. Replace Section 5.3.22 - Polling Request and Response 813 Section 5.3.22 of RFC 4210 [RFC4210] describes when and how polling 814 messages are used for ir, cr, and kur messages. This document 815 extends the polling mechanism for outstanding responses to any kind 816 of request message. This update also fixes the inconsistent use of 817 the terms 'rReq' vs. 'pollReq' and 'pRep' vs. 'pollRep'. 819 Replace Section 5.3.22 with following text: 821 This pair of messages is intended to handle scenarios in which the 822 client needs to poll the server to determine the status of an 823 outstanding response (i.e., when the "waiting" PKIStatus has been 824 received). 826 PollReqContent ::= SEQUENCE OF SEQUENCE { 827 certReqId INTEGER } 829 PollRepContent ::= SEQUENCE OF SEQUENCE { 830 certReqId INTEGER, 831 checkAfter INTEGER, -- time in seconds 832 reason PKIFreeText OPTIONAL } 834 In response to an ir, cr, p10cr, or kur request message, polling is 835 initiated with an ip, cp, or kup response message containing status 836 "waiting". For any type of request message, polling can be initiated 837 with an error response messages with status "waiting". The following 838 clauses describe how polling messages are used. It is assumed that 839 multiple certConf messages can be sent during transactions. There 840 will be one sent in response to each ip, cp, or kup that contains a 841 CertStatus for an issued certificate. 843 1 In response to an ip, cp, or kup message, an EE will send a 844 certConf for all issued certificates and expect a PKIconf for each 845 certConf. An EE will send a pollReq message in response to each 846 CertResponse element of an ip, cp, or kup message with status 847 "waiting" and in response to an error message with status 848 "waiting". Its certReqId MUST be either the index of a 849 CertResponse data structure with status "waiting" or -1 referring 850 to the complete response. 852 2 In response to a pollReq, a CA/RA will return an ip, cp, or kup if 853 one or more of still pending requested certificates are ready or 854 the final response to some other type of request is available; 855 otherwise, it will return a pollRep. 857 3 If the EE receives a pollRep, it will wait for at least the number 858 of seconds given in the checkAfter field before sending another 859 pollReq. 861 4 If the EE receives an ip, cp, or kup, then it will be treated in 862 the same way as the initial response; if it receives any other 863 response, then this will be treated as the final response to the 864 original request. 866 The following client-side state machine describes polling for 867 individual CertResponse elements. 869 START 870 | 871 v 872 Send ir 873 | ip 874 v 875 Check status 876 of returned <------------------------+ 877 certs | 878 | | 879 +------------------------>|<------------------+ | 880 | | | | 881 | (issued) v (waiting) | | 882 Add to <----------- Check CertResponse ------> Add to | 883 conf list for each certificate pending list | 884 / | 885 / | 886 (conf list) / (empty conf list) | 887 / ip | 888 / +-----------------+ 889 (empty pending list) / | pollRep 890 END <---- Send certConf Send pollReq---------->Wait 891 | ^ ^ | 892 | | | | 893 +-----------------+ +---------------+ 894 (pending list) 896 In the following exchange, the end entity is enrolling for two 897 certificates in one request. 899 Step End Entity PKI 900 -------------------------------------------------------------------- 901 1 Format ir 902 2 -> ir -> 903 3 Handle ir 904 4 Manual intervention is 905 required for both certs. 906 5 <- ip <- 907 6 Process ip 908 7 Format pollReq 909 8 -> pollReq -> 910 9 Check status of cert requests 911 10 Certificates not ready 912 11 Format pollRep 913 12 <- pollRep <- 914 13 Wait 915 14 Format pollReq 916 15 -> pollReq -> 917 16 Check status of cert requests 918 17 One certificate is ready 919 18 Format ip 920 19 <- ip <- 921 20 Handle ip 922 21 Format certConf 923 22 -> certConf -> 924 23 Handle certConf 925 24 Format ack 926 25 <- pkiConf <- 927 26 Format pollReq 928 27 -> pollReq -> 929 28 Check status of certificate 930 29 Certificate is ready 931 30 Format ip 932 31 <- ip <- 933 31 Handle ip 934 32 Format certConf 935 33 -> certConf -> 936 34 Handle certConf 937 35 Format ack 938 36 <- pkiConf <- 940 The following client-side state machine describes polling for a 941 complete response message. 943 Start 944 | 945 | Send request 946 | 947 +----------- Receive response ------------+ 948 | | 949 | ip/cp/kup/error with | other 950 | status "waiting" | response 951 | | 952 v | 953 +------> Polling | 954 | | | 955 | | Send pollReq | 956 | | Receive response | 957 | | | 958 | pollRep | other response | 959 +-----------+------------------->+<-------------------+ 960 | 961 v 962 Handle response 963 | 964 v 965 End 967 In the following exchange, the end-entity is sending a general 968 message request, and the response is delayed by the server. 970 Step End Entity PKI 971 -------------------------------------------------------------------- 972 1 Format genm 973 2 -> genm -> 974 3 Handle genm 975 4 delay in response is necessary 976 5 Format error message "waiting" 977 with certReqId set to -1 978 6 <- error <- 979 7 Process error 980 8 Format pollReq 981 9 -> pollReq -> 982 10 Check status of original request 983 general message response not ready 984 11 Format pollRep 985 12 <- pollRep <- 986 13 Wait 987 14 Format pollReq 988 15 -> pollReq -> 989 16 Check status of original request 990 general message response is ready 991 17 Format genp 992 18 <- genp <- 993 19 Handle genp 995 2.20. Update Section 7 - Version Negotiation 997 Section 7 of RFC 4210 [RFC4210] describes the use of CMP protocol 998 versions. This document describes the handling of the additional CMP 999 version cmp2021 introduced to indicate support of EnvelopedData and 1000 hashAlg. 1002 Replace the text of the second paragraph with the following text: 1004 If a client knows the protocol version(s) supported by the server 1005 (e.g., from a previous PKIMessage exchange or via some out-of-band 1006 means), then it MUST send a PKIMessage with the highest version 1007 supported by both it and the server. If a client does not know what 1008 version(s) the server supports, then it MUST send a PKIMessage using 1009 the highest version it supports, with the following exception. 1010 Version cmp2021 SHOULD only be used if cmp2021 syntax is needed for 1011 the request being sent or for the expected response. 1013 Note: Using cmp2000 as the default pvno is done to avoid extra 1014 message exchanges for version negotiation and to foster compatibility 1015 with cmp2000 implementations. Version cmp2021 syntax is only needed 1016 if a message exchange uses hashAlg (in CertStatus) or EnvelopedData. 1018 2.21. Update Section 7.1.1. - Clients Talking to RFC 2510 Servers 1020 Section 7.1.1 of RFC 4210 [RFC4210] describes the behavior of a 1021 client sending a cmp2000 message talking to a cmp1999 server. This 1022 document extends the section to clients with any higher version than 1023 cmp1999. 1025 Replace the first sentence of Section 7.1.1 with the following text: 1027 If, after sending a message with a protocol version number higher 1028 than cmp1999, a client receives an ErrorMsgContent with a version of 1029 cmp1999, then it MUST abort the current transaction. 1031 2.22. Add Section 8.4 - Private Keys for Certificate Signing and CMP 1032 Message Protection 1034 The following subsection addresses the risk arising from reusing the 1035 CA private key for CMP message protection. 1037 Insert this section after Section 8.3 (Note: This fixes Errata ID 1038 5731): 1040 8.4. Private Keys for Certificate Signing and CMP Message Protection 1042 A CA should not reuse its certificate signing key for other purposes 1043 such as protecting CMP responses and TLS connections. This way, 1044 exposure to other parts of the system and the number of uses of this 1045 particularly critical key is reduced to a minimum. 1047 2.23. Add Section 8.5 - Entropy of Random Numbers, Key Pairs, and 1048 Shared Secret Information 1050 The following subsection addresses the risk arising from low entropy 1051 of random numbers, asymmetric keys, and shared secret information. 1053 Insert this section after Section 8.4: 1055 8.5. Entropy of Random Numbers, Key Pairs, and Shared Secret 1056 Information 1058 Implementations must generate nonces and private keys from random 1059 input. The use of inadequate pseudo-random number generators (PRNGs) 1060 to generate cryptographic keys can result in little or no security. 1061 An attacker may find it much easier to reproduce the PRNG environment 1062 that produced the keys and to search the resulting small set of 1063 possibilities than brute-force searching the whole key space. As an 1064 example of predictable random numbers see [CVE-2008-0166]; 1065 consequences of low-entropy random numbers are discussed in Mining 1066 Your Ps and Qs [MiningPsQs]. The generation of quality random 1067 numbers is difficult. ISO/IEC 20543:2019 [ISO.20543-2019], NIST SP 1068 800-90A Rev.1 [NIST.SP.800-90Ar1], BSI AIS 31 V2.0 [AIS31], and 1069 others offer valuable guidance in this area. 1071 If shared secret information is generated by a cryptographically 1072 secure random-number generator (CSRNG) it is safe to assume that the 1073 entropy of the shared secret information equals its bit length. If 1074 no CSRNG is used, the entropy of a shared secret information depends 1075 on the details of the generation process and cannot be measured 1076 securely after it has been generated. If user-generated passwords 1077 are used as shared secret information, their entropy cannot be 1078 measured and are typically insufficient for protected delivery of 1079 centrally generated keys or trust anchors. 1081 If the entropy of a shared secret information protecting the delivery 1082 of a centrally generated key pair is known, it should not be less 1083 than the security strength of that key pair; if the shared secret 1084 information is re-used for different key pairs, the security of the 1085 shared secret information should exceed the security strength of each 1086 individual key pair. 1088 For the case of a PKI management operation that delivers a new trust 1089 anchor (e.g., a root CA certificate) using caPubs or genm (a) that is 1090 not concluded in a timely manner or (b) where the shared secret 1091 information is re-used for several key management operations, the 1092 entropy of the shared secret information, if known, should not be 1093 less than the security strength of the trust anchor being managed by 1094 the operation. The shared secret information should have an entropy 1095 that at least matches the security strength of the key material being 1096 managed by the operation. Certain use cases may require shared 1097 secret information that may be of a low security strength, e.g., a 1098 human generated password. It is RECOMMENDED that such secret 1099 information be limited to a single PKI management operation. 1101 2.24. Add Section 8.6 - Trust Anchor Provisioning Using CMP Messages 1103 The following subsection addresses the risk arising from in-band 1104 provisioning of new trust anchors in a PKI management operation. 1106 Insert this section after new Section 8.5: 1108 8.6. Trust Anchor Provisioning Using CMP Messages 1109 A provider of trust anchors, which may be an RA involved in 1110 configuration management of its clients, MUST NOT include to-be- 1111 trusted CA certificates in a CMP message unless the specific 1112 deployment scenario can ensure that it is adequate that the receiving 1113 EE trusts these certificates, e.g., by loading them into its trust 1114 store. 1116 Whenever an EE receives in a CMP message, e.g., in the caPubs field 1117 of a certificate response or in a general response (genp), a CA 1118 certificate for use as a trust anchor, it MUST properly authenticate 1119 the message sender with existing trust anchors without requiring new 1120 trust anchors included in the message. 1122 Additionally, the EE MUST verify that the sender is an authorized 1123 source of trust anchors. This authorization is governed by local 1124 policy and typically indicated using shared secret information or 1125 with a signature-based message protection using a certificate issued 1126 by a PKI that is explicitly authorized for this purpose. 1128 2.25. Update Section 9 - IANA Considerations 1130 Section 9 of RFC 4210 [RFC4210] contains the IANA Considerations of 1131 that document. As this document defines a new Extended Key Usage, 1132 the IANA Considerations need to be updated accordingly. 1134 Replace the fourth paragraph of this section with the following text: 1136 In the SMI-numbers registry "SMI Security for PKIX Extended Key 1137 Purpose Identifiers (1.3.6.1.5.5.7.3)" (see 1138 https://www.iana.org/assignments/smi-numbers/smi-numbers.xhtml#smi- 1139 numbers-1.3.6.1.5.5.7.3) as defined in RFC 7299 [RFC7299] one 1140 addition has been performed. 1142 One new entry has been added: 1144 +=========+=============+============+ 1145 | Decimal | Description | References | 1146 +=========+=============+============+ 1147 | 32 | id-kp-cmKGA | [RFCXXXX] | 1148 +---------+-------------+------------+ 1150 Table 1: Addition to the PKIX 1151 Extended Key Purpose Identifiers 1152 Registry 1154 In the SMI-numbers registry "SMI Security for PKIX CMP Information 1155 Types (1.3.6.1.5.5.7.4)" (see https://www.iana.org/assignments/smi- 1156 numbers/smi-numbers.xhtml#smi-numbers-1.3.6.1.5.5.7.4) as defined in 1157 RFC 7299 [RFC7299] seven additions have been performed. 1159 Seven new entries have been added: 1161 +=========+=======================+============+ 1162 | Decimal | Description | References | 1163 +=========+=======================+============+ 1164 | 17 | id-it-caCerts | [RFCXXXX] | 1165 +---------+-----------------------+------------+ 1166 | 18 | id-it-rootCaKeyUpdate | [RFCXXXX] | 1167 +---------+-----------------------+------------+ 1168 | 19 | id-it-certReqTemplate | [RFCXXXX] | 1169 +---------+-----------------------+------------+ 1170 | 20 | id-it-rootCaCert | [RFCXXXX] | 1171 +---------+-----------------------+------------+ 1172 | 21 | id-it-certProfile | [RFCXXXX] | 1173 +---------+-----------------------+------------+ 1174 | 22 | id-it-crlStatusList | [RFCXXXX] | 1175 +---------+-----------------------+------------+ 1176 | 23 | id-it-crls | [RFCXXXX] | 1177 +---------+-----------------------+------------+ 1179 Table 2: Addition to the PKIX CMP 1180 Information Types Registry 1182 In the SMI-numbers registry "SMI Security for PKIX CRMF Registration 1183 Controls (1.3.6.1.5.5.7.5.1)" (see https://www.iana.org/assignments/ 1184 smi-numbers/smi-numbers.xhtml#smi-numbers-1.3.6.1.5.5.7.5.1) as 1185 defined in RFC 7299 [RFC7299] two additions have been performed. 1187 Two new entries have been added: 1189 +=========+======================+============+ 1190 | Decimal | Description | References | 1191 +=========+======================+============+ 1192 | 11 | id-regCtrl-algId | [RFCXXXX] | 1193 +---------+----------------------+------------+ 1194 | 12 | id-regCtrl-rsaKeyLen | [RFCXXXX] | 1195 +---------+----------------------+------------+ 1197 Table 3: Addition to the PKIX CRMF 1198 Registration Controls Registry 1200 2.26. Update Appendix B - The Use of Revocation Passphrase 1202 Appendix B of RFC 4210 [RFC4210] describes the use of the revocation 1203 passphrase. As this document updates RFC 4210 [RFC4210] to utilize 1204 the parent structure EncryptedKey instead of EncryptedValue as 1205 described in Section 2.7 above, the description is updated 1206 accordingly. 1208 Replace the first bullet point of this section with the following 1209 text: 1211 * The OID and value specified in Section 5.3.19.9 MAY be sent in a 1212 GenMsg message at any time, or MAY be sent in the generalInfo 1213 field of the PKIHeader of any PKIMessage at any time. (In 1214 particular, the EncryptedKey structure as described in 1215 Section 5.2.2 may be sent in the header of the certConf message 1216 that confirms acceptance of certificates requested in an 1217 initialization request or certificate request message.) This 1218 conveys a revocation passphrase chosen by the entity to the 1219 relevant CA/RA. When EnvelopedData is used, this is in the 1220 decrypted bytes of encryptedContent field. When EncryptedValue is 1221 used, this is in the decrypted bytes of the encValue field. 1222 Furthermore, the transfer is accomplished with appropriate 1223 confidentiality characteristics. 1225 Replace the third bullet point of this section with the following 1226 text: 1228 * Either the localKeyId attribute of EnvelopedData as specified in 1229 RFC 2985 [RFC2985] or the valueHint field of EncryptedValue MAY 1230 contain a key identifier (chosen by the entity, along with the 1231 passphrase itself) to assist in later retrieval of the correct 1232 passphrase (e.g., when the revocation request is constructed by 1233 the entity and received by the CA/RA). 1235 2.27. Update Appendix C - Request Message Behavioral Clarifications 1237 Appendix C of RFC 4210 [RFC4210] provides clarifications to the 1238 request message behavior. As this document updates RFC 4210 1239 [RFC4210] to utilize the parent structure EncryptedKey instead of 1240 EncryptedValue as described in Section 2.7 above, the description is 1241 updated accordingly. 1243 Replace the comment within the ASN.1 syntax coming after the 1244 definition of POPOSigningKey with the following text (Note: This 1245 fixes Errata ID 2615): 1247 -- ********** 1248 -- * For the purposes of this specification, the ASN.1 comment 1249 -- * given in [RFC4211] pertains not only to certTemplate, but 1250 -- * also to the altCertTemplate control. 1251 -- ********** 1252 -- * The signature (using "algorithmIdentifier") is on the 1253 -- * DER-encoded value of poposkInput (i.e., the "value" OCTETs 1254 -- * of the POPOSigningKeyInput DER). NOTE: If CertReqMsg 1255 -- * certReq certTemplate (or the altCertTemplate control) 1256 -- * contains the subject and publicKey values, then poposkInput 1257 -- * MUST be omitted and the signature MUST be computed on the 1258 -- * DER-encoded value of CertReqMsg certReq (or the DER- 1259 -- * encoded value of AltCertTemplate). If 1260 -- * certTemplate/altCertTemplate does not contain both the 1261 -- * subject and public key values (i.e., if it contains only 1262 -- * one of these, or neither), then poposkInput MUST be present 1263 -- * and MUST be signed. 1264 -- ********** 1266 Replace the comment within the ASN.1 syntax coming after the 1267 definition of POPOPrivKey with the following text: 1269 -- ********** 1270 -- * the type of "thisMessage" is given as BIT STRING in RFC 4211 1271 -- * [RFC4211]; it should be "EncryptedKey" (in accordance with 1272 -- * Section 5.2.2 of this specification). Therefore, this 1273 -- * document makes the behavioral clarification of specifying 1274 -- * that the contents of "thisMessage" MUST be encoded either as 1275 -- * "EnvelopedData" or "EncryptedValue" (only for backward 1276 -- * compatibility) and then wrapped in a BIT STRING. This 1277 -- * allows the necessary conveyance and protection of the 1278 -- * private key while maintaining bits-on-the-wire compatibility 1279 -- * with RFC4210 and [RFCXXXX]. 1280 -- ********** 1282 2.28. Update Appendix D.1. - General Rules for Interpretation of These 1283 Profiles 1285 Appendix D.1 of RFC 4210 [RFC4210] provides general rules for 1286 interpretation of the PKI management messages profiles specified in 1287 Appendix D and Appendix E of RFC 4210 [RFC4210]. This document 1288 updates a sentence regarding the new protocol version cmp2021. 1290 Replace the last sentence of the first paragraph of the section with 1291 the following text: 1293 Mandatory fields are not mentioned if they have an obvious value 1294 (e.g., in this version of these profiles, pvno is always cmp2000). 1296 2.29. Update Appendix D.2. - Algorithm Use Profile 1298 Appendix D.2 of RFC 4210 [RFC4210] provides a list of algorithms that 1299 implementations must support when claiming conformance with PKI 1300 Management Message Profiles as specified in CMP Appendix D.2 1301 [RFC4210]. This document redirects to the new algorithm profile as 1302 specified in Appendix A.1 of CMP Algorithms 1303 [I-D.ietf-lamps-cmp-algorithms]. 1305 Replace the text of the section with the following text: 1307 D.2. Algorithm Use Profile 1309 For specifications of algorithm identifiers and respective 1310 conventions for conforming implementations, please refer to CMP 1311 Algorithms Appendix A.1 [I-D.ietf-lamps-cmp-algorithms]. 1313 2.30. Update Appendix D.4. - Initial Registration/Certification (Basic 1314 Authenticated Scheme) 1316 Appendix D.4 of RFC 4210 [RFC4210] provides the initial registration/ 1317 certification scheme. This scheme shall continue using 1318 EncryptedValue for backward compatibility reasons. 1320 Replace the line specifying protectionAlg of the Initialization 1321 Response message with the following text (Note: This fixes Errata ID 1322 5201): 1324 protectionAlg MSG_MAC_ALG 1326 Replace the comment after the privateKey field of 1327 crc[1].certifiedKeyPair in the syntax of the Initialization Response 1328 message with the following text: 1330 -- see Appendix C, Request Message Behavioral Clarifications 1331 -- for backward compatibility reasons, use EncryptedValue 1333 3. Updates to RFC 6712 - HTTP Transfer for the Certificate Management 1334 Protocol (CMP) 1336 3.1. Update Section 1. - Introduction 1338 To indicate and explain why delayed delivery of all kinds of 1339 PKIMessages may be handled at transfer level and/or at CMP level, the 1340 introduction of RFC 6712 [RFC6712] is updated. 1342 Replace the third paragraph of this section with the following text: 1344 In addition to reliable transport, CMP requires connection and error 1345 handling from the transfer protocol, which is all covered by HTTP. 1346 Additionally, delayed delivery of CMP response messages may be 1347 handled at transfer level regardless of the message contents. Since 1348 this document extends the polling mechanism specified in the second 1349 version of CMP [RFC4210] to cover all types of PKI management 1350 transactions, delays detected at application level may also be 1351 handled within CMP, using pollReq and pollRep messages. 1353 3.2. New Section 1.1. - Changes Since RFC 6712 1355 The following subsection describes feature updates to RFC 6712 1356 [RFC6712]. They are related to the base specification. Hence, 1357 references to the original sections in RFC 6712 [RFC6712] are used 1358 whenever possible. 1360 Insert this section at the end of the current Section 1: 1362 1.1 Changes Since RFC 6712 1364 The following updates are made in this document: 1366 * Introduce the HTTP path '/.well-known/cmp'. 1368 * Extend the URI structure. 1370 3.3. Replace Section 3.6. - HTTP Request-URI 1372 Section 3.6 of RFC 6712 [RFC6712] specifies the used HTTP URIs. This 1373 document introduces the HTTP path '/.well-known/cmp' and extends the 1374 URIs. 1376 Replace the text of the section with the following text: 1378 3.6. HTTP Request-URI 1380 Each CMP server on a PKI management entity supporting HTTP or HTTPS 1381 transfer MUST support the use of the path prefix '/.well-known/' as 1382 defined in RFC 8615 [RFC8615] and the registered name 'cmp' to ease 1383 interworking in a multi-vendor environment. 1385 The CMP client needs to be configured with sufficient information to 1386 form the CMP server URI. This is at least the authority portion of 1387 the URI, e.g., 'www.example.com:80', or the full operation path 1388 segment of the PKI management entity. Additionally, OPTIONAL path 1389 segments MAY be added after the registered application name as part 1390 of the full operation path to provide further distinction. The path 1391 segment 'p' followed by an arbitraryLabel could for example 1392 support the differentiation of specific CAs or certificate profiles. 1393 Further path segments, e.g., as specified in the Lightweight CMP 1394 Profile [I-D.ietf-lamps-lightweight-cmp-profile], could indicate PKI 1395 management operations using an operationLabel . A valid 1396 full CMP URI can look like this: 1398 http://www.example.com/.well-known/cmp 1399 http://www.example.com/.well-known/cmp/ 1400 http://www.example.com/.well-known/cmp/p/ 1401 http://www.example.com/.well-known/cmp/p// 1403 3.4. Update Section 6. - IANA Considerations 1405 Section 6 of RFC 6712 [RFC6712] contains the IANA Considerations of 1406 that document. As this document defines a new well-known URI suffix, 1407 the IANA Considerations need to be updated accordingly. 1409 Replace the second paragraph of this section with the following text: 1411 6.1. Well-Known URI Registration 1413 This document defines a new entry with the following content in the 1414 "Well-Known URIs" registry (see https://www.iana.org/assignments/ 1415 well-known-uris/) as defined in RFC 8615 [RFC8615]. 1417 URI Suffix: cmp 1418 Change Controller: IETF 1419 References: [RFCXXXX] [I-D.ietf-ace-cmpv2-coap-transport] 1420 Related Information: CMP has a sub-registry at 1421 [https://www.iana.org/assignments/cmp/] 1423 6.2. CMP Well-Known URI Registry 1425 This document defines a new protocol registry group entitled 1426 "Certificate Management Protocol (CMP)" (at 1427 https://www.iana.org/assignments/cmp/) with a new registry "CMP Well- 1428 Known URI Path Segments" containing three columns: Path Segment, 1429 Description, and Reference. New items can be added using the 1430 Specification Required RFC 8615 [RFC8615] process. The initial 1431 contents of this registry is: 1433 Path Segment: p 1434 Description: Indicates that the next path segment specifies, e.g., 1435 a CA or certificate profile name 1436 References: [RFCXXXX] [I-D.ietf-ace-cmpv2-coap-transport] 1438 4. IANA Considerations 1440 This document updates the ASN.1 modules of RFC 4210 Appendix F 1441 [RFC4210] and RFC 5912 Section 9 [RFC5912]. The OIDs 99 (id-mod- 1442 cmp2021-88) and 100 (id-mod-cmp2021-02) were registered in the SMI 1443 Security for PKIX Module Identifier registry to identify the updated 1444 ASN.1 modules. 1446 This document contains an update to the IANA Consideration sections 1447 of [RFC4210] adding this content. 1449 In the SMI-numbers registry "SMI Security for PKIX Extended Key 1450 Purpose Identifiers (1.3.6.1.5.5.7.3)" (see 1451 https://www.iana.org/assignments/smi-numbers/smi-numbers.xhtml#smi- 1452 numbers-1.3.6.1.5.5.7.3) as defined in RFC 7299 [RFC7299] one 1453 addition has been performed. 1455 One new entry has been added: 1457 +=========+=============+============+ 1458 | Decimal | Description | References | 1459 +=========+=============+============+ 1460 | 32 | id-kp-cmKGA | [RFCXXXX] | 1461 +---------+-------------+------------+ 1463 Table 4: Addition to the PKIX 1464 Extended Key Purpose Identifiers 1465 Registry 1467 In the SMI-numbers registry "SMI Security for PKIX CMP Information 1468 Types (1.3.6.1.5.5.7.4)" (see https://www.iana.org/assignments/smi- 1469 numbers/smi-numbers.xhtml#smi-numbers-1.3.6.1.5.5.7.4) as defined in 1470 RFC 7299 [RFC7299] seven additions have been performed. 1472 Seven new entries have been added: 1474 +=========+=======================+============+ 1475 | Decimal | Description | References | 1476 +=========+=======================+============+ 1477 | 17 | id-it-caCerts | [RFCXXXX] | 1478 +---------+-----------------------+------------+ 1479 | 18 | id-it-rootCaKeyUpdate | [RFCXXXX] | 1480 +---------+-----------------------+------------+ 1481 | 19 | id-it-certReqTemplate | [RFCXXXX] | 1482 +---------+-----------------------+------------+ 1483 | 20 | id-it-rootCaCert | [RFCXXXX] | 1484 +---------+-----------------------+------------+ 1485 | 21 | id-it-certProfile | [RFCXXXX] | 1486 +---------+-----------------------+------------+ 1487 | 22 | id-it-crlStatusList | [RFCXXXX] | 1488 +---------+-----------------------+------------+ 1489 | 23 | id-it-crls | [RFCXXXX] | 1490 +---------+-----------------------+------------+ 1492 Table 5: Addition to the PKIX CMP 1493 Information Types Registry 1495 In the SMI-numbers registry "SMI Security for PKIX CRMF Registration 1496 Controls (1.3.6.1.5.5.7.5.1)" (see https://www.iana.org/assignments/ 1497 smi-numbers/smi-numbers.xhtml#smi-numbers-1.3.6.1.5.5.7.5.1) as 1498 defined in RFC 7299 [RFC7299] two additions have been performed. 1500 Two new entries have been added: 1502 +=========+======================+============+ 1503 | Decimal | Description | References | 1504 +=========+======================+============+ 1505 | 11 | id-regCtrl-algId | [RFCXXXX] | 1506 +---------+----------------------+------------+ 1507 | 12 | id-regCtrl-rsaKeyLen | [RFCXXXX] | 1508 +---------+----------------------+------------+ 1510 Table 6: Addition to the PKIX CRMF 1511 Registration Controls Registry 1513 This document contains an update to the IANA Consideration sections 1514 of [RFC6712] adding this content. 1516 This document defines a new entry with the following content in the 1517 "Well-Known URIs" registry (see https://www.iana.org/assignments/ 1518 well-known-uris/) as defined in RFC 8615 [RFC8615]. 1520 URI Suffix: cmp 1521 Change Controller: IETF 1522 References: [RFCXXXX] [I-D.ietf-ace-cmpv2-coap-transport] 1523 Related Information: CMP has a sub-registry at 1524 [https://www.iana.org/assignments/cmp/] 1526 This document defines a new protocol registry group entitled 1527 "Certificate Management Protocol (CMP)" (at 1528 https://www.iana.org/assignments/cmp/) with a new registry "CMP Well- 1529 Known URI Path Segments" containing three columns: Path Segment, 1530 Description, and Reference. New items can be added using the 1531 Specification Required RFC 8615 [RFC8615] process. The initial 1532 contents of this registry is: 1534 Path Segment: p 1535 Description: Indicates that the next path segment specifies, e.g., 1536 a CA or certificate profile name 1537 References: [RFCXXXX] [I-D.ietf-ace-cmpv2-coap-transport] 1539 5. Security Considerations 1541 The security considerations of RFC 4210 [RFC4210] are extended in 1542 Section 2.22 to Section 2.24. No security considerations updates of 1543 RFC 6712 [RFC6712] were required. 1545 6. Acknowledgements 1547 Special thank goes to Jim Schaad for his guidance and the inspiration 1548 on structuring and writing this document we got from [RFC6402] which 1549 updates CMC. Special thank also goes to Russ Housley, Lijun Liao, 1550 Martin Peylo, and Tomas Gustavsson for reviewing and providing 1551 valuable suggestions on improving this document. 1553 We also thank all reviewers of this document for their valuable 1554 feedback. 1556 7. References 1558 7.1. Normative References 1560 [I-D.ietf-ace-cmpv2-coap-transport] 1561 Sahni, M. and S. Tripathi, "CoAP Transfer for the 1562 Certificate Management Protocol", Work in Progress, 1563 Internet-Draft, draft-ietf-ace-cmpv2-coap-transport-04, 8 1564 November 2021, . 1567 [I-D.ietf-lamps-cmp-algorithms] 1568 Brockhaus, H., Aschauer, H., Ounsworth, M., and J. Gray, 1569 "Certificate Management Protocol (CMP) Algorithms", Work 1570 in Progress, Internet-Draft, draft-ietf-lamps-cmp- 1571 algorithms-15, 2 June 2022, 1572 . 1575 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 1576 Requirement Levels", BCP 14, RFC 2119, 1577 DOI 10.17487/RFC2119, March 1997, 1578 . 1580 [RFC2510] Adams, C. and S. Farrell, "Internet X.509 Public Key 1581 Infrastructure Certificate Management Protocols", 1582 RFC 2510, DOI 10.17487/RFC2510, March 1999, 1583 . 1585 [RFC2985] Nystrom, M. and B. Kaliski, "PKCS #9: Selected Object 1586 Classes and Attribute Types Version 2.0", RFC 2985, 1587 DOI 10.17487/RFC2985, November 2000, 1588 . 1590 [RFC2986] Nystrom, M. and B. Kaliski, "PKCS #10: Certification 1591 Request Syntax Specification Version 1.7", RFC 2986, 1592 DOI 10.17487/RFC2986, November 2000, 1593 . 1595 [RFC3629] Yergeau, F., "UTF-8, a transformation format of ISO 1596 10646", STD 63, RFC 3629, DOI 10.17487/RFC3629, November 1597 2003, . 1599 [RFC4210] Adams, C., Farrell, S., Kause, T., and T. Mononen, 1600 "Internet X.509 Public Key Infrastructure Certificate 1601 Management Protocol (CMP)", RFC 4210, 1602 DOI 10.17487/RFC4210, September 2005, 1603 . 1605 [RFC4211] Schaad, J., "Internet X.509 Public Key Infrastructure 1606 Certificate Request Message Format (CRMF)", RFC 4211, 1607 DOI 10.17487/RFC4211, September 2005, 1608 . 1610 [RFC5280] Cooper, D., Santesson, S., Farrell, S., Boeyen, S., 1611 Housley, R., and W. Polk, "Internet X.509 Public Key 1612 Infrastructure Certificate and Certificate Revocation List 1613 (CRL) Profile", RFC 5280, DOI 10.17487/RFC5280, May 2008, 1614 . 1616 [RFC5480] Turner, S., Brown, D., Yiu, K., Housley, R., and T. Polk, 1617 "Elliptic Curve Cryptography Subject Public Key 1618 Information", RFC 5480, DOI 10.17487/RFC5480, March 2009, 1619 . 1621 [RFC5652] Housley, R., "Cryptographic Message Syntax (CMS)", STD 70, 1622 RFC 5652, DOI 10.17487/RFC5652, September 2009, 1623 . 1625 [RFC5958] Turner, S., "Asymmetric Key Packages", RFC 5958, 1626 DOI 10.17487/RFC5958, August 2010, 1627 . 1629 [RFC6402] Schaad, J., "Certificate Management over CMS (CMC) 1630 Updates", RFC 6402, DOI 10.17487/RFC6402, November 2011, 1631 . 1633 [RFC6712] Kause, T. and M. Peylo, "Internet X.509 Public Key 1634 Infrastructure -- HTTP Transfer for the Certificate 1635 Management Protocol (CMP)", RFC 6712, 1636 DOI 10.17487/RFC6712, September 2012, 1637 . 1639 [RFC8174] Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC 1640 2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174, 1641 May 2017, . 1643 [RFC8615] Nottingham, M., "Well-Known Uniform Resource Identifiers 1644 (URIs)", RFC 8615, DOI 10.17487/RFC8615, May 2019, 1645 . 1647 [RFC8933] Housley, R., "Update to the Cryptographic Message Syntax 1648 (CMS) for Algorithm Identifier Protection", RFC 8933, 1649 DOI 10.17487/RFC8933, October 2020, 1650 . 1652 [RFC9045] Housley, R., "Algorithm Requirements Update to the 1653 Internet X.509 Public Key Infrastructure Certificate 1654 Request Message Format (CRMF)", RFC 9045, 1655 DOI 10.17487/RFC9045, June 2021, 1656 . 1658 7.2. Informative References 1660 [AIS31] Bundesamt fuer Sicherheit in der Informationstechnik 1661 (BSI), Killmann, W., and W. Schindler, "A proposal for: 1662 Functionality classes for random number generators, 1663 version 2.0", 18 September 2011, 1664 . 1668 [CVE-2008-0166] 1669 National Institute of Science and Technology (NIST), 1670 "National Vulnerability Database - CVE-2008-0166", 13 May 1671 2008, . 1673 [I-D.ietf-lamps-lightweight-cmp-profile] 1674 Brockhaus, H., Oheimb, D. V., and S. Fries, "Lightweight 1675 Certificate Management Protocol (CMP) Profile", Work in 1676 Progress, Internet-Draft, draft-ietf-lamps-lightweight- 1677 cmp-profile-12, 13 May 2022, 1678 . 1681 [IEEE.802.1AR_2018] 1682 IEEE, "IEEE Standard for Local and metropolitan area 1683 networks - Secure Device Identity", IEEE 802.1AR-2018, 1684 DOI 10.1109/IEEESTD.2018.8423794, 2 August 2018, 1685 . 1687 [ISO.20543-2019] 1688 International Organization for Standardization (ISO), 1689 "Information technology -- Security techniques -- Test and 1690 analysis methods for random bit generators within ISO/IEC 1691 19790 and ISO/IEC 15408", ISO Draft Standard 20543-2019, 1692 October 2019. 1694 [MiningPsQs] 1695 Security'12: Proceedings of the 21st USENIX conference on 1696 Security symposium, Heninger, N., Durumeric, Z., Wustrow, 1697 E., and J. A. Halderman, "Mining Your Ps and Qs: Detection 1698 of Widespread Weak Keys in Network Devices", August 2012, 1699 . 1702 [NIST.SP.800-90Ar1] 1703 Barker, Elaine B. and John M. Kelsey, "Recommendation for 1704 Random Number Generation Using Deterministic Random Bit 1705 Generators", NIST NIST SP 800-90Ar1, 1706 DOI 10.6028/NIST.SP.800-90Ar1, June 2015, 1707 . 1710 [PKCS11] RSA Laboratories, "The Public-Key Cryptography Standards - 1711 Cryptographic Token Interface Standard. Version 2.10", 1712 December 1999, 1713 . 1716 [RFC2104] Krawczyk, H., Bellare, M., and R. Canetti, "HMAC: Keyed- 1717 Hashing for Message Authentication", RFC 2104, 1718 DOI 10.17487/RFC2104, February 1997, 1719 . 1721 [RFC2202] Cheng, P. and R. Glenn, "Test Cases for HMAC-MD5 and HMAC- 1722 SHA-1", RFC 2202, DOI 10.17487/RFC2202, September 1997, 1723 . 1725 [RFC5912] Hoffman, P. and J. Schaad, "New ASN.1 Modules for the 1726 Public Key Infrastructure Using X.509 (PKIX)", RFC 5912, 1727 DOI 10.17487/RFC5912, June 2010, 1728 . 1730 [RFC7299] Housley, R., "Object Identifier Registry for the PKIX 1731 Working Group", RFC 7299, DOI 10.17487/RFC7299, July 2014, 1732 . 1734 Appendix A. ASN.1 Modules 1736 A.1. Update to RFC4210 - 1988 ASN.1 Module 1738 This section contains the updated ASN.1 module for [RFC4210]. This 1739 module replaces the module in Appendix F of that document. Although 1740 a 2002 ASN.1 module is provided, this 1988 ASN.1 module remains the 1741 normative module as per the policy of the PKIX working group. 1743 PKIXCMP {iso(1) identified-organization(3) 1744 dod(6) internet(1) security(5) mechanisms(5) pkix(7) 1745 id-mod(0) id-mod-cmp2021-88(99)} 1747 DEFINITIONS EXPLICIT TAGS ::= 1749 BEGIN 1751 -- EXPORTS ALL -- 1753 IMPORTS 1755 Certificate, CertificateList, Extensions, Name, Time, 1756 AlgorithmIdentifier, id-kp 1757 --, UTF8String -- -- if required; otherwise, comment out 1758 FROM PKIX1Explicit88 {iso(1) identified-organization(3) 1759 dod(6) internet(1) security(5) mechanisms(5) pkix(7) 1760 id-mod(0) id-pkix1-explicit-88(18)} 1761 -- The import of Name is added to define CertificationRequest 1762 -- instead of importing it from PKCS#10 [RFC2986] 1764 DistributionPointName, GeneralNames, GeneralName, KeyIdentifier 1765 FROM PKIX1Implicit88 {iso(1) identified-organization(3) 1766 dod(6) internet(1) security(5) mechanisms(5) pkix(7) 1767 id-mod(0) id-pkix1-implicit-88(19)} 1769 CertTemplate, PKIPublicationInfo, EncryptedKey, CertId, 1770 CertReqMessages, Controls, AttributeTypeAndValue, id-regCtrl 1771 FROM PKIXCRMF-2005 {iso(1) identified-organization(3) 1772 dod(6) internet(1) security(5) mechanisms(5) pkix(7) 1773 id-mod(0) id-mod-crmf2005(36)} 1774 -- The import of EncryptedKey is added due to the updates made 1775 -- in CMP Updates [RFCXXXX]]. EncryptedValue does not need to 1776 -- be imported anymore and is therefore removed here. 1778 -- see also the behavioral clarifications to CRMF codified in 1779 -- Appendix C of this specification 1781 EnvelopedData, SignedData, Attribute 1782 FROM CryptographicMessageSyntax2004 { iso(1) 1783 member-body(2) us(840) rsadsi(113549) pkcs(1) pkcs-9(9) 1784 smime(16) modules(0) cms-2004(24) } 1785 -- The import of EnvelopedData and SignedData is added due to 1786 -- the updates made in CMP Updates [RFCXXXX] 1787 -- The import of Attribute is added to define 1788 -- CertificationRequest instead of importing it from 1789 -- PKCS#10 [RFC2986] 1791 ; 1793 -- the rest of the module contains locally-defined OIDs and 1794 -- constructs 1796 CMPCertificate ::= CHOICE { 1797 x509v3PKCert Certificate 1798 } 1799 -- This syntax, while bits-on-the-wire compatible with the 1800 -- standard X.509 definition of "Certificate", allows the 1801 -- possibility of future certificate types (such as X.509 1802 -- attribute certificates, WAP WTLS certificates, or other kinds 1803 -- of certificates) within this certificate management protocol, 1804 -- should a need ever arise to support such generality. Those 1805 -- implementations that do not foresee a need to ever support 1806 -- other certificate types MAY, if they wish, comment out the 1807 -- above structure and "un-comment" the following one prior to 1808 -- compiling this ASN.1 module. (Note that interoperability 1809 -- with implementations that don't do this will be unaffected by 1810 -- this change.) 1812 -- CMPCertificate ::= Certificate 1814 PKIMessage ::= SEQUENCE { 1815 header PKIHeader, 1816 body PKIBody, 1817 protection [0] PKIProtection OPTIONAL, 1818 extraCerts [1] SEQUENCE SIZE (1..MAX) OF CMPCertificate 1819 OPTIONAL 1820 } 1821 PKIMessages ::= SEQUENCE SIZE (1..MAX) OF PKIMessage 1823 PKIHeader ::= SEQUENCE { 1824 pvno INTEGER { cmp1999(1), cmp2000(2), 1825 cmp2021(3) }, 1826 sender GeneralName, 1827 -- identifies the sender 1828 recipient GeneralName, 1829 -- identifies the intended recipient 1830 messageTime [0] GeneralizedTime OPTIONAL, 1831 -- time of production of this message (used when sender 1832 -- believes that the transport will be "suitable"; i.e., 1833 -- that the time will still be meaningful upon receipt) 1834 protectionAlg [1] AlgorithmIdentifier OPTIONAL, 1835 -- algorithm used for calculation of protection bits 1836 senderKID [2] KeyIdentifier OPTIONAL, 1837 recipKID [3] KeyIdentifier OPTIONAL, 1838 -- to identify specific keys used for protection 1839 transactionID [4] OCTET STRING OPTIONAL, 1840 -- identifies the transaction; i.e., this will be the same in 1841 -- corresponding request, response, certConf, and PKIConf 1842 -- messages 1843 senderNonce [5] OCTET STRING OPTIONAL, 1844 recipNonce [6] OCTET STRING OPTIONAL, 1845 -- nonces used to provide replay protection, senderNonce 1846 -- is inserted by the creator of this message; recipNonce 1847 -- is a nonce previously inserted in a related message by 1848 -- the intended recipient of this message 1849 freeText [7] PKIFreeText OPTIONAL, 1850 -- this may be used to indicate context-specific instructions 1851 -- (this field is intended for human consumption) 1852 generalInfo [8] SEQUENCE SIZE (1..MAX) OF 1853 InfoTypeAndValue OPTIONAL 1854 -- this may be used to convey context-specific information 1855 -- (this field not primarily intended for human consumption) 1856 } 1858 PKIFreeText ::= SEQUENCE SIZE (1..MAX) OF UTF8String 1859 -- text encoded as UTF-8 String [RFC3629] 1861 PKIBody ::= CHOICE { -- message-specific body elements 1862 ir [0] CertReqMessages, --Initialization Request 1863 ip [1] CertRepMessage, --Initialization Response 1864 cr [2] CertReqMessages, --Certification Request 1865 cp [3] CertRepMessage, --Certification Response 1866 p10cr [4] CertificationRequest, --imported from [RFC2986] 1867 popdecc [5] POPODecKeyChallContent, --pop Challenge 1868 popdecr [6] POPODecKeyRespContent, --pop Response 1869 kur [7] CertReqMessages, --Key Update Request 1870 kup [8] CertRepMessage, --Key Update Response 1871 krr [9] CertReqMessages, --Key Recovery Request 1872 krp [10] KeyRecRepContent, --Key Recovery Response 1873 rr [11] RevReqContent, --Revocation Request 1874 rp [12] RevRepContent, --Revocation Response 1875 ccr [13] CertReqMessages, --Cross-Cert. Request 1876 ccp [14] CertRepMessage, --Cross-Cert. Response 1877 ckuann [15] CAKeyUpdAnnContent, --CA Key Update Ann. 1878 cann [16] CertAnnContent, --Certificate Ann. 1879 rann [17] RevAnnContent, --Revocation Ann. 1880 crlann [18] CRLAnnContent, --CRL Announcement 1881 pkiconf [19] PKIConfirmContent, --Confirmation 1882 nested [20] NestedMessageContent, --Nested Message 1883 genm [21] GenMsgContent, --General Message 1884 genp [22] GenRepContent, --General Response 1885 error [23] ErrorMsgContent, --Error Message 1886 certConf [24] CertConfirmContent, --Certificate confirm 1887 pollReq [25] PollReqContent, --Polling request 1888 pollRep [26] PollRepContent --Polling response 1889 } 1891 PKIProtection ::= BIT STRING 1893 ProtectedPart ::= SEQUENCE { 1894 header PKIHeader, 1895 body PKIBody 1896 } 1898 id-PasswordBasedMac OBJECT IDENTIFIER ::= {1 2 840 113533 7 66 13} 1899 PBMParameter ::= SEQUENCE { 1900 salt OCTET STRING, 1901 -- note: implementations MAY wish to limit acceptable sizes 1902 -- of this string to values appropriate for their environment 1903 -- in order to reduce the risk of denial-of-service attacks 1904 owf AlgorithmIdentifier, 1905 -- AlgId for a One-Way Function 1906 iterationCount INTEGER, 1907 -- number of times the OWF is applied 1908 -- note: implementations MAY wish to limit acceptable sizes 1909 -- of this integer to values appropriate for their environment 1910 -- in order to reduce the risk of denial-of-service attacks 1911 mac AlgorithmIdentifier 1912 -- the MAC AlgId (e.g., DES-MAC, Triple-DES-MAC [PKCS11], 1913 } -- or HMAC [RFC2104, RFC2202]) 1915 id-DHBasedMac OBJECT IDENTIFIER ::= {1 2 840 113533 7 66 30} 1916 DHBMParameter ::= SEQUENCE { 1917 owf AlgorithmIdentifier, 1918 -- AlgId for a One-Way Function 1919 mac AlgorithmIdentifier 1920 -- the MAC AlgId (e.g., DES-MAC, Triple-DES-MAC [PKCS11], 1921 } -- or HMAC [RFC2104, RFC2202]) 1923 NestedMessageContent ::= PKIMessages 1925 PKIStatus ::= INTEGER { 1926 accepted (0), 1927 -- you got exactly what you asked for 1928 grantedWithMods (1), 1929 -- you got something like what you asked for; the 1930 -- requester is responsible for ascertaining the differences 1931 rejection (2), 1932 -- you don't get it, more information elsewhere in the message 1933 waiting (3), 1934 -- the request body part has not yet been processed; expect to 1935 -- hear more later (note: proper handling of this status 1936 -- response MAY use the polling req/rep PKIMessages specified 1937 -- in Section 5.3.22 of [RFC4210]; alternatively, polling in the 1938 -- underlying transport layer MAY have some utility in this 1939 -- regard) 1940 revocationWarning (4), 1941 -- this message contains a warning that a revocation is 1942 -- imminent 1943 revocationNotification (5), 1944 -- notification that a revocation has occurred 1945 keyUpdateWarning (6) 1946 -- update already done for the oldCertId specified in 1947 -- CertReqMsg 1948 } 1950 PKIFailureInfo ::= BIT STRING { 1951 -- since we can fail in more than one way! 1952 -- More codes may be added in the future if/when required. 1953 badAlg (0), 1954 -- unrecognized or unsupported Algorithm Identifier 1955 badMessageCheck (1), 1956 -- integrity check failed (e.g., signature did not verify) 1957 badRequest (2), 1958 -- transaction not permitted or supported 1959 badTime (3), 1960 -- messageTime was not sufficiently close to the system time, 1961 -- as defined by local policy 1962 badCertId (4), 1963 -- no certificate could be found matching the provided criteria 1964 badDataFormat (5), 1965 -- the data submitted has the wrong format 1966 wrongAuthority (6), 1967 -- the authority indicated in the request is different from the 1968 -- one creating the response token 1969 incorrectData (7), 1970 -- the requester's data is incorrect (for notary services) 1971 missingTimeStamp (8), 1972 -- when the timestamp is missing but should be there 1973 -- (by policy) 1974 badPOP (9), 1975 -- the proof-of-possession failed 1976 certRevoked (10), 1977 -- the certificate has already been revoked 1978 certConfirmed (11), 1979 -- the certificate has already been confirmed 1980 wrongIntegrity (12), 1981 -- not valid integrity, password based instead of signature or 1982 -- vice versa 1983 badRecipientNonce (13), 1984 -- not valid recipient nonce, either missing or wrong value 1985 timeNotAvailable (14), 1986 -- the TSA's time source is not available 1987 unacceptedPolicy (15), 1988 -- the requested TSA policy is not supported by the TSA. 1989 unacceptedExtension (16), 1990 -- the requested extension is not supported by the TSA. 1991 addInfoNotAvailable (17), 1992 -- the additional information requested could not be 1993 -- understood or is not available 1994 badSenderNonce (18), 1995 -- not valid sender nonce, either missing or wrong size 1996 badCertTemplate (19), 1997 -- not valid cert. template or missing mandatory information 1998 signerNotTrusted (20), 1999 -- signer of the message unknown or not trusted 2000 transactionIdInUse (21), 2001 -- the transaction identifier is already in use 2002 unsupportedVersion (22), 2003 -- the version of the message is not supported 2004 notAuthorized (23), 2005 -- the sender was not authorized to make the preceding 2006 -- request or perform the preceding action 2007 systemUnavail (24), 2008 -- the request cannot be handled due to system unavailability 2009 systemFailure (25), 2010 -- the request cannot be handled due to system failure 2011 duplicateCertReq (26) 2012 -- certificate cannot be issued because a duplicate 2013 -- certificate already exists 2014 } 2016 PKIStatusInfo ::= SEQUENCE { 2017 status PKIStatus, 2018 statusString PKIFreeText OPTIONAL, 2019 failInfo PKIFailureInfo OPTIONAL 2020 } 2022 OOBCert ::= CMPCertificate 2024 OOBCertHash ::= SEQUENCE { 2025 hashAlg [0] AlgorithmIdentifier OPTIONAL, 2026 certId [1] CertId OPTIONAL, 2027 hashVal BIT STRING 2028 -- hashVal is calculated over the DER encoding of the 2029 -- self-signed certificate with the identifier certID. 2030 } 2032 POPODecKeyChallContent ::= SEQUENCE OF Challenge 2033 -- One Challenge per encryption key certification request (in the 2034 -- same order as these requests appear in CertReqMessages). 2036 Challenge ::= SEQUENCE { 2037 owf AlgorithmIdentifier OPTIONAL, 2038 -- MUST be present in the first Challenge; MAY be omitted in 2039 -- any subsequent Challenge in POPODecKeyChallContent (if 2040 -- omitted, then the owf used in the immediately preceding 2041 -- Challenge is to be used). 2042 witness OCTET STRING, 2043 -- the result of applying the one-way function (owf) to a 2044 -- randomly-generated INTEGER, A. [Note that a different 2045 -- INTEGER MUST be used for each Challenge.] 2046 challenge OCTET STRING 2047 -- the encryption (under the public key for which the cert. 2048 -- request is being made) of Rand. 2049 } 2051 -- Added in CMP Updates [RFCXXXX] 2053 Rand ::= SEQUENCE { 2054 -- Rand is encrypted under the public key to form the challenge 2055 -- in POPODecKeyChallContent 2056 int INTEGER, 2057 -- the randomly-generated INTEGER A (above) 2058 sender GeneralName 2059 -- the sender's name (as included in PKIHeader) 2061 } 2063 POPODecKeyRespContent ::= SEQUENCE OF INTEGER 2064 -- One INTEGER per encryption key certification request (in the 2065 -- same order as these requests appear in CertReqMessages). The 2066 -- retrieved INTEGER A (above) is returned to the sender of the 2067 -- corresponding Challenge. 2069 CertRepMessage ::= SEQUENCE { 2070 caPubs [1] SEQUENCE SIZE (1..MAX) OF CMPCertificate 2071 OPTIONAL, 2072 response SEQUENCE OF CertResponse 2073 } 2075 CertificationRequest ::= SEQUENCE { 2076 certificationRequestInfo SEQUENCE { 2077 version INTEGER, 2078 subject Name, 2079 subjectPublicKeyInfo SEQUENCE { 2080 algorithm AlgorithmIdentifier, 2081 subjectPublicKey BIT STRING }, 2082 attributes [0] IMPLICIT SET OF Attribute }, 2083 signatureAlgorithm AlgorithmIdentifier, 2084 signature BIT STRING 2085 } 2087 CertResponse ::= SEQUENCE { 2088 certReqId INTEGER, 2089 -- to match this response with corresponding request (a value 2090 -- of -1 is to be used if certReqId is not specified in the 2091 -- corresponding request, which can only be a p10cr) 2092 status PKIStatusInfo, 2093 certifiedKeyPair CertifiedKeyPair OPTIONAL, 2094 rspInfo OCTET STRING OPTIONAL 2095 -- analogous to the id-regInfo-utf8Pairs string defined 2096 -- for regInfo in CertReqMsg [RFC4211] 2097 } 2099 CertifiedKeyPair ::= SEQUENCE { 2100 certOrEncCert CertOrEncCert, 2101 privateKey [0] EncryptedKey OPTIONAL, 2102 -- see [RFC4211] for comment on encoding 2103 -- Changed from Encrypted Value to EncryptedKey as a CHOICE of 2104 -- EncryptedValue and EnvelopedData due to the changes made in 2105 -- CMP Updates [RFCXXXX] 2106 -- Using the choice EncryptedValue is bit-compatible to the 2107 -- syntax without this change 2108 publicationInfo [1] PKIPublicationInfo OPTIONAL 2110 } 2112 CertOrEncCert ::= CHOICE { 2113 certificate [0] CMPCertificate, 2114 encryptedCert [1] EncryptedKey 2115 -- Changed from Encrypted Value to EncryptedKey as a CHOICE of 2116 -- EncryptedValue and EnvelopedData due to the changes made in 2117 -- CMP Updates [RFCXXXX] 2118 -- Using the choice EncryptedValue is bit-compatible to the 2119 -- syntax without this change 2120 } 2122 KeyRecRepContent ::= SEQUENCE { 2123 status PKIStatusInfo, 2124 newSigCert [0] CMPCertificate OPTIONAL, 2125 caCerts [1] SEQUENCE SIZE (1..MAX) OF 2126 CMPCertificate OPTIONAL, 2127 keyPairHist [2] SEQUENCE SIZE (1..MAX) OF 2128 CertifiedKeyPair OPTIONAL 2129 } 2131 RevReqContent ::= SEQUENCE OF RevDetails 2133 RevDetails ::= SEQUENCE { 2134 certDetails CertTemplate, 2135 -- allows requester to specify as much as they can about 2136 -- the cert. for which revocation is requested 2137 -- (e.g., for cases in which serialNumber is not available) 2138 crlEntryDetails Extensions OPTIONAL 2139 -- requested crlEntryExtensions 2140 } 2142 RevRepContent ::= SEQUENCE { 2143 status SEQUENCE SIZE (1..MAX) OF PKIStatusInfo, 2144 -- in same order as was sent in RevReqContent 2145 revCerts [0] SEQUENCE SIZE (1..MAX) OF CertId 2146 OPTIONAL, 2147 -- IDs for which revocation was requested 2148 -- (same order as status) 2149 crls [1] SEQUENCE SIZE (1..MAX) OF CertificateList 2150 OPTIONAL 2151 -- the resulting CRLs (there may be more than one) 2152 } 2154 CAKeyUpdAnnContent ::= SEQUENCE { 2155 oldWithNew CMPCertificate, -- old pub signed with new priv 2156 newWithOld CMPCertificate, -- new pub signed with old priv 2157 newWithNew CMPCertificate -- new pub signed with new priv 2159 } 2161 CertAnnContent ::= CMPCertificate 2163 RevAnnContent ::= SEQUENCE { 2164 status PKIStatus, 2165 certId CertId, 2166 willBeRevokedAt GeneralizedTime, 2167 badSinceDate GeneralizedTime, 2168 crlDetails Extensions OPTIONAL 2169 -- extra CRL details (e.g., crl number, reason, location, etc.) 2170 } 2172 CRLAnnContent ::= SEQUENCE OF CertificateList 2174 CertConfirmContent ::= SEQUENCE OF CertStatus 2176 CertStatus ::= SEQUENCE { 2177 certHash OCTET STRING, 2178 -- the hash of the certificate, using the same hash algorithm 2179 -- as is used to create and verify the certificate signature 2180 certReqId INTEGER, 2181 -- to match this confirmation with the corresponding req/rep 2182 statusInfo PKIStatusInfo OPTIONAL, 2183 hashAlg [0] AlgorithmIdentifier OPTIONAL 2184 -- the hash algorithm to use for calculating certHash 2185 -- SHOULD NOT be used in all cases where the AlgorithmIdentifier 2186 -- of the certificate signature specifies a hash algorithm 2187 } 2189 PKIConfirmContent ::= NULL 2191 -- CertReqTemplateContent, id-regCtrl-algId, id-regCtrl-algId, and 2192 -- id-regCtrl-rsaKeyLen were added in CMP Updates [RFCXXXX] 2194 CertReqTemplateContent ::= SEQUENCE { 2195 certTemplate CertTemplate, 2196 -- prefilled certTemplate structure elements 2197 -- The SubjectPublicKeyInfo field in the certTemplate MUST NOT 2198 -- be used. 2199 keySpec Controls OPTIONAL 2200 -- MAY be used to specify supported algorithms. 2201 -- Controls ::= SEQUENCE SIZE (1..MAX) OF AttributeTypeAndValue 2202 -- as specified in CRMF (RFC4211) 2203 } 2205 id-regCtrl-altCertTemplate OBJECT IDENTIFIER ::= { id-regCtrl 7 } 2206 AltCertTemplate ::= AttributeTypeAndValue 2207 -- specifies a template for a certificate other than an X.509v3 2208 -- public-key certificate 2210 id-regCtrl-algId OBJECT IDENTIFIER ::= { id-regCtrl 11 } 2211 AlgIdCtrl ::= AlgorithmIdentifier 2212 -- SHALL be used to specify supported algorithms other than RSA 2214 id-regCtrl-rsaKeyLen OBJECT IDENTIFIER ::= { id-regCtrl 12 } 2215 RsaKeyLenCtrl ::= INTEGER (1..MAX) 2216 -- SHALL be used to specify supported RSA key lengths 2218 -- RootCaKeyUpdateContent, CRLSource, and CRLStatus were added in 2219 -- CMP Updates [RFCXXXX] 2221 RootCaKeyUpdateContent ::= SEQUENCE { 2222 newWithNew CMPCertificate, 2223 -- new root CA certificate 2224 newWithOld [0] CMPCertificate OPTIONAL, 2225 -- X.509 certificate containing the new public root CA key 2226 -- signed with the old private root CA key 2227 oldWithNew [1] CMPCertificate OPTIONAL 2228 -- X.509 certificate containing the old public root CA key 2229 -- signed with the new private root CA key 2230 } 2232 CRLSource ::= CHOICE { 2233 dpn [0] DistributionPointName, 2234 issuer [1] GeneralNames } 2236 CRLStatus ::= SEQUENCE { 2237 source CRLSource, 2238 thisUpdate Time OPTIONAL } 2240 InfoTypeAndValue ::= SEQUENCE { 2241 infoType OBJECT IDENTIFIER, 2242 infoValue ANY DEFINED BY infoType OPTIONAL 2243 } 2244 -- Example InfoTypeAndValue contents include, but are not limited 2245 -- to, the following (un-comment in this ASN.1 module and use as 2246 -- appropriate for a given environment): 2247 -- 2248 -- id-it-caProtEncCert OBJECT IDENTIFIER ::= {id-it 1} 2249 -- CAProtEncCertValue ::= CMPCertificate 2250 -- id-it-signKeyPairTypes OBJECT IDENTIFIER ::= {id-it 2} 2251 -- SignKeyPairTypesValue ::= SEQUENCE SIZE (1..MAX) OF 2252 -- AlgorithmIdentifier 2253 -- id-it-encKeyPairTypes OBJECT IDENTIFIER ::= {id-it 3} 2254 -- EncKeyPairTypesValue ::= SEQUENCE SIZE (1..MAX) OF 2255 -- AlgorithmIdentifier 2256 -- id-it-preferredSymmAlg OBJECT IDENTIFIER ::= {id-it 4} 2257 -- PreferredSymmAlgValue ::= AlgorithmIdentifier 2258 -- id-it-caKeyUpdateInfo OBJECT IDENTIFIER ::= {id-it 5} 2259 -- CAKeyUpdateInfoValue ::= CAKeyUpdAnnContent 2260 -- id-it-currentCRL OBJECT IDENTIFIER ::= {id-it 6} 2261 -- CurrentCRLValue ::= CertificateList 2262 -- id-it-unsupportedOIDs OBJECT IDENTIFIER ::= {id-it 7} 2263 -- UnsupportedOIDsValue ::= SEQUENCE SIZE (1..MAX) OF 2264 -- OBJECT IDENTIFIER 2265 -- id-it-keyPairParamReq OBJECT IDENTIFIER ::= {id-it 10} 2266 -- KeyPairParamReqValue ::= OBJECT IDENTIFIER 2267 -- id-it-keyPairParamRep OBJECT IDENTIFIER ::= {id-it 11} 2268 -- KeyPairParamRepValue ::= AlgorithmIdentifier 2269 -- id-it-revPassphrase OBJECT IDENTIFIER ::= {id-it 12} 2270 -- RevPassphraseValue ::= EncryptedKey 2271 -- - Changed from Encrypted Value to EncryptedKey as a CHOICE 2272 -- - of EncryptedValue and EnvelopedData due to the changes 2273 -- - made in CMP Updates [RFCXXXX] 2274 -- - Using the choice EncryptedValue is bit-compatible to the 2275 -- - syntax without this change 2276 -- id-it-implicitConfirm OBJECT IDENTIFIER ::= {id-it 13} 2277 -- ImplicitConfirmValue ::= NULL 2278 -- id-it-confirmWaitTime OBJECT IDENTIFIER ::= {id-it 14} 2279 -- ConfirmWaitTimeValue ::= GeneralizedTime 2280 -- id-it-origPKIMessage OBJECT IDENTIFIER ::= {id-it 15} 2281 -- OrigPKIMessageValue ::= PKIMessages 2282 -- id-it-suppLangTags OBJECT IDENTIFIER ::= {id-it 16} 2283 -- SuppLangTagsValue ::= SEQUENCE OF UTF8String 2284 -- id-it-caCerts OBJECT IDENTIFIER ::= {id-it 17} 2285 -- CaCertsValue ::= SEQUENCE SIZE (1..MAX) OF 2286 -- CMPCertificate 2287 -- - id-it-caCerts added in CMP Updates [RFCXXXX] 2288 -- id-it-rootCaKeyUpdate OBJECT IDENTIFIER ::= {id-it 18} 2289 -- RootCaKeyUpdateValue ::= RootCaKeyUpdateContent 2290 -- - id-it-rootCaKeyUpdate added in CMP Updates [RFCXXXX] 2291 -- id-it-certReqTemplate OBJECT IDENTIFIER ::= {id-it 19} 2292 -- CertReqTemplateValue ::= CertReqTemplateContent 2293 -- - id-it-certReqTemplate added in CMP Updates [RFCXXXX] 2294 -- id-it-rootCaCert OBJECT IDENTIFIER ::= {id-it 20} 2295 -- RootCaCertValue ::= CMPCertificate 2296 -- - id-it-rootCaCert added in CMP Updates [RFCXXXX] 2297 -- id-it-certProfile OBJECT IDENTIFIER ::= {id-it 21} 2298 -- CertProfileValue ::= SEQUENCE SIZE (1..MAX) OF 2299 -- UTF8String 2300 -- - id-it-certProfile added in CMP Updates [RFCXXXX] 2301 -- id-it-crlStatusList OBJECT IDENTIFIER ::= {id-it 22} 2302 -- CRLStatusListValue ::= SEQUENCE SIZE (1..MAX) OF 2303 -- CRLStatus 2304 -- - id-it-crlStatusList added in CMP Updates [RFCXXXX] 2305 -- id-it-crls OBJECT IDENTIFIER ::= {id-it 23} 2306 -- CRLsValue ::= SEQUENCE SIZE (1..MAX) OF 2307 -- CertificateList 2308 -- - id-it-crls added in CMP Updates [RFCXXXX] 2309 -- 2310 -- where 2311 -- 2312 -- id-pkix OBJECT IDENTIFIER ::= { 2313 -- iso(1) identified-organization(3) 2314 -- dod(6) internet(1) security(5) mechanisms(5) pkix(7)} 2315 -- and 2316 -- id-it OBJECT IDENTIFIER ::= {id-pkix 4} 2317 -- 2318 -- 2319 -- This construct MAY also be used to define new PKIX Certificate 2320 -- Management Protocol request and response messages, or general- 2321 -- purpose (e.g., announcement) messages for future needs or for 2322 -- specific environments. 2324 GenMsgContent ::= SEQUENCE OF InfoTypeAndValue 2326 -- May be sent by EE, RA, or CA (depending on message content). 2327 -- The OPTIONAL infoValue parameter of InfoTypeAndValue will 2328 -- typically be omitted for some of the examples given above. 2329 -- The receiver is free to ignore any contained OBJ. IDs that it 2330 -- does not recognize. If sent from EE to CA, the empty set 2331 -- indicates that the CA may send 2332 -- any/all information that it wishes. 2334 GenRepContent ::= SEQUENCE OF InfoTypeAndValue 2335 -- Receiver MAY ignore any contained OIDs that it does not 2336 -- recognize. 2338 ErrorMsgContent ::= SEQUENCE { 2339 pKIStatusInfo PKIStatusInfo, 2340 errorCode INTEGER OPTIONAL, 2341 -- implementation-specific error codes 2342 errorDetails PKIFreeText OPTIONAL 2343 -- implementation-specific error details 2344 } 2346 PollReqContent ::= SEQUENCE OF SEQUENCE { 2347 certReqId INTEGER 2348 } 2350 PollRepContent ::= SEQUENCE OF SEQUENCE { 2351 certReqId INTEGER, 2352 checkAfter INTEGER, -- time in seconds 2353 reason PKIFreeText OPTIONAL 2354 } 2356 -- 2357 -- Extended Key Usage extension for PKI entities used in CMP 2358 -- operations, added due to the changes made in 2359 -- CMP Updates [RFCXXXX] 2360 -- The EKUs for the CA and RA are reused from CMC as defined in 2361 -- [RFC6402] 2362 -- 2364 -- id-kp-cmcCA OBJECT IDENTIFIER ::= { id-kp 27 } 2365 -- id-kp-cmcRA OBJECT IDENTIFIER ::= { id-kp 28 } 2366 id-kp-cmKGA OBJECT IDENTIFIER ::= { id-kp 32 } 2368 -- There is no 1988 ASN.1 module of PKCS#9 available to import the 2369 -- syntax of the localKeyId attribute type and value from. Therefore, 2370 -- the syntax is added here as needed for the updates made in 2371 -- CMP Updates [RFCXXXX] 2373 pkcs-9 OBJECT IDENTIFIER ::= {iso(1) member-body(2) us(840) 2374 rsadsi(113549) pkcs(1) 9} 2376 pkcs-9-at-localKeyId OBJECT IDENTIFIER ::= {pkcs-9 21} 2378 LocalKeyIdValue ::= OCTET STRING 2380 END -- of CMP module 2382 A.2. Update to RFC5912 - 2002 ASN.1 Module 2384 This section contains the updated 2002 ASN.1 module for [RFC5912]. 2385 This module replaces the module in Section 9 of [RFC5912]. The 2386 module contains those changes to the normative ASN.1 module from 2387 RFC4210 Appendix F [RFC4210] that were to update to 2002 ASN.1 2388 standard done in [RFC5912] as well as changes made in this document. 2390 PKIXCMP-2021 2391 { iso(1) identified-organization(3) dod(6) internet(1) 2392 security(5) mechanisms(5) pkix(7) id-mod(0) 2393 id-mod-cmp2021-02(100) } 2394 DEFINITIONS EXPLICIT TAGS ::= 2395 BEGIN 2396 IMPORTS 2398 AttributeSet{}, SingleAttribute{}, Extensions{}, EXTENSION, ATTRIBUTE 2399 FROM PKIX-CommonTypes-2009 2400 {iso(1) identified-organization(3) dod(6) internet(1) security(5) 2401 mechanisms(5) pkix(7) id-mod(0) id-mod-pkixCommon-02(57)} 2403 AlgorithmIdentifier{}, SIGNATURE-ALGORITHM, ALGORITHM, 2404 DIGEST-ALGORITHM, MAC-ALGORITHM 2405 FROM AlgorithmInformation-2009 2406 {iso(1) identified-organization(3) dod(6) internet(1) security(5) 2407 mechanisms(5) pkix(7) id-mod(0) 2408 id-mod-algorithmInformation-02(58)} 2410 Certificate, CertificateList, Time, id-kp 2411 FROM PKIX1Explicit-2009 2412 {iso(1) identified-organization(3) dod(6) internet(1) security(5) 2413 mechanisms(5) pkix(7) id-mod(0) id-mod-pkix1-explicit-02(51)} 2415 DistributionPointName, GeneralNames, GeneralName, KeyIdentifier 2416 FROM PKIX1Implicit-2009 2417 {iso(1) identified-organization(3) dod(6) internet(1) security(5) 2418 mechanisms(5) pkix(7) id-mod(0) id-mod-pkix1-implicit-02(59)} 2420 CertTemplate, PKIPublicationInfo, EncryptedKey, CertId, 2421 CertReqMessages, Controls, RegControlSet, id-regCtrl 2422 FROM PKIXCRMF-2009 2423 { iso(1) identified-organization(3) dod(6) internet(1) 2424 security(5) mechanisms(5) pkix(7) id-mod(0) 2425 id-mod-crmf2005-02(55) } 2426 -- The import of EncryptedKey is added due to the updates made 2427 -- in CMP Updates [RFCXXXX]. EncryptedValue does not need to 2428 -- be imported anymore and is therefore removed here. 2430 -- see also the behavioral clarifications to CRMF codified in 2431 -- Appendix C of this specification 2433 CertificationRequest 2434 FROM PKCS-10 2435 {iso(1) identified-organization(3) dod(6) internet(1) security(5) 2436 mechanisms(5) pkix(7) id-mod(0) id-mod-pkcs10-2009(69)} 2437 -- (specified in RFC 2986 with 1993 ASN.1 syntax and IMPLICIT 2438 -- tags). Alternatively, implementers may directly include 2439 -- the [RFC2986] syntax in this module 2441 localKeyId 2442 FROM PKCS-9 2443 {iso(1) member-body(2) us(840) rsadsi(113549) pkcs(1) pkcs-9(9) 2444 modules(0) pkcs-9(1)} 2445 -- The import of localKeyId is added due to the updates made in 2446 -- CMP Updates [RFCXXXX] 2448 EnvelopedData, SignedData 2449 FROM CryptographicMessageSyntax-2009 2450 {iso(1) member-body(2) us(840) rsadsi(113549) pkcs(1) pkcs-9(9) 2451 smime(16) modules(0) id-mod-cms-2004-02(41)} 2452 -- The import of EnvelopedData and SignedData is added due to 2453 -- the updates made in CMP Updates [RFCXXXX] 2454 ; 2456 -- the rest of the module contains locally defined OIDs and 2457 -- constructs 2459 CMPCertificate ::= CHOICE { x509v3PKCert Certificate, ... } 2460 -- This syntax, while bits-on-the-wire compatible with the 2461 -- standard X.509 definition of "Certificate", allows the 2462 -- possibility of future certificate types (such as X.509 2463 -- attribute certificates, WAP WTLS certificates, or other kinds 2464 -- of certificates) within this certificate management protocol, 2465 -- should a need ever arise to support such generality. Those 2466 -- implementations that do not foresee a need to ever support 2467 -- other certificate types MAY, if they wish, comment out the 2468 -- above structure and "uncomment" the following one prior to 2469 -- compiling this ASN.1 module. (Note that interoperability 2470 -- with implementations that don't do this will be unaffected by 2471 -- this change.) 2473 -- CMPCertificate ::= Certificate 2475 PKIMessage ::= SEQUENCE { 2476 header PKIHeader, 2477 body PKIBody, 2478 protection [0] PKIProtection OPTIONAL, 2479 extraCerts [1] SEQUENCE SIZE (1..MAX) OF CMPCertificate 2480 OPTIONAL } 2482 PKIMessages ::= SEQUENCE SIZE (1..MAX) OF PKIMessage 2484 PKIHeader ::= SEQUENCE { 2485 pvno INTEGER { cmp1999(1), cmp2000(2), 2486 cmp2012(3) }, 2487 sender GeneralName, 2488 -- identifies the sender 2489 recipient GeneralName, 2490 -- identifies the intended recipient 2491 messageTime [0] GeneralizedTime OPTIONAL, 2492 -- time of production of this message (used when sender 2493 -- believes that the transport will be "suitable"; i.e., 2494 -- that the time will still be meaningful upon receipt) 2495 protectionAlg [1] AlgorithmIdentifier{ALGORITHM, {...}} 2496 OPTIONAL, 2497 -- algorithm used for calculation of protection bits 2498 senderKID [2] KeyIdentifier OPTIONAL, 2499 recipKID [3] KeyIdentifier OPTIONAL, 2500 -- to identify specific keys used for protection 2501 transactionID [4] OCTET STRING OPTIONAL, 2502 -- identifies the transaction; i.e., this will be the same in 2503 -- corresponding request, response, certConf, and PKIConf 2504 -- messages 2505 senderNonce [5] OCTET STRING OPTIONAL, 2506 recipNonce [6] OCTET STRING OPTIONAL, 2507 -- nonces used to provide replay protection, senderNonce 2508 -- is inserted by the creator of this message; recipNonce 2509 -- is a nonce previously inserted in a related message by 2510 -- the intended recipient of this message 2511 freeText [7] PKIFreeText OPTIONAL, 2512 -- this may be used to indicate context-specific instructions 2513 -- (this field is intended for human consumption) 2514 generalInfo [8] SEQUENCE SIZE (1..MAX) OF 2515 InfoTypeAndValue OPTIONAL 2516 -- this may be used to convey context-specific information 2517 -- (this field not primarily intended for human consumption) 2518 } 2520 PKIFreeText ::= SEQUENCE SIZE (1..MAX) OF UTF8String 2521 -- text encoded as UTF-8 String [RFC3629] 2523 PKIBody ::= CHOICE { -- message-specific body elements 2524 ir [0] CertReqMessages, --Initialization Request 2525 ip [1] CertRepMessage, --Initialization Response 2526 cr [2] CertReqMessages, --Certification Request 2527 cp [3] CertRepMessage, --Certification Response 2528 p10cr [4] CertificationRequest, --imported from [RFC2986] 2529 popdecc [5] POPODecKeyChallContent, --pop Challenge 2530 popdecr [6] POPODecKeyRespContent, --pop Response 2531 kur [7] CertReqMessages, --Key Update Request 2532 kup [8] CertRepMessage, --Key Update Response 2533 krr [9] CertReqMessages, --Key Recovery Request 2534 krp [10] KeyRecRepContent, --Key Recovery Response 2535 rr [11] RevReqContent, --Revocation Request 2536 rp [12] RevRepContent, --Revocation Response 2537 ccr [13] CertReqMessages, --Cross-Cert. Request 2538 ccp [14] CertRepMessage, --Cross-Cert. Response 2539 ckuann [15] CAKeyUpdAnnContent, --CA Key Update Ann. 2540 cann [16] CertAnnContent, --Certificate Ann. 2541 rann [17] RevAnnContent, --Revocation Ann. 2542 crlann [18] CRLAnnContent, --CRL Announcement 2543 pkiconf [19] PKIConfirmContent, --Confirmation 2544 nested [20] NestedMessageContent, --Nested Message 2545 genm [21] GenMsgContent, --General Message 2546 genp [22] GenRepContent, --General Response 2547 error [23] ErrorMsgContent, --Error Message 2548 certConf [24] CertConfirmContent, --Certificate confirm 2549 pollReq [25] PollReqContent, --Polling request 2550 pollRep [26] PollRepContent --Polling response 2551 } 2553 PKIProtection ::= BIT STRING 2555 ProtectedPart ::= SEQUENCE { 2556 header PKIHeader, 2557 body PKIBody } 2559 id-PasswordBasedMac OBJECT IDENTIFIER ::= { iso(1) member-body(2) 2560 usa(840) nt(113533) nsn(7) algorithms(66) 13 } 2561 PBMParameter ::= SEQUENCE { 2562 salt OCTET STRING, 2563 -- note: implementations MAY wish to limit acceptable sizes 2564 -- of this string to values appropriate for their environment 2565 -- in order to reduce the risk of denial-of-service attacks 2566 owf AlgorithmIdentifier{DIGEST-ALGORITHM, {...}}, 2567 -- AlgId for a One-Way Function 2568 iterationCount INTEGER, 2569 -- number of times the OWF is applied 2570 -- note: implementations MAY wish to limit acceptable sizes 2571 -- of this integer to values appropriate for their environment 2572 -- in order to reduce the risk of denial-of-service attacks 2573 mac AlgorithmIdentifier{MAC-ALGORITHM, {...}} 2574 -- the MAC AlgId (e.g., DES-MAC, Triple-DES-MAC [PKCS11], 2575 -- or HMAC [RFC2104, RFC2202]) 2576 } 2578 id-DHBasedMac OBJECT IDENTIFIER ::= { iso(1) member-body(2) 2579 usa(840) nt(113533) nsn(7) algorithms(66) 30 } 2580 DHBMParameter ::= SEQUENCE { 2581 owf AlgorithmIdentifier{DIGEST-ALGORITHM, {...}}, 2582 -- AlgId for a One-Way Function 2583 mac AlgorithmIdentifier{MAC-ALGORITHM, {...}} 2584 -- the MAC AlgId (e.g., DES-MAC, Triple-DES-MAC [PKCS11], 2585 -- or HMAC [RFC2104, RFC2202]) 2586 } 2588 PKIStatus ::= INTEGER { 2589 accepted (0), 2590 -- you got exactly what you asked for 2591 grantedWithMods (1), 2592 -- you got something like what you asked for; the 2593 -- requester is responsible for ascertaining the differences 2594 rejection (2), 2595 -- you don't get it, more information elsewhere in the message 2596 waiting (3), 2597 -- the request body part has not yet been processed; expect to 2598 -- hear more later (note: proper handling of this status 2599 -- response MAY use the polling req/rep PKIMessages specified 2600 -- in Section 5.3.22 of [RFC4210]; alternatively, polling in the 2601 -- underlying transport layer MAY have some utility in this 2602 -- regard) 2603 revocationWarning (4), 2604 -- this message contains a warning that a revocation is 2605 -- imminent 2606 revocationNotification (5), 2607 -- notification that a revocation has occurred 2608 keyUpdateWarning (6) 2609 -- update already done for the oldCertId specified in 2610 -- CertReqMsg 2611 } 2613 PKIFailureInfo ::= BIT STRING { 2614 -- since we can fail in more than one way! 2615 -- More codes may be added in the future if/when required. 2616 badAlg (0), 2617 -- unrecognized or unsupported Algorithm Identifier 2618 badMessageCheck (1), 2619 -- integrity check failed (e.g., signature did not verify) 2620 badRequest (2), 2621 -- transaction not permitted or supported 2622 badTime (3), 2623 -- messageTime was not sufficiently close to the system time, 2624 -- as defined by local policy 2625 badCertId (4), 2626 -- no certificate could be found matching the provided criteria 2627 badDataFormat (5), 2628 -- the data submitted has the wrong format 2629 wrongAuthority (6), 2630 -- the authority indicated in the request is different from the 2631 -- one creating the response token 2632 incorrectData (7), 2633 -- the requester's data is incorrect (for notary services) 2634 missingTimeStamp (8), 2635 -- when the timestamp is missing but should be there 2636 -- (by policy) 2637 badPOP (9), 2638 -- the proof-of-possession failed 2639 certRevoked (10), 2640 -- the certificate has already been revoked 2641 certConfirmed (11), 2642 -- the certificate has already been confirmed 2643 wrongIntegrity (12), 2644 -- not valid integrity, password based instead of signature or 2645 -- vice versa 2646 badRecipientNonce (13), 2647 -- not valid recipient nonce, either missing or wrong value 2648 timeNotAvailable (14), 2649 -- the TSA's time source is not available 2650 unacceptedPolicy (15), 2651 -- the requested TSA policy is not supported by the TSA 2652 unacceptedExtension (16), 2653 -- the requested extension is not supported by the TSA 2654 addInfoNotAvailable (17), 2655 -- the additional information requested could not be 2656 -- understood or is not available 2657 badSenderNonce (18), 2658 -- not valid sender nonce, either missing or wrong size 2659 badCertTemplate (19), 2660 -- not valid cert. template or missing mandatory information 2661 signerNotTrusted (20), 2662 -- signer of the message unknown or not trusted 2663 transactionIdInUse (21), 2664 -- the transaction identifier is already in use 2665 unsupportedVersion (22), 2666 -- the version of the message is not supported 2667 notAuthorized (23), 2668 -- the sender was not authorized to make the preceding 2669 -- request or perform the preceding action 2670 systemUnavail (24), 2671 -- the request cannot be handled due to system unavailability 2672 systemFailure (25), 2673 -- the request cannot be handled due to system failure 2674 duplicateCertReq (26) 2675 -- certificate cannot be issued because a duplicate 2676 -- certificate already exists 2677 } 2679 PKIStatusInfo ::= SEQUENCE { 2680 status PKIStatus, 2681 statusString PKIFreeText OPTIONAL, 2682 failInfo PKIFailureInfo OPTIONAL } 2684 OOBCert ::= CMPCertificate 2686 OOBCertHash ::= SEQUENCE { 2687 hashAlg [0] AlgorithmIdentifier{DIGEST-ALGORITHM, {...}} 2688 OPTIONAL, 2689 certId [1] CertId OPTIONAL, 2690 hashVal BIT STRING 2691 -- hashVal is calculated over the DER encoding of the 2692 -- self-signed certificate with the identifier certID. 2693 } 2695 POPODecKeyChallContent ::= SEQUENCE OF Challenge 2696 -- One Challenge per encryption key certification request (in the 2697 -- same order as these requests appear in CertReqMessages). 2699 Challenge ::= SEQUENCE { 2700 owf AlgorithmIdentifier{DIGEST-ALGORITHM, {...}} 2701 OPTIONAL, 2702 -- MUST be present in the first Challenge; MAY be omitted in 2703 -- any subsequent Challenge in POPODecKeyChallContent (if 2704 -- omitted, then the owf used in the immediately preceding 2705 -- Challenge is to be used). 2706 witness OCTET STRING, 2707 -- the result of applying the one-way function (owf) to a 2708 -- randomly-generated INTEGER, A. [Note that a different 2709 -- INTEGER MUST be used for each Challenge.] 2710 challenge OCTET STRING 2711 -- the encryption (under the public key for which the cert. 2712 -- request is being made) of Rand. 2713 } 2715 -- Added in CMP Updates [RFCXXXX] 2717 Rand ::= SEQUENCE { 2718 -- Rand is encrypted under the public key to form the challenge 2719 -- in POPODecKeyChallContent 2720 int INTEGER, 2721 -- the randomly-generated INTEGER A (above) 2722 sender GeneralName 2723 -- the sender's name (as included in PKIHeader) 2724 } 2726 POPODecKeyRespContent ::= SEQUENCE OF INTEGER 2727 -- One INTEGER per encryption key certification request (in the 2728 -- same order as these requests appear in CertReqMessages). The 2729 -- retrieved INTEGER A (above) is returned to the sender of the 2730 -- corresponding Challenge. 2732 CertRepMessage ::= SEQUENCE { 2733 caPubs [1] SEQUENCE SIZE (1..MAX) OF CMPCertificate 2734 OPTIONAL, 2735 response SEQUENCE OF CertResponse } 2737 CertResponse ::= SEQUENCE { 2738 certReqId INTEGER, 2739 -- to match this response with the corresponding request (a value 2740 -- of -1 is to be used if certReqId is not specified in the 2741 -- corresponding request, which can only be a p10cr) 2742 status PKIStatusInfo, 2743 certifiedKeyPair CertifiedKeyPair OPTIONAL, 2744 rspInfo OCTET STRING OPTIONAL 2745 -- analogous to the id-regInfo-utf8Pairs string defined 2746 -- for regInfo in CertReqMsg [RFC4211] 2747 } 2749 CertifiedKeyPair ::= SEQUENCE { 2750 certOrEncCert CertOrEncCert, 2751 privateKey [0] EncryptedKey OPTIONAL, 2752 -- see [RFC4211] for comment on encoding 2753 -- Changed from Encrypted Value to EncryptedKey as a CHOICE of 2754 -- EncryptedValue and EnvelopedData due to the changes made in 2755 -- CMP Updates [RFCXXXX] 2756 -- Using the choice EncryptedValue is bit-compatible to the 2757 -- syntax without this change 2758 publicationInfo [1] PKIPublicationInfo OPTIONAL } 2760 CertOrEncCert ::= CHOICE { 2761 certificate [0] CMPCertificate, 2762 encryptedCert [1] EncryptedKey 2763 -- Changed from Encrypted Value to EncryptedKey as a CHOICE of 2764 -- EncryptedValue and EnvelopedData due to the changes made in 2765 -- CMP Updates [RFCXXXX] 2766 -- Using the choice EncryptedValue is bit-compatible to the 2767 -- syntax without this change 2768 } 2770 KeyRecRepContent ::= SEQUENCE { 2771 status PKIStatusInfo, 2772 newSigCert [0] CMPCertificate OPTIONAL, 2773 caCerts [1] SEQUENCE SIZE (1..MAX) OF 2774 CMPCertificate OPTIONAL, 2775 keyPairHist [2] SEQUENCE SIZE (1..MAX) OF 2776 CertifiedKeyPair OPTIONAL } 2778 RevReqContent ::= SEQUENCE OF RevDetails 2780 RevDetails ::= SEQUENCE { 2781 certDetails CertTemplate, 2782 -- allows requester to specify as much as they can about 2783 -- the cert. for which revocation is requested 2784 -- (e.g., for cases in which serialNumber is not available) 2785 crlEntryDetails Extensions{{...}} OPTIONAL 2786 -- requested crlEntryExtensions 2787 } 2789 RevRepContent ::= SEQUENCE { 2790 status SEQUENCE SIZE (1..MAX) OF PKIStatusInfo, 2791 -- in same order as was sent in RevReqContent 2792 revCerts [0] SEQUENCE SIZE (1..MAX) OF CertId OPTIONAL, 2793 -- IDs for which revocation was requested 2794 -- (same order as status) 2795 crls [1] SEQUENCE SIZE (1..MAX) OF CertificateList OPTIONAL 2796 -- the resulting CRLs (there may be more than one) 2797 } 2799 CAKeyUpdAnnContent ::= SEQUENCE { 2800 oldWithNew CMPCertificate, -- old pub signed with new priv 2801 newWithOld CMPCertificate, -- new pub signed with old priv 2802 newWithNew CMPCertificate -- new pub signed with new priv 2803 } 2805 CertAnnContent ::= CMPCertificate 2807 RevAnnContent ::= SEQUENCE { 2808 status PKIStatus, 2809 certId CertId, 2810 willBeRevokedAt GeneralizedTime, 2811 badSinceDate GeneralizedTime, 2812 crlDetails Extensions{{...}} OPTIONAL 2813 -- extra CRL details (e.g., crl number, reason, location, etc.) 2814 } 2816 CRLAnnContent ::= SEQUENCE OF CertificateList 2817 PKIConfirmContent ::= NULL 2819 NestedMessageContent ::= PKIMessages 2821 -- CertReqTemplateContent, AttributeTypeAndValue, 2822 -- ExpandedRegControlSet, id-regCtrl-altCertTemplate, 2823 -- AltCertTemplate, regCtrl-algId, id-regCtrl-algId, AlgIdCtrl, 2824 -- regCtrl-rsaKeyLen, id-regCtrl-rsaKeyLen, and RsaKeyLenCtrl 2825 -- were added in CMP Updates [RFCXXXX] 2827 CertReqTemplateContent ::= SEQUENCE { 2828 certTemplate CertTemplate, 2829 -- prefilled certTemplate structure elements 2830 -- The SubjectPublicKeyInfo field in the certTemplate MUST NOT 2831 -- be used. 2832 keySpec Controls OPTIONAL 2833 -- MAY be used to specify supported algorithms. 2834 -- Controls ::= SEQUENCE SIZE (1..MAX) OF AttributeTypeAndValue 2835 -- as specified in CRMF (RFC4211) 2836 } 2838 AttributeTypeAndValue ::= SingleAttribute{{ ... }} 2840 ExpandedRegControlSet ATTRIBUTE ::= { RegControlSet | 2841 regCtrl-altCertTemplate | regCtrl-algId | regCtrl-rsaKeyLen, ... } 2843 regCtrl-altCertTemplate ATTRIBUTE ::= 2844 { TYPE AltCertTemplate IDENTIFIED BY id-regCtrl-altCertTemplate } 2846 id-regCtrl-altCertTemplate OBJECT IDENTIFIER ::= { id-regCtrl 7 } 2848 AltCertTemplate ::= AttributeTypeAndValue 2849 -- specifies a template for a certificate other than an X.509v3 2850 -- public-key certificate 2852 regCtrl-algId ATTRIBUTE ::= 2853 { TYPE AlgIdCtrl IDENTIFIED BY id-regCtrl-algId } 2855 id-regCtrl-algId OBJECT IDENTIFIER ::= { id-regCtrl 11 } 2857 AlgIdCtrl ::= AlgorithmIdentifier{ALGORITHM, {...}} 2858 -- SHALL be used to specify supported algorithms other than RSA 2860 regCtrl-rsaKeyLen ATTRIBUTE ::= 2861 { TYPE RsaKeyLenCtrl IDENTIFIED BY id-regCtrl-rsaKeyLen } 2863 id-regCtrl-rsaKeyLen OBJECT IDENTIFIER ::= { id-regCtrl 12 } 2865 RsaKeyLenCtrl ::= INTEGER (1..MAX) 2866 -- SHALL be used to specify supported RSA key lengths 2868 -- RootCaKeyUpdateContent, CRLSource, and CRLStatus were added in 2869 -- CMP Updates [RFCXXXX] 2871 RootCaKeyUpdateContent ::= SEQUENCE { 2872 newWithNew CMPCertificate, 2873 -- new root CA certificate 2874 newWithOld [0] CMPCertificate OPTIONAL, 2875 -- X.509 certificate containing the new public root CA key 2876 -- signed with the old private root CA key 2877 oldWithNew [1] CMPCertificate OPTIONAL 2878 -- X.509 certificate containing the old public root CA key 2879 -- signed with the new private root CA key 2880 } 2882 CRLSource ::= CHOICE { 2883 dpn [0] DistributionPointName, 2884 issuer [1] GeneralNames } 2886 CRLStatus ::= SEQUENCE { 2887 source CRLSource, 2888 thisUpdate Time OPTIONAL } 2890 INFO-TYPE-AND-VALUE ::= TYPE-IDENTIFIER 2892 InfoTypeAndValue ::= SEQUENCE { 2893 infoType INFO-TYPE-AND-VALUE. 2894 &id({SupportedInfoSet}), 2895 infoValue INFO-TYPE-AND-VALUE. 2896 &Type({SupportedInfoSet}{@infoType}) } 2898 SupportedInfoSet INFO-TYPE-AND-VALUE ::= { ... } 2900 -- Example InfoTypeAndValue contents include, but are not limited 2901 -- to, the following (uncomment in this ASN.1 module and use as 2902 -- appropriate for a given environment): 2903 -- 2904 -- id-it-caProtEncCert OBJECT IDENTIFIER ::= {id-it 1} 2905 -- CAProtEncCertValue ::= CMPCertificate 2906 -- id-it-signKeyPairTypes OBJECT IDENTIFIER ::= {id-it 2} 2907 -- SignKeyPairTypesValue ::= SEQUENCE SIZE (1..MAX) OF 2908 -- AlgorithmIdentifier{{...}} 2909 -- id-it-encKeyPairTypes OBJECT IDENTIFIER ::= {id-it 3} 2910 -- EncKeyPairTypesValue ::= SEQUENCE SIZE (1..MAX) OF 2911 -- AlgorithmIdentifier{{...}} 2912 -- id-it-preferredSymmAlg OBJECT IDENTIFIER ::= {id-it 4} 2913 -- PreferredSymmAlgValue ::= AlgorithmIdentifier{{...}} 2914 -- id-it-caKeyUpdateInfo OBJECT IDENTIFIER ::= {id-it 5} 2915 -- CAKeyUpdateInfoValue ::= CAKeyUpdAnnContent 2916 -- id-it-currentCRL OBJECT IDENTIFIER ::= {id-it 6} 2917 -- CurrentCRLValue ::= CertificateList 2918 -- id-it-unsupportedOIDs OBJECT IDENTIFIER ::= {id-it 7} 2919 -- UnsupportedOIDsValue ::= SEQUENCE SIZE (1..MAX) OF 2920 -- OBJECT IDENTIFIER 2921 -- id-it-keyPairParamReq OBJECT IDENTIFIER ::= {id-it 10} 2922 -- KeyPairParamReqValue ::= OBJECT IDENTIFIER 2923 -- id-it-keyPairParamRep OBJECT IDENTIFIER ::= {id-it 11} 2924 -- KeyPairParamRepValue ::= AlgorithmIdentifier{{...}} 2925 -- id-it-revPassphrase OBJECT IDENTIFIER ::= {id-it 12} 2926 -- RevPassphraseValue ::= EncryptedKey 2927 -- - Changed from Encrypted Value to EncryptedKey as a CHOICE 2928 -- - of EncryptedValue and EnvelopedData due to the changes 2929 -- - made in CMP Updates [RFCXXXX] 2930 -- - Using the choice EncryptedValue is bit-compatible to 2931 -- - the syntax without this change 2932 -- id-it-implicitConfirm OBJECT IDENTIFIER ::= {id-it 13} 2933 -- ImplicitConfirmValue ::= NULL 2934 -- id-it-confirmWaitTime OBJECT IDENTIFIER ::= {id-it 14} 2935 -- ConfirmWaitTimeValue ::= GeneralizedTime 2936 -- id-it-origPKIMessage OBJECT IDENTIFIER ::= {id-it 15} 2937 -- OrigPKIMessageValue ::= PKIMessages 2938 -- id-it-suppLangTags OBJECT IDENTIFIER ::= {id-it 16} 2939 -- SuppLangTagsValue ::= SEQUENCE OF UTF8String 2940 -- id-it-caCerts OBJECT IDENTIFIER ::= {id-it 17} 2941 -- CaCertsValue ::= SEQUENCE SIZE (1..MAX) OF 2942 -- CMPCertificate 2943 -- - id-it-caCerts added in CMP Updates [RFCXXXX] 2944 -- id-it-rootCaKeyUpdate OBJECT IDENTIFIER ::= {id-it 18} 2945 -- RootCaKeyUpdateValue ::= RootCaKeyUpdateContent 2946 -- - id-it-rootCaKeyUpdate added in CMP Updates [RFCXXXX] 2947 -- id-it-certReqTemplate OBJECT IDENTIFIER ::= {id-it 19} 2948 -- CertReqTemplateValue ::= CertReqTemplateContent 2949 -- - id-it-certReqTemplate added in CMP Updates [RFCXXXX] 2950 -- id-it-rootCaCert OBJECT IDENTIFIER ::= {id-it 20} 2951 -- RootCaCertValue ::= CMPCertificate 2952 -- - id-it-rootCaCert added in CMP Updates [RFCXXXX] 2953 -- id-it-certProfile OBJECT IDENTIFIER ::= {id-it 21} 2954 -- CertProfileValue ::= SEQUENCE SIZE (1..MAX) OF 2955 -- UTF8String 2956 -- - id-it-certProfile added in CMP Updates [RFCXXXX] 2957 -- id-it-crlStatusList OBJECT IDENTIFIER ::= {id-it 22} 2958 -- CRLStatusListValue ::= SEQUENCE SIZE (1..MAX) OF 2959 -- CRLStatus 2960 -- - id-it-crlStatusList added in CMP Updates [RFCXXXX] 2961 -- id-it-crls OBJECT IDENTIFIER ::= {id-it 23} 2962 -- CRLsValue ::= SEQUENCE SIZE (1..MAX) OF 2963 -- CertificateList 2964 -- - id-it-crls added in CMP Updates [RFCXXXX] 2965 -- 2966 -- where 2967 -- 2968 -- id-pkix OBJECT IDENTIFIER ::= { 2969 -- iso(1) identified-organization(3) 2970 -- dod(6) internet(1) security(5) mechanisms(5) pkix(7)} 2971 -- and 2972 -- id-it OBJECT IDENTIFIER ::= {id-pkix 4} 2973 -- 2974 -- 2975 -- This construct MAY also be used to define new PKIX Certificate 2976 -- Management Protocol request and response messages, or general- 2977 -- purpose (e.g., announcement) messages for future needs or for 2978 -- specific environments. 2980 GenMsgContent ::= SEQUENCE OF InfoTypeAndValue 2982 -- May be sent by EE, RA, or CA (depending on message content). 2983 -- The OPTIONAL infoValue parameter of InfoTypeAndValue will 2984 -- typically be omitted for some of the examples given above. 2985 -- The receiver is free to ignore any contained OBJECT IDs that it 2986 -- does not recognize. If sent from EE to CA, the empty set 2987 -- indicates that the CA may send 2988 -- any/all information that it wishes. 2990 GenRepContent ::= SEQUENCE OF InfoTypeAndValue 2991 -- Receiver MAY ignore any contained OIDs that it does not 2992 -- recognize. 2994 ErrorMsgContent ::= SEQUENCE { 2995 pKIStatusInfo PKIStatusInfo, 2996 errorCode INTEGER OPTIONAL, 2997 -- implementation-specific error codes 2998 errorDetails PKIFreeText OPTIONAL 2999 -- implementation-specific error details 3000 } 3002 CertConfirmContent ::= SEQUENCE OF CertStatus 3004 CertStatus ::= SEQUENCE { 3005 certHash OCTET STRING, 3006 -- the hash of the certificate, using the same hash algorithm 3007 -- as is used to create and verify the certificate signature 3008 certReqId INTEGER, 3009 -- to match this confirmation with the corresponding req/rep 3010 statusInfo PKIStatusInfo OPTIONAL, 3011 hashAlg [0] AlgorithmIdentifier{DIGEST-ALGORITHM, {...}} OPTIONAL 3012 -- the hash algorithm to use for calculating certHash 3013 -- SHOULD NOT be used in all cases where the AlgorithmIdentifier 3014 -- of the certificate signature specifies a hash algorithm 3015 } 3017 PollReqContent ::= SEQUENCE OF SEQUENCE { 3018 certReqId INTEGER } 3020 PollRepContent ::= SEQUENCE OF SEQUENCE { 3021 certReqId INTEGER, 3022 checkAfter INTEGER, -- time in seconds 3023 reason PKIFreeText OPTIONAL } 3025 -- 3026 -- Extended Key Usage extension for PKI entities used in CMP 3027 -- operations, added due to the changes made in 3028 -- CMP Updates [RFCXXXX] 3029 -- The EKUs for the CA and RA are reused from CMC as defined in 3030 -- [RFC6402] 3031 -- 3033 -- id-kp-cmcCA OBJECT IDENTIFIER ::= { id-kp 27 } 3034 -- id-kp-cmcRA OBJECT IDENTIFIER ::= { id-kp 28 } 3035 id-kp-cmKGA OBJECT IDENTIFIER ::= { id-kp 32 } 3037 END 3039 Appendix B. History of Changes 3041 [RFC Editor: This appendix must be deleted in the final version of 3042 the document.] 3044 From version 21 -> 22: 3046 * Addressed comments from IESG discussion (see thread " Paul 3047 Wouters' Discuss on draft-ietf-lamps-cmp-updates-21: (with DISCUSS 3048 and COMMENT)") 3050 From version 20 -> 21: 3052 * Extended Section 1 based on feedback from the IESG telechat 3053 * Removed a redundant paragraph from the Abstract 3055 From version 19 -> 20: 3057 * Addressed comments reported after GEN AD review 3059 From version 18 -> 19: 3061 * Deleted the Comments on IANA ToDos and changed the decimals TBD1 3062 -> 22 and TBD2 -> 23 3063 * Updated Section 3.4 regarding ToDos updating the well-known URI 3064 registration 3066 From version 17 -> 18: 3068 * Addressed comments from AD Evaluation (see thread "AD Review of 3069 draft-ietf-lamps-cmp-updates-17") 3070 * Added Section 2.8 to clarify on the usage of GeneralizedTime (see 3071 thread "draft-ietf-lamps-cmp-updates: fractional seconds") 3073 * Updated Section 3.4 introducing the path segment 'p' to indicate 3074 the following arbitrary label according to the discussion during 3075 IETF 113 (see thread "/.well-known/brski reference to brski- 3076 registry") 3077 * Capitalized all headlines 3079 From version 16 -> 17: 3081 * Removed the pre-RFC5378 work disclaimer after the RFC 4210 authors 3082 granted BCP78 rights to the IETF Trust 3083 * Removed note on usage of language tags in UTF8String due to 3084 reference to references to outdated/historic RFCs 3085 * Resolved some nits reported by I-D nit checker tool 3087 From version 15 -> 16: 3089 * Updated IPR disclaimer 3091 From version 14 -> 15: 3093 * Updated Section 2.16 clarifying the usage of CRLSource (see thread 3094 "CRL update retrieval - WG Last Call for draft-ietf-lamps-cmp- 3095 updates-14 and draft-ietf-lamps-lightweight-cmp-profile-08") 3096 * Updated Section 2.22 adding further references regarding random 3097 number generation (see thread "CMP draft WGLC: measuring entropy, 3098 CA certificates") 3099 * Fixed some nits 3101 From version 13 -> 14: 3103 * Extended id-it-caCerts support message to allow transporting to- 3104 be-trusted root CA certificates; added respective security 3105 consideration (see thread "Generalizing the CMP "Get CA 3106 certificates" use case") 3107 * Rolled back changes made in previous version regarding root CA 3108 update to avoid registration of new OIDs. Yet we sticked to using 3109 id-it-rootCaCert in the genm body instead its headers' generalInfo 3110 field and removed the ToDos and TBDs on re-arranging id-it OIDs 3111 (see thread "Allocation of OIDs for CRL update retrieval (draft- 3112 ietf-lamps-cmp-updates-13)") 3114 From version 12 -> 13: 3116 * Added John Gray to the list of authors due to fruitful discussion 3117 and important proposals 3118 * Fixed errata no. 2615, 2616, 3949, 4078, and 5201 on RFC 4210 3119 * Added reference on RFC 8933 regarding CMS signedAttrs to 3120 Section 2.7 3122 * Updated Section 2.9 and the ASN.1 modules moving the position of 3123 the hashAlg field (see thread "[CMP Updates] position of hashAlg 3124 in certStatus") 3125 * Changed "rootCaCert" from generalInfo to genm body and generalized 3126 to "oldTrustAnchor", renaming "rootCaKeyUpdate" to 3127 "trustAnchorUpdate" in Sections 2.14, A.1, and A.2, removing 3128 former Section 2.4 3129 * Added genm use case "CRL update retrieval" in Section 2.16, A.1, 3130 and A.2. (see thread "[CMP Updates] Requesting a current CRL") 3131 * Updated Section 2.18 and 2.17 to support polling for all kinds of 3132 CMP request messages initiated by an error message with status 3133 "waiting" as initially discussed at IETF 111 3134 * Updated Sections 2.19 and 2.20 regarding version handling 3135 * Added further OIDs and a TBD regarding reordering of the OIDs 3136 * Added Sections 2.21 to 2.23 with new security considerations and 3137 updated Section 5 accordingly 3138 * Added a ToDo regarding OID registration, renaming, and re-ordering 3139 * Added Section 3.1 updating the introduction of RFC 6712 3140 * Fixed some nits in the ASN.1 modules (see thread "draft-ietf- 3141 lamps-cmp-updates-12: Comments on A.1. 1988 ASN.1 Module" and 3142 "draft-ietf-lamps-cmp-updates-12: Comments on A.2. 2002 ASN.1 3143 Module") 3144 * Replaced the term "transport" by "transfer" where appropriate to 3145 prevent confusion 3146 * Minor editorial changes 3148 From version 11 -> 12: 3150 * Extended Section 2.5 and the ASN.1 modules in Appendix A to allow 3151 a sequence of certificate profiles in CertProfileValue (see thread 3152 "id-it-CertProfile in draft-ietf-lamps-cmp-updates") 3154 From version 10 -> 11: 3156 * Add Section 2.10 to add an additional hashAlg field to the 3157 CertStatus type to support certificates signed with a signature 3158 algorithm not explicitly indicating a hash algorithm in the 3159 AlgorithmIdentifier (see thread "Hash algorithm to us for 3160 calculating certHash") 3161 * Added newly registered OIDs and temporarily registered URI suffix 3162 * Exchanged the import of CertificationRequest from RFC 2986 to the 3163 definition from RFC 6402 Appendix A.1 (see thread "CMP Update of 3164 CertificationRequest") 3165 * Corrected the definition of LocalKeyIdValue in Appendix A.1 3166 * Updated new RFC numbers for draft-lamps-crmf-update-algs 3168 From version 9 -> 10: 3170 * Added 1988 ASN.1 syntax for localKeyId attribute to Appendix A.1 3172 From version 08 -> 09: 3174 * Deleted specific definition of CMP CA and CMP RA in Section 2.2 3175 and only reference RFC 6402 for definition of id-kp-cmcCA and id- 3176 kp-cmcRA to resolve the ToDo below based on feedback of Tomas 3177 Gustavsson 3178 * Added Section 2.4. and 2.5 to define id-it-rootCaCert and id-it- 3179 certProfile to be used in Section 2.14 and 2.15 3180 * Added reference to CMP Algorithms in Section 2.8 3181 * Extended Section 2.14 to explicitly indicate the root CA an update 3182 is requested for by using id-it-rootCaCert and changing the ASN.1 3183 syntax to require providing the newWithOld certificate in the 3184 response message 3185 * Extended Section 2.15 to explicitly indicate the certificate 3186 request template by using id-it-certProfile and on further details 3187 of the newly introduced controls 3188 * Deleted the table on id-kp-cmcCA and id-kp-cmcRA and adding id-it- 3189 rootCaCert and id-it-certProfile in Section 2.19 3190 * Adding the definition of id-it-rootCaCert and id-it-certProfile in 3191 both ASN.1 modules in Appendix A 3192 * Minor editorial changes reflecting the above changes 3194 From version 07 -> 08: 3196 * Added a ToDo to Section 2.2 to reflect a current discussion on the 3197 need of an additional CMP-CA role and EKU and differentiation from 3198 CMP-RA 3199 * Added ToDos to Section 2.12 and 2.13 3201 From version 06 -> 07: 3203 * Added David von Oheimb as co-author 3204 * Changed to XML V3 3205 * Added Section 2.3 to enable a CMP protocol version number 3 in the 3206 PKIHeader for cases where EnvelopedData is to be used (see thread 3207 "Mail regarding draft-ietf-lamps-cmp-updates"). 3208 * Added Section 2.4 to refer to draft-ietf-lamps-crmf-update-algs 3209 for the update of id-PasswordBasedMac for PKI message protection 3210 using passwords or shared secrets. 3211 * Updated Section 2.6 to introduce the protocol version number 3 to 3212 properly indicate support of EnvelopedData instead of 3213 EncryptedValue in case a transaction requires use of EnvelopedData 3214 (see thread "Mail regarding draft-ietf-lamps-cmp-updates"). 3215 * Update Section 2.14 to make the minimal changes to the respective 3216 section in CMP more explicit. 3218 * Added Sections 2.15 and 2.16 to address the new cmp2021 protocol 3219 version in Section 7 Version Negotiation. 3220 * Updated Section 2.17 to add new OIDs for id-regCtrl-algId and id- 3221 regCtrl-rsaKeyLen for registration at IANA. 3222 * Added Section 2.20 to update the general rules of interpretation 3223 in Appendix D.1 regarding the new cmp2021 version. 3224 * Added Section 2.21 to update the Algorithm Use Profile in 3225 Appendix D.2 with the reference to the new CMP Algorithms document 3226 as decided at IETF 108. 3227 * Updates Section 3.1 to delete the description of a discovery 3228 mechanism as decided at IETF 108. 3229 * Various changes and corrections in wording. 3231 From version 05 -> 06: 3233 * Added the update of Appendix D.2 with the reference to the new CMP 3234 Algorithms document as decided in IETF 108 3235 * Updated the IANA considerations to register new OIDs for id- 3236 regCtrl-algId and d-regCtrl-rsaKeyLen. 3237 * Minor changes and corrections 3239 From version 04 -> 05: 3241 * Added Section 2.11 and Section 2.12 to clarify the usage of these 3242 general messages types with EC curves (see thread 3243 "AlgorithmIdentifier parameters NULL value - Re: InfoTypeAndValue 3244 in CMP headers") 3245 * Split former section 2.7 on adding 'CA Certificates', 'Root CA 3246 Certificates Update', and 'Certificate Request Template' in three 3247 separate sections for easier readability 3248 * Changed in Section 2.15 the ASN.1 syntax of CertReqTemplateValue 3249 from using rsaKeyLen to usage of controls as specified in CRMF 3250 Section 6 [RFC4211] (see thread "dtaft-ietf-lamps-cmp-updates and 3251 rsaKeyLen") 3252 * Updated the IANA considerations in Section 2.25 to introduce new 3253 OID for id-regCtrl-algId and id-regCtrl-rsaKeyLen (see thread 3254 "dtaft-ietf-lamps-cmp-updates and rsaKeyLen") 3255 * Updated the IANA Considerations in and the Appendixes to introduce 3256 new OID for the updates ASN.1 modules (see thread "I-D Action: 3257 draft-ietf-lamps-cmp-updates-04.txt") 3258 * Removed EncryptedValue from and added Controls to the list of 3259 types imported from CRMF [RFC4211] in ASN.1 modules (see thread 3260 "draft-ietf-lamps-cmp-updates and the ASN.1 modules") 3261 * Moved declaration of Rand out of the comment in ASN.1 modules (see 3262 thread "draft-ietf-lamps-cmp-updates and the ASN.1 modules") 3263 * Minor changes and corrections 3265 From version 03 -> 04: 3267 * Added Section 2.7 to introduce three new id-it IDs for uses in 3268 general messages as discussed (see thread "draft-ietf-lamps-cmp- 3269 updates add section to introduce id-it-caCerts, id-it- 3270 rootCaKeyUpdate, and id-it-certReqTemplate") 3271 * Added the new id-it IDs and the /.well-known/cmp to the IANA 3272 Considerations of [RFC4210] in Section 2.9 3273 * Updated the IANA Considerations of [RFC4210] in Section 2.26 3274 * Some changes in wording on Section 3 due to review comments from 3275 Martin Peylo 3277 From version 02 -> 03: 3279 * Added a ToDo on aligning with the CMP Algorithms draft that will 3280 be set up as decided in IETF 108 3281 * Updated section on Encrypted Values in Section 2.7 to add the 3282 AsymmetricKey Package structure to transport a newly generated 3283 private key as decided in IETF 108 3284 * Updated the IANA Considerations of [RFC4210] in Section 2.26 3285 * Added the pre-registered OID in Section 2.26 and the ASN.1 module 3286 * Added Section 3 to document the changes to RFC 6712 [RFC6712] 3287 regarding URI discovery and using the path-prefix of '/.well- 3288 known/' as discussed in IETF 108 3289 * Updated the IANA Considerations section 3290 * Added a complete updated ASN.1 module in 1988 syntax to update 3291 Appendix F of [RFC4210] and a complete updated ASN.1 module in 3292 2002 syntax to update Section 9 of [RFC5912] 3293 * Minor changes in wording 3295 From version 01 -> 02: 3297 * Updated section on EKU OIDs in Section 2.2 as decided in IETF 107 3298 * Changed from symmetric key-encryption to password-based key 3299 management technique in Section 2.7 as discussed with Russ and Jim 3300 on the mailing list 3301 * Defined the attribute containing the key identifier for the 3302 revocation passphrase in Section 2.26 3303 * Moved the change history to the Appendix 3305 From version 00 -> 01: 3307 * Minor changes in wording 3309 From draft-brockhaus-lamps-cmp-updates-03 -> draft-ietf-lamps-cmp- 3310 updates-00: 3312 * Changes required to reflect WG adoption 3314 From version 02 -> 03: 3316 * Added some clarification in Section 2.1 3318 From version 01 -> 02: 3320 * Added clarification to section on multiple protection 3321 * Added clarification on new EKUs after some exchange with Tomas 3322 Gustavsson 3323 * Reused OIDs from RFC 6402 [RFC6402] as suggested by Sean Turner at 3324 IETF 106 3325 * Added clarification on the field containing the key identifier for 3326 a revocation passphrase 3327 * Minor changes in wording 3329 From version 00 -> 01: 3331 * Added a section describing the new extended key usages 3332 * Completed the section on changes to the specification of encrypted 3333 values 3334 * Added a section on clarification to Appendix D.4 3335 * Minor generalization in RFC 4210 [RFC4210] Sections 5.1.3.4 and 3336 5.3.22 3337 * Minor changes in wording 3339 Authors' Addresses 3341 Hendrik Brockhaus (editor) 3342 Siemens 3343 Werner-von-Siemens-Strasse 1 3344 80333 Munich 3345 Germany 3346 Email: hendrik.brockhaus@siemens.com 3347 URI: https://www.siemens.com 3349 David von Oheimb 3350 Siemens 3351 Werner-von-Siemens-Strasse 1 3352 80333 Munich 3353 Germany 3354 Email: david.von.oheimb@siemens.com 3355 URI: https://www.siemens.com 3357 John Gray 3358 Entrust 3359 1187 Park Place 3360 Minneapolis, MN 55379 3361 United States of America 3362 Email: john.gray@entrust.com 3363 URI: https://www.entrust.com