idnits 2.17.1 draft-ietf-lamps-cmp-updates-15.txt: -(1583): Line appears to be too long, but this could be caused by non-ascii characters in UTF-8 encoding 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: ---------------------------------------------------------------------------- == There is 1 instance of lines with non-ascii characters in the document. 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 (17 December 2021) is 860 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 2910 -- Looks like a reference, but probably isn't: '1' on line 2783 -- Looks like a reference, but probably isn't: '2' on line 2674 -- Looks like a reference, but probably isn't: '3' on line 2428 -- Looks like a reference, but probably isn't: '4' on line 2429 -- Looks like a reference, but probably isn't: '5' on line 2430 -- Looks like a reference, but probably isn't: '6' on line 2431 -- Looks like a reference, but probably isn't: '7' on line 2432 -- Looks like a reference, but probably isn't: '8' on line 2433 == Missing Reference: 'CRMF' is mentioned on line 2004, but not defined == Missing Reference: 'I-D.ietf-lamps-cmp-updates' is mentioned on line 1372, but not defined == Missing Reference: 'RFC3629' is mentioned on line 2419, but not defined == Missing Reference: 'RFC3066' is mentioned on line 2420, but not defined ** Obsolete undefined reference: RFC 3066 (Obsoleted by RFC 4646, RFC 4647) == Missing Reference: 'RFC2482' is mentioned on line 2422, but not defined ** Obsolete undefined reference: RFC 2482 (Obsoleted by RFC 6082) == Missing Reference: 'PKCS10' is mentioned on line 2429, but not defined -- Looks like a reference, but probably isn't: '9' on line 2434 -- Looks like a reference, but probably isn't: '10' on line 2435 -- Looks like a reference, but probably isn't: '11' on line 2436 -- Looks like a reference, but probably isn't: '12' on line 2437 -- Looks like a reference, but probably isn't: '13' on line 2438 -- Looks like a reference, but probably isn't: '14' on line 2439 -- Looks like a reference, but probably isn't: '15' on line 2440 -- Looks like a reference, but probably isn't: '16' on line 2441 -- Looks like a reference, but probably isn't: '17' on line 2442 -- Looks like a reference, but probably isn't: '18' on line 2443 -- Looks like a reference, but probably isn't: '19' on line 2444 -- Looks like a reference, but probably isn't: '20' on line 2445 -- Looks like a reference, but probably isn't: '21' on line 2446 -- Looks like a reference, but probably isn't: '22' on line 2447 -- Looks like a reference, but probably isn't: '23' on line 2448 -- Looks like a reference, but probably isn't: '24' on line 2449 -- Looks like a reference, but probably isn't: '25' on line 2450 -- Looks like a reference, but probably isn't: '26' on line 2451 == Missing Reference: 'PKCS11' is mentioned on line 2485, but not defined == Missing Reference: 'RFC2104' is mentioned on line 2486, but not defined == Missing Reference: 'RFC2202' is mentioned on line 2486, but not defined == Missing Reference: 'I-D.ietf-lamps-crmf-update-algs' is mentioned on line 3058, but not defined == Outdated reference: A later version (-15) exists of draft-ietf-lamps-cmp-algorithms-08 ** 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 5912 ** Downref: Normative reference to an Informational RFC: RFC 7299 == Outdated reference: A later version (-21) exists of draft-ietf-lamps-lightweight-cmp-profile-08 Summary: 7 errors (**), 0 flaws (~~), 15 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: 20 June 2022 Entrust 7 17 December 2021 9 Certificate Management Protocol (CMP) Updates 10 draft-ietf-lamps-cmp-updates-15 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' HTTP 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 20 June 2022. 50 Copyright Notice 52 Copyright (c) 2021 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. Update Section 5.3.4. - Certification Response . . . . . 11 78 2.9. Update Section 5.3.18. - Certificate Confirmation 79 Content . . . . . . . . . . . . . . . . . . . . . . . . 12 80 2.10. Update Section 5.3.19.2. - Signing Key Pair Types . . . . 13 81 2.11. Update Section 5.3.19.3. - Encryption/Key Agreement Key 82 Pair Types . . . . . . . . . . . . . . . . . . . . . . . 13 83 2.12. Replace Section 5.3.19.9. - Revocation Passphrase . . . . 13 84 2.13. New Section 5.3.19.14 - CA Certificates . . . . . . . . . 14 85 2.14. New Section 5.3.19.15 - Root CA Certificate Update . . . 14 86 2.15. New Section 5.3.19.16 - Certificate Request Template . . 15 87 2.16. New Section 5.3.19.17 - CRL update retrieval . . . . . . 16 88 2.17. Update Section 5.3.21 - Error Message Content . . . . . . 17 89 2.18. Replace Section 5.3.22 - Polling Request and Response . . 18 90 2.19. Update Section 7 - Version Negotiation . . . . . . . . . 22 91 2.20. Update Section 7.1.1. - Clients Talking to RFC 2510 92 Servers . . . . . . . . . . . . . . . . . . . . . . . . 24 93 2.21. Add Section 8.4 - Private keys for certificate signing and 94 CMP message protection . . . . . . . . . . . . . . . . . 24 95 2.22. Add Section 8.5 - Entropy of random numbers, key pairs, and 96 shared secret information . . . . . . . . . . . . . . . 24 98 2.23. Add Section 8.6 - Trust anchor provisioning using CMP 99 messages . . . . . . . . . . . . . . . . . . . . . . . . 25 100 2.24. Update Section 9 - IANA Considerations . . . . . . . . . 26 101 2.25. Update Appendix B - The Use of Revocation Passphrase . . 28 102 2.26. Update Appendix C - Request Message Behavioral 103 Clarifications . . . . . . . . . . . . . . . . . . . . . 28 104 2.27. Update Appendix D.1. - General Rules for Interpretation of 105 These Profiles . . . . . . . . . . . . . . . . . . . . . 29 106 2.28. Update Appendix D.2. - Algorithm Use Profile . . . . . . 30 107 2.29. Update Appendix D.4. - Initial Registration/Certification 108 (Basic Authenticated Scheme) . . . . . . . . . . . . . . 30 109 3. Updates to RFC 6712 - HTTP Transfer for the Certificate 110 Management Protocol (CMP) . . . . . . . . . . . . . . . . 30 111 3.1. Update Section 1. - Introduction . . . . . . . . . . . . 30 112 3.2. New Section 1.1. - Changes since RFC 6712 . . . . . . . . 31 113 3.3. Replace Section 3.6. - HTTP Request-URI . . . . . . . . . 31 114 3.4. Update Section 6. - IANA Considerations . . . . . . . . . 32 115 4. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 32 116 5. Security Considerations . . . . . . . . . . . . . . . . . . . 33 117 6. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 33 118 7. References . . . . . . . . . . . . . . . . . . . . . . . . . 33 119 7.1. Normative References . . . . . . . . . . . . . . . . . . 33 120 7.2. Informative References . . . . . . . . . . . . . . . . . 35 121 Appendix A. ASN.1 Modules . . . . . . . . . . . . . . . . . . . 36 122 A.1. 1988 ASN.1 Module . . . . . . . . . . . . . . . . . . . . 36 123 A.2. 2002 ASN.1 Module . . . . . . . . . . . . . . . . . . . . 50 124 Appendix B. History of changes . . . . . . . . . . . . . . . . . 63 125 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 68 127 1. Introduction 129 While using CMP [RFC4210] in industrial and IoT environments and 130 developing the Lightweight CMP Profile 131 [I-D.ietf-lamps-lightweight-cmp-profile] some limitations were 132 identified in the original CMP specification. This document updates 133 RFC 4210 [RFC4210] and RFC 6712 [RFC6712] to overcome these 134 limitations. 136 Among others, this document improves the crypto agility of CMP, which 137 means to be flexible to react on future advances in cryptography. 139 This document also introduces new extended key usages to identify CMP 140 endpoints on registration and certification authorities. 142 1.1. Convention and Terminology 144 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 145 "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and 146 "OPTIONAL" in this document are to be interpreted as described in BCP 147 14 [RFC2119] [RFC8174] when, and only when, they appear in all 148 capitals, as shown here. 150 Technical terminology is used in conformance with RFC 4210 [RFC4210], 151 RFC 4211 [RFC4211], and RFC 5280 [RFC5280]. The following key words 152 are used: 154 CA: Certification authority, which issues certificates. 156 RA: Registration authority, an optional system component to which a 157 CA delegates certificate management functions such as 158 authorization checks. 160 KGA: Key generation authority, which generates key pairs on behalf 161 of an EE. The KGA could be co-located with an RA or a CA. 163 EE: End entity, a user, device, or service that holds a PKI 164 certificate. An identifier for the EE is given as its subject 165 of the certificate. 167 2. Updates to RFC 4210 - Certificate Management Protocol (CMP) 169 2.1. New Section 1.1. - Changes since RFC 4210 171 The following subsection describes feature updates to RFC 4210 172 [RFC4210]. They are always related to the base specification. Hence 173 references to the original sections in RFC 4210 [RFC4210] are used 174 whenever possible. 176 Insert this section at the end of the current Section 1: 178 1.1. Changes since RFC 4210 180 The following updates are made in [thisRFC]: 182 * Add new extended key usages for various CMP server types, e.g., 183 registration authority and certification authority, to express the 184 authorization of the entity identified in the certificate 185 containing the respective extended key usage extension to act as 186 the indicated PKI management entity. 188 * Extend the description of multiple protection to cover additional 189 use cases, e.g., batch processing of messages. 191 * Offering EnvelopedData as the preferred choice next to 192 EncryptedValue to better support crypto agility in CMP. Note that 193 according to RFC 4211 [RFC4211] section 2.1. point 9 the use of 194 the EncryptedValue structure has been deprecated in favor of the 195 EnvelopedData structure. RFC 4211 [RFC4211] offers the 196 EncryptedKey structure, a choice of EncryptedValue and 197 EnvelopedData for migration to EnvelopedData. For reasons of 198 completeness and consistency the type EncryptedValue has been 199 exchanged in all occurrences in RFC 4210 [RFC4210]. This includes 200 the protection of centrally generated private keys, encryption of 201 certificates, and protection of revocation passphrases. To 202 properly differentiate the support of EnvelopedData instead of 203 EncryptedValue, the CMP version 3 is introduced in case a 204 transaction is supposed to use EnvelopedData. 206 * Offering an optional hashAlg field in CertStatus supporting 207 confirmation of certificates signed with signature algorithms, 208 e.g., EdDSA, not directly indicating a specific hash algorithm to 209 use to compute the certHash. 211 * Adding new general message types to request CA certificates, a 212 root CA update, a certificate request template, or a CRL update. 214 * Extend the usage of polling to p10cr, certConf, rr, genm, and 215 error messages. 217 * Delete the mandatory algorithm profile in RFC 4210 Appendix D.2 218 [RFC4210] and refer to CMP Algorithms Section 7 219 [I-D.ietf-lamps-cmp-algorithms]. 221 2.2. New Section 4.5 - Extended Key Usage 223 The following subsection introduces a new extended key usage for CMP 224 servers authorized to centrally generate key pairs on behalf of end 225 entities. 227 Insert this section at the end of the current Section 4: 229 4.5. Extended Key Usage 231 The Extended Key Usage (EKU) extension indicates the purposes for 232 which the certified key pair may be used. It therefore restricts the 233 use of a certificate to specific applications. 235 A CA may want to delegate parts of its duties to other PKI management 236 entities. The mechanism to prove this delegation explained in this 237 section offers an automatic way of checking the authorization of such 238 delegation. Such delegation MAY also be expressed by other means, 239 e.g., explicit configuration. 241 To offer automatic validation for the delegation of a role by a CA to 242 another entity, the certificates used for CMP message protection or 243 signed data for central key generation MUST be issued by the 244 delegating CA and MUST contain the respective EKUs. This proves the 245 authorization of this entity by the delegating CA to act in the given 246 role as described below. 248 The OIDs to be used for these EKUs are: 250 id-kp-cmcCA OBJECT IDENTIFIER ::= { 251 iso(1) identified-organization(3) dod(6) internet(1) 252 security(5) mechanisms(5) pkix(7) kp(3) 27 } 254 id-kp-cmcRA OBJECT IDENTIFIER ::= { 255 iso(1) identified-organization(3) dod(6) internet(1) 256 security(5) mechanisms(5) pkix(7) kp(3) 28 } 258 id-kp-cmKGA OBJECT IDENTIFIER ::= { 259 iso(1) identified-organization(3) dod(6) internet(1) 260 security(5) mechanisms(5) pkix(7) kp(3) 32 } 262 Note: RFC 6402 section 2.10 [RFC6402] specifies OIDs for a CMC CA and 263 a CMC RA. As the functionality of a CA and RA is not specific to 264 using CMC or CMP as the certificate management protocol, these OIDs 265 MAY be re-used. 267 The meaning of the id-kp-cmKGA EKU is as follows: 269 CMP KGA: CMP Key Generation Authorities are identified by the id-kp- 270 cmKGA extended key usage. The CMP KGA knows the private 271 key it generated on behalf of the end entity. This is a 272 very sensitive service and therefore needs specific 273 authorization. This authorization is with the CA 274 certificate itself. Alternatively, the CA MAY delegate the 275 authorization by placing the id-kp-cmKGA extended key usage 276 in the certificate used to authenticate the origin of the 277 generated private key or the delegation MAY be determined 278 through local configuration of the end entity. 280 Note: In device PKIs, especially those issuing IDevID certificates 281 IEEE 802.1AR Section 8.5 [IEEE.802.1AR_2018], CA certificates may 282 have very long validity (including the GeneralizedTime value 283 99991231235959Z to indicate a not well-defined expiration date as 284 specified in IEEE 802.1AR Section 8.5 [IEEE.802.1AR_2018] and 285 RFC 5280 Section 4.1.2.5 [RFC5280]). Such validity periods SHOULD 286 NOT be used for protection of CMP messages and key generation. 287 Certificates containing one of the above EKUs SHOULD NOT use 288 indefinite expiration date. 290 2.3. Update Section 5.1.1. - PKI Message Header 292 Section 5.1.1 of RFC 4210 [RFC4210] describes the PKI message header. 293 This document introduces the new version 3 indicating support of 294 EnvelopedData as specified in Section 2.7. 296 Replace the ASN.1 Syntax of PKIHeader and the subsequent description 297 of pvno with the following text: 299 PKIHeader ::= SEQUENCE { 300 pvno INTEGER { cmp1999(1), cmp2000(2), 301 cmp2021(3) }, 302 sender GeneralName, 303 recipient GeneralName, 304 messageTime [0] GeneralizedTime OPTIONAL, 305 protectionAlg [1] AlgorithmIdentifier{ALGORITHM, {...}} 306 OPTIONAL, 307 senderKID [2] KeyIdentifier OPTIONAL, 308 recipKID [3] KeyIdentifier OPTIONAL, 309 transactionID [4] OCTET STRING OPTIONAL, 310 senderNonce [5] OCTET STRING OPTIONAL, 311 recipNonce [6] OCTET STRING OPTIONAL, 312 freeText [7] PKIFreeText OPTIONAL, 313 generalInfo [8] SEQUENCE SIZE (1..MAX) OF 314 InfoTypeAndValue OPTIONAL 315 } 317 PKIFreeText ::= SEQUENCE SIZE (1..MAX) OF UTF8String 319 The usage of pvno values is described in Section 7. 321 2.4. New Section 5.1.1.3. - CertProfile 323 Section 5.1.1 of RFC 4210 [RFC4210] defines the PKIHeader and id-it 324 OIDs to be used in the generalInfo field. This section introduces 325 id-it-certProfile. 327 Insert this section after Section 5.1.1.2: 329 5.1.1.3. CertProfile 330 This is used by the EE to indicate specific certificate profiles, 331 e.g., when requesting a new certificate or a certificate request 332 template, see Section 5.3.19.16. 334 id-it-certProfile OBJECT IDENTIFIER ::= {id-it 21} 335 CertProfileValue ::= SEQUENCE SIZE (1..MAX) OF UTF8String 337 When used in an ir/cr/kur/genm, the value MUST NOT contain more 338 elements than the number of CertReqMsg or InfoTypeAndValue elements 339 and the certificate profile names refer to the elements in the given 340 order. 342 When used in a p10cr, the value MUST NOT contain multiple certificate 343 profile names. 345 2.5. Update Section 5.1.3.1. - Shared Secret Information 347 Section 5.1.3.1 of RFC 4210 [RFC4210] describes the MAC based 348 protection of a PKIMessage using the algorithm id-PasswordBasedMac. 350 Replace the first paragraph with the following text: 352 In this case, the sender and recipient share secret information with 353 sufficient entropy (established via out-of-band means or from a 354 previous PKI management operation). PKIProtection will contain a MAC 355 value and the protectionAlg MAY be one of the options described in 356 CMP Algorithms [I-D.ietf-lamps-cmp-algorithms]. The PasswordBasedMac 357 is specified as follows (see also [RFC4211] and [RFC9045]): 359 Replace the last paragraph with the following text (Note: This fixes 360 Errata ID 2616): 362 Note: It is RECOMMENDED that the fields of PBMParameter remain 363 constant throughout the messages of a single transaction (e.g., 364 ir/ip/certConf/pkiConf) to reduce the overhead associated with 365 PasswordBasedMac computation. 367 2.6. Replace Section 5.1.3.4 - Multiple Protection 369 Section 5.1.3.4 of RFC 4210 [RFC4210] describes the nested message. 370 This document enables using nested messages also for batch-delivery 371 transport of PKI messages between PKI management entities and with 372 mixed body types. 374 Replace the text of the section with the following text: 376 5.1.3.4. Multiple Protection 377 When receiving a protected PKI message, a PKI management entity such 378 as an RA MAY forward that message adding its own protection (which 379 MAY be a MAC or a signature, depending on the information and 380 certificates shared between the RA and the CA). Moreover, multiple 381 PKI messages MAY be aggregated. There are several use cases for such 382 messages. 384 * The RA confirms having validated and authorized a message and 385 forwards the original message unchanged. 387 * The RA modifies the message(s) in some way (e.g., adds or modifies 388 particular field values or add new extensions) before forwarding 389 them, then it MAY create its own desired PKIBody. If the changes 390 made by the RA to PKIMessage break the POP of a certificate 391 request, the RA MUST set the POP RAVerified. It MAY include the 392 original PKIMessage from the EE in the generalInfo field of 393 PKIHeader of a nested message (to accommodate, for example, cases 394 in which the CA wishes to check POP or other information on the 395 original EE message). The infoType to be used in this situation 396 is {id-it 15} (see Section 5.3.19 for the value of id-it) and the 397 infoValue is PKIMessages (contents MUST be in the same order as 398 the message in PKIBody). 400 * The RA collects several messages that are to be forwarded in the 401 same direction and forwards them in a batch. In communication to 402 the CA request messages and in communication from the CA response 403 or announcement messages will be collected. This can for instance 404 be used when bridging an off-line connection between two PKI 405 management entities. 407 These use cases are accomplished by nesting the messages within a new 408 PKI message. The structure used is as follows: 410 NestedMessageContent ::= PKIMessages 412 2.7. Replace Section 5.2.2. - Encrypted Values 414 Section 5.2.2 of RFC 4210 [RFC4210] describes the use of 415 EncryptedValue to transport encrypted data. This document extends 416 the encryption of data to preferably use EnvelopedData. 418 Replace the text of the section with the following text: 420 5.2.2. Encrypted Values 422 Where encrypted data (in this specification, private keys, 423 certificates, or revocation passphrase) are sent in PKI messages, the 424 EncryptedKey data structure is used. 426 EncryptedKey ::= CHOICE { 427 encryptedValue EncryptedValue, -- deprecated 428 envelopedData [0] EnvelopedData } 430 See CRMF [RFC4211] for EncryptedKey and EncryptedValue syntax and CMS 431 [RFC5652] for EnvelopedData syntax. Using the EncryptedKey data 432 structure offers the choice to either use EncryptedValue (for 433 backward compatibility only) or EnvelopedData. The use of the 434 EncryptedValue structure has been deprecated in favor of the 435 EnvelopedData structure. Therefore, it is recommended to use 436 EnvelopedData. 438 Note: The EncryptedKey structure defined in CRMF [RFC4211] is reused 439 here, which makes the update backward compatible. Using the new 440 syntax with the untagged default choice EncryptedValue is bits-on- 441 the-wire compatible with the old syntax. 443 To indicate support for EnvelopedData the pvno cmp2021 is introduced 444 by this document. Details on the usage of pvno values is described 445 in Section 7. 447 The EncryptedKey data structure is used in CMP to transport a private 448 key, certificate, or revocation passphrase in encrypted form. 450 EnvelopedData is used as follows: 452 * It contains only one RecipientInfo structure because the content 453 is encrypted only for one recipient. 455 * It may contain a private key in the AsymmetricKeyPackage structure 456 as defined in RFC 5958 [RFC5958] wrapped in a SignedData structure 457 as specified in CMS section 5 [RFC5652] and [RFC8933] signed by 458 the Key Generation Authority. 460 * It may contain a certificate or revocation passphrase directly in 461 the encryptedContent field. 463 The content of the EnvelopedData structure, as specified in CMS 464 section 6 [RFC5652], MUST be encrypted using a newly generated 465 symmetric content-encryption key. This content-encryption key MUST 466 be securely provided to the recipient using one of three key 467 management techniques. 469 The choice of the key management technique to be used by the sender 470 depends on the credential available at the recipient: 472 * Recipient's certificate that contains a key usage extension 473 asserting keyAgreement: The content-encryption key will be 474 protected using the key agreement key management technique, as 475 specified in CMS section 6.2.2 [RFC5652]. This is the preferred 476 technique. 478 * Recipient's certificate that contains a key usage extension 479 asserting keyEncipherment: The content-encryption key will be 480 protected using the key transport key management technique, as 481 specified in CMS section 6.2.1 [RFC5652]. 483 * A password or shared secret: The content-encryption key will be 484 protected using the password-based key management technique, as 485 specified in CMS section 6.2.4 [RFC5652]. 487 2.8. Update Section 5.3.4. - Certification Response 489 Section 5.3.4 of RFC 4210 [RFC4210] describes the Certification 490 Response. This document updates the syntax by using the parent 491 structure EncryptedKey instead of EncryptedValue as described in 492 Section 2.7 above. Moreover, it clarifies the certReqId to be used 493 in response to a p10cr message. 495 Replace the ASN.1 syntax with the following text (Note: This also 496 fixes Errata ID 3949 and 4078): 498 CertRepMessage ::= SEQUENCE { 499 caPubs [1] SEQUENCE SIZE (1..MAX) OF CMPCertificate 500 OPTIONAL, 501 response SEQUENCE OF CertResponse 502 } 504 CertResponse ::= SEQUENCE { 505 certReqId INTEGER, 506 status PKIStatusInfo, 507 certifiedKeyPair CertifiedKeyPair OPTIONAL, 508 rspInfo OCTET STRING OPTIONAL 509 -- analogous to the id-regInfo-utf8Pairs string defined 510 -- for regInfo in CertReqMsg [CRMF] 511 } 513 CertifiedKeyPair ::= SEQUENCE { 514 certOrEncCert CertOrEncCert, 515 privateKey [0] EncryptedKey OPTIONAL, 516 -- see [CRMF] for comment on encoding 517 publicationInfo [1] PKIPublicationInfo OPTIONAL 518 } 520 CertOrEncCert ::= CHOICE { 521 certificate [0] CMPCertificate, 522 encryptedCert [1] EncryptedKey 523 } 525 Add the following as a new paragraph right after the ASN.1 syntax: 527 A p10cr message contains exactly one CertificationRequestInfo data 528 structure as specified in PKCS#10 [RFC2986] but no certReqId. 529 Therefore, the certReqId in the corresponding certification response 530 (cp) message MUST be set to -1. 532 Add the following as new paragraphs to the end of the section: 534 The use of EncryptedKey is described in Section 5.2.2. 536 Note: To indicate support for EnvelopedData the pvno cmp2021 is 537 introduced by this document. Details on the usage of different pvno 538 values are described in Section 7. 540 2.9. Update Section 5.3.18. - Certificate Confirmation Content 542 This section introduces an optional hashAlg field to the CertStatus 543 type used in certConf messages to explicitly specify the hash 544 algorithm for those certificates where no hash algorithm is specified 545 in the signatureAlgorithm field. 547 Replace the ASN.1 Syntax of CertStatus with the following text: 549 CertStatus ::= SEQUENCE { 550 certHash OCTET STRING, 551 certReqId INTEGER, 552 statusInfo PKIStatusInfo OPTIONAL, 553 hashAlg [0] AlgorithmIdentifier{DIGEST-ALGORITHM, {...}} 554 OPTIONAL 555 } 557 The hashAlg field SHOULD be used only in exceptional cases where the 558 signatureAlgorithm of the certificate to be confirmed does not 559 specify a hash algorithm, neither in the OID nor in the parameters. 560 In such cases, e.g., for EdDSA, the hashAlg MUST be used to specify 561 the hash algorithm to be used for calculating the certHash value. 562 Otherwise, the certHash value SHALL be computed using the same hash 563 algorithm as used to create and verify the certificate signature. If 564 hashAlg is used, the CMP version indicated by the certConf message 565 header must be cmp2021(3). 567 2.10. Update Section 5.3.19.2. - Signing Key Pair Types 569 The following section clarifies the usage of the Signing Key Pair 570 Types on referencing EC curves. 572 Insert this note at the end of Section 5.3.19.2: 574 Note: In case several EC curves are supported, several id-ecPublicKey 575 elements need to be given, one per named curve. 577 2.11. Update Section 5.3.19.3. - Encryption/Key Agreement Key Pair 578 Types 580 The following section clarifies the use of the Encryption/Key 581 Agreement Key Pair Types on referencing EC curves. 583 Insert this note at the end of Section 5.3.19.3: 585 Note: In case several EC curves are supported, several id-ecPublicKey 586 elements need to be given, one per named curve. 588 2.12. Replace Section 5.3.19.9. - Revocation Passphrase 590 Section 5.3.19.9 of RFC 4210 [RFC4210] describes the provisioning of 591 a revocation passphrase for authenticating a later revocation 592 request. This document updates the handling by using the parent 593 structure EncryptedKey instead of EncryptedValue to transport this 594 information as described in Section 2.7 above. 596 Replace the text of the section with the following text: 598 5.3.19.9. Revocation Passphrase 600 This MAY be used by the EE to send a passphrase to a CA/RA for the 601 purpose of authenticating a later revocation request (in the case 602 that the appropriate signing private key is no longer available to 603 authenticate the request). See Appendix B for further details on the 604 use of this mechanism. 606 GenMsg: {id-it 12}, EncryptedKey 607 GenRep: {id-it 12}, < absent > 609 The use of EncryptedKey is described in Section 5.2.2. 611 2.13. New Section 5.3.19.14 - CA Certificates 613 The following subsection describes PKI general messages using id-it- 614 caCerts. The intended use is specified in Lightweight CMP Profile 615 Section 4.3 [I-D.ietf-lamps-lightweight-cmp-profile]. 617 Insert this section after Section 5.3.19.13: 619 2.3.19.14 CA Certificates 621 This MAY be used by the client to get CA certificates. 623 GenMsg: {id-it 17}, < absent > 624 GenRep: {id-it 17}, SEQUENCE SIZE (1..MAX) OF 625 CMPCertificate | < absent > 627 2.14. New Section 5.3.19.15 - Root CA Certificate Update 629 The following subsection describes PKI general messages using id-it- 630 rootCaCert and id-it-rootCaKeyUpdate. The use is specified in 631 Lightweight CMP Profile Section 4.3 632 [I-D.ietf-lamps-lightweight-cmp-profile]. 634 Insert this section after new Section 5.3.19.14: 636 5.3.19.15. Root CA Certificate Update 638 This MAY be used by the client to get an update of a root CA 639 certificate, which is provided in the body of the request message. 640 In contrast to the ckuann message this approach follows the request/ 641 response model. 643 The EE SHOULD reference its current trust anchor in a TrustAnchor 644 structure in the request body, giving the root CA certificate if 645 available, otherwise the public key value of the trust anchor. 647 GenMsg: {id-it 20}, RootCaCertValue | < absent > 648 GenRep: {id-it 18}, RootCaKeyUpdateContent | < absent > 650 RootCaCertValue ::= CMPCertificate 652 RootCaKeyUpdateValue ::= RootCaKeyUpdateContent 654 RootCaKeyUpdateContent ::= SEQUENCE { 655 newWithNew CMPCertificate, 656 newWithOld [0] CMPCertificate OPTIONAL, 657 oldWithNew [1] CMPCertificate OPTIONAL 658 } 660 Note: In contrast to CAKeyUpdAnnContent, this type offers omitting 661 newWithOld and oldWithNew in the GenRep message, depending on the 662 needs of the EE. 664 2.15. New Section 5.3.19.16 - Certificate Request Template 666 The following subsection introduces the PKI general message using id- 667 it-certReqTemplate. Details are specified in the Lightweight CMP 668 Profile Section 4.3 [I-D.ietf-lamps-lightweight-cmp-profile]. 670 Insert this section after new Section 5.3.19.15: 672 5.3.19.16. Certificate Request Template 674 This MAY be used by the client to get a template containing 675 requirements for certificate request attributes and extensions. The 676 controls id-regCtrl-algId and id-regCtrl-rsaKeyLen MAY contain 677 details on the types of subject public keys the CA is willing to 678 certify. 680 The id-regCtrl-algId control MAY be used to identify a cryptographic 681 algorithm, see RFC 5280 Section 4.1.2.7 [RFC5280], other than 682 rsaEncryption. The algorithm field SHALL identify a cryptographic 683 algorithm. The contents of the optional parameters field will vary 684 according to the algorithm identified. For example, when the 685 algorithm is set to id-ecPublicKey, the parameters identify the 686 elliptic curve to be used, see [RFC5480]. 688 The id-regCtrl-rsaKeyLen control SHALL be used for algorithm 689 rsaEncryption and SHALL contain the intended modulus bit length of 690 the RSA key. 692 GenMsg: {id-it 19}, < absent > 693 GenRep: {id-it 19}, CertReqTemplateContent | < absent > 695 CertReqTemplateValue ::= CertReqTemplateContent 697 CertReqTemplateContent ::= SEQUENCE { 698 certTemplate CertTemplate, 699 keySpec Controls OPTIONAL } 701 Controls ::= SEQUENCE SIZE (1..MAX) OF AttributeTypeAndValue 703 id-regCtrl-algId OBJECT IDENTIFIER ::= { iso(1) 704 identified-organization(3) dod(6) internet(1) security(5) 705 mechanisms(5) pkix(7) pkip(5) regCtrl(1) 11 } 707 AlgIdCtrl ::= AlgorithmIdentifier{ALGORITHM, {...}} 709 id-regCtrl-rsaKeyLen OBJECT IDENTIFIER ::= { iso(1) 710 identified-organization(3) dod(6) internet(1) security(5) 711 mechanisms(5) pkix(7) pkip(5) regCtrl(1) 12 } 713 RsaKeyLenCtrl ::= INTEGER (1..MAX) 715 The CertReqTemplateValue contains the prefilled certTemplate to be 716 used for a future certificate request. The publicKey field in the 717 certTemplate MUST NOT be used. In case the PKI management entity 718 wishes to specify supported public-key algorithms, the keySpec field 719 MUST be used. One AttributeTypeAndValue per supported algorithm or 720 RSA key length MUST be used. 722 Note: The Controls ASN.1 type is defined in CRMF Section 6 [RFC4211] 724 2.16. New Section 5.3.19.17 - CRL update retrieval 726 The following subsection introduces the PKI general message using id- 727 it-crlStatusList and id-it-crls. Details are specified in the 728 Lightweight CMP Profile Section 4.3 729 [I-D.ietf-lamps-lightweight-cmp-profile]. Insert this section after 730 new Section 5.3.19.16: 732 5.3.19.17. CRL update retrieval 734 This MAY be used by the client to get new CRLs, specifying the source 735 of the CRLs and the thisUpdate value of the latest CRL it already 736 has, if available. A CRL source is given either by a 737 DistributionPointName or the GeneralNames of the issuing CA. The 738 DistributionPointName should be treated as an internal pointer to 739 identify a CRL that the server already has and not as a way to ask 740 the server to fetch CRLs from external locations. The server shall 741 provide only those CRLs that are more recent than the ones indicated 742 by the client. 744 GenMsg: {id-it TBD1}, SEQUENCE SIZE (1..MAX) OF CRLStatus 745 GenRep: {id-it TBD2}, SEQUENCE SIZE (1..MAX) OF 746 CertificateList | < absent > 748 CRLSource ::= CHOICE { 749 dpn [0] DistributionPointName, 750 issuer [1] GeneralNames } 752 CRLStatus ::= SEQUENCE { 753 source CRLSource, 754 thisUpdate Time OPTIONAL } 756 < TBD: Add requested OIDs for id-it-crlStatusList (TBD1) and id-it- 757 crls (TBD2). > 759 2.17. Update Section 5.3.21 - Error Message Content 761 Section 5.3.21 of RFC 4210 [RFC4210] describes the regular use of 762 error messages. This document adds a use by a PKI management entity 763 to initiate delayed delivery in response to certConf, rr, and genm 764 requests and to error messages. 766 Replace the first sentence of the first paragraph with the following 767 one: 769 This data structure MAY be used by EE, CA, or RA to convey error info 770 and by a PKI management entity to initiate delayed delivery of 771 responses. 773 Replace the second paragraph with the following text: 775 This message MAY be generated at any time during a PKI transaction. 776 If the client sends this request, the server MUST respond with a 777 PKIConfirm response, or another ErrorMsg if any part of the header is 778 not valid. In case a PKI management entity sends an error message to 779 the EE with the pKIStatusInfo field containing the status "waiting", 780 the EE will initiate polling as described in Section 5.3.22. 781 Otherwise, both sides MUST treat this message as the end of the 782 transaction (if a transaction is in progress). 784 2.18. Replace Section 5.3.22 - Polling Request and Response 786 Section 5.3.22 of RFC 4210 [RFC4210] describes when and how polling 787 messages are used for ir, cr, and kur messages. This document 788 extends the polling mechanism for outstanding responses to any kind 789 of request message. This update also fixes the inconsistent use of 790 the terms 'rReq' vs. 'pollReq' and 'pRep' vs. 'pollRep'. 792 Replace Section 5.3.22 with following text: 794 This pair of messages is intended to handle scenarios in which the 795 client needs to poll the server to determine the status of an 796 outstanding response (i.e., when the "waiting" PKIStatus has been 797 received). 799 PollReqContent ::= SEQUENCE OF SEQUENCE { 800 certReqId INTEGER } 802 PollRepContent ::= SEQUENCE OF SEQUENCE { 803 certReqId INTEGER, 804 checkAfter INTEGER, -- time in seconds 805 reason PKIFreeText OPTIONAL } 807 In response to an ir, cr, p10cr, or kur request message, polling is 808 initiated with an ip, cp, or kup response message containing status 809 "waiting". For any type of request message, polling can be initiated 810 with an error response messages with status "waiting". The following 811 clauses describe how polling messages are used. It is assumed that 812 multiple certConf messages can be sent during transactions. There 813 will be one sent in response to each ip, cp, or kup that contains a 814 CertStatus for an issued certificate. 816 1 In response to an ip, cp, or kup message, an EE will send a 817 certConf for all issued certificates and expect a PKIconf for each 818 certConf. An EE will send a pollReq message in response to each 819 CertResponse element of an ip, cp, or kup message with status 820 "waiting" and in response to an error message with status 821 "waiting". Its certReqId MUST be either the index of a 822 CertResponse data structure with status "waiting" or -1 referring 823 to the complete response. 825 2 In response to a pollReq, a CA/RA will return an ip, cp, or kup if 826 one or more of still pending requested certificates are ready or 827 the final response to some other type of request is available; 828 otherwise, it will return a pollRep. 830 3 If the EE receives a pollRep, it will wait for at least the number 831 of seconds given in the checkAfter field before sending another 832 pollReq.. 834 4 If the EE receives an ip, cp, or kup, then it will be treated in 835 the same way as the initial response; if it receives any other 836 response, then this will be treated as the final response to the 837 original request. 839 The following client-side state machine describes polling for 840 individual CertResponse elements. 842 START 843 | 844 v 845 Send ir 846 | ip 847 v 848 Check status 849 of returned <------------------------+ 850 certs | 851 | | 852 +------------------------>|<------------------+ | 853 | | | | 854 | (issued) v (waiting) | | 855 Add to <----------- Check CertResponse ------> Add to | 856 conf list for each certificate pending list | 857 / | 858 / | 859 (conf list) / (empty conf list) | 860 / ip | 861 / +-----------------+ 862 (empty pending list) / | pollRep 863 END <---- Send certConf Send pollReq---------->Wait 864 | ^ ^ | 865 | | | | 866 +-----------------+ +---------------+ 867 (pending list) 869 In the following exchange, the end entity is enrolling for two 870 certificates in one request. 872 Step End Entity PKI 873 -------------------------------------------------------------------- 874 1 Format ir 875 2 -> ir -> 876 3 Handle ir 877 4 Manual intervention is 878 required for both certs. 879 5 <- ip <- 880 6 Process ip 881 7 Format pollReq 882 8 -> pollReq -> 883 9 Check status of cert requests 884 10 Certificates not ready 885 11 Format pollRep 886 12 <- pollRep <- 887 13 Wait 888 14 Format pollReq 889 15 -> pollReq -> 890 16 Check status of cert requests 891 17 One certificate is ready 892 18 Format ip 893 19 <- ip <- 894 20 Handle ip 895 21 Format certConf 896 22 -> certConf -> 897 23 Handle certConf 898 24 Format ack 899 25 <- pkiConf <- 900 26 Format pollReq 901 27 -> pollReq -> 902 28 Check status of certificate 903 29 Certificate is ready 904 30 Format ip 905 31 <- ip <- 906 31 Handle ip 907 32 Format certConf 908 33 -> certConf -> 909 34 Handle certConf 910 35 Format ack 911 36 <- pkiConf <- 913 The following client-side state machine describes polling for a 914 complete response message. 916 Start 917 | 918 | Send request 919 | 920 +----------- Receive response ------------+ 921 | | 922 | ip/cp/kup/error with | other 923 | status "waiting" | response 924 | | 925 v | 926 +------> Polling | 927 | | | 928 | | Send pollReq | 929 | | Receive response | 930 | | | 931 | pollRep | other response | 932 +-----------+------------------->+<-------------------+ 933 | 934 v 935 Handle response 936 | 937 v 938 End 940 In the following exchange, the end-entity is sending a general 941 message request, and the response is delayed by the server. 943 Step End Entity PKI 944 -------------------------------------------------------------------- 945 1 Format genm 946 2 -> genm -> 947 3 Handle genm 948 4 delay in response is necessary 949 5 Format error message "waiting" 950 with certReqId set to -1 951 6 <- error <- 952 7 Process error 953 8 Format pollReq 954 9 -> pollReq -> 955 10 Check status of original request 956 general message response not ready 957 11 Format pollRep 958 12 <- pollRep <- 959 13 Wait 960 14 Format pollReq 961 15 -> pollReq -> 962 16 Check status of original request 963 general message response is ready 964 17 Format genp 965 18 <- genp <- 966 19 Handle genp 968 2.19. Update Section 7 - Version Negotiation 970 Section 7 of RFC 4210 [RFC4210] describes the use of CMP protocol 971 versions. This document describes the handling of the additional CMP 972 version cmp2021 introduced to indicate support of EnvelopedData and 973 hashAlg. 975 Replace the text of the first three paragraphs with the following 976 text: 978 This section defines the version negotiation between client and 979 server used to choose among cmp1999 (specified in RFC 2510 980 [RFC2510]), cmp2000 (specified in RFC 4210 [RFC4210]), and cmp2021 981 (specified in this document). The only difference between protocol 982 versions cmp2021 and cmp2000 is that EnvelopedData replaces 983 EncryptedValue and the optional hashAlg field is added to CertStatus. 985 If a client does not support cmp2021 it chooses the versions for a 986 request as follows: 988 * If the client knows the protocol version(s) supported by the 989 server (e.g., from a previous PKIMessage exchange or via some out- 990 of-band means), then it MUST send a PKIMessage with the highest 991 version supported by both itself and the server. 993 * If the client does not know what version(s) the server supports, 994 then it MUST send a PKIMessage using the highest version it 995 supports. 997 If a client supports cmp2021 and encrypted values are supposed to be 998 transferred in the PKI management operation the client MUST choose 999 the version for a request message containing the CertReqMessages data 1000 structure as follows: 1002 * If the client accepts EnvelopedData, but not EncryptedValue, then 1003 it MUST use cmp2021. 1005 * If the client does not accept EnvelopedData, but EncryptedValue, 1006 then it MUST use cmp2000. 1008 * If the client accepts both EnvelopedData and EncryptedValue: 1010 - If the client knows that the Server supports EnvelopedData 1011 (e.g., from a previous PKIMessage exchange or via some out-of- 1012 band means), then it MUST use cmp2021. 1014 - If the client knows that the server supports only 1015 EncryptedValue, then it MUST use cmp2000. 1017 - If the client does not know whether the server supports 1018 EnvelopedData or EncryptedValue, then it MUST send the request 1019 message using cmp2021. 1021 If a client sends a certConf message and the signatureAlgorithm of 1022 the certificate to be confirmed does not specify a hash algorithm 1023 (neither in its OID nor in its parameters) there are two cases: 1025 * A client supporting cmp2021 MUST use cmp2021 in the certConf 1026 message. 1028 * A client not supporting cmp2021 will not be able to handle this 1029 situation and will fail or reject the certificate. 1031 If a server receives a message with version cmp1999 and supports it, 1032 then the version of the response message MUST also be cmp1999. If a 1033 server receives a message with a version higher or lower than it 1034 supports, then it MUST send back an ErrorMsg with the 1035 unsupportedVersion bit set (in the failureInfo field of the 1036 pKIStatusInfo). If the received version is higher than the highest 1037 supported version for this request message, then the version in the 1038 error message MUST be the highest version the server supports for 1039 this message type; if the received version is lower than the lowest 1040 supported version for this request message then the version in the 1041 error message MUST be the lowest version the server supports for this 1042 message type. 1044 2.20. Update Section 7.1.1. - Clients Talking to RFC 2510 Servers 1046 Section 7.1.1 of RFC 4210 [RFC4210] describes the behavior of a 1047 client sending a cmp2000 message talking to a cmp1999 server. This 1048 document extends the section to clients with any higher version than 1049 cmp1999. 1051 Replace the first sentence of Section 7.1.1 with the following text: 1053 If, after sending a message with a protocol version number higher 1054 than cmp1999, a client receives an ErrorMsgContent with a version of 1055 cmp1999, then it MUST abort the current transaction. 1057 2.21. Add Section 8.4 - Private keys for certificate signing and CMP 1058 message protection 1060 The following subsection addresses the risk arising from reusing the 1061 CA private key for CMP message protection. 1063 Insert this section after Section 8.3: 1065 8.4. Private keys for certificate signing and CMP message protection 1067 When a CA acts as a CMP endpoint, it should not use the same private 1068 key for issuing certificates and for protecting CMP responses, to 1069 reduce the number of usages of the key to the minimum required. 1071 2.22. Add Section 8.5 - Entropy of random numbers, key pairs, and 1072 shared secret information 1074 The following subsection addresses the risk arising from low entropy 1075 of random numbers, asymmetric keys, and shared secret information. 1077 8.5. Entropy of random numbers, key pairs, and shared secret 1078 information 1080 Implementations must generate nonces and private keys from random 1081 input. The use of inadequate pseudo-random number generators (PRNGs) 1082 to generate cryptographic keys can result in little or no security. 1083 An attacker may find it much easier to reproduce the PRNG environment 1084 that produced the keys and to search the resulting small set of 1085 possibilities than brute-force searching the whole key space. As an 1086 example of predictable random numbers see CVE-2008-0166 1087 [CVE-2008-0166]; consequences of low-entropy random numbers are 1088 discussed in Mining Your Ps and Qs [MiningPsQs]. The generation of 1089 quality random numbers is difficult. ISO/IEC 20543:2019 1090 [ISO.20543-2019], NIST SP 800-90A Rev.1 [NIST.SP.800-90Ar1], BSI AIS 1091 31 V2.0 [AIS31], and others offer valuable guidance in this area. 1093 If shared secret information is generated by a cryptographically 1094 secure random-number generator (CSRNG) it is safe to assume that the 1095 entropy of the shared secret information equals its bit length. If 1096 no CSRNG is used, the entropy of a shared secret information depends 1097 on the details of the generation process and cannot be measure 1098 securely after it has been generated. If user-generated passwords 1099 are used as shared secret information, their entropy cannot be 1100 measured and are typically insufficient for protected delivery of 1101 centrally generated keys or trust anchors. 1103 If the entropy of a shared secret information protecting the delivery 1104 of a centrally generated key pair is known, it should not be less 1105 than the security strength of that key pair; if the shared secret 1106 information is re-used for different key pairs, the security of the 1107 shared secret information should exceed the security strength of each 1108 key pair. 1110 For the case of a PKI management operation that delivers a new trust 1111 anchor (e.g., a root CA certificate) using caPubs or genm (a) that is 1112 not concluded in a timely manner or (b) where the shared secret 1113 information is re-used for several key management operations, the 1114 entropy of the shared secret information, if known, should not be 1115 less than the security strength of the trust anchor being managed by 1116 the operation. For other cases it is recommended to (a) use a shared 1117 secret information of possibly low security strength (e.g., a 1118 password) only for a single PKI management operation or (b) use a 1119 shared secret information with an entropy that at least matches the 1120 security strength of the key material being managed by the operation. 1122 2.23. Add Section 8.6 - Trust anchor provisioning using CMP messages 1124 The following subsection addresses the risk arising from in-band 1125 provisioning of new trust anchors in a PKI management operation. 1127 Insert this section after new Section 8.5: 1129 8.6. Trust anchor provisioning using CMP messages 1130 The provider of trust anchors, which typically will be an RA involved 1131 in configuration management of its clients, MUST NOT include to-be- 1132 trusted CA certificates in a CMP message unless it can take 1133 responsibility for making the recipient trust them. When doing so, 1134 it MUST exert the same due diligence as for its own trust anchors. 1136 Whenever an EE receives in a CMP message, e.g., in the caPubs field 1137 of a certificate response or in a general response (genp), a CA 1138 certificate for use as a trust anchor, it MUST properly authenticate 1139 the message sender without already trusting any of the CA 1140 certificates given in the message. 1142 Moreover, the EE MUST verify that the sender is an authorized source 1143 of trust anchors. This authorization is typically indicated using 1144 shared secret information or with a signature-based message 1145 protection using a certificate issued by a PKI that is explicitly 1146 authorized for this purpose. 1148 2.24. Update Section 9 - IANA Considerations 1150 Section 9 of RFC 4210 [RFC4210] contains the IANA Considerations of 1151 that document. As this document defines a new Extended Key Usage, 1152 the IANA Considerations need to be updated accordingly. 1154 Add the following paragraphs after the third paragraph of the 1155 section: 1157 In the SMI-numbers registry "SMI Security for PKIX Extended Key 1158 Purpose Identifiers (1.3.6.1.5.5.7.3)" (see 1159 https://www.iana.org/assignments/smi-numbers/smi-numbers.xhtml#smi- 1160 numbers-1.3.6.1.5.5.7.3) as defined in RFC 7299 [RFC7299] one 1161 addition has been performed. 1163 One new entry has been added: 1165 +=========+=============+============+ 1166 | Decimal | Description | References | 1167 +=========+=============+============+ 1168 | 32 | id-kp-cmKGA | [thisRFC] | 1169 +---------+-------------+------------+ 1171 Table 1: Addition to the PKIX 1172 Extended Key Purpose Identifiers 1173 registry 1175 In the SMI-numbers registry "SMI Security for PKIX CMP Information 1176 Types (1.3.6.1.5.5.7.4)" (see https://www.iana.org/assignments/smi- 1177 numbers/smi-numbers.xhtml#smi-numbers-1.3.6.1.5.5.7.4) as defined in 1178 RFC 7299 [RFC7299] seven additions have been performed. 1180 Seven new entries have been added: 1182 +=========+=======================+============+ 1183 | Decimal | Description | References | 1184 +=========+=======================+============+ 1185 | 17 | id-it-caCerts | [thisRFC] | 1186 +---------+-----------------------+------------+ 1187 | 18 | id-it-rootCaKeyUpdate | [thisRFC] | 1188 +---------+-----------------------+------------+ 1189 | 19 | id-it-certReqTemplate | [thisRFC] | 1190 +---------+-----------------------+------------+ 1191 | 20 | id-it-rootCaCert | [thisRFC] | 1192 +---------+-----------------------+------------+ 1193 | 21 | id-it-certProfile | [thisRFC] | 1194 +---------+-----------------------+------------+ 1195 | TBD1 | id-it-crlStatusList | [thisRFC] | 1196 +---------+-----------------------+------------+ 1197 | TBD2 | id-it-crls | [thisRFC] | 1198 +---------+-----------------------+------------+ 1200 Table 2: Addition to the PKIX CMP 1201 Information Types registry 1203 < TBD: Add requested OIDs for id-it-crlStatusList (TBD1) and id-it- 1204 crls (TBD2). > 1206 In the SMI-numbers registry " SMI Security for PKIX CRMF Registration 1207 Controls (1.3.6.1.5.5.7.5.1)" (see https://www.iana.org/assignments/ 1208 smi-numbers/smi-numbers.xhtml#smi-numbers-1.3.6.1.5.5.7.5.1) as 1209 defined in RFC 7299 [RFC7299] two additions have been performed. 1211 Two new entries have been added: 1213 +=========+======================+============+ 1214 | Decimal | Description | References | 1215 +=========+======================+============+ 1216 | 11 | id-regCtrl-algId | [thisRFC] | 1217 +---------+----------------------+------------+ 1218 | 12 | id-regCtrl-rsaKeyLen | [thisRFC] | 1219 +---------+----------------------+------------+ 1221 Table 3: Addition to the PKIX CRMF 1222 Registration Controls registry 1224 2.25. Update Appendix B - The Use of Revocation Passphrase 1226 Appendix B of RFC 4210 [RFC4210] describes the use of the revocation 1227 passphrase. As this document updates RFC 4210 [RFC4210] to utilize 1228 the parent structure EncryptedKey instead of EncryptedValue as 1229 described in Section 2.7 above, the description is updated 1230 accordingly. 1232 Replace the first bullet point of this section with the following 1233 text: 1235 * The OID and value specified in Section 5.3.19.9 MAY be sent in a 1236 GenMsg message at any time, or MAY be sent in the generalInfo 1237 field of the PKIHeader of any PKIMessage at any time. (In 1238 particular, the EncryptedKey structure as described in section 1239 5.2.2 may be sent in the header of the certConf message that 1240 confirms acceptance of certificates requested in an initialization 1241 request or certificate request message.) This conveys a 1242 revocation passphrase chosen by the entity to the relevant CA/RA. 1243 For use of EnvelopedData this is in the decrypted bytes of 1244 encryptedContent field and for use of EncryptedValue this is in 1245 the decrypted bytes of the encValue field. Furthermore, the 1246 transfer is accomplished with appropriate confidentiality 1247 characteristics. 1249 Replace the third bullet point of this section with the following 1250 text: 1252 * When using EnvelopedData the localKeyId attribute as specified in 1253 RFC 2985 [RFC2985] and when using EncryptedValue the valueHint 1254 field MAY contain a key identifier (chosen by the entity, along 1255 with the passphrase itself) to assist in later retrieval of the 1256 correct passphrase (e.g., when the revocation request is 1257 constructed by the entity and received by the CA/RA). 1259 2.26. Update Appendix C - Request Message Behavioral Clarifications 1261 Appendix C of RFC 4210 [RFC4210] provides clarifications to the 1262 request message behavior. As this document updates RFC 4210 1263 [RFC4210] to utilize the parent structure EncryptedKey instead of 1264 EncryptedValue as described in Section 2.7 above, the description is 1265 updated accordingly. 1267 Replace the comment within the ASN.1 syntax coming after the 1268 definition of POPOSigningKey with the following text (Note: This 1269 fixes Errata ID 2615): 1271 -- ********** 1272 -- * For the purposes of this specification, the ASN.1 comment 1273 -- * given in [CRMF] pertains not only to certTemplate, but 1274 -- * also to the altCertTemplate control. 1275 -- ********** 1276 -- * The signature (using "algorithmIdentifier") is on the 1277 -- * DER-encoded value of poposkInput (i.e., the "value" OCTETs 1278 -- * of the POPOSigningKeyInput DER). NOTE: If CertReqMsg 1279 -- * certReq certTemplate (or the altCertTemplate control) 1280 -- * contains the subject and publicKey values, then poposkInput 1281 -- * MUST be omitted and the signature MUST be computed on the 1282 -- * DER-encoded value of CertReqMsg certReq (or the DER- 1283 -- * encoded value of AltCertTemplate). If 1284 -- * certTemplate/altCertTemplate does not contain both the 1285 -- * subject and public key values (i.e., if it contains only 1286 -- * one of these, or neither), then poposkInput MUST be present 1287 -- * and MUST be signed. 1288 -- ********** 1290 Replace the comment within the ASN.1 syntax coming after the 1291 definition of POPOPrivKey with the following text: 1293 -- ********** 1294 -- * the type of "thisMessage" is given as BIT STRING in RFC 4211 1295 -- * [RFC4211]; it should be "EncryptedKey" (in accordance with 1296 -- * Section 5.2.2 of this specification). Therefore, this 1297 -- * document makes the behavioral clarification of specifying 1298 -- * that the contents of "thisMessage" MUST be encoded either as 1299 -- * "EnvelopedData" or "EncryptedValue" (only for backward 1300 -- * compatibility) and then wrapped in a BIT STRING. This 1301 -- * allows the necessary conveyance and protection of the 1302 -- * private key while maintaining bits-on-the-wire compatibility 1303 -- * with RFC 4211 [RFC4211]. 1304 -- ********** 1306 2.27. Update Appendix D.1. - General Rules for Interpretation of These 1307 Profiles 1309 Appendix D.1 of RFC 4210 [RFC4210] provides general rules for 1310 interpretation of the PKI management messages profiles specified in 1311 Appendix D and Appendix E of RFC 4210 [RFC4210]. This document 1312 updates a sentence regarding the new protocol version cmp2021. 1314 Replace the last sentence of the first paragraph of the section with 1315 the following text: 1317 Mandatory fields are not mentioned if they have an obvious value 1318 (e.g., in this version of these profiles, pvno is always cmp2000). 1320 2.28. Update Appendix D.2. - Algorithm Use Profile 1322 Appendix D.2 of RFC 4210 [RFC4210] provides a list of algorithms that 1323 implementations must support when claiming conformance with PKI 1324 Management Message Profiles as specified in CMP Appendix D.2 1325 [RFC4210]. This document redirects to the new algorithm profile as 1326 specified in Appendix A.1 of CMP Algorithms 1327 [I-D.ietf-lamps-cmp-algorithms]. 1329 Replace the text of the section with the following text: 1331 D.2. Algorithm Use Profile 1333 For specifications of algorithm identifiers and respective 1334 conventions for conforming implementations, please refer to CMP 1335 Algorithms Appendix A.1 [I-D.ietf-lamps-cmp-algorithms]. 1337 2.29. Update Appendix D.4. - Initial Registration/Certification (Basic 1338 Authenticated Scheme) 1340 Appendix D.4 of RFC 4210 [RFC4210] provides the initial registration/ 1341 certification scheme. This scheme shall continue using 1342 EncryptedValue for backward compatibility reasons. 1344 Replace the line specifying protectionAlg of the Initialization 1345 Response message with the following text (Note: This fixes Errata ID 1346 5201): 1348 protectionAlg MSG_MAC_ALG 1350 Replace the comment after the privateKey field of 1351 crc[1].certifiedKeyPair in the syntax of the Initialization Response 1352 message with the following text: 1354 -- see Appendix C, Request Message Behavioral Clarifications 1355 -- for backward compatibility reasons, use EncryptedValue 1357 3. Updates to RFC 6712 - HTTP Transfer for the Certificate Management 1358 Protocol (CMP) 1360 3.1. Update Section 1. - Introduction 1362 To indicate and explain why delayed delivery of all kinds of 1363 PKIMessages may be handled at transfer level and/or at CMP level, the 1364 introduction of RFC 6712 [RFC6712] is updated. 1366 Replace the third paragraph of this section with the following text: 1368 In addition to reliable transport, CMP requires connection and error 1369 handling from the transfer protocol, which is all covered by HTTP. 1370 Moreover, delayed delivery of CMP response messages may be handled at 1371 transfer level regardless of the message contents. Since CMP Updates 1372 [I-D.ietf-lamps-cmp-updates] extends the polling mechanism specified 1373 in the second version of CMP [RFC4210] to cover all types of PKI 1374 management transactions, delays detected at application level may 1375 also be handled within CMP, using pollReq and pollReq messages. 1377 3.2. New Section 1.1. - Changes since RFC 6712 1379 The following subsection describes feature updates to RFC 6712 1380 [RFC6712]. They are related to the base specification. Hence 1381 references to the original sections in RFC 6712 [RFC6712] are used 1382 whenever possible. 1384 Insert this section at the end of the current Section 1: 1386 1.1 Changes since RFC 6712 1388 The following updates are made in [thisRFC]: 1390 * Introduce the HTTP path '/.well-known/cmp'. 1392 * Extend the URI structure. 1394 3.3. Replace Section 3.6. - HTTP Request-URI 1396 Section 3.6 of RFC 6712 [RFC6712] specifies the used HTTP URIs. This 1397 document introduces the HTTP path '/.well-known/cmp' and extends the 1398 URIs. 1400 Replace the text of the section with the following text: 1402 3.6. HTTP Request-URI 1404 Each CMP server on a PKI management entity supporting HTTP or HTTPS 1405 transfer MUST support the use of the path prefix '/.well-known/' as 1406 defined in RFC 8615 [RFC8615] and the registered name 'cmp' to ease 1407 interworking in a multi-vendor environment. 1409 The CMP client needs to be configured with sufficient information to 1410 form the CMP server URI. This is at least the authority portion of 1411 the URI, e.g., 'www.example.com:80', or the full operation path 1412 segment of the PKI management entity. Additionally, OPTIONAL path 1413 segments MAY be added after the registered application name as part 1414 of the full operation path to provide further distinction. A path 1415 segment could for example support the differentiation of specific 1416 CAs, certificate profiles, or PKI management operations. A valid 1417 full CMP path can look like this: 1419 http://www.example.com/.well-known/cmp 1420 http://www.example.com/.well-known/cmp/operationLabel 1421 http://www.example.com/.well-known/cmp/profileLabel 1422 http://www.example.com/.well-known/cmp/profileLabel/operationLabel 1424 3.4. Update Section 6. - IANA Considerations 1426 Section 6 of RFC 6712 [RFC6712] contains the IANA Considerations of 1427 that document. As this document defines a new '.well-known' URI 1428 prefix, the IANA Considerations need to be updated accordingly. 1430 Add the following text between the first and second paragraph of the 1431 section: 1433 In the registry of well-known URIs (see 1434 https://www.iana.org/assignments/well-known-uris/well-known- 1435 uris.xhtml#well-known-uris-1) as defined in RFC 8615 [RFC8615] the 1436 following change has been performed. 1438 One new name entry has been added: 1440 +============+===================+============+ 1441 | URI suffix | Change controller | References | 1442 +============+===================+============+ 1443 | cmp | IETF | [thisRFC] | 1444 +------------+-------------------+------------+ 1446 Table 4: Addition to the well-known URI 1447 registry 1449 4. IANA Considerations 1451 This document contains an update to the IANA Consideration sections 1452 to be added to [RFC4210] and [RFC6712]. 1454 This document updates the ASN.1 modules of RFC 4210 Appendix F 1455 [RFC4210] and RFC 5912 Section 9 [RFC5912]. The OIDs 99 (id-mod- 1456 cmp2021-88) and 100 (id-mod-cmp2021-02) were registered in the SMI 1457 Security for PKIX Module Identifier registry to identify the updated 1458 ASN.1 modules. 1460 < TBD: The temporary registration of cmp URI suffix expires 1461 2022-05-20. The registration must be extended in time or update from 1462 provisional to permanent. > 1464 5. Security Considerations 1466 The security considerations of RFC 4210 [RFC4210] are extended in 1467 Section 2.21 to Section 2.23. No changes are made to the existing 1468 security considerations of RFC 6712 [RFC6712]. 1470 6. Acknowledgements 1472 Special thank goes to Jim Schaad for his guidance and the inspiration 1473 on structuring and writing this document we got from [RFC6402] which 1474 updates CMC. Special thank also goes also to Russ Housley, Lijun 1475 Liao, Martin Peylo, and Tomas Gustavsson for reviewing and providing 1476 valuable suggestions on improving this document. 1478 We also thank all reviewers of this document for their valuable 1479 feedback. 1481 7. References 1483 7.1. Normative References 1485 [I-D.ietf-lamps-cmp-algorithms] 1486 Brockhaus, H., Aschauer, H., Ounsworth, M., and J. Gray, 1487 "Certificate Management Protocol (CMP) Algorithms", Work 1488 in Progress, Internet-Draft, draft-ietf-lamps-cmp- 1489 algorithms-08, 17 November 2021, 1490 . 1493 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 1494 Requirement Levels", BCP 14, RFC 2119, 1495 DOI 10.17487/RFC2119, March 1997, 1496 . 1498 [RFC2510] Adams, C. and S. Farrell, "Internet X.509 Public Key 1499 Infrastructure Certificate Management Protocols", 1500 RFC 2510, DOI 10.17487/RFC2510, March 1999, 1501 . 1503 [RFC2985] Nystrom, M. and B. Kaliski, "PKCS #9: Selected Object 1504 Classes and Attribute Types Version 2.0", RFC 2985, 1505 DOI 10.17487/RFC2985, November 2000, 1506 . 1508 [RFC2986] Nystrom, M. and B. Kaliski, "PKCS #10: Certification 1509 Request Syntax Specification Version 1.7", RFC 2986, 1510 DOI 10.17487/RFC2986, November 2000, 1511 . 1513 [RFC4210] Adams, C., Farrell, S., Kause, T., and T. Mononen, 1514 "Internet X.509 Public Key Infrastructure Certificate 1515 Management Protocol (CMP)", RFC 4210, 1516 DOI 10.17487/RFC4210, September 2005, 1517 . 1519 [RFC4211] Schaad, J., "Internet X.509 Public Key Infrastructure 1520 Certificate Request Message Format (CRMF)", RFC 4211, 1521 DOI 10.17487/RFC4211, September 2005, 1522 . 1524 [RFC5280] Cooper, D., Santesson, S., Farrell, S., Boeyen, S., 1525 Housley, R., and W. Polk, "Internet X.509 Public Key 1526 Infrastructure Certificate and Certificate Revocation List 1527 (CRL) Profile", RFC 5280, DOI 10.17487/RFC5280, May 2008, 1528 . 1530 [RFC5480] Turner, S., Brown, D., Yiu, K., Housley, R., and T. Polk, 1531 "Elliptic Curve Cryptography Subject Public Key 1532 Information", RFC 5480, DOI 10.17487/RFC5480, March 2009, 1533 . 1535 [RFC5652] Housley, R., "Cryptographic Message Syntax (CMS)", STD 70, 1536 RFC 5652, DOI 10.17487/RFC5652, September 2009, 1537 . 1539 [RFC5912] Hoffman, P. and J. Schaad, "New ASN.1 Modules for the 1540 Public Key Infrastructure Using X.509 (PKIX)", RFC 5912, 1541 DOI 10.17487/RFC5912, June 2010, 1542 . 1544 [RFC5958] Turner, S., "Asymmetric Key Packages", RFC 5958, 1545 DOI 10.17487/RFC5958, August 2010, 1546 . 1548 [RFC6402] Schaad, J., "Certificate Management over CMS (CMC) 1549 Updates", RFC 6402, DOI 10.17487/RFC6402, November 2011, 1550 . 1552 [RFC6712] Kause, T. and M. Peylo, "Internet X.509 Public Key 1553 Infrastructure -- HTTP Transfer for the Certificate 1554 Management Protocol (CMP)", RFC 6712, 1555 DOI 10.17487/RFC6712, September 2012, 1556 . 1558 [RFC7299] Housley, R., "Object Identifier Registry for the PKIX 1559 Working Group", RFC 7299, DOI 10.17487/RFC7299, July 2014, 1560 . 1562 [RFC8174] Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC 1563 2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174, 1564 May 2017, . 1566 [RFC8615] Nottingham, M., "Well-Known Uniform Resource Identifiers 1567 (URIs)", RFC 8615, DOI 10.17487/RFC8615, May 2019, 1568 . 1570 [RFC8933] Housley, R., "Update to the Cryptographic Message Syntax 1571 (CMS) for Algorithm Identifier Protection", RFC 8933, 1572 DOI 10.17487/RFC8933, October 2020, 1573 . 1575 [RFC9045] Housley, R., "Algorithm Requirements Update to the 1576 Internet X.509 Public Key Infrastructure Certificate 1577 Request Message Format (CRMF)", RFC 9045, 1578 DOI 10.17487/RFC9045, June 2021, 1579 . 1581 7.2. Informative References 1583 [AIS31] Bundesamt für Sicherheit in der Informationstechnik (BSI), 1584 Killmann, W., and W. Schindler, "A proposal for: 1585 Functionality classes for random number generators, 1586 version 2.0", 18 September 2011, 1587 . 1591 [CVE-2008-0166] 1592 National Institute of Science and Technology (NIST), 1593 "National Vulnerability Database - CVE-2008-0166", 13 May 1594 2008, . 1596 [I-D.ietf-lamps-lightweight-cmp-profile] 1597 Brockhaus, H., Oheimb, D. V., and S. Fries, "Lightweight 1598 Certificate Management Protocol (CMP) Profile", Work in 1599 Progress, Internet-Draft, draft-ietf-lamps-lightweight- 1600 cmp-profile-08, 19 November 2021, 1601 . 1604 [IEEE.802.1AR_2018] 1605 IEEE, "IEEE Standard for Local and metropolitan area 1606 networks - Secure Device Identity", IEEE 802.1AR-2018, 1607 DOI 10.1109/IEEESTD.2018.8423794, 2 August 2018, 1608 . 1610 [ISO.20543-2019] 1611 International Organization for Standardization (ISO), 1612 "Information technology -- Security techniques -- Test and 1613 analysis methods for random bit generators within ISO/IEC 1614 19790 and ISO/IEC 15408", ISO Draft Standard 20543-2019, 1615 October 2019. 1617 [MiningPsQs] 1618 Security'12: Proceedings of the 21st USENIX conference on 1619 Security symposium, Heninger, N., Durumeric, Z., Wustrow, 1620 E., and J. A. Halderman, "Mining Your Ps and Qs: Detection 1621 of Widespread Weak Keys in Network Devices", August 2012, 1622 . 1625 [NIST.SP.800-90Ar1] 1626 Barker, Elaine B. and John M. Kelsey, "Recommendation for 1627 Random Number Generation Using Deterministic Random Bit 1628 Generators", NIST NIST SP 800-90Ar1, 1629 DOI 10.6028/NIST.SP.800-90Ar1, June 2015, 1630 . 1633 Appendix A. ASN.1 Modules 1635 A.1. 1988 ASN.1 Module 1637 This section contains the updated ASN.1 module for [RFC4210]. This 1638 module replaces the module in Appendix F of that document. Although 1639 a 2002 ASN.1 module is provided, this 1988 ASN.1 module remains the 1640 normative module as per the policy of the PKIX working group. 1642 PKIXCMP {iso(1) identified-organization(3) 1643 dod(6) internet(1) security(5) mechanisms(5) pkix(7) 1644 id-mod(0) id-mod-cmp2021-88(99)} 1646 DEFINITIONS EXPLICIT TAGS ::= 1648 BEGIN 1650 -- EXPORTS ALL -- 1652 IMPORTS 1654 Certificate, CertificateList, Extensions, Name, Time, 1655 AlgorithmIdentifier, id-kp 1656 --, UTF8String -- -- if required; otherwise, comment out 1657 FROM PKIX1Explicit88 {iso(1) identified-organization(3) 1658 dod(6) internet(1) security(5) mechanisms(5) pkix(7) 1659 id-mod(0) id-pkix1-explicit-88(18)} 1660 -- The import of Name is added to define CertificationRequest 1661 -- instead of importing it from PKCS#10 [RFC2986] 1663 DistributionPointName, GeneralNames, GeneralName, KeyIdentifier 1664 FROM PKIX1Implicit88 {iso(1) identified-organization(3) 1665 dod(6) internet(1) security(5) mechanisms(5) pkix(7) 1666 id-mod(0) id-pkix1-implicit-88(19)} 1668 CertTemplate, PKIPublicationInfo, EncryptedKey, CertId, 1669 CertReqMessages, Controls, AttributeTypeAndValue, id-regCtrl 1670 FROM PKIXCRMF-2005 {iso(1) identified-organization(3) 1671 dod(6) internet(1) security(5) mechanisms(5) pkix(7) 1672 id-mod(0) id-mod-crmf2005(36)} 1673 -- The import of EncryptedKey is added due to the updates made 1674 -- in CMP Updates [thisRFC]]. EncryptedValue does not need to 1675 -- be imported anymore and is therefore removed here. 1677 -- see also the behavioral clarifications to CRMF codified in 1678 -- Appendix C of this specification 1680 EnvelopedData, SignedData, Attribute 1681 FROM CryptographicMessageSyntax2004 { iso(1) 1682 member-body(2) us(840) rsadsi(113549) pkcs(1) pkcs-9(9) 1683 smime(16) modules(0) cms-2004(24) } 1684 -- The import of EnvelopedData and SignedData is added due to 1685 -- the updates made in CMP Updates [thisRFC] 1686 -- The import of Attribute is added to define 1687 -- CertificationRequest instead of importing it from 1688 -- PKCS#10 [RFC2986] 1690 ; 1692 -- the rest of the module contains locally-defined OIDs and 1693 -- constructs 1695 CMPCertificate ::= CHOICE { 1696 x509v3PKCert Certificate 1697 } 1698 -- This syntax, while bits-on-the-wire compatible with the 1699 -- standard X.509 definition of "Certificate", allows the 1700 -- possibility of future certificate types (such as X.509 1701 -- attribute certificates, WAP WTLS certificates, or other kinds 1702 -- of certificates) within this certificate management protocol, 1703 -- should a need ever arise to support such generality. Those 1704 -- implementations that do not foresee a need to ever support 1705 -- other certificate types MAY, if they wish, comment out the 1706 -- above structure and "un-comment" the following one prior to 1707 -- compiling this ASN.1 module. (Note that interoperability 1708 -- with implementations that don't do this will be unaffected by 1709 -- this change.) 1711 -- CMPCertificate ::= Certificate 1713 PKIMessage ::= SEQUENCE { 1714 header PKIHeader, 1715 body PKIBody, 1716 protection [0] PKIProtection OPTIONAL, 1717 extraCerts [1] SEQUENCE SIZE (1..MAX) OF CMPCertificate 1718 OPTIONAL 1719 } 1721 PKIMessages ::= SEQUENCE SIZE (1..MAX) OF PKIMessage 1723 PKIHeader ::= SEQUENCE { 1724 pvno INTEGER { cmp1999(1), cmp2000(2), 1725 cmp2021(3) }, 1726 sender GeneralName, 1727 -- identifies the sender 1728 recipient GeneralName, 1729 -- identifies the intended recipient 1730 messageTime [0] GeneralizedTime OPTIONAL, 1731 -- time of production of this message (used when sender 1732 -- believes that the transport will be "suitable"; i.e., 1733 -- that the time will still be meaningful upon receipt) 1734 protectionAlg [1] AlgorithmIdentifier OPTIONAL, 1735 -- algorithm used for calculation of protection bits 1736 senderKID [2] KeyIdentifier OPTIONAL, 1737 recipKID [3] KeyIdentifier OPTIONAL, 1738 -- to identify specific keys used for protection 1739 transactionID [4] OCTET STRING OPTIONAL, 1740 -- identifies the transaction; i.e., this will be the same in 1741 -- corresponding request, response, certConf, and PKIConf 1742 -- messages 1743 senderNonce [5] OCTET STRING OPTIONAL, 1744 recipNonce [6] OCTET STRING OPTIONAL, 1745 -- nonces used to provide replay protection, senderNonce 1746 -- is inserted by the creator of this message; recipNonce 1747 -- is a nonce previously inserted in a related message by 1748 -- the intended recipient of this message 1749 freeText [7] PKIFreeText OPTIONAL, 1750 -- this may be used to indicate context-specific instructions 1751 -- (this field is intended for human consumption) 1752 generalInfo [8] SEQUENCE SIZE (1..MAX) OF 1753 InfoTypeAndValue OPTIONAL 1755 -- this may be used to convey context-specific information 1756 -- (this field not primarily intended for human consumption) 1757 } 1759 PKIFreeText ::= SEQUENCE SIZE (1..MAX) OF UTF8String 1760 -- text encoded as UTF-8 String [RFC3629] (note: Each 1761 -- UTF8String MAY include an [RFC3066] language tag 1762 -- to indicate the language of the contained text 1763 -- see [RFC2482] for details) 1765 PKIBody ::= CHOICE { -- message-specific body elements 1766 ir [0] CertReqMessages, --Initialization Request 1767 ip [1] CertRepMessage, --Initialization Response 1768 cr [2] CertReqMessages, --Certification Request 1769 cp [3] CertRepMessage, --Certification Response 1770 p10cr [4] CertificationRequest, --imported from [PKCS10] 1771 popdecc [5] POPODecKeyChallContent, --pop Challenge 1772 popdecr [6] POPODecKeyRespContent, --pop Response 1773 kur [7] CertReqMessages, --Key Update Request 1774 kup [8] CertRepMessage, --Key Update Response 1775 krr [9] CertReqMessages, --Key Recovery Request 1776 krp [10] KeyRecRepContent, --Key Recovery Response 1777 rr [11] RevReqContent, --Revocation Request 1778 rp [12] RevRepContent, --Revocation Response 1779 ccr [13] CertReqMessages, --Cross-Cert. Request 1780 ccp [14] CertRepMessage, --Cross-Cert. Response 1781 ckuann [15] CAKeyUpdAnnContent, --CA Key Update Ann. 1782 cann [16] CertAnnContent, --Certificate Ann. 1783 rann [17] RevAnnContent, --Revocation Ann. 1784 crlann [18] CRLAnnContent, --CRL Announcement 1785 pkiconf [19] PKIConfirmContent, --Confirmation 1786 nested [20] NestedMessageContent, --Nested Message 1787 genm [21] GenMsgContent, --General Message 1788 genp [22] GenRepContent, --General Response 1789 error [23] ErrorMsgContent, --Error Message 1790 certConf [24] CertConfirmContent, --Certificate confirm 1791 pollReq [25] PollReqContent, --Polling request 1792 pollRep [26] PollRepContent --Polling response 1793 } 1795 PKIProtection ::= BIT STRING 1797 ProtectedPart ::= SEQUENCE { 1798 header PKIHeader, 1799 body PKIBody 1800 } 1802 id-PasswordBasedMac OBJECT IDENTIFIER ::= {1 2 840 113533 7 66 13} 1803 PBMParameter ::= SEQUENCE { 1804 salt OCTET STRING, 1805 -- note: implementations MAY wish to limit acceptable sizes 1806 -- of this string to values appropriate for their environment 1807 -- in order to reduce the risk of denial-of-service attacks 1808 owf AlgorithmIdentifier, 1809 -- AlgId for a One-Way Function (SHA-1 recommended) 1810 iterationCount INTEGER, 1811 -- number of times the OWF is applied 1812 -- note: implementations MAY wish to limit acceptable sizes 1813 -- of this integer to values appropriate for their environment 1814 -- in order to reduce the risk of denial-of-service attacks 1815 mac AlgorithmIdentifier 1816 -- the MAC AlgId (e.g., DES-MAC, Triple-DES-MAC [PKCS11], 1817 } -- or HMAC [RFC2104, RFC2202]) 1819 id-DHBasedMac OBJECT IDENTIFIER ::= {1 2 840 113533 7 66 30} 1820 DHBMParameter ::= SEQUENCE { 1821 owf AlgorithmIdentifier, 1822 -- AlgId for a One-Way Function (SHA-1 recommended) 1823 mac AlgorithmIdentifier 1824 -- the MAC AlgId (e.g., DES-MAC, Triple-DES-MAC [PKCS11], 1825 } -- or HMAC [RFC2104, RFC2202]) 1827 NestedMessageContent ::= PKIMessages 1829 PKIStatus ::= INTEGER { 1830 accepted (0), 1831 -- you got exactly what you asked for 1832 grantedWithMods (1), 1833 -- you got something like what you asked for; the 1834 -- requester is responsible for ascertaining the differences 1835 rejection (2), 1836 -- you don't get it, more information elsewhere in the message 1837 waiting (3), 1838 -- the request body part has not yet been processed; expect to 1839 -- hear more later (note: proper handling of this status 1840 -- response MAY use the polling req/rep PKIMessages specified 1841 -- in Section 5.3.22; alternatively, polling in the underlying 1842 -- transport layer MAY have some utility in this regard) 1843 revocationWarning (4), 1844 -- this message contains a warning that a revocation is 1845 -- imminent 1846 revocationNotification (5), 1847 -- notification that a revocation has occurred 1848 keyUpdateWarning (6) 1849 -- update already done for the oldCertId specified in 1850 -- CertReqMsg 1851 } 1853 PKIFailureInfo ::= BIT STRING { 1854 -- since we can fail in more than one way! 1855 -- More codes may be added in the future if/when required. 1856 badAlg (0), 1857 -- unrecognized or unsupported Algorithm Identifier 1858 badMessageCheck (1), 1859 -- integrity check failed (e.g., signature did not verify) 1860 badRequest (2), 1861 -- transaction not permitted or supported 1862 badTime (3), 1863 -- messageTime was not sufficiently close to the system time, 1864 -- as defined by local policy 1865 badCertId (4), 1866 -- no certificate could be found matching the provided criteria 1867 badDataFormat (5), 1868 -- the data submitted has the wrong format 1869 wrongAuthority (6), 1870 -- the authority indicated in the request is different from the 1871 -- one creating the response token 1872 incorrectData (7), 1873 -- the requester's data is incorrect (for notary services) 1874 missingTimeStamp (8), 1875 -- when the timestamp is missing but should be there 1876 -- (by policy) 1877 badPOP (9), 1878 -- the proof-of-possession failed 1879 certRevoked (10), 1880 -- the certificate has already been revoked 1881 certConfirmed (11), 1882 -- the certificate has already been confirmed 1883 wrongIntegrity (12), 1884 -- invalid integrity, password based instead of signature or 1885 -- vice versa 1886 badRecipientNonce (13), 1887 -- invalid recipient nonce, either missing or wrong value 1888 timeNotAvailable (14), 1889 -- the TSA's time source is not available 1890 unacceptedPolicy (15), 1891 -- the requested TSA policy is not supported by the TSA. 1892 unacceptedExtension (16), 1893 -- the requested extension is not supported by the TSA. 1894 addInfoNotAvailable (17), 1895 -- the additional information requested could not be 1896 -- understood or is not available 1897 badSenderNonce (18), 1898 -- invalid sender nonce, either missing or wrong size 1899 badCertTemplate (19), 1900 -- invalid cert. template or missing mandatory information 1901 signerNotTrusted (20), 1902 -- signer of the message unknown or not trusted 1903 transactionIdInUse (21), 1904 -- the transaction identifier is already in use 1905 unsupportedVersion (22), 1906 -- the version of the message is not supported 1907 notAuthorized (23), 1908 -- the sender was not authorized to make the preceding 1909 -- request or perform the preceding action 1910 systemUnavail (24), 1911 -- the request cannot be handled due to system unavailability 1912 systemFailure (25), 1913 -- the request cannot be handled due to system failure 1914 duplicateCertReq (26) 1915 -- certificate cannot be issued because a duplicate 1916 -- certificate already exists 1917 } 1919 PKIStatusInfo ::= SEQUENCE { 1920 status PKIStatus, 1921 statusString PKIFreeText OPTIONAL, 1922 failInfo PKIFailureInfo OPTIONAL 1923 } 1925 OOBCert ::= CMPCertificate 1927 OOBCertHash ::= SEQUENCE { 1928 hashAlg [0] AlgorithmIdentifier OPTIONAL, 1929 certId [1] CertId OPTIONAL, 1930 hashVal BIT STRING 1931 -- hashVal is calculated over the DER encoding of the 1932 -- self-signed certificate with the identifier certID. 1933 } 1935 POPODecKeyChallContent ::= SEQUENCE OF Challenge 1936 -- One Challenge per encryption key certification request (in the 1937 -- same order as these requests appear in CertReqMessages). 1939 Challenge ::= SEQUENCE { 1940 owf AlgorithmIdentifier OPTIONAL, 1941 -- MUST be present in the first Challenge; MAY be omitted in 1942 -- any subsequent Challenge in POPODecKeyChallContent (if 1943 -- omitted, then the owf used in the immediately preceding 1944 -- Challenge is to be used). 1945 witness OCTET STRING, 1946 -- the result of applying the one-way function (owf) to a 1947 -- randomly-generated INTEGER, A. [Note that a different 1948 -- INTEGER MUST be used for each Challenge.] 1949 challenge OCTET STRING 1950 -- the encryption (under the public key for which the cert. 1951 -- request is being made) of Rand. 1952 } 1954 -- Added in CMP Updates [thisRFC] 1956 Rand ::= SEQUENCE { 1957 -- Rand is encrypted under the public key to form the challenge 1958 -- in POPODecKeyChallContent 1959 int INTEGER, 1960 -- the randomly-generated INTEGER A (above) 1961 sender GeneralName 1962 -- the sender's name (as included in PKIHeader) 1963 } 1965 POPODecKeyRespContent ::= SEQUENCE OF INTEGER 1966 -- One INTEGER per encryption key certification request (in the 1967 -- same order as these requests appear in CertReqMessages). The 1968 -- retrieved INTEGER A (above) is returned to the sender of the 1969 -- corresponding Challenge. 1971 CertRepMessage ::= SEQUENCE { 1972 caPubs [1] SEQUENCE SIZE (1..MAX) OF CMPCertificate 1973 OPTIONAL, 1974 response SEQUENCE OF CertResponse 1975 } 1977 CertificationRequest ::= SEQUENCE { 1978 certificationRequestInfo SEQUENCE { 1979 version INTEGER, 1980 subject Name, 1981 subjectPublicKeyInfo SEQUENCE { 1982 algorithm AlgorithmIdentifier, 1983 subjectPublicKey BIT STRING }, 1984 attributes [0] IMPLICIT SET OF Attribute }, 1985 signatureAlgorithm AlgorithmIdentifier, 1986 signature BIT STRING 1987 } 1989 CertResponse ::= SEQUENCE { 1990 certReqId INTEGER, 1991 -- to match this response with corresponding request (a value 1992 -- of -1 is to be used if certReqId is not specified in the 1993 -- corresponding request, which can only be a p10cr) 1994 status PKIStatusInfo, 1995 certifiedKeyPair CertifiedKeyPair OPTIONAL, 1996 rspInfo OCTET STRING OPTIONAL 1997 -- analogous to the id-regInfo-utf8Pairs string defined 1998 -- for regInfo in CertReqMsg [CRMF] 1999 } 2001 CertifiedKeyPair ::= SEQUENCE { 2002 certOrEncCert CertOrEncCert, 2003 privateKey [0] EncryptedKey OPTIONAL, 2004 -- see [CRMF] for comment on encoding 2005 -- Changed from Encrypted Value to EncryptedKey as a CHOICE of 2006 -- EncryptedValue and EnvelopedData due to the changes made in 2007 -- CMP Updates [thisRFC] 2008 -- Using the choice EncryptedValue is bit-compatible to the 2009 -- syntax without this change 2010 publicationInfo [1] PKIPublicationInfo OPTIONAL 2011 } 2013 CertOrEncCert ::= CHOICE { 2014 certificate [0] CMPCertificate, 2015 encryptedCert [1] EncryptedKey 2016 -- Changed from Encrypted Value to EncryptedKey as a CHOICE of 2017 -- EncryptedValue and EnvelopedData due to the changes made in 2018 -- CMP Updates [thisRFC] 2019 -- Using the choice EncryptedValue is bit-compatible to the 2020 -- syntax without this change 2021 } 2023 KeyRecRepContent ::= SEQUENCE { 2024 status PKIStatusInfo, 2025 newSigCert [0] CMPCertificate OPTIONAL, 2026 caCerts [1] SEQUENCE SIZE (1..MAX) OF 2027 CMPCertificate OPTIONAL, 2028 keyPairHist [2] SEQUENCE SIZE (1..MAX) OF 2029 CertifiedKeyPair OPTIONAL 2030 } 2032 RevReqContent ::= SEQUENCE OF RevDetails 2034 RevDetails ::= SEQUENCE { 2035 certDetails CertTemplate, 2036 -- allows requester to specify as much as they can about 2037 -- the cert. for which revocation is requested 2038 -- (e.g., for cases in which serialNumber is not available) 2039 crlEntryDetails Extensions OPTIONAL 2040 -- requested crlEntryExtensions 2041 } 2042 RevRepContent ::= SEQUENCE { 2043 status SEQUENCE SIZE (1..MAX) OF PKIStatusInfo, 2044 -- in same order as was sent in RevReqContent 2045 revCerts [0] SEQUENCE SIZE (1..MAX) OF CertId 2046 OPTIONAL, 2047 -- IDs for which revocation was requested 2048 -- (same order as status) 2049 crls [1] SEQUENCE SIZE (1..MAX) OF CertificateList 2050 OPTIONAL 2051 -- the resulting CRLs (there may be more than one) 2052 } 2054 CAKeyUpdAnnContent ::= SEQUENCE { 2055 oldWithNew CMPCertificate, -- old pub signed with new priv 2056 newWithOld CMPCertificate, -- new pub signed with old priv 2057 newWithNew CMPCertificate -- new pub signed with new priv 2058 } 2060 CertAnnContent ::= CMPCertificate 2062 RevAnnContent ::= SEQUENCE { 2063 status PKIStatus, 2064 certId CertId, 2065 willBeRevokedAt GeneralizedTime, 2066 badSinceDate GeneralizedTime, 2067 crlDetails Extensions OPTIONAL 2068 -- extra CRL details (e.g., crl number, reason, location, etc.) 2069 } 2071 CRLAnnContent ::= SEQUENCE OF CertificateList 2073 CertConfirmContent ::= SEQUENCE OF CertStatus 2075 CertStatus ::= SEQUENCE { 2076 certHash OCTET STRING, 2077 -- the hash of the certificate, using the same hash algorithm 2078 -- as is used to create and verify the certificate signature 2079 certReqId INTEGER, 2080 -- to match this confirmation with the corresponding req/rep 2081 statusInfo PKIStatusInfo OPTIONAL, 2082 hashAlg [0] AlgorithmIdentifier OPTIONAL 2083 -- the hash algorithm to use for calculating certHash 2084 -- SHOULD NOT be used in all cases where the AlgorithmIdentifier 2085 -- of the certificate signature specifies a hash algorithm 2086 } 2088 PKIConfirmContent ::= NULL 2089 -- CertReqTemplateContent, id-regCtrl-algId, id-regCtrl-algId, and 2090 -- id-regCtrl-rsaKeyLen were added in CMP Updates [thisRFC] 2092 CertReqTemplateContent ::= SEQUENCE { 2093 certTemplate CertTemplate, 2094 -- prefilled certTemplate structure elements 2095 -- The SubjectPublicKeyInfo field in the certTemplate MUST NOT 2096 -- be used. 2097 keySpec Controls OPTIONAL 2098 -- MAY be used to specify supported algorithms. 2099 -- Controls ::= SEQUENCE SIZE (1..MAX) OF AttributeTypeAndValue 2100 -- as specified in CRMF (RFC4211) 2101 } 2103 id-regCtrl-altCertTemplate OBJECT IDENTIFIER ::= { id-regCtrl 7 } 2104 AltCertTemplate ::= AttributeTypeAndValue 2105 -- specifies a template for a certificate other than an X.509v3 2106 -- public-key certificate 2108 id-regCtrl-algId OBJECT IDENTIFIER ::= { id-regCtrl 11 } 2109 AlgIdCtrl ::= AlgorithmIdentifier 2110 -- SHALL be used to specify supported algorithms other than RSA 2112 id-regCtrl-rsaKeyLen OBJECT IDENTIFIER ::= { id-regCtrl 12 } 2113 RsaKeyLenCtrl ::= INTEGER (1..MAX) 2114 -- SHALL be used to specify supported RSA key lengths 2116 -- RootCaKeyUpdateContent, CRLSource, and CRLStatus were added in 2117 -- CMP Updates [thisRFC] 2119 RootCaKeyUpdateContent ::= SEQUENCE { 2120 newWithNew CMPCertificate, 2121 -- new root CA certificate 2122 newWithOld [0] CMPCertificate OPTIONAL, 2123 -- X.509 certificate containing the new public root CA key 2124 -- signed with the old private root CA key 2125 oldWithNew [1] CMPCertificate OPTIONAL 2126 -- X.509 certificate containing the old public root CA key 2127 -- signed with the new private root CA key 2128 } 2130 CRLSource ::= CHOICE { 2131 dpn [0] DistributionPointName, 2132 issuer [1] GeneralNames } 2134 CRLStatus ::= SEQUENCE { 2135 source CRLSource, 2136 thisUpdate Time OPTIONAL } 2138 InfoTypeAndValue ::= SEQUENCE { 2139 infoType OBJECT IDENTIFIER, 2140 infoValue ANY DEFINED BY infoType OPTIONAL 2141 } 2142 -- Example InfoTypeAndValue contents include, but are not limited 2143 -- to, the following (un-comment in this ASN.1 module and use as 2144 -- appropriate for a given environment): 2145 -- 2146 -- id-it-caProtEncCert OBJECT IDENTIFIER ::= {id-it 1} 2147 -- CAProtEncCertValue ::= CMPCertificate 2148 -- id-it-signKeyPairTypes OBJECT IDENTIFIER ::= {id-it 2} 2149 -- SignKeyPairTypesValue ::= SEQUENCE SIZE (1..MAX) OF 2150 -- AlgorithmIdentifier 2151 -- id-it-encKeyPairTypes OBJECT IDENTIFIER ::= {id-it 3} 2152 -- EncKeyPairTypesValue ::= SEQUENCE SIZE (1..MAX) OF 2153 -- AlgorithmIdentifier 2154 -- id-it-preferredSymmAlg OBJECT IDENTIFIER ::= {id-it 4} 2155 -- PreferredSymmAlgValue ::= AlgorithmIdentifier 2156 -- id-it-caKeyUpdateInfo OBJECT IDENTIFIER ::= {id-it 5} 2157 -- CAKeyUpdateInfoValue ::= CAKeyUpdAnnContent 2158 -- id-it-currentCRL OBJECT IDENTIFIER ::= {id-it 6} 2159 -- CurrentCRLValue ::= CertificateList 2160 -- id-it-unsupportedOIDs OBJECT IDENTIFIER ::= {id-it 7} 2161 -- UnsupportedOIDsValue ::= SEQUENCE SIZE (1..MAX) OF 2162 -- OBJECT IDENTIFIER 2163 -- id-it-keyPairParamReq OBJECT IDENTIFIER ::= {id-it 10} 2164 -- KeyPairParamReqValue ::= OBJECT IDENTIFIER 2165 -- id-it-keyPairParamRep OBJECT IDENTIFIER ::= {id-it 11} 2166 -- KeyPairParamRepValue ::= AlgorithmIdentifier 2167 -- id-it-revPassphrase OBJECT IDENTIFIER ::= {id-it 12} 2168 -- RevPassphraseValue ::= EncryptedKey 2169 -- - Changed from Encrypted Value to EncryptedKey as a CHOICE 2170 -- - of EncryptedValue and EnvelopedData due to the changes 2171 -- - made in CMP Updates [thisRFC] 2172 -- - Using the choice EncryptedValue is bit-compatible to the 2173 -- - syntax without this change 2174 -- id-it-implicitConfirm OBJECT IDENTIFIER ::= {id-it 13} 2175 -- ImplicitConfirmValue ::= NULL 2176 -- id-it-confirmWaitTime OBJECT IDENTIFIER ::= {id-it 14} 2177 -- ConfirmWaitTimeValue ::= GeneralizedTime 2178 -- id-it-origPKIMessage OBJECT IDENTIFIER ::= {id-it 15} 2179 -- OrigPKIMessageValue ::= PKIMessages 2180 -- id-it-suppLangTags OBJECT IDENTIFIER ::= {id-it 16} 2181 -- SuppLangTagsValue ::= SEQUENCE OF UTF8String 2182 -- id-it-caCerts OBJECT IDENTIFIER ::= {id-it 17} 2183 -- CaCertsValue ::= SEQUENCE SIZE (1..MAX) OF 2184 -- CMPCertificate 2185 -- - id-it-caCerts added in CMP Updates [thisRFC] 2186 -- id-it-rootCaKeyUpdate OBJECT IDENTIFIER ::= {id-it 18} 2187 -- RootCaKeyUpdateValue ::= RootCaKeyUpdateContent 2188 -- - id-it-rootCaKeyUpdate added in CMP Updates [thisRFC] 2189 -- id-it-certReqTemplate OBJECT IDENTIFIER ::= {id-it 19} 2190 -- CertReqTemplateValue ::= CertReqTemplateContent 2191 -- - id-it-certReqTemplate added in CMP Updates [thisRFC] 2192 -- id-it-rootCaCert OBJECT IDENTIFIER ::= {id-it 20} 2193 -- RootCaCertValue ::= CMPCertificate 2194 -- - id-it-rootCaCert added in CMP Updates [thisRFC] 2195 -- id-it-certProfile OBJECT IDENTIFIER ::= {id-it 21} 2196 -- CertProfileValue ::= SEQUENCE SIZE (1..MAX) OF 2197 -- UTF8String 2198 -- - id-it-certProfile added in CMP Updates [thisRFC] 2199 -- id-it-crlStatusList OBJECT IDENTIFIER ::= {id-it TBD1} 2200 -- CRLStatusListValue ::= SEQUENCE SIZE (1..MAX) OF 2201 -- CRLStatus 2202 -- - id-it-crlStatusList added in CMP Updates [thisRFC] 2203 -- id-it-crls OBJECT IDENTIFIER ::= {id-it TBD2} 2204 -- CRLsValue ::= SEQUENCE SIZE (1..MAX) OF 2205 -- CertificateList 2206 -- - id-it-crls added in CMP Updates [thisRFC] 2207 -- 2208 -- where 2209 -- 2210 -- id-pkix OBJECT IDENTIFIER ::= { 2211 -- iso(1) identified-organization(3) 2212 -- dod(6) internet(1) security(5) mechanisms(5) pkix(7)} 2213 -- and 2214 -- id-it OBJECT IDENTIFIER ::= {id-pkix 4} 2215 -- 2216 -- 2217 -- This construct MAY also be used to define new PKIX Certificate 2218 -- Management Protocol request and response messages, or general- 2219 -- purpose (e.g., announcement) messages for future needs or for 2220 -- specific environments. 2222 GenMsgContent ::= SEQUENCE OF InfoTypeAndValue 2224 -- May be sent by EE, RA, or CA (depending on message content). 2225 -- The OPTIONAL infoValue parameter of InfoTypeAndValue will 2226 -- typically be omitted for some of the examples given above. 2227 -- The receiver is free to ignore any contained OBJ. IDs that it 2228 -- does not recognize. If sent from EE to CA, the empty set 2229 -- indicates that the CA may send 2230 -- any/all information that it wishes. 2232 GenRepContent ::= SEQUENCE OF InfoTypeAndValue 2233 -- Receiver MAY ignore any contained OIDs that it does not 2234 -- recognize. 2236 ErrorMsgContent ::= SEQUENCE { 2237 pKIStatusInfo PKIStatusInfo, 2238 errorCode INTEGER OPTIONAL, 2239 -- implementation-specific error codes 2240 errorDetails PKIFreeText OPTIONAL 2241 -- implementation-specific error details 2242 } 2244 PollReqContent ::= SEQUENCE OF SEQUENCE { 2245 certReqId INTEGER 2246 } 2248 PollRepContent ::= SEQUENCE OF SEQUENCE { 2249 certReqId INTEGER, 2250 checkAfter INTEGER, -- time in seconds 2251 reason PKIFreeText OPTIONAL 2252 } 2254 -- 2255 -- Extended Key Usage extension for PKI entities used in CMP 2256 -- operations, added due to the changes made in 2257 -- CMP Updates [thisRFC] 2258 -- The EKUs for the CA and RA are reused from CMC as defined in 2259 -- [RFC6402] 2260 -- 2262 -- id-kp-cmcCA OBJECT IDENTIFIER ::= { id-kp 27 } 2263 -- id-kp-cmcRA OBJECT IDENTIFIER ::= { id-kp 28 } 2264 id-kp-cmKGA OBJECT IDENTIFIER ::= { id-kp 32 } 2266 -- There is no 1988 ASN.1 module of PKCS#9 available to import the 2267 -- syntax of the localKeyId attribute type and value from. Therefore, 2268 -- the syntax is added here as needed for the updates made in 2269 -- CMP Updates [thisRFC] 2271 pkcs-9 OBJECT IDENTIFIER ::= {iso(1) member-body(2) us(840) 2272 rsadsi(113549) pkcs(1) 9} 2274 pkcs-9-at-localKeyId OBJECT IDENTIFIER ::= {pkcs-9 21} 2276 LocalKeyIdValue ::= OCTET STRING 2278 END -- of CMP module 2280 A.2. 2002 ASN.1 Module 2282 This section contains the updated 2002 ASN.1 module for [RFC5912]. 2283 This module replaces the module in Section 9 of that document. The 2284 module contains those changes to the normative ASN.1 module from 2285 RFC4210 Appendix F [RFC4210] that were to update to 2002 ASN.1 2286 standard done in [RFC5912] as well as changes made in this document. 2288 PKIXCMP-2021 2289 { iso(1) identified-organization(3) dod(6) internet(1) 2290 security(5) mechanisms(5) pkix(7) id-mod(0) 2291 id-mod-cmp2021-02(100) } 2292 DEFINITIONS EXPLICIT TAGS ::= 2293 BEGIN 2294 IMPORTS 2296 AttributeSet{}, SingleAttribute{}, Extensions{}, EXTENSION, ATTRIBUTE 2297 FROM PKIX-CommonTypes-2009 2298 {iso(1) identified-organization(3) dod(6) internet(1) security(5) 2299 mechanisms(5) pkix(7) id-mod(0) id-mod-pkixCommon-02(57)} 2301 AlgorithmIdentifier{}, SIGNATURE-ALGORITHM, ALGORITHM, 2302 DIGEST-ALGORITHM, MAC-ALGORITHM 2303 FROM AlgorithmInformation-2009 2304 {iso(1) identified-organization(3) dod(6) internet(1) security(5) 2305 mechanisms(5) pkix(7) id-mod(0) 2306 id-mod-algorithmInformation-02(58)} 2308 Certificate, CertificateList, Time, id-kp 2309 FROM PKIX1Explicit-2009 2310 {iso(1) identified-organization(3) dod(6) internet(1) security(5) 2311 mechanisms(5) pkix(7) id-mod(0) id-mod-pkix1-explicit-02(51)} 2313 DistributionPointName, GeneralNames, GeneralName, KeyIdentifier 2314 FROM PKIX1Implicit-2009 2315 {iso(1) identified-organization(3) dod(6) internet(1) security(5) 2316 mechanisms(5) pkix(7) id-mod(0) id-mod-pkix1-implicit-02(59)} 2318 CertTemplate, PKIPublicationInfo, EncryptedKey, CertId, 2319 CertReqMessages, Controls, RegControlSet, id-regCtrl 2320 FROM PKIXCRMF-2009 2321 { iso(1) identified-organization(3) dod(6) internet(1) 2322 security(5) mechanisms(5) pkix(7) id-mod(0) 2323 id-mod-crmf2005-02(55) } 2324 -- The import of EncryptedKey is added due to the updates made 2325 -- in CMP Updates [thisRFC]. EncryptedValue does not need to 2326 -- be imported anymore and is therefore removed here. 2328 -- see also the behavioral clarifications to CRMF codified in 2329 -- Appendix C of this specification 2331 CertificationRequest 2332 FROM PKCS-10 2333 {iso(1) identified-organization(3) dod(6) internet(1) security(5) 2334 mechanisms(5) pkix(7) id-mod(0) id-mod-pkcs10-2009(69)} 2335 -- (specified in RFC 2986 with 1993 ASN.1 syntax and IMPLICIT 2336 -- tags). Alternatively, implementers may directly include 2337 -- the [PKCS10] syntax in this module 2339 localKeyId 2340 FROM PKCS-9 2341 {iso(1) member-body(2) us(840) rsadsi(113549) pkcs(1) pkcs-9(9) 2342 modules(0) pkcs-9(1)} 2343 -- The import of localKeyId is added due to the updates made in 2344 -- CMP Updates [thisRFC] 2346 EnvelopedData, SignedData 2347 FROM CryptographicMessageSyntax-2009 2348 {iso(1) member-body(2) us(840) rsadsi(113549) pkcs(1) pkcs-9(9) 2349 smime(16) modules(0) id-mod-cms-2004-02(41)} 2350 -- The import of EnvelopedData and SignedData is added due to 2351 -- the updates made in CMP Updates [thisRFC] 2352 ; 2354 -- the rest of the module contains locally defined OIDs and 2355 -- constructs 2357 CMPCertificate ::= CHOICE { x509v3PKCert Certificate, ... } 2358 -- This syntax, while bits-on-the-wire compatible with the 2359 -- standard X.509 definition of "Certificate", allows the 2360 -- possibility of future certificate types (such as X.509 2361 -- attribute certificates, WAP WTLS certificates, or other kinds 2362 -- of certificates) within this certificate management protocol, 2363 -- should a need ever arise to support such generality. Those 2364 -- implementations that do not foresee a need to ever support 2365 -- other certificate types MAY, if they wish, comment out the 2366 -- above structure and "uncomment" the following one prior to 2367 -- compiling this ASN.1 module. (Note that interoperability 2368 -- with implementations that don't do this will be unaffected by 2369 -- this change.) 2371 -- CMPCertificate ::= Certificate 2373 PKIMessage ::= SEQUENCE { 2374 header PKIHeader, 2375 body PKIBody, 2376 protection [0] PKIProtection OPTIONAL, 2377 extraCerts [1] SEQUENCE SIZE (1..MAX) OF CMPCertificate 2378 OPTIONAL } 2380 PKIMessages ::= SEQUENCE SIZE (1..MAX) OF PKIMessage 2382 PKIHeader ::= SEQUENCE { 2383 pvno INTEGER { cmp1999(1), cmp2000(2), 2384 cmp2012(3) }, 2385 sender GeneralName, 2386 -- identifies the sender 2387 recipient GeneralName, 2388 -- identifies the intended recipient 2389 messageTime [0] GeneralizedTime OPTIONAL, 2390 -- time of production of this message (used when sender 2391 -- believes that the transport will be "suitable"; i.e., 2392 -- that the time will still be meaningful upon receipt) 2393 protectionAlg [1] AlgorithmIdentifier{ALGORITHM, {...}} 2394 OPTIONAL, 2395 -- algorithm used for calculation of protection bits 2396 senderKID [2] KeyIdentifier OPTIONAL, 2397 recipKID [3] KeyIdentifier OPTIONAL, 2398 -- to identify specific keys used for protection 2399 transactionID [4] OCTET STRING OPTIONAL, 2400 -- identifies the transaction; i.e., this will be the same in 2401 -- corresponding request, response, certConf, and PKIConf 2402 -- messages 2403 senderNonce [5] OCTET STRING OPTIONAL, 2404 recipNonce [6] OCTET STRING OPTIONAL, 2405 -- nonces used to provide replay protection, senderNonce 2406 -- is inserted by the creator of this message; recipNonce 2407 -- is a nonce previously inserted in a related message by 2408 -- the intended recipient of this message 2409 freeText [7] PKIFreeText OPTIONAL, 2410 -- this may be used to indicate context-specific instructions 2411 -- (this field is intended for human consumption) 2412 generalInfo [8] SEQUENCE SIZE (1..MAX) OF 2413 InfoTypeAndValue OPTIONAL 2414 -- this may be used to convey context-specific information 2415 -- (this field not primarily intended for human consumption) 2416 } 2418 PKIFreeText ::= SEQUENCE SIZE (1..MAX) OF UTF8String 2419 -- text encoded as UTF-8 String [RFC3629] (note: each 2420 -- UTF8String MAY include an [RFC3066] language tag 2421 -- to indicate the language of the contained text; 2422 -- see [RFC2482] for details) 2424 PKIBody ::= CHOICE { -- message-specific body elements 2425 ir [0] CertReqMessages, --Initialization Request 2426 ip [1] CertRepMessage, --Initialization Response 2427 cr [2] CertReqMessages, --Certification Request 2428 cp [3] CertRepMessage, --Certification Response 2429 p10cr [4] CertificationRequest, --imported from [PKCS10] 2430 popdecc [5] POPODecKeyChallContent, --pop Challenge 2431 popdecr [6] POPODecKeyRespContent, --pop Response 2432 kur [7] CertReqMessages, --Key Update Request 2433 kup [8] CertRepMessage, --Key Update Response 2434 krr [9] CertReqMessages, --Key Recovery Request 2435 krp [10] KeyRecRepContent, --Key Recovery Response 2436 rr [11] RevReqContent, --Revocation Request 2437 rp [12] RevRepContent, --Revocation Response 2438 ccr [13] CertReqMessages, --Cross-Cert. Request 2439 ccp [14] CertRepMessage, --Cross-Cert. Response 2440 ckuann [15] CAKeyUpdAnnContent, --CA Key Update Ann. 2441 cann [16] CertAnnContent, --Certificate Ann. 2442 rann [17] RevAnnContent, --Revocation Ann. 2443 crlann [18] CRLAnnContent, --CRL Announcement 2444 pkiconf [19] PKIConfirmContent, --Confirmation 2445 nested [20] NestedMessageContent, --Nested Message 2446 genm [21] GenMsgContent, --General Message 2447 genp [22] GenRepContent, --General Response 2448 error [23] ErrorMsgContent, --Error Message 2449 certConf [24] CertConfirmContent, --Certificate confirm 2450 pollReq [25] PollReqContent, --Polling request 2451 pollRep [26] PollRepContent --Polling response 2452 } 2454 PKIProtection ::= BIT STRING 2456 ProtectedPart ::= SEQUENCE { 2457 header PKIHeader, 2458 body PKIBody } 2460 id-PasswordBasedMac OBJECT IDENTIFIER ::= { iso(1) member-body(2) 2461 usa(840) nt(113533) nsn(7) algorithms(66) 13 } 2462 PBMParameter ::= SEQUENCE { 2463 salt OCTET STRING, 2464 -- note: implementations MAY wish to limit acceptable sizes 2465 -- of this string to values appropriate for their environment 2466 -- in order to reduce the risk of denial-of-service attacks 2467 owf AlgorithmIdentifier{DIGEST-ALGORITHM, {...}}, 2468 -- AlgId for a One-Way Function (SHA-1 recommended) 2469 iterationCount INTEGER, 2470 -- number of times the OWF is applied 2471 -- note: implementations MAY wish to limit acceptable sizes 2472 -- of this integer to values appropriate for their environment 2473 -- in order to reduce the risk of denial-of-service attacks 2474 mac AlgorithmIdentifier{MAC-ALGORITHM, {...}} 2475 -- the MAC AlgId (e.g., DES-MAC, Triple-DES-MAC [PKCS11], 2476 -- or HMAC [RFC2104, RFC2202]) 2477 } 2479 id-DHBasedMac OBJECT IDENTIFIER ::= { iso(1) member-body(2) 2480 usa(840) nt(113533) nsn(7) algorithms(66) 30 } 2481 DHBMParameter ::= SEQUENCE { 2482 owf AlgorithmIdentifier{DIGEST-ALGORITHM, {...}}, 2483 -- AlgId for a One-Way Function (SHA-1 recommended) 2484 mac AlgorithmIdentifier{MAC-ALGORITHM, {...}} 2485 -- the MAC AlgId (e.g., DES-MAC, Triple-DES-MAC [PKCS11], 2486 -- or HMAC [RFC2104, RFC2202]) 2487 } 2489 PKIStatus ::= INTEGER { 2490 accepted (0), 2491 -- you got exactly what you asked for 2492 grantedWithMods (1), 2493 -- you got something like what you asked for; the 2494 -- requester is responsible for ascertaining the differences 2495 rejection (2), 2496 -- you don't get it, more information elsewhere in the message 2497 waiting (3), 2498 -- the request body part has not yet been processed; expect to 2499 -- hear more later (note: proper handling of this status 2500 -- response MAY use the polling req/rep PKIMessages specified 2501 -- in Section 5.3.22; alternatively, polling in the underlying 2502 -- transport layer MAY have some utility in this regard) 2503 revocationWarning (4), 2504 -- this message contains a warning that a revocation is 2505 -- imminent 2506 revocationNotification (5), 2507 -- notification that a revocation has occurred 2508 keyUpdateWarning (6) 2509 -- update already done for the oldCertId specified in 2510 -- CertReqMsg 2511 } 2513 PKIFailureInfo ::= BIT STRING { 2514 -- since we can fail in more than one way! 2515 -- More codes may be added in the future if/when required. 2516 badAlg (0), 2517 -- unrecognized or unsupported Algorithm Identifier 2518 badMessageCheck (1), 2519 -- integrity check failed (e.g., signature did not verify) 2520 badRequest (2), 2521 -- transaction not permitted or supported 2522 badTime (3), 2523 -- messageTime was not sufficiently close to the system time, 2524 -- as defined by local policy 2525 badCertId (4), 2526 -- no certificate could be found matching the provided criteria 2527 badDataFormat (5), 2528 -- the data submitted has the wrong format 2529 wrongAuthority (6), 2530 -- the authority indicated in the request is different from the 2531 -- one creating the response token 2532 incorrectData (7), 2533 -- the requester's data is incorrect (for notary services) 2534 missingTimeStamp (8), 2535 -- when the timestamp is missing but should be there 2536 -- (by policy) 2537 badPOP (9), 2538 -- the proof-of-possession failed 2539 certRevoked (10), 2540 -- the certificate has already been revoked 2541 certConfirmed (11), 2542 -- the certificate has already been confirmed 2543 wrongIntegrity (12), 2544 -- invalid integrity, password based instead of signature or 2545 -- vice versa 2546 badRecipientNonce (13), 2547 -- invalid recipient nonce, either missing or wrong value 2548 timeNotAvailable (14), 2549 -- the TSA's time source is not available 2550 unacceptedPolicy (15), 2551 -- the requested TSA policy is not supported by the TSA 2552 unacceptedExtension (16), 2553 -- the requested extension is not supported by the TSA 2554 addInfoNotAvailable (17), 2555 -- the additional information requested could not be 2556 -- understood or is not available 2557 badSenderNonce (18), 2558 -- invalid sender nonce, either missing or wrong size 2559 badCertTemplate (19), 2560 -- invalid cert. template or missing mandatory information 2561 signerNotTrusted (20), 2562 -- signer of the message unknown or not trusted 2563 transactionIdInUse (21), 2564 -- the transaction identifier is already in use 2565 unsupportedVersion (22), 2566 -- the version of the message is not supported 2567 notAuthorized (23), 2568 -- the sender was not authorized to make the preceding 2569 -- request or perform the preceding action 2570 systemUnavail (24), 2571 -- the request cannot be handled due to system unavailability 2572 systemFailure (25), 2573 -- the request cannot be handled due to system failure 2574 duplicateCertReq (26) 2575 -- certificate cannot be issued because a duplicate 2576 -- certificate already exists 2577 } 2579 PKIStatusInfo ::= SEQUENCE { 2580 status PKIStatus, 2581 statusString PKIFreeText OPTIONAL, 2582 failInfo PKIFailureInfo OPTIONAL } 2584 OOBCert ::= CMPCertificate 2586 OOBCertHash ::= SEQUENCE { 2587 hashAlg [0] AlgorithmIdentifier{DIGEST-ALGORITHM, {...}} 2588 OPTIONAL, 2589 certId [1] CertId OPTIONAL, 2590 hashVal BIT STRING 2591 -- hashVal is calculated over the DER encoding of the 2592 -- self-signed certificate with the identifier certID. 2593 } 2595 POPODecKeyChallContent ::= SEQUENCE OF Challenge 2596 -- One Challenge per encryption key certification request (in the 2597 -- same order as these requests appear in CertReqMessages). 2599 Challenge ::= SEQUENCE { 2600 owf AlgorithmIdentifier{DIGEST-ALGORITHM, {...}} 2601 OPTIONAL, 2602 -- MUST be present in the first Challenge; MAY be omitted in 2603 -- any subsequent Challenge in POPODecKeyChallContent (if 2604 -- omitted, then the owf used in the immediately preceding 2605 -- Challenge is to be used). 2606 witness OCTET STRING, 2607 -- the result of applying the one-way function (owf) to a 2608 -- randomly-generated INTEGER, A. [Note that a different 2609 -- INTEGER MUST be used for each Challenge.] 2610 challenge OCTET STRING 2611 -- the encryption (under the public key for which the cert. 2612 -- request is being made) of Rand. 2613 } 2615 -- Added in CMP Updates [thisRFC] 2616 Rand ::= SEQUENCE { 2617 -- Rand is encrypted under the public key to form the challenge 2618 -- in POPODecKeyChallContent 2619 int INTEGER, 2620 -- the randomly-generated INTEGER A (above) 2621 sender GeneralName 2622 -- the sender's name (as included in PKIHeader) 2623 } 2625 POPODecKeyRespContent ::= SEQUENCE OF INTEGER 2626 -- One INTEGER per encryption key certification request (in the 2627 -- same order as these requests appear in CertReqMessages). The 2628 -- retrieved INTEGER A (above) is returned to the sender of the 2629 -- corresponding Challenge. 2631 CertRepMessage ::= SEQUENCE { 2632 caPubs [1] SEQUENCE SIZE (1..MAX) OF CMPCertificate 2633 OPTIONAL, 2634 response SEQUENCE OF CertResponse } 2636 CertResponse ::= SEQUENCE { 2637 certReqId INTEGER, 2638 -- to match this response with the corresponding request (a value 2639 -- of -1 is to be used if certReqId is not specified in the 2640 -- corresponding request, which can only be a p10cr) 2641 status PKIStatusInfo, 2642 certifiedKeyPair CertifiedKeyPair OPTIONAL, 2643 rspInfo OCTET STRING OPTIONAL 2644 -- analogous to the id-regInfo-utf8Pairs string defined 2645 -- for regInfo in CertReqMsg [RFC4211] 2646 } 2648 CertifiedKeyPair ::= SEQUENCE { 2649 certOrEncCert CertOrEncCert, 2650 privateKey [0] EncryptedKey OPTIONAL, 2651 -- see [RFC4211] for comment on encoding 2652 -- Changed from Encrypted Value to EncryptedKey as a CHOICE of 2653 -- EncryptedValue and EnvelopedData due to the changes made in 2654 -- CMP Updates [thisRFC] 2655 -- Using the choice EncryptedValue is bit-compatible to the 2656 -- syntax without this change 2657 publicationInfo [1] PKIPublicationInfo OPTIONAL } 2659 CertOrEncCert ::= CHOICE { 2660 certificate [0] CMPCertificate, 2661 encryptedCert [1] EncryptedKey 2662 -- Changed from Encrypted Value to EncryptedKey as a CHOICE of 2663 -- EncryptedValue and EnvelopedData due to the changes made in 2664 -- CMP Updates [thisRFC] 2665 -- Using the choice EncryptedValue is bit-compatible to the 2666 -- syntax without this change 2667 } 2669 KeyRecRepContent ::= SEQUENCE { 2670 status PKIStatusInfo, 2671 newSigCert [0] CMPCertificate OPTIONAL, 2672 caCerts [1] SEQUENCE SIZE (1..MAX) OF 2673 CMPCertificate OPTIONAL, 2674 keyPairHist [2] SEQUENCE SIZE (1..MAX) OF 2675 CertifiedKeyPair OPTIONAL } 2677 RevReqContent ::= SEQUENCE OF RevDetails 2679 RevDetails ::= SEQUENCE { 2680 certDetails CertTemplate, 2681 -- allows requester to specify as much as they can about 2682 -- the cert. for which revocation is requested 2683 -- (e.g., for cases in which serialNumber is not available) 2684 crlEntryDetails Extensions{{...}} OPTIONAL 2685 -- requested crlEntryExtensions 2686 } 2688 RevRepContent ::= SEQUENCE { 2689 status SEQUENCE SIZE (1..MAX) OF PKIStatusInfo, 2690 -- in same order as was sent in RevReqContent 2691 revCerts [0] SEQUENCE SIZE (1..MAX) OF CertId OPTIONAL, 2692 -- IDs for which revocation was requested 2693 -- (same order as status) 2694 crls [1] SEQUENCE SIZE (1..MAX) OF CertificateList OPTIONAL 2695 -- the resulting CRLs (there may be more than one) 2696 } 2698 CAKeyUpdAnnContent ::= SEQUENCE { 2699 oldWithNew CMPCertificate, -- old pub signed with new priv 2700 newWithOld CMPCertificate, -- new pub signed with old priv 2701 newWithNew CMPCertificate -- new pub signed with new priv 2702 } 2704 CertAnnContent ::= CMPCertificate 2706 RevAnnContent ::= SEQUENCE { 2707 status PKIStatus, 2708 certId CertId, 2709 willBeRevokedAt GeneralizedTime, 2710 badSinceDate GeneralizedTime, 2711 crlDetails Extensions{{...}} OPTIONAL 2712 -- extra CRL details (e.g., crl number, reason, location, etc.) 2713 } 2715 CRLAnnContent ::= SEQUENCE OF CertificateList 2716 PKIConfirmContent ::= NULL 2718 NestedMessageContent ::= PKIMessages 2720 -- CertReqTemplateContent, AttributeTypeAndValue, 2721 -- ExpandedRegControlSet, id-regCtrl-altCertTemplate, 2722 -- AltCertTemplate, regCtrl-algId, id-regCtrl-algId, AlgIdCtrl, 2723 -- regCtrl-rsaKeyLen, id-regCtrl-rsaKeyLen, and RsaKeyLenCtrl 2724 -- were added in CMP Updates [thisRFC] 2726 CertReqTemplateContent ::= SEQUENCE { 2727 certTemplate CertTemplate, 2728 -- prefilled certTemplate structure elements 2729 -- The SubjectPublicKeyInfo field in the certTemplate MUST NOT 2730 -- be used. 2731 keySpec Controls OPTIONAL 2732 -- MAY be used to specify supported algorithms. 2733 -- Controls ::= SEQUENCE SIZE (1..MAX) OF AttributeTypeAndValue 2734 -- as specified in CRMF (RFC4211) 2735 } 2737 AttributeTypeAndValue ::= SingleAttribute{{ ... }} 2739 ExpandedRegControlSet ATTRIBUTE ::= { RegControlSet | 2740 regCtrl-altCertTemplate | regCtrl-algId | regCtrl-rsaKeyLen, ... } 2742 regCtrl-altCertTemplate ATTRIBUTE ::= 2743 { TYPE AltCertTemplate IDENTIFIED BY id-regCtrl-altCertTemplate } 2745 id-regCtrl-altCertTemplate OBJECT IDENTIFIER ::= { id-regCtrl 7 } 2747 AltCertTemplate ::= AttributeTypeAndValue 2748 -- specifies a template for a certificate other than an X.509v3 2749 -- public-key certificate 2751 regCtrl-algId ATTRIBUTE ::= 2752 { TYPE AlgIdCtrl IDENTIFIED BY id-regCtrl-algId } 2754 id-regCtrl-algId OBJECT IDENTIFIER ::= { id-regCtrl 11 } 2756 AlgIdCtrl ::= AlgorithmIdentifier{ALGORITHM, {...}} 2757 -- SHALL be used to specify supported algorithms other than RSA 2759 regCtrl-rsaKeyLen ATTRIBUTE ::= 2760 { TYPE RsaKeyLenCtrl IDENTIFIED BY id-regCtrl-rsaKeyLen } 2762 id-regCtrl-rsaKeyLen OBJECT IDENTIFIER ::= { id-regCtrl 12 } 2764 RsaKeyLenCtrl ::= INTEGER (1..MAX) 2765 -- SHALL be used to specify supported RSA key lengths 2767 -- RootCaKeyUpdateContent, CRLSource, and CRLStatus were added in 2768 -- CMP Updates [thisRFC] 2770 RootCaKeyUpdateContent ::= SEQUENCE { 2771 newWithNew CMPCertificate, 2772 -- new root CA certificate 2773 newWithOld [0] CMPCertificate OPTIONAL, 2774 -- X.509 certificate containing the new public root CA key 2775 -- signed with the old private root CA key 2776 oldWithNew [1] CMPCertificate OPTIONAL 2777 -- X.509 certificate containing the old public root CA key 2778 -- signed with the new private root CA key 2779 } 2781 CRLSource ::= CHOICE { 2782 dpn [0] DistributionPointName, 2783 issuer [1] GeneralNames } 2785 CRLStatus ::= SEQUENCE { 2786 source CRLSource, 2787 thisUpdate Time OPTIONAL } 2789 INFO-TYPE-AND-VALUE ::= TYPE-IDENTIFIER 2791 InfoTypeAndValue ::= SEQUENCE { 2792 infoType INFO-TYPE-AND-VALUE. 2793 &id({SupportedInfoSet}), 2794 infoValue INFO-TYPE-AND-VALUE. 2795 &Type({SupportedInfoSet}{@infoType}) } 2797 SupportedInfoSet INFO-TYPE-AND-VALUE ::= { ... } 2799 -- Example InfoTypeAndValue contents include, but are not limited 2800 -- to, the following (uncomment in this ASN.1 module and use as 2801 -- appropriate for a given environment): 2802 -- 2803 -- id-it-caProtEncCert OBJECT IDENTIFIER ::= {id-it 1} 2804 -- CAProtEncCertValue ::= CMPCertificate 2805 -- id-it-signKeyPairTypes OBJECT IDENTIFIER ::= {id-it 2} 2806 -- SignKeyPairTypesValue ::= SEQUENCE SIZE (1..MAX) OF 2807 -- AlgorithmIdentifier{{...}} 2808 -- id-it-encKeyPairTypes OBJECT IDENTIFIER ::= {id-it 3} 2809 -- EncKeyPairTypesValue ::= SEQUENCE SIZE (1..MAX) OF 2810 -- AlgorithmIdentifier{{...}} 2811 -- id-it-preferredSymmAlg OBJECT IDENTIFIER ::= {id-it 4} 2812 -- PreferredSymmAlgValue ::= AlgorithmIdentifier{{...}} 2813 -- id-it-caKeyUpdateInfo OBJECT IDENTIFIER ::= {id-it 5} 2814 -- CAKeyUpdateInfoValue ::= CAKeyUpdAnnContent 2815 -- id-it-currentCRL OBJECT IDENTIFIER ::= {id-it 6} 2816 -- CurrentCRLValue ::= CertificateList 2817 -- id-it-unsupportedOIDs OBJECT IDENTIFIER ::= {id-it 7} 2818 -- UnsupportedOIDsValue ::= SEQUENCE SIZE (1..MAX) OF 2819 -- OBJECT IDENTIFIER 2820 -- id-it-keyPairParamReq OBJECT IDENTIFIER ::= {id-it 10} 2821 -- KeyPairParamReqValue ::= OBJECT IDENTIFIER 2822 -- id-it-keyPairParamRep OBJECT IDENTIFIER ::= {id-it 11} 2823 -- KeyPairParamRepValue ::= AlgorithmIdentifier{{...}} 2824 -- id-it-revPassphrase OBJECT IDENTIFIER ::= {id-it 12} 2825 -- RevPassphraseValue ::= EncryptedKey 2826 -- - Changed from Encrypted Value to EncryptedKey as a CHOICE 2827 -- - of EncryptedValue and EnvelopedData due to the changes 2828 -- - made in CMP Updates [thisRFC] 2829 -- - Using the choice EncryptedValue is bit-compatible to 2830 -- - the syntax without this change 2831 -- id-it-implicitConfirm OBJECT IDENTIFIER ::= {id-it 13} 2832 -- ImplicitConfirmValue ::= NULL 2833 -- id-it-confirmWaitTime OBJECT IDENTIFIER ::= {id-it 14} 2834 -- ConfirmWaitTimeValue ::= GeneralizedTime 2835 -- id-it-origPKIMessage OBJECT IDENTIFIER ::= {id-it 15} 2836 -- OrigPKIMessageValue ::= PKIMessages 2837 -- id-it-suppLangTags OBJECT IDENTIFIER ::= {id-it 16} 2838 -- SuppLangTagsValue ::= SEQUENCE OF UTF8String 2839 -- id-it-caCerts OBJECT IDENTIFIER ::= {id-it 17} 2840 -- CaCertsValue ::= SEQUENCE SIZE (1..MAX) OF 2841 -- CMPCertificate 2842 -- - id-it-caCerts added in CMP Updates [thisRFC] 2843 -- id-it-rootCaKeyUpdate OBJECT IDENTIFIER ::= {id-it 18} 2844 -- RootCaKeyUpdateValue ::= RootCaKeyUpdateContent 2845 -- - id-it-rootCaKeyUpdate added in CMP Updates [thisRFC] 2846 -- id-it-certReqTemplate OBJECT IDENTIFIER ::= {id-it 19} 2847 -- CertReqTemplateValue ::= CertReqTemplateContent 2848 -- - id-it-certReqTemplate added in CMP Updates [thisRFC] 2849 -- id-it-rootCaCert OBJECT IDENTIFIER ::= {id-it 20} 2850 -- RootCaCertValue ::= CMPCertificate 2851 -- - id-it-rootCaCert added in CMP Updates [thisRFC] 2852 -- id-it-certProfile OBJECT IDENTIFIER ::= {id-it 21} 2853 -- CertProfileValue ::= SEQUENCE SIZE (1..MAX) OF 2854 -- UTF8String 2855 -- - id-it-certProfile added in CMP Updates [thisRFC] 2856 -- id-it-crlStatusList OBJECT IDENTIFIER ::= {id-it TBD1} 2857 -- CRLStatusListValue ::= SEQUENCE SIZE (1..MAX) OF 2858 -- CRLStatus 2859 -- - id-it-crlStatusList added in CMP Updates [thisRFC] 2860 -- id-it-crls OBJECT IDENTIFIER ::= {id-it TBD2} 2861 -- CRLsValue ::= SEQUENCE SIZE (1..MAX) OF 2862 -- CertificateList 2863 -- - id-it-crls added in CMP Updates [thisRFC] 2864 -- 2865 -- where 2866 -- 2867 -- id-pkix OBJECT IDENTIFIER ::= { 2868 -- iso(1) identified-organization(3) 2869 -- dod(6) internet(1) security(5) mechanisms(5) pkix(7)} 2870 -- and 2871 -- id-it OBJECT IDENTIFIER ::= {id-pkix 4} 2872 -- 2873 -- 2874 -- This construct MAY also be used to define new PKIX Certificate 2875 -- Management Protocol request and response messages, or general- 2876 -- purpose (e.g., announcement) messages for future needs or for 2877 -- specific environments. 2879 GenMsgContent ::= SEQUENCE OF InfoTypeAndValue 2881 -- May be sent by EE, RA, or CA (depending on message content). 2882 -- The OPTIONAL infoValue parameter of InfoTypeAndValue will 2883 -- typically be omitted for some of the examples given above. 2884 -- The receiver is free to ignore any contained OBJECT IDs that it 2885 -- does not recognize. If sent from EE to CA, the empty set 2886 -- indicates that the CA may send 2887 -- any/all information that it wishes. 2889 GenRepContent ::= SEQUENCE OF InfoTypeAndValue 2890 -- Receiver MAY ignore any contained OIDs that it does not 2891 -- recognize. 2893 ErrorMsgContent ::= SEQUENCE { 2894 pKIStatusInfo PKIStatusInfo, 2895 errorCode INTEGER OPTIONAL, 2896 -- implementation-specific error codes 2897 errorDetails PKIFreeText OPTIONAL 2898 -- implementation-specific error details 2899 } 2901 CertConfirmContent ::= SEQUENCE OF CertStatus 2903 CertStatus ::= SEQUENCE { 2904 certHash OCTET STRING, 2905 -- the hash of the certificate, using the same hash algorithm 2906 -- as is used to create and verify the certificate signature 2907 certReqId INTEGER, 2908 -- to match this confirmation with the corresponding req/rep 2909 statusInfo PKIStatusInfo OPTIONAL, 2910 hashAlg [0] AlgorithmIdentifier{DIGEST-ALGORITHM, {...}} OPTIONAL 2911 -- the hash algorithm to use for calculating certHash 2912 -- SHOULD NOT be used in all cases where the AlgorithmIdentifier 2913 -- of the certificate signature specifies a hash algorithm 2914 } 2916 PollReqContent ::= SEQUENCE OF SEQUENCE { 2917 certReqId INTEGER } 2919 PollRepContent ::= SEQUENCE OF SEQUENCE { 2920 certReqId INTEGER, 2921 checkAfter INTEGER, -- time in seconds 2922 reason PKIFreeText OPTIONAL } 2924 -- 2925 -- Extended Key Usage extension for PKI entities used in CMP 2926 -- operations, added due to the changes made in 2927 -- CMP Updates [thisRFC] 2928 -- The EKUs for the CA and RA are reused from CMC as defined in 2929 -- [RFC6402] 2930 -- 2932 -- id-kp-cmcCA OBJECT IDENTIFIER ::= { id-kp 27 } 2933 -- id-kp-cmcRA OBJECT IDENTIFIER ::= { id-kp 28 } 2934 id-kp-cmKGA OBJECT IDENTIFIER ::= { id-kp 32 } 2936 END 2938 Appendix B. History of changes 2940 Note: This appendix will be deleted in the final version of the 2941 document. 2943 From version 14 -> 15: 2945 * Updated Section 2.16 clarifying the usage of CRLSource (see thread 2946 "CRL update retrieval - WG Last Call for draft-ietf-lamps-cmp- 2947 updates-14 and draft-ietf-lamps-lightweight-cmp-profile-08") 2948 * Updated Section 2.22 adding further references regarding random 2949 number generation (see thread "CMP draft WGLC: measuring entropy, 2950 CA certificates") 2951 * Fixed some nits 2952 From version 13 -> 14: 2954 * Extended id-it-caCerts support message to allow transporting to- 2955 be-trusted root CA certificates; added respective security 2956 consideration (see thread "Generalizing the CMP "Get CA 2957 certificates" use case") 2958 * Rolled back changes made in previous version regarding root CA 2959 update to avoid registration of new OIDs. Yet we sticked to using 2960 id-it-rootCaCert in the genm body instead its headers' generalInfo 2961 field and removed the ToDos and TBDs on re-arranging id-it OIDs 2962 (see thread "Allocation of OIDs for CRL update retrieval (draft- 2963 ietf-lamps-cmp-updates-13)") 2965 From version 12 -> 13: 2967 * Added John Gray to the list of authors due to fruitful discussion 2968 and important proposals 2969 * Fixed errata no. 2615, 2616, 3949, 4078, and 5201 on RFC 4210 2970 * Added reference on RFC 8933 regarding CMS signedAttrs to 2971 Section 2.7 2972 * Updated Section 2.9 and the ASN.1 modules moving the position of 2973 the hashAlg field (see thread "[CMP Updates] position of hashAlg 2974 in certStatus") 2975 * Changed "rootCaCert" from generalInfo to genm body and generalized 2976 to "oldTrustAnchor", renaming "rootCaKeyUpdate" to 2977 "trustAnchorUpdate" in Sections 2.14, A.1, and A.2, removing 2978 former Section 2.4 2979 * Added genm use case "CRL update retrieval" in Section 2.16, A.1, 2980 and A.2. (see thread "[CMP Updates] Requesting a current CRL") 2981 * Updated Section 2.18 and 2.17 to support polling for all kinds of 2982 CMP request messages initiated by an error message with status 2983 "waiting" as initially discussed at IETF 111 2984 * Updated Sections 2.19 and 2.20 regarding version handling 2985 * Added further OIDs and a TBD regarding reordering of the OIDs 2986 * Added Sections 2.21 to 2.23 with new security considerations and 2987 updated Section 5 accordingly 2988 * Added a ToDo regarding OID registration, renaming, and re-ordering 2989 * Added Section 3.1 updating the introduction of RFC 6712 2990 * Fixed some nits in the ASN.1 modules (see thread "draft-ietf- 2991 lamps-cmp-updates-12: Comments on A.1. 1988 ASN.1 Module" and 2992 "draft-ietf-lamps-cmp-updates-12: Comments on A.2. 2002 ASN.1 2993 Module") 2994 * Replaced the term "transport" by "transfer" where appropriate to 2995 prevent confusion 2996 * Minor editorial changes 2998 From version 11 -> 12: 3000 * Extended Section 2.5 and the ASN.1 modules in Appendix A to allow 3001 a sequence of certificate profiles in CertProfileValue (see thread 3002 "id-it-CertProfile in draft-ietf-lamps-cmp-updates") 3004 From version 10 -> 11: 3006 * Add Section 2.10 to add an additional hashAlg field to the 3007 CertStatus type to support certificates signed with a signature 3008 algorithm not explicitly indicating a hash algorithm in the 3009 AlgorithmIdentifier (see thread "Hash algorithm to us for 3010 calculating certHash") 3011 * Added newly registered OIDs and temporarily registered URI suffix 3012 * Exchanged the import of CertificationRequest from RFC 2986 to the 3013 definition from RFC 6402 Appendix A.1 (see thread "CMP Update of 3014 CertificationRequest") 3015 * Corrected the definition of LocalKeyIdValue in Appendix A.1 3016 * Updated new RFC numbers for I-D.ietf-lamps-crmf-update-algs 3018 From version 9 -> 10: 3020 * Added 1988 ASN.1 syntax for localKeyId attribute to Appendix A.1 3022 From version 08 -> 09: 3024 * Deleted specific definition of CMP CA and CMP RA in Section 2.2 3025 and only reference RFC 6402 for definition of id-kp-cmcCA and id- 3026 kp-cmcRA to resolve the ToDo below based on feedback of Tomas 3027 Gustavsson 3028 * Added Section 2.4. and 2.5 to define id-it-rootCaCert and id-it- 3029 certProfile to be used in Section 2.14 and 2.15 3030 * Added reference to CMP Algorithms in Section 2.8 3031 * Extended Section 2.14 to explicitly indicate the root CA an update 3032 is requested for by using id-it-rootCaCert and changing the ASN.1 3033 syntax to require providing the newWithOld certificate in the 3034 response message 3035 * Extended Section 2.15 to explicitly indicate the certificate 3036 request template by using id-it-certProfile and on further details 3037 of the newly introduced controls 3038 * Deleted the table on id-kp-cmcCA and id-kp-cmcRA and adding id-it- 3039 rootCaCert and id-it-certProfile in Section 2.19 3040 * Adding the definition of id-it-rootCaCert and id-it-certProfile in 3041 both ASN.1 modules in Appendix A 3042 * Minor editorial changes reflecting the above changes 3044 From version 07 -> 08: 3046 * Added a ToDo to Section 2.2 to reflect a current discussion on the 3047 need of an additional CMP-CA role and EKU and differentiation from 3048 CMP-RA 3049 * Added ToDos to Section 2.12 and 2.13 3051 From version 06 -> 07: 3053 * Added David von Oheimb as co-author 3054 * Changed to XML V3 3055 * Added Section 2.3 to enable a CMP protocol version number 3 in the 3056 PKIHeader for cases where EnvelopedData is to be used (see thread 3057 "Mail regarding draft-ietf-lamps-cmp-updates"). 3058 * Added Section 2.4 to refer to [I-D.ietf-lamps-crmf-update-algs] 3059 for the update of id-PasswordBasedMac for PKI message protection 3060 using passwords or shared secrets. 3061 * Updated Section 2.6 to introduce the protocol version number 3 to 3062 properly indicate support of EnvelopedData instead of 3063 EncryptedValue in case a transaction requires use of EnvelopedData 3064 (see thread "Mail regarding draft-ietf-lamps-cmp-updates"). 3065 * Update Section 2.14 to make the minimal changes to the respective 3066 section in CMP more explicit. 3067 * Added Sections 2.15 and 2.16 to address the new cmp2021 protocol 3068 version in Section 7 Version Negotiation. 3069 * Updated Section 2.17 to add new OIDs for id-regCtrl-algId and id- 3070 regCtrl-rsaKeyLen for registration at IANA. 3071 * Added Section 2.20 to update the general rules of interpretation 3072 in Appendix D.1 regarding the new cmp2021 version. 3073 * Added Section 2.21 to update the Algorithm Use Profile in 3074 Appendix D.2 with the reference to the new CMP Algorithms document 3075 as decided at IETF 108. 3076 * Updates Section 3.1 to delete the description of a discovery 3077 mechanism as decided at IETF 108. 3078 * Various changes and corrections in wording. 3080 From version 05 -> 06: 3082 * Added the update of Appendix D.2 with the reference to the new CMP 3083 Algorithms document as decided in IETF 108 3084 * Updated the IANA considerations to register new OIDs for id- 3085 regCtrl-algId and d-regCtrl-rsaKeyLen. 3086 * Minor changes and corrections 3088 From version 04 -> 05: 3090 * Added Section 2.10 and Section 2.11 to clarify the usage of these 3091 general messages types with EC curves (see thread 3092 "AlgorithmIdentifier parameters NULL value - Re: InfoTypeAndValue 3093 in CMP headers") 3095 * Split former section 2.7 on adding 'CA Certificates', 'Root CA 3096 Certificates Update', and 'Certificate Request Template' in three 3097 separate sections for easier readability 3098 * Changed in Section 2.14 the ASN.1 syntax of CertReqTemplateValue 3099 from using rsaKeyLen to usage of controls as specified in CRMF 3100 Section 6 [RFC4211] (see thread "dtaft-ietf-lamps-cmp-updates and 3101 rsaKeyLen") 3102 * Updated the IANA considerations in Section 2.24 to introduce new 3103 OID for id-regCtrl-algId and id-regCtrl-rsaKeyLen (see thread 3104 "dtaft-ietf-lamps-cmp-updates and rsaKeyLen") 3105 * Updated the IANA Considerations in and the Appendixes to introduce 3106 new OID for the updates ASN.1 modules (see thread "I-D Action: 3107 draft-ietf-lamps-cmp-updates-04.txt") 3108 * Removed EncryptedValue from and added Controls to the list of 3109 types imported from CRMF [RFC4211] in ASN.1 modules (see thread 3110 "draft-ietf-lamps-cmp-updates and the ASN.1 modules") 3111 * Moved declaration of Rand out of the comment in ASN.1 modules (see 3112 thread "draft-ietf-lamps-cmp-updates and the ASN.1 modules") 3113 * Minor changes and corrections 3115 From version 03 -> 04: 3117 * Added Section 2.7 to introduce three new id-it IDs for uses in 3118 general messages as discussed (see thread "draft-ietf-lamps-cmp- 3119 updates add section to introduce id-it-caCerts, id-it- 3120 rootCaKeyUpdate, and id-it-certReqTemplate") 3121 * Added the new id-it IDs and the /.well-known/cmp to the IANA 3122 Considerations of [RFC4210] in Section 2.9 3123 * Updated the IANA Considerations of [RFC4210] in Section 2.25 3124 * Some changes in wording on Section 3 due to review comments from 3125 Martin Peylo 3127 From version 02 -> 03: 3129 * Added a ToDo on aligning with the CMP Algorithms draft that will 3130 be set up as decided in IETF 108 3131 * Updated section on Encrypted Values in Section 2.7 to add the 3132 AsymmetricKey Package structure to transport a newly generated 3133 private key as decided in IETF 108 3134 * Updated the IANA Considerations of [RFC4210] in Section 2.25 3135 * Added the pre-registered OID in Section 2.25 and the ASN.1 module 3136 * Added Section 3 to document the changes to RFC 6712 [RFC6712] 3137 regarding URI discovery and using the path-prefix of '/.well- 3138 known/' as discussed in IETF 108 3139 * Updated the IANA Considerations section 3140 * Added a complete updated ASN.1 module in 1988 syntax to update 3141 Appendix F of [RFC4210] and a complete updated ASN.1 module in 3142 2002 syntax to update Section 9 of [RFC5912] 3144 * Minor changes in wording 3146 From version 01 -> 02: 3148 * Updated section on EKU OIDs in Section 2.2 as decided in IETF 107 3149 * Changed from symmetric key-encryption to password-based key 3150 management technique in Section 2.7 as discussed with Russ and Jim 3151 on the mailing list 3152 * Defined the attribute containing the key identifier for the 3153 revocation passphrase in Section 2.25 3154 * Moved the change history to the Appendix 3156 From version 00 -> 01: 3158 * Minor changes in wording 3160 From draft-brockhaus-lamps-cmp-updates-03 -> draft-ietf-lamps-cmp- 3161 updates-00: 3163 * Changes required to reflect WG adoption 3165 From version 02 -> 03: 3167 * Added some clarification in Section 2.1 3169 From version 01 -> 02: 3171 * Added clarification to section on multiple protection 3172 * Added clarification on new EKUs after some exchange with Tomas 3173 Gustavsson 3174 * Reused OIDs from RFC 6402 [RFC6402] as suggested by Sean Turner at 3175 IETF 106 3176 * Added clarification on the field containing the key identifier for 3177 a revocation passphrase 3178 * Minor changes in wording 3180 From version 00 -> 01: 3182 * Added a section describing the new extended key usages 3183 * Completed the section on changes to the specification of encrypted 3184 values 3185 * Added a section on clarification to Appendix D.4 3186 * Minor generalization in RFC 4210 [RFC4210] Sections 5.1.3.4 and 3187 5.3.22 3188 * Minor changes in wording 3190 Authors' Addresses 3191 Hendrik Brockhaus (editor) 3192 Siemens AG 3194 Email: hendrik.brockhaus@siemens.com 3196 David von Oheimb 3197 Siemens AG 3199 Email: david.von.oheimb@siemens.com 3201 John Gray 3202 Entrust 3204 Email: john.gray@entrust.com