idnits 2.17.1 draft-ietf-lamps-cmp-updates-07.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 5 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 == 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 (22 January 2021) is 1161 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 2134 -- Looks like a reference, but probably isn't: '1' on line 2137 -- Looks like a reference, but probably isn't: '2' on line 2084 -- Looks like a reference, but probably isn't: '3' on line 1836 -- Looks like a reference, but probably isn't: '4' on line 1837 -- Looks like a reference, but probably isn't: '5' on line 1838 -- Looks like a reference, but probably isn't: '6' on line 1839 -- Looks like a reference, but probably isn't: '7' on line 1840 -- Looks like a reference, but probably isn't: '8' on line 1841 == Missing Reference: 'CRMF' is mentioned on line 1463, but not defined == Missing Reference: 'PKCS10' is mentioned on line 1837, but not defined == Missing Reference: 'RFC3629' is mentioned on line 1827, but not defined == Missing Reference: 'RFC3066' is mentioned on line 1828, but not defined ** Obsolete undefined reference: RFC 3066 (Obsoleted by RFC 4646, RFC 4647) == Missing Reference: 'RFC2482' is mentioned on line 1830, but not defined ** Obsolete undefined reference: RFC 2482 (Obsoleted by RFC 6082) -- Looks like a reference, but probably isn't: '9' on line 1842 -- Looks like a reference, but probably isn't: '10' on line 1843 -- Looks like a reference, but probably isn't: '11' on line 1844 -- Looks like a reference, but probably isn't: '12' on line 1845 -- Looks like a reference, but probably isn't: '13' on line 1846 -- Looks like a reference, but probably isn't: '14' on line 1847 -- Looks like a reference, but probably isn't: '15' on line 1848 -- Looks like a reference, but probably isn't: '16' on line 1849 -- Looks like a reference, but probably isn't: '17' on line 1850 -- Looks like a reference, but probably isn't: '18' on line 1851 -- Looks like a reference, but probably isn't: '19' on line 1852 -- Looks like a reference, but probably isn't: '20' on line 1853 -- Looks like a reference, but probably isn't: '21' on line 1854 -- Looks like a reference, but probably isn't: '22' on line 1855 -- Looks like a reference, but probably isn't: '23' on line 1856 -- Looks like a reference, but probably isn't: '24' on line 1857 -- Looks like a reference, but probably isn't: '25' on line 1858 -- Looks like a reference, but probably isn't: '26' on line 1859 == Missing Reference: 'PKCS11' is mentioned on line 1893, but not defined == Missing Reference: 'RFC2104' is mentioned on line 1894, but not defined == Missing Reference: 'RFC2202' is mentioned on line 1894, but not defined == Outdated reference: A later version (-15) exists of draft-ietf-lamps-cmp-algorithms-02 == Outdated reference: A later version (-07) exists of draft-ietf-lamps-crmf-update-algs-02 ** 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-04 Summary: 7 errors (**), 0 flaws (~~), 14 warnings (==), 30 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 LAMPS Working Group H. Brockhaus 3 Internet-Draft D. von Oheimb 4 Updates: 4210, 5912, 6712 (if approved) Siemens 5 Intended status: Standards Track 22 January 2021 6 Expires: 26 July 2021 8 Certificate Management Protocol (CMP) Updates 9 draft-ietf-lamps-cmp-updates-07 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, adding new general message types, defining 19 extended key usages to identify certificates of CMP endpoints on 20 certification and registration authorities, and adding an HTTP URI 21 discovery mechanism and extending the URI structure. 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 26 July 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 . . . . . . . 7 67 2.4. Update Section 5.1.3.1. - Shared Secret Information . . . 7 68 2.5. Replace Section 5.1.3.4 - Multiple Protection . . . . . . 8 69 2.6. Replace Section 5.2.2. - Encrypted Values . . . . . . . . 9 70 2.7. Update Section 5.3.4. - Certification Response . . . . . 10 71 2.8. Update Section 5.3.19.2. - Signing Key Pair Types . . . . 11 72 2.9. Update Section 5.3.19.3. - Encryption/Key Agreement Key 73 Pair Types . . . . . . . . . . . . . . . . . . . . . . . 11 74 2.10. Replace Section 5.3.19.9. - Revocation Passphrase . . . . 12 75 2.11. New Section 5.3.19.14 - CA Certificates . . . . . . . . . 12 76 2.12. New Section 5.3.19.15 - Root CA Certificate Update . . . 12 77 2.13. New Section 5.3.19.16 - Certificate Request Template . . 13 78 2.14. Update Section 5.3.22 - Polling Request and Response . . 14 79 2.15. Update Section 7 - Version Negotiation . . . . . . . . . 15 80 2.16. Update Section 7.1.1. - Clients Talking to RFC 2510 81 Servers . . . . . . . . . . . . . . . . . . . . . . . . 16 82 2.17. Update Section 9 - IANA Considerations . . . . . . . . . 16 83 2.18. Update Appendix B - The Use of Revocation Passphrase . . 18 84 2.19. Update Appendix C - Request Message Behavioral 85 Clarifications . . . . . . . . . . . . . . . . . . . . . 18 86 2.20. Update Appendix D.1. - General Rules for Interpretation of 87 These Profiles . . . . . . . . . . . . . . . . . . . . . 19 88 2.21. Update Appendix D.2. - Algorithm Use Profile . . . . . . 19 89 2.22. Update Appendix D.4. - Initial Registration/Certification 90 (Basic Authenticated Scheme) . . . . . . . . . . . . . . 20 91 3. Updates to RFC 6712 - HTTP Transfer for the Certificate 92 Management Protocol (CMP) . . . . . . . . . . . . . . . . 20 93 3.1. New Section 1.1. - Changes since RFC 6712 . . . . . . . . 20 94 3.2. Replace Section 3.6. - HTTP Request-URI . . . . . . . . . 20 95 3.3. Update Section 6. - IANA Considerations . . . . . . . . . 21 96 4. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 21 97 5. Security Considerations . . . . . . . . . . . . . . . . . . . 22 98 6. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 22 99 7. References . . . . . . . . . . . . . . . . . . . . . . . . . 22 100 7.1. Normative References . . . . . . . . . . . . . . . . . . 22 101 7.2. Informative References . . . . . . . . . . . . . . . . . 24 102 Appendix A. ASN.1 Modules . . . . . . . . . . . . . . . . . . . 24 103 A.1. 1988 ASN.1 Module . . . . . . . . . . . . . . . . . . . . 25 104 A.2. 2002 ASN.1 Module . . . . . . . . . . . . . . . . . . . . 37 105 Appendix B. History of changes . . . . . . . . . . . . . . . . . 49 106 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 52 108 1. Introduction 110 [RFC Editor: please delete]: !!! The change history was moved to 111 Appendix B !!! 113 While using CMP [RFC4210] in industrial and IoT environments and 114 developing the Lightweight CMP Profile 115 [I-D.ietf-lamps-lightweight-cmp-profile] some limitations were 116 identified in the original CMP specification. This document updates 117 RFC 4210 [RFC4210] and RFC 6712 [RFC6712] to overcome these 118 limitations. 120 Among others, this document improves the crypto agility of CMP, which 121 means to be flexible to react on future advances in cryptography. 123 This document also introduces new extended key usages to identify CMP 124 endpoints on registration and certification authorities. 126 1.1. Convention and Terminology 128 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 129 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 130 document are to be interpreted as described in BCP 14 [RFC2119] 131 [RFC8174] when, and only when, they appear in all capitals, as shown 132 here. 134 Technical terminology is used in conformance with RFC 4210 [RFC4210], 135 RFC 4211 [RFC4211], and RFC 5280 [RFC5280]. The following key words 136 are used: 138 CA: Certification authority, which issues certificates. 140 RA: Registration authority, an optional system component to which a 141 CA delegates certificate management functions such as 142 authorization checks. 144 KGA: Key generation authority, which generates key pairs on behalf 145 of an EE. The KGA could be co-located with an RA or a CA. 147 EE: End entity, a user, device, or service that holds a PKI 148 certificate. An identifier for the EE is given as its subject 149 of the certificate. 151 2. Updates to RFC 4210 - Certificate Management Protocol (CMP) 153 2.1. New Section 1.1. - Changes since RFC 4210 155 The following subsection describes feature updates to RFC 4210 156 [RFC4210]. They are always related to the base specification. Hence 157 references to the original sections in RFC 4210 [RFC4210] are used 158 whenever possible. 160 Insert this section at the end of the current Section 1. 162 1.1. Changes since RFC 4210 164 The following updates are made in [thisRFC]: 166 * Add new extended key usages for various CMP server types, e.g., 167 registration authority and certification authority, to express the 168 authorization of the entity identified in the certificate 169 containing the respective extended key usage extension to act as 170 the indicated PKI management entity. 172 * Extend the description of multiple protection to cover additional 173 use cases, e.g., batch processing of messages. 175 * Offering EnvelopedData as the preferred choice next to 176 EncryptedValue to better support crypto agility in CMP. Note that 177 according to RFC 4211 [RFC4211] section 2.1. point 9 the use of 178 the EncryptedValue structure has been deprecated in favor of the 179 EnvelopedData structure. RFC 4211 [RFC4211] offers the 180 EncryptedKey structure, a choice of EncryptedValue and 181 EnvelopedData for migration to EnvelopedData. For reasons of 182 completeness and consistency the type EncryptedValue has been 183 exchanged in all occurrences in RFC 4210 [RFC4210]. This includes 184 the protection of centrally generated private keys, encryption of 185 certificates, and protection of revocation passphrases. To 186 properly differentiate the support of EnvelopedData instead of 187 EncryptedValue, the CMP version 3 is introduced in case a 188 transaction is supposed to use EnvelopedData. 190 * Adding new general message types to request CA certificates, a 191 root CA update, or a certificate request template. 193 * Extend the usage of polling to p10cr messages. 195 * Delete the mandatory algorithm profile in RFC 4210 Appendix D.2 196 [RFC4210] and refer to CMP Algorithms 197 [I-D.ietf-lamps-cmp-algorithms]. 199 < TBD: The specification of algorithm profiles seed to be moved to a 200 separate document. > 202 2.2. New Section 4.5 - Extended Key Usage 204 The following subsection describes new extended key usages for 205 various CMP server types specified in RFC 4210 [RFC4210]. 207 Insert this section at the end of the current Section 4. 209 4.5. Extended Key Usage 211 The Extended Key Usage (EKU) extension indicates the purposes for 212 which the certified key pair may be used. It therefore restricts the 213 use of a certificate to specific applications. 215 A CA may want to delegate parts of its duties to other PKI management 216 entities. The mechanism to prove this delegation explained in this 217 section offers automatic way of checking the authorization of such 218 delegation. Such delegation could also be expressed by other means, 219 e.g., explicit configuration. 221 To offer automatic validation for the delegation of a role by a CA, 222 the certificates used for CMP message protection or signed data for 223 central key generation MUST be issued by the delegating CA and MUST 224 contain the respective EKUs. This proves the authorization of this 225 entity by the delegating CA to act in the given role as described 226 below. 228 The OIDs to be used for these EKUs are: 230 id-kp-cmcCA OBJECT IDENTIFIER ::= { 231 iso(1) identified-organization(3) dod(6) internet(1) 232 security(5) mechanisms(5) pkix(7) kp(3) 27 } 233 id-kp-cmcRA OBJECT IDENTIFIER ::= { 234 iso(1) identified-organization(3) dod(6) internet(1) 235 security(5) mechanisms(5) pkix(7) kp(3) 28 } 236 id-kp-cmKGA OBJECT IDENTIFIER ::= { 237 iso(1) identified-organization(3) dod(6) internet(1) 238 security(5) mechanisms(5) pkix(7) kp(3) 32 } 240 Note: RFC 6402 section 2.10 [RFC6402] specifies OIDs for a CMC CA and 241 a CMC RA. As the functionality of a CA and RA is not specific to 242 using CMC or CMP as certificate management protocol, these OIDs SHALL 243 be re-used also for CMP CAs and for CMP RAs. 245 The description of the PKI management entity for each of the EKUs is 246 as follows: 248 CMP CA: CMP Certification Authorities are CMP endpoints on CA 249 equipment as described in section 3.1.1.2. The private key 250 used in the context of CMP management operations, 251 especially CMP message protection, does not need to be the 252 same as for signing certificates. It is necessary, 253 however, to ensure that the entity acting as CMP CA is 254 authorized to do so. Therefore, the CMP CA MUST do one of 255 the following, 257 * use the CA private key also for the CMP endpoint, or 259 * explicitly designate this role to another entity. 261 For automatic validation of such a delegation this MUST be 262 indicated by the id-kp-cmcCA extended key usage. This 263 extended key usage MUST be placed into the certificate used 264 on the CA equipment and the CA that delegates this role 265 MUST issue the CMP CA certificate. 267 Note: Using a separate key pair for protecting CMP 268 management operations at the CA decreases the number of 269 operations of the private key used to sign certificates. 271 CMP RA: CMP Registration Authorities are CMP endpoints on RA 272 equipment as described in Section 3.1.1.3. A CMP RA is 273 identified by the id-kp-cmcRA extended key usage. This 274 extended key usage MUST be placed in RA certificates. The 275 CA that delegated this role is identified by the CA that 276 issued the CMP RA certificate. 278 CMP KGA: CMP Key Generation Authorities are identified by the id-kp- 279 cmKGA extended key usage. The CMP KGA knows the private 280 key it generated on behalf of the end entity. This is a 281 very sensitive service and therefore needs specific 282 authorization. This authorization is either with the CA 283 certificate itself, or it MUST be indicated by placing the 284 id-kp-cmKGA extended key usage in the certificate used to 285 authenticate the origin of the generated private key, and 286 to express the authorization to offer this service. 288 Note: In device PKIs, especially those issuing IDevID certificates 289 IEEE 802.1AR Section 8.5 [IEEE.802.1AR_2018], CA certificates may 290 have very long validity (including the GeneralizedTime value 291 99991231235959Z to indicate a not well-defined expiration date as 292 specified in IEEE 802.1AR Section 8.5 [IEEE.802.1AR_2018] and 293 RFC 5280 Section 4.1.2.5 [RFC5280]). Such validity periods SHOULD 294 NOT be used for protection of CMP messages. Certificates for 295 delegated CMP message protection (CMP CA, CMP RA, CMP KGA) MUST NOT 296 use indefinite expiration date. 298 2.3. Update Section 5.1.1. - PKI Message Header 300 Section 5.1.1 of RFC 4210 [RFC4210] describes the PKI message header. 301 This document introduces the new version 3 indicating support of 302 EnvelopedData as specified in Section 2.6. 304 Replace the ASN.1 Syntax of PKIHeader and the subsequent description 305 of pvno with the following text: 307 PKIHeader ::= SEQUENCE { 308 pvno INTEGER { cmp1999(1), cmp2000(2), 309 cmp2021(3) }, 310 sender GeneralName, 311 recipient GeneralName, 312 messageTime [0] GeneralizedTime OPTIONAL, 313 protectionAlg [1] AlgorithmIdentifier OPTIONAL, 314 senderKID [2] KeyIdentifier OPTIONAL, 315 recipKID [3] KeyIdentifier OPTIONAL, 316 transactionID [4] OCTET STRING OPTIONAL, 317 senderNonce [5] OCTET STRING OPTIONAL, 318 recipNonce [6] OCTET STRING OPTIONAL, 319 freeText [7] PKIFreeText OPTIONAL, 320 generalInfo [8] SEQUENCE SIZE (1..MAX) OF 321 InfoTypeAndValue OPTIONAL 322 } 323 PKIFreeText ::= SEQUENCE SIZE (1..MAX) OF UTF8String 325 The usage of different pvno values is described in Section 7. 327 2.4. Update Section 5.1.3.1. - Shared Secret Information 329 Section 5.1.3.1 of RFC 4210 [RFC4210] describes the MAC based 330 protection of a PKIMessage using the algorithm id-PasswordBasedMac. 332 Replace the first paragraph with the following text: 334 In this case, the sender and recipient share secret information with 335 sufficient entropy (established via out-of-band means or from a 336 previous PKI management operation). PKIProtection will contain a MAC 337 value and the protectionAlg will be the following (see also [RFC4211] 338 and [I-D.ietf-lamps-crmf-update-algs]): 340 2.5. Replace Section 5.1.3.4 - Multiple Protection 342 Section 5.1.3.4 of RFC 4210 [RFC4210] describes the nested message. 343 This document enables using opens the usage of nested messages also 344 for batch transport of PKI messages between PKI management entities 345 and also with mixed body types. 347 Replace the text of the section with the following text. 349 5.1.3.4. Multiple Protection 351 When receiving a protected PKI message, a PKI management entity such 352 as an RA MAY forward that message adding its own protection (which 353 MAY be a MAC or a signature, depending on the information and 354 certificates shared between the RA and the CA). Moreover, multiple 355 PKI messages MAY be aggregated. There are several use cases for such 356 messages. 358 * The RA confirms having validated and authorized a message and 359 forwards the original message unchanged. 361 * The RA collects several messages that are to be forwarded in the 362 same direction and forwards them in a batch. In communication to 363 the CA request messages and in communication from the CA response 364 or announcement messages will be collected. This can for instance 365 be used when bridging an off-line connection between two PKI 366 management entities. 368 * The RA modifies the message(s) in some way (e.g., add or modify 369 particular field values or add new extensions) before forwarding 370 them, then it MAY create its own desired PKIBody. In case the 371 changes made by the RA to PKIMessage breaks the POP of a 372 certificate request, the RA MUST set the POP RAVerified. It MAY 373 include the original PKIMessage from the EE in the generalInfo 374 field of PKIHeader of the nested message (to accommodate, for 375 example, cases in which the CA wishes to check POP or other 376 information on the original EE message). The infoType to be used 377 in this situation is {id-it 15} (see Section 5.3.19 for the value 378 of id-it) and the infoValue is PKIMessages (contents MUST be in 379 the same order as the message in PKIBody). 381 These use cases are accomplished by nesting the messages sent by the 382 PKI entity within a new PKI message. The structure used is as 383 follows. 385 NestedMessageContent ::= PKIMessages 387 2.6. Replace Section 5.2.2. - Encrypted Values 389 Section 5.2.2 of RFC 4210 [RFC4210] describes the use of 390 EncryptedValue to transport encrypted data. This document extends 391 the encryption of data to preferably use EnvelopedData. 393 Replace the text of the section with the following text. 395 5.2.2. Encrypted Values 397 Where encrypted data (in this specification, private keys, 398 certificates, or revocation passphrase) are sent in PKI messages, the 399 EncryptedKey data structure is used. 401 EncryptedKey ::= CHOICE { 402 encryptedValue EncryptedValue, -- deprecated 403 envelopedData [0] EnvelopedData } 405 See CRMF [RFC4211] for EncryptedKey and EncryptedValue syntax and CMS 406 [RFC5652] for EnvelopedData syntax. Using the EncryptedKey data 407 structure, offers the choice to either use EncryptedValue (for 408 backward compatibility only) or EnvelopedData. The use of the 409 EncryptedValue structure has been deprecated in favor of the 410 EnvelopedData structure. Therefore, it is recommended to use 411 EnvelopedData. 413 Note: The EncryptedKey structure defined in CRMF [RFC4211] is reused 414 here, which makes the update is backward compatible. Using the new 415 syntax with the untagged default choice EncryptedValue is bits-on- 416 the-wire compatible with the old syntax. 418 To indicate support for EnvelopedData the pvno cmp2021 is introduced 419 by this document. Details on the usage of different pvno values is 420 described in Section 7. 422 The EncryptedKey data structure is used in CMP to transport a private 423 key, certificate, or revocation passphrase in encrypted form. 425 EnvelopedData is used as follows: 427 * It contains only one RecipientInfo structure because the content 428 is encrypted only for one recipient. 430 * It may contain a private key in the AsymmetricKeyPackage structure 431 as defined in RFC 5958 [RFC5958] wrapped in a SignedData structure 432 as specified in CMS section 5 [RFC5652] signed by the Key 433 Generation Authority. 435 * It may contain a certificate or revocation passphrase directly in 436 the encryptedContent field. 438 The content of the EnvelopedData structure, as specified in CMS 439 section 6 [RFC5652], MUST be encrypted using a newly generated 440 symmetric content-encryption key. This content-encryption key MUST 441 be securely provided to the recipient using one of three key 442 management techniques. 444 The choice of the key management technique to be used by the sender 445 depends on the credential available at the recipient: 447 * Recipient's certificate that contains a key usage extension 448 asserting keyAgreement: The content-encryption key will be 449 protected using the key agreement key management technique, as 450 specified in CMS section 6.2.2 [RFC5652]. This is the preferred 451 technique. 453 * Recipient's certificate that contains a key usage extension 454 asserting keyEncipherment: The content-encryption key will be 455 protected using the key transport key management technique, as 456 specified in CMS section 6.2.1 [RFC5652]. 458 * A password or shared secret: The content-encryption key will be 459 protected using the password-based key management technique, as 460 specified in CMS section 6.2.4 [RFC5652]. 462 2.7. Update Section 5.3.4. - Certification Response 464 Section 5.3.4 of RFC 4210 [RFC4210] describes the Certification 465 Response. This document updates the syntax by using the parent 466 structure EncryptedKey instead of EncryptedValue as described in 467 Section 2.6 above. 469 Replace the ASN.1 syntax of CertifiedKeyPair and CertOrEncCert with 470 the following text. 472 CertifiedKeyPair ::= SEQUENCE { 473 certOrEncCert CertOrEncCert, 474 privateKey [0] EncryptedKey OPTIONAL, 475 -- see [CRMF] for comment on encoding 476 publicationInfo [1] PKIPublicationInfo OPTIONAL 477 } 479 CertOrEncCert ::= CHOICE { 480 certificate [0] Certificate, 481 encryptedCert [1] EncryptedKey 482 } 484 Add the following as a new paragraph right after the ASN.1 syntax. 486 A p10cr message contains exactly one CertificationRequestInfo data 487 structure as specified in PKCS#10 [RFC2986] but no certReqId. 488 Therefore, the certReqId in the corresponding certification response 489 (cp) message MUST be set to 0. 491 Add the following as new paragraphs to the end of the section. 493 The use of EncryptedKey is described in Section 5.2.2. 495 Note: To indicate support for EnvelopedData the pvno cmp2021 is 496 introduced by this document. Details on the usage of different pvno 497 values is described in Section 7. 499 2.8. Update Section 5.3.19.2. - Signing Key Pair Types 501 The following section clarifies the usage of the Signing Key Pair 502 Types PKI general message on referencing EC curves. 504 Insert this note at the end of Section 5.3.19.2. 506 Note: In case several EC curves are supported, several id-ecPublicKey 507 elements need to be given, one each per named curve. 509 2.9. Update Section 5.3.19.3. - Encryption/Key Agreement Key Pair Types 511 The following section clarifies the use of the Encryption/Key 512 Agreement Key Pair Types PKI general message on referencing EC 513 curves. 515 Insert this note at the end of Section 5.3.19.3. 517 Note: In case several EC curves are supported, several id-ecPublicKey 518 elements need to be given, one each per named curve. 520 2.10. Replace Section 5.3.19.9. - Revocation Passphrase 522 Section 5.3.19.9 of RFC 4210 [RFC4210] describes the provisioning of 523 a revocation passphrase for authenticating a later revocation 524 request. This document updates the handling by using the parent 525 structure EncryptedKey instead of EncryptedValue to transport this 526 information as described in Section 2.6 above. 528 Replace the text of the section with the following text. 530 5.3.19.9. Revocation Passphrase 532 This MAY be used by the EE to send a passphrase to a CA/RA for the 533 purpose of authenticating a later revocation request (in the case 534 that the appropriate signing private key is no longer available to 535 authenticate the request). See Appendix B for further details on the 536 use of this mechanism. 538 GenMsg: {id-it 12}, EncryptedKey 539 GenRep: {id-it 12}, < absent > 541 The use of EncryptedKey is described in section 5.2.2. 543 2.11. New Section 5.3.19.14 - CA Certificates 545 The following subsection describes the PKI general message using id- 546 it-caCerts. The use is specified in Lightweight CMP Profile [I- 547 D.ietf-lamps-lightweight-cmp-profile] Section 4.4. 549 Insert this section after Section 5.3.19.13. 551 2.3.19.14 CA Certificates 553 This MAY be used by the client to get the current CA intermediate and 554 issuing CA certificates. 556 GenMsg: {id-it 17}, < absent > 557 GenRep: {id-it 17}, SEQUENCE OF CMPCertificate | < absent > 559 2.12. New Section 5.3.19.15 - Root CA Certificate Update 561 The following subsection describes the PKI general message using id- 562 it-rootCaKeyUpdate. The use is specified in Lightweight CMP Profile 563 [I-D.ietf-lamps-lightweight-cmp-profile] Section 4.4. 565 Insert this section after new Section 5.3.19.14. 567 5.3.19.15. Root CA Certificate Update 569 This MAY be used by the client to get an update of an existing root 570 CA Certificate. In contrast to the ckuann message it follows the 571 request/response model. 573 GenMsg: {id-it 18}, < absent > 574 GenRep: {id-it 18}, RootCaKeyUpdateContent | < absent > 576 RootCaKeyUpdateContent ::= SEQUENCE { 577 newWithNew CMPCertificate 578 newWithOld [0] CMPCertificate OPTIONAL, 579 oldWithNew [1] CMPCertificate OPTIONAL 580 } 582 Note: In contrast to CAKeyUpdAnnContent, this type offers omitting 583 newWithOld and oldWithNew in the GenRep message, depending on the 584 needs of the EE. 586 2.13. New Section 5.3.19.16 - Certificate Request Template 588 The following subsection describes the PKI general message using id- 589 it-certReqTemplate. The use is specified in Lightweight CMP Profile 590 [I-D.ietf-lamps-lightweight-cmp-profile] Section 4.4. 592 Insert this section after new Section 5.3.19.15. 594 5.3.19.16. Certificate Request Template 596 This MAY be used by the client to get a template containing 597 requirements for certificate request attributes and extensions and 598 optionally a specification for the key pair to generate for a future 599 certificate request operation. 601 GenMsg: {id-it 19}, < absent > 602 GenRep: {id-it 19}, CertReqTemplateContent | < absent > 604 CertReqTemplateContent ::= SEQUENCE { 605 certTemplate CertTemplate, 606 keySpec Controls OPTIONAL 607 } 609 Controls ::= SEQUENCE SIZE(1..MAX) OF AttributeTypeAndValue 611 id-regCtrl-algId OBJECT IDENTIFIER ::= { iso(1) 612 identified-organization(3) dod(6) internet(1) security(5) 613 mechanisms(5) pkix(7) pkip(5) regCtrl(1) TBD3 } 614 AlgIdCtrl ::= AlgorithmIdentifier 616 id-regCtrl-rsaKeyLen OBJECT IDENTIFIER ::= { iso(1) 617 identified-organization(3) dod(6) internet(1) security(5) 618 mechanisms(5) pkix(7) pkip(5) regCtrl(1) TBD4 } 619 RsaKeyLenCtrl ::= Integer 621 < TBD: The OIDs TBD3 and TBD4 have to be registered at IANA. > 623 CertReqTemplateValue contains a prefilled certTemplate to be used for 624 the future certificate request. The SubjectPublicKeyInfo field in 625 the certTemplate MUST NOT be used. In case the PKI management entity 626 wishes to specify supported algorithms, the keySpec field MUST be 627 used. One AttributeTypeAndValue per supported algorithm or RSA key 628 length MUST be used. 630 Note: The Controls ASN.1 type is defined in CRMF Section 6 [RFC4211] 632 2.14. Update Section 5.3.22 - Polling Request and Response 634 Section 5.3.22 of RFC 4210 [RFC4210] describes when and how polling 635 messages are used. This document adds the polling mechanism also for 636 outstanding responses to a p10cr. 638 Replace in the first paragraph the word 'cr' by 'cr, p10cr' and add 639 just before the state machine diagram the following text. 641 A p10cr message contains exactly one CertificationRequestInfo data 642 structure as specified in PKCS#10 [RFC2986] but no certificate 643 request identifier. Therefore, the certReqId MUST be set to 0 in all 644 subsequent messages of this transaction. 646 2.15. Update Section 7 - Version Negotiation 648 Section 7 of RFC 4210 [RFC4210] describes the use of different CMP 649 protocol versions. This document describes the handling of the 650 additional CMP version cmp2021 introduced to indicate support of 651 EnvelopedData. 653 Replace the text of the first two paragraphs with the following text. 655 This section defines the version negotiation between client and 656 servers used to choose among cmp1999 (specified in RFC 2510 657 [RFC2510]), of cmp2000 (specified in RFC 4210 [RFC4210]), and cmp2021 658 (specified in this document). The only difference between protocol 659 versions cmp2021 and cmp2000 is that EnvelopedData replaces 660 EncryptedValue. 662 If a client does not support cmp2021 it chooses the versions for a 663 request as follows: 665 * If the client knows the protocol version(s) supported by the 666 server (e.g., from a previous PKIMessage exchange or via some out- 667 of-band means), then it MUST send a PKIMessage with the highest 668 version supported by both it and the server. 670 * If the client does not know what version(s) the server supports, 671 then it MUST send a PKIMessage using the highest version it 672 supports. 674 If a client supports cmp2021 and encrypted values are supposed to be 675 transferred in the PKI management operation the client MUST choose 676 the version for a request as follows: 678 * If the client supports EnvelopedData, but not EncryptedValue, then 679 it MUST send a PKIMessage using cmp2021. 681 * If the client does not support EnvelopedData, but EncryptedValue, 682 then it MUST send a PKIMessage using cmp2000. 684 * If the client supports both EnvelopedData and EncryptedValues: 686 - If the client knows the protocol version(s) supported by the 687 server (e.g., from a previous PKIMessage exchange or via some 688 out-of-band means), then it MUST send a PKIMessage with the 689 highest version supported the server. 691 - If the client does not know what version(s) the server 692 supports, then it MUST send a PKIMessage using cmp2021. 694 2.16. Update Section 7.1.1. - Clients Talking to RFC 2510 Servers 696 Section 7.1.1 of RFC 4210 [RFC4210] describes the behaviour of a 697 client talking to a cmp1999 server. This document extends the 698 section to all clients with a higher version than cmp1999. 700 Replace the first sentence of section 7.1.1 with the following text. 702 If, after sending a message with a higher protocol version number 703 than cmp1999, a client receives an ErrorMsgContent with a version of 704 cmp1999, then it MUST abort the current transaction. 706 2.17. Update Section 9 - IANA Considerations 708 Section 9 of RFC 4210 [RFC4210] contains the IANA Considerations of 709 that document. As this document defines one new and updates two 710 existing Extended Key Usages, the IANA Considerations need to be 711 updated accordingly. 713 Add the following paragraphs after the third paragraph of the 714 section. 716 In the SMI-numbers registry "SMI Security for PKIX Extended Key 717 Purpose Identifiers (1.3.6.1.5.5.7.3)" (see 718 https://www.iana.org/assignments/smi-numbers/smi-numbers.xhtml#smi- 719 numbers-1.3.6.1.5.5.7.3) as defined in RFC 7299 [RFC7299] three 720 changes have been performed. 722 Two existing entries have been updated to also point to this 723 document: 725 +=========+=============+====================+ 726 | Decimal | Description | References | 727 +=========+=============+====================+ 728 | 27 | id-kp-cmcCA | [RFC6402][thisRFC] | 729 +---------+-------------+--------------------+ 730 | 28 | id-kp-cmcRA | [RFC6402][thisRFC] | 731 +---------+-------------+--------------------+ 733 Table 1: Changes to the PKIX Extended Key 734 Purpose Identifiers registry 736 One new entry has been added: 738 +=========+=============+============+ 739 | Decimal | Description | References | 740 +=========+=============+============+ 741 | 32 | id-kp-cmKGA | [thisRFC] | 742 +---------+-------------+------------+ 744 Table 2: Adition to the PKIX 745 Extended Key Purpose Identifiers 746 registry 748 In the SMI-numbers registry "SMI Security for PKIX CMP Information 749 Types (1.3.6.1.5.5.7.4)" (see https://www.iana.org/assignments/smi- 750 numbers/smi-numbers.xhtml#smi-numbers-1.3.6.1.5.5.7.4) as defined in 751 RFC 7299 [RFC7299] three additions have been performed. 753 Three new entries have been added: 755 +=========+=======================+============+ 756 | Decimal | Description | References | 757 +=========+=======================+============+ 758 | 17 | id-it-caCerts | [thisRFC] | 759 +---------+-----------------------+------------+ 760 | 18 | id-it-rootCaKeyUpdate | [thisRFC] | 761 +---------+-----------------------+------------+ 762 | 19 | id-it-certReqTemplate | [thisRFC] | 763 +---------+-----------------------+------------+ 765 Table 3: Addition to the PKIX CMP 766 Information Types registry 768 In the SMI-numbers registry " SMI Security for PKIX CRMF Registration 769 Controls (1.3.6.1.5.5.7.5.1)" (see https://www.iana.org/assignments/ 770 smi-numbers/smi-numbers.xhtml#smi-numbers-1.3.6.1.5.5.7.5.1) as 771 defined in RFC 7299 [RFC7299] two additions have been performed. 773 Two new entries have been added: 775 +=========+======================+============+ 776 | Decimal | Description | References | 777 +=========+======================+============+ 778 | TBD3 | id-regCtrl-algId | [thisRFC] | 779 +---------+----------------------+------------+ 780 | TBD4 | id-regCtrl-rsaKeyLen | [thisRFC] | 781 +---------+----------------------+------------+ 783 Table 4: Addition to the PKIX CRMF 784 Registration Controls registry 786 2.18. Update Appendix B - The Use of Revocation Passphrase 788 Appendix B of RFC 4210 [RFC4210] describes the use of the revocation 789 passphrase. As this document updates RFC 4210 [RFC4210] to utilize 790 the parent structure EncryptedKey instead of EncryptedValue as 791 described in Section 2.6 above, the description is updated 792 accordingly. 794 Replace the first bullet point of this section with the following 795 text. 797 * The OID and value specified in Section 5.3.19.9 MAY be sent in a 798 GenMsg message at any time, or MAY be sent in the generalInfo 799 field of the PKIHeader of any PKIMessage at any time. (In 800 particular, the EncryptedKey structure as described in section 801 5.2.2 may be sent in the header of the certConf message that 802 confirms acceptance of certificates requested in an initialization 803 request or certificate request message.) This conveys a 804 revocation passphrase chosen by the entity to the relevant CA/RA. 805 For use of EnvelopedData this is in the decrypted bytes of 806 encryptedContent field and for use of EncryptedValue this is in 807 the decrypted bytes of the encValue field. Furthermore, the 808 transfer is accomplished with appropriate confidentiality 809 characteristics. 811 Replace the third bullet point of this section with the following 812 text. 814 * When using EnvelopedData the localKeyId attribute as specified in 815 RFC 2985 [RFC2985] and when using EncryptedValue the valueHint 816 field MAY contain a key identifier (chosen by the entity, along 817 with the passphrase itself) to assist in later retrieval of the 818 correct passphrase (e.g., when the revocation request is 819 constructed by the entity and received by the CA/RA). 821 2.19. Update Appendix C - Request Message Behavioral Clarifications 823 Appendix C of RFC 4210 [RFC4210] provides clarifications to the 824 request message behavior. As this document updates RFC 4210 825 [RFC4210] to utilize the parent structure EncryptedKey instead of 826 EncryptedValue as described in Section 2.6 above, the description is 827 updated accordingly. 829 Replace the comment within the ASN.1 syntax coming after the 830 definition of POPOPrivKey with the following text. 832 -- ********** 833 -- * the type of "thisMessage" is given as BIT STRING in RFC 4211 834 -- * [RFC4211]; it should be "EncryptedKey" (in accordance with 835 -- * Section 5.2.2 of this specification). Therefore, this 836 -- * document makes the behavioral clarification of specifying 837 -- * that the contents of "thisMessage" MUST be encoded either as 838 -- * "EnvelopedData" or "EncryptedValue" (only for backward 839 -- * compatibility) and then wrapped in a BIT STRING. This 840 -- * allows the necessary conveyance and protection of the 841 -- * private key while maintaining bits-on-the-wire compatibility 842 -- * with RFC 4211 [RFC4211]. 843 -- ********** 845 2.20. Update Appendix D.1. - General Rules for Interpretation of These 846 Profiles 848 Appendix D.1 of RFC 4210 [RFC4210] provides general rules for 849 interpretation of the PKI management messages profiles specified in 850 Appendix D and Appendix E of RFC 4210 [RFC4210]. This document 851 updates a sentence regarding the new protocol version cmp2021. 853 Replace the last sentence of the first paragraph of the section with 854 the following text. 856 Mandatory fields are not mentioned if they have an obvious value 857 (e.g., in this version of these profiles, pvno is always cmp2000). 859 2.21. Update Appendix D.2. - Algorithm Use Profile 861 Appendix D.2 of RFC 4210 [RFC4210] provides a list of algorithms that 862 implementations must support when claiming conformance with PKI 863 Management Message Profiles as specified in CMP Appendix D.2 864 [RFC4210]. This document redirects to the new algorithm profile as 865 specified in Appendix A.1 of CMP Algorithms 866 [I-D.ietf-lamps-cmp-algorithms]. 868 Replace the text of the section with the following text. 870 D.2. Algorithm Use Profile 872 For specifications of algorithm identifiers and respective 873 conventions for conforming implementations, please refer to CMP 874 Algorithms Appendix A.1 [I-D.ietf-lamps-cmp-algorithms]. 876 2.22. Update Appendix D.4. - Initial Registration/Certification (Basic 877 Authenticated Scheme) 879 Appendix D.4 of RFC 4210 [RFC4210] provides the initial registration/ 880 certification scheme. This scheme shall continue using 881 EncryptedValue for backward compatibility reasons. 883 Replace the comment after the privateKey field of 884 crc[1].certifiedKeyPair in the syntax of the Initialization Response 885 message with the following text. 887 -- see Appendix C, Request Message Behavioral Clarifications 888 -- for backward compatibility reasons, use EncryptedValue 890 3. Updates to RFC 6712 - HTTP Transfer for the Certificate Management 891 Protocol (CMP) 893 3.1. New Section 1.1. - Changes since RFC 6712 895 The following subsection describes feature updates to RFC 6712 896 [RFC6712]. They are related to the base specification. Hence 897 references to the original sections in RFC 6712 [RFC6712] are used 898 whenever possible. 900 Insert this section at the end of the current Section 1. 902 1.1 Changes since RFC 6712 904 The following updates are made in [thisRFC]: 906 * Introduce the HTTP path '/.well-known/cmp'. 908 * Extend the URI structure. 910 3.2. Replace Section 3.6. - HTTP Request-URI 912 Section 3.6 of RFC 6712 [RFC6712] specifies the used HTTP URIs. This 913 document introduces the HTTP path '/.well-known/cmp' and extends the 914 URIs. 916 Replace the text of the section with the following text. 918 3.6. HTTP Request-URI 919 Each CMP server on a PKI management entity supporting HTTP or HTTPS 920 transport MUST support the use of the path prefix '/.well-known/' as 921 defined in RFC 8615 [RFC8615] and the registered name 'cmp' to ease 922 interworking in a multi-vendor environment. 924 The CMP client needs to be configured with sufficient information to 925 form the CMP server URI. This is at least the authority portion of 926 the URI, e.g., 'www.example.com:80', or the full operation path 927 segment of the PKI management entity. Additionally, OPTIONAL path 928 segments MAY be added after the registered application name as part 929 of the full operation path to provide further distinction. A path 930 segment could for example support the differentiation of specific 931 CAs, certificate profiles, or PKI management operations. A valid 932 full operation path segment can look like this: 934 http://www.example.com/.well-known/cmp 935 http://www.example.com/.well-known/cmp/operationLabel 936 http://www.example.com/.well-known/cmp/profileLabel 937 http://www.example.com/.well-known/cmp/profileLabel/operationLabel 939 3.3. Update Section 6. - IANA Considerations 941 Section 6 of RFC 6712 [RFC6712] contains the IANA Considerations of 942 that document. As this document defines a new well-known URI, the 943 IANA Considerations need to be updated accordingly. 945 Add the following text between the first and second paragraph of the 946 section. 948 In the well-known URI registry (see https://www.iana.org/assignments/ 949 well-known-uris/well-known-uris.xhtml#well-known-uris-1) as defined 950 in RFC 8615 [RFC8615] the following change has been performed. 952 One new name entry has been added: 954 +============+===================+ 955 | URI suffix | Change controller | 956 +============+===================+ 957 | cmp | IETF | 958 +------------+-------------------+ 960 Table 5 962 4. IANA Considerations 964 This document contains an update to the IANA Consideration sections 965 to be added to [RFC4210] and [RFC6712]. 967 < TBD: This document updates the ASN.1 modules of RFC 4210 Appendix F 968 [RFC4210] and RFC 5912 Section 9 [RFC5912]. New OIDs TBD1 and TBD2 969 need to be registered to identify the updates ASN.1 modules. > 971 < TBD: New OIDs TBD3 (id-regCtrl-algId) and TBD4 (id-regCtrl- 972 rsaKeyLen) need to be registered. > 974 < TBD: The existing description and information of id-kp-cmcRA and 975 id-kp-cmcCA need to be updated to reflect their extended usage. > 977 5. Security Considerations 979 No changes are made to the existing security considerations of 980 RFC 4210 [RFC4210] and RFC 6712 [RFC6712]. 982 6. Acknowledgements 984 Special thank goes to Jim Schaad for his guidance and the inspiration 985 on structuring and writing this document we got from [RFC6402] which 986 updates CMC. Special thank also goes also to Russ Housley and Tomas 987 Gustavsson for reviewing and providing valuable suggestions on 988 improving this document. 990 We also thank all reviewers of this document for their valuable 991 feedback. 993 7. References 995 7.1. Normative References 997 [I-D.ietf-lamps-cmp-algorithms] 998 Brockhaus, H., Aschauer, H., Ounsworth, M., and S. Mister, 999 "CMP Algorithms", Work in Progress, Internet-Draft, draft- 1000 ietf-lamps-cmp-algorithms-02, 20 January 2021, 1001 . 1004 [I-D.ietf-lamps-crmf-update-algs] 1005 Housley, R., "Algorithm Requirements Update to the 1006 Internet X.509 Public Key Infrastructure Certificate 1007 Request Message Format (CRMF)", Work in Progress, 1008 Internet-Draft, draft-ietf-lamps-crmf-update-algs-02, 21 1009 December 2020, . 1012 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 1013 Requirement Levels", BCP 14, RFC 2119, 1014 DOI 10.17487/RFC2119, March 1997, 1015 . 1017 [RFC2510] Adams, C. and S. Farrell, "Internet X.509 Public Key 1018 Infrastructure Certificate Management Protocols", 1019 RFC 2510, DOI 10.17487/RFC2510, March 1999, 1020 . 1022 [RFC2985] Nystrom, M. and B. Kaliski, "PKCS #9: Selected Object 1023 Classes and Attribute Types Version 2.0", RFC 2985, 1024 DOI 10.17487/RFC2985, November 2000, 1025 . 1027 [RFC2986] Nystrom, M. and B. Kaliski, "PKCS #10: Certification 1028 Request Syntax Specification Version 1.7", RFC 2986, 1029 DOI 10.17487/RFC2986, November 2000, 1030 . 1032 [RFC4210] Adams, C., Farrell, S., Kause, T., and T. Mononen, 1033 "Internet X.509 Public Key Infrastructure Certificate 1034 Management Protocol (CMP)", RFC 4210, 1035 DOI 10.17487/RFC4210, September 2005, 1036 . 1038 [RFC4211] Schaad, J., "Internet X.509 Public Key Infrastructure 1039 Certificate Request Message Format (CRMF)", RFC 4211, 1040 DOI 10.17487/RFC4211, September 2005, 1041 . 1043 [RFC5280] Cooper, D., Santesson, S., Farrell, S., Boeyen, S., 1044 Housley, R., and W. Polk, "Internet X.509 Public Key 1045 Infrastructure Certificate and Certificate Revocation List 1046 (CRL) Profile", RFC 5280, DOI 10.17487/RFC5280, May 2008, 1047 . 1049 [RFC5652] Housley, R., "Cryptographic Message Syntax (CMS)", STD 70, 1050 RFC 5652, DOI 10.17487/RFC5652, September 2009, 1051 . 1053 [RFC5912] Hoffman, P. and J. Schaad, "New ASN.1 Modules for the 1054 Public Key Infrastructure Using X.509 (PKIX)", RFC 5912, 1055 DOI 10.17487/RFC5912, June 2010, 1056 . 1058 [RFC5958] Turner, S., "Asymmetric Key Packages", RFC 5958, 1059 DOI 10.17487/RFC5958, August 2010, 1060 . 1062 [RFC6402] Schaad, J., "Certificate Management over CMS (CMC) 1063 Updates", RFC 6402, DOI 10.17487/RFC6402, November 2011, 1064 . 1066 [RFC6712] Kause, T. and M. Peylo, "Internet X.509 Public Key 1067 Infrastructure -- HTTP Transfer for the Certificate 1068 Management Protocol (CMP)", RFC 6712, 1069 DOI 10.17487/RFC6712, September 2012, 1070 . 1072 [RFC7299] Housley, R., "Object Identifier Registry for the PKIX 1073 Working Group", RFC 7299, DOI 10.17487/RFC7299, July 2014, 1074 . 1076 [RFC8174] Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC 1077 2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174, 1078 May 2017, . 1080 [RFC8615] Nottingham, M., "Well-Known Uniform Resource Identifiers 1081 (URIs)", RFC 8615, DOI 10.17487/RFC8615, May 2019, 1082 . 1084 7.2. Informative References 1086 [I-D.ietf-lamps-lightweight-cmp-profile] 1087 Brockhaus, H., Fries, S., and D. V. Oheimb, "Lightweight 1088 CMP Profile", Work in Progress, Internet-Draft, draft- 1089 ietf-lamps-lightweight-cmp-profile-04, 2 November 2020, 1090 . 1093 [IEEE.802.1AR_2018] 1094 IEEE, "IEEE Standard for Local and metropolitan area 1095 networks - Secure Device Identity", IEEE 802.1AR-2018, 1096 DOI 10.1109/IEEESTD.2018.8423794, 2 August 2018, 1097 . 1099 Appendix A. ASN.1 Modules 1100 A.1. 1988 ASN.1 Module 1102 This section contains the updated ASN.1 module for [RFC4210]. This 1103 module replaces the module in Appendix F of that document. Although 1104 a 2002 ASN.1 module is provided, this 1988 ASN.1 module remains the 1105 normative module as per the policy of the PKIX working group. 1107 PKIXCMP {iso(1) identified-organization(3) 1108 dod(6) internet(1) security(5) mechanisms(5) pkix(7) 1109 id-mod(0) id-mod-cmp2021-88(TBD1)} 1111 DEFINITIONS EXPLICIT TAGS ::= 1113 BEGIN 1115 -- EXPORTS ALL -- 1117 IMPORTS 1119 Certificate, CertificateList, Extensions, AlgorithmIdentifier, 1120 UTF8String, id-kp -- if required; otherwise, comment out 1121 FROM PKIX1Explicit88 {iso(1) identified-organization(3) 1122 dod(6) internet(1) security(5) mechanisms(5) pkix(7) 1123 id-mod(0) id-pkix1-explicit-88(1)} 1125 GeneralName, KeyIdentifier 1126 FROM PKIX1Implicit88 {iso(1) identified-organization(3) 1127 dod(6) internet(1) security(5) mechanisms(5) pkix(7) 1128 id-mod(0) id-pkix1-implicit-88(2)} 1130 CertTemplate, PKIPublicationInfo, EncryptedKey, CertId, 1131 CertReqMessages, Controls, id-regCtrl 1132 FROM PKIXCRMF-2005 {iso(1) identified-organization(3) 1133 dod(6) internet(1) security(5) mechanisms(5) pkix(7) 1134 id-mod(0) id-mod-crmf2005(36)} 1135 -- The import of EncryptedKey is added due to the updates made 1136 -- in CMP Updates [thisRFC]]. EncryptedValue does not need to 1137 -- be imported anymore and is therefore removed here. 1139 -- see also the behavioral clarifications to CRMF codified in 1140 -- Appendix C of this specification 1141 CertificationRequest 1142 FROM PKCS-10 {iso(1) member-body(2) 1143 us(840) rsadsi(113549) 1144 pkcs(1) pkcs-10(10) modules(1) pkcs-10(1)} 1145 -- (specified in RFC 2986 with 1993 ASN.1 syntax and IMPLICIT 1146 -- tags). Alternatively, implementers may directly include 1147 -- the [PKCS10] syntax in this module 1149 localKeyId 1150 FROM PKCS-9 {iso(1) member-body(2) us(840) rsadsi(113549) 1151 pkcs(1) pkcs-9(9) modules(0) pkcs-9(1)} 1152 -- The import of localKeyId is added due to the updates made in 1153 -- CMP Updates [thisRFC] 1155 EnvelopedData, SignedData 1156 FROM CryptographicMessageSyntax2004 { iso(1) 1157 member-body(2) us(840) rsadsi(113549) pkcs(1) pkcs-9(9) 1158 smime(16) modules(0) cms-2004(24) } 1159 -- The import of EnvelopedData and SignedData is added due to 1160 -- the updates made in CMP Updates [thisRFC] 1162 ; 1164 -- the rest of the module contains locally-defined OIDs and 1165 -- constructs 1167 CMPCertificate ::= CHOICE { 1168 x509v3PKCert Certificate 1169 } 1170 -- This syntax, while bits-on-the-wire compatible with the 1171 -- standard X.509 definition of "Certificate", allows the 1172 -- possibility of future certificate types (such as X.509 1173 -- attribute certificates, WAP WTLS certificates, or other kinds 1174 -- of certificates) within this certificate management protocol, 1175 -- should a need ever arise to support such generality. Those 1176 -- implementations that do not foresee a need to ever support 1177 -- other certificate types MAY, if they wish, comment out the 1178 -- above structure and "un-comment" the following one prior to 1179 -- compiling this ASN.1 module. (Note that interoperability 1180 -- with implementations that don't do this will be unaffected by 1181 -- this change.) 1183 -- CMPCertificate ::= Certificate 1185 PKIMessage ::= SEQUENCE { 1186 header PKIHeader, 1187 body PKIBody, 1188 protection [0] PKIProtection OPTIONAL, 1189 extraCerts [1] SEQUENCE SIZE (1..MAX) OF CMPCertificate 1190 OPTIONAL 1191 } 1193 PKIMessages ::= SEQUENCE SIZE (1..MAX) OF PKIMessage 1194 PKIHeader ::= SEQUENCE { 1195 pvno INTEGER { cmp1999(1), cmp2000(2), 1196 cmp2021(3) }, 1197 sender GeneralName, 1198 -- identifies the sender 1199 recipient GeneralName, 1200 -- identifies the intended recipient 1201 messageTime [0] GeneralizedTime OPTIONAL, 1202 -- time of production of this message (used when sender 1203 -- believes that the transport will be "suitable"; i.e., 1204 -- that the time will still be meaningful upon receipt) 1205 protectionAlg [1] AlgorithmIdentifier OPTIONAL, 1206 -- algorithm used for calculation of protection bits 1207 senderKID [2] KeyIdentifier OPTIONAL, 1208 recipKID [3] KeyIdentifier OPTIONAL, 1209 -- to identify specific keys used for protection 1210 transactionID [4] OCTET STRING OPTIONAL, 1211 -- identifies the transaction; i.e., this will be the same in 1212 -- corresponding request, response, certConf, and PKIConf 1213 -- messages 1214 senderNonce [5] OCTET STRING OPTIONAL, 1215 recipNonce [6] OCTET STRING OPTIONAL, 1216 -- nonces used to provide replay protection, senderNonce 1217 -- is inserted by the creator of this message; recipNonce 1218 -- is a nonce previously inserted in a related message by 1219 -- the intended recipient of this message 1220 freeText [7] PKIFreeText OPTIONAL, 1221 -- this may be used to indicate context-specific instructions 1222 -- (this field is intended for human consumption) 1223 generalInfo [8] SEQUENCE SIZE (1..MAX) OF 1224 InfoTypeAndValue OPTIONAL 1225 -- this may be used to convey context-specific information 1226 -- (this field not primarily intended for human consumption) 1227 } 1229 PKIFreeText ::= SEQUENCE SIZE (1..MAX) OF UTF8String 1230 -- text encoded as UTF-8 String [RFC3629] (note: each 1231 -- UTF8String MAY include an [RFC3066] language tag 1232 -- to indicate the language of the contained text 1233 -- see [RFC2482] for details) 1235 PKIBody ::= CHOICE { -- message-specific body elements 1236 ir [0] CertReqMessages, --Initialization Request 1237 ip [1] CertRepMessage, --Initialization Response 1238 cr [2] CertReqMessages, --Certification Request 1239 cp [3] CertRepMessage, --Certification Response 1240 p10cr [4] CertificationRequest, --imported from [PKCS10] 1241 popdecc [5] POPODecKeyChallContent, --pop Challenge 1242 popdecr [6] POPODecKeyRespContent, --pop Response 1243 kur [7] CertReqMessages, --Key Update Request 1244 kup [8] CertRepMessage, --Key Update Response 1245 krr [9] CertReqMessages, --Key Recovery Request 1246 krp [10] KeyRecRepContent, --Key Recovery Response 1247 rr [11] RevReqContent, --Revocation Request 1248 rp [12] RevRepContent, --Revocation Response 1249 ccr [13] CertReqMessages, --Cross-Cert. Request 1250 ccp [14] CertRepMessage, --Cross-Cert. Response 1251 ckuann [15] CAKeyUpdAnnContent, --CA Key Update Ann. 1252 cann [16] CertAnnContent, --Certificate Ann. 1253 rann [17] RevAnnContent, --Revocation Ann. 1254 crlann [18] CRLAnnContent, --CRL Announcement 1255 pkiconf [19] PKIConfirmContent, --Confirmation 1256 nested [20] NestedMessageContent, --Nested Message 1257 genm [21] GenMsgContent, --General Message 1258 genp [22] GenRepContent, --General Response 1259 error [23] ErrorMsgContent, --Error Message 1260 certConf [24] CertConfirmContent, --Certificate confirm 1261 pollReq [25] PollReqContent, --Polling request 1262 pollRep [26] PollRepContent --Polling response 1263 } 1265 PKIProtection ::= BIT STRING 1267 ProtectedPart ::= SEQUENCE { 1268 header PKIHeader, 1269 body PKIBody 1270 } 1272 id-PasswordBasedMac OBJECT IDENTIFIER ::= {1 2 840 113533 7 66 13} 1273 PBMParameter ::= SEQUENCE { 1274 salt OCTET STRING, 1275 -- note: implementations MAY wish to limit acceptable sizes 1276 -- of this string to values appropriate for their environment 1277 -- in order to reduce the risk of denial-of-service attacks 1278 owf AlgorithmIdentifier, 1279 -- AlgId for a One-Way Function (SHA-1 recommended) 1280 iterationCount INTEGER, 1281 -- number of times the OWF is applied 1282 -- note: implementations MAY wish to limit acceptable sizes 1283 -- of this integer to values appropriate for their environment 1284 -- in order to reduce the risk of denial-of-service attacks 1285 mac AlgorithmIdentifier 1286 -- the MAC AlgId (e.g., DES-MAC, Triple-DES-MAC [PKCS11], 1287 } -- or HMAC [RFC2104, RFC2202]) 1289 id-DHBasedMac OBJECT IDENTIFIER ::= {1 2 840 113533 7 66 30} 1290 DHBMParameter ::= SEQUENCE { 1291 owf AlgorithmIdentifier, 1292 -- AlgId for a One-Way Function (SHA-1 recommended) 1293 mac AlgorithmIdentifier 1294 -- the MAC AlgId (e.g., DES-MAC, Triple-DES-MAC [PKCS11], 1295 } -- or HMAC [RFC2104, RFC2202]) 1297 NestedMessageContent ::= PKIMessages 1299 PKIStatus ::= INTEGER { 1300 accepted (0), 1301 -- you got exactly what you asked for 1302 grantedWithMods (1), 1303 -- you got something like what you asked for; the 1304 -- requester is responsible for ascertaining the differences 1305 rejection (2), 1306 -- you don't get it, more information elsewhere in the message 1307 waiting (3), 1308 -- the request body part has not yet been processed; expect to 1309 -- hear more later (note: proper handling of this status 1310 -- response MAY use the polling req/rep PKIMessages specified 1311 -- in Section 5.3.22; alternatively, polling in the underlying 1312 -- transport layer MAY have some utility in this regard) 1313 revocationWarning (4), 1314 -- this message contains a warning that a revocation is 1315 -- imminent 1316 revocationNotification (5), 1317 -- notification that a revocation has occurred 1318 keyUpdateWarning (6) 1319 -- update already done for the oldCertId specified in 1320 -- CertReqMsg 1321 } 1323 PKIFailureInfo ::= BIT STRING { 1324 -- since we can fail in more than one way! 1325 -- More codes may be added in the future if/when required. 1326 badAlg (0), 1327 -- unrecognized or unsupported Algorithm Identifier 1328 badMessageCheck (1), 1329 -- integrity check failed (e.g., signature did not verify) 1330 badRequest (2), 1331 -- transaction not permitted or supported 1332 badTime (3), 1333 -- messageTime was not sufficiently close to the system time, 1334 -- as defined by local policy 1335 badCertId (4), 1336 -- no certificate could be found matching the provided criteria 1337 badDataFormat (5), 1338 -- the data submitted has the wrong format 1339 wrongAuthority (6), 1340 -- the authority indicated in the request is different from the 1341 -- one creating the response token 1342 incorrectData (7), 1343 -- the requester's data is incorrect (for notary services) 1344 missingTimeStamp (8), 1345 -- when the timestamp is missing but should be there 1346 -- (by policy) 1347 badPOP (9), 1348 -- the proof-of-possession failed 1349 certRevoked (10), 1350 -- the certificate has already been revoked 1351 certConfirmed (11), 1352 -- the certificate has already been confirmed 1353 wrongIntegrity (12), 1354 -- invalid integrity, password based instead of signature or 1355 -- vice versa 1356 badRecipientNonce (13), 1357 -- invalid recipient nonce, either missing or wrong value 1358 timeNotAvailable (14), 1359 -- the TSA's time source is not available 1360 unacceptedPolicy (15), 1361 -- the requested TSA policy is not supported by the TSA. 1362 unacceptedExtension (16), 1363 -- the requested extension is not supported by the TSA. 1364 addInfoNotAvailable (17), 1365 -- the additional information requested could not be 1366 -- understood or is not available 1367 badSenderNonce (18), 1368 -- invalid sender nonce, either missing or wrong size 1369 badCertTemplate (19), 1370 -- invalid cert. template or missing mandatory information 1371 signerNotTrusted (20), 1372 -- signer of the message unknown or not trusted 1373 transactionIdInUse (21), 1374 -- the transaction identifier is already in use 1375 unsupportedVersion (22), 1376 -- the version of the message is not supported 1377 notAuthorized (23), 1378 -- the sender was not authorized to make the preceding 1379 -- request or perform the preceding action 1380 systemUnavail (24), 1381 -- the request cannot be handled due to system unavailability 1382 systemFailure (25), 1383 -- the request cannot be handled due to system failure 1384 duplicateCertReq (26) 1385 -- certificate cannot be issued because a duplicate 1386 -- certificate already exists 1387 } 1389 PKIStatusInfo ::= SEQUENCE { 1390 status PKIStatus, 1391 statusString PKIFreeText OPTIONAL, 1392 failInfo PKIFailureInfo OPTIONAL 1393 } 1395 OOBCert ::= CMPCertificate 1397 OOBCertHash ::= SEQUENCE { 1398 hashAlg [0] AlgorithmIdentifier OPTIONAL, 1399 certId [1] CertId OPTIONAL, 1400 hashVal BIT STRING 1401 -- hashVal is calculated over the DER encoding of the 1402 -- self-signed certificate with the identifier certID. 1403 } 1405 POPODecKeyChallContent ::= SEQUENCE OF Challenge 1406 -- One Challenge per encryption key certification request (in the 1407 -- same order as these requests appear in CertReqMessages). 1409 Challenge ::= SEQUENCE { 1410 owf AlgorithmIdentifier OPTIONAL, 1411 -- MUST be present in the first Challenge; MAY be omitted in 1412 -- any subsequent Challenge in POPODecKeyChallContent (if 1413 -- omitted, then the owf used in the immediately preceding 1414 -- Challenge is to be used). 1415 witness OCTET STRING, 1416 -- the result of applying the one-way function (owf) to a 1417 -- randomly-generated INTEGER, A. [Note that a different 1418 -- INTEGER MUST be used for each Challenge.] 1419 challenge OCTET STRING 1420 -- the encryption (under the public key for which the cert. 1421 -- request is being made) of Rand. 1422 } 1424 -- Added in CMP Updates [thisRFC] 1426 Rand ::= SEQUENCE { 1427 -- Rand is encrypted under the public key to form the challenge 1428 -- in POPODecKeyChallContent 1429 int INTEGER, 1430 -- the randomly-generated INTEGER A (above) 1431 sender GeneralName 1432 -- the sender's name (as included in PKIHeader) 1434 } 1436 POPODecKeyRespContent ::= SEQUENCE OF INTEGER 1437 -- One INTEGER per encryption key certification request (in the 1438 -- same order as these requests appear in CertReqMessages). The 1439 -- retrieved INTEGER A (above) is returned to the sender of the 1440 -- corresponding Challenge. 1442 CertRepMessage ::= SEQUENCE { 1443 caPubs [1] SEQUENCE SIZE (1..MAX) OF CMPCertificate 1444 OPTIONAL, 1445 response SEQUENCE OF CertResponse 1446 } 1448 CertResponse ::= SEQUENCE { 1449 certReqId INTEGER, 1450 -- to match this response with corresponding request (a value 1451 -- of 0 is to be used if certReqId is not specified in the 1452 -- corresponding request, which can only be a p10cr) 1453 status PKIStatusInfo, 1454 certifiedKeyPair CertifiedKeyPair OPTIONAL, 1455 rspInfo OCTET STRING OPTIONAL 1456 -- analogous to the id-regInfo-utf8Pairs string defined 1457 -- for regInfo in CertReqMsg [CRMF] 1458 } 1460 CertifiedKeyPair ::= SEQUENCE { 1461 certOrEncCert CertOrEncCert, 1462 privateKey [0] EncryptedKey OPTIONAL, 1463 -- see [CRMF] for comment on encoding 1464 -- Changed from Encrypted Value to EncryptedKey as a CHOICE of 1465 -- EncryptedValue and EnvelopedData due to the changes made in 1466 -- CMP Updates [thisRFC] 1467 -- Using the choice EncryptedValue is bit-compatible to the 1468 -- syntax without this change 1469 publicationInfo [1] PKIPublicationInfo OPTIONAL 1470 } 1472 CertOrEncCert ::= CHOICE { 1473 certificate [0] CMPCertificate, 1474 encryptedCert [1] EncryptedKey 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 } 1481 KeyRecRepContent ::= SEQUENCE { 1482 status PKIStatusInfo, 1483 newSigCert [0] CMPCertificate OPTIONAL, 1484 caCerts [1] SEQUENCE SIZE (1..MAX) OF 1485 CMPCertificate OPTIONAL, 1486 keyPairHist [2] SEQUENCE SIZE (1..MAX) OF 1487 CertifiedKeyPair OPTIONAL 1488 } 1490 RevReqContent ::= SEQUENCE OF RevDetails 1492 RevDetails ::= SEQUENCE { 1493 certDetails CertTemplate, 1494 -- allows requester to specify as much as they can about 1495 -- the cert. for which revocation is requested 1496 -- (e.g., for cases in which serialNumber is not available) 1497 crlEntryDetails Extensions OPTIONAL 1498 -- requested crlEntryExtensions 1499 } 1501 RevRepContent ::= SEQUENCE { 1502 status SEQUENCE SIZE (1..MAX) OF PKIStatusInfo, 1503 -- in same order as was sent in RevReqContent 1504 revCerts [0] SEQUENCE SIZE (1..MAX) OF CertId 1505 OPTIONAL, 1506 -- IDs for which revocation was requested 1507 -- (same order as status) 1508 crls [1] SEQUENCE SIZE (1..MAX) OF CertificateList 1509 OPTIONAL 1510 -- the resulting CRLs (there may be more than one) 1511 } 1513 CAKeyUpdAnnContent ::= SEQUENCE { 1514 oldWithNew CMPCertificate, -- old pub signed with new priv 1515 newWithOld CMPCertificate, -- new pub signed with old priv 1516 newWithNew CMPCertificate -- new pub signed with new priv 1517 } 1519 CertAnnContent ::= CMPCertificate 1521 RevAnnContent ::= SEQUENCE { 1522 status PKIStatus, 1523 certId CertId, 1524 willBeRevokedAt GeneralizedTime, 1525 badSinceDate GeneralizedTime, 1526 crlDetails Extensions OPTIONAL 1527 -- extra CRL details (e.g., crl number, reason, location, etc.) 1528 } 1529 CRLAnnContent ::= SEQUENCE OF CertificateList 1531 CertConfirmContent ::= SEQUENCE OF CertStatus 1533 CertStatus ::= SEQUENCE { 1534 certHash OCTET STRING, 1535 -- the hash of the certificate, using the same hash algorithm 1536 -- as is used to create and verify the certificate signature 1537 certReqId INTEGER, 1538 -- to match this confirmation with the corresponding req/rep 1539 statusInfo PKIStatusInfo OPTIONAL 1540 } 1542 PKIConfirmContent ::= NULL 1544 -- Added in CMP Updates [thisRFC] 1546 RootCaKeyUpdateContent ::= SEQUENCE { 1547 newWithNew CMPCertificate 1548 -- new root CA certificate 1549 newWithOld [0] CMPCertificate OPTIONAL, 1550 -- X.509 certificate containing the new public root CA key 1551 -- signed with the old private root CA key 1552 oldWithNew [1] CMPCertificate OPTIONAL 1553 -- X.509 certificate containing the old public root CA key 1554 -- signed with the new private root CA key 1555 } 1557 -- Added in CMP Updates [thisRFC] 1559 CertReqTemplateContent ::= SEQUENCE { 1560 certTemplate CertTemplate, 1561 -- prefilled certTemplate structure elements 1562 -- The SubjectPublicKeyInfo field in the certTemplate MUST NOT 1563 -- be used. 1564 keySpec Controls OPTIONAL 1565 -- MAY be used to specify supported algorithms. 1566 -- Controls ::= SEQUENCE SIZE(1..MAX) OF AttributeTypeAndValue 1567 -- as specified in CRMF (RFC4211) 1568 } 1570 id-regCtrl-algId OBJECT IDENTIFIER ::= { id-regCtrl TBD3 } 1571 AlgIdCtrl ::= AlgorithmIdentifier 1572 -- SHALL be used to specify suported algorithms other than RSA 1574 id-regCtrl-rsaKeyLen OBJECT IDENTIFIER ::= { id-regCtrl TBD4 } 1575 RsaKeyLenCtrl ::= Integer 1576 -- SHALL be used to specify suported RSA key lengths 1578 InfoTypeAndValue ::= SEQUENCE { 1579 infoType OBJECT IDENTIFIER, 1580 infoValue ANY DEFINED BY infoType OPTIONAL 1581 } 1582 -- Example InfoTypeAndValue contents include, but are not limited 1583 -- to, the following (un-comment in this ASN.1 module and use as 1584 -- appropriate for a given environment): 1585 -- 1586 -- id-it-caProtEncCert OBJECT IDENTIFIER ::= {id-it 1} 1587 -- CAProtEncCertValue ::= CMPCertificate 1588 -- id-it-signKeyPairTypes OBJECT IDENTIFIER ::= {id-it 2} 1589 -- SignKeyPairTypesValue ::= SEQUENCE OF AlgorithmIdentifier 1590 -- id-it-encKeyPairTypes OBJECT IDENTIFIER ::= {id-it 3} 1591 -- EncKeyPairTypesValue ::= SEQUENCE OF AlgorithmIdentifier 1592 -- id-it-preferredSymmAlg OBJECT IDENTIFIER ::= {id-it 4} 1593 -- PreferredSymmAlgValue ::= AlgorithmIdentifier 1594 -- id-it-caKeyUpdateInfo OBJECT IDENTIFIER ::= {id-it 5} 1595 -- CAKeyUpdateInfoValue ::= CAKeyUpdAnnContent 1596 -- id-it-currentCRL OBJECT IDENTIFIER ::= {id-it 6} 1597 -- CurrentCRLValue ::= CertificateList 1598 -- id-it-unsupportedOIDs OBJECT IDENTIFIER ::= {id-it 7} 1599 -- UnsupportedOIDsValue ::= SEQUENCE OF OBJECT IDENTIFIER 1600 -- id-it-keyPairParamReq OBJECT IDENTIFIER ::= {id-it 10} 1601 -- KeyPairParamReqValue ::= OBJECT IDENTIFIER 1602 -- id-it-keyPairParamRep OBJECT IDENTIFIER ::= {id-it 11} 1603 -- KeyPairParamRepValue ::= AlgorithmIdentifer 1604 -- id-it-revPassphrase OBJECT IDENTIFIER ::= {id-it 12} 1605 -- RevPassphraseValue ::= EncryptedKey 1606 -- -- Changed from Encrypted Value to EncryptedKey as a CHOICE 1607 -- -- of EncryptedValue and EnvelopedData due to the changes 1608 -- -- made in CMP Updates [thisRFC] 1609 -- -- Using the choice EncryptedValue is bit-compatible to the 1610 -- -- syntax without this change 1611 -- id-it-implicitConfirm OBJECT IDENTIFIER ::= {id-it 13} 1612 -- ImplicitConfirmValue ::= NULL 1613 -- id-it-confirmWaitTime OBJECT IDENTIFIER ::= {id-it 14} 1614 -- ConfirmWaitTimeValue ::= GeneralizedTime 1615 -- id-it-origPKIMessage OBJECT IDENTIFIER ::= {id-it 15} 1616 -- OrigPKIMessageValue ::= PKIMessages 1617 -- id-it-suppLangTags OBJECT IDENTIFIER ::= {id-it 16} 1618 -- SuppLangTagsValue ::= SEQUENCE OF UTF8String 1619 -- id-it-caCerts OBJECT IDENTIFIER ::= { id-it 17} 1620 -- CaCertsValue ::= SEQUENCE OF CMPCertificate 1621 -- -- id-it-caCerts added in CMP Updates [thisRFC] 1622 -- id-it-rootCaKeyUpdate OBJECT IDENTIFIER ::= { id-it 18} 1623 -- RootCaKeyUpdateValue ::= RootCaKeyUpdateContent 1624 -- -- id-it-rootCaKeyUpdate added in CMP Updates [thisRFC] 1625 -- id-it-certReqTemplate OBJECT IDENTIFIER ::= { id-it 19} 1626 -- CertReqTemplateValue ::= CertReqTemplateContent 1627 -- -- id-it-certReqTemplate added in CMP Updates [thisRFC] 1628 -- 1629 -- where 1630 -- 1631 -- id-pkix OBJECT IDENTIFIER ::= { 1632 -- iso(1) identified-organization(3) 1633 -- dod(6) internet(1) security(5) mechanisms(5) pkix(7)} 1634 -- and 1635 -- id-it OBJECT IDENTIFIER ::= {id-pkix 4} 1636 -- 1637 -- 1638 -- This construct MAY also be used to define new PKIX Certificate 1639 -- Management Protocol request and response messages, or general- 1640 -- purpose (e.g., announcement) messages for future needs or for 1641 -- specific environments. 1643 GenMsgContent ::= SEQUENCE OF InfoTypeAndValue 1645 -- May be sent by EE, RA, or CA (depending on message content). 1646 -- The OPTIONAL infoValue parameter of InfoTypeAndValue will 1647 -- typically be omitted for some of the examples given above. 1648 -- The receiver is free to ignore any contained OBJ. IDs that it 1649 -- does not recognize. If sent from EE to CA, the empty set 1650 -- indicates that the CA may send 1651 -- any/all information that it wishes. 1653 GenRepContent ::= SEQUENCE OF InfoTypeAndValue 1654 -- Receiver MAY ignore any contained OIDs that it does not 1655 -- recognize. 1657 ErrorMsgContent ::= SEQUENCE { 1658 pKIStatusInfo PKIStatusInfo, 1659 errorCode INTEGER OPTIONAL, 1660 -- implementation-specific error codes 1661 errorDetails PKIFreeText OPTIONAL 1662 -- implementation-specific error details 1663 } 1665 PollReqContent ::= SEQUENCE OF SEQUENCE { 1666 certReqId INTEGER 1667 } 1669 PollRepContent ::= SEQUENCE OF SEQUENCE { 1670 certReqId INTEGER, 1671 checkAfter INTEGER, -- time in seconds 1672 reason PKIFreeText OPTIONAL 1673 } 1674 -- 1675 -- Extended Key Usage extension for PKI entities used in CMP 1676 -- operations, added due to the changes made in 1677 -- CMP Updates [thisRFC] 1678 -- The EKUs for the CA and RA are reused from CMC as defined in 1679 -- [RFC6402] 1680 -- 1682 -- id-kp-cmcCA OBJECT IDENTIFIER ::= { id-kp 27 } 1683 -- id-kp-cmcRA OBJECT IDENTIFIER ::= { id-kp 28 } 1684 id-kp-cmKGA OBJECT IDENTIFIER ::= { id-kp 32 } 1686 END -- of CMP module 1688 A.2. 2002 ASN.1 Module 1690 This section contains the updated 2002 ASN.1 module for [RFC5912]. 1691 This module replaces the module in Section 9 of that document. The 1692 module contains those changes to the normative ASN.1 module from 1693 RFC4210 Appendix F [RFC4210] that were to update to 2002 ASN.1 1694 standard done in [RFC5912] as well as changes made in this document. 1696 PKIXCMP-2009 1697 { iso(1) identified-organization(3) dod(6) internet(1) 1698 security(5) mechanisms(5) pkix(7) id-mod(0) 1699 id-mod-cmp2021-02(TBD2) } 1700 DEFINITIONS EXPLICIT TAGS ::= 1701 BEGIN 1702 IMPORTS 1704 AttributeSet{}, Extensions{}, EXTENSION, ATTRIBUTE 1705 FROM PKIX-CommonTypes-2009 1706 {iso(1) identified-organization(3) dod(6) internet(1) security(5) 1707 mechanisms(5) pkix(7) id-mod(0) id-mod-pkixCommon-02(57)} 1709 AlgorithmIdentifier{}, SIGNATURE-ALGORITHM, ALGORITHM, 1710 DIGEST-ALGORITHM, MAC-ALGORITHM 1711 FROM AlgorithmInformation-2009 1712 {iso(1) identified-organization(3) dod(6) internet(1) security(5) 1713 mechanisms(5) pkix(7) id-mod(0) 1714 id-mod-algorithmInformation-02(58)} 1716 Certificate, CertificateList, id-kp 1717 FROM PKIX1Explicit-2009 1718 {iso(1) identified-organization(3) dod(6) internet(1) security(5) 1719 mechanisms(5) pkix(7) id-mod(0) id-mod-pkix1-explicit-02(51)} 1721 GeneralName, KeyIdentifier 1722 FROM PKIX1Implicit-2009 1723 {iso(1) identified-organization(3) dod(6) internet(1) security(5) 1724 mechanisms(5) pkix(7) id-mod(0) id-mod-pkix1-implicit-02(59)} 1726 CertTemplate, PKIPublicationInfo, EncryptedKey, CertId, 1727 CertReqMessages, Controls, id-regCtrl 1728 FROM PKIXCRMF-2009 1729 { iso(1) identified-organization(3) dod(6) internet(1) 1730 security(5) mechanisms(5) pkix(7) id-mod(0) 1731 id-mod-crmf2005-02(55) } 1732 -- The import of EncryptedKey is added due to the updates made 1733 -- in CMP Updates [thisRFC]. EncryptedValue does not need to 1734 -- be imported anymore and is therefore removed here. 1736 -- see also the behavioral clarifications to CRMF codified in 1737 -- Appendix C of this specification 1739 CertificationRequest 1740 FROM PKCS-10 1741 {iso(1) identified-organization(3) dod(6) internet(1) security(5) 1742 mechanisms(5) pkix(7) id-mod(0) id-mod-pkcs10-2009(69)} 1743 -- (specified in RFC 2986 with 1993 ASN.1 syntax and IMPLICIT 1744 -- tags). Alternatively, implementers may directly include 1745 -- the [PKCS10] syntax in this module 1747 localKeyId 1748 FROM PKCS-9 1749 {iso(1) member-body(2) us(840) rsadsi(113549) pkcs(1) pkcs-9(9) 1750 modules(0) pkcs-9(1)} 1751 -- The import of localKeyId is added due to the updates made in 1752 -- CMP Updates [thisRFC] 1754 EnvelopedData, SignedData 1755 FROM CryptographicMessageSyntax-2009 1756 {iso(1) member-body(2) us(840) rsadsi(113549) pkcs(1) pkcs-9(9) 1757 smime(16) modules(0) id-mod-cms-2004-02(41)} 1758 -- The import of EnvelopedData and SignedData is added due to 1759 -- the updates made in CMP Updates [thisRFC] 1760 ; 1762 -- the rest of the module contains locally defined OIDs and 1763 -- constructs 1765 CMPCertificate ::= CHOICE { x509v3PKCert Certificate, ... } 1766 -- This syntax, while bits-on-the-wire compatible with the 1767 -- standard X.509 definition of "Certificate", allows the 1768 -- possibility of future certificate types (such as X.509 1769 -- attribute certificates, WAP WTLS certificates, or other kinds 1770 -- of certificates) within this certificate management protocol, 1771 -- should a need ever arise to support such generality. Those 1772 -- implementations that do not foresee a need to ever support 1773 -- other certificate types MAY, if they wish, comment out the 1774 -- above structure and "uncomment" the following one prior to 1775 -- compiling this ASN.1 module. (Note that interoperability 1776 -- with implementations that don't do this will be unaffected by 1777 -- this change.) 1779 -- CMPCertificate ::= Certificate 1781 PKIMessage ::= SEQUENCE { 1782 header PKIHeader, 1783 body PKIBody, 1784 protection [0] PKIProtection OPTIONAL, 1785 extraCerts [1] SEQUENCE SIZE (1..MAX) OF CMPCertificate 1786 OPTIONAL } 1788 PKIMessages ::= SEQUENCE SIZE (1..MAX) OF PKIMessage 1790 PKIHeader ::= SEQUENCE { 1791 pvno INTEGER { cmp1999(1), cmp2000(2), 1792 cmp2012(3) }, 1793 sender GeneralName, 1794 -- identifies the sender 1795 recipient GeneralName, 1796 -- identifies the intended recipient 1797 messageTime [0] GeneralizedTime OPTIONAL, 1798 -- time of production of this message (used when sender 1799 -- believes that the transport will be "suitable"; i.e., 1800 -- that the time will still be meaningful upon receipt) 1801 protectionAlg [1] AlgorithmIdentifier{ALGORITHM, {...}} 1802 OPTIONAL, 1803 -- algorithm used for calculation of protection bits 1804 senderKID [2] KeyIdentifier OPTIONAL, 1805 recipKID [3] KeyIdentifier OPTIONAL, 1806 -- to identify specific keys used for protection 1807 transactionID [4] OCTET STRING OPTIONAL, 1808 -- identifies the transaction; i.e., this will be the same in 1809 -- corresponding request, response, certConf, and PKIConf 1810 -- messages 1811 senderNonce [5] OCTET STRING OPTIONAL, 1812 recipNonce [6] OCTET STRING OPTIONAL, 1813 -- nonces used to provide replay protection, senderNonce 1814 -- is inserted by the creator of this message; recipNonce 1815 -- is a nonce previously inserted in a related message by 1816 -- the intended recipient of this message 1817 freeText [7] PKIFreeText OPTIONAL, 1818 -- this may be used to indicate context-specific instructions 1819 -- (this field is intended for human consumption) 1820 generalInfo [8] SEQUENCE SIZE (1..MAX) OF 1821 InfoTypeAndValue OPTIONAL 1822 -- this may be used to convey context-specific information 1823 -- (this field not primarily intended for human consumption) 1824 } 1826 PKIFreeText ::= SEQUENCE SIZE (1..MAX) OF UTF8String 1827 -- text encoded as UTF-8 String [RFC3629] (note: each 1828 -- UTF8String MAY include an [RFC3066] language tag 1829 -- to indicate the language of the contained text; 1830 -- see [RFC2482] for details) 1832 PKIBody ::= CHOICE { -- message-specific body elements 1833 ir [0] CertReqMessages, --Initialization Request 1834 ip [1] CertRepMessage, --Initialization Response 1835 cr [2] CertReqMessages, --Certification Request 1836 cp [3] CertRepMessage, --Certification Response 1837 p10cr [4] CertificationRequest, --imported from [PKCS10] 1838 popdecc [5] POPODecKeyChallContent, --pop Challenge 1839 popdecr [6] POPODecKeyRespContent, --pop Response 1840 kur [7] CertReqMessages, --Key Update Request 1841 kup [8] CertRepMessage, --Key Update Response 1842 krr [9] CertReqMessages, --Key Recovery Request 1843 krp [10] KeyRecRepContent, --Key Recovery Response 1844 rr [11] RevReqContent, --Revocation Request 1845 rp [12] RevRepContent, --Revocation Response 1846 ccr [13] CertReqMessages, --Cross-Cert. Request 1847 ccp [14] CertRepMessage, --Cross-Cert. Response 1848 ckuann [15] CAKeyUpdAnnContent, --CA Key Update Ann. 1849 cann [16] CertAnnContent, --Certificate Ann. 1850 rann [17] RevAnnContent, --Revocation Ann. 1851 crlann [18] CRLAnnContent, --CRL Announcement 1852 pkiconf [19] PKIConfirmContent, --Confirmation 1853 nested [20] NestedMessageContent, --Nested Message 1854 genm [21] GenMsgContent, --General Message 1855 genp [22] GenRepContent, --General Response 1856 error [23] ErrorMsgContent, --Error Message 1857 certConf [24] CertConfirmContent, --Certificate confirm 1858 pollReq [25] PollReqContent, --Polling request 1859 pollRep [26] PollRepContent --Polling response 1860 } 1862 PKIProtection ::= BIT STRING 1864 ProtectedPart ::= SEQUENCE { 1865 header PKIHeader, 1866 body PKIBody } 1868 id-PasswordBasedMac OBJECT IDENTIFIER ::= { iso(1) member-body(2) 1869 usa(840) nt(113533) nsn(7) algorithms(66) 13 } 1870 PBMParameter ::= SEQUENCE { 1871 salt OCTET STRING, 1872 -- note: implementations MAY wish to limit acceptable sizes 1873 -- of this string to values appropriate for their environment 1874 -- in order to reduce the risk of denial-of-service attacks 1875 owf AlgorithmIdentifier{DIGEST-ALGORITHM, {...}}, 1876 -- AlgId for a One-Way Function (SHA-1 recommended) 1877 iterationCount INTEGER, 1878 -- number of times the OWF is applied 1879 -- note: implementations MAY wish to limit acceptable sizes 1880 -- of this integer to values appropriate for their environment 1881 -- in order to reduce the risk of denial-of-service attacks 1882 mac AlgorithmIdentifier{MAC-ALGORITHM, {...}} 1883 -- the MAC AlgId (e.g., DES-MAC, Triple-DES-MAC [PKCS11], 1884 -- or HMAC [RFC2104, RFC2202]) 1885 } 1887 id-DHBasedMac OBJECT IDENTIFIER ::= { iso(1) member-body(2) 1888 usa(840) nt(113533) nsn(7) algorithms(66) 30 } 1889 DHBMParameter ::= SEQUENCE { 1890 owf AlgorithmIdentifier{DIGEST-ALGORITHM, {...}}, 1891 -- AlgId for a One-Way Function (SHA-1 recommended) 1892 mac AlgorithmIdentifier{MAC-ALGORITHM, {...}} 1893 -- the MAC AlgId (e.g., DES-MAC, Triple-DES-MAC [PKCS11], 1894 -- or HMAC [RFC2104, RFC2202]) 1895 } 1897 PKIStatus ::= INTEGER { 1898 accepted (0), 1899 -- you got exactly what you asked for 1900 grantedWithMods (1), 1901 -- you got something like what you asked for; the 1902 -- requester is responsible for ascertaining the differences 1903 rejection (2), 1904 -- you don't get it, more information elsewhere in the message 1905 waiting (3), 1906 -- the request body part has not yet been processed; expect to 1907 -- hear more later (note: proper handling of this status 1908 -- response MAY use the polling req/rep PKIMessages specified 1909 -- in Section 5.3.22; alternatively, polling in the underlying 1910 -- transport layer MAY have some utility in this regard) 1911 revocationWarning (4), 1912 -- this message contains a warning that a revocation is 1913 -- imminent 1914 revocationNotification (5), 1915 -- notification that a revocation has occurred 1916 keyUpdateWarning (6) 1917 -- update already done for the oldCertId specified in 1918 -- CertReqMsg 1919 } 1921 PKIFailureInfo ::= BIT STRING { 1922 -- since we can fail in more than one way! 1923 -- More codes may be added in the future if/when required. 1924 badAlg (0), 1925 -- unrecognized or unsupported Algorithm Identifier 1926 badMessageCheck (1), 1927 -- integrity check failed (e.g., signature did not verify) 1928 badRequest (2), 1929 -- transaction not permitted or supported 1930 badTime (3), 1931 -- messageTime was not sufficiently close to the system time, 1932 -- as defined by local policy 1933 badCertId (4), 1934 -- no certificate could be found matching the provided criteria 1935 badDataFormat (5), 1936 -- the data submitted has the wrong format 1937 wrongAuthority (6), 1938 -- the authority indicated in the request is different from the 1939 -- one creating the response token 1940 incorrectData (7), 1941 -- the requester's data is incorrect (for notary services) 1942 missingTimeStamp (8), 1943 -- when the timestamp is missing but should be there 1944 -- (by policy) 1945 badPOP (9), 1946 -- the proof-of-possession failed 1947 certRevoked (10), 1948 -- the certificate has already been revoked 1949 certConfirmed (11), 1950 -- the certificate has already been confirmed 1951 wrongIntegrity (12), 1952 -- invalid integrity, password based instead of signature or 1953 -- vice versa 1954 badRecipientNonce (13), 1955 -- invalid recipient nonce, either missing or wrong value 1956 timeNotAvailable (14), 1957 -- the TSA's time source is not available 1958 unacceptedPolicy (15), 1959 -- the requested TSA policy is not supported by the TSA 1960 unacceptedExtension (16), 1961 -- the requested extension is not supported by the TSA 1962 addInfoNotAvailable (17), 1963 -- the additional information requested could not be 1964 -- understood or is not available 1965 badSenderNonce (18), 1966 -- invalid sender nonce, either missing or wrong size 1967 badCertTemplate (19), 1968 -- invalid cert. template or missing mandatory information 1969 signerNotTrusted (20), 1970 -- signer of the message unknown or not trusted 1971 transactionIdInUse (21), 1972 -- the transaction identifier is already in use 1973 unsupportedVersion (22), 1974 -- the version of the message is not supported 1975 notAuthorized (23), 1976 -- the sender was not authorized to make the preceding 1977 -- request or perform the preceding action 1978 systemUnavail (24), 1979 -- the request cannot be handled due to system unavailability 1980 systemFailure (25), 1981 -- the request cannot be handled due to system failure 1982 duplicateCertReq (26) 1983 -- certificate cannot be issued because a duplicate 1984 -- certificate already exists 1985 } 1987 PKIStatusInfo ::= SEQUENCE { 1988 status PKIStatus, 1989 statusString PKIFreeText OPTIONAL, 1990 failInfo PKIFailureInfo OPTIONAL } 1992 OOBCert ::= CMPCertificate 1994 OOBCertHash ::= SEQUENCE { 1995 hashAlg [0] AlgorithmIdentifier{DIGEST-ALGORITHM, {...}} 1996 OPTIONAL, 1997 certId [1] CertId OPTIONAL, 1998 hashVal BIT STRING 1999 -- hashVal is calculated over the DER encoding of the 2000 -- self-signed certificate with the identifier certID. 2001 } 2003 POPODecKeyChallContent ::= SEQUENCE OF Challenge 2004 -- One Challenge per encryption key certification request (in the 2005 -- same order as these requests appear in CertReqMessages). 2007 Challenge ::= SEQUENCE { 2008 owf AlgorithmIdentifier{DIGEST-ALGORITHM, {...}} 2009 OPTIONAL, 2011 -- MUST be present in the first Challenge; MAY be omitted in 2012 -- any subsequent Challenge in POPODecKeyChallContent (if 2013 -- omitted, then the owf used in the immediately preceding 2014 -- Challenge is to be used). 2015 witness OCTET STRING, 2016 -- the result of applying the one-way function (owf) to a 2017 -- randomly-generated INTEGER, A. [Note that a different 2018 -- INTEGER MUST be used for each Challenge.] 2019 challenge OCTET STRING 2020 -- the encryption (under the public key for which the cert. 2021 -- request is being made) of Rand. 2022 } 2024 -- Added in CMP Updates [thisRFC] 2026 Rand ::= SEQUENCE { 2027 -- Rand is encrypted under the public key to form the challenge 2028 -- in POPODecKeyChallContent 2029 int INTEGER, 2030 -- the randomly-generated INTEGER A (above) 2031 sender GeneralName 2032 -- the sender's name (as included in PKIHeader) 2033 } 2035 POPODecKeyRespContent ::= SEQUENCE OF INTEGER 2036 -- One INTEGER per encryption key certification request (in the 2037 -- same order as these requests appear in CertReqMessages). The 2038 -- retrieved INTEGER A (above) is returned to the sender of the 2039 -- corresponding Challenge. 2041 CertRepMessage ::= SEQUENCE { 2042 caPubs [1] SEQUENCE SIZE (1..MAX) OF CMPCertificate 2043 OPTIONAL, 2044 response SEQUENCE OF CertResponse } 2046 CertResponse ::= SEQUENCE { 2047 certReqId INTEGER, 2048 -- to match this response with the corresponding request (a value 2049 -- of 0 is to be used if certReqId is not specified in the 2050 -- corresponding request, which can only be a p10cr) 2051 status PKIStatusInfo, 2052 certifiedKeyPair CertifiedKeyPair OPTIONAL, 2053 rspInfo OCTET STRING OPTIONAL 2054 -- analogous to the id-regInfo-utf8Pairs string defined 2055 -- for regInfo in CertReqMsg [RFC4211] 2056 } 2058 CertifiedKeyPair ::= SEQUENCE { 2059 certOrEncCert CertOrEncCert, 2060 privateKey [0] EncryptedKey OPTIONAL, 2061 -- see [RFC4211] for comment on encoding 2062 -- Changed from Encrypted Value to EncryptedKey as a CHOICE of 2063 -- EncryptedValue and EnvelopedData due to the changes made in 2064 -- CMP Updates [thisRFC] 2065 -- Using the choice EncryptedValue is bit-compatible to the 2066 -- syntax without this change 2067 publicationInfo [1] PKIPublicationInfo OPTIONAL } 2069 CertOrEncCert ::= CHOICE { 2070 certificate [0] CMPCertificate, 2071 encryptedCert [1] EncryptedKey 2072 -- Changed from Encrypted Value to EncryptedKey as a CHOICE of 2073 -- EncryptedValue and EnvelopedData due to the changes made in 2074 -- CMP Updates [thisRFC] 2075 -- Using the choice EncryptedValue is bit-compatible to the 2076 -- syntax without this change 2077 } 2079 KeyRecRepContent ::= SEQUENCE { 2080 status PKIStatusInfo, 2081 newSigCert [0] CMPCertificate OPTIONAL, 2082 caCerts [1] SEQUENCE SIZE (1..MAX) OF 2083 CMPCertificate OPTIONAL, 2084 keyPairHist [2] SEQUENCE SIZE (1..MAX) OF 2085 CertifiedKeyPair OPTIONAL } 2087 RevReqContent ::= SEQUENCE OF RevDetails 2089 RevDetails ::= SEQUENCE { 2090 certDetails CertTemplate, 2091 -- allows requester to specify as much as they can about 2092 -- the cert. for which revocation is requested 2093 -- (e.g., for cases in which serialNumber is not available) 2094 crlEntryDetails Extensions{{...}} OPTIONAL 2095 -- requested crlEntryExtensions 2096 } 2098 RevRepContent ::= SEQUENCE { 2099 status SEQUENCE SIZE (1..MAX) OF PKIStatusInfo, 2100 -- in same order as was sent in RevReqContent 2101 revCerts [0] SEQUENCE SIZE (1..MAX) OF CertId OPTIONAL, 2102 -- IDs for which revocation was requested 2103 -- (same order as status) 2104 crls [1] SEQUENCE SIZE (1..MAX) OF CertificateList OPTIONAL 2105 -- the resulting CRLs (there may be more than one) 2106 } 2107 CAKeyUpdAnnContent ::= SEQUENCE { 2108 oldWithNew CMPCertificate, -- old pub signed with new priv 2109 newWithOld CMPCertificate, -- new pub signed with old priv 2110 newWithNew CMPCertificate -- new pub signed with new priv 2111 } 2113 CertAnnContent ::= CMPCertificate 2115 RevAnnContent ::= SEQUENCE { 2116 status PKIStatus, 2117 certId CertId, 2118 willBeRevokedAt GeneralizedTime, 2119 badSinceDate GeneralizedTime, 2120 crlDetails Extensions{{...}} OPTIONAL 2121 -- extra CRL details (e.g., crl number, reason, location, etc.) 2122 } 2124 CRLAnnContent ::= SEQUENCE OF CertificateList 2125 PKIConfirmContent ::= NULL 2127 NestedMessageContent ::= PKIMessages 2129 -- Added in CMP Updates [thisRFC] 2131 RootCaKeyUpdateContent ::= SEQUENCE { 2132 newWithNew CMPCertificate 2133 -- new root CA certificate 2134 newWithOld [0] CMPCertificate OPTIONAL, 2135 -- X.509 certificate containing the new public root CA key 2136 -- signed with the old private root CA key 2137 oldWithNew [1] CMPCertificate OPTIONAL 2138 -- X.509 certificate containing the old public root CA key 2139 -- signed with the new private root CA key 2140 } 2142 -- Added in CMP Updates [thisRFC] 2144 CertReqTemplateContent ::= SEQUENCE { 2145 certTemplate CertTemplate, 2146 -- prefilled certTemplate structure elements 2147 -- The SubjectPublicKeyInfo field in the certTemplate MUST NOT 2148 -- be used. 2149 keySpec Controls OPTIONAL 2150 -- MAY be used to specify supported algorithms. 2151 -- Controls ::= SEQUENCE SIZE(1..MAX) OF AttributeTypeAndValue 2152 -- as specified in CRMF (RFC4211) 2153 } 2155 id-regCtrl-algId OBJECT IDENTIFIER ::= { id-regCtrl TBD3 } 2156 AlgIdCtrl ::= AlgorithmIdentifier 2157 -- SHALL be used to specify suported algorithms other than RSA 2159 id-regCtrl-rsaKeyLen OBJECT IDENTIFIER ::= { id-regCtrl TBD4 } 2160 RsaKeyLenCtrl ::= Integer 2161 -- SHALL be used to specify suported RSA key lengths 2163 INFO-TYPE-AND-VALUE ::= TYPE-IDENTIFIER 2165 InfoTypeAndValue ::= SEQUENCE { 2166 infoType INFO-TYPE-AND-VALUE. 2167 &id({SupportedInfoSet}), 2168 infoValue INFO-TYPE-AND-VALUE. 2169 &Type({SupportedInfoSet}{@infoType}) } 2171 SupportedInfoSet INFO-TYPE-AND-VALUE ::= { ... } 2173 -- Example InfoTypeAndValue contents include, but are not limited 2174 -- to, the following (uncomment in this ASN.1 module and use as 2175 -- appropriate for a given environment): 2176 -- 2177 -- id-it-caProtEncCert OBJECT IDENTIFIER ::= {id-it 1} 2178 -- CAProtEncCertValue ::= CMPCertificate 2179 -- id-it-signKeyPairTypes OBJECT IDENTIFIER ::= {id-it 2} 2180 -- SignKeyPairTypesValue ::= SEQUENCE OF 2181 -- AlgorithmIdentifier{{...}} 2182 -- id-it-encKeyPairTypes OBJECT IDENTIFIER ::= {id-it 3} 2183 -- EncKeyPairTypesValue ::= SEQUENCE OF 2184 -- AlgorithmIdentifier{{...}} 2185 -- id-it-preferredSymmAlg OBJECT IDENTIFIER ::= {id-it 4} 2186 -- PreferredSymmAlgValue ::= AlgorithmIdentifier{{...}} 2187 -- id-it-caKeyUpdateInfo OBJECT IDENTIFIER ::= {id-it 5} 2188 -- CAKeyUpdateInfoValue ::= CAKeyUpdAnnContent 2189 -- id-it-currentCRL OBJECT IDENTIFIER ::= {id-it 6} 2190 -- CurrentCRLValue ::= CertificateList 2191 -- id-it-unsupportedOIDs OBJECT IDENTIFIER ::= {id-it 7} 2192 -- UnsupportedOIDsValue ::= SEQUENCE OF OBJECT IDENTIFIER 2193 -- id-it-keyPairParamReq OBJECT IDENTIFIER ::= {id-it 10} 2194 -- KeyPairParamReqValue ::= OBJECT IDENTIFIER 2195 -- id-it-keyPairParamRep OBJECT IDENTIFIER ::= {id-it 11} 2196 -- KeyPairParamRepValue ::= AlgorithmIdentifer 2197 -- id-it-revPassphrase OBJECT IDENTIFIER ::= {id-it 12} 2198 -- RevPassphraseValue ::= EncryptedKey 2199 -- -- Changed from Encrypted Value to EncryptedKey as a CHOICE 2200 -- -- of EncryptedValue and EnvelopedData due to the changes 2201 -- -- made in CMP Updates [thisRFC] 2202 -- -- Using the choice EncryptedValue is bit-compatible to 2203 -- -- the syntax without this change 2204 -- id-it-implicitConfirm OBJECT IDENTIFIER ::= {id-it 13} 2205 -- ImplicitConfirmValue ::= NULL 2206 -- id-it-confirmWaitTime OBJECT IDENTIFIER ::= {id-it 14} 2207 -- ConfirmWaitTimeValue ::= GeneralizedTime 2208 -- id-it-origPKIMessage OBJECT IDENTIFIER ::= {id-it 15} 2209 -- OrigPKIMessageValue ::= PKIMessages 2210 -- id-it-suppLangTags OBJECT IDENTIFIER ::= {id-it 16} 2211 -- SuppLangTagsValue ::= SEQUENCE OF UTF8String 2212 -- id-it-caCerts OBJECT IDENTIFIER ::= { id-it 17} 2213 -- CaCertsValue ::= SEQUENCE OF CMPCertificate 2214 -- -- id-it-caCerts added in CMP Updates [thisRFC] 2215 -- id-it-rootCaKeyUpdate OBJECT IDENTIFIER ::= { id-it 18} 2216 -- RootCaKeyUpdateValue ::= RootCaKeyUpdateContent 2217 -- -- id-it-rootCaKeyUpdate added in CMP Updates [thisRFC] 2218 -- id-it-certReqTemplate OBJECT IDENTIFIER ::= { id-it 19} 2219 -- CertReqTemplateValue ::= CertReqTemplateContent 2220 -- -- id-it-certReqTemplate added in CMP Updates [thisRFC] 2221 -- 2222 -- where 2223 -- 2224 -- id-pkix OBJECT IDENTIFIER ::= { 2225 -- iso(1) identified-organization(3) 2226 -- dod(6) internet(1) security(5) mechanisms(5) pkix(7)} 2227 -- and 2228 -- id-it OBJECT IDENTIFIER ::= {id-pkix 4} 2229 -- 2230 -- 2231 -- This construct MAY also be used to define new PKIX Certificate 2232 -- Management Protocol request and response messages, or general- 2233 -- purpose (e.g., announcement) messages for future needs or for 2234 -- specific environments. 2236 GenMsgContent ::= SEQUENCE OF InfoTypeAndValue 2238 -- May be sent by EE, RA, or CA (depending on message content). 2239 -- The OPTIONAL infoValue parameter of InfoTypeAndValue will 2240 -- typically be omitted for some of the examples given above. 2241 -- The receiver is free to ignore any contained OBJECT IDs that it 2242 -- does not recognize. If sent from EE to CA, the empty set 2243 -- indicates that the CA may send 2244 -- any/all information that it wishes. 2246 GenRepContent ::= SEQUENCE OF InfoTypeAndValue 2247 -- Receiver MAY ignore any contained OIDs that it does not 2248 -- recognize. 2250 ErrorMsgContent ::= SEQUENCE { 2251 pKIStatusInfo PKIStatusInfo, 2252 errorCode INTEGER OPTIONAL, 2253 -- implementation-specific error codes 2254 errorDetails PKIFreeText OPTIONAL 2255 -- implementation-specific error details 2256 } 2258 CertConfirmContent ::= SEQUENCE OF CertStatus 2260 CertStatus ::= SEQUENCE { 2261 certHash OCTET STRING, 2262 -- the hash of the certificate, using the same hash algorithm 2263 -- as is used to create and verify the certificate signature 2264 certReqId INTEGER, 2265 -- to match this confirmation with the corresponding req/rep 2266 statusInfo PKIStatusInfo OPTIONAL } 2268 PollReqContent ::= SEQUENCE OF SEQUENCE { 2269 certReqId INTEGER } 2271 PollRepContent ::= SEQUENCE OF SEQUENCE { 2272 certReqId INTEGER, 2273 checkAfter INTEGER, -- time in seconds 2274 reason PKIFreeText OPTIONAL } 2276 -- 2277 -- Extended Key Usage extension for PKI entities used in CMP 2278 -- operations, added due to the changes made in 2279 -- CMP Updates [thisRFC] 2280 -- The EKUs for the CA and RA are reused from CMC as defined in 2281 -- [RFC6402] 2282 -- 2284 -- id-kp-cmcCA OBJECT IDENTIFIER ::= { id-kp 27 } 2285 -- id-kp-cmcRA OBJECT IDENTIFIER ::= { id-kp 28 } 2286 id-kp-cmKGA OBJECT IDENTIFIER ::= { id-kp 32 } 2288 END 2290 Appendix B. History of changes 2292 Note: This appendix will be deleted in the final version of the 2293 document. 2295 From version 06 -> 07: 2297 * Added David von Oheimb as co-author 2298 * Changed to XML V3 2299 * Added Section 2.3 to enable a CMP protocol version number 3 in the 2300 PKIHeader for cases where EnvelopedData is to be used (see thread 2301 "Mail regarding draft-ietf-lamps-cmp-updates"). 2302 * Added Section 2.4 to refer to [I-D.ietf-lamps-crmf-update-algs] 2303 for the update of id-PasswordBasedMac for PKI message protection 2304 using passwords or shared secrets. 2305 * Updated Section 2.6 to introduce the protocol version number 3 to 2306 properly indicate support of EnvelopedData instead of 2307 EncryptedValue in case a transaction requires use of EnvelopedData 2308 (see thread "Mail regarding draft-ietf-lamps-cmp-updates"). 2309 * Update Section 2.14 to make the minimal changes to the respective 2310 section in CMP more explicit. 2311 * Added Sections 2.15 and 2.16 to address the new cmp2021 protocol 2312 version in Section 7 Version Negotiation. 2313 * Updated Section 2.17 to add new OIDs for id-regCtrl-algId and id- 2314 regCtrl-rsaKeyLen for registration at IANA. 2315 * Added Section 2.20 to update the general rules of interpretation 2316 in Appendix D.1 regarding the new cmp2021 version. 2317 * Added Section 2.21 to update the Algorithm Use Profile in 2318 Appendix D.2 with the reference to the new CMP Algorithms document 2319 as decided at IETF 108. 2320 * Updates Section 3.1 to delete the description of a discovery 2321 mechanism as decided at IETF 108. 2322 * Various changes and corrections in wording. 2324 From version 05 -> 06: 2326 * Added the update of Appendix D.2 with the reference to the new CMP 2327 Algorithms document as decided in IETF 108 2328 * Updated the IANA considerations to register new OIDs for id- 2329 regCtrl-algId and d-regCtrl-rsaKeyLen. 2330 * Minor changes and corrections 2332 From version 04 -> 05: 2334 * Added Section 2.8 and Section 2.9 to clarify the usage of these 2335 general messages types with EC curves (see thread 2336 "AlgorithmIdentifier parameters NULL value - Re: InfoTypeAndValue 2337 in CMP headers") 2338 * Split former section 2.7 on adding 'CA Certificates', 'Root CA 2339 Certificates Update', and 'Certificate Request Template' in three 2340 separate sections for easier readability 2341 * Changed in Section 2.12 the ASN.1 syntax of CertReqTemplateValue 2342 from using reaKeyLen to usage of controls as specified in CRMF 2343 Section 6 [RFC4211] (see thread "dtaft-ietf-lamps-cmp-updates and 2344 rsaKeyLen") 2346 * Updated the IANA considerations in Section 2.17 to introduce new 2347 OID for id-regCtrl-algId and id-regCtrl-rsaKeyLen (see thread 2348 "dtaft-ietf-lamps-cmp-updates and rsaKeyLen") 2349 * Updated the IANA Considerations in and the Appendixes to introduce 2350 new OID for the updates ASN.1 modules (see thread "I-D Action: 2351 draft-ietf-lamps-cmp-updates-04.txt") 2352 * Removed EncryptedValue from and added Controls to the list of 2353 types imported from CRMF [RFC4211] in ASN.1 modules (see thread 2354 "draft-ietf-lamps-cmp-updates and the ASN.1 modules") 2355 * Moved declaration of Rand out of the comment in ASN.1 modules (see 2356 thread "draft-ietf-lamps-cmp-updates and the ASN.1 modules") 2357 * Minor changes and corrections 2359 From version 03 -> 04: 2361 * Added Section 2.7 to introduce three new id-it IDs for uses in 2362 general messages as discussed (see thread "draft-ietf-lamps-cmp- 2363 updates add section to introduce id-it-caCerts, id-it- 2364 rootCaKeyUpdate, and id-it-certReqTemplate") 2365 * Added the new id-it IDs and the /.well-known/cmp to the IANA 2366 Considerations of [RFC4210] in Section 2.9 2367 * Updated the IANA Considerations of [RFC4210] in Section 2.18 2368 * Some changes in wording on Section 3 due to review comments from 2369 Martin Peylo 2371 From version 02 -> 03: 2373 * Added a ToDo on aligning with the CMP Algorithms draft that will 2374 be set up as decided in IETF 108 2375 * Updated section on Encrypted Values in Section 2.6 to add the 2376 AsymmetricKey Package structure to transport a newly generated 2377 private key as decided in IETF 108 2378 * Updated the IANA Considerations of [RFC4210] in Section 2.18 2379 * Added the pre-registered OID in Section 2.18 and the ASN.1 module 2380 * Added Section 3 to document the changes to RFC 6712 [RFC6712] 2381 regarding URI discovery and using the path-prefix of '/.well- 2382 known/' as discussed in IETF 108 2383 * Updated the IANA Considerations section 2384 * Added a complete updated ASN.1 module in 1988 syntax to update 2385 Appendix F of [RFC4210] and a complete updated ASN.1 module in 2386 2002 syntax to update Section 9 of [RFC5912] 2387 * Minor changes in wording 2389 From version 01 -> 02: 2391 * Updated section on EKU OIDs in Section 2.2 as decided in IETF 107 2392 * Changed from symmetric key-encryption to password-based key 2393 management technique in Section 2.6 as discussed with Russ and Jim 2394 on the mailing list 2395 * Defined the attribute containing the key identifier for the 2396 revocation passphrase in Section 2.18 2397 * Moved the change history to the Appendix 2399 From version 00 -> 01: 2401 * Minor changes in wording 2403 From draft-brockhaus-lamps-cmp-updates-03 -> draft-ietf-lamps-cmp- 2404 updates-00: 2406 * Changes required to reflect WG adoption 2408 From version 02 -> 03: 2410 * Added some clarification in Section 2.1 2412 From version 01 -> 02: 2414 * Added clarification to section on multiple protection 2415 * Added clarification on new EKUs after some exchange with Tomas 2416 Gustavsson 2417 * Reused OIDs from RFC 6402 [RFC6402] as suggested by Sean Turner at 2418 IETF 106 2419 * Added clarification on the field containing the key identifier for 2420 a revocation passphrase 2421 * Minor changes in wording 2423 From version 00 -> 01: 2425 * Added a section describing the new extended key usages 2426 * Completed the section on changes to the specification of encrypted 2427 values 2428 * Added a section on clarification to Appendix D.4 2429 * Minor generalization in RFC 4210 [RFC4210] Sections 5.1.3.4 and 2430 5.3.22 2431 * Minor changes in wording 2433 Authors' Addresses 2435 Hendrik Brockhaus 2436 Siemens AG 2438 Email: hendrik.brockhaus@siemens.com 2439 David von Oheimb 2440 Siemens AG 2442 Email: david.von.oheimb@siemens.com