idnits 2.17.1 draft-ietf-lamps-cmp-updates-14.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- No issues found here. Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- No issues found here. Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- == There are 7 instances of lines with non-RFC6890-compliant IPv4 addresses in the document. If these are example addresses, they should be changed. -- The draft header indicates that this document updates RFC6712, but the abstract doesn't seem to directly say this. It does mention RFC6712 though, so this could be OK. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust and authors Copyright Line does not match the current year (Using the creation date from RFC4210, updated by this document, for RFC5378 checks: 2000-03-07) -- The document seems to lack a disclaimer for pre-RFC5378 work, but may have content which was first submitted before 10 November 2008. If you have contacted all the original authors and they are all willing to grant the BCP78 rights to the IETF Trust, then this is fine, and you can ignore this comment. If not, you may need to add the pre-RFC5378 disclaimer. (See the Legal Provisions document at https://trustee.ietf.org/license-info for more information.) -- The document date (19 November 2021) is 861 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 2855 -- Looks like a reference, but probably isn't: '1' on line 2729 -- Looks like a reference, but probably isn't: '2' on line 2621 -- Looks like a reference, but probably isn't: '3' on line 2373 -- Looks like a reference, but probably isn't: '4' on line 2374 -- Looks like a reference, but probably isn't: '5' on line 2375 -- Looks like a reference, but probably isn't: '6' on line 2376 -- Looks like a reference, but probably isn't: '7' on line 2377 -- Looks like a reference, but probably isn't: '8' on line 2378 == Missing Reference: 'CRMF' is mentioned on line 1949, but not defined == Missing Reference: 'I-D.ietf-lamps-cmp-updates' is mentioned on line 1350, but not defined == Missing Reference: 'RFC3629' is mentioned on line 2364, but not defined == Missing Reference: 'RFC3066' is mentioned on line 2365, but not defined ** Obsolete undefined reference: RFC 3066 (Obsoleted by RFC 4646, RFC 4647) == Missing Reference: 'RFC2482' is mentioned on line 2367, but not defined ** Obsolete undefined reference: RFC 2482 (Obsoleted by RFC 6082) == Missing Reference: 'PKCS10' is mentioned on line 2374, but not defined -- Looks like a reference, but probably isn't: '9' on line 2379 -- Looks like a reference, but probably isn't: '10' on line 2380 -- Looks like a reference, but probably isn't: '11' on line 2381 -- Looks like a reference, but probably isn't: '12' on line 2382 -- Looks like a reference, but probably isn't: '13' on line 2383 -- Looks like a reference, but probably isn't: '14' on line 2384 -- Looks like a reference, but probably isn't: '15' on line 2385 -- Looks like a reference, but probably isn't: '16' on line 2386 -- Looks like a reference, but probably isn't: '17' on line 2387 -- Looks like a reference, but probably isn't: '18' on line 2388 -- Looks like a reference, but probably isn't: '19' on line 2389 -- Looks like a reference, but probably isn't: '20' on line 2390 -- Looks like a reference, but probably isn't: '21' on line 2391 -- Looks like a reference, but probably isn't: '22' on line 2392 -- Looks like a reference, but probably isn't: '23' on line 2393 -- Looks like a reference, but probably isn't: '24' on line 2394 -- Looks like a reference, but probably isn't: '25' on line 2395 -- Looks like a reference, but probably isn't: '26' on line 2396 == Missing Reference: 'PKCS11' is mentioned on line 2430, but not defined == Missing Reference: 'RFC2104' is mentioned on line 2431, but not defined == Missing Reference: 'RFC2202' is mentioned on line 2431, but not defined == Missing Reference: 'I-D.ietf-lamps-crmf-update-algs' is mentioned on line 2995, 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-07 Summary: 7 errors (**), 0 flaws (~~), 14 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: 23 May 2022 Entrust 7 19 November 2021 9 Certificate Management Protocol (CMP) Updates 10 draft-ietf-lamps-cmp-updates-14 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 23 May 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 . . 17 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 . . 27 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 . . . . . . 29 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 . . . . . . . . 30 113 3.3. Replace Section 3.6. - HTTP Request-URI . . . . . . . . . 31 114 3.4. Update Section 6. - IANA Considerations . . . . . . . . . 31 115 4. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 32 116 5. Security Considerations . . . . . . . . . . . . . . . . . . . 32 117 6. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 32 118 7. References . . . . . . . . . . . . . . . . . . . . . . . . . 32 119 7.1. Normative References . . . . . . . . . . . . . . . . . . 33 120 7.2. Informative References . . . . . . . . . . . . . . . . . 35 121 Appendix A. ASN.1 Modules . . . . . . . . . . . . . . . . . . . 35 122 A.1. 1988 ASN.1 Module . . . . . . . . . . . . . . . . . . . . 35 123 A.2. 2002 ASN.1 Module . . . . . . . . . . . . . . . . . . . . 49 124 Appendix B. History of changes . . . . . . . . . . . . . . . . . 62 125 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 67 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 server shall provide only those CRLs that are more recent than the 739 ones indicated by the client. 741 GenMsg: {id-it TBD1}, SEQUENCE SIZE (1..MAX) OF CRLStatus 742 GenRep: {id-it TBD2}, SEQUENCE SIZE (1..MAX) OF 743 CertificateList | < absent > 745 CRLSource ::= CHOICE { 746 dpn [0] DistributionPointName, 747 issuer [1] GeneralNames } 749 CRLStatus ::= SEQUENCE { 750 source CRLSource, 751 thisUpdate Time OPTIONAL } 753 < TBD: Add requested OIDs for id-it-crlStatusList (TBD1) and id-it- 754 crls (TBD2). > 756 2.17. Update Section 5.3.21 - Error Message Content 758 Section 5.3.21 of RFC 4210 [RFC4210] describes the regular use of 759 error messages. This document adds a use by a PKI management entity 760 to initiate delayed delivery in response to certConf, rr, and genm 761 requests and to error messages. 763 Replace the first sentence of the first paragraph with the following 764 one: 766 This data structure MAY be used by EE, CA, or RA to convey error info 767 and by a PKI management entity to initiate delayed delivery of 768 responses. 770 Replace the second paragraph with the following text: 772 This message MAY be generated at any time during a PKI transaction. 773 If the client sends this request, the server MUST respond with a 774 PKIConfirm response, or another ErrorMsg if any part of the header is 775 not valid. In case a PKI management entity sends an error message to 776 the EE with the pKIStatusInfo field containing the status "waiting", 777 the EE will initiate polling as described in Section 5.3.22. 778 Otherwise, both sides MUST treat this message as the end of the 779 transaction (if a transaction is in progress). 781 2.18. Replace Section 5.3.22 - Polling Request and Response 783 Section 5.3.22 of RFC 4210 [RFC4210] describes when and how polling 784 messages are used for ir, cr, and kur messages. This document 785 extends the polling mechanism for outstanding responses to any kind 786 of request message. This update also fixes the inconsistent use of 787 the terms 'rReq' vs. 'pollReq' and 'pRep' vs. 'pollRep'. 789 Replace Section 5.3.22 with following text: 791 This pair of messages is intended to handle scenarios in which the 792 client needs to poll the server to determine the status of an 793 outstanding response (i.e., when the "waiting" PKIStatus has been 794 received). 796 PollReqContent ::= SEQUENCE OF SEQUENCE { 797 certReqId INTEGER } 799 PollRepContent ::= SEQUENCE OF SEQUENCE { 800 certReqId INTEGER, 801 checkAfter INTEGER, -- time in seconds 802 reason PKIFreeText OPTIONAL } 804 In response to an ir, cr, p10cr, or kur request message, polling is 805 initiated with an ip, cp, or kup response message containing status 806 "waiting". For any type of request message, polling can be initiated 807 with an error response messages with status "waiting". The following 808 clauses describe how polling messages are used. It is assumed that 809 multiple certConf messages can be sent during transactions. There 810 will be one sent in response to each ip, cp, or kup that contains a 811 CertStatus for an issued certificate. 813 1 In response to an ip, cp, or kup message, an EE will send a 814 certConf for all issued certificates and expect a PKIconf for each 815 certConf. An EE will send a pollReq message in response to each 816 CertResponse element of an ip, cp, or kup message with status 817 "waiting" and in response to an error message with status 818 "waiting". Its certReqId MUST be either the index of a 819 CertResponse data structure with status "waiting" or -1 referring 820 to the complete response. 822 2 In response to a pollReq, a CA/RA will return an ip, cp, or kup if 823 one or more of still pending requested certificates are ready or 824 the final response to some other type of request is available; 825 otherwise, it will return a pollRep. 827 3 If the EE receives a pollRep, it will wait for at least the number 828 of seconds given in the checkAfter field before sending another 829 pollReq.. 831 4 If the EE receives an ip, cp, or kup, then it will be treated in 832 the same way as the initial response; if it receives any other 833 response, then this will be treated as the final response to the 834 original request. 836 The following client-side state machine describes polling for 837 individual CertResponse elements. 839 START 840 | 841 v 842 Send ir 843 | ip 844 v 845 Check status 846 of returned <------------------------+ 847 certs | 848 | | 849 +------------------------>|<------------------+ | 850 | | | | 851 | (issued) v (waiting) | | 852 Add to <----------- Check CertResponse ------> Add to | 853 conf list for each certificate pending list | 854 / | 855 / | 856 (conf list) / (empty conf list) | 857 / ip | 858 / +-----------------+ 859 (empty pending list) / | pollRep 860 END <---- Send certConf Send pollReq---------->Wait 861 | ^ ^ | 862 | | | | 863 +-----------------+ +---------------+ 864 (pending list) 866 In the following exchange, the end entity is enrolling for two 867 certificates in one request. 869 Step End Entity PKI 870 -------------------------------------------------------------------- 871 1 Format ir 872 2 -> ir -> 873 3 Handle ir 874 4 Manual intervention is 875 required for both certs. 876 5 <- ip <- 877 6 Process ip 878 7 Format pollReq 879 8 -> pollReq -> 880 9 Check status of cert requests 881 10 Certificates not ready 882 11 Format pollRep 883 12 <- pollRep <- 884 13 Wait 885 14 Format pollReq 886 15 -> pollReq -> 887 16 Check status of cert requests 888 17 One certificate is ready 889 18 Format ip 890 19 <- ip <- 891 20 Handle ip 892 21 Format certConf 893 22 -> certConf -> 894 23 Handle certConf 895 24 Format ack 896 25 <- pkiConf <- 897 26 Format pollReq 898 27 -> pollReq -> 899 28 Check status of certificate 900 29 Certificate is ready 901 30 Format ip 902 31 <- ip <- 903 31 Handle ip 904 32 Format certConf 905 33 -> certConf -> 906 34 Handle certConf 907 35 Format ack 908 36 <- pkiConf <- 910 The following client-side state machine describes polling for a 911 complete response message. 913 Start 914 | 915 | Send request 916 | 917 +----------- Receive response ------------+ 918 | | 919 | ip/cp/kup/error with | other 920 | status "waiting" | response 921 | | 922 v | 923 +------> Polling | 924 | | | 925 | | Send pollReq | 926 | | Receive response | 927 | | | 928 | pollRep | other response | 929 +-----------+------------------->+<-------------------+ 930 | 931 v 932 Handle response 933 | 934 v 935 End 937 In the following exchange, the end-entity is sending a general 938 message request, and the response is delayed by the server. 940 Step End Entity PKI 941 -------------------------------------------------------------------- 942 1 Format genm 943 2 -> genm -> 944 3 Handle genm 945 4 delay in response is necessary 946 5 Format error message "waiting" 947 with certReqId set to -1 948 6 <- error <- 949 7 Process error 950 8 Format pollReq 951 9 -> pollReq -> 952 10 Check status of original request 953 general message response not ready 954 11 Format pollRep 955 12 <- pollRep <- 956 13 Wait 957 14 Format pollReq 958 15 -> pollReq -> 959 16 Check status of original request 960 general message response is ready 961 17 Format genp 962 18 <- genp <- 963 19 Handle genp 965 2.19. Update Section 7 - Version Negotiation 967 Section 7 of RFC 4210 [RFC4210] describes the use of CMP protocol 968 versions. This document describes the handling of the additional CMP 969 version cmp2021 introduced to indicate support of EnvelopedData and 970 hashAlg. 972 Replace the text of the first three paragraphs with the following 973 text: 975 This section defines the version negotiation between client and 976 server used to choose among cmp1999 (specified in RFC 2510 977 [RFC2510]), cmp2000 (specified in RFC 4210 [RFC4210]), and cmp2021 978 (specified in this document). The only difference between protocol 979 versions cmp2021 and cmp2000 is that EnvelopedData replaces 980 EncryptedValue and the optional hashAlg field is added to CertStatus. 982 If a client does not support cmp2021 it chooses the versions for a 983 request as follows: 985 * If the client knows the protocol version(s) supported by the 986 server (e.g., from a previous PKIMessage exchange or via some out- 987 of-band means), then it MUST send a PKIMessage with the highest 988 version supported by both itself and the server. 990 * If the client does not know what version(s) the server supports, 991 then it MUST send a PKIMessage using the highest version it 992 supports. 994 If a client supports cmp2021 and encrypted values are supposed to be 995 transferred in the PKI management operation the client MUST choose 996 the version for a request message containing the CertReqMessages data 997 structure as follows: 999 * If the client accepts EnvelopedData, but not EncryptedValue, then 1000 it MUST use cmp2021. 1002 * If the client does not accept EnvelopedData, but EncryptedValue, 1003 then it MUST use cmp2000. 1005 * If the client accepts both EnvelopedData and EncryptedValue: 1007 - If the client knows that the Server supports EnvelopedData 1008 (e.g., from a previous PKIMessage exchange or via some out-of- 1009 band means), then it MUST use cmp2021. 1011 - If the client knows that the server supports only 1012 EncryptedValue, then it MUST use cmp2000. 1014 - If the client does not know whether the server supports 1015 EnvelopedData or EncryptedValue, then it MUST send the request 1016 message using cmp2021. 1018 If a client sends a certConf message and the signatureAlgorithm of 1019 the certificate to be confirmed does not specify a hash algorithm 1020 (neither in its OID nor in its parameters) there are two cases: 1022 * A client supporting cmp2021 MUST use cmp2021 in the certConf 1023 message. 1025 * A client not supporting cmp2021 will not be able to handle this 1026 situation and will fail or reject the certificate. 1028 If a server receives a message with version cmp1999 and supports it, 1029 then the version of the response message MUST also be cmp1999. If a 1030 server receives a message with a version higher or lower than it 1031 supports, then it MUST send back an ErrorMsg with the 1032 unsupportedVersion bit set (in the failureInfo field of the 1033 pKIStatusInfo). If the received version is higher than the highest 1034 supported version for this request message, then the version in the 1035 error message MUST be the highest version the server supports for 1036 this message type; if the received version is lower than the lowest 1037 supported version for this request message then the version in the 1038 error message MUST be the lowest version the server supports for this 1039 message type. 1041 2.20. Update Section 7.1.1. - Clients Talking to RFC 2510 Servers 1043 Section 7.1.1 of RFC 4210 [RFC4210] describes the behavior of a 1044 client sending a cmp2000 message talking to a cmp1999 server. This 1045 document extends the section to clients with any higher version than 1046 cmp1999. 1048 Replace the first sentence of Section 7.1.1 with the following text: 1050 If, after sending a message with a protocol version number higher 1051 than cmp1999, a client receives an ErrorMsgContent with a version of 1052 cmp1999, then it MUST abort the current transaction. 1054 2.21. Add Section 8.4 - Private keys for certificate signing and CMP 1055 message protection 1057 The following subsection addresses the risk arising from reusing the 1058 CA private key for CMP message protection. 1060 Insert this section after Section 8.3: 1062 8.4. Private keys for certificate signing and CMP message protection 1064 When a CA acts as a CMP endpoint, it should not use the same private 1065 key for issuing certificates and for protecting CMP responses, to 1066 reduce the number of usages of the key to the minimum required. 1068 2.22. Add Section 8.5 - Entropy of random numbers, key pairs, and 1069 shared secret information 1071 The following subsection addresses the risk arising from low entropy 1072 of random numbers, asymmetric keys, and shared secret information. 1074 8.5. Entropy of random numbers, key pairs, and shared secret 1075 information 1077 For requirements regarding proper random number and key generation 1078 please refer to [RFC4086]. 1080 For the case of centrally generated key pairs, the entropy of the 1081 shared secret information SHALL NOT be less than the security 1082 strength of the centrally generated key pair; if the shared secret 1083 information is re-used for different key pairs, the entropy and the 1084 security of the underlying cryptographic mechanisms SHOULD exceed the 1085 security strength of the key pairs. 1087 For the case of a PKI management operation that delivers a new trust 1088 anchor (e.g., a root CA certificate) using caPubs, (a) that is not 1089 concluded in a timely manner or (b) where the shared secret 1090 information is re-used for several key management operations, the 1091 entropy of the shared secret information SHALL NOT be less than the 1092 security strength of the key material being managed by the operation. 1093 For other cases it is recommended to (a) either use a shared secret 1094 information of possibly low entropy (e.g., a password) only for a 1095 single PKI management operation or (b) use a shared secret 1096 information with an entropy that matches the security strength of the 1097 key material being managed by the operation. 1099 2.23. Add Section 8.6 - Trust anchor provisioning using CMP messages 1101 The following subsection addresses the risk arising from in-band 1102 provisioning of new trust anchors in a PKI management operation. 1104 Insert this section after new Section 8.5: 1106 8.6. Trust anchor provisioning using CMP messages 1108 The provider of trust anchors, which typically will be an RA involved 1109 in configuration management of its clients, MUST NOT include to-be- 1110 trusted CA certificates in a CMP message unless it can take 1111 responsibility for making the recipient trust them. When doing so, 1112 it MUST exert the same due diligence as for its own trust anchors. 1114 Whenever an EE receives in a CMP message, e.g., in the caPubs field 1115 of a certificate response or in a general response (genp), a CA 1116 certificate for use as a trust anchor, it MUST properly authenticate 1117 the message sender without already trusting any of the CA 1118 certificates given in the message. 1120 Moreover, the EE MUST verify that the sender is an authorized source 1121 of trust anchors. This authorization is typically indicated using 1122 shared secret information or with a signature-based message 1123 protection using a certificate issued by a PKI that is explicitly 1124 authorized for this purpose. 1126 2.24. Update Section 9 - IANA Considerations 1128 Section 9 of RFC 4210 [RFC4210] contains the IANA Considerations of 1129 that document. As this document defines a new Extended Key Usage, 1130 the IANA Considerations need to be updated accordingly. 1132 Add the following paragraphs after the third paragraph of the 1133 section: 1135 In the SMI-numbers registry "SMI Security for PKIX Extended Key 1136 Purpose Identifiers (1.3.6.1.5.5.7.3)" (see 1137 https://www.iana.org/assignments/smi-numbers/smi-numbers.xhtml#smi- 1138 numbers-1.3.6.1.5.5.7.3) as defined in RFC 7299 [RFC7299] one 1139 addition has been performed. 1141 One new entry has been added: 1143 +=========+=============+============+ 1144 | Decimal | Description | References | 1145 +=========+=============+============+ 1146 | 32 | id-kp-cmKGA | [thisRFC] | 1147 +---------+-------------+------------+ 1149 Table 1: Addition to the PKIX 1150 Extended Key Purpose Identifiers 1151 registry 1153 In the SMI-numbers registry "SMI Security for PKIX CMP Information 1154 Types (1.3.6.1.5.5.7.4)" (see https://www.iana.org/assignments/smi- 1155 numbers/smi-numbers.xhtml#smi-numbers-1.3.6.1.5.5.7.4) as defined in 1156 RFC 7299 [RFC7299] fife additions have been performed. 1158 Fife new entries have been added: 1160 +=========+=======================+============+ 1161 | Decimal | Description | References | 1162 +=========+=======================+============+ 1163 | 17 | id-it-caCerts | [thisRFC] | 1164 +---------+-----------------------+------------+ 1165 | 18 | id-it-rootCaKeyUpdate | [thisRFC] | 1166 +---------+-----------------------+------------+ 1167 | 19 | id-it-certReqTemplate | [thisRFC] | 1168 +---------+-----------------------+------------+ 1169 | 20 | id-it-rootCaCert | [thisRFC] | 1170 +---------+-----------------------+------------+ 1171 | 21 | id-it-certProfile | [thisRFC] | 1172 +---------+-----------------------+------------+ 1173 | TBD1 | id-it-crlStatusList | [thisRFC] | 1174 +---------+-----------------------+------------+ 1175 | TBD2 | id-it-crls | [thisRFC] | 1176 +---------+-----------------------+------------+ 1178 Table 2: Addition to the PKIX CMP 1179 Information Types registry 1181 < TBD: Add requested OIDs for id-it-crlStatusList (TBD1) and id-it- 1182 crls (TBD2). > 1184 In the SMI-numbers registry " SMI Security for PKIX CRMF Registration 1185 Controls (1.3.6.1.5.5.7.5.1)" (see https://www.iana.org/assignments/ 1186 smi-numbers/smi-numbers.xhtml#smi-numbers-1.3.6.1.5.5.7.5.1) as 1187 defined in RFC 7299 [RFC7299] two additions have been performed. 1189 Two new entries have been added: 1191 +=========+======================+============+ 1192 | Decimal | Description | References | 1193 +=========+======================+============+ 1194 | 11 | id-regCtrl-algId | [thisRFC] | 1195 +---------+----------------------+------------+ 1196 | 12 | id-regCtrl-rsaKeyLen | [thisRFC] | 1197 +---------+----------------------+------------+ 1199 Table 3: Addition to the PKIX CRMF 1200 Registration Controls registry 1202 2.25. Update Appendix B - The Use of Revocation Passphrase 1204 Appendix B of RFC 4210 [RFC4210] describes the use of the revocation 1205 passphrase. As this document updates RFC 4210 [RFC4210] to utilize 1206 the parent structure EncryptedKey instead of EncryptedValue as 1207 described in Section 2.7 above, the description is updated 1208 accordingly. 1210 Replace the first bullet point of this section with the following 1211 text: 1213 * The OID and value specified in Section 5.3.19.9 MAY be sent in a 1214 GenMsg message at any time, or MAY be sent in the generalInfo 1215 field of the PKIHeader of any PKIMessage at any time. (In 1216 particular, the EncryptedKey structure as described in section 1217 5.2.2 may be sent in the header of the certConf message that 1218 confirms acceptance of certificates requested in an initialization 1219 request or certificate request message.) This conveys a 1220 revocation passphrase chosen by the entity to the relevant CA/RA. 1221 For use of EnvelopedData this is in the decrypted bytes of 1222 encryptedContent field and for use of EncryptedValue this is in 1223 the decrypted bytes of the encValue field. Furthermore, the 1224 transfer is accomplished with appropriate confidentiality 1225 characteristics. 1227 Replace the third bullet point of this section with the following 1228 text: 1230 * When using EnvelopedData the localKeyId attribute as specified in 1231 RFC 2985 [RFC2985] and when using EncryptedValue the valueHint 1232 field MAY contain a key identifier (chosen by the entity, along 1233 with the passphrase itself) to assist in later retrieval of the 1234 correct passphrase (e.g., when the revocation request is 1235 constructed by the entity and received by the CA/RA). 1237 2.26. Update Appendix C - Request Message Behavioral Clarifications 1239 Appendix C of RFC 4210 [RFC4210] provides clarifications to the 1240 request message behavior. As this document updates RFC 4210 1241 [RFC4210] to utilize the parent structure EncryptedKey instead of 1242 EncryptedValue as described in Section 2.7 above, the description is 1243 updated accordingly. 1245 Replace the comment within the ASN.1 syntax coming after the 1246 definition of POPOSigningKey with the following text (Note: This 1247 fixes Errata ID 2615): 1249 -- ********** 1250 -- * For the purposes of this specification, the ASN.1 comment 1251 -- * given in [CRMF] pertains not only to certTemplate, but 1252 -- * also to the altCertTemplate control. 1253 -- ********** 1254 -- * The signature (using "algorithmIdentifier") is on the 1255 -- * DER-encoded value of poposkInput (i.e., the "value" OCTETs 1256 -- * of the POPOSigningKeyInput DER). NOTE: If CertReqMsg 1257 -- * certReq certTemplate (or the altCertTemplate control) 1258 -- * contains the subject and publicKey values, then poposkInput 1259 -- * MUST be omitted and the signature MUST be computed on the 1260 -- * DER-encoded value of CertReqMsg certReq (or the DER- 1261 -- * encoded value of AltCertTemplate). If 1262 -- * certTemplate/altCertTemplate does not contain both the 1263 -- * subject and public key values (i.e., if it contains only 1264 -- * one of these, or neither), then poposkInput MUST be present 1265 -- * and MUST be signed. 1266 -- ********** 1268 Replace the comment within the ASN.1 syntax coming after the 1269 definition of POPOPrivKey with the following text: 1271 -- ********** 1272 -- * the type of "thisMessage" is given as BIT STRING in RFC 4211 1273 -- * [RFC4211]; it should be "EncryptedKey" (in accordance with 1274 -- * Section 5.2.2 of this specification). Therefore, this 1275 -- * document makes the behavioral clarification of specifying 1276 -- * that the contents of "thisMessage" MUST be encoded either as 1277 -- * "EnvelopedData" or "EncryptedValue" (only for backward 1278 -- * compatibility) and then wrapped in a BIT STRING. This 1279 -- * allows the necessary conveyance and protection of the 1280 -- * private key while maintaining bits-on-the-wire compatibility 1281 -- * with RFC 4211 [RFC4211]. 1282 -- ********** 1284 2.27. Update Appendix D.1. - General Rules for Interpretation of These 1285 Profiles 1287 Appendix D.1 of RFC 4210 [RFC4210] provides general rules for 1288 interpretation of the PKI management messages profiles specified in 1289 Appendix D and Appendix E of RFC 4210 [RFC4210]. This document 1290 updates a sentence regarding the new protocol version cmp2021. 1292 Replace the last sentence of the first paragraph of the section with 1293 the following text: 1295 Mandatory fields are not mentioned if they have an obvious value 1296 (e.g., in this version of these profiles, pvno is always cmp2000). 1298 2.28. Update Appendix D.2. - Algorithm Use Profile 1300 Appendix D.2 of RFC 4210 [RFC4210] provides a list of algorithms that 1301 implementations must support when claiming conformance with PKI 1302 Management Message Profiles as specified in CMP Appendix D.2 1303 [RFC4210]. This document redirects to the new algorithm profile as 1304 specified in Appendix A.1 of CMP Algorithms 1305 [I-D.ietf-lamps-cmp-algorithms]. 1307 Replace the text of the section with the following text: 1309 D.2. Algorithm Use Profile 1311 For specifications of algorithm identifiers and respective 1312 conventions for conforming implementations, please refer to CMP 1313 Algorithms Appendix A.1 [I-D.ietf-lamps-cmp-algorithms]. 1315 2.29. Update Appendix D.4. - Initial Registration/Certification (Basic 1316 Authenticated Scheme) 1318 Appendix D.4 of RFC 4210 [RFC4210] provides the initial registration/ 1319 certification scheme. This scheme shall continue using 1320 EncryptedValue for backward compatibility reasons. 1322 Replace the line specifying protectionAlg of the Initialization 1323 Response message with the following text (Note: This fixes Errata ID 1324 5201): 1326 protectionAlg MSG_MAC_ALG 1328 Replace the comment after the privateKey field of 1329 crc[1].certifiedKeyPair in the syntax of the Initialization Response 1330 message with the following text: 1332 -- see Appendix C, Request Message Behavioral Clarifications 1333 -- for backward compatibility reasons, use EncryptedValue 1335 3. Updates to RFC 6712 - HTTP Transfer for the Certificate Management 1336 Protocol (CMP) 1338 3.1. Update Section 1. - Introduction 1340 To indicate and explain why delayed delivery of all kinds of 1341 PKIMessages may be handled at transfer level and/or at CMP level, the 1342 introduction of RFC 6712 [RFC6712] is updated. 1344 Replace the third paragraph of this section with the following text: 1346 In addition to reliable transport, CMP requires connection and error 1347 handling from the transfer protocol, which is all covered by HTTP. 1348 Moreover, delayed delivery of CMP response messages may be handled at 1349 transfer level regardless of the message contents. Since CMP Updates 1350 [I-D.ietf-lamps-cmp-updates] extends the polling mechanism specified 1351 in the second version of CMP [RFC4210] to cover all types of PKI 1352 management transactions, delays detected at application level may 1353 also be handled within CMP, using pollReq and pollReq messages. 1355 3.2. New Section 1.1. - Changes since RFC 6712 1357 The following subsection describes feature updates to RFC 6712 1358 [RFC6712]. They are related to the base specification. Hence 1359 references to the original sections in RFC 6712 [RFC6712] are used 1360 whenever possible. 1362 Insert this section at the end of the current Section 1: 1364 1.1 Changes since RFC 6712 1366 The following updates are made in [thisRFC]: 1368 * Introduce the HTTP path '/.well-known/cmp'. 1370 * Extend the URI structure. 1372 3.3. Replace Section 3.6. - HTTP Request-URI 1374 Section 3.6 of RFC 6712 [RFC6712] specifies the used HTTP URIs. This 1375 document introduces the HTTP path '/.well-known/cmp' and extends the 1376 URIs. 1378 Replace the text of the section with the following text: 1380 3.6. HTTP Request-URI 1382 Each CMP server on a PKI management entity supporting HTTP or HTTPS 1383 transfer MUST support the use of the path prefix '/.well-known/' as 1384 defined in RFC 8615 [RFC8615] and the registered name 'cmp' to ease 1385 interworking in a multi-vendor environment. 1387 The CMP client needs to be configured with sufficient information to 1388 form the CMP server URI. This is at least the authority portion of 1389 the URI, e.g., 'www.example.com:80', or the full operation path 1390 segment of the PKI management entity. Additionally, OPTIONAL path 1391 segments MAY be added after the registered application name as part 1392 of the full operation path to provide further distinction. A path 1393 segment could for example support the differentiation of specific 1394 CAs, certificate profiles, or PKI management operations. A valid 1395 full CMP path can look like this: 1397 http://www.example.com/.well-known/cmp 1398 http://www.example.com/.well-known/cmp/operationLabel 1399 http://www.example.com/.well-known/cmp/profileLabel 1400 http://www.example.com/.well-known/cmp/profileLabel/operationLabel 1402 3.4. Update Section 6. - IANA Considerations 1404 Section 6 of RFC 6712 [RFC6712] contains the IANA Considerations of 1405 that document. As this document defines a new '.well-known' URI 1406 prefix, the IANA Considerations need to be updated accordingly. 1408 Add the following text between the first and second paragraph of the 1409 section: 1411 In the registry of well-known URIs (see 1412 https://www.iana.org/assignments/well-known-uris/well-known- 1413 uris.xhtml#well-known-uris-1) as defined in RFC 8615 [RFC8615] the 1414 following change has been performed. 1416 One new name entry has been added: 1418 +============+===================+============+ 1419 | URI suffix | Change controller | References | 1420 +============+===================+============+ 1421 | cmp | IETF | [thisRFC] | 1422 +------------+-------------------+------------+ 1424 Table 4: Addition to the well-known URI 1425 registry 1427 4. IANA Considerations 1429 This document contains an update to the IANA Consideration sections 1430 to be added to [RFC4210] and [RFC6712]. 1432 This document updates the ASN.1 modules of RFC 4210 Appendix F 1433 [RFC4210] and RFC 5912 Section 9 [RFC5912]. The OIDs 99 (id-mod- 1434 cmp2021-88) and 100 (id-mod-cmp2021-02) were registered in the SMI 1435 Security for PKIX Module Identifier registry to identify the updated 1436 ASN.1 modules. 1438 < TBD: The temporary registration of cmp URI suffix expires 1439 2022-05-20. The registration must be extended in time or update from 1440 provisional to permanent. > 1442 5. Security Considerations 1444 The security considerations of RFC 4210 [RFC4210] are extended in 1445 Section 2.21 to Section 2.23. No changes are made to the existing 1446 security considerations of RFC 6712 [RFC6712]. 1448 6. Acknowledgements 1450 Special thank goes to Jim Schaad for his guidance and the inspiration 1451 on structuring and writing this document we got from [RFC6402] which 1452 updates CMC. Special thank also goes also to Russ Housley, Lijun 1453 Liao, Martin Peylo, and Tomas Gustavsson for reviewing and providing 1454 valuable suggestions on improving this document. 1456 We also thank all reviewers of this document for their valuable 1457 feedback. 1459 7. References 1460 7.1. Normative References 1462 [I-D.ietf-lamps-cmp-algorithms] 1463 Brockhaus, H., Aschauer, H., Ounsworth, M., and J. Gray, 1464 "Certificate Management Protocol (CMP) Algorithms", Work 1465 in Progress, Internet-Draft, draft-ietf-lamps-cmp- 1466 algorithms-08, 17 November 2021, 1467 . 1470 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 1471 Requirement Levels", BCP 14, RFC 2119, 1472 DOI 10.17487/RFC2119, March 1997, 1473 . 1475 [RFC2510] Adams, C. and S. Farrell, "Internet X.509 Public Key 1476 Infrastructure Certificate Management Protocols", 1477 RFC 2510, DOI 10.17487/RFC2510, March 1999, 1478 . 1480 [RFC2985] Nystrom, M. and B. Kaliski, "PKCS #9: Selected Object 1481 Classes and Attribute Types Version 2.0", RFC 2985, 1482 DOI 10.17487/RFC2985, November 2000, 1483 . 1485 [RFC2986] Nystrom, M. and B. Kaliski, "PKCS #10: Certification 1486 Request Syntax Specification Version 1.7", RFC 2986, 1487 DOI 10.17487/RFC2986, November 2000, 1488 . 1490 [RFC4086] Eastlake 3rd, D., Schiller, J., and S. Crocker, 1491 "Randomness Requirements for Security", BCP 106, RFC 4086, 1492 DOI 10.17487/RFC4086, June 2005, 1493 . 1495 [RFC4210] Adams, C., Farrell, S., Kause, T., and T. Mononen, 1496 "Internet X.509 Public Key Infrastructure Certificate 1497 Management Protocol (CMP)", RFC 4210, 1498 DOI 10.17487/RFC4210, September 2005, 1499 . 1501 [RFC4211] Schaad, J., "Internet X.509 Public Key Infrastructure 1502 Certificate Request Message Format (CRMF)", RFC 4211, 1503 DOI 10.17487/RFC4211, September 2005, 1504 . 1506 [RFC5280] Cooper, D., Santesson, S., Farrell, S., Boeyen, S., 1507 Housley, R., and W. Polk, "Internet X.509 Public Key 1508 Infrastructure Certificate and Certificate Revocation List 1509 (CRL) Profile", RFC 5280, DOI 10.17487/RFC5280, May 2008, 1510 . 1512 [RFC5480] Turner, S., Brown, D., Yiu, K., Housley, R., and T. Polk, 1513 "Elliptic Curve Cryptography Subject Public Key 1514 Information", RFC 5480, DOI 10.17487/RFC5480, March 2009, 1515 . 1517 [RFC5652] Housley, R., "Cryptographic Message Syntax (CMS)", STD 70, 1518 RFC 5652, DOI 10.17487/RFC5652, September 2009, 1519 . 1521 [RFC5912] Hoffman, P. and J. Schaad, "New ASN.1 Modules for the 1522 Public Key Infrastructure Using X.509 (PKIX)", RFC 5912, 1523 DOI 10.17487/RFC5912, June 2010, 1524 . 1526 [RFC5958] Turner, S., "Asymmetric Key Packages", RFC 5958, 1527 DOI 10.17487/RFC5958, August 2010, 1528 . 1530 [RFC6402] Schaad, J., "Certificate Management over CMS (CMC) 1531 Updates", RFC 6402, DOI 10.17487/RFC6402, November 2011, 1532 . 1534 [RFC6712] Kause, T. and M. Peylo, "Internet X.509 Public Key 1535 Infrastructure -- HTTP Transfer for the Certificate 1536 Management Protocol (CMP)", RFC 6712, 1537 DOI 10.17487/RFC6712, September 2012, 1538 . 1540 [RFC7299] Housley, R., "Object Identifier Registry for the PKIX 1541 Working Group", RFC 7299, DOI 10.17487/RFC7299, July 2014, 1542 . 1544 [RFC8174] Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC 1545 2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174, 1546 May 2017, . 1548 [RFC8615] Nottingham, M., "Well-Known Uniform Resource Identifiers 1549 (URIs)", RFC 8615, DOI 10.17487/RFC8615, May 2019, 1550 . 1552 [RFC8933] Housley, R., "Update to the Cryptographic Message Syntax 1553 (CMS) for Algorithm Identifier Protection", RFC 8933, 1554 DOI 10.17487/RFC8933, October 2020, 1555 . 1557 [RFC9045] Housley, R., "Algorithm Requirements Update to the 1558 Internet X.509 Public Key Infrastructure Certificate 1559 Request Message Format (CRMF)", RFC 9045, 1560 DOI 10.17487/RFC9045, June 2021, 1561 . 1563 7.2. Informative References 1565 [I-D.ietf-lamps-lightweight-cmp-profile] 1566 Brockhaus, H., Fries, S., and D. V. Oheimb, "Lightweight 1567 Certificate Management Protocol (CMP) Profile", Work in 1568 Progress, Internet-Draft, draft-ietf-lamps-lightweight- 1569 cmp-profile-07, 25 October 2021, 1570 . 1573 [IEEE.802.1AR_2018] 1574 IEEE, "IEEE Standard for Local and metropolitan area 1575 networks - Secure Device Identity", IEEE 802.1AR-2018, 1576 DOI 10.1109/IEEESTD.2018.8423794, 2 August 2018, 1577 . 1579 Appendix A. ASN.1 Modules 1581 A.1. 1988 ASN.1 Module 1583 This section contains the updated ASN.1 module for [RFC4210]. This 1584 module replaces the module in Appendix F of that document. Although 1585 a 2002 ASN.1 module is provided, this 1988 ASN.1 module remains the 1586 normative module as per the policy of the PKIX working group. 1588 PKIXCMP {iso(1) identified-organization(3) 1589 dod(6) internet(1) security(5) mechanisms(5) pkix(7) 1590 id-mod(0) id-mod-cmp2021-88(99)} 1592 DEFINITIONS EXPLICIT TAGS ::= 1594 BEGIN 1596 -- EXPORTS ALL -- 1598 IMPORTS 1599 Certificate, CertificateList, Extensions, Name, Time, 1600 AlgorithmIdentifier, id-kp 1601 --, UTF8String -- -- if required; otherwise, comment out 1602 FROM PKIX1Explicit88 {iso(1) identified-organization(3) 1603 dod(6) internet(1) security(5) mechanisms(5) pkix(7) 1604 id-mod(0) id-pkix1-explicit-88(18)} 1605 -- The import of Name is added to define CertificationRequest 1606 -- instead of importing it from PKCS#10 [RFC2986] 1608 DistributionPointName, GeneralNames, GeneralName, KeyIdentifier 1609 FROM PKIX1Implicit88 {iso(1) identified-organization(3) 1610 dod(6) internet(1) security(5) mechanisms(5) pkix(7) 1611 id-mod(0) id-pkix1-implicit-88(19)} 1613 CertTemplate, PKIPublicationInfo, EncryptedKey, CertId, 1614 CertReqMessages, Controls, AttributeTypeAndValue, id-regCtrl 1615 FROM PKIXCRMF-2005 {iso(1) identified-organization(3) 1616 dod(6) internet(1) security(5) mechanisms(5) pkix(7) 1617 id-mod(0) id-mod-crmf2005(36)} 1618 -- The import of EncryptedKey is added due to the updates made 1619 -- in CMP Updates [thisRFC]]. EncryptedValue does not need to 1620 -- be imported anymore and is therefore removed here. 1622 -- see also the behavioral clarifications to CRMF codified in 1623 -- Appendix C of this specification 1625 EnvelopedData, SignedData, Attribute 1626 FROM CryptographicMessageSyntax2004 { iso(1) 1627 member-body(2) us(840) rsadsi(113549) pkcs(1) pkcs-9(9) 1628 smime(16) modules(0) cms-2004(24) } 1629 -- The import of EnvelopedData and SignedData is added due to 1630 -- the updates made in CMP Updates [thisRFC] 1631 -- The import of Attribute is added to define 1632 -- CertificationRequest instead of importing it from 1633 -- PKCS#10 [RFC2986] 1635 ; 1637 -- the rest of the module contains locally-defined OIDs and 1638 -- constructs 1640 CMPCertificate ::= CHOICE { 1641 x509v3PKCert Certificate 1642 } 1643 -- This syntax, while bits-on-the-wire compatible with the 1644 -- standard X.509 definition of "Certificate", allows the 1645 -- possibility of future certificate types (such as X.509 1646 -- attribute certificates, WAP WTLS certificates, or other kinds 1647 -- of certificates) within this certificate management protocol, 1648 -- should a need ever arise to support such generality. Those 1649 -- implementations that do not foresee a need to ever support 1650 -- other certificate types MAY, if they wish, comment out the 1651 -- above structure and "un-comment" the following one prior to 1652 -- compiling this ASN.1 module. (Note that interoperability 1653 -- with implementations that don't do this will be unaffected by 1654 -- this change.) 1656 -- CMPCertificate ::= Certificate 1658 PKIMessage ::= SEQUENCE { 1659 header PKIHeader, 1660 body PKIBody, 1661 protection [0] PKIProtection OPTIONAL, 1662 extraCerts [1] SEQUENCE SIZE (1..MAX) OF CMPCertificate 1663 OPTIONAL 1664 } 1666 PKIMessages ::= SEQUENCE SIZE (1..MAX) OF PKIMessage 1668 PKIHeader ::= SEQUENCE { 1669 pvno INTEGER { cmp1999(1), cmp2000(2), 1670 cmp2021(3) }, 1671 sender GeneralName, 1672 -- identifies the sender 1673 recipient GeneralName, 1674 -- identifies the intended recipient 1675 messageTime [0] GeneralizedTime OPTIONAL, 1676 -- time of production of this message (used when sender 1677 -- believes that the transport will be "suitable"; i.e., 1678 -- that the time will still be meaningful upon receipt) 1679 protectionAlg [1] AlgorithmIdentifier OPTIONAL, 1680 -- algorithm used for calculation of protection bits 1681 senderKID [2] KeyIdentifier OPTIONAL, 1682 recipKID [3] KeyIdentifier OPTIONAL, 1683 -- to identify specific keys used for protection 1684 transactionID [4] OCTET STRING OPTIONAL, 1685 -- identifies the transaction; i.e., this will be the same in 1686 -- corresponding request, response, certConf, and PKIConf 1687 -- messages 1688 senderNonce [5] OCTET STRING OPTIONAL, 1689 recipNonce [6] OCTET STRING OPTIONAL, 1690 -- nonces used to provide replay protection, senderNonce 1691 -- is inserted by the creator of this message; recipNonce 1692 -- is a nonce previously inserted in a related message by 1693 -- the intended recipient of this message 1694 freeText [7] PKIFreeText OPTIONAL, 1695 -- this may be used to indicate context-specific instructions 1696 -- (this field is intended for human consumption) 1697 generalInfo [8] SEQUENCE SIZE (1..MAX) OF 1698 InfoTypeAndValue OPTIONAL 1699 -- this may be used to convey context-specific information 1700 -- (this field not primarily intended for human consumption) 1701 } 1703 PKIFreeText ::= SEQUENCE SIZE (1..MAX) OF UTF8String 1704 -- text encoded as UTF-8 String [RFC3629] (note: Each 1705 -- UTF8String MAY include an [RFC3066] language tag 1706 -- to indicate the language of the contained text 1707 -- see [RFC2482] for details) 1709 PKIBody ::= CHOICE { -- message-specific body elements 1710 ir [0] CertReqMessages, --Initialization Request 1711 ip [1] CertRepMessage, --Initialization Response 1712 cr [2] CertReqMessages, --Certification Request 1713 cp [3] CertRepMessage, --Certification Response 1714 p10cr [4] CertificationRequest, --imported from [PKCS10] 1715 popdecc [5] POPODecKeyChallContent, --pop Challenge 1716 popdecr [6] POPODecKeyRespContent, --pop Response 1717 kur [7] CertReqMessages, --Key Update Request 1718 kup [8] CertRepMessage, --Key Update Response 1719 krr [9] CertReqMessages, --Key Recovery Request 1720 krp [10] KeyRecRepContent, --Key Recovery Response 1721 rr [11] RevReqContent, --Revocation Request 1722 rp [12] RevRepContent, --Revocation Response 1723 ccr [13] CertReqMessages, --Cross-Cert. Request 1724 ccp [14] CertRepMessage, --Cross-Cert. Response 1725 ckuann [15] CAKeyUpdAnnContent, --CA Key Update Ann. 1726 cann [16] CertAnnContent, --Certificate Ann. 1727 rann [17] RevAnnContent, --Revocation Ann. 1728 crlann [18] CRLAnnContent, --CRL Announcement 1729 pkiconf [19] PKIConfirmContent, --Confirmation 1730 nested [20] NestedMessageContent, --Nested Message 1731 genm [21] GenMsgContent, --General Message 1732 genp [22] GenRepContent, --General Response 1733 error [23] ErrorMsgContent, --Error Message 1734 certConf [24] CertConfirmContent, --Certificate confirm 1735 pollReq [25] PollReqContent, --Polling request 1736 pollRep [26] PollRepContent --Polling response 1737 } 1739 PKIProtection ::= BIT STRING 1741 ProtectedPart ::= SEQUENCE { 1742 header PKIHeader, 1743 body PKIBody 1744 } 1746 id-PasswordBasedMac OBJECT IDENTIFIER ::= {1 2 840 113533 7 66 13} 1747 PBMParameter ::= SEQUENCE { 1748 salt OCTET STRING, 1749 -- note: implementations MAY wish to limit acceptable sizes 1750 -- of this string to values appropriate for their environment 1751 -- in order to reduce the risk of denial-of-service attacks 1752 owf AlgorithmIdentifier, 1753 -- AlgId for a One-Way Function (SHA-1 recommended) 1754 iterationCount INTEGER, 1755 -- number of times the OWF is applied 1756 -- note: implementations MAY wish to limit acceptable sizes 1757 -- of this integer to values appropriate for their environment 1758 -- in order to reduce the risk of denial-of-service attacks 1759 mac AlgorithmIdentifier 1760 -- the MAC AlgId (e.g., DES-MAC, Triple-DES-MAC [PKCS11], 1761 } -- or HMAC [RFC2104, RFC2202]) 1763 id-DHBasedMac OBJECT IDENTIFIER ::= {1 2 840 113533 7 66 30} 1764 DHBMParameter ::= SEQUENCE { 1765 owf AlgorithmIdentifier, 1766 -- AlgId for a One-Way Function (SHA-1 recommended) 1767 mac AlgorithmIdentifier 1768 -- the MAC AlgId (e.g., DES-MAC, Triple-DES-MAC [PKCS11], 1769 } -- or HMAC [RFC2104, RFC2202]) 1771 NestedMessageContent ::= PKIMessages 1773 PKIStatus ::= INTEGER { 1774 accepted (0), 1775 -- you got exactly what you asked for 1776 grantedWithMods (1), 1777 -- you got something like what you asked for; the 1778 -- requester is responsible for ascertaining the differences 1779 rejection (2), 1780 -- you don't get it, more information elsewhere in the message 1781 waiting (3), 1782 -- the request body part has not yet been processed; expect to 1783 -- hear more later (note: proper handling of this status 1784 -- response MAY use the polling req/rep PKIMessages specified 1785 -- in Section 5.3.22; alternatively, polling in the underlying 1786 -- transport layer MAY have some utility in this regard) 1787 revocationWarning (4), 1788 -- this message contains a warning that a revocation is 1789 -- imminent 1790 revocationNotification (5), 1791 -- notification that a revocation has occurred 1792 keyUpdateWarning (6) 1793 -- update already done for the oldCertId specified in 1794 -- CertReqMsg 1795 } 1797 PKIFailureInfo ::= BIT STRING { 1798 -- since we can fail in more than one way! 1799 -- More codes may be added in the future if/when required. 1800 badAlg (0), 1801 -- unrecognized or unsupported Algorithm Identifier 1802 badMessageCheck (1), 1803 -- integrity check failed (e.g., signature did not verify) 1804 badRequest (2), 1805 -- transaction not permitted or supported 1806 badTime (3), 1807 -- messageTime was not sufficiently close to the system time, 1808 -- as defined by local policy 1809 badCertId (4), 1810 -- no certificate could be found matching the provided criteria 1811 badDataFormat (5), 1812 -- the data submitted has the wrong format 1813 wrongAuthority (6), 1814 -- the authority indicated in the request is different from the 1815 -- one creating the response token 1816 incorrectData (7), 1817 -- the requester's data is incorrect (for notary services) 1818 missingTimeStamp (8), 1819 -- when the timestamp is missing but should be there 1820 -- (by policy) 1821 badPOP (9), 1822 -- the proof-of-possession failed 1823 certRevoked (10), 1824 -- the certificate has already been revoked 1825 certConfirmed (11), 1826 -- the certificate has already been confirmed 1827 wrongIntegrity (12), 1828 -- invalid integrity, password based instead of signature or 1829 -- vice versa 1830 badRecipientNonce (13), 1831 -- invalid recipient nonce, either missing or wrong value 1832 timeNotAvailable (14), 1833 -- the TSA's time source is not available 1834 unacceptedPolicy (15), 1835 -- the requested TSA policy is not supported by the TSA. 1836 unacceptedExtension (16), 1837 -- the requested extension is not supported by the TSA. 1839 addInfoNotAvailable (17), 1840 -- the additional information requested could not be 1841 -- understood or is not available 1842 badSenderNonce (18), 1843 -- invalid sender nonce, either missing or wrong size 1844 badCertTemplate (19), 1845 -- invalid cert. template or missing mandatory information 1846 signerNotTrusted (20), 1847 -- signer of the message unknown or not trusted 1848 transactionIdInUse (21), 1849 -- the transaction identifier is already in use 1850 unsupportedVersion (22), 1851 -- the version of the message is not supported 1852 notAuthorized (23), 1853 -- the sender was not authorized to make the preceding 1854 -- request or perform the preceding action 1855 systemUnavail (24), 1856 -- the request cannot be handled due to system unavailability 1857 systemFailure (25), 1858 -- the request cannot be handled due to system failure 1859 duplicateCertReq (26) 1860 -- certificate cannot be issued because a duplicate 1861 -- certificate already exists 1862 } 1864 PKIStatusInfo ::= SEQUENCE { 1865 status PKIStatus, 1866 statusString PKIFreeText OPTIONAL, 1867 failInfo PKIFailureInfo OPTIONAL 1868 } 1870 OOBCert ::= CMPCertificate 1872 OOBCertHash ::= SEQUENCE { 1873 hashAlg [0] AlgorithmIdentifier OPTIONAL, 1874 certId [1] CertId OPTIONAL, 1875 hashVal BIT STRING 1876 -- hashVal is calculated over the DER encoding of the 1877 -- self-signed certificate with the identifier certID. 1878 } 1880 POPODecKeyChallContent ::= SEQUENCE OF Challenge 1881 -- One Challenge per encryption key certification request (in the 1882 -- same order as these requests appear in CertReqMessages). 1884 Challenge ::= SEQUENCE { 1885 owf AlgorithmIdentifier OPTIONAL, 1886 -- MUST be present in the first Challenge; MAY be omitted in 1887 -- any subsequent Challenge in POPODecKeyChallContent (if 1888 -- omitted, then the owf used in the immediately preceding 1889 -- Challenge is to be used). 1890 witness OCTET STRING, 1891 -- the result of applying the one-way function (owf) to a 1892 -- randomly-generated INTEGER, A. [Note that a different 1893 -- INTEGER MUST be used for each Challenge.] 1894 challenge OCTET STRING 1895 -- the encryption (under the public key for which the cert. 1896 -- request is being made) of Rand. 1897 } 1899 -- Added in CMP Updates [thisRFC] 1901 Rand ::= SEQUENCE { 1902 -- Rand is encrypted under the public key to form the challenge 1903 -- in POPODecKeyChallContent 1904 int INTEGER, 1905 -- the randomly-generated INTEGER A (above) 1906 sender GeneralName 1907 -- the sender's name (as included in PKIHeader) 1908 } 1910 POPODecKeyRespContent ::= SEQUENCE OF INTEGER 1911 -- One INTEGER per encryption key certification request (in the 1912 -- same order as these requests appear in CertReqMessages). The 1913 -- retrieved INTEGER A (above) is returned to the sender of the 1914 -- corresponding Challenge. 1916 CertRepMessage ::= SEQUENCE { 1917 caPubs [1] SEQUENCE SIZE (1..MAX) OF CMPCertificate 1918 OPTIONAL, 1919 response SEQUENCE OF CertResponse 1920 } 1922 CertificationRequest ::= SEQUENCE { 1923 certificationRequestInfo SEQUENCE { 1924 version INTEGER, 1925 subject Name, 1926 subjectPublicKeyInfo SEQUENCE { 1927 algorithm AlgorithmIdentifier, 1928 subjectPublicKey BIT STRING }, 1929 attributes [0] IMPLICIT SET OF Attribute }, 1930 signatureAlgorithm AlgorithmIdentifier, 1931 signature BIT STRING 1932 } 1934 CertResponse ::= SEQUENCE { 1935 certReqId INTEGER, 1936 -- to match this response with corresponding request (a value 1937 -- of -1 is to be used if certReqId is not specified in the 1938 -- corresponding request, which can only be a p10cr) 1939 status PKIStatusInfo, 1940 certifiedKeyPair CertifiedKeyPair OPTIONAL, 1941 rspInfo OCTET STRING OPTIONAL 1942 -- analogous to the id-regInfo-utf8Pairs string defined 1943 -- for regInfo in CertReqMsg [CRMF] 1944 } 1946 CertifiedKeyPair ::= SEQUENCE { 1947 certOrEncCert CertOrEncCert, 1948 privateKey [0] EncryptedKey OPTIONAL, 1949 -- see [CRMF] for comment on encoding 1950 -- Changed from Encrypted Value to EncryptedKey as a CHOICE of 1951 -- EncryptedValue and EnvelopedData due to the changes made in 1952 -- CMP Updates [thisRFC] 1953 -- Using the choice EncryptedValue is bit-compatible to the 1954 -- syntax without this change 1955 publicationInfo [1] PKIPublicationInfo OPTIONAL 1956 } 1958 CertOrEncCert ::= CHOICE { 1959 certificate [0] CMPCertificate, 1960 encryptedCert [1] EncryptedKey 1961 -- Changed from Encrypted Value to EncryptedKey as a CHOICE of 1962 -- EncryptedValue and EnvelopedData due to the changes made in 1963 -- CMP Updates [thisRFC] 1964 -- Using the choice EncryptedValue is bit-compatible to the 1965 -- syntax without this change 1966 } 1968 KeyRecRepContent ::= SEQUENCE { 1969 status PKIStatusInfo, 1970 newSigCert [0] CMPCertificate OPTIONAL, 1971 caCerts [1] SEQUENCE SIZE (1..MAX) OF 1972 CMPCertificate OPTIONAL, 1973 keyPairHist [2] SEQUENCE SIZE (1..MAX) OF 1974 CertifiedKeyPair OPTIONAL 1975 } 1977 RevReqContent ::= SEQUENCE OF RevDetails 1979 RevDetails ::= SEQUENCE { 1980 certDetails CertTemplate, 1981 -- allows requester to specify as much as they can about 1982 -- the cert. for which revocation is requested 1983 -- (e.g., for cases in which serialNumber is not available) 1984 crlEntryDetails Extensions OPTIONAL 1985 -- requested crlEntryExtensions 1986 } 1988 RevRepContent ::= SEQUENCE { 1989 status SEQUENCE SIZE (1..MAX) OF PKIStatusInfo, 1990 -- in same order as was sent in RevReqContent 1991 revCerts [0] SEQUENCE SIZE (1..MAX) OF CertId 1992 OPTIONAL, 1993 -- IDs for which revocation was requested 1994 -- (same order as status) 1995 crls [1] SEQUENCE SIZE (1..MAX) OF CertificateList 1996 OPTIONAL 1997 -- the resulting CRLs (there may be more than one) 1998 } 2000 CAKeyUpdAnnContent ::= SEQUENCE { 2001 oldWithNew CMPCertificate, -- old pub signed with new priv 2002 newWithOld CMPCertificate, -- new pub signed with old priv 2003 newWithNew CMPCertificate -- new pub signed with new priv 2004 } 2006 CertAnnContent ::= CMPCertificate 2008 RevAnnContent ::= SEQUENCE { 2009 status PKIStatus, 2010 certId CertId, 2011 willBeRevokedAt GeneralizedTime, 2012 badSinceDate GeneralizedTime, 2013 crlDetails Extensions OPTIONAL 2014 -- extra CRL details (e.g., crl number, reason, location, etc.) 2015 } 2017 CRLAnnContent ::= SEQUENCE OF CertificateList 2019 CertConfirmContent ::= SEQUENCE OF CertStatus 2021 CertStatus ::= SEQUENCE { 2022 certHash OCTET STRING, 2023 -- the hash of the certificate, using the same hash algorithm 2024 -- as is used to create and verify the certificate signature 2025 certReqId INTEGER, 2026 -- to match this confirmation with the corresponding req/rep 2027 statusInfo PKIStatusInfo OPTIONAL, 2028 hashAlg [0] AlgorithmIdentifier OPTIONAL 2029 -- the hash algorithm to use for calculating certHash 2030 -- SHOULD NOT be used in all cases where the AlgorithmIdentifier 2031 -- of the certificate signature specifies a hash algorithm 2032 } 2034 PKIConfirmContent ::= NULL 2036 -- CertReqTemplateContent, id-regCtrl-algId, id-regCtrl-algId, and 2037 -- id-regCtrl-rsaKeyLen were added in CMP Updates [thisRFC] 2039 CertReqTemplateContent ::= SEQUENCE { 2040 certTemplate CertTemplate, 2041 -- prefilled certTemplate structure elements 2042 -- The SubjectPublicKeyInfo field in the certTemplate MUST NOT 2043 -- be used. 2044 keySpec Controls OPTIONAL 2045 -- MAY be used to specify supported algorithms. 2046 -- Controls ::= SEQUENCE SIZE (1..MAX) OF AttributeTypeAndValue 2047 -- as specified in CRMF (RFC4211) 2048 } 2050 id-regCtrl-altCertTemplate OBJECT IDENTIFIER ::= { id-regCtrl 7 } 2051 AltCertTemplate ::= AttributeTypeAndValue 2052 -- specifies a template for a certificate other than an X.509v3 2053 -- public-key certificate 2055 id-regCtrl-algId OBJECT IDENTIFIER ::= { id-regCtrl 11 } 2056 AlgIdCtrl ::= AlgorithmIdentifier 2057 -- SHALL be used to specify supported algorithms other than RSA 2059 id-regCtrl-rsaKeyLen OBJECT IDENTIFIER ::= { id-regCtrl 12 } 2060 RsaKeyLenCtrl ::= INTEGER (1..MAX) 2061 -- SHALL be used to specify supported RSA key lengths 2063 -- RootCaKeyUpdateContent, CRLSource, and CRLStatus were added in 2064 -- CMP Updates [thisRFC] 2066 RootCaKeyUpdateContent ::= SEQUENCE { 2067 newWithNew CMPCertificate, 2068 -- new root CA certificate 2069 newWithOld [0] CMPCertificate OPTIONAL, 2070 -- X.509 certificate containing the new public root CA key 2071 -- signed with the old private root CA key 2072 oldWithNew [1] CMPCertificate OPTIONAL 2073 -- X.509 certificate containing the old public root CA key 2074 -- signed with the new private root CA key 2075 } 2077 CRLSource ::= CHOICE { 2078 dpn [0] DistributionPointName, 2079 issuer [1] GeneralNames } 2081 CRLStatus ::= SEQUENCE { 2082 source CRLSource, 2083 thisUpdate Time OPTIONAL } 2085 InfoTypeAndValue ::= SEQUENCE { 2086 infoType OBJECT IDENTIFIER, 2087 infoValue ANY DEFINED BY infoType OPTIONAL 2088 } 2089 -- Example InfoTypeAndValue contents include, but are not limited 2090 -- to, the following (un-comment in this ASN.1 module and use as 2091 -- appropriate for a given environment): 2092 -- 2093 -- id-it-caProtEncCert OBJECT IDENTIFIER ::= {id-it 1} 2094 -- CAProtEncCertValue ::= CMPCertificate 2095 -- id-it-signKeyPairTypes OBJECT IDENTIFIER ::= {id-it 2} 2096 -- SignKeyPairTypesValue ::= SEQUENCE SIZE (1..MAX) OF 2097 -- AlgorithmIdentifier 2098 -- id-it-encKeyPairTypes OBJECT IDENTIFIER ::= {id-it 3} 2099 -- EncKeyPairTypesValue ::= SEQUENCE SIZE (1..MAX) OF 2100 -- AlgorithmIdentifier 2101 -- id-it-preferredSymmAlg OBJECT IDENTIFIER ::= {id-it 4} 2102 -- PreferredSymmAlgValue ::= AlgorithmIdentifier 2103 -- id-it-caKeyUpdateInfo OBJECT IDENTIFIER ::= {id-it 5} 2104 -- CAKeyUpdateInfoValue ::= CAKeyUpdAnnContent 2105 -- id-it-currentCRL OBJECT IDENTIFIER ::= {id-it 6} 2106 -- CurrentCRLValue ::= CertificateList 2107 -- id-it-unsupportedOIDs OBJECT IDENTIFIER ::= {id-it 7} 2108 -- UnsupportedOIDsValue ::= SEQUENCE SIZE (1..MAX) OF 2109 -- OBJECT IDENTIFIER 2110 -- id-it-keyPairParamReq OBJECT IDENTIFIER ::= {id-it 10} 2111 -- KeyPairParamReqValue ::= OBJECT IDENTIFIER 2112 -- id-it-keyPairParamRep OBJECT IDENTIFIER ::= {id-it 11} 2113 -- KeyPairParamRepValue ::= AlgorithmIdentifier 2114 -- id-it-revPassphrase OBJECT IDENTIFIER ::= {id-it 12} 2115 -- RevPassphraseValue ::= EncryptedKey 2116 -- - Changed from Encrypted Value to EncryptedKey as a CHOICE 2117 -- - of EncryptedValue and EnvelopedData due to the changes 2118 -- - made in CMP Updates [thisRFC] 2119 -- - Using the choice EncryptedValue is bit-compatible to the 2120 -- - syntax without this change 2121 -- id-it-implicitConfirm OBJECT IDENTIFIER ::= {id-it 13} 2122 -- ImplicitConfirmValue ::= NULL 2123 -- id-it-confirmWaitTime OBJECT IDENTIFIER ::= {id-it 14} 2124 -- ConfirmWaitTimeValue ::= GeneralizedTime 2125 -- id-it-origPKIMessage OBJECT IDENTIFIER ::= {id-it 15} 2126 -- OrigPKIMessageValue ::= PKIMessages 2127 -- id-it-suppLangTags OBJECT IDENTIFIER ::= {id-it 16} 2128 -- SuppLangTagsValue ::= SEQUENCE OF UTF8String 2129 -- id-it-caCerts OBJECT IDENTIFIER ::= {id-it 17} 2130 -- CaCertsValue ::= SEQUENCE SIZE (1..MAX) OF 2131 -- CMPCertificate 2132 -- - id-it-caCerts added in CMP Updates [thisRFC] 2133 -- id-it-rootCaKeyUpdate OBJECT IDENTIFIER ::= {id-it 18} 2134 -- RootCaKeyUpdateValue ::= RootCaKeyUpdateContent 2135 -- - id-it-rootCaKeyUpdate added in CMP Updates [thisRFC] 2136 -- id-it-certReqTemplate OBJECT IDENTIFIER ::= {id-it 19} 2137 -- CertReqTemplateValue ::= CertReqTemplateContent 2138 -- - id-it-certReqTemplate added in CMP Updates [thisRFC] 2139 -- id-it-rootCaCert OBJECT IDENTIFIER ::= {id-it 20} 2140 -- RootCaCertValue ::= CMPCertificate 2141 -- - id-it-rootCaCert added in CMP Updates [thisRFC] 2142 -- id-it-certProfile OBJECT IDENTIFIER ::= {id-it 21} 2143 -- CertProfileValue ::= SEQUENCE SIZE (1..MAX) OF 2144 -- UTF8String 2145 -- - id-it-certProfile added in CMP Updates [thisRFC] 2146 -- id-it-crlStatusList OBJECT IDENTIFIER ::= {id-it TBD1} 2147 -- CRLStatusListValue ::= SEQUENCE SIZE (1..MAX) OF 2148 -- CRLStatus 2149 -- - id-it-crlStatusList added in CMP Updates [thisRFC] 2150 -- id-it-crls OBJECT IDENTIFIER ::= {id-it TBD2} 2151 -- CRLsValue ::= SEQUENCE SIZE (1..MAX) OF 2152 -- CertificateList 2153 -- - id-it-crls added in CMP Updates [thisRFC] 2154 -- 2155 -- where 2156 -- 2157 -- id-pkix OBJECT IDENTIFIER ::= { 2158 -- iso(1) identified-organization(3) 2159 -- dod(6) internet(1) security(5) mechanisms(5) pkix(7)} 2160 -- and 2161 -- id-it OBJECT IDENTIFIER ::= {id-pkix 4} 2162 -- 2163 -- 2164 -- This construct MAY also be used to define new PKIX Certificate 2165 -- Management Protocol request and response messages, or general- 2166 -- purpose (e.g., announcement) messages for future needs or for 2167 -- specific environments. 2169 GenMsgContent ::= SEQUENCE OF InfoTypeAndValue 2171 -- May be sent by EE, RA, or CA (depending on message content). 2172 -- The OPTIONAL infoValue parameter of InfoTypeAndValue will 2173 -- typically be omitted for some of the examples given above. 2174 -- The receiver is free to ignore any contained OBJ. IDs that it 2175 -- does not recognize. If sent from EE to CA, the empty set 2176 -- indicates that the CA may send 2177 -- any/all information that it wishes. 2179 GenRepContent ::= SEQUENCE OF InfoTypeAndValue 2180 -- Receiver MAY ignore any contained OIDs that it does not 2181 -- recognize. 2183 ErrorMsgContent ::= SEQUENCE { 2184 pKIStatusInfo PKIStatusInfo, 2185 errorCode INTEGER OPTIONAL, 2186 -- implementation-specific error codes 2187 errorDetails PKIFreeText OPTIONAL 2188 -- implementation-specific error details 2189 } 2191 PollReqContent ::= SEQUENCE OF SEQUENCE { 2192 certReqId INTEGER 2193 } 2195 PollRepContent ::= SEQUENCE OF SEQUENCE { 2196 certReqId INTEGER, 2197 checkAfter INTEGER, -- time in seconds 2198 reason PKIFreeText OPTIONAL 2199 } 2201 -- 2202 -- Extended Key Usage extension for PKI entities used in CMP 2203 -- operations, added due to the changes made in 2204 -- CMP Updates [thisRFC] 2205 -- The EKUs for the CA and RA are reused from CMC as defined in 2206 -- [RFC6402] 2207 -- 2209 -- id-kp-cmcCA OBJECT IDENTIFIER ::= { id-kp 27 } 2210 -- id-kp-cmcRA OBJECT IDENTIFIER ::= { id-kp 28 } 2211 id-kp-cmKGA OBJECT IDENTIFIER ::= { id-kp 32 } 2213 -- There is no 1988 ASN.1 module of PKCS#9 available to import the 2214 -- syntax of the localKeyId attribute type and value from. Therefore, 2215 -- the syntax is added here as needed for the updates made in 2216 -- CMP Updates [thisRFC] 2218 pkcs-9 OBJECT IDENTIFIER ::= {iso(1) member-body(2) us(840) 2219 rsadsi(113549) pkcs(1) 9} 2221 pkcs-9-at-localKeyId OBJECT IDENTIFIER ::= {pkcs-9 21} 2222 LocalKeyIdValue ::= OCTET STRING 2224 END -- of CMP module 2226 A.2. 2002 ASN.1 Module 2228 This section contains the updated 2002 ASN.1 module for [RFC5912]. 2229 This module replaces the module in Section 9 of that document. The 2230 module contains those changes to the normative ASN.1 module from 2231 RFC4210 Appendix F [RFC4210] that were to update to 2002 ASN.1 2232 standard done in [RFC5912] as well as changes made in this document. 2234 PKIXCMP-2021 2235 { iso(1) identified-organization(3) dod(6) internet(1) 2236 security(5) mechanisms(5) pkix(7) id-mod(0) 2237 id-mod-cmp2021-02(100) } 2238 DEFINITIONS EXPLICIT TAGS ::= 2239 BEGIN 2240 IMPORTS 2242 AttributeSet{}, SingleAttribute{}, Extensions{}, EXTENSION, ATTRIBUTE 2243 FROM PKIX-CommonTypes-2009 2244 {iso(1) identified-organization(3) dod(6) internet(1) security(5) 2245 mechanisms(5) pkix(7) id-mod(0) id-mod-pkixCommon-02(57)} 2247 AlgorithmIdentifier{}, SIGNATURE-ALGORITHM, ALGORITHM, 2248 DIGEST-ALGORITHM, MAC-ALGORITHM 2249 FROM AlgorithmInformation-2009 2250 {iso(1) identified-organization(3) dod(6) internet(1) security(5) 2251 mechanisms(5) pkix(7) id-mod(0) 2252 id-mod-algorithmInformation-02(58)} 2254 Certificate, CertificateList, Time, id-kp 2255 FROM PKIX1Explicit-2009 2256 {iso(1) identified-organization(3) dod(6) internet(1) security(5) 2257 mechanisms(5) pkix(7) id-mod(0) id-mod-pkix1-explicit-02(51)} 2259 DistributionPointName, GeneralNames, GeneralName, KeyIdentifier 2260 FROM PKIX1Implicit-2009 2261 {iso(1) identified-organization(3) dod(6) internet(1) security(5) 2262 mechanisms(5) pkix(7) id-mod(0) id-mod-pkix1-implicit-02(59)} 2264 CertTemplate, PKIPublicationInfo, EncryptedKey, CertId, 2265 CertReqMessages, Controls, RegControlSet, id-regCtrl 2266 FROM PKIXCRMF-2009 2267 { iso(1) identified-organization(3) dod(6) internet(1) 2268 security(5) mechanisms(5) pkix(7) id-mod(0) 2269 id-mod-crmf2005-02(55) } 2270 -- The import of EncryptedKey is added due to the updates made 2271 -- in CMP Updates [thisRFC]. EncryptedValue does not need to 2272 -- be imported anymore and is therefore removed here. 2274 -- see also the behavioral clarifications to CRMF codified in 2275 -- Appendix C of this specification 2277 CertificationRequest 2278 FROM PKCS-10 2279 {iso(1) identified-organization(3) dod(6) internet(1) security(5) 2280 mechanisms(5) pkix(7) id-mod(0) id-mod-pkcs10-2009(69)} 2281 -- (specified in RFC 2986 with 1993 ASN.1 syntax and IMPLICIT 2282 -- tags). Alternatively, implementers may directly include 2283 -- the [PKCS10] syntax in this module 2285 localKeyId 2286 FROM PKCS-9 2287 {iso(1) member-body(2) us(840) rsadsi(113549) pkcs(1) pkcs-9(9) 2288 modules(0) pkcs-9(1)} 2289 -- The import of localKeyId is added due to the updates made in 2290 -- CMP Updates [thisRFC] 2292 EnvelopedData, SignedData 2293 FROM CryptographicMessageSyntax-2009 2294 {iso(1) member-body(2) us(840) rsadsi(113549) pkcs(1) pkcs-9(9) 2295 smime(16) modules(0) id-mod-cms-2004-02(41)} 2296 -- The import of EnvelopedData and SignedData is added due to 2297 -- the updates made in CMP Updates [thisRFC] 2298 ; 2300 -- the rest of the module contains locally defined OIDs and 2301 -- constructs 2303 CMPCertificate ::= CHOICE { x509v3PKCert Certificate, ... } 2304 -- This syntax, while bits-on-the-wire compatible with the 2305 -- standard X.509 definition of "Certificate", allows the 2306 -- possibility of future certificate types (such as X.509 2307 -- attribute certificates, WAP WTLS certificates, or other kinds 2308 -- of certificates) within this certificate management protocol, 2309 -- should a need ever arise to support such generality. Those 2310 -- implementations that do not foresee a need to ever support 2311 -- other certificate types MAY, if they wish, comment out the 2312 -- above structure and "uncomment" the following one prior to 2313 -- compiling this ASN.1 module. (Note that interoperability 2314 -- with implementations that don't do this will be unaffected by 2315 -- this change.) 2317 -- CMPCertificate ::= Certificate 2318 PKIMessage ::= SEQUENCE { 2319 header PKIHeader, 2320 body PKIBody, 2321 protection [0] PKIProtection OPTIONAL, 2322 extraCerts [1] SEQUENCE SIZE (1..MAX) OF CMPCertificate 2323 OPTIONAL } 2325 PKIMessages ::= SEQUENCE SIZE (1..MAX) OF PKIMessage 2327 PKIHeader ::= SEQUENCE { 2328 pvno INTEGER { cmp1999(1), cmp2000(2), 2329 cmp2012(3) }, 2330 sender GeneralName, 2331 -- identifies the sender 2332 recipient GeneralName, 2333 -- identifies the intended recipient 2334 messageTime [0] GeneralizedTime OPTIONAL, 2335 -- time of production of this message (used when sender 2336 -- believes that the transport will be "suitable"; i.e., 2337 -- that the time will still be meaningful upon receipt) 2338 protectionAlg [1] AlgorithmIdentifier{ALGORITHM, {...}} 2339 OPTIONAL, 2340 -- algorithm used for calculation of protection bits 2341 senderKID [2] KeyIdentifier OPTIONAL, 2342 recipKID [3] KeyIdentifier OPTIONAL, 2343 -- to identify specific keys used for protection 2344 transactionID [4] OCTET STRING OPTIONAL, 2345 -- identifies the transaction; i.e., this will be the same in 2346 -- corresponding request, response, certConf, and PKIConf 2347 -- messages 2348 senderNonce [5] OCTET STRING OPTIONAL, 2349 recipNonce [6] OCTET STRING OPTIONAL, 2350 -- nonces used to provide replay protection, senderNonce 2351 -- is inserted by the creator of this message; recipNonce 2352 -- is a nonce previously inserted in a related message by 2353 -- the intended recipient of this message 2354 freeText [7] PKIFreeText OPTIONAL, 2355 -- this may be used to indicate context-specific instructions 2356 -- (this field is intended for human consumption) 2357 generalInfo [8] SEQUENCE SIZE (1..MAX) OF 2358 InfoTypeAndValue OPTIONAL 2359 -- this may be used to convey context-specific information 2360 -- (this field not primarily intended for human consumption) 2361 } 2363 PKIFreeText ::= SEQUENCE SIZE (1..MAX) OF UTF8String 2364 -- text encoded as UTF-8 String [RFC3629] (note: each 2365 -- UTF8String MAY include an [RFC3066] language tag 2366 -- to indicate the language of the contained text; 2367 -- see [RFC2482] for details) 2369 PKIBody ::= CHOICE { -- message-specific body elements 2370 ir [0] CertReqMessages, --Initialization Request 2371 ip [1] CertRepMessage, --Initialization Response 2372 cr [2] CertReqMessages, --Certification Request 2373 cp [3] CertRepMessage, --Certification Response 2374 p10cr [4] CertificationRequest, --imported from [PKCS10] 2375 popdecc [5] POPODecKeyChallContent, --pop Challenge 2376 popdecr [6] POPODecKeyRespContent, --pop Response 2377 kur [7] CertReqMessages, --Key Update Request 2378 kup [8] CertRepMessage, --Key Update Response 2379 krr [9] CertReqMessages, --Key Recovery Request 2380 krp [10] KeyRecRepContent, --Key Recovery Response 2381 rr [11] RevReqContent, --Revocation Request 2382 rp [12] RevRepContent, --Revocation Response 2383 ccr [13] CertReqMessages, --Cross-Cert. Request 2384 ccp [14] CertRepMessage, --Cross-Cert. Response 2385 ckuann [15] CAKeyUpdAnnContent, --CA Key Update Ann. 2386 cann [16] CertAnnContent, --Certificate Ann. 2387 rann [17] RevAnnContent, --Revocation Ann. 2388 crlann [18] CRLAnnContent, --CRL Announcement 2389 pkiconf [19] PKIConfirmContent, --Confirmation 2390 nested [20] NestedMessageContent, --Nested Message 2391 genm [21] GenMsgContent, --General Message 2392 genp [22] GenRepContent, --General Response 2393 error [23] ErrorMsgContent, --Error Message 2394 certConf [24] CertConfirmContent, --Certificate confirm 2395 pollReq [25] PollReqContent, --Polling request 2396 pollRep [26] PollRepContent --Polling response 2397 } 2399 PKIProtection ::= BIT STRING 2401 ProtectedPart ::= SEQUENCE { 2402 header PKIHeader, 2403 body PKIBody } 2405 id-PasswordBasedMac OBJECT IDENTIFIER ::= { iso(1) member-body(2) 2406 usa(840) nt(113533) nsn(7) algorithms(66) 13 } 2407 PBMParameter ::= SEQUENCE { 2408 salt OCTET STRING, 2409 -- note: implementations MAY wish to limit acceptable sizes 2410 -- of this string to values appropriate for their environment 2411 -- in order to reduce the risk of denial-of-service attacks 2412 owf AlgorithmIdentifier{DIGEST-ALGORITHM, {...}}, 2413 -- AlgId for a One-Way Function (SHA-1 recommended) 2414 iterationCount INTEGER, 2415 -- number of times the OWF is applied 2416 -- note: implementations MAY wish to limit acceptable sizes 2417 -- of this integer to values appropriate for their environment 2418 -- in order to reduce the risk of denial-of-service attacks 2419 mac AlgorithmIdentifier{MAC-ALGORITHM, {...}} 2420 -- the MAC AlgId (e.g., DES-MAC, Triple-DES-MAC [PKCS11], 2421 -- or HMAC [RFC2104, RFC2202]) 2422 } 2424 id-DHBasedMac OBJECT IDENTIFIER ::= { iso(1) member-body(2) 2425 usa(840) nt(113533) nsn(7) algorithms(66) 30 } 2426 DHBMParameter ::= SEQUENCE { 2427 owf AlgorithmIdentifier{DIGEST-ALGORITHM, {...}}, 2428 -- AlgId for a One-Way Function (SHA-1 recommended) 2429 mac AlgorithmIdentifier{MAC-ALGORITHM, {...}} 2430 -- the MAC AlgId (e.g., DES-MAC, Triple-DES-MAC [PKCS11], 2431 -- or HMAC [RFC2104, RFC2202]) 2432 } 2434 PKIStatus ::= INTEGER { 2435 accepted (0), 2436 -- you got exactly what you asked for 2437 grantedWithMods (1), 2438 -- you got something like what you asked for; the 2439 -- requester is responsible for ascertaining the differences 2440 rejection (2), 2441 -- you don't get it, more information elsewhere in the message 2442 waiting (3), 2443 -- the request body part has not yet been processed; expect to 2444 -- hear more later (note: proper handling of this status 2445 -- response MAY use the polling req/rep PKIMessages specified 2446 -- in Section 5.3.22; alternatively, polling in the underlying 2447 -- transport layer MAY have some utility in this regard) 2448 revocationWarning (4), 2449 -- this message contains a warning that a revocation is 2450 -- imminent 2451 revocationNotification (5), 2452 -- notification that a revocation has occurred 2453 keyUpdateWarning (6) 2454 -- update already done for the oldCertId specified in 2455 -- CertReqMsg 2456 } 2458 PKIFailureInfo ::= BIT STRING { 2459 -- since we can fail in more than one way! 2460 -- More codes may be added in the future if/when required. 2461 badAlg (0), 2462 -- unrecognized or unsupported Algorithm Identifier 2463 badMessageCheck (1), 2464 -- integrity check failed (e.g., signature did not verify) 2465 badRequest (2), 2466 -- transaction not permitted or supported 2467 badTime (3), 2468 -- messageTime was not sufficiently close to the system time, 2469 -- as defined by local policy 2470 badCertId (4), 2471 -- no certificate could be found matching the provided criteria 2472 badDataFormat (5), 2473 -- the data submitted has the wrong format 2474 wrongAuthority (6), 2475 -- the authority indicated in the request is different from the 2476 -- one creating the response token 2477 incorrectData (7), 2478 -- the requester's data is incorrect (for notary services) 2479 missingTimeStamp (8), 2480 -- when the timestamp is missing but should be there 2481 -- (by policy) 2482 badPOP (9), 2483 -- the proof-of-possession failed 2484 certRevoked (10), 2485 -- the certificate has already been revoked 2486 certConfirmed (11), 2487 -- the certificate has already been confirmed 2488 wrongIntegrity (12), 2489 -- invalid integrity, password based instead of signature or 2490 -- vice versa 2491 badRecipientNonce (13), 2492 -- invalid recipient nonce, either missing or wrong value 2493 timeNotAvailable (14), 2494 -- the TSA's time source is not available 2495 unacceptedPolicy (15), 2496 -- the requested TSA policy is not supported by the TSA 2497 unacceptedExtension (16), 2498 -- the requested extension is not supported by the TSA 2499 addInfoNotAvailable (17), 2500 -- the additional information requested could not be 2501 -- understood or is not available 2502 badSenderNonce (18), 2503 -- invalid sender nonce, either missing or wrong size 2504 badCertTemplate (19), 2505 -- invalid cert. template or missing mandatory information 2506 signerNotTrusted (20), 2507 -- signer of the message unknown or not trusted 2508 transactionIdInUse (21), 2509 -- the transaction identifier is already in use 2510 unsupportedVersion (22), 2511 -- the version of the message is not supported 2512 notAuthorized (23), 2513 -- the sender was not authorized to make the preceding 2514 -- request or perform the preceding action 2515 systemUnavail (24), 2516 -- the request cannot be handled due to system unavailability 2517 systemFailure (25), 2518 -- the request cannot be handled due to system failure 2519 duplicateCertReq (26) 2520 -- certificate cannot be issued because a duplicate 2521 -- certificate already exists 2522 } 2524 PKIStatusInfo ::= SEQUENCE { 2525 status PKIStatus, 2526 statusString PKIFreeText OPTIONAL, 2527 failInfo PKIFailureInfo OPTIONAL } 2529 OOBCert ::= CMPCertificate 2531 OOBCertHash ::= SEQUENCE { 2532 hashAlg [0] AlgorithmIdentifier{DIGEST-ALGORITHM, {...}} 2533 OPTIONAL, 2534 certId [1] CertId OPTIONAL, 2535 hashVal BIT STRING 2536 -- hashVal is calculated over the DER encoding of the 2537 -- self-signed certificate with the identifier certID. 2538 } 2540 POPODecKeyChallContent ::= SEQUENCE OF Challenge 2541 -- One Challenge per encryption key certification request (in the 2542 -- same order as these requests appear in CertReqMessages). 2544 Challenge ::= SEQUENCE { 2545 owf AlgorithmIdentifier{DIGEST-ALGORITHM, {...}} 2546 OPTIONAL, 2547 -- MUST be present in the first Challenge; MAY be omitted in 2548 -- any subsequent Challenge in POPODecKeyChallContent (if 2549 -- omitted, then the owf used in the immediately preceding 2550 -- Challenge is to be used). 2551 witness OCTET STRING, 2552 -- the result of applying the one-way function (owf) to a 2553 -- randomly-generated INTEGER, A. [Note that a different 2554 -- INTEGER MUST be used for each Challenge.] 2555 challenge OCTET STRING 2556 -- the encryption (under the public key for which the cert. 2557 -- request is being made) of Rand. 2559 } 2561 -- Added in CMP Updates [thisRFC] 2563 Rand ::= SEQUENCE { 2564 -- Rand is encrypted under the public key to form the challenge 2565 -- in POPODecKeyChallContent 2566 int INTEGER, 2567 -- the randomly-generated INTEGER A (above) 2568 sender GeneralName 2569 -- the sender's name (as included in PKIHeader) 2570 } 2572 POPODecKeyRespContent ::= SEQUENCE OF INTEGER 2573 -- One INTEGER per encryption key certification request (in the 2574 -- same order as these requests appear in CertReqMessages). The 2575 -- retrieved INTEGER A (above) is returned to the sender of the 2576 -- corresponding Challenge. 2578 CertRepMessage ::= SEQUENCE { 2579 caPubs [1] SEQUENCE SIZE (1..MAX) OF CMPCertificate 2580 OPTIONAL, 2581 response SEQUENCE OF CertResponse } 2583 CertResponse ::= SEQUENCE { 2584 certReqId INTEGER, 2585 -- to match this response with the corresponding request (a value 2586 -- of -1 is to be used if certReqId is not specified in the 2587 -- corresponding request, which can only be a p10cr) 2588 status PKIStatusInfo, 2589 certifiedKeyPair CertifiedKeyPair OPTIONAL, 2590 rspInfo OCTET STRING OPTIONAL 2591 -- analogous to the id-regInfo-utf8Pairs string defined 2592 -- for regInfo in CertReqMsg [RFC4211] 2593 } 2595 CertifiedKeyPair ::= SEQUENCE { 2596 certOrEncCert CertOrEncCert, 2597 privateKey [0] EncryptedKey OPTIONAL, 2598 -- see [RFC4211] for comment on encoding 2599 -- Changed from Encrypted Value to EncryptedKey as a CHOICE of 2600 -- EncryptedValue and EnvelopedData due to the changes made in 2601 -- CMP Updates [thisRFC] 2602 -- Using the choice EncryptedValue is bit-compatible to the 2603 -- syntax without this change 2604 publicationInfo [1] PKIPublicationInfo OPTIONAL } 2606 CertOrEncCert ::= CHOICE { 2607 certificate [0] CMPCertificate, 2608 encryptedCert [1] EncryptedKey 2609 -- Changed from Encrypted Value to EncryptedKey as a CHOICE of 2610 -- EncryptedValue and EnvelopedData due to the changes made in 2611 -- CMP Updates [thisRFC] 2612 -- Using the choice EncryptedValue is bit-compatible to the 2613 -- syntax without this change 2614 } 2616 KeyRecRepContent ::= SEQUENCE { 2617 status PKIStatusInfo, 2618 newSigCert [0] CMPCertificate OPTIONAL, 2619 caCerts [1] SEQUENCE SIZE (1..MAX) OF 2620 CMPCertificate OPTIONAL, 2621 keyPairHist [2] SEQUENCE SIZE (1..MAX) OF 2622 CertifiedKeyPair OPTIONAL } 2624 RevReqContent ::= SEQUENCE OF RevDetails 2626 RevDetails ::= SEQUENCE { 2627 certDetails CertTemplate, 2628 -- allows requester to specify as much as they can about 2629 -- the cert. for which revocation is requested 2630 -- (e.g., for cases in which serialNumber is not available) 2631 crlEntryDetails Extensions{{...}} OPTIONAL 2632 -- requested crlEntryExtensions 2633 } 2635 RevRepContent ::= SEQUENCE { 2636 status SEQUENCE SIZE (1..MAX) OF PKIStatusInfo, 2637 -- in same order as was sent in RevReqContent 2638 revCerts [0] SEQUENCE SIZE (1..MAX) OF CertId OPTIONAL, 2639 -- IDs for which revocation was requested 2640 -- (same order as status) 2641 crls [1] SEQUENCE SIZE (1..MAX) OF CertificateList OPTIONAL 2642 -- the resulting CRLs (there may be more than one) 2643 } 2645 CAKeyUpdAnnContent ::= SEQUENCE { 2646 oldWithNew CMPCertificate, -- old pub signed with new priv 2647 newWithOld CMPCertificate, -- new pub signed with old priv 2648 newWithNew CMPCertificate -- new pub signed with new priv 2649 } 2651 CertAnnContent ::= CMPCertificate 2653 RevAnnContent ::= SEQUENCE { 2654 status PKIStatus, 2655 certId CertId, 2656 willBeRevokedAt GeneralizedTime, 2657 badSinceDate GeneralizedTime, 2658 crlDetails Extensions{{...}} OPTIONAL 2659 -- extra CRL details (e.g., crl number, reason, location, etc.) 2660 } 2662 CRLAnnContent ::= SEQUENCE OF CertificateList 2663 PKIConfirmContent ::= NULL 2665 NestedMessageContent ::= PKIMessages 2667 -- CertReqTemplateContent, AttributeTypeAndValue, 2668 -- ExpandedRegControlSet, id-regCtrl-altCertTemplate, 2669 -- AltCertTemplate, regCtrl-algId, id-regCtrl-algId, AlgIdCtrl, 2670 -- regCtrl-rsaKeyLen, id-regCtrl-rsaKeyLen, and RsaKeyLenCtrl 2671 -- were added in CMP Updates [thisRFC] 2673 CertReqTemplateContent ::= SEQUENCE { 2674 certTemplate CertTemplate, 2675 -- prefilled certTemplate structure elements 2676 -- The SubjectPublicKeyInfo field in the certTemplate MUST NOT 2677 -- be used. 2678 keySpec Controls OPTIONAL 2679 -- MAY be used to specify supported algorithms. 2680 -- Controls ::= SEQUENCE SIZE (1..MAX) OF AttributeTypeAndValue 2681 -- as specified in CRMF (RFC4211) 2682 } 2684 AttributeTypeAndValue ::= SingleAttribute{{ ... }} 2686 ExpandedRegControlSet ATTRIBUTE ::= { RegControlSet | 2687 regCtrl-altCertTemplate | regCtrl-algId | regCtrl-rsaKeyLen, ... } 2689 regCtrl-altCertTemplate ATTRIBUTE ::= 2690 { TYPE AltCertTemplate IDENTIFIED BY id-regCtrl-altCertTemplate } 2692 id-regCtrl-altCertTemplate OBJECT IDENTIFIER ::= { id-regCtrl 7 } 2694 AltCertTemplate ::= AttributeTypeAndValue 2695 -- specifies a template for a certificate other than an X.509v3 2696 -- public-key certificate 2698 regCtrl-algId ATTRIBUTE ::= 2699 { TYPE AlgIdCtrl IDENTIFIED BY id-regCtrl-algId } 2701 id-regCtrl-algId OBJECT IDENTIFIER ::= { id-regCtrl 11 } 2702 AlgIdCtrl ::= AlgorithmIdentifier{ALGORITHM, {...}} 2703 -- SHALL be used to specify supported algorithms other than RSA 2705 regCtrl-rsaKeyLen ATTRIBUTE ::= 2706 { TYPE RsaKeyLenCtrl IDENTIFIED BY id-regCtrl-rsaKeyLen } 2708 id-regCtrl-rsaKeyLen OBJECT IDENTIFIER ::= { id-regCtrl 12 } 2710 RsaKeyLenCtrl ::= INTEGER (1..MAX) 2711 -- SHALL be used to specify supported RSA key lengths 2713 -- RootCaKeyUpdateContent, CRLSource, and CRLStatus were added in 2714 -- CMP Updates [thisRFC] 2716 RootCaKeyUpdateContent ::= SEQUENCE { 2717 newWithNew CMPCertificate, 2718 -- new root CA certificate 2719 newWithOld [0] CMPCertificate OPTIONAL, 2720 -- X.509 certificate containing the new public root CA key 2721 -- signed with the old private root CA key 2722 oldWithNew [1] CMPCertificate OPTIONAL 2723 -- X.509 certificate containing the old public root CA key 2724 -- signed with the new private root CA key 2725 } 2727 CRLSource ::= CHOICE { 2728 dpn [0] DistributionPointName, 2729 issuer [1] GeneralNames } 2731 CRLStatus ::= SEQUENCE { 2732 source CRLSource, 2733 thisUpdate Time OPTIONAL } 2735 INFO-TYPE-AND-VALUE ::= TYPE-IDENTIFIER 2737 InfoTypeAndValue ::= SEQUENCE { 2738 infoType INFO-TYPE-AND-VALUE. 2739 &id({SupportedInfoSet}), 2740 infoValue INFO-TYPE-AND-VALUE. 2741 &Type({SupportedInfoSet}{@infoType}) } 2743 SupportedInfoSet INFO-TYPE-AND-VALUE ::= { ... } 2745 -- Example InfoTypeAndValue contents include, but are not limited 2746 -- to, the following (uncomment in this ASN.1 module and use as 2747 -- appropriate for a given environment): 2748 -- 2749 -- id-it-caProtEncCert OBJECT IDENTIFIER ::= {id-it 1} 2750 -- CAProtEncCertValue ::= CMPCertificate 2751 -- id-it-signKeyPairTypes OBJECT IDENTIFIER ::= {id-it 2} 2752 -- SignKeyPairTypesValue ::= SEQUENCE SIZE (1..MAX) OF 2753 -- AlgorithmIdentifier{{...}} 2754 -- id-it-encKeyPairTypes OBJECT IDENTIFIER ::= {id-it 3} 2755 -- EncKeyPairTypesValue ::= SEQUENCE SIZE (1..MAX) OF 2756 -- AlgorithmIdentifier{{...}} 2757 -- id-it-preferredSymmAlg OBJECT IDENTIFIER ::= {id-it 4} 2758 -- PreferredSymmAlgValue ::= AlgorithmIdentifier{{...}} 2759 -- id-it-caKeyUpdateInfo OBJECT IDENTIFIER ::= {id-it 5} 2760 -- CAKeyUpdateInfoValue ::= CAKeyUpdAnnContent 2761 -- id-it-currentCRL OBJECT IDENTIFIER ::= {id-it 6} 2762 -- CurrentCRLValue ::= CertificateList 2763 -- id-it-unsupportedOIDs OBJECT IDENTIFIER ::= {id-it 7} 2764 -- UnsupportedOIDsValue ::= SEQUENCE SIZE (1..MAX) OF 2765 -- OBJECT IDENTIFIER 2766 -- id-it-keyPairParamReq OBJECT IDENTIFIER ::= {id-it 10} 2767 -- KeyPairParamReqValue ::= OBJECT IDENTIFIER 2768 -- id-it-keyPairParamRep OBJECT IDENTIFIER ::= {id-it 11} 2769 -- KeyPairParamRepValue ::= AlgorithmIdentifier{{...}} 2770 -- id-it-revPassphrase OBJECT IDENTIFIER ::= {id-it 12} 2771 -- RevPassphraseValue ::= EncryptedKey 2772 -- - Changed from Encrypted Value to EncryptedKey as a CHOICE 2773 -- - of EncryptedValue and EnvelopedData due to the changes 2774 -- - made in CMP Updates [thisRFC] 2775 -- - Using the choice EncryptedValue is bit-compatible to 2776 -- - the syntax without this change 2777 -- id-it-implicitConfirm OBJECT IDENTIFIER ::= {id-it 13} 2778 -- ImplicitConfirmValue ::= NULL 2779 -- id-it-confirmWaitTime OBJECT IDENTIFIER ::= {id-it 14} 2780 -- ConfirmWaitTimeValue ::= GeneralizedTime 2781 -- id-it-origPKIMessage OBJECT IDENTIFIER ::= {id-it 15} 2782 -- OrigPKIMessageValue ::= PKIMessages 2783 -- id-it-suppLangTags OBJECT IDENTIFIER ::= {id-it 16} 2784 -- SuppLangTagsValue ::= SEQUENCE OF UTF8String 2785 -- id-it-caCerts OBJECT IDENTIFIER ::= {id-it 17} 2786 -- CaCertsValue ::= SEQUENCE SIZE (1..MAX) OF 2787 -- CMPCertificate 2788 -- - id-it-caCerts added in CMP Updates [thisRFC] 2789 -- id-it-rootCaKeyUpdate OBJECT IDENTIFIER ::= {id-it 18} 2790 -- RootCaKeyUpdateValue ::= RootCaKeyUpdateContent 2791 -- - id-it-rootCaKeyUpdate added in CMP Updates [thisRFC] 2792 -- id-it-certReqTemplate OBJECT IDENTIFIER ::= {id-it 19} 2793 -- CertReqTemplateValue ::= CertReqTemplateContent 2794 -- - id-it-certReqTemplate added in CMP Updates [thisRFC] 2795 -- id-it-rootCaCert OBJECT IDENTIFIER ::= {id-it 20} 2796 -- RootCaCertValue ::= CMPCertificate 2797 -- - id-it-rootCaCert added in CMP Updates [thisRFC] 2798 -- id-it-certProfile OBJECT IDENTIFIER ::= {id-it 21} 2799 -- CertProfileValue ::= SEQUENCE SIZE (1..MAX) OF 2800 -- UTF8String 2801 -- - id-it-certProfile added in CMP Updates [thisRFC] 2802 -- id-it-crlStatusList OBJECT IDENTIFIER ::= {id-it TBD1} 2803 -- CRLStatusListValue ::= SEQUENCE SIZE (1..MAX) OF 2804 -- CRLStatus 2805 -- - id-it-crlStatusList added in CMP Updates [thisRFC] 2806 -- id-it-crls OBJECT IDENTIFIER ::= {id-it TBD2} 2807 -- CRLsValue ::= SEQUENCE SIZE (1..MAX) OF 2808 -- CertificateList 2809 -- - id-it-crls added in CMP Updates [thisRFC] 2810 -- 2811 -- where 2812 -- 2813 -- id-pkix OBJECT IDENTIFIER ::= { 2814 -- iso(1) identified-organization(3) 2815 -- dod(6) internet(1) security(5) mechanisms(5) pkix(7)} 2816 -- and 2817 -- id-it OBJECT IDENTIFIER ::= {id-pkix 4} 2818 -- 2819 -- 2820 -- This construct MAY also be used to define new PKIX Certificate 2821 -- Management Protocol request and response messages, or general- 2822 -- purpose (e.g., announcement) messages for future needs or for 2823 -- specific environments. 2825 GenMsgContent ::= SEQUENCE OF InfoTypeAndValue 2827 -- May be sent by EE, RA, or CA (depending on message content). 2828 -- The OPTIONAL infoValue parameter of InfoTypeAndValue will 2829 -- typically be omitted for some of the examples given above. 2830 -- The receiver is free to ignore any contained OBJECT IDs that it 2831 -- does not recognize. If sent from EE to CA, the empty set 2832 -- indicates that the CA may send 2833 -- any/all information that it wishes. 2835 GenRepContent ::= SEQUENCE OF InfoTypeAndValue 2836 -- Receiver MAY ignore any contained OIDs that it does not 2837 -- recognize. 2839 ErrorMsgContent ::= SEQUENCE { 2840 pKIStatusInfo PKIStatusInfo, 2841 errorCode INTEGER OPTIONAL, 2842 -- implementation-specific error codes 2843 errorDetails PKIFreeText OPTIONAL 2844 -- implementation-specific error details 2845 } 2846 CertConfirmContent ::= SEQUENCE OF CertStatus 2848 CertStatus ::= SEQUENCE { 2849 certHash OCTET STRING, 2850 -- the hash of the certificate, using the same hash algorithm 2851 -- as is used to create and verify the certificate signature 2852 certReqId INTEGER, 2853 -- to match this confirmation with the corresponding req/rep 2854 statusInfo PKIStatusInfo OPTIONAL, 2855 hashAlg [0] AlgorithmIdentifier{DIGEST-ALGORITHM, {...}} OPTIONAL 2856 -- the hash algorithm to use for calculating certHash 2857 -- SHOULD NOT be used in all cases where the AlgorithmIdentifier 2858 -- of the certificate signature specifies a hash algorithm 2859 } 2861 PollReqContent ::= SEQUENCE OF SEQUENCE { 2862 certReqId INTEGER } 2864 PollRepContent ::= SEQUENCE OF SEQUENCE { 2865 certReqId INTEGER, 2866 checkAfter INTEGER, -- time in seconds 2867 reason PKIFreeText OPTIONAL } 2869 -- 2870 -- Extended Key Usage extension for PKI entities used in CMP 2871 -- operations, added due to the changes made in 2872 -- CMP Updates [thisRFC] 2873 -- The EKUs for the CA and RA are reused from CMC as defined in 2874 -- [RFC6402] 2875 -- 2877 -- id-kp-cmcCA OBJECT IDENTIFIER ::= { id-kp 27 } 2878 -- id-kp-cmcRA OBJECT IDENTIFIER ::= { id-kp 28 } 2879 id-kp-cmKGA OBJECT IDENTIFIER ::= { id-kp 32 } 2881 END 2883 Appendix B. History of changes 2885 Note: This appendix will be deleted in the final version of the 2886 document. 2888 From version 13 -> 14: 2890 * Extended id-it-caCerts support message to allow transporting to- 2891 be-trusted root CA certificates; added respective security 2892 consideration (see thread "Generalizing the CMP "Get CA 2893 certificates" use case") 2895 * Rolled back changes made in previous version regarding root CA 2896 update to avoid registration of new OIDs. Yet we sticked to using 2897 id-it-rootCaCert in the genm body instead its headers' generalInfo 2898 field and removed the ToDos and TBDs on re-arranging id-it OIDs 2899 (see thread "Allocation of OIDs for CRL update retrieval (draft- 2900 ietf-lamps-cmp-updates-13)") 2902 From version 12 -> 13: 2904 * Added John Gray to the list of authors due to fruitful discussion 2905 and important proposals 2906 * Fixed errata no. 2615, 2616, 3949, 4078, and 5201 on RFC 4210 2907 * Added reference on RFC 8933 regarding CMS signedAttrs to 2908 Section 2.7 2909 * Updated Section 2.9 and the ASN.1 modules moving the position of 2910 the hashAlg field (see thread "[CMP Updates] position of hashAlg 2911 in certStatus") 2912 * Changed "rootCaCert" from generalInfo to genm body and generalized 2913 to "oldTrustAnchor", renaming "rootCaKeyUpdate" to 2914 "trustAnchorUpdate" in Sections 2.14, A.1, and A.2, removing 2915 former Section 2.4 2916 * Added genm use case "CRL update retrieval" in Section 2.16, A.1, 2917 and A.2. (see thread "[CMP Updates] Requesting a current CRL") 2918 * Updated Section 2.18 and 2.17 to support polling for all kinds of 2919 CMP request messages initiated by an error message with status 2920 "waiting" as initially discussed at IETF 111 2921 * Updated Sections 2.19 and 2.20 regarding version handling 2922 * Added further OIDs and a TBD regarding reordering of the OIDs 2923 * Added Sections 2.21 to 2.23 with new security considerations and 2924 updated Section 5 accordingly 2925 * Added a ToDo regarding OID registration, renaming, and re-ordering 2926 * Added Section 3.1 updating the introduction of RFC 6712 2927 * Fixed some nits in the ASN.1 modules (see thread "draft-ietf- 2928 lamps-cmp-updates-12: Comments on A.1. 1988 ASN.1 Module" and 2929 "draft-ietf-lamps-cmp-updates-12: Comments on A.2. 2002 ASN.1 2930 Module") 2931 * Replaced the term "transport" by "transfer" where appropriate to 2932 prevent confusion 2933 * Minor editorial changes 2935 From version 11 -> 12: 2937 * Extended Section 2.5 and the ASN.1 modules in Appendix A to allow 2938 a sequence of certificate profiles in CertProfileValue (see thread 2939 "id-it-CertProfile in draft-ietf-lamps-cmp-updates") 2941 From version 10 -> 11: 2943 * Add Section 2.10 to add an additional hashAlg field to the 2944 CertStatus type to support certificates signed with a signature 2945 algorithm not explicitly indicating a hash algorithm in the 2946 AlgorithmIdentifier (see thread "Hash algorithm to us for 2947 calculating certHash") 2948 * Added newly registered OIDs and temporarily registered URI suffix 2949 * Exchanged the import of CertificationRequest from RFC 2986 to the 2950 definition from RFC 6402 Appendix A.1 (see thread "CMP Update of 2951 CertificationRequest") 2952 * Corrected the definition of LocalKeyIdValue in Appendix A.1 2953 * Updated new RFC numbers for I-D.ietf-lamps-crmf-update-algs 2955 From version 9 -> 10: 2957 * Added 1988 ASN.1 syntax for localKeyId attribute to Appendix A.1 2959 From version 08 -> 09: 2961 * Deleted specific definition of CMP CA and CMP RA in Section 2.2 2962 and only reference RFC 6402 for definition of id-kp-cmcCA and id- 2963 kp-cmcRA to resolve the ToDo below based on feedback of Tomas 2964 Gustavsson 2965 * Added Section 2.4. and 2.5 to define id-it-rootCaCert and id-it- 2966 certProfile to be used in Section 2.14 and 2.15 2967 * Added reference to CMP Algorithms in Section 2.8 2968 * Extended Section 2.14 to explicitly indicate the root CA an update 2969 is requested for by using id-it-rootCaCert and changing the ASN.1 2970 syntax to require providing the newWithOld certificate in the 2971 response message 2972 * Extended Section 2.15 to explicitly indicate the certificate 2973 request template by using id-it-certProfile and on further details 2974 of the newly introduced controls 2975 * Deleted the table on id-kp-cmcCA and id-kp-cmcRA and adding id-it- 2976 rootCaCert and id-it-certProfile in Section 2.19 2977 * Adding the definition of id-it-rootCaCert and id-it-certProfile in 2978 both ASN.1 modules in Appendix A 2979 * Minor editorial changes reflecting the above changes 2981 From version 07 -> 08: 2983 * Added a ToDo to Section 2.2 to reflect a current discussion on the 2984 need of an additional CMP-CA role and EKU and differentiation from 2985 CMP-RA 2986 * Added ToDos to Section 2.12 and 2.13 2988 From version 06 -> 07: 2990 * Added David von Oheimb as co-author 2991 * Changed to XML V3 2992 * Added Section 2.3 to enable a CMP protocol version number 3 in the 2993 PKIHeader for cases where EnvelopedData is to be used (see thread 2994 "Mail regarding draft-ietf-lamps-cmp-updates"). 2995 * Added Section 2.4 to refer to [I-D.ietf-lamps-crmf-update-algs] 2996 for the update of id-PasswordBasedMac for PKI message protection 2997 using passwords or shared secrets. 2998 * Updated Section 2.6 to introduce the protocol version number 3 to 2999 properly indicate support of EnvelopedData instead of 3000 EncryptedValue in case a transaction requires use of EnvelopedData 3001 (see thread "Mail regarding draft-ietf-lamps-cmp-updates"). 3002 * Update Section 2.14 to make the minimal changes to the respective 3003 section in CMP more explicit. 3004 * Added Sections 2.15 and 2.16 to address the new cmp2021 protocol 3005 version in Section 7 Version Negotiation. 3006 * Updated Section 2.17 to add new OIDs for id-regCtrl-algId and id- 3007 regCtrl-rsaKeyLen for registration at IANA. 3008 * Added Section 2.20 to update the general rules of interpretation 3009 in Appendix D.1 regarding the new cmp2021 version. 3010 * Added Section 2.21 to update the Algorithm Use Profile in 3011 Appendix D.2 with the reference to the new CMP Algorithms document 3012 as decided at IETF 108. 3013 * Updates Section 3.1 to delete the description of a discovery 3014 mechanism as decided at IETF 108. 3015 * Various changes and corrections in wording. 3017 From version 05 -> 06: 3019 * Added the update of Appendix D.2 with the reference to the new CMP 3020 Algorithms document as decided in IETF 108 3021 * Updated the IANA considerations to register new OIDs for id- 3022 regCtrl-algId and d-regCtrl-rsaKeyLen. 3023 * Minor changes and corrections 3025 From version 04 -> 05: 3027 * Added Section 2.10 and Section 2.11 to clarify the usage of these 3028 general messages types with EC curves (see thread 3029 "AlgorithmIdentifier parameters NULL value - Re: InfoTypeAndValue 3030 in CMP headers") 3031 * Split former section 2.7 on adding 'CA Certificates', 'Root CA 3032 Certificates Update', and 'Certificate Request Template' in three 3033 separate sections for easier readability 3034 * Changed in Section 2.14 the ASN.1 syntax of CertReqTemplateValue 3035 from using rsaKeyLen to usage of controls as specified in CRMF 3036 Section 6 [RFC4211] (see thread "dtaft-ietf-lamps-cmp-updates and 3037 rsaKeyLen") 3039 * Updated the IANA considerations in Section 2.24 to introduce new 3040 OID for id-regCtrl-algId and id-regCtrl-rsaKeyLen (see thread 3041 "dtaft-ietf-lamps-cmp-updates and rsaKeyLen") 3042 * Updated the IANA Considerations in and the Appendixes to introduce 3043 new OID for the updates ASN.1 modules (see thread "I-D Action: 3044 draft-ietf-lamps-cmp-updates-04.txt") 3045 * Removed EncryptedValue from and added Controls to the list of 3046 types imported from CRMF [RFC4211] in ASN.1 modules (see thread 3047 "draft-ietf-lamps-cmp-updates and the ASN.1 modules") 3048 * Moved declaration of Rand out of the comment in ASN.1 modules (see 3049 thread "draft-ietf-lamps-cmp-updates and the ASN.1 modules") 3050 * Minor changes and corrections 3052 From version 03 -> 04: 3054 * Added Section 2.7 to introduce three new id-it IDs for uses in 3055 general messages as discussed (see thread "draft-ietf-lamps-cmp- 3056 updates add section to introduce id-it-caCerts, id-it- 3057 rootCaKeyUpdate, and id-it-certReqTemplate") 3058 * Added the new id-it IDs and the /.well-known/cmp to the IANA 3059 Considerations of [RFC4210] in Section 2.9 3060 * Updated the IANA Considerations of [RFC4210] in Section 2.25 3061 * Some changes in wording on Section 3 due to review comments from 3062 Martin Peylo 3064 From version 02 -> 03: 3066 * Added a ToDo on aligning with the CMP Algorithms draft that will 3067 be set up as decided in IETF 108 3068 * Updated section on Encrypted Values in Section 2.7 to add the 3069 AsymmetricKey Package structure to transport a newly generated 3070 private key as decided in IETF 108 3071 * Updated the IANA Considerations of [RFC4210] in Section 2.25 3072 * Added the pre-registered OID in Section 2.25 and the ASN.1 module 3073 * Added Section 3 to document the changes to RFC 6712 [RFC6712] 3074 regarding URI discovery and using the path-prefix of '/.well- 3075 known/' as discussed in IETF 108 3076 * Updated the IANA Considerations section 3077 * Added a complete updated ASN.1 module in 1988 syntax to update 3078 Appendix F of [RFC4210] and a complete updated ASN.1 module in 3079 2002 syntax to update Section 9 of [RFC5912] 3080 * Minor changes in wording 3082 From version 01 -> 02: 3084 * Updated section on EKU OIDs in Section 2.2 as decided in IETF 107 3085 * Changed from symmetric key-encryption to password-based key 3086 management technique in Section 2.7 as discussed with Russ and Jim 3087 on the mailing list 3088 * Defined the attribute containing the key identifier for the 3089 revocation passphrase in Section 2.25 3090 * Moved the change history to the Appendix 3092 From version 00 -> 01: 3094 * Minor changes in wording 3096 From draft-brockhaus-lamps-cmp-updates-03 -> draft-ietf-lamps-cmp- 3097 updates-00: 3099 * Changes required to reflect WG adoption 3101 From version 02 -> 03: 3103 * Added some clarification in Section 2.1 3105 From version 01 -> 02: 3107 * Added clarification to section on multiple protection 3108 * Added clarification on new EKUs after some exchange with Tomas 3109 Gustavsson 3110 * Reused OIDs from RFC 6402 [RFC6402] as suggested by Sean Turner at 3111 IETF 106 3112 * Added clarification on the field containing the key identifier for 3113 a revocation passphrase 3114 * Minor changes in wording 3116 From version 00 -> 01: 3118 * Added a section describing the new extended key usages 3119 * Completed the section on changes to the specification of encrypted 3120 values 3121 * Added a section on clarification to Appendix D.4 3122 * Minor generalization in RFC 4210 [RFC4210] Sections 5.1.3.4 and 3123 5.3.22 3124 * Minor changes in wording 3126 Authors' Addresses 3128 Hendrik Brockhaus (editor) 3129 Siemens AG 3131 Email: hendrik.brockhaus@siemens.com 3132 David von Oheimb 3133 Siemens AG 3135 Email: david.von.oheimb@siemens.com 3137 John Gray 3138 Entrust 3140 Email: john.gray@entrust.com