idnits 2.17.1 draft-ietf-lamps-cmp-updates-10.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 RFC5912, but the abstract doesn't seem to mention this, which it should. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust and authors Copyright Line does not match the current year == Line 1643 has weird spacing: '...tCaCert added...' == Line 1646 has weird spacing: '...Profile added...' == Line 2254 has weird spacing: '...tCaCert added...' == Line 2257 has weird spacing: '...Profile added...' == The document seems to lack the recommended RFC 2119 boilerplate, even if it appears to use RFC 2119 keywords -- however, there's a paragraph with a matching beginning. Boilerplate error? (The document does seem to have the reference to RFC 2119 which the ID-Checklist requires). (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 (4 May 2021) is 1087 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 2165 -- Looks like a reference, but probably isn't: '1' on line 2168 -- Looks like a reference, but probably isn't: '2' on line 2114 -- Looks like a reference, but probably isn't: '3' on line 1867 -- Looks like a reference, but probably isn't: '4' on line 1868 -- Looks like a reference, but probably isn't: '5' on line 1869 -- Looks like a reference, but probably isn't: '6' on line 1870 -- Looks like a reference, but probably isn't: '7' on line 1871 -- Looks like a reference, but probably isn't: '8' on line 1872 == Missing Reference: 'CRMF' is mentioned on line 1474, but not defined == Missing Reference: 'PKCS10' is mentioned on line 1868, but not defined == Missing Reference: 'RFC3629' is mentioned on line 1858, but not defined == Missing Reference: 'RFC3066' is mentioned on line 1859, but not defined ** Obsolete undefined reference: RFC 3066 (Obsoleted by RFC 4646, RFC 4647) == Missing Reference: 'RFC2482' is mentioned on line 1861, but not defined ** Obsolete undefined reference: RFC 2482 (Obsoleted by RFC 6082) -- Looks like a reference, but probably isn't: '9' on line 1873 -- Looks like a reference, but probably isn't: '10' on line 1874 -- Looks like a reference, but probably isn't: '11' on line 1875 -- Looks like a reference, but probably isn't: '12' on line 1876 -- Looks like a reference, but probably isn't: '13' on line 1877 -- Looks like a reference, but probably isn't: '14' on line 1878 -- Looks like a reference, but probably isn't: '15' on line 1879 -- Looks like a reference, but probably isn't: '16' on line 1880 -- Looks like a reference, but probably isn't: '17' on line 1881 -- Looks like a reference, but probably isn't: '18' on line 1882 -- Looks like a reference, but probably isn't: '19' on line 1883 -- Looks like a reference, but probably isn't: '20' on line 1884 -- Looks like a reference, but probably isn't: '21' on line 1885 -- Looks like a reference, but probably isn't: '22' on line 1886 -- Looks like a reference, but probably isn't: '23' on line 1887 -- Looks like a reference, but probably isn't: '24' on line 1888 -- Looks like a reference, but probably isn't: '25' on line 1889 -- Looks like a reference, but probably isn't: '26' on line 1890 == Missing Reference: 'PKCS11' is mentioned on line 1924, but not defined == Missing Reference: 'RFC2104' is mentioned on line 1925, but not defined == Missing Reference: 'RFC2202' is mentioned on line 1925, but not defined == Outdated reference: A later version (-15) exists of draft-ietf-lamps-cmp-algorithms-03 ** Obsolete normative reference: RFC 2510 (Obsoleted by RFC 4210) ** Downref: Normative reference to an Informational RFC: RFC 2985 ** Downref: Normative reference to an Informational RFC: RFC 2986 ** Downref: Normative reference to an Informational RFC: RFC 5912 ** Downref: Normative reference to an Informational RFC: RFC 7299 == Outdated reference: A later version (-21) exists of draft-ietf-lamps-lightweight-cmp-profile-05 Summary: 7 errors (**), 0 flaws (~~), 17 warnings (==), 30 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 LAMPS Working Group H. Brockhaus 3 Internet-Draft D. von Oheimb 4 Updates: 4210, 5912, 6712 (if approved) Siemens 5 Intended status: Standards Track 4 May 2021 6 Expires: 5 November 2021 8 Certificate Management Protocol (CMP) Updates 9 draft-ietf-lamps-cmp-updates-10 11 Abstract 13 This document contains a set of updates to the syntax and transport 14 of Certificate Management Protocol (CMP) version 2. This document 15 updates RFC 4210 and RFC 6712. 17 The aspects of CMP updated in this document are using EnvelopedData 18 instead of EncryptedValue, clarifying the handling of p10cr messages, 19 improving the crypto agility, as well as adding new general message 20 types, extended key usages to identify certificates for use with CMP, 21 and '.well-known' HTTP path segments. 23 To properly differentiate the support of EnvelopedData instead of 24 EncryptedValue, the CMP version 3 is introduced in case a transaction 25 is supposed to use EnvelopedData. 27 Status of This Memo 29 This Internet-Draft is submitted in full conformance with the 30 provisions of BCP 78 and BCP 79. 32 Internet-Drafts are working documents of the Internet Engineering 33 Task Force (IETF). Note that other groups may also distribute 34 working documents as Internet-Drafts. The list of current Internet- 35 Drafts is at https://datatracker.ietf.org/drafts/current/. 37 Internet-Drafts are draft documents valid for a maximum of six months 38 and may be updated, replaced, or obsoleted by other documents at any 39 time. It is inappropriate to use Internet-Drafts as reference 40 material or to cite them other than as "work in progress." 42 This Internet-Draft will expire on 5 November 2021. 44 Copyright Notice 46 Copyright (c) 2021 IETF Trust and the persons identified as the 47 document authors. All rights reserved. 49 This document is subject to BCP 78 and the IETF Trust's Legal 50 Provisions Relating to IETF Documents (https://trustee.ietf.org/ 51 license-info) in effect on the date of publication of this document. 52 Please review these documents carefully, as they describe your rights 53 and restrictions with respect to this document. Code Components 54 extracted from this document must include Simplified BSD License text 55 as described in Section 4.e of the Trust Legal Provisions and are 56 provided without warranty as described in the Simplified BSD License. 58 Table of Contents 60 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 3 61 1.1. Convention and Terminology . . . . . . . . . . . . . . . 3 62 2. Updates to RFC 4210 - Certificate Management Protocol 63 (CMP) . . . . . . . . . . . . . . . . . . . . . . . . . . 4 64 2.1. New Section 1.1. - Changes since RFC 4210 . . . . . . . . 4 65 2.2. New Section 4.5 - Extended Key Usage . . . . . . . . . . 5 66 2.3. Update Section 5.1.1. - PKI Message Header . . . . . . . 6 67 2.4. New Section 5.1.1.3. - RootCaCert . . . . . . . . . . . . 7 68 2.5. New Section 5.1.1.4. - CertProfile . . . . . . . . . . . 7 69 2.6. Update Section 5.1.3.1. - Shared Secret Information . . . 8 70 2.7. Replace Section 5.1.3.4 - Multiple Protection . . . . . . 8 71 2.8. Replace Section 5.2.2. - Encrypted Values . . . . . . . . 9 72 2.9. Update Section 5.3.4. - Certification Response . . . . . 11 73 2.10. Update Section 5.3.19.2. - Signing Key Pair Types . . . . 11 74 2.11. Update Section 5.3.19.3. - Encryption/Key Agreement Key 75 Pair Types . . . . . . . . . . . . . . . . . . . . . . . 12 76 2.12. Replace Section 5.3.19.9. - Revocation Passphrase . . . . 12 77 2.13. New Section 5.3.19.14 - CA Certificates . . . . . . . . . 12 78 2.14. New Section 5.3.19.15 - Root CA Certificate Update . . . 13 79 2.15. New Section 5.3.19.16 - Certificate Request Template . . 13 80 2.16. Update Section 5.3.22 - Polling Request and Response . . 15 81 2.17. Update Section 7 - Version Negotiation . . . . . . . . . 15 82 2.18. Update Section 7.1.1. - Clients Talking to RFC 2510 83 Servers . . . . . . . . . . . . . . . . . . . . . . . . 16 84 2.19. Update Section 9 - IANA Considerations . . . . . . . . . 16 85 2.20. Update Appendix B - The Use of Revocation Passphrase . . 18 86 2.21. Update Appendix C - Request Message Behavioral 87 Clarifications . . . . . . . . . . . . . . . . . . . . . 18 88 2.22. Update Appendix D.1. - General Rules for Interpretation of 89 These Profiles . . . . . . . . . . . . . . . . . . . . . 19 90 2.23. Update Appendix D.2. - Algorithm Use Profile . . . . . . 19 91 2.24. Update Appendix D.4. - Initial Registration/Certification 92 (Basic Authenticated Scheme) . . . . . . . . . . . . . . 20 93 3. Updates to RFC 6712 - HTTP Transfer for the Certificate 94 Management Protocol (CMP) . . . . . . . . . . . . . . . . 20 95 3.1. New Section 1.1. - Changes since RFC 6712 . . . . . . . . 20 96 3.2. Replace Section 3.6. - HTTP Request-URI . . . . . . . . . 20 97 3.3. Update Section 6. - IANA Considerations . . . . . . . . . 21 98 4. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 21 99 5. Security Considerations . . . . . . . . . . . . . . . . . . . 22 100 6. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 22 101 7. References . . . . . . . . . . . . . . . . . . . . . . . . . 22 102 7.1. Normative References . . . . . . . . . . . . . . . . . . 22 103 7.2. Informative References . . . . . . . . . . . . . . . . . 24 104 Appendix A. ASN.1 Modules . . . . . . . . . . . . . . . . . . . 24 105 A.1. 1988 ASN.1 Module . . . . . . . . . . . . . . . . . . . . 25 106 A.2. 2002 ASN.1 Module . . . . . . . . . . . . . . . . . . . . 37 107 Appendix B. History of changes . . . . . . . . . . . . . . . . . 50 108 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 53 110 1. Introduction 112 While using CMP [RFC4210] in industrial and IoT environments and 113 developing the Lightweight CMP Profile 114 [I-D.ietf-lamps-lightweight-cmp-profile] some limitations were 115 identified in the original CMP specification. This document updates 116 RFC 4210 [RFC4210] and RFC 6712 [RFC6712] to overcome these 117 limitations. 119 Among others, this document improves the crypto agility of CMP, which 120 means to be flexible to react on future advances in cryptography. 122 This document also introduces new extended key usages to identify CMP 123 endpoints on registration and certification authorities. 125 1.1. Convention and Terminology 127 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 128 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 129 document are to be interpreted as described in BCP 14 [RFC2119] 130 [RFC8174] when, and only when, they appear in all capitals, as shown 131 here. 133 Technical terminology is used in conformance with RFC 4210 [RFC4210], 134 RFC 4211 [RFC4211], and RFC 5280 [RFC5280]. The following key words 135 are used: 137 CA: Certification authority, which issues certificates. 139 RA: Registration authority, an optional system component to which a 140 CA delegates certificate management functions such as 141 authorization checks. 143 KGA: Key generation authority, which generates key pairs on behalf 144 of an EE. The KGA could be co-located with an RA or a CA. 146 EE: End entity, a user, device, or service that holds a PKI 147 certificate. An identifier for the EE is given as its subject 148 of the certificate. 150 2. Updates to RFC 4210 - Certificate Management Protocol (CMP) 152 2.1. New Section 1.1. - Changes since RFC 4210 154 The following subsection describes feature updates to RFC 4210 155 [RFC4210]. They are always related to the base specification. Hence 156 references to the original sections in RFC 4210 [RFC4210] are used 157 whenever possible. 159 Insert this section at the end of the current Section 1: 161 1.1. Changes since RFC 4210 163 The following updates are made in [thisRFC]: 165 * Add new extended key usages for various CMP server types, e.g., 166 registration authority and certification authority, to express the 167 authorization of the entity identified in the certificate 168 containing the respective extended key usage extension to act as 169 the indicated PKI management entity. 171 * Extend the description of multiple protection to cover additional 172 use cases, e.g., batch processing of messages. 174 * Offering EnvelopedData as the preferred choice next to 175 EncryptedValue to better support crypto agility in CMP. Note that 176 according to RFC 4211 [RFC4211] section 2.1. point 9 the use of 177 the EncryptedValue structure has been deprecated in favor of the 178 EnvelopedData structure. RFC 4211 [RFC4211] offers the 179 EncryptedKey structure, a choice of EncryptedValue and 180 EnvelopedData for migration to EnvelopedData. For reasons of 181 completeness and consistency the type EncryptedValue has been 182 exchanged in all occurrences in RFC 4210 [RFC4210]. This includes 183 the protection of centrally generated private keys, encryption of 184 certificates, and protection of revocation passphrases. To 185 properly differentiate the support of EnvelopedData instead of 186 EncryptedValue, the CMP version 3 is introduced in case a 187 transaction is supposed to use EnvelopedData. 189 * Adding new general message types to request CA certificates, a 190 root CA update, or a certificate request template. 192 * Extend the usage of polling to p10cr messages. 194 * Delete the mandatory algorithm profile in RFC 4210 Appendix D.2 195 [RFC4210] and refer to CMP Algorithms Section 7 196 [I-D.ietf-lamps-cmp-algorithms]. 198 2.2. New Section 4.5 - Extended Key Usage 200 The following subsection introduces a new extended key usage for CMP 201 servers authorized to centrally generate key pairs on behalf of end 202 entities. 204 Insert this section at the end of the current Section 4: 206 4.5. Extended Key Usage 208 The Extended Key Usage (EKU) extension indicates the purposes for 209 which the certified key pair may be used. It therefore restricts the 210 use of a certificate to specific applications. 212 A CA may want to delegate parts of its duties to other PKI management 213 entities. The mechanism to prove this delegation explained in this 214 section offers an automatic way of checking the authorization of such 215 delegation. Such delegation MAY also be expressed by other means, 216 e.g., explicit configuration. 218 To offer automatic validation for the delegation of a role by a CA to 219 another entity, the certificates used for CMP message protection or 220 signed data for central key generation MUST be issued by the 221 delegating CA and MUST contain the respective EKUs. This proves the 222 authorization of this entity by the delegating CA to act in the given 223 role as described below. 225 The OIDs to be used for these EKUs are: 227 id-kp-cmcCA OBJECT IDENTIFIER ::= { 228 iso(1) identified-organization(3) dod(6) internet(1) 229 security(5) mechanisms(5) pkix(7) kp(3) 27 } 230 id-kp-cmcRA OBJECT IDENTIFIER ::= { 231 iso(1) identified-organization(3) dod(6) internet(1) 232 security(5) mechanisms(5) pkix(7) kp(3) 28 } 233 id-kp-cmKGA OBJECT IDENTIFIER ::= { 234 iso(1) identified-organization(3) dod(6) internet(1) 235 security(5) mechanisms(5) pkix(7) kp(3) 32 } 237 Note: RFC 6402 section 2.10 [RFC6402] specifies OIDs for a CMC CA and 238 a CMC RA. As the functionality of a CA and RA is not specific to 239 using CMC or CMP as the certificate management protocol, these OIDs 240 MAY be re-used. 242 The meaning of the id-kp-cmKGA EKU is as follows: 244 CMP KGA: CMP Key Generation Authorities are identified by the id-kp- 245 cmKGA extended key usage. The CMP KGA knows the private 246 key it generated on behalf of the end entity. This is a 247 very sensitive service and therefore needs specific 248 authorization. This authorization is with the CA 249 certificate itself. Alternatively, the CA MAY delegate the 250 authorization by placing the id-kp-cmKGA extended key usage 251 in the certificate used to authenticate the origin of the 252 generated private key or the delegation MAY be determined 253 through local configuration of the end entity. 255 Note: In device PKIs, especially those issuing IDevID certificates 256 IEEE 802.1AR Section 8.5 [IEEE.802.1AR_2018], CA certificates may 257 have very long validity (including the GeneralizedTime value 258 99991231235959Z to indicate a not well-defined expiration date as 259 specified in IEEE 802.1AR Section 8.5 [IEEE.802.1AR_2018] and 260 RFC 5280 Section 4.1.2.5 [RFC5280]). Such validity periods SHOULD 261 NOT be used for protection of CMP messages and key generation. 262 Certificates containing one of the above EKUs SHOULD NOT use 263 indefinite expiration date. 265 2.3. Update Section 5.1.1. - PKI Message Header 267 Section 5.1.1 of RFC 4210 [RFC4210] describes the PKI message header. 268 This document introduces the new version 3 indicating support of 269 EnvelopedData as specified in Section 2.8. 271 Replace the ASN.1 Syntax of PKIHeader and the subsequent description 272 of pvno with the following text: 274 PKIHeader ::= SEQUENCE { 275 pvno INTEGER { cmp1999(1), cmp2000(2), 276 cmp2021(3) }, 277 sender GeneralName, 278 recipient GeneralName, 279 messageTime [0] GeneralizedTime OPTIONAL, 280 protectionAlg [1] AlgorithmIdentifier OPTIONAL, 281 senderKID [2] KeyIdentifier OPTIONAL, 282 recipKID [3] KeyIdentifier OPTIONAL, 283 transactionID [4] OCTET STRING OPTIONAL, 284 senderNonce [5] OCTET STRING OPTIONAL, 285 recipNonce [6] OCTET STRING OPTIONAL, 286 freeText [7] PKIFreeText OPTIONAL, 287 generalInfo [8] SEQUENCE SIZE (1..MAX) OF 288 InfoTypeAndValue OPTIONAL 289 } 290 PKIFreeText ::= SEQUENCE SIZE (1..MAX) OF UTF8String 292 The usage of pvno values is described in Section 7. 294 2.4. New Section 5.1.1.3. - RootCaCert 296 Section 5.1.1 of RFC 4210 [RFC4210] defines the PKIHeader and id-it 297 OIDs to be used in the generalInfo field. This section introduces 298 id-it-rootCaCert. 300 Insert this section after Section 5.1.1.2: 302 5.1.1.3. RootCaCert 304 This is used by the EE to indicate a specific root CA certificate, 305 e.g., when requesting a root CA certificate update, see 306 Section 5.3.19.15. 308 id-it-rootCaCert OBJECT IDENTIFIER ::= {id-it TBD5} 309 RootCaCertValue ::= CMPCertificate 311 < TBD: The OID TBD5 has to be registered at IANA. > 313 2.5. New Section 5.1.1.4. - CertProfile 315 Section 5.1.1 of RFC 4210 [RFC4210] defines the PKIHeader and id-it 316 OIDs to be used in the generalInfo field. This section introduces 317 id-it-certProfile. 319 Insert this section after Section 5.1.1.3: 321 5.1.1.4. CertProfile 322 This is used by the EE to indicate a specific certificate profile, 323 e.g., when requesting a new certificate or a certificate request 324 template, see Section 5.3.19.16. 326 id-it-certProfile OBJECT IDENTIFIER ::= {id-it TBD6} 327 CertProfileValue ::= UTF8String 329 < TBD: The OID TBD6 has to be registered at IANA. > 331 2.6. Update Section 5.1.3.1. - Shared Secret Information 333 Section 5.1.3.1 of RFC 4210 [RFC4210] describes the MAC based 334 protection of a PKIMessage using the algorithm id-PasswordBasedMac. 336 Replace the first paragraph with the following text: 338 In this case, the sender and recipient share secret information with 339 sufficient entropy (established via out-of-band means or from a 340 previous PKI management operation). PKIProtection will contain a MAC 341 value and the protectionAlg MAY be one of the options described in 342 CMP Algorithms [I-D.ietf-lamps-cmp-algorithms]. The PasswordBasedMac 343 is specified as follows (see also [RFC4211] and 344 [I-D.ietf-lamps-crmf-update-algs]): 346 2.7. Replace Section 5.1.3.4 - Multiple Protection 348 Section 5.1.3.4 of RFC 4210 [RFC4210] describes the nested message. 349 This document enables using nested messages also for batch transport 350 of PKI messages between PKI management entities and with mixed body 351 types. 353 Replace the text of the section with the following text: 355 5.1.3.4. Multiple Protection 357 When receiving a protected PKI message, a PKI management entity such 358 as an RA MAY forward that message adding its own protection (which 359 MAY be a MAC or a signature, depending on the information and 360 certificates shared between the RA and the CA). Moreover, multiple 361 PKI messages MAY be aggregated. There are several use cases for such 362 messages. 364 * The RA confirms having validated and authorized a message and 365 forwards the original message unchanged. 367 * The RA modifies the message(s) in some way (e.g., adds or modifies 368 particular field values or add new extensions) before forwarding 369 them, then it MAY create its own desired PKIBody. If the changes 370 made by the RA to PKIMessage break the POP of a certificate 371 request, the RA MUST set the POP RAVerified. It MAY include the 372 original PKIMessage from the EE in the generalInfo field of 373 PKIHeader of a nested message (to accommodate, for example, cases 374 in which the CA wishes to check POP or other information on the 375 original EE message). The infoType to be used in this situation 376 is {id-it 15} (see Section 5.3.19 for the value of id-it) and the 377 infoValue is PKIMessages (contents MUST be in the same order as 378 the message in PKIBody). 380 * The RA collects several messages that are to be forwarded in the 381 same direction and forwards them in a batch. In communication to 382 the CA request messages and in communication from the CA response 383 or announcement messages will be collected. This can for instance 384 be used when bridging an off-line connection between two PKI 385 management entities. 387 These use cases are accomplished by nesting the messages within a new 388 PKI message. The structure used is as follows: 390 NestedMessageContent ::= PKIMessages 392 2.8. Replace Section 5.2.2. - Encrypted Values 394 Section 5.2.2 of RFC 4210 [RFC4210] describes the use of 395 EncryptedValue to transport encrypted data. This document extends 396 the encryption of data to preferably use EnvelopedData. 398 Replace the text of the section with the following text: 400 5.2.2. Encrypted Values 402 Where encrypted data (in this specification, private keys, 403 certificates, or revocation passphrase) are sent in PKI messages, the 404 EncryptedKey data structure is used. 406 EncryptedKey ::= CHOICE { 407 encryptedValue EncryptedValue, -- deprecated 408 envelopedData [0] EnvelopedData } 410 See CRMF [RFC4211] for EncryptedKey and EncryptedValue syntax and CMS 411 [RFC5652] for EnvelopedData syntax. Using the EncryptedKey data 412 structure offers the choice to either use EncryptedValue (for 413 backward compatibility only) or EnvelopedData. The use of the 414 EncryptedValue structure has been deprecated in favor of the 415 EnvelopedData structure. Therefore, it is recommended to use 416 EnvelopedData. 418 Note: The EncryptedKey structure defined in CRMF [RFC4211] is reused 419 here, which makes the update backward compatible. Using the new 420 syntax with the untagged default choice EncryptedValue is bits-on- 421 the-wire compatible with the old syntax. 423 To indicate support for EnvelopedData the pvno cmp2021 is introduced 424 by this document. Details on the usage of pvno values is described 425 in Section 7. 427 The EncryptedKey data structure is used in CMP to transport a private 428 key, certificate, or revocation passphrase in encrypted form. 430 EnvelopedData is used as follows: 432 * It contains only one RecipientInfo structure because the content 433 is encrypted only for one recipient. 435 * It may contain a private key in the AsymmetricKeyPackage structure 436 as defined in RFC 5958 [RFC5958] wrapped in a SignedData structure 437 as specified in CMS section 5 [RFC5652] signed by the Key 438 Generation Authority. 440 * It may contain a certificate or revocation passphrase directly in 441 the encryptedContent field. 443 The content of the EnvelopedData structure, as specified in CMS 444 section 6 [RFC5652], MUST be encrypted using a newly generated 445 symmetric content-encryption key. This content-encryption key MUST 446 be securely provided to the recipient using one of three key 447 management techniques. 449 The choice of the key management technique to be used by the sender 450 depends on the credential available at the recipient: 452 * Recipient's certificate that contains a key usage extension 453 asserting keyAgreement: The content-encryption key will be 454 protected using the key agreement key management technique, as 455 specified in CMS section 6.2.2 [RFC5652]. This is the preferred 456 technique. 458 * Recipient's certificate that contains a key usage extension 459 asserting keyEncipherment: The content-encryption key will be 460 protected using the key transport key management technique, as 461 specified in CMS section 6.2.1 [RFC5652]. 463 * A password or shared secret: The content-encryption key will be 464 protected using the password-based key management technique, as 465 specified in CMS section 6.2.4 [RFC5652]. 467 2.9. Update Section 5.3.4. - Certification Response 469 Section 5.3.4 of RFC 4210 [RFC4210] describes the Certification 470 Response. This document updates the syntax by using the parent 471 structure EncryptedKey instead of EncryptedValue as described in 472 Section 2.8 above. Moreover, it clarifies the certReqId to be used 473 in response to a p10cr message. 475 Replace the ASN.1 syntax of CertifiedKeyPair and CertOrEncCert with 476 the following text: 478 CertifiedKeyPair ::= SEQUENCE { 479 certOrEncCert CertOrEncCert, 480 privateKey [0] EncryptedKey OPTIONAL, 481 -- see [CRMF] for comment on encoding 482 publicationInfo [1] PKIPublicationInfo OPTIONAL 483 } 485 CertOrEncCert ::= CHOICE { 486 certificate [0] Certificate, 487 encryptedCert [1] EncryptedKey 488 } 490 Add the following as a new paragraph right after the ASN.1 syntax: 492 A p10cr message contains exactly one CertificationRequestInfo data 493 structure as specified in PKCS#10 [RFC2986] but no certReqId. 494 Therefore, the certReqId in the corresponding certification response 495 (cp) message MUST be set to 0. 497 Add the following as new paragraphs to the end of the section: 499 The use of EncryptedKey is described in Section 5.2.2. 501 Note: To indicate support for EnvelopedData the pvno cmp2021 is 502 introduced by this document. Details on the usage of different pvno 503 values is described in Section 7. 505 2.10. Update Section 5.3.19.2. - Signing Key Pair Types 507 The following section clarifies the usage of the Signing Key Pair 508 Types on referencing EC curves. 510 Insert this note at the end of Section 5.3.19.2: 512 Note: In case several EC curves are supported, several id-ecPublicKey 513 elements need to be given, one per named curve. 515 2.11. Update Section 5.3.19.3. - Encryption/Key Agreement Key Pair 516 Types 518 The following section clarifies the use of the Encryption/Key 519 Agreement Key Pair Types on referencing EC curves. 521 Insert this note at the end of Section 5.3.19.3: 523 Note: In case several EC curves are supported, several id-ecPublicKey 524 elements need to be given, one per named curve. 526 2.12. Replace Section 5.3.19.9. - Revocation Passphrase 528 Section 5.3.19.9 of RFC 4210 [RFC4210] describes the provisioning of 529 a revocation passphrase for authenticating a later revocation 530 request. This document updates the handling by using the parent 531 structure EncryptedKey instead of EncryptedValue to transport this 532 information as described in Section 2.8 above. 534 Replace the text of the section with the following text: 536 5.3.19.9. Revocation Passphrase 538 This MAY be used by the EE to send a passphrase to a CA/RA for the 539 purpose of authenticating a later revocation request (in the case 540 that the appropriate signing private key is no longer available to 541 authenticate the request). See Appendix B for further details on the 542 use of this mechanism. 544 GenMsg: {id-it 12}, EncryptedKey 545 GenRep: {id-it 12}, < absent > 547 The use of EncryptedKey is described in Section 5.2.2. 549 2.13. New Section 5.3.19.14 - CA Certificates 551 The following subsection describes PKI general messages using id-it- 552 caCerts. The use is specified in Lightweight CMP Profile [I-D.ietf- 553 lamps-lightweight-cmp-profile] Section 4.4. 555 Insert this section after Section 5.3.19.13: 557 2.3.19.14 CA Certificates 559 This MAY be used by the client to get the current CA intermediate and 560 issuing CA certificates. 562 GenMsg: {id-it 17}, < absent > 563 GenRep: {id-it 17}, SEQUENCE OF CMPCertificate | < absent > 565 2.14. New Section 5.3.19.15 - Root CA Certificate Update 567 The following subsection describes PKI general messages using id-it- 568 rootCaKeyUpdate. The use is specified in Lightweight CMP Profile [I- 569 D.ietf-lamps-lightweight-cmp-profile] Section 4.4. 571 Insert this section after new Section 5.3.19.14: 573 5.3.19.15. Root CA Certificate Update 575 This MAY be used by the client to get an update of an existing root 576 CA Certificate, which MAY be indicated in the rootCaCert field, see 577 Section 5.1.1.3, of the PKIHeader of the request message. In 578 contrast to the ckuann message this approach follows the request/ 579 response model. 581 GenMsg: {id-it 18}, < absent > 582 GenRep: {id-it 18}, RootCaKeyUpdateContent | < absent > 584 RootCaKeyUpdateContent ::= SEQUENCE { 585 newWithNew CMPCertificate, 586 newWithOld [0] CMPCertificate OPTIONAL, 587 oldWithNew [1] CMPCertificate OPTIONAL 588 } 590 Note: In contrast to CAKeyUpdAnnContent, this type offers omitting 591 newWithOld and oldWithNew in the GenRep message, depending on the 592 needs of the EE. 594 2.15. New Section 5.3.19.16 - Certificate Request Template 596 The following subsection introduces the PKI general message using id- 597 it-certReqTemplate. Details are specified in the Lightweight CMP 598 Profile [I-D.ietf-lamps-lightweight-cmp-profile] Section 4.4. 600 Insert this section after new Section 5.3.19.15: 602 5.3.19.16. Certificate Request Template 604 This MAY be used by the client to get a template containing 605 requirements for certificate request attributes and extensions. The 606 controls id-regCtrl-algId and id-regCtrl-rsaKeyLen MAY contain 607 details on the types of subject public keys the CA is willing to 608 certify. 610 The id-regCtrl-algId control MAY be used to identify a cryptographic 611 algorithm, see RFC 5280 Section 4.1.2.7 [RFC5280], other than 612 rsaEncryption. The algorithm field SHALL identify a cryptographic 613 algorithm. The contents of the optional parameters field will vary 614 according to the algorithm identified. For example, when the 615 algorithm is set to id-ecPublicKey, the parameters identify the 616 elliptic curve to be used, see [RFC5480]. 618 The id-regCtrl-rsaKeyLen control SHALL be used for algorithm 619 rsaEncrytion and SHALL contain the intended modulus bit length of the 620 RSA key. 622 GenMsg: {id-it 19}, < absent > 623 GenRep: {id-it 19}, CertReqTemplateContent | < absent > 625 CertReqTemplateValue ::= CertReqTemplateContent 626 CertReqTemplateContent ::= SEQUENCE { 627 certTemplate CertTemplate, 628 keySpec Controls OPTIONAL 629 } 631 Controls ::= SEQUENCE SIZE(1..MAX) OF AttributeTypeAndValue 633 id-regCtrl-algId OBJECT IDENTIFIER ::= { iso(1) 634 identified-organization(3) dod(6) internet(1) security(5) 635 mechanisms(5) pkix(7) pkip(5) regCtrl(1) TBD3 } 636 AlgIdCtrl ::= AlgorithmIdentifier{ALGORITHM, {...}} 638 id-regCtrl-rsaKeyLen OBJECT IDENTIFIER ::= { iso(1) 639 identified-organization(3) dod(6) internet(1) security(5) 640 mechanisms(5) pkix(7) pkip(5) regCtrl(1) TBD4 } 641 RsaKeyLenCtrl ::= INTEGER 643 < TBD: The OIDs TBD3 and TBD4 have to be registered at IANA. > 645 The CertReqTemplateValue contains the prefilled certTemplate to be 646 used for a future certificate request. The publicKey field in the 647 certTemplate MUST NOT be used. In case the PKI management entity 648 wishes to specify supported public-key algorithms, the keySpec field 649 MUST be used. One AttributeTypeAndValue per supported algorithm or 650 RSA key length MUST be used. 652 Note: The Controls ASN.1 type is defined in CRMF Section 6 [RFC4211] 654 2.16. Update Section 5.3.22 - Polling Request and Response 656 Section 5.3.22 of RFC 4210 [RFC4210] describes when and how polling 657 messages are used. This document adds the polling mechanism also for 658 outstanding responses to a p10cr. 660 Replace in the first paragraph the word 'cr' by 'cr, p10cr' and add 661 just before the state machine diagram the following text: 663 A p10cr message contains exactly one CertificationRequestInfo data 664 structure as specified in PKCS#10 [RFC2986] but no certificate 665 request identifier. Therefore, the certReqId MUST be set to 0 in all 666 subsequent messages of this transaction. 668 2.17. Update Section 7 - Version Negotiation 670 Section 7 of RFC 4210 [RFC4210] describes the use of CMP protocol 671 versions. This document describes the handling of the additional CMP 672 version cmp2021 introduced to indicate support of EnvelopedData. 674 Replace the text of the first two paragraphs with the following text: 676 This section defines the version negotiation between client and 677 server used to choose among cmp1999 (specified in RFC 2510 678 [RFC2510]), cmp2000 (specified in RFC 4210 [RFC4210]), and cmp2021 679 (specified in this document). The only difference between protocol 680 versions cmp2021 and cmp2000 is that EnvelopedData replaces 681 EncryptedValue. 683 If a client does not support cmp2021 it chooses the versions for a 684 request as follows: 686 * If the client knows the protocol version(s) supported by the 687 server (e.g., from a previous PKIMessage exchange or via some out- 688 of-band means), then it MUST send a PKIMessage with the highest 689 version supported by both itself and the server. 691 * If the client does not know what version(s) the server supports, 692 then it MUST send a PKIMessage using the highest version it 693 supports. 695 If a client supports cmp2021 and encrypted values are supposed to be 696 transferred in the PKI management operation the client MUST choose 697 the version for a request as follows: 699 * If the client supports EnvelopedData, but not EncryptedValue, then 700 it MUST send a PKIMessage using cmp2021. 702 * If the client does not support EnvelopedData, but EncryptedValue, 703 then it MUST send a PKIMessage using cmp2000. 705 * If the client supports both EnvelopedData and EncryptedValue: 707 - If the client knows the protocol version(s) supported by the 708 server (e.g., from a previous PKIMessage exchange or via some 709 out-of-band means), then it MUST send a PKIMessage with the 710 highest version supported the server. 712 - If the client does not know what version(s) the server 713 supports, then it MUST send a PKIMessage using cmp2021. 715 2.18. Update Section 7.1.1. - Clients Talking to RFC 2510 Servers 717 Section 7.1.1 of RFC 4210 [RFC4210] describes the behavior of a 718 client sending a cmp2000 message talking to a cmp1999 server. This 719 document extends the section to clients with any higher version than 720 cmp1999. 722 Replace the first sentence of Section 7.1.1 with the following text: 724 If, after sending a message with a protocol version number higher 725 than cmp1999, a client receives an ErrorMsgContent with a version of 726 cmp1999, then it MUST abort the current transaction. 728 2.19. Update Section 9 - IANA Considerations 730 Section 9 of RFC 4210 [RFC4210] contains the IANA Considerations of 731 that document. As this document defines a new Extended Key Usage, 732 the IANA Considerations need to be updated accordingly. 734 Add the following paragraphs after the third paragraph of the 735 section: 737 In the SMI-numbers registry "SMI Security for PKIX Extended Key 738 Purpose Identifiers (1.3.6.1.5.5.7.3)" (see 739 https://www.iana.org/assignments/smi-numbers/smi-numbers.xhtml#smi- 740 numbers-1.3.6.1.5.5.7.3) as defined in RFC 7299 [RFC7299] one 741 addition has been performed. 743 One new entry has been added: 745 +=========+=============+============+ 746 | Decimal | Description | References | 747 +=========+=============+============+ 748 | 32 | id-kp-cmKGA | [thisRFC] | 749 +---------+-------------+------------+ 750 Table 1: Addition to the PKIX 751 Extended Key Purpose Identifiers 752 registry 754 In the SMI-numbers registry "SMI Security for PKIX CMP Information 755 Types (1.3.6.1.5.5.7.4)" (see https://www.iana.org/assignments/smi- 756 numbers/smi-numbers.xhtml#smi-numbers-1.3.6.1.5.5.7.4) as defined in 757 RFC 7299 [RFC7299] fife additions have been performed. 759 Fife new entries have been added: 761 +=========+=======================+============+ 762 | Decimal | Description | References | 763 +=========+=======================+============+ 764 | 17 | id-it-caCerts | [thisRFC] | 765 +---------+-----------------------+------------+ 766 | 18 | id-it-rootCaKeyUpdate | [thisRFC] | 767 +---------+-----------------------+------------+ 768 | 19 | id-it-certReqTemplate | [thisRFC] | 769 +---------+-----------------------+------------+ 770 | TBD5 | id-it-rootCaCert | [thisRFC] | 771 +---------+-----------------------+------------+ 772 | TBD6 | id-it-certProfile | [thisRFC] | 773 +---------+-----------------------+------------+ 775 Table 2: Addition to the PKIX CMP 776 Information Types registry 778 In the SMI-numbers registry " SMI Security for PKIX CRMF Registration 779 Controls (1.3.6.1.5.5.7.5.1)" (see https://www.iana.org/assignments/ 780 smi-numbers/smi-numbers.xhtml#smi-numbers-1.3.6.1.5.5.7.5.1) as 781 defined in RFC 7299 [RFC7299] two additions have been performed. 783 Two new entries have been added: 785 +=========+======================+============+ 786 | Decimal | Description | References | 787 +=========+======================+============+ 788 | TBD3 | id-regCtrl-algId | [thisRFC] | 789 +---------+----------------------+------------+ 790 | TBD4 | id-regCtrl-rsaKeyLen | [thisRFC] | 791 +---------+----------------------+------------+ 793 Table 3: Addition to the PKIX CRMF 794 Registration Controls registry 796 2.20. Update Appendix B - The Use of Revocation Passphrase 798 Appendix B of RFC 4210 [RFC4210] describes the use of the revocation 799 passphrase. As this document updates RFC 4210 [RFC4210] to utilize 800 the parent structure EncryptedKey instead of EncryptedValue as 801 described in Section 2.8 above, the description is updated 802 accordingly. 804 Replace the first bullet point of this section with the following 805 text: 807 * The OID and value specified in Section 5.3.19.9 MAY be sent in a 808 GenMsg message at any time, or MAY be sent in the generalInfo 809 field of the PKIHeader of any PKIMessage at any time. (In 810 particular, the EncryptedKey structure as described in section 811 5.2.2 may be sent in the header of the certConf message that 812 confirms acceptance of certificates requested in an initialization 813 request or certificate request message.) This conveys a 814 revocation passphrase chosen by the entity to the relevant CA/RA. 815 For use of EnvelopedData this is in the decrypted bytes of 816 encryptedContent field and for use of EncryptedValue this is in 817 the decrypted bytes of the encValue field. Furthermore, the 818 transfer is accomplished with appropriate confidentiality 819 characteristics. 821 Replace the third bullet point of this section with the following 822 text: 824 * When using EnvelopedData the localKeyId attribute as specified in 825 RFC 2985 [RFC2985] and when using EncryptedValue the valueHint 826 field MAY contain a key identifier (chosen by the entity, along 827 with the passphrase itself) to assist in later retrieval of the 828 correct passphrase (e.g., when the revocation request is 829 constructed by the entity and received by the CA/RA). 831 2.21. Update Appendix C - Request Message Behavioral Clarifications 833 Appendix C of RFC 4210 [RFC4210] provides clarifications to the 834 request message behavior. As this document updates RFC 4210 835 [RFC4210] to utilize the parent structure EncryptedKey instead of 836 EncryptedValue as described in Section 2.8 above, the description is 837 updated accordingly. 839 Replace the comment within the ASN.1 syntax coming after the 840 definition of POPOPrivKey with the following text: 842 -- ********** 843 -- * the type of "thisMessage" is given as BIT STRING in RFC 4211 844 -- * [RFC4211]; it should be "EncryptedKey" (in accordance with 845 -- * Section 5.2.2 of this specification). Therefore, this 846 -- * document makes the behavioral clarification of specifying 847 -- * that the contents of "thisMessage" MUST be encoded either as 848 -- * "EnvelopedData" or "EncryptedValue" (only for backward 849 -- * compatibility) and then wrapped in a BIT STRING. This 850 -- * allows the necessary conveyance and protection of the 851 -- * private key while maintaining bits-on-the-wire compatibility 852 -- * with RFC 4211 [RFC4211]. 853 -- ********** 855 2.22. Update Appendix D.1. - General Rules for Interpretation of These 856 Profiles 858 Appendix D.1 of RFC 4210 [RFC4210] provides general rules for 859 interpretation of the PKI management messages profiles specified in 860 Appendix D and Appendix E of RFC 4210 [RFC4210]. This document 861 updates a sentence regarding the new protocol version cmp2021. 863 Replace the last sentence of the first paragraph of the section with 864 the following text: 866 Mandatory fields are not mentioned if they have an obvious value 867 (e.g., in this version of these profiles, pvno is always cmp2000). 869 2.23. Update Appendix D.2. - Algorithm Use Profile 871 Appendix D.2 of RFC 4210 [RFC4210] provides a list of algorithms that 872 implementations must support when claiming conformance with PKI 873 Management Message Profiles as specified in CMP Appendix D.2 874 [RFC4210]. This document redirects to the new algorithm profile as 875 specified in Appendix A.1 of CMP Algorithms 876 [I-D.ietf-lamps-cmp-algorithms]. 878 Replace the text of the section with the following text: 880 D.2. Algorithm Use Profile 882 For specifications of algorithm identifiers and respective 883 conventions for conforming implementations, please refer to CMP 884 Algorithms Appendix A.1 [I-D.ietf-lamps-cmp-algorithms]. 886 2.24. Update Appendix D.4. - Initial Registration/Certification (Basic 887 Authenticated Scheme) 889 Appendix D.4 of RFC 4210 [RFC4210] provides the initial registration/ 890 certification scheme. This scheme shall continue using 891 EncryptedValue for backward compatibility reasons. 893 Replace the comment after the privateKey field of 894 crc[1].certifiedKeyPair in the syntax of the Initialization Response 895 message with the following text: 897 -- see Appendix C, Request Message Behavioral Clarifications 898 -- for backward compatibility reasons, use EncryptedValue 900 3. Updates to RFC 6712 - HTTP Transfer for the Certificate Management 901 Protocol (CMP) 903 3.1. New Section 1.1. - Changes since RFC 6712 905 The following subsection describes feature updates to RFC 6712 906 [RFC6712]. They are related to the base specification. Hence 907 references to the original sections in RFC 6712 [RFC6712] are used 908 whenever possible. 910 Insert this section at the end of the current Section 1: 912 1.1 Changes since RFC 6712 914 The following updates are made in [thisRFC]: 916 * Introduce the HTTP path '/.well-known/cmp'. 918 * Extend the URI structure. 920 3.2. Replace Section 3.6. - HTTP Request-URI 922 Section 3.6 of RFC 6712 [RFC6712] specifies the used HTTP URIs. This 923 document introduces the HTTP path '/.well-known/cmp' and extends the 924 URIs. 926 Replace the text of the section with the following text: 928 3.6. HTTP Request-URI 930 Each CMP server on a PKI management entity supporting HTTP or HTTPS 931 transport MUST support the use of the path prefix '/.well-known/' as 932 defined in RFC 8615 [RFC8615] and the registered name 'cmp' to ease 933 interworking in a multi-vendor environment. 935 The CMP client needs to be configured with sufficient information to 936 form the CMP server URI. This is at least the authority portion of 937 the URI, e.g., 'www.example.com:80', or the full operation path 938 segment of the PKI management entity. Additionally, OPTIONAL path 939 segments MAY be added after the registered application name as part 940 of the full operation path to provide further distinction. A path 941 segment could for example support the differentiation of specific 942 CAs, certificate profiles, or PKI management operations. A valid 943 full operation path segment can look like this: 945 http://www.example.com/.well-known/cmp 946 http://www.example.com/.well-known/cmp/operationLabel 947 http://www.example.com/.well-known/cmp/profileLabel 948 http://www.example.com/.well-known/cmp/profileLabel/operationLabel 950 3.3. Update Section 6. - IANA Considerations 952 Section 6 of RFC 6712 [RFC6712] contains the IANA Considerations of 953 that document. As this document defines a new '.well-known' URI 954 prefix, the IANA Considerations need to be updated accordingly. 956 Add the following text between the first and second paragraph of the 957 section: 959 In the registry of well-known URIs (see 960 https://www.iana.org/assignments/well-known-uris/well-known- 961 uris.xhtml#well-known-uris-1) as defined in RFC 8615 [RFC8615] the 962 following change has been performed. 964 One new name entry has been added: 966 +============+===================+ 967 | URI suffix | Change controller | 968 +============+===================+ 969 | cmp | IETF | 970 +------------+-------------------+ 972 Table 4 974 4. IANA Considerations 976 This document contains an update to the IANA Consideration sections 977 to be added to [RFC4210] and [RFC6712]. 979 < TBD: This document updates the ASN.1 modules of RFC 4210 Appendix F 980 [RFC4210] and RFC 5912 Section 9 [RFC5912]. New OIDs TBD1 and TBD2 981 need to be registered to identify the updated ASN.1 modules. > 982 < TBD: New OIDs TBD3 (id-regCtrl-algId) and TBD4 (id-regCtrl- 983 rsaKeyLen) need to be registered. > 985 < TBD: New OIDs TBD5 (id-it-rootCaCert) and TBD6 (id-it-certProfile) 986 need to be registered. > 988 5. Security Considerations 990 No changes are made to the existing security considerations of 991 RFC 4210 [RFC4210] and RFC 6712 [RFC6712]. 993 6. Acknowledgements 995 Special thank goes to Jim Schaad for his guidance and the inspiration 996 on structuring and writing this document we got from [RFC6402] which 997 updates CMC. Special thank also goes also to Russ Housley and Tomas 998 Gustavsson for reviewing and providing valuable suggestions on 999 improving this document. 1001 We also thank all reviewers of this document for their valuable 1002 feedback. 1004 7. References 1006 7.1. Normative References 1008 [I-D.ietf-lamps-cmp-algorithms] 1009 Brockhaus, H., Aschauer, H., Ounsworth, M., and S. Mister, 1010 "Certificate Management Protocol (CMP) Algorithms", Work 1011 in Progress, Internet-Draft, draft-ietf-lamps-cmp- 1012 algorithms-03, 22 February 2021, 1013 . 1016 [I-D.ietf-lamps-crmf-update-algs] 1017 Housley, R., "Algorithm Requirements Update to the 1018 Internet X.509 Public Key Infrastructure Certificate 1019 Request Message Format (CRMF)", Work in Progress, 1020 Internet-Draft, draft-ietf-lamps-crmf-update-algs-07, 8 1021 April 2021, . 1024 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 1025 Requirement Levels", BCP 14, RFC 2119, 1026 DOI 10.17487/RFC2119, March 1997, 1027 . 1029 [RFC2510] Adams, C. and S. Farrell, "Internet X.509 Public Key 1030 Infrastructure Certificate Management Protocols", 1031 RFC 2510, DOI 10.17487/RFC2510, March 1999, 1032 . 1034 [RFC2985] Nystrom, M. and B. Kaliski, "PKCS #9: Selected Object 1035 Classes and Attribute Types Version 2.0", RFC 2985, 1036 DOI 10.17487/RFC2985, November 2000, 1037 . 1039 [RFC2986] Nystrom, M. and B. Kaliski, "PKCS #10: Certification 1040 Request Syntax Specification Version 1.7", RFC 2986, 1041 DOI 10.17487/RFC2986, November 2000, 1042 . 1044 [RFC4210] Adams, C., Farrell, S., Kause, T., and T. Mononen, 1045 "Internet X.509 Public Key Infrastructure Certificate 1046 Management Protocol (CMP)", RFC 4210, 1047 DOI 10.17487/RFC4210, September 2005, 1048 . 1050 [RFC4211] Schaad, J., "Internet X.509 Public Key Infrastructure 1051 Certificate Request Message Format (CRMF)", RFC 4211, 1052 DOI 10.17487/RFC4211, September 2005, 1053 . 1055 [RFC5280] Cooper, D., Santesson, S., Farrell, S., Boeyen, S., 1056 Housley, R., and W. Polk, "Internet X.509 Public Key 1057 Infrastructure Certificate and Certificate Revocation List 1058 (CRL) Profile", RFC 5280, DOI 10.17487/RFC5280, May 2008, 1059 . 1061 [RFC5480] Turner, S., Brown, D., Yiu, K., Housley, R., and T. Polk, 1062 "Elliptic Curve Cryptography Subject Public Key 1063 Information", RFC 5480, DOI 10.17487/RFC5480, March 2009, 1064 . 1066 [RFC5652] Housley, R., "Cryptographic Message Syntax (CMS)", STD 70, 1067 RFC 5652, DOI 10.17487/RFC5652, September 2009, 1068 . 1070 [RFC5912] Hoffman, P. and J. Schaad, "New ASN.1 Modules for the 1071 Public Key Infrastructure Using X.509 (PKIX)", RFC 5912, 1072 DOI 10.17487/RFC5912, June 2010, 1073 . 1075 [RFC5958] Turner, S., "Asymmetric Key Packages", RFC 5958, 1076 DOI 10.17487/RFC5958, August 2010, 1077 . 1079 [RFC6402] Schaad, J., "Certificate Management over CMS (CMC) 1080 Updates", RFC 6402, DOI 10.17487/RFC6402, November 2011, 1081 . 1083 [RFC6712] Kause, T. and M. Peylo, "Internet X.509 Public Key 1084 Infrastructure -- HTTP Transfer for the Certificate 1085 Management Protocol (CMP)", RFC 6712, 1086 DOI 10.17487/RFC6712, September 2012, 1087 . 1089 [RFC7299] Housley, R., "Object Identifier Registry for the PKIX 1090 Working Group", RFC 7299, DOI 10.17487/RFC7299, July 2014, 1091 . 1093 [RFC8174] Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC 1094 2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174, 1095 May 2017, . 1097 [RFC8615] Nottingham, M., "Well-Known Uniform Resource Identifiers 1098 (URIs)", RFC 8615, DOI 10.17487/RFC8615, May 2019, 1099 . 1101 7.2. Informative References 1103 [I-D.ietf-lamps-lightweight-cmp-profile] 1104 Brockhaus, H., Fries, S., and D. V. Oheimb, "Lightweight 1105 Certificate Management Protocol (CMP) Profile", Work in 1106 Progress, Internet-Draft, draft-ietf-lamps-lightweight- 1107 cmp-profile-05, 22 February 2021, 1108 . 1111 [IEEE.802.1AR_2018] 1112 IEEE, "IEEE Standard for Local and metropolitan area 1113 networks - Secure Device Identity", IEEE 802.1AR-2018, 1114 DOI 10.1109/IEEESTD.2018.8423794, 2 August 2018, 1115 . 1117 Appendix A. ASN.1 Modules 1118 A.1. 1988 ASN.1 Module 1120 This section contains the updated ASN.1 module for [RFC4210]. This 1121 module replaces the module in Appendix F of that document. Although 1122 a 2002 ASN.1 module is provided, this 1988 ASN.1 module remains the 1123 normative module as per the policy of the PKIX working group. 1125 PKIXCMP {iso(1) identified-organization(3) 1126 dod(6) internet(1) security(5) mechanisms(5) pkix(7) 1127 id-mod(0) id-mod-cmp2021-88(TBD1)} 1129 DEFINITIONS EXPLICIT TAGS ::= 1131 BEGIN 1133 -- EXPORTS ALL -- 1135 IMPORTS 1137 Certificate, CertificateList, Extensions, AlgorithmIdentifier, 1138 UTF8String, id-kp -- if required; otherwise, comment out 1139 FROM PKIX1Explicit88 {iso(1) identified-organization(3) 1140 dod(6) internet(1) security(5) mechanisms(5) pkix(7) 1141 id-mod(0) id-pkix1-explicit-88(18)} 1143 GeneralName, KeyIdentifier 1144 FROM PKIX1Implicit88 {iso(1) identified-organization(3) 1145 dod(6) internet(1) security(5) mechanisms(5) pkix(7) 1146 id-mod(0) id-pkix1-implicit-88(19)} 1148 CertTemplate, PKIPublicationInfo, EncryptedKey, CertId, 1149 CertReqMessages, Controls, id-regCtrl 1150 FROM PKIXCRMF-2005 {iso(1) identified-organization(3) 1151 dod(6) internet(1) security(5) mechanisms(5) pkix(7) 1152 id-mod(0) id-mod-crmf2005(36)} 1153 -- The import of EncryptedKey is added due to the updates made 1154 -- in CMP Updates [thisRFC]]. EncryptedValue does not need to 1155 -- be imported anymore and is therefore removed here. 1157 -- see also the behavioral clarifications to CRMF codified in 1158 -- Appendix C of this specification 1159 CertificationRequest 1160 FROM PKCS-10 {iso(1) member-body(2) 1161 us(840) rsadsi(113549) 1162 pkcs(1) pkcs-10(10) modules(1) pkcs-10(1)} 1163 -- (specified in RFC 2986 with 1993 ASN.1 syntax and IMPLICIT 1164 -- tags). Alternatively, implementers may directly include 1165 -- the [PKCS10] syntax in this module 1166 EnvelopedData, SignedData 1167 FROM CryptographicMessageSyntax2004 { iso(1) 1168 member-body(2) us(840) rsadsi(113549) pkcs(1) pkcs-9(9) 1169 smime(16) modules(0) cms-2004(24) } 1170 -- The import of EnvelopedData and SignedData is added due to 1171 -- the updates made in CMP Updates [thisRFC] 1173 ; 1175 -- the rest of the module contains locally-defined OIDs and 1176 -- constructs 1178 CMPCertificate ::= CHOICE { 1179 x509v3PKCert Certificate 1180 } 1181 -- This syntax, while bits-on-the-wire compatible with the 1182 -- standard X.509 definition of "Certificate", allows the 1183 -- possibility of future certificate types (such as X.509 1184 -- attribute certificates, WAP WTLS certificates, or other kinds 1185 -- of certificates) within this certificate management protocol, 1186 -- should a need ever arise to support such generality. Those 1187 -- implementations that do not foresee a need to ever support 1188 -- other certificate types MAY, if they wish, comment out the 1189 -- above structure and "un-comment" the following one prior to 1190 -- compiling this ASN.1 module. (Note that interoperability 1191 -- with implementations that don't do this will be unaffected by 1192 -- this change.) 1194 -- CMPCertificate ::= Certificate 1196 PKIMessage ::= SEQUENCE { 1197 header PKIHeader, 1198 body PKIBody, 1199 protection [0] PKIProtection OPTIONAL, 1200 extraCerts [1] SEQUENCE SIZE (1..MAX) OF CMPCertificate 1201 OPTIONAL 1202 } 1204 PKIMessages ::= SEQUENCE SIZE (1..MAX) OF PKIMessage 1206 PKIHeader ::= SEQUENCE { 1207 pvno INTEGER { cmp1999(1), cmp2000(2), 1208 cmp2021(3) }, 1209 sender GeneralName, 1210 -- identifies the sender 1211 recipient GeneralName, 1212 -- identifies the intended recipient 1213 messageTime [0] GeneralizedTime OPTIONAL, 1214 -- time of production of this message (used when sender 1215 -- believes that the transport will be "suitable"; i.e., 1216 -- that the time will still be meaningful upon receipt) 1217 protectionAlg [1] AlgorithmIdentifier OPTIONAL, 1218 -- algorithm used for calculation of protection bits 1219 senderKID [2] KeyIdentifier OPTIONAL, 1220 recipKID [3] KeyIdentifier OPTIONAL, 1221 -- to identify specific keys used for protection 1222 transactionID [4] OCTET STRING OPTIONAL, 1223 -- identifies the transaction; i.e., this will be the same in 1224 -- corresponding request, response, certConf, and PKIConf 1225 -- messages 1226 senderNonce [5] OCTET STRING OPTIONAL, 1227 recipNonce [6] OCTET STRING OPTIONAL, 1228 -- nonces used to provide replay protection, senderNonce 1229 -- is inserted by the creator of this message; recipNonce 1230 -- is a nonce previously inserted in a related message by 1231 -- the intended recipient of this message 1232 freeText [7] PKIFreeText OPTIONAL, 1233 -- this may be used to indicate context-specific instructions 1234 -- (this field is intended for human consumption) 1235 generalInfo [8] SEQUENCE SIZE (1..MAX) OF 1236 InfoTypeAndValue OPTIONAL 1237 -- this may be used to convey context-specific information 1238 -- (this field not primarily intended for human consumption) 1239 } 1241 PKIFreeText ::= SEQUENCE SIZE (1..MAX) OF UTF8String 1242 -- text encoded as UTF-8 String [RFC3629] (note: each 1243 -- UTF8String MAY include an [RFC3066] language tag 1244 -- to indicate the language of the contained text 1245 -- see [RFC2482] for details) 1247 PKIBody ::= CHOICE { -- message-specific body elements 1248 ir [0] CertReqMessages, --Initialization Request 1249 ip [1] CertRepMessage, --Initialization Response 1250 cr [2] CertReqMessages, --Certification Request 1251 cp [3] CertRepMessage, --Certification Response 1252 p10cr [4] CertificationRequest, --imported from [PKCS10] 1253 popdecc [5] POPODecKeyChallContent, --pop Challenge 1254 popdecr [6] POPODecKeyRespContent, --pop Response 1255 kur [7] CertReqMessages, --Key Update Request 1256 kup [8] CertRepMessage, --Key Update Response 1257 krr [9] CertReqMessages, --Key Recovery Request 1258 krp [10] KeyRecRepContent, --Key Recovery Response 1259 rr [11] RevReqContent, --Revocation Request 1260 rp [12] RevRepContent, --Revocation Response 1261 ccr [13] CertReqMessages, --Cross-Cert. Request 1262 ccp [14] CertRepMessage, --Cross-Cert. Response 1263 ckuann [15] CAKeyUpdAnnContent, --CA Key Update Ann. 1264 cann [16] CertAnnContent, --Certificate Ann. 1265 rann [17] RevAnnContent, --Revocation Ann. 1266 crlann [18] CRLAnnContent, --CRL Announcement 1267 pkiconf [19] PKIConfirmContent, --Confirmation 1268 nested [20] NestedMessageContent, --Nested Message 1269 genm [21] GenMsgContent, --General Message 1270 genp [22] GenRepContent, --General Response 1271 error [23] ErrorMsgContent, --Error Message 1272 certConf [24] CertConfirmContent, --Certificate confirm 1273 pollReq [25] PollReqContent, --Polling request 1274 pollRep [26] PollRepContent --Polling response 1275 } 1277 PKIProtection ::= BIT STRING 1279 ProtectedPart ::= SEQUENCE { 1280 header PKIHeader, 1281 body PKIBody 1282 } 1284 id-PasswordBasedMac OBJECT IDENTIFIER ::= {1 2 840 113533 7 66 13} 1285 PBMParameter ::= SEQUENCE { 1286 salt OCTET STRING, 1287 -- note: implementations MAY wish to limit acceptable sizes 1288 -- of this string to values appropriate for their environment 1289 -- in order to reduce the risk of denial-of-service attacks 1290 owf AlgorithmIdentifier, 1291 -- AlgId for a One-Way Function (SHA-1 recommended) 1292 iterationCount INTEGER, 1293 -- number of times the OWF is applied 1294 -- note: implementations MAY wish to limit acceptable sizes 1295 -- of this integer to values appropriate for their environment 1296 -- in order to reduce the risk of denial-of-service attacks 1297 mac AlgorithmIdentifier 1298 -- the MAC AlgId (e.g., DES-MAC, Triple-DES-MAC [PKCS11], 1299 } -- or HMAC [RFC2104, RFC2202]) 1301 id-DHBasedMac OBJECT IDENTIFIER ::= {1 2 840 113533 7 66 30} 1302 DHBMParameter ::= SEQUENCE { 1303 owf AlgorithmIdentifier, 1304 -- AlgId for a One-Way Function (SHA-1 recommended) 1305 mac AlgorithmIdentifier 1306 -- the MAC AlgId (e.g., DES-MAC, Triple-DES-MAC [PKCS11], 1307 } -- or HMAC [RFC2104, RFC2202]) 1308 NestedMessageContent ::= PKIMessages 1310 PKIStatus ::= INTEGER { 1311 accepted (0), 1312 -- you got exactly what you asked for 1313 grantedWithMods (1), 1314 -- you got something like what you asked for; the 1315 -- requester is responsible for ascertaining the differences 1316 rejection (2), 1317 -- you don't get it, more information elsewhere in the message 1318 waiting (3), 1319 -- the request body part has not yet been processed; expect to 1320 -- hear more later (note: proper handling of this status 1321 -- response MAY use the polling req/rep PKIMessages specified 1322 -- in Section 5.3.22; alternatively, polling in the underlying 1323 -- transport layer MAY have some utility in this regard) 1324 revocationWarning (4), 1325 -- this message contains a warning that a revocation is 1326 -- imminent 1327 revocationNotification (5), 1328 -- notification that a revocation has occurred 1329 keyUpdateWarning (6) 1330 -- update already done for the oldCertId specified in 1331 -- CertReqMsg 1332 } 1334 PKIFailureInfo ::= BIT STRING { 1335 -- since we can fail in more than one way! 1336 -- More codes may be added in the future if/when required. 1337 badAlg (0), 1338 -- unrecognized or unsupported Algorithm Identifier 1339 badMessageCheck (1), 1340 -- integrity check failed (e.g., signature did not verify) 1341 badRequest (2), 1342 -- transaction not permitted or supported 1343 badTime (3), 1344 -- messageTime was not sufficiently close to the system time, 1345 -- as defined by local policy 1346 badCertId (4), 1347 -- no certificate could be found matching the provided criteria 1348 badDataFormat (5), 1349 -- the data submitted has the wrong format 1350 wrongAuthority (6), 1351 -- the authority indicated in the request is different from the 1352 -- one creating the response token 1353 incorrectData (7), 1354 -- the requester's data is incorrect (for notary services) 1355 missingTimeStamp (8), 1356 -- when the timestamp is missing but should be there 1357 -- (by policy) 1358 badPOP (9), 1359 -- the proof-of-possession failed 1360 certRevoked (10), 1361 -- the certificate has already been revoked 1362 certConfirmed (11), 1363 -- the certificate has already been confirmed 1364 wrongIntegrity (12), 1365 -- invalid integrity, password based instead of signature or 1366 -- vice versa 1367 badRecipientNonce (13), 1368 -- invalid recipient nonce, either missing or wrong value 1369 timeNotAvailable (14), 1370 -- the TSA's time source is not available 1371 unacceptedPolicy (15), 1372 -- the requested TSA policy is not supported by the TSA. 1373 unacceptedExtension (16), 1374 -- the requested extension is not supported by the TSA. 1375 addInfoNotAvailable (17), 1376 -- the additional information requested could not be 1377 -- understood or is not available 1378 badSenderNonce (18), 1379 -- invalid sender nonce, either missing or wrong size 1380 badCertTemplate (19), 1381 -- invalid cert. template or missing mandatory information 1382 signerNotTrusted (20), 1383 -- signer of the message unknown or not trusted 1384 transactionIdInUse (21), 1385 -- the transaction identifier is already in use 1386 unsupportedVersion (22), 1387 -- the version of the message is not supported 1388 notAuthorized (23), 1389 -- the sender was not authorized to make the preceding 1390 -- request or perform the preceding action 1391 systemUnavail (24), 1392 -- the request cannot be handled due to system unavailability 1393 systemFailure (25), 1394 -- the request cannot be handled due to system failure 1395 duplicateCertReq (26) 1396 -- certificate cannot be issued because a duplicate 1397 -- certificate already exists 1398 } 1400 PKIStatusInfo ::= SEQUENCE { 1401 status PKIStatus, 1402 statusString PKIFreeText OPTIONAL, 1403 failInfo PKIFailureInfo OPTIONAL 1405 } 1407 OOBCert ::= CMPCertificate 1409 OOBCertHash ::= SEQUENCE { 1410 hashAlg [0] AlgorithmIdentifier OPTIONAL, 1411 certId [1] CertId OPTIONAL, 1412 hashVal BIT STRING 1413 -- hashVal is calculated over the DER encoding of the 1414 -- self-signed certificate with the identifier certID. 1415 } 1417 POPODecKeyChallContent ::= SEQUENCE OF Challenge 1418 -- One Challenge per encryption key certification request (in the 1419 -- same order as these requests appear in CertReqMessages). 1421 Challenge ::= SEQUENCE { 1422 owf AlgorithmIdentifier OPTIONAL, 1423 -- MUST be present in the first Challenge; MAY be omitted in 1424 -- any subsequent Challenge in POPODecKeyChallContent (if 1425 -- omitted, then the owf used in the immediately preceding 1426 -- Challenge is to be used). 1427 witness OCTET STRING, 1428 -- the result of applying the one-way function (owf) to a 1429 -- randomly-generated INTEGER, A. [Note that a different 1430 -- INTEGER MUST be used for each Challenge.] 1431 challenge OCTET STRING 1432 -- the encryption (under the public key for which the cert. 1433 -- request is being made) of Rand. 1434 } 1436 -- Added in CMP Updates [thisRFC] 1438 Rand ::= SEQUENCE { 1439 -- Rand is encrypted under the public key to form the challenge 1440 -- in POPODecKeyChallContent 1441 int INTEGER, 1442 -- the randomly-generated INTEGER A (above) 1443 sender GeneralName 1444 -- the sender's name (as included in PKIHeader) 1445 } 1447 POPODecKeyRespContent ::= SEQUENCE OF INTEGER 1448 -- One INTEGER per encryption key certification request (in the 1449 -- same order as these requests appear in CertReqMessages). The 1450 -- retrieved INTEGER A (above) is returned to the sender of the 1451 -- corresponding Challenge. 1453 CertRepMessage ::= SEQUENCE { 1454 caPubs [1] SEQUENCE SIZE (1..MAX) OF CMPCertificate 1455 OPTIONAL, 1456 response SEQUENCE OF CertResponse 1457 } 1459 CertResponse ::= SEQUENCE { 1460 certReqId INTEGER, 1461 -- to match this response with corresponding request (a value 1462 -- of 0 is to be used if certReqId is not specified in the 1463 -- corresponding request, which can only be a p10cr) 1464 status PKIStatusInfo, 1465 certifiedKeyPair CertifiedKeyPair OPTIONAL, 1466 rspInfo OCTET STRING OPTIONAL 1467 -- analogous to the id-regInfo-utf8Pairs string defined 1468 -- for regInfo in CertReqMsg [CRMF] 1469 } 1471 CertifiedKeyPair ::= SEQUENCE { 1472 certOrEncCert CertOrEncCert, 1473 privateKey [0] EncryptedKey OPTIONAL, 1474 -- see [CRMF] for comment on encoding 1475 -- Changed from Encrypted Value to EncryptedKey as a CHOICE of 1476 -- EncryptedValue and EnvelopedData due to the changes made in 1477 -- CMP Updates [thisRFC] 1478 -- Using the choice EncryptedValue is bit-compatible to the 1479 -- syntax without this change 1480 publicationInfo [1] PKIPublicationInfo OPTIONAL 1481 } 1483 CertOrEncCert ::= CHOICE { 1484 certificate [0] CMPCertificate, 1485 encryptedCert [1] EncryptedKey 1486 -- Changed from Encrypted Value to EncryptedKey as a CHOICE of 1487 -- EncryptedValue and EnvelopedData due to the changes made in 1488 -- CMP Updates [thisRFC] 1489 -- Using the choice EncryptedValue is bit-compatible to the 1490 -- syntax without this change 1491 } 1493 KeyRecRepContent ::= SEQUENCE { 1494 status PKIStatusInfo, 1495 newSigCert [0] CMPCertificate OPTIONAL, 1496 caCerts [1] SEQUENCE SIZE (1..MAX) OF 1497 CMPCertificate OPTIONAL, 1498 keyPairHist [2] SEQUENCE SIZE (1..MAX) OF 1499 CertifiedKeyPair OPTIONAL 1500 } 1501 RevReqContent ::= SEQUENCE OF RevDetails 1503 RevDetails ::= SEQUENCE { 1504 certDetails CertTemplate, 1505 -- allows requester to specify as much as they can about 1506 -- the cert. for which revocation is requested 1507 -- (e.g., for cases in which serialNumber is not available) 1508 crlEntryDetails Extensions OPTIONAL 1509 -- requested crlEntryExtensions 1510 } 1512 RevRepContent ::= SEQUENCE { 1513 status SEQUENCE SIZE (1..MAX) OF PKIStatusInfo, 1514 -- in same order as was sent in RevReqContent 1515 revCerts [0] SEQUENCE SIZE (1..MAX) OF CertId 1516 OPTIONAL, 1517 -- IDs for which revocation was requested 1518 -- (same order as status) 1519 crls [1] SEQUENCE SIZE (1..MAX) OF CertificateList 1520 OPTIONAL 1521 -- the resulting CRLs (there may be more than one) 1522 } 1524 CAKeyUpdAnnContent ::= SEQUENCE { 1525 oldWithNew CMPCertificate, -- old pub signed with new priv 1526 newWithOld CMPCertificate, -- new pub signed with old priv 1527 newWithNew CMPCertificate -- new pub signed with new priv 1528 } 1530 CertAnnContent ::= CMPCertificate 1532 RevAnnContent ::= SEQUENCE { 1533 status PKIStatus, 1534 certId CertId, 1535 willBeRevokedAt GeneralizedTime, 1536 badSinceDate GeneralizedTime, 1537 crlDetails Extensions OPTIONAL 1538 -- extra CRL details (e.g., crl number, reason, location, etc.) 1539 } 1541 CRLAnnContent ::= SEQUENCE OF CertificateList 1543 CertConfirmContent ::= SEQUENCE OF CertStatus 1545 CertStatus ::= SEQUENCE { 1546 certHash OCTET STRING, 1547 -- the hash of the certificate, using the same hash algorithm 1548 -- as is used to create and verify the certificate signature 1549 certReqId INTEGER, 1550 -- to match this confirmation with the corresponding req/rep 1551 statusInfo PKIStatusInfo OPTIONAL 1552 } 1554 PKIConfirmContent ::= NULL 1556 -- Added in CMP Updates [thisRFC] 1558 RootCaKeyUpdateContent ::= SEQUENCE { 1559 newWithNew CMPCertificate, 1560 -- new root CA certificate 1561 newWithOld [0] CMPCertificate OPTIONAL, 1562 -- X.509 certificate containing the new public root CA key 1563 -- signed with the old private root CA key 1564 oldWithNew [1] CMPCertificate OPTIONAL 1565 -- X.509 certificate containing the old public root CA key 1566 -- signed with the new private root CA key 1567 } 1569 -- Added in CMP Updates [thisRFC] 1571 CertReqTemplateContent ::= SEQUENCE { 1572 certTemplate CertTemplate, 1573 -- prefilled certTemplate structure elements 1574 -- The SubjectPublicKeyInfo field in the certTemplate MUST NOT 1575 -- be used. 1576 keySpec Controls OPTIONAL 1577 -- MAY be used to specify supported algorithms. 1578 -- Controls ::= SEQUENCE SIZE(1..MAX) OF AttributeTypeAndValue 1579 -- as specified in CRMF (RFC4211) 1580 } 1582 id-regCtrl-algId OBJECT IDENTIFIER ::= { id-regCtrl TBD3 } 1583 AlgIdCtrl ::= AlgorithmIdentifier 1584 -- SHALL be used to specify suported algorithms other than RSA 1586 id-regCtrl-rsaKeyLen OBJECT IDENTIFIER ::= { id-regCtrl TBD4 } 1587 RsaKeyLenCtrl ::= INTEGER 1588 -- SHALL be used to specify suported RSA key lengths 1590 InfoTypeAndValue ::= SEQUENCE { 1591 infoType OBJECT IDENTIFIER, 1592 infoValue ANY DEFINED BY infoType OPTIONAL 1593 } 1594 -- Example InfoTypeAndValue contents include, but are not limited 1595 -- to, the following (un-comment in this ASN.1 module and use as 1596 -- appropriate for a given environment): 1598 -- 1599 -- id-it-caProtEncCert OBJECT IDENTIFIER ::= {id-it 1} 1600 -- CAProtEncCertValue ::= CMPCertificate 1601 -- id-it-signKeyPairTypes OBJECT IDENTIFIER ::= {id-it 2} 1602 -- SignKeyPairTypesValue ::= SEQUENCE OF AlgorithmIdentifier 1603 -- id-it-encKeyPairTypes OBJECT IDENTIFIER ::= {id-it 3} 1604 -- EncKeyPairTypesValue ::= SEQUENCE OF AlgorithmIdentifier 1605 -- id-it-preferredSymmAlg OBJECT IDENTIFIER ::= {id-it 4} 1606 -- PreferredSymmAlgValue ::= AlgorithmIdentifier 1607 -- id-it-caKeyUpdateInfo OBJECT IDENTIFIER ::= {id-it 5} 1608 -- CAKeyUpdateInfoValue ::= CAKeyUpdAnnContent 1609 -- id-it-currentCRL OBJECT IDENTIFIER ::= {id-it 6} 1610 -- CurrentCRLValue ::= CertificateList 1611 -- id-it-unsupportedOIDs OBJECT IDENTIFIER ::= {id-it 7} 1612 -- UnsupportedOIDsValue ::= SEQUENCE OF OBJECT IDENTIFIER 1613 -- id-it-keyPairParamReq OBJECT IDENTIFIER ::= {id-it 10} 1614 -- KeyPairParamReqValue ::= OBJECT IDENTIFIER 1615 -- id-it-keyPairParamRep OBJECT IDENTIFIER ::= {id-it 11} 1616 -- KeyPairParamRepValue ::= AlgorithmIdentifer 1617 -- id-it-revPassphrase OBJECT IDENTIFIER ::= {id-it 12} 1618 -- RevPassphraseValue ::= EncryptedKey 1619 -- - Changed from Encrypted Value to EncryptedKey as a CHOICE 1620 -- - of EncryptedValue and EnvelopedData due to the changes 1621 -- - made in CMP Updates [thisRFC] 1622 -- - Using the choice EncryptedValue is bit-compatible to the 1623 -- - syntax without this change 1624 -- id-it-implicitConfirm OBJECT IDENTIFIER ::= {id-it 13} 1625 -- ImplicitConfirmValue ::= NULL 1626 -- id-it-confirmWaitTime OBJECT IDENTIFIER ::= {id-it 14} 1627 -- ConfirmWaitTimeValue ::= GeneralizedTime 1628 -- id-it-origPKIMessage OBJECT IDENTIFIER ::= {id-it 15} 1629 -- OrigPKIMessageValue ::= PKIMessages 1630 -- id-it-suppLangTags OBJECT IDENTIFIER ::= {id-it 16} 1631 -- SuppLangTagsValue ::= SEQUENCE OF UTF8String 1632 -- id-it-caCerts OBJECT IDENTIFIER ::= { id-it 17} 1633 -- CaCertsValue ::= SEQUENCE OF CMPCertificate 1634 -- - id-it-caCerts added in CMP Updates [thisRFC] 1635 -- id-it-rootCaKeyUpdate OBJECT IDENTIFIER ::= { id-it 18} 1636 -- RootCaKeyUpdateValue ::= RootCaKeyUpdateContent 1637 -- - id-it-rootCaKeyUpdate added in CMP Updates [thisRFC] 1638 -- id-it-certReqTemplate OBJECT IDENTIFIER ::= { id-it 19} 1639 -- CertReqTemplateValue ::= CertReqTemplateContent 1640 -- - id-it-certReqTemplate added in CMP Updates [thisRFC] 1641 -- id-it-rootCaCert OBJECT IDENTIFIER ::= {id-it TBD5} 1642 -- RootCaCertValue ::= CMPCertificate 1643 -- - id-it-rootCaCert added in CMP Updates [thisRFC] 1644 -- id-it-certProfile OBJECT IDENTIFIER ::= {id-it TBD6} 1645 -- CertProfileValue ::= UTF8String 1646 -- - id-it-certProfile added in CMP Updates [thisRFC] 1647 -- 1648 -- where 1649 -- 1650 -- id-pkix OBJECT IDENTIFIER ::= { 1651 -- iso(1) identified-organization(3) 1652 -- dod(6) internet(1) security(5) mechanisms(5) pkix(7)} 1653 -- and 1654 -- id-it OBJECT IDENTIFIER ::= {id-pkix 4} 1655 -- 1656 -- 1657 -- This construct MAY also be used to define new PKIX Certificate 1658 -- Management Protocol request and response messages, or general- 1659 -- purpose (e.g., announcement) messages for future needs or for 1660 -- specific environments. 1662 GenMsgContent ::= SEQUENCE OF InfoTypeAndValue 1664 -- May be sent by EE, RA, or CA (depending on message content). 1665 -- The OPTIONAL infoValue parameter of InfoTypeAndValue will 1666 -- typically be omitted for some of the examples given above. 1667 -- The receiver is free to ignore any contained OBJ. IDs that it 1668 -- does not recognize. If sent from EE to CA, the empty set 1669 -- indicates that the CA may send 1670 -- any/all information that it wishes. 1672 GenRepContent ::= SEQUENCE OF InfoTypeAndValue 1673 -- Receiver MAY ignore any contained OIDs that it does not 1674 -- recognize. 1676 ErrorMsgContent ::= SEQUENCE { 1677 pKIStatusInfo PKIStatusInfo, 1678 errorCode INTEGER OPTIONAL, 1679 -- implementation-specific error codes 1680 errorDetails PKIFreeText OPTIONAL 1681 -- implementation-specific error details 1682 } 1684 PollReqContent ::= SEQUENCE OF SEQUENCE { 1685 certReqId INTEGER 1686 } 1688 PollRepContent ::= SEQUENCE OF SEQUENCE { 1689 certReqId INTEGER, 1690 checkAfter INTEGER, -- time in seconds 1691 reason PKIFreeText OPTIONAL 1692 } 1693 -- 1694 -- Extended Key Usage extension for PKI entities used in CMP 1695 -- operations, added due to the changes made in 1696 -- CMP Updates [thisRFC] 1697 -- The EKUs for the CA and RA are reused from CMC as defined in 1698 -- [RFC6402] 1699 -- 1701 -- id-kp-cmcCA OBJECT IDENTIFIER ::= { id-kp 27 } 1702 -- id-kp-cmcRA OBJECT IDENTIFIER ::= { id-kp 28 } 1703 id-kp-cmKGA OBJECT IDENTIFIER ::= { id-kp 32 } 1705 -- There is no 1988 ASN.1 module of PKCS#9 available to import the 1706 -- syntax of the localKeyId attribute type and value from. Therefore, 1707 -- the syntax is added here as needed for the updates made in 1708 -- CMP Updates [thisRFC] 1710 pkcs-9 OBJECT IDENTIFIER ::= {iso(1) member-body(2) us(840) 1711 rsadsi(113549) pkcs(1) 9} 1713 pkcs-9-at-localKeyId OBJECT IDENTIFIER ::= {pkcs-9 21} 1715 localKeyIdValue ::= OCTET STRING 1717 END -- of CMP module 1719 A.2. 2002 ASN.1 Module 1721 This section contains the updated 2002 ASN.1 module for [RFC5912]. 1722 This module replaces the module in Section 9 of that document. The 1723 module contains those changes to the normative ASN.1 module from 1724 RFC4210 Appendix F [RFC4210] that were to update to 2002 ASN.1 1725 standard done in [RFC5912] as well as changes made in this document. 1727 PKIXCMP-2021 1728 { iso(1) identified-organization(3) dod(6) internet(1) 1729 security(5) mechanisms(5) pkix(7) id-mod(0) 1730 id-mod-cmp2021-02(TBD2) } 1731 DEFINITIONS EXPLICIT TAGS ::= 1732 BEGIN 1733 IMPORTS 1735 AttributeSet{}, Extensions{}, EXTENSION, ATTRIBUTE 1736 FROM PKIX-CommonTypes-2009 1737 {iso(1) identified-organization(3) dod(6) internet(1) security(5) 1738 mechanisms(5) pkix(7) id-mod(0) id-mod-pkixCommon-02(57)} 1740 AlgorithmIdentifier{}, SIGNATURE-ALGORITHM, ALGORITHM, 1741 DIGEST-ALGORITHM, MAC-ALGORITHM 1742 FROM AlgorithmInformation-2009 1743 {iso(1) identified-organization(3) dod(6) internet(1) security(5) 1744 mechanisms(5) pkix(7) id-mod(0) 1745 id-mod-algorithmInformation-02(58)} 1747 Certificate, CertificateList, id-kp 1748 FROM PKIX1Explicit-2009 1749 {iso(1) identified-organization(3) dod(6) internet(1) security(5) 1750 mechanisms(5) pkix(7) id-mod(0) id-mod-pkix1-explicit-02(51)} 1752 GeneralName, KeyIdentifier 1753 FROM PKIX1Implicit-2009 1754 {iso(1) identified-organization(3) dod(6) internet(1) security(5) 1755 mechanisms(5) pkix(7) id-mod(0) id-mod-pkix1-implicit-02(59)} 1757 CertTemplate, PKIPublicationInfo, EncryptedKey, CertId, 1758 CertReqMessages, Controls, id-regCtrl 1759 FROM PKIXCRMF-2009 1760 { iso(1) identified-organization(3) dod(6) internet(1) 1761 security(5) mechanisms(5) pkix(7) id-mod(0) 1762 id-mod-crmf2005-02(55) } 1763 -- The import of EncryptedKey is added due to the updates made 1764 -- in CMP Updates [thisRFC]. EncryptedValue does not need to 1765 -- be imported anymore and is therefore removed here. 1767 -- see also the behavioral clarifications to CRMF codified in 1768 -- Appendix C of this specification 1770 CertificationRequest 1771 FROM PKCS-10 1772 {iso(1) identified-organization(3) dod(6) internet(1) security(5) 1773 mechanisms(5) pkix(7) id-mod(0) id-mod-pkcs10-2009(69)} 1774 -- (specified in RFC 2986 with 1993 ASN.1 syntax and IMPLICIT 1775 -- tags). Alternatively, implementers may directly include 1776 -- the [PKCS10] syntax in this module 1778 localKeyId 1779 FROM PKCS-9 1780 {iso(1) member-body(2) us(840) rsadsi(113549) pkcs(1) pkcs-9(9) 1781 modules(0) pkcs-9(1)} 1782 -- The import of localKeyId is added due to the updates made in 1783 -- CMP Updates [thisRFC] 1785 EnvelopedData, SignedData 1786 FROM CryptographicMessageSyntax-2009 1787 {iso(1) member-body(2) us(840) rsadsi(113549) pkcs(1) pkcs-9(9) 1788 smime(16) modules(0) id-mod-cms-2004-02(41)} 1789 -- The import of EnvelopedData and SignedData is added due to 1790 -- the updates made in CMP Updates [thisRFC] 1791 ; 1793 -- the rest of the module contains locally defined OIDs and 1794 -- constructs 1796 CMPCertificate ::= CHOICE { x509v3PKCert Certificate, ... } 1797 -- This syntax, while bits-on-the-wire compatible with the 1798 -- standard X.509 definition of "Certificate", allows the 1799 -- possibility of future certificate types (such as X.509 1800 -- attribute certificates, WAP WTLS certificates, or other kinds 1801 -- of certificates) within this certificate management protocol, 1802 -- should a need ever arise to support such generality. Those 1803 -- implementations that do not foresee a need to ever support 1804 -- other certificate types MAY, if they wish, comment out the 1805 -- above structure and "uncomment" the following one prior to 1806 -- compiling this ASN.1 module. (Note that interoperability 1807 -- with implementations that don't do this will be unaffected by 1808 -- this change.) 1810 -- CMPCertificate ::= Certificate 1812 PKIMessage ::= SEQUENCE { 1813 header PKIHeader, 1814 body PKIBody, 1815 protection [0] PKIProtection OPTIONAL, 1816 extraCerts [1] SEQUENCE SIZE (1..MAX) OF CMPCertificate 1817 OPTIONAL } 1819 PKIMessages ::= SEQUENCE SIZE (1..MAX) OF PKIMessage 1821 PKIHeader ::= SEQUENCE { 1822 pvno INTEGER { cmp1999(1), cmp2000(2), 1823 cmp2012(3) }, 1824 sender GeneralName, 1825 -- identifies the sender 1826 recipient GeneralName, 1827 -- identifies the intended recipient 1828 messageTime [0] GeneralizedTime OPTIONAL, 1829 -- time of production of this message (used when sender 1830 -- believes that the transport will be "suitable"; i.e., 1831 -- that the time will still be meaningful upon receipt) 1832 protectionAlg [1] AlgorithmIdentifier{ALGORITHM, {...}} 1833 OPTIONAL, 1834 -- algorithm used for calculation of protection bits 1835 senderKID [2] KeyIdentifier OPTIONAL, 1836 recipKID [3] KeyIdentifier OPTIONAL, 1837 -- to identify specific keys used for protection 1838 transactionID [4] OCTET STRING OPTIONAL, 1839 -- identifies the transaction; i.e., this will be the same in 1840 -- corresponding request, response, certConf, and PKIConf 1841 -- messages 1842 senderNonce [5] OCTET STRING OPTIONAL, 1843 recipNonce [6] OCTET STRING OPTIONAL, 1844 -- nonces used to provide replay protection, senderNonce 1845 -- is inserted by the creator of this message; recipNonce 1846 -- is a nonce previously inserted in a related message by 1847 -- the intended recipient of this message 1848 freeText [7] PKIFreeText OPTIONAL, 1849 -- this may be used to indicate context-specific instructions 1850 -- (this field is intended for human consumption) 1851 generalInfo [8] SEQUENCE SIZE (1..MAX) OF 1852 InfoTypeAndValue OPTIONAL 1853 -- this may be used to convey context-specific information 1854 -- (this field not primarily intended for human consumption) 1855 } 1857 PKIFreeText ::= SEQUENCE SIZE (1..MAX) OF UTF8String 1858 -- text encoded as UTF-8 String [RFC3629] (note: each 1859 -- UTF8String MAY include an [RFC3066] language tag 1860 -- to indicate the language of the contained text; 1861 -- see [RFC2482] for details) 1863 PKIBody ::= CHOICE { -- message-specific body elements 1864 ir [0] CertReqMessages, --Initialization Request 1865 ip [1] CertRepMessage, --Initialization Response 1866 cr [2] CertReqMessages, --Certification Request 1867 cp [3] CertRepMessage, --Certification Response 1868 p10cr [4] CertificationRequest, --imported from [PKCS10] 1869 popdecc [5] POPODecKeyChallContent, --pop Challenge 1870 popdecr [6] POPODecKeyRespContent, --pop Response 1871 kur [7] CertReqMessages, --Key Update Request 1872 kup [8] CertRepMessage, --Key Update Response 1873 krr [9] CertReqMessages, --Key Recovery Request 1874 krp [10] KeyRecRepContent, --Key Recovery Response 1875 rr [11] RevReqContent, --Revocation Request 1876 rp [12] RevRepContent, --Revocation Response 1877 ccr [13] CertReqMessages, --Cross-Cert. Request 1878 ccp [14] CertRepMessage, --Cross-Cert. Response 1879 ckuann [15] CAKeyUpdAnnContent, --CA Key Update Ann. 1880 cann [16] CertAnnContent, --Certificate Ann. 1881 rann [17] RevAnnContent, --Revocation Ann. 1882 crlann [18] CRLAnnContent, --CRL Announcement 1883 pkiconf [19] PKIConfirmContent, --Confirmation 1884 nested [20] NestedMessageContent, --Nested Message 1885 genm [21] GenMsgContent, --General Message 1886 genp [22] GenRepContent, --General Response 1887 error [23] ErrorMsgContent, --Error Message 1888 certConf [24] CertConfirmContent, --Certificate confirm 1889 pollReq [25] PollReqContent, --Polling request 1890 pollRep [26] PollRepContent --Polling response 1891 } 1893 PKIProtection ::= BIT STRING 1895 ProtectedPart ::= SEQUENCE { 1896 header PKIHeader, 1897 body PKIBody } 1899 id-PasswordBasedMac OBJECT IDENTIFIER ::= { iso(1) member-body(2) 1900 usa(840) nt(113533) nsn(7) algorithms(66) 13 } 1901 PBMParameter ::= SEQUENCE { 1902 salt OCTET STRING, 1903 -- note: implementations MAY wish to limit acceptable sizes 1904 -- of this string to values appropriate for their environment 1905 -- in order to reduce the risk of denial-of-service attacks 1906 owf AlgorithmIdentifier{DIGEST-ALGORITHM, {...}}, 1907 -- AlgId for a One-Way Function (SHA-1 recommended) 1908 iterationCount INTEGER, 1909 -- number of times the OWF is applied 1910 -- note: implementations MAY wish to limit acceptable sizes 1911 -- of this integer to values appropriate for their environment 1912 -- in order to reduce the risk of denial-of-service attacks 1913 mac AlgorithmIdentifier{MAC-ALGORITHM, {...}} 1914 -- the MAC AlgId (e.g., DES-MAC, Triple-DES-MAC [PKCS11], 1915 -- or HMAC [RFC2104, RFC2202]) 1916 } 1918 id-DHBasedMac OBJECT IDENTIFIER ::= { iso(1) member-body(2) 1919 usa(840) nt(113533) nsn(7) algorithms(66) 30 } 1920 DHBMParameter ::= SEQUENCE { 1921 owf AlgorithmIdentifier{DIGEST-ALGORITHM, {...}}, 1922 -- AlgId for a One-Way Function (SHA-1 recommended) 1923 mac AlgorithmIdentifier{MAC-ALGORITHM, {...}} 1924 -- the MAC AlgId (e.g., DES-MAC, Triple-DES-MAC [PKCS11], 1925 -- or HMAC [RFC2104, RFC2202]) 1926 } 1928 PKIStatus ::= INTEGER { 1929 accepted (0), 1930 -- you got exactly what you asked for 1931 grantedWithMods (1), 1932 -- you got something like what you asked for; the 1933 -- requester is responsible for ascertaining the differences 1934 rejection (2), 1935 -- you don't get it, more information elsewhere in the message 1936 waiting (3), 1937 -- the request body part has not yet been processed; expect to 1938 -- hear more later (note: proper handling of this status 1939 -- response MAY use the polling req/rep PKIMessages specified 1940 -- in Section 5.3.22; alternatively, polling in the underlying 1941 -- transport layer MAY have some utility in this regard) 1942 revocationWarning (4), 1943 -- this message contains a warning that a revocation is 1944 -- imminent 1945 revocationNotification (5), 1946 -- notification that a revocation has occurred 1947 keyUpdateWarning (6) 1948 -- update already done for the oldCertId specified in 1949 -- CertReqMsg 1950 } 1952 PKIFailureInfo ::= BIT STRING { 1953 -- since we can fail in more than one way! 1954 -- More codes may be added in the future if/when required. 1955 badAlg (0), 1956 -- unrecognized or unsupported Algorithm Identifier 1957 badMessageCheck (1), 1958 -- integrity check failed (e.g., signature did not verify) 1959 badRequest (2), 1960 -- transaction not permitted or supported 1961 badTime (3), 1962 -- messageTime was not sufficiently close to the system time, 1963 -- as defined by local policy 1964 badCertId (4), 1965 -- no certificate could be found matching the provided criteria 1966 badDataFormat (5), 1967 -- the data submitted has the wrong format 1968 wrongAuthority (6), 1969 -- the authority indicated in the request is different from the 1970 -- one creating the response token 1971 incorrectData (7), 1972 -- the requester's data is incorrect (for notary services) 1973 missingTimeStamp (8), 1974 -- when the timestamp is missing but should be there 1975 -- (by policy) 1976 badPOP (9), 1977 -- the proof-of-possession failed 1978 certRevoked (10), 1979 -- the certificate has already been revoked 1980 certConfirmed (11), 1981 -- the certificate has already been confirmed 1982 wrongIntegrity (12), 1983 -- invalid integrity, password based instead of signature or 1984 -- vice versa 1985 badRecipientNonce (13), 1986 -- invalid recipient nonce, either missing or wrong value 1987 timeNotAvailable (14), 1988 -- the TSA's time source is not available 1989 unacceptedPolicy (15), 1990 -- the requested TSA policy is not supported by the TSA 1991 unacceptedExtension (16), 1992 -- the requested extension is not supported by the TSA 1993 addInfoNotAvailable (17), 1994 -- the additional information requested could not be 1995 -- understood or is not available 1996 badSenderNonce (18), 1997 -- invalid sender nonce, either missing or wrong size 1998 badCertTemplate (19), 1999 -- invalid cert. template or missing mandatory information 2000 signerNotTrusted (20), 2001 -- signer of the message unknown or not trusted 2002 transactionIdInUse (21), 2003 -- the transaction identifier is already in use 2004 unsupportedVersion (22), 2005 -- the version of the message is not supported 2006 notAuthorized (23), 2007 -- the sender was not authorized to make the preceding 2008 -- request or perform the preceding action 2009 systemUnavail (24), 2010 -- the request cannot be handled due to system unavailability 2011 systemFailure (25), 2012 -- the request cannot be handled due to system failure 2013 duplicateCertReq (26) 2014 -- certificate cannot be issued because a duplicate 2015 -- certificate already exists 2016 } 2018 PKIStatusInfo ::= SEQUENCE { 2019 status PKIStatus, 2020 statusString PKIFreeText OPTIONAL, 2021 failInfo PKIFailureInfo OPTIONAL } 2023 OOBCert ::= CMPCertificate 2025 OOBCertHash ::= SEQUENCE { 2026 hashAlg [0] AlgorithmIdentifier{DIGEST-ALGORITHM, {...}} 2027 OPTIONAL, 2028 certId [1] CertId OPTIONAL, 2029 hashVal BIT STRING 2030 -- hashVal is calculated over the DER encoding of the 2031 -- self-signed certificate with the identifier certID. 2032 } 2034 POPODecKeyChallContent ::= SEQUENCE OF Challenge 2035 -- One Challenge per encryption key certification request (in the 2036 -- same order as these requests appear in CertReqMessages). 2038 Challenge ::= SEQUENCE { 2039 owf AlgorithmIdentifier{DIGEST-ALGORITHM, {...}} 2040 OPTIONAL, 2041 -- MUST be present in the first Challenge; MAY be omitted in 2042 -- any subsequent Challenge in POPODecKeyChallContent (if 2043 -- omitted, then the owf used in the immediately preceding 2044 -- Challenge is to be used). 2045 witness OCTET STRING, 2046 -- the result of applying the one-way function (owf) to a 2047 -- randomly-generated INTEGER, A. [Note that a different 2048 -- INTEGER MUST be used for each Challenge.] 2049 challenge OCTET STRING 2050 -- the encryption (under the public key for which the cert. 2051 -- request is being made) of Rand. 2052 } 2054 -- Added in CMP Updates [thisRFC] 2056 Rand ::= SEQUENCE { 2057 -- Rand is encrypted under the public key to form the challenge 2058 -- in POPODecKeyChallContent 2059 int INTEGER, 2060 -- the randomly-generated INTEGER A (above) 2061 sender GeneralName 2062 -- the sender's name (as included in PKIHeader) 2063 } 2065 POPODecKeyRespContent ::= SEQUENCE OF INTEGER 2066 -- One INTEGER per encryption key certification request (in the 2067 -- same order as these requests appear in CertReqMessages). The 2068 -- retrieved INTEGER A (above) is returned to the sender of the 2069 -- corresponding Challenge. 2071 CertRepMessage ::= SEQUENCE { 2072 caPubs [1] SEQUENCE SIZE (1..MAX) OF CMPCertificate 2073 OPTIONAL, 2074 response SEQUENCE OF CertResponse } 2076 CertResponse ::= SEQUENCE { 2077 certReqId INTEGER, 2078 -- to match this response with the corresponding request (a value 2079 -- of 0 is to be used if certReqId is not specified in the 2080 -- corresponding request, which can only be a p10cr) 2081 status PKIStatusInfo, 2082 certifiedKeyPair CertifiedKeyPair OPTIONAL, 2083 rspInfo OCTET STRING OPTIONAL 2084 -- analogous to the id-regInfo-utf8Pairs string defined 2085 -- for regInfo in CertReqMsg [RFC4211] 2086 } 2088 CertifiedKeyPair ::= SEQUENCE { 2089 certOrEncCert CertOrEncCert, 2090 privateKey [0] EncryptedKey OPTIONAL, 2091 -- see [RFC4211] for comment on encoding 2092 -- Changed from Encrypted Value to EncryptedKey as a CHOICE of 2093 -- EncryptedValue and EnvelopedData due to the changes made in 2094 -- CMP Updates [thisRFC] 2095 -- Using the choice EncryptedValue is bit-compatible to the 2096 -- syntax without this change 2097 publicationInfo [1] PKIPublicationInfo OPTIONAL } 2099 CertOrEncCert ::= CHOICE { 2100 certificate [0] CMPCertificate, 2101 encryptedCert [1] EncryptedKey 2102 -- Changed from Encrypted Value to EncryptedKey as a CHOICE of 2103 -- EncryptedValue and EnvelopedData due to the changes made in 2104 -- CMP Updates [thisRFC] 2105 -- Using the choice EncryptedValue is bit-compatible to the 2106 -- syntax without this change 2107 } 2109 KeyRecRepContent ::= SEQUENCE { 2110 status PKIStatusInfo, 2111 newSigCert [0] CMPCertificate OPTIONAL, 2112 caCerts [1] SEQUENCE SIZE (1..MAX) OF 2113 CMPCertificate OPTIONAL, 2114 keyPairHist [2] SEQUENCE SIZE (1..MAX) OF 2115 CertifiedKeyPair OPTIONAL } 2117 RevReqContent ::= SEQUENCE OF RevDetails 2119 RevDetails ::= SEQUENCE { 2120 certDetails CertTemplate, 2121 -- allows requester to specify as much as they can about 2122 -- the cert. for which revocation is requested 2123 -- (e.g., for cases in which serialNumber is not available) 2124 crlEntryDetails Extensions{{...}} OPTIONAL 2125 -- requested crlEntryExtensions 2126 } 2128 RevRepContent ::= SEQUENCE { 2129 status SEQUENCE SIZE (1..MAX) OF PKIStatusInfo, 2130 -- in same order as was sent in RevReqContent 2131 revCerts [0] SEQUENCE SIZE (1..MAX) OF CertId OPTIONAL, 2132 -- IDs for which revocation was requested 2133 -- (same order as status) 2134 crls [1] SEQUENCE SIZE (1..MAX) OF CertificateList OPTIONAL 2135 -- the resulting CRLs (there may be more than one) 2136 } 2138 CAKeyUpdAnnContent ::= SEQUENCE { 2139 oldWithNew CMPCertificate, -- old pub signed with new priv 2140 newWithOld CMPCertificate, -- new pub signed with old priv 2141 newWithNew CMPCertificate -- new pub signed with new priv 2142 } 2144 CertAnnContent ::= CMPCertificate 2146 RevAnnContent ::= SEQUENCE { 2147 status PKIStatus, 2148 certId CertId, 2149 willBeRevokedAt GeneralizedTime, 2150 badSinceDate GeneralizedTime, 2151 crlDetails Extensions{{...}} OPTIONAL 2152 -- extra CRL details (e.g., crl number, reason, location, etc.) 2153 } 2155 CRLAnnContent ::= SEQUENCE OF CertificateList 2156 PKIConfirmContent ::= NULL 2158 NestedMessageContent ::= PKIMessages 2160 -- Added in CMP Updates [thisRFC] 2162 RootCaKeyUpdateContent ::= SEQUENCE { 2163 newWithNew CMPCertificate, 2164 -- new root CA certificate 2165 newWithOld [0] CMPCertificate OPTIONAL, 2166 -- X.509 certificate containing the new public root CA key 2167 -- signed with the old private root CA key 2168 oldWithNew [1] CMPCertificate OPTIONAL 2169 -- X.509 certificate containing the old public root CA key 2170 -- signed with the new private root CA key 2171 } 2173 -- Added in CMP Updates [thisRFC] 2175 CertReqTemplateContent ::= SEQUENCE { 2176 certTemplate CertTemplate, 2177 -- prefilled certTemplate structure elements 2178 -- The SubjectPublicKeyInfo field in the certTemplate MUST NOT 2179 -- be used. 2180 keySpec Controls OPTIONAL 2181 -- MAY be used to specify supported algorithms. 2182 -- Controls ::= SEQUENCE SIZE(1..MAX) OF AttributeTypeAndValue 2183 -- as specified in CRMF (RFC4211) 2184 } 2186 id-regCtrl-algId OBJECT IDENTIFIER ::= { id-regCtrl TBD3 } 2187 AlgIdCtrl ::= AlgorithmIdentifier{ALGORITHM, {...}} 2188 -- SHALL be used to specify suported algorithms other than RSA 2190 id-regCtrl-rsaKeyLen OBJECT IDENTIFIER ::= { id-regCtrl TBD4 } 2191 RsaKeyLenCtrl ::= INTEGER 2192 -- SHALL be used to specify suported RSA key lengths 2194 INFO-TYPE-AND-VALUE ::= TYPE-IDENTIFIER 2196 InfoTypeAndValue ::= SEQUENCE { 2197 infoType INFO-TYPE-AND-VALUE. 2198 &id({SupportedInfoSet}), 2199 infoValue INFO-TYPE-AND-VALUE. 2200 &Type({SupportedInfoSet}{@infoType}) } 2202 SupportedInfoSet INFO-TYPE-AND-VALUE ::= { ... } 2204 -- Example InfoTypeAndValue contents include, but are not limited 2205 -- to, the following (uncomment in this ASN.1 module and use as 2206 -- appropriate for a given environment): 2207 -- 2208 -- id-it-caProtEncCert OBJECT IDENTIFIER ::= {id-it 1} 2209 -- CAProtEncCertValue ::= CMPCertificate 2210 -- id-it-signKeyPairTypes OBJECT IDENTIFIER ::= {id-it 2} 2211 -- SignKeyPairTypesValue ::= SEQUENCE OF 2212 -- AlgorithmIdentifier{{...}} 2213 -- id-it-encKeyPairTypes OBJECT IDENTIFIER ::= {id-it 3} 2214 -- EncKeyPairTypesValue ::= SEQUENCE OF 2215 -- AlgorithmIdentifier{{...}} 2216 -- id-it-preferredSymmAlg OBJECT IDENTIFIER ::= {id-it 4} 2217 -- PreferredSymmAlgValue ::= AlgorithmIdentifier{{...}} 2218 -- id-it-caKeyUpdateInfo OBJECT IDENTIFIER ::= {id-it 5} 2219 -- CAKeyUpdateInfoValue ::= CAKeyUpdAnnContent 2220 -- id-it-currentCRL OBJECT IDENTIFIER ::= {id-it 6} 2221 -- CurrentCRLValue ::= CertificateList 2222 -- id-it-unsupportedOIDs OBJECT IDENTIFIER ::= {id-it 7} 2223 -- UnsupportedOIDsValue ::= SEQUENCE OF OBJECT IDENTIFIER 2224 -- id-it-keyPairParamReq OBJECT IDENTIFIER ::= {id-it 10} 2225 -- KeyPairParamReqValue ::= OBJECT IDENTIFIER 2226 -- id-it-keyPairParamRep OBJECT IDENTIFIER ::= {id-it 11} 2227 -- KeyPairParamRepValue ::= AlgorithmIdentifer 2228 -- id-it-revPassphrase OBJECT IDENTIFIER ::= {id-it 12} 2229 -- RevPassphraseValue ::= EncryptedKey 2230 -- - Changed from Encrypted Value to EncryptedKey as a CHOICE 2231 -- - of EncryptedValue and EnvelopedData due to the changes 2232 -- - made in CMP Updates [thisRFC] 2233 -- - Using the choice EncryptedValue is bit-compatible to 2234 -- - the syntax without this change 2235 -- id-it-implicitConfirm OBJECT IDENTIFIER ::= {id-it 13} 2236 -- ImplicitConfirmValue ::= NULL 2237 -- id-it-confirmWaitTime OBJECT IDENTIFIER ::= {id-it 14} 2238 -- ConfirmWaitTimeValue ::= GeneralizedTime 2239 -- id-it-origPKIMessage OBJECT IDENTIFIER ::= {id-it 15} 2240 -- OrigPKIMessageValue ::= PKIMessages 2241 -- id-it-suppLangTags OBJECT IDENTIFIER ::= {id-it 16} 2242 -- SuppLangTagsValue ::= SEQUENCE OF UTF8String 2243 -- id-it-caCerts OBJECT IDENTIFIER ::= { id-it 17} 2244 -- CaCertsValue ::= SEQUENCE OF CMPCertificate 2245 -- - id-it-caCerts added in CMP Updates [thisRFC] 2246 -- id-it-rootCaKeyUpdate OBJECT IDENTIFIER ::= { id-it 18} 2247 -- RootCaKeyUpdateValue ::= RootCaKeyUpdateContent 2248 -- - id-it-rootCaKeyUpdate added in CMP Updates [thisRFC] 2249 -- id-it-certReqTemplate OBJECT IDENTIFIER ::= { id-it 19} 2250 -- CertReqTemplateValue ::= CertReqTemplateContent 2251 -- - id-it-certReqTemplate added in CMP Updates [thisRFC] 2252 -- id-it-rootCaCert OBJECT IDENTIFIER ::= {id-it TBD5} 2253 -- RootCaCertValue ::= CMPCertificate 2254 -- - id-it-rootCaCert added in CMP Updates [thisRFC] 2255 -- id-it-certProfile OBJECT IDENTIFIER ::= {id-it TBD6} 2256 -- CertProfileValue ::= UTF8String 2257 -- - id-it-certProfile added in CMP Updates [thisRFC] 2258 -- 2259 -- where 2260 -- 2261 -- id-pkix OBJECT IDENTIFIER ::= { 2262 -- iso(1) identified-organization(3) 2263 -- dod(6) internet(1) security(5) mechanisms(5) pkix(7)} 2264 -- and 2265 -- id-it OBJECT IDENTIFIER ::= {id-pkix 4} 2266 -- 2267 -- 2268 -- This construct MAY also be used to define new PKIX Certificate 2269 -- Management Protocol request and response messages, or general- 2270 -- purpose (e.g., announcement) messages for future needs or for 2271 -- specific environments. 2273 GenMsgContent ::= SEQUENCE OF InfoTypeAndValue 2275 -- May be sent by EE, RA, or CA (depending on message content). 2276 -- The OPTIONAL infoValue parameter of InfoTypeAndValue will 2277 -- typically be omitted for some of the examples given above. 2278 -- The receiver is free to ignore any contained OBJECT IDs that it 2279 -- does not recognize. If sent from EE to CA, the empty set 2280 -- indicates that the CA may send 2281 -- any/all information that it wishes. 2283 GenRepContent ::= SEQUENCE OF InfoTypeAndValue 2284 -- Receiver MAY ignore any contained OIDs that it does not 2285 -- recognize. 2287 ErrorMsgContent ::= SEQUENCE { 2288 pKIStatusInfo PKIStatusInfo, 2289 errorCode INTEGER OPTIONAL, 2290 -- implementation-specific error codes 2291 errorDetails PKIFreeText OPTIONAL 2292 -- implementation-specific error details 2293 } 2295 CertConfirmContent ::= SEQUENCE OF CertStatus 2297 CertStatus ::= SEQUENCE { 2298 certHash OCTET STRING, 2299 -- the hash of the certificate, using the same hash algorithm 2300 -- as is used to create and verify the certificate signature 2301 certReqId INTEGER, 2302 -- to match this confirmation with the corresponding req/rep 2303 statusInfo PKIStatusInfo OPTIONAL } 2305 PollReqContent ::= SEQUENCE OF SEQUENCE { 2306 certReqId INTEGER } 2308 PollRepContent ::= SEQUENCE OF SEQUENCE { 2309 certReqId INTEGER, 2310 checkAfter INTEGER, -- time in seconds 2311 reason PKIFreeText OPTIONAL } 2313 -- 2314 -- Extended Key Usage extension for PKI entities used in CMP 2315 -- operations, added due to the changes made in 2316 -- CMP Updates [thisRFC] 2317 -- The EKUs for the CA and RA are reused from CMC as defined in 2318 -- [RFC6402] 2319 -- 2321 -- id-kp-cmcCA OBJECT IDENTIFIER ::= { id-kp 27 } 2322 -- id-kp-cmcRA OBJECT IDENTIFIER ::= { id-kp 28 } 2323 id-kp-cmKGA OBJECT IDENTIFIER ::= { id-kp 32 } 2325 END 2327 Appendix B. History of changes 2329 Note: This appendix will be deleted in the final version of the 2330 document. 2332 From version 9 -> 10: 2334 * Added 1988 ASN.1 syntax for localKeyId attribute to Appendix A.1 2336 From version 08 -> 09: 2338 * Deleted specific definition of CMP CA and CMP RA in Section 2.2 2339 and only reference RFC 6402 for definition of id-kp-cmcCA and id- 2340 kp-cmcRA to resolve the ToDo below based on feedback of Tomas 2341 Gustavesson 2342 * Added Section 2.4. and 2.5 to define id-it-rootCaCert and id-it- 2343 certProfile to be used in Section 2.14 and 2.15 2344 * Added reference to CMP Algorithms in Section 2.8 2345 * Extended Section 2.14 to explicitly indicate the root CA an update 2346 is requested for by using id-it-rootCaCert and changing the ASN.1 2347 syntax to require providing the newWithOld certificate in the 2348 response message 2349 * Extended Section 2.15 to explicitly indicate the certificate 2350 request template by using id-it-certProfile and on further details 2351 of the newly introduced controls 2352 * Deleted the table on id-kp-cmcCA and id-kp-cmcRA and adding id-it- 2353 rootCaCert and id-it-certProfile in Section 2.19 2354 * Adding the definition of id-it-rootCaCert and id-it-certProfile in 2355 both ASN.1 modules in Appendix A 2356 * Minor editorial changes reflecting the above changes 2358 From version 07 -> 08: 2360 * Added a ToDo to Section 2.2 to reflect a current discussion on the 2361 need of an additional CMP-CA role and EKU and differentiation from 2362 CMP-RA 2363 * Added ToDos to Section 2.12 and 2.13 2364 From version 06 -> 07: 2366 * Added David von Oheimb as co-author 2367 * Changed to XML V3 2368 * Added Section 2.3 to enable a CMP protocol version number 3 in the 2369 PKIHeader for cases where EnvelopedData is to be used (see thread 2370 "Mail regarding draft-ietf-lamps-cmp-updates"). 2371 * Added Section 2.4 to refer to [I-D.ietf-lamps-crmf-update-algs] 2372 for the update of id-PasswordBasedMac for PKI message protection 2373 using passwords or shared secrets. 2374 * Updated Section 2.6 to introduce the protocol version number 3 to 2375 properly indicate support of EnvelopedData instead of 2376 EncryptedValue in case a transaction requires use of EnvelopedData 2377 (see thread "Mail regarding draft-ietf-lamps-cmp-updates"). 2378 * Update Section 2.14 to make the minimal changes to the respective 2379 section in CMP more explicit. 2380 * Added Sections 2.15 and 2.16 to address the new cmp2021 protocol 2381 version in Section 7 Version Negotiation. 2382 * Updated Section 2.17 to add new OIDs for id-regCtrl-algId and id- 2383 regCtrl-rsaKeyLen for registration at IANA. 2384 * Added Section 2.20 to update the general rules of interpretation 2385 in Appendix D.1 regarding the new cmp2021 version. 2386 * Added Section 2.21 to update the Algorithm Use Profile in 2387 Appendix D.2 with the reference to the new CMP Algorithms document 2388 as decided at IETF 108. 2389 * Updates Section 3.1 to delete the description of a discovery 2390 mechanism as decided at IETF 108. 2391 * Various changes and corrections in wording. 2393 From version 05 -> 06: 2395 * Added the update of Appendix D.2 with the reference to the new CMP 2396 Algorithms document as decided in IETF 108 2397 * Updated the IANA considerations to register new OIDs for id- 2398 regCtrl-algId and d-regCtrl-rsaKeyLen. 2399 * Minor changes and corrections 2401 From version 04 -> 05: 2403 * Added Section 2.10 and Section 2.11 to clarify the usage of these 2404 general messages types with EC curves (see thread 2405 "AlgorithmIdentifier parameters NULL value - Re: InfoTypeAndValue 2406 in CMP headers") 2407 * Split former section 2.7 on adding 'CA Certificates', 'Root CA 2408 Certificates Update', and 'Certificate Request Template' in three 2409 separate sections for easier readability 2411 * Changed in Section 2.14 the ASN.1 syntax of CertReqTemplateValue 2412 from using reaKeyLen to usage of controls as specified in CRMF 2413 Section 6 [RFC4211] (see thread "dtaft-ietf-lamps-cmp-updates and 2414 rsaKeyLen") 2415 * Updated the IANA considerations in Section 2.19 to introduce new 2416 OID for id-regCtrl-algId and id-regCtrl-rsaKeyLen (see thread 2417 "dtaft-ietf-lamps-cmp-updates and rsaKeyLen") 2418 * Updated the IANA Considerations in and the Appendixes to introduce 2419 new OID for the updates ASN.1 modules (see thread "I-D Action: 2420 draft-ietf-lamps-cmp-updates-04.txt") 2421 * Removed EncryptedValue from and added Controls to the list of 2422 types imported from CRMF [RFC4211] in ASN.1 modules (see thread 2423 "draft-ietf-lamps-cmp-updates and the ASN.1 modules") 2424 * Moved declaration of Rand out of the comment in ASN.1 modules (see 2425 thread "draft-ietf-lamps-cmp-updates and the ASN.1 modules") 2426 * Minor changes and corrections 2428 From version 03 -> 04: 2430 * Added Section 2.7 to introduce three new id-it IDs for uses in 2431 general messages as discussed (see thread "draft-ietf-lamps-cmp- 2432 updates add section to introduce id-it-caCerts, id-it- 2433 rootCaKeyUpdate, and id-it-certReqTemplate") 2434 * Added the new id-it IDs and the /.well-known/cmp to the IANA 2435 Considerations of [RFC4210] in Section 2.9 2436 * Updated the IANA Considerations of [RFC4210] in Section 2.20 2437 * Some changes in wording on Section 3 due to review comments from 2438 Martin Peylo 2440 From version 02 -> 03: 2442 * Added a ToDo on aligning with the CMP Algorithms draft that will 2443 be set up as decided in IETF 108 2444 * Updated section on Encrypted Values in Section 2.8 to add the 2445 AsymmetricKey Package structure to transport a newly generated 2446 private key as decided in IETF 108 2447 * Updated the IANA Considerations of [RFC4210] in Section 2.20 2448 * Added the pre-registered OID in Section 2.20 and the ASN.1 module 2449 * Added Section 3 to document the changes to RFC 6712 [RFC6712] 2450 regarding URI discovery and using the path-prefix of '/.well- 2451 known/' as discussed in IETF 108 2452 * Updated the IANA Considerations section 2453 * Added a complete updated ASN.1 module in 1988 syntax to update 2454 Appendix F of [RFC4210] and a complete updated ASN.1 module in 2455 2002 syntax to update Section 9 of [RFC5912] 2456 * Minor changes in wording 2458 From version 01 -> 02: 2460 * Updated section on EKU OIDs in Section 2.2 as decided in IETF 107 2461 * Changed from symmetric key-encryption to password-based key 2462 management technique in Section 2.8 as discussed with Russ and Jim 2463 on the mailing list 2464 * Defined the attribute containing the key identifier for the 2465 revocation passphrase in Section 2.20 2466 * Moved the change history to the Appendix 2468 From version 00 -> 01: 2470 * Minor changes in wording 2472 From draft-brockhaus-lamps-cmp-updates-03 -> draft-ietf-lamps-cmp- 2473 updates-00: 2475 * Changes required to reflect WG adoption 2477 From version 02 -> 03: 2479 * Added some clarification in Section 2.1 2481 From version 01 -> 02: 2483 * Added clarification to section on multiple protection 2484 * Added clarification on new EKUs after some exchange with Tomas 2485 Gustavsson 2486 * Reused OIDs from RFC 6402 [RFC6402] as suggested by Sean Turner at 2487 IETF 106 2488 * Added clarification on the field containing the key identifier for 2489 a revocation passphrase 2490 * Minor changes in wording 2492 From version 00 -> 01: 2494 * Added a section describing the new extended key usages 2495 * Completed the section on changes to the specification of encrypted 2496 values 2497 * Added a section on clarification to Appendix D.4 2498 * Minor generalization in RFC 4210 [RFC4210] Sections 5.1.3.4 and 2499 5.3.22 2500 * Minor changes in wording 2502 Authors' Addresses 2504 Hendrik Brockhaus 2505 Siemens AG 2507 Email: hendrik.brockhaus@siemens.com 2508 David von Oheimb 2509 Siemens AG 2511 Email: david.von.oheimb@siemens.com