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