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