idnits 2.17.1 draft-ietf-lamps-cmp-updates-08.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 February 2021) is 1156 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 2139 -- Looks like a reference, but probably isn't: '1' on line 2142 -- Looks like a reference, but probably isn't: '2' on line 2088 -- Looks like a reference, but probably isn't: '3' on line 1842 -- Looks like a reference, but probably isn't: '4' on line 1843 -- Looks like a reference, but probably isn't: '5' on line 1844 -- Looks like a reference, but probably isn't: '6' on line 1845 -- Looks like a reference, but probably isn't: '7' on line 1846 -- Looks like a reference, but probably isn't: '8' on line 1847 == Missing Reference: 'CRMF' is mentioned on line 1468, but not defined == Missing Reference: 'PKCS10' is mentioned on line 1843, but not defined == Missing Reference: 'RFC3629' is mentioned on line 1833, but not defined == Missing Reference: 'RFC3066' is mentioned on line 1834, but not defined ** Obsolete undefined reference: RFC 3066 (Obsoleted by RFC 4646, RFC 4647) == Missing Reference: 'RFC2482' is mentioned on line 1836, but not defined ** Obsolete undefined reference: RFC 2482 (Obsoleted by RFC 6082) -- Looks like a reference, but probably isn't: '9' on line 1848 -- Looks like a reference, but probably isn't: '10' on line 1849 -- Looks like a reference, but probably isn't: '11' on line 1850 -- Looks like a reference, but probably isn't: '12' on line 1851 -- Looks like a reference, but probably isn't: '13' on line 1852 -- Looks like a reference, but probably isn't: '14' on line 1853 -- Looks like a reference, but probably isn't: '15' on line 1854 -- Looks like a reference, but probably isn't: '16' on line 1855 -- Looks like a reference, but probably isn't: '17' on line 1856 -- Looks like a reference, but probably isn't: '18' on line 1857 -- Looks like a reference, but probably isn't: '19' on line 1858 -- Looks like a reference, but probably isn't: '20' on line 1859 -- Looks like a reference, but probably isn't: '21' on line 1860 -- Looks like a reference, but probably isn't: '22' on line 1861 -- Looks like a reference, but probably isn't: '23' on line 1862 -- Looks like a reference, but probably isn't: '24' on line 1863 -- Looks like a reference, but probably isn't: '25' on line 1864 -- Looks like a reference, but probably isn't: '26' on line 1865 == Missing Reference: 'PKCS11' is mentioned on line 1899, but not defined == Missing Reference: 'RFC2104' is mentioned on line 1900, but not defined == Missing Reference: 'RFC2202' is mentioned on line 1900, 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-04 ** 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 February 2021 6 Expires: 26 August 2021 8 Certificate Management Protocol (CMP) Updates 9 draft-ietf-lamps-cmp-updates-08 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 August 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 . . . . . . . . . . . . . . . . . . . . 24 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 Section 7 197 [I-D.ietf-lamps-cmp-algorithms]. 199 2.2. New Section 4.5 - Extended Key Usage 201 The following subsection describes new extended key usages for 202 various CMP server types specified in RFC 4210 [RFC4210]. 204 Insert this section at the end of the current Section 4: 206 4.5. Extended Key Usage 208 The Extended Key Usage (EKU) extension indicates the purposes for 209 which the certified key pair may be used. It therefore restricts the 210 use of a certificate to specific applications. 212 A CA may want to delegate parts of its duties to other PKI management 213 entities. The mechanism to prove this delegation explained in this 214 section offers automatic way of checking the authorization of such 215 delegation. Such delegation could also be expressed by other means, 216 e.g., explicit configuration. 218 To offer automatic validation for the delegation of a role by a CA, 219 the certificates used for CMP message protection or signed data for 220 central key generation MUST be issued by the delegating CA and MUST 221 contain the respective EKUs. This proves the authorization of this 222 entity by the delegating CA to act in the given role as described 223 below. 225 The OIDs to be used for these EKUs are: 227 id-kp-cmcCA OBJECT IDENTIFIER ::= { 228 iso(1) identified-organization(3) dod(6) internet(1) 229 security(5) mechanisms(5) pkix(7) kp(3) 27 } 230 id-kp-cmcRA OBJECT IDENTIFIER ::= { 231 iso(1) identified-organization(3) dod(6) internet(1) 232 security(5) mechanisms(5) pkix(7) kp(3) 28 } 233 id-kp-cmKGA OBJECT IDENTIFIER ::= { 234 iso(1) identified-organization(3) dod(6) internet(1) 235 security(5) mechanisms(5) pkix(7) kp(3) 32 } 237 Note: RFC 6402 section 2.10 [RFC6402] specifies OIDs for a CMC CA and 238 a CMC RA. As the functionality of a CA and RA is not specific to 239 using CMC or CMP as certificate management protocol, these OIDs SHALL 240 be re-used also for CMP CAs and for CMP RAs. 242 The description of the PKI management entity for each of the EKUs is 243 as follows: 245 CMP CA: CMP Certification Authorities are CMP endpoints on CA 246 equipment as described in section 3.1.1.2. The private key 247 used in the context of CMP management operations, 248 especially CMP message protection, does not need to be the 249 same as for signing certificates. It is necessary, 250 however, to ensure that the entity acting as CMP CA is 251 authorized to do so. Therefore, the CMP CA MUST do one of 252 the following, 254 * use the CA private key also for the CMP endpoint, or 256 * explicitly designate this role to another entity. 258 For automatic validation of such a delegation this MUST be 259 indicated by the id-kp-cmcCA extended key usage. This 260 extended key usage MUST be placed into the certificate used 261 on the CA equipment and the CA that delegates this role 262 MUST issue the CMP CA certificate. 264 Note: Using a separate key pair for protecting CMP 265 management operations at the CA decreases the number of 266 operations of the private key used to sign certificates. 268 CMP RA: CMP Registration Authorities are CMP endpoints on RA 269 equipment as described in Section 3.1.1.3. A CMP RA is 270 identified by the id-kp-cmcRA extended key usage. This 271 extended key usage MUST be placed in RA certificates. The 272 CA that delegated this role is identified by the CA that 273 issued the CMP RA certificate. 275 CMP KGA: CMP Key Generation Authorities are identified by the id-kp- 276 cmKGA extended key usage. The CMP KGA knows the private 277 key it generated on behalf of the end entity. This is a 278 very sensitive service and therefore needs specific 279 authorization. This authorization is either with the CA 280 certificate itself, or it MUST be indicated by placing the 281 id-kp-cmKGA extended key usage in the certificate used to 282 authenticate the origin of the generated private key, and 283 to express the authorization to offer this service. 285 < TBD: Tomas addressed the quiestion if the CMP CA role and EKU are 286 really needed. The discussion is ongoing. > 287 Note: In device PKIs, especially those issuing IDevID certificates 288 IEEE 802.1AR Section 8.5 [IEEE.802.1AR_2018], CA certificates may 289 have very long validity (including the GeneralizedTime value 290 99991231235959Z to indicate a not well-defined expiration date as 291 specified in IEEE 802.1AR Section 8.5 [IEEE.802.1AR_2018] and 292 RFC 5280 Section 4.1.2.5 [RFC5280]). Such validity periods SHOULD 293 NOT be used for protection of CMP messages. Certificates for 294 delegated CMP message protection (CMP CA, CMP RA, CMP KGA) MUST NOT 295 use indefinite expiration date. 297 2.3. Update Section 5.1.1. - PKI Message Header 299 Section 5.1.1 of RFC 4210 [RFC4210] describes the PKI message header. 300 This document introduces the new version 3 indicating support of 301 EnvelopedData as specified in Section 2.6. 303 Replace the ASN.1 Syntax of PKIHeader and the subsequent description 304 of pvno with the following text: 306 PKIHeader ::= SEQUENCE { 307 pvno INTEGER { cmp1999(1), cmp2000(2), 308 cmp2021(3) }, 309 sender GeneralName, 310 recipient GeneralName, 311 messageTime [0] GeneralizedTime OPTIONAL, 312 protectionAlg [1] AlgorithmIdentifier OPTIONAL, 313 senderKID [2] KeyIdentifier OPTIONAL, 314 recipKID [3] KeyIdentifier OPTIONAL, 315 transactionID [4] OCTET STRING OPTIONAL, 316 senderNonce [5] OCTET STRING OPTIONAL, 317 recipNonce [6] OCTET STRING OPTIONAL, 318 freeText [7] PKIFreeText OPTIONAL, 319 generalInfo [8] SEQUENCE SIZE (1..MAX) OF 320 InfoTypeAndValue OPTIONAL 321 } 322 PKIFreeText ::= SEQUENCE SIZE (1..MAX) OF UTF8String 324 The usage of different pvno values is described in Section 7. 326 2.4. Update Section 5.1.3.1. - Shared Secret Information 328 Section 5.1.3.1 of RFC 4210 [RFC4210] describes the MAC based 329 protection of a PKIMessage using the algorithm id-PasswordBasedMac. 331 Replace the first paragraph with the following text: 333 In this case, the sender and recipient share secret information with 334 sufficient entropy (established via out-of-band means or from a 335 previous PKI management operation). PKIProtection will contain a MAC 336 value and the protectionAlg will be the following (see also [RFC4211] 337 and [I-D.ietf-lamps-crmf-update-algs]): 339 2.5. Replace Section 5.1.3.4 - Multiple Protection 341 Section 5.1.3.4 of RFC 4210 [RFC4210] describes the nested message. 342 This document enables using opens the usage of nested messages also 343 for batch transport of PKI messages between PKI management entities 344 and also with mixed body types. 346 Replace the text of the section with the following text: 348 5.1.3.4. Multiple Protection 350 When receiving a protected PKI message, a PKI management entity such 351 as an RA MAY forward that message adding its own protection (which 352 MAY be a MAC or a signature, depending on the information and 353 certificates shared between the RA and the CA). Moreover, multiple 354 PKI messages MAY be aggregated. There are several use cases for such 355 messages. 357 * The RA confirms having validated and authorized a message and 358 forwards the original message unchanged. 360 * The RA collects several messages that are to be forwarded in the 361 same direction and forwards them in a batch. In communication to 362 the CA request messages and in communication from the CA response 363 or announcement messages will be collected. This can for instance 364 be used when bridging an off-line connection between two PKI 365 management entities. 367 * The RA modifies the message(s) in some way (e.g., add or modify 368 particular field values or add new extensions) before forwarding 369 them, then it MAY create its own desired PKIBody. In case the 370 changes made by the RA to PKIMessage breaks the POP of a 371 certificate request, the RA MUST set the POP RAVerified. It MAY 372 include the original PKIMessage from the EE in the generalInfo 373 field of PKIHeader of the nested message (to accommodate, for 374 example, cases in which the CA wishes to check POP or other 375 information on the original EE message). The infoType to be used 376 in this situation is {id-it 15} (see Section 5.3.19 for the value 377 of id-it) and the infoValue is PKIMessages (contents MUST be in 378 the same order as the message in PKIBody). 380 These use cases are accomplished by nesting the messages sent by the 381 PKI entity within a new PKI message. The structure used is as 382 follows: 384 NestedMessageContent ::= PKIMessages 386 2.6. Replace Section 5.2.2. - Encrypted Values 388 Section 5.2.2 of RFC 4210 [RFC4210] describes the use of 389 EncryptedValue to transport encrypted data. This document extends 390 the encryption of data to preferably use EnvelopedData. 392 Replace the text of the section with the following text: 394 5.2.2. Encrypted Values 396 Where encrypted data (in this specification, private keys, 397 certificates, or revocation passphrase) are sent in PKI messages, the 398 EncryptedKey data structure is used. 400 EncryptedKey ::= CHOICE { 401 encryptedValue EncryptedValue, -- deprecated 402 envelopedData [0] EnvelopedData } 404 See CRMF [RFC4211] for EncryptedKey and EncryptedValue syntax and CMS 405 [RFC5652] for EnvelopedData syntax. Using the EncryptedKey data 406 structure, offers the choice to either use EncryptedValue (for 407 backward compatibility only) or EnvelopedData. The use of the 408 EncryptedValue structure has been deprecated in favor of the 409 EnvelopedData structure. Therefore, it is recommended to use 410 EnvelopedData. 412 Note: The EncryptedKey structure defined in CRMF [RFC4211] is reused 413 here, which makes the update is backward compatible. Using the new 414 syntax with the untagged default choice EncryptedValue is bits-on- 415 the-wire compatible with the old syntax. 417 To indicate support for EnvelopedData the pvno cmp2021 is introduced 418 by this document. Details on the usage of different pvno values is 419 described in Section 7. 421 The EncryptedKey data structure is used in CMP to transport a private 422 key, certificate, or revocation passphrase in encrypted form. 424 EnvelopedData is used as follows: 426 * It contains only one RecipientInfo structure because the content 427 is encrypted only for one recipient. 429 * It may contain a private key in the AsymmetricKeyPackage structure 430 as defined in RFC 5958 [RFC5958] wrapped in a SignedData structure 431 as specified in CMS section 5 [RFC5652] signed by the Key 432 Generation Authority. 434 * It may contain a certificate or revocation passphrase directly in 435 the encryptedContent field. 437 The content of the EnvelopedData structure, as specified in CMS 438 section 6 [RFC5652], MUST be encrypted using a newly generated 439 symmetric content-encryption key. This content-encryption key MUST 440 be securely provided to the recipient using one of three key 441 management techniques. 443 The choice of the key management technique to be used by the sender 444 depends on the credential available at the recipient: 446 * Recipient's certificate that contains a key usage extension 447 asserting keyAgreement: The content-encryption key will be 448 protected using the key agreement key management technique, as 449 specified in CMS section 6.2.2 [RFC5652]. This is the preferred 450 technique. 452 * Recipient's certificate that contains a key usage extension 453 asserting keyEncipherment: The content-encryption key will be 454 protected using the key transport key management technique, as 455 specified in CMS section 6.2.1 [RFC5652]. 457 * A password or shared secret: The content-encryption key will be 458 protected using the password-based key management technique, as 459 specified in CMS section 6.2.4 [RFC5652]. 461 2.7. Update Section 5.3.4. - Certification Response 463 Section 5.3.4 of RFC 4210 [RFC4210] describes the Certification 464 Response. This document updates the syntax by using the parent 465 structure EncryptedKey instead of EncryptedValue as described in 466 Section 2.6 above. 468 Replace the ASN.1 syntax of CertifiedKeyPair and CertOrEncCert with 469 the following text: 471 CertifiedKeyPair ::= SEQUENCE { 472 certOrEncCert CertOrEncCert, 473 privateKey [0] EncryptedKey OPTIONAL, 474 -- see [CRMF] for comment on encoding 475 publicationInfo [1] PKIPublicationInfo OPTIONAL 476 } 478 CertOrEncCert ::= CHOICE { 479 certificate [0] Certificate, 480 encryptedCert [1] EncryptedKey 481 } 483 Add the following as a new paragraph right after the ASN.1 syntax: 485 A p10cr message contains exactly one CertificationRequestInfo data 486 structure as specified in PKCS#10 [RFC2986] but no certReqId. 487 Therefore, the certReqId in the corresponding certification response 488 (cp) message MUST be set to 0. 490 Add the following as new paragraphs to the end of the section: 492 The use of EncryptedKey is described in Section 5.2.2. 494 Note: To indicate support for EnvelopedData the pvno cmp2021 is 495 introduced by this document. Details on the usage of different pvno 496 values is described in Section 7. 498 2.8. Update Section 5.3.19.2. - Signing Key Pair Types 500 The following section clarifies the usage of the Signing Key Pair 501 Types PKI general message on referencing EC curves. 503 Insert this note at the end of Section 5.3.19.2: 505 Note: In case several EC curves are supported, several id-ecPublicKey 506 elements need to be given, one each per named curve. 508 2.9. Update Section 5.3.19.3. - Encryption/Key Agreement Key Pair Types 510 The following section clarifies the use of the Encryption/Key 511 Agreement Key Pair Types PKI general message on referencing EC 512 curves. 514 Insert this note at the end of Section 5.3.19.3: 516 Note: In case several EC curves are supported, several id-ecPublicKey 517 elements need to be given, one each per named curve. 519 2.10. Replace Section 5.3.19.9. - Revocation Passphrase 521 Section 5.3.19.9 of RFC 4210 [RFC4210] describes the provisioning of 522 a revocation passphrase for authenticating a later revocation 523 request. This document updates the handling by using the parent 524 structure EncryptedKey instead of EncryptedValue to transport this 525 information as described in Section 2.6 above. 527 Replace the text of the section with the following text: 529 5.3.19.9. Revocation Passphrase 531 This MAY be used by the EE to send a passphrase to a CA/RA for the 532 purpose of authenticating a later revocation request (in the case 533 that the appropriate signing private key is no longer available to 534 authenticate the request). See Appendix B for further details on the 535 use of this mechanism. 537 GenMsg: {id-it 12}, EncryptedKey 538 GenRep: {id-it 12}, < absent > 540 The use of EncryptedKey is described in section 5.2.2. 542 2.11. New Section 5.3.19.14 - CA Certificates 544 The following subsection describes the PKI general message using id- 545 it-caCerts. The use is specified in Lightweight CMP Profile [I- 546 D.ietf-lamps-lightweight-cmp-profile] Section 4.4. 548 Insert this section after Section 5.3.19.13: 550 2.3.19.14 CA Certificates 552 This MAY be used by the client to get the current CA intermediate and 553 issuing CA certificates. 555 GenMsg: {id-it 17}, < absent > 556 GenRep: {id-it 17}, SEQUENCE OF CMPCertificate | < absent > 558 2.12. New Section 5.3.19.15 - Root CA Certificate Update 560 The following subsection describes the PKI general message using id- 561 it-rootCaKeyUpdate. The use is specified in Lightweight CMP Profile 562 [I-D.ietf-lamps-lightweight-cmp-profile] Section 4.4. 564 Insert this section after new Section 5.3.19.14: 566 5.3.19.15. Root CA Certificate Update 567 This MAY be used by the client to get an update of an existing root 568 CA Certificate. In contrast to the ckuann message it follows the 569 request/response model. 571 GenMsg: {id-it 18}, < absent > 572 GenRep: {id-it 18}, RootCaKeyUpdateContent | < absent > 574 RootCaKeyUpdateContent ::= SEQUENCE { 575 newWithNew CMPCertificate 576 newWithOld [0] CMPCertificate OPTIONAL, 577 oldWithNew [1] CMPCertificate OPTIONAL 578 } 580 < TBD: In case the PKI offers updates of various root CA 581 certificates, it needs to be defined how the EE requests an update of 582 a specific root CA certificate. > 584 Note: In contrast to CAKeyUpdAnnContent, this type offers omitting 585 newWithOld and oldWithNew in the GenRep message, depending on the 586 needs of the EE. 588 2.13. New Section 5.3.19.16 - Certificate Request Template 590 The following subsection describes the PKI general message using id- 591 it-certReqTemplate. The use is specified in Lightweight CMP Profile 592 [I-D.ietf-lamps-lightweight-cmp-profile] Section 4.4. 594 Insert this section after new Section 5.3.19.15: 596 5.3.19.16. Certificate Request Template 598 This MAY be used by the client to get a template containing 599 requirements for certificate request attributes and extensions and 600 optionally a specification for the key pair to generate for a future 601 certificate request operation. 603 GenMsg: {id-it 19}, < absent > 604 GenRep: {id-it 19}, CertReqTemplateContent | < absent > 606 CertReqTemplateContent ::= SEQUENCE { 607 certTemplate CertTemplate, 608 keySpec Controls OPTIONAL 609 } 611 Controls ::= SEQUENCE SIZE(1..MAX) OF AttributeTypeAndValue 613 id-regCtrl-algId OBJECT IDENTIFIER ::= { iso(1) 614 identified-organization(3) dod(6) internet(1) security(5) 615 mechanisms(5) pkix(7) pkip(5) regCtrl(1) TBD3 } 616 AlgIdCtrl ::= AlgorithmIdentifier 618 id-regCtrl-rsaKeyLen OBJECT IDENTIFIER ::= { iso(1) 619 identified-organization(3) dod(6) internet(1) security(5) 620 mechanisms(5) pkix(7) pkip(5) regCtrl(1) TBD4 } 621 RsaKeyLenCtrl ::= Integer 623 < TBD: The OIDs TBD3 and TBD4 have to be registered at IANA. > 625 < TBD: In case the PKI offers certificate request templates for 626 various certificates, it needs to be defined how the EE requests a 627 specific certificate request template. > 629 CertReqTemplateValue contains a prefilled certTemplate to be used for 630 the future certificate request. The SubjectPublicKeyInfo field in 631 the certTemplate MUST NOT be used. In case the PKI management entity 632 wishes to specify supported algorithms, the keySpec field MUST be 633 used. One AttributeTypeAndValue per supported algorithm or RSA key 634 length MUST be used. 636 Note: The Controls ASN.1 type is defined in CRMF Section 6 [RFC4211] 638 2.14. Update Section 5.3.22 - Polling Request and Response 640 Section 5.3.22 of RFC 4210 [RFC4210] describes when and how polling 641 messages are used. This document adds the polling mechanism also for 642 outstanding responses to a p10cr. 644 Replace in the first paragraph the word 'cr' by 'cr, p10cr' and add 645 just before the state machine diagram the following text: 647 A p10cr message contains exactly one CertificationRequestInfo data 648 structure as specified in PKCS#10 [RFC2986] but no certificate 649 request identifier. Therefore, the certReqId MUST be set to 0 in all 650 subsequent messages of this transaction. 652 2.15. Update Section 7 - Version Negotiation 654 Section 7 of RFC 4210 [RFC4210] describes the use of different CMP 655 protocol versions. This document describes the handling of the 656 additional CMP version cmp2021 introduced to indicate support of 657 EnvelopedData. 659 Replace the text of the first two paragraphs with the following text: 661 This section defines the version negotiation between client and 662 servers used to choose among cmp1999 (specified in RFC 2510 663 [RFC2510]), of cmp2000 (specified in RFC 4210 [RFC4210]), and cmp2021 664 (specified in this document). The only difference between protocol 665 versions cmp2021 and cmp2000 is that EnvelopedData replaces 666 EncryptedValue. 668 If a client does not support cmp2021 it chooses the versions for a 669 request as follows: 671 * If the client knows the protocol version(s) supported by the 672 server (e.g., from a previous PKIMessage exchange or via some out- 673 of-band means), then it MUST send a PKIMessage with the highest 674 version supported by both it and the server. 676 * If the client does not know what version(s) the server supports, 677 then it MUST send a PKIMessage using the highest version it 678 supports. 680 If a client supports cmp2021 and encrypted values are supposed to be 681 transferred in the PKI management operation the client MUST choose 682 the version for a request as follows: 684 * If the client supports EnvelopedData, but not EncryptedValue, then 685 it MUST send a PKIMessage using cmp2021. 687 * If the client does not support EnvelopedData, but EncryptedValue, 688 then it MUST send a PKIMessage using cmp2000. 690 * If the client supports both EnvelopedData and EncryptedValues: 692 - If the client knows the protocol version(s) supported by the 693 server (e.g., from a previous PKIMessage exchange or via some 694 out-of-band means), then it MUST send a PKIMessage with the 695 highest version supported the server. 697 - If the client does not know what version(s) the server 698 supports, then it MUST send a PKIMessage using cmp2021. 700 2.16. Update Section 7.1.1. - Clients Talking to RFC 2510 Servers 702 Section 7.1.1 of RFC 4210 [RFC4210] describes the behaviour of a 703 client talking to a cmp1999 server. This document extends the 704 section to all clients with a higher version than cmp1999. 706 Replace the first sentence of section 7.1.1 with the following text: 708 If, after sending a message with a higher protocol version number 709 than cmp1999, a client receives an ErrorMsgContent with a version of 710 cmp1999, then it MUST abort the current transaction. 712 2.17. Update Section 9 - IANA Considerations 714 Section 9 of RFC 4210 [RFC4210] contains the IANA Considerations of 715 that document. As this document defines one new and updates two 716 existing Extended Key Usages, the IANA Considerations need to be 717 updated accordingly. 719 Add the following paragraphs after the third paragraph of the 720 section: 722 In the SMI-numbers registry "SMI Security for PKIX Extended Key 723 Purpose Identifiers (1.3.6.1.5.5.7.3)" (see 724 https://www.iana.org/assignments/smi-numbers/smi-numbers.xhtml#smi- 725 numbers-1.3.6.1.5.5.7.3) as defined in RFC 7299 [RFC7299] three 726 changes have been performed. 728 Two existing entries have been updated to also point to this 729 document: 731 +=========+=============+====================+ 732 | Decimal | Description | References | 733 +=========+=============+====================+ 734 | 27 | id-kp-cmcCA | [RFC6402][thisRFC] | 735 +---------+-------------+--------------------+ 736 | 28 | id-kp-cmcRA | [RFC6402][thisRFC] | 737 +---------+-------------+--------------------+ 739 Table 1: Changes to the PKIX Extended Key 740 Purpose Identifiers registry 742 One new entry has been added: 744 +=========+=============+============+ 745 | Decimal | Description | References | 746 +=========+=============+============+ 747 | 32 | id-kp-cmKGA | [thisRFC] | 748 +---------+-------------+------------+ 750 Table 2: Adition to the PKIX 751 Extended Key Purpose Identifiers 752 registry 754 In the SMI-numbers registry "SMI Security for PKIX CMP Information 755 Types (1.3.6.1.5.5.7.4)" (see https://www.iana.org/assignments/smi- 756 numbers/smi-numbers.xhtml#smi-numbers-1.3.6.1.5.5.7.4) as defined in 757 RFC 7299 [RFC7299] three additions have been performed. 759 Three new entries have been added: 761 +=========+=======================+============+ 762 | Decimal | Description | References | 763 +=========+=======================+============+ 764 | 17 | id-it-caCerts | [thisRFC] | 765 +---------+-----------------------+------------+ 766 | 18 | id-it-rootCaKeyUpdate | [thisRFC] | 767 +---------+-----------------------+------------+ 768 | 19 | id-it-certReqTemplate | [thisRFC] | 769 +---------+-----------------------+------------+ 771 Table 3: Addition to the PKIX CMP 772 Information Types registry 774 In the SMI-numbers registry " SMI Security for PKIX CRMF Registration 775 Controls (1.3.6.1.5.5.7.5.1)" (see https://www.iana.org/assignments/ 776 smi-numbers/smi-numbers.xhtml#smi-numbers-1.3.6.1.5.5.7.5.1) as 777 defined in RFC 7299 [RFC7299] two additions have been performed. 779 Two new entries have been added: 781 +=========+======================+============+ 782 | Decimal | Description | References | 783 +=========+======================+============+ 784 | TBD3 | id-regCtrl-algId | [thisRFC] | 785 +---------+----------------------+------------+ 786 | TBD4 | id-regCtrl-rsaKeyLen | [thisRFC] | 787 +---------+----------------------+------------+ 789 Table 4: Addition to the PKIX CRMF 790 Registration Controls registry 792 2.18. Update Appendix B - The Use of Revocation Passphrase 794 Appendix B of RFC 4210 [RFC4210] describes the use of the revocation 795 passphrase. As this document updates RFC 4210 [RFC4210] to utilize 796 the parent structure EncryptedKey instead of EncryptedValue as 797 described in Section 2.6 above, the description is updated 798 accordingly. 800 Replace the first bullet point of this section with the following 801 text: 803 * The OID and value specified in Section 5.3.19.9 MAY be sent in a 804 GenMsg message at any time, or MAY be sent in the generalInfo 805 field of the PKIHeader of any PKIMessage at any time. (In 806 particular, the EncryptedKey structure as described in section 807 5.2.2 may be sent in the header of the certConf message that 808 confirms acceptance of certificates requested in an initialization 809 request or certificate request message.) This conveys a 810 revocation passphrase chosen by the entity to the relevant CA/RA. 811 For use of EnvelopedData this is in the decrypted bytes of 812 encryptedContent field and for use of EncryptedValue this is in 813 the decrypted bytes of the encValue field. Furthermore, the 814 transfer is accomplished with appropriate confidentiality 815 characteristics. 817 Replace the third bullet point of this section with the following 818 text: 820 * When using EnvelopedData the localKeyId attribute as specified in 821 RFC 2985 [RFC2985] and when using EncryptedValue the valueHint 822 field MAY contain a key identifier (chosen by the entity, along 823 with the passphrase itself) to assist in later retrieval of the 824 correct passphrase (e.g., when the revocation request is 825 constructed by the entity and received by the CA/RA). 827 2.19. Update Appendix C - Request Message Behavioral Clarifications 829 Appendix C of RFC 4210 [RFC4210] provides clarifications to the 830 request message behavior. As this document updates RFC 4210 831 [RFC4210] to utilize the parent structure EncryptedKey instead of 832 EncryptedValue as described in Section 2.6 above, the description is 833 updated accordingly. 835 Replace the comment within the ASN.1 syntax coming after the 836 definition of POPOPrivKey with the following text: 838 -- ********** 839 -- * the type of "thisMessage" is given as BIT STRING in RFC 4211 840 -- * [RFC4211]; it should be "EncryptedKey" (in accordance with 841 -- * Section 5.2.2 of this specification). Therefore, this 842 -- * document makes the behavioral clarification of specifying 843 -- * that the contents of "thisMessage" MUST be encoded either as 844 -- * "EnvelopedData" or "EncryptedValue" (only for backward 845 -- * compatibility) and then wrapped in a BIT STRING. This 846 -- * allows the necessary conveyance and protection of the 847 -- * private key while maintaining bits-on-the-wire compatibility 848 -- * with RFC 4211 [RFC4211]. 849 -- ********** 851 2.20. Update Appendix D.1. - General Rules for Interpretation of These 852 Profiles 854 Appendix D.1 of RFC 4210 [RFC4210] provides general rules for 855 interpretation of the PKI management messages profiles specified in 856 Appendix D and Appendix E of RFC 4210 [RFC4210]. This document 857 updates a sentence regarding the new protocol version cmp2021. 859 Replace the last sentence of the first paragraph of the section with 860 the following text: 862 Mandatory fields are not mentioned if they have an obvious value 863 (e.g., in this version of these profiles, pvno is always cmp2000). 865 2.21. Update Appendix D.2. - Algorithm Use Profile 867 Appendix D.2 of RFC 4210 [RFC4210] provides a list of algorithms that 868 implementations must support when claiming conformance with PKI 869 Management Message Profiles as specified in CMP Appendix D.2 870 [RFC4210]. This document redirects to the new algorithm profile as 871 specified in Appendix A.1 of CMP Algorithms 872 [I-D.ietf-lamps-cmp-algorithms]. 874 Replace the text of the section with the following text: 876 D.2. Algorithm Use Profile 878 For specifications of algorithm identifiers and respective 879 conventions for conforming implementations, please refer to CMP 880 Algorithms Appendix A.1 [I-D.ietf-lamps-cmp-algorithms]. 882 2.22. Update Appendix D.4. - Initial Registration/Certification (Basic 883 Authenticated Scheme) 885 Appendix D.4 of RFC 4210 [RFC4210] provides the initial registration/ 886 certification scheme. This scheme shall continue using 887 EncryptedValue for backward compatibility reasons. 889 Replace the comment after the privateKey field of 890 crc[1].certifiedKeyPair in the syntax of the Initialization Response 891 message with the following text: 893 -- see Appendix C, Request Message Behavioral Clarifications 894 -- for backward compatibility reasons, use EncryptedValue 896 3. Updates to RFC 6712 - HTTP Transfer for the Certificate Management 897 Protocol (CMP) 899 3.1. New Section 1.1. - Changes since RFC 6712 901 The following subsection describes feature updates to RFC 6712 902 [RFC6712]. They are related to the base specification. Hence 903 references to the original sections in RFC 6712 [RFC6712] are used 904 whenever possible. 906 Insert this section at the end of the current Section 1: 908 1.1 Changes since RFC 6712 910 The following updates are made in [thisRFC]: 912 * Introduce the HTTP path '/.well-known/cmp'. 914 * Extend the URI structure. 916 3.2. Replace Section 3.6. - HTTP Request-URI 918 Section 3.6 of RFC 6712 [RFC6712] specifies the used HTTP URIs. This 919 document introduces the HTTP path '/.well-known/cmp' and extends the 920 URIs. 922 Replace the text of the section with the following text: 924 3.6. HTTP Request-URI 926 Each CMP server on a PKI management entity supporting HTTP or HTTPS 927 transport MUST support the use of the path prefix '/.well-known/' as 928 defined in RFC 8615 [RFC8615] and the registered name 'cmp' to ease 929 interworking in a multi-vendor environment. 931 The CMP client needs to be configured with sufficient information to 932 form the CMP server URI. This is at least the authority portion of 933 the URI, e.g., 'www.example.com:80', or the full operation path 934 segment of the PKI management entity. Additionally, OPTIONAL path 935 segments MAY be added after the registered application name as part 936 of the full operation path to provide further distinction. A path 937 segment could for example support the differentiation of specific 938 CAs, certificate profiles, or PKI management operations. A valid 939 full operation path segment can look like this: 941 http://www.example.com/.well-known/cmp 942 http://www.example.com/.well-known/cmp/operationLabel 943 http://www.example.com/.well-known/cmp/profileLabel 944 http://www.example.com/.well-known/cmp/profileLabel/operationLabel 946 3.3. Update Section 6. - IANA Considerations 948 Section 6 of RFC 6712 [RFC6712] contains the IANA Considerations of 949 that document. As this document defines a new well-known URI, the 950 IANA Considerations need to be updated accordingly. 952 Add the following text between the first and second paragraph of the 953 section: 955 In the well-known URI registry (see https://www.iana.org/assignments/ 956 well-known-uris/well-known-uris.xhtml#well-known-uris-1) as defined 957 in RFC 8615 [RFC8615] the following change has been performed. 959 One new name entry has been added: 961 +============+===================+ 962 | URI suffix | Change controller | 963 +============+===================+ 964 | cmp | IETF | 965 +------------+-------------------+ 967 Table 5 969 4. IANA Considerations 971 This document contains an update to the IANA Consideration sections 972 to be added to [RFC4210] and [RFC6712]. 974 < TBD: This document updates the ASN.1 modules of RFC 4210 Appendix F 975 [RFC4210] and RFC 5912 Section 9 [RFC5912]. New OIDs TBD1 and TBD2 976 need to be registered to identify the updates ASN.1 modules. > 977 < TBD: New OIDs TBD3 (id-regCtrl-algId) and TBD4 (id-regCtrl- 978 rsaKeyLen) need to be registered. > 980 < TBD: The existing description and information of id-kp-cmcRA and 981 id-kp-cmcCA need to be updated to reflect their extended usage. > 983 5. Security Considerations 985 No changes are made to the existing security considerations of 986 RFC 4210 [RFC4210] and RFC 6712 [RFC6712]. 988 6. Acknowledgements 990 Special thank goes to Jim Schaad for his guidance and the inspiration 991 on structuring and writing this document we got from [RFC6402] which 992 updates CMC. Special thank also goes also to Russ Housley and Tomas 993 Gustavsson for reviewing and providing valuable suggestions on 994 improving this document. 996 We also thank all reviewers of this document for their valuable 997 feedback. 999 7. References 1001 7.1. Normative References 1003 [I-D.ietf-lamps-cmp-algorithms] 1004 Brockhaus, H., Aschauer, H., Ounsworth, M., and S. Mister, 1005 "CMP Algorithms", Work in Progress, Internet-Draft, draft- 1006 ietf-lamps-cmp-algorithms-02, 20 January 2021, 1007 . 1010 [I-D.ietf-lamps-crmf-update-algs] 1011 Housley, R., "Algorithm Requirements Update to the 1012 Internet X.509 Public Key Infrastructure Certificate 1013 Request Message Format (CRMF)", Work in Progress, 1014 Internet-Draft, draft-ietf-lamps-crmf-update-algs-04, 19 1015 February 2021, . 1018 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 1019 Requirement Levels", BCP 14, RFC 2119, 1020 DOI 10.17487/RFC2119, March 1997, 1021 . 1023 [RFC2510] Adams, C. and S. Farrell, "Internet X.509 Public Key 1024 Infrastructure Certificate Management Protocols", 1025 RFC 2510, DOI 10.17487/RFC2510, March 1999, 1026 . 1028 [RFC2985] Nystrom, M. and B. Kaliski, "PKCS #9: Selected Object 1029 Classes and Attribute Types Version 2.0", RFC 2985, 1030 DOI 10.17487/RFC2985, November 2000, 1031 . 1033 [RFC2986] Nystrom, M. and B. Kaliski, "PKCS #10: Certification 1034 Request Syntax Specification Version 1.7", RFC 2986, 1035 DOI 10.17487/RFC2986, November 2000, 1036 . 1038 [RFC4210] Adams, C., Farrell, S., Kause, T., and T. Mononen, 1039 "Internet X.509 Public Key Infrastructure Certificate 1040 Management Protocol (CMP)", RFC 4210, 1041 DOI 10.17487/RFC4210, September 2005, 1042 . 1044 [RFC4211] Schaad, J., "Internet X.509 Public Key Infrastructure 1045 Certificate Request Message Format (CRMF)", RFC 4211, 1046 DOI 10.17487/RFC4211, September 2005, 1047 . 1049 [RFC5280] Cooper, D., Santesson, S., Farrell, S., Boeyen, S., 1050 Housley, R., and W. Polk, "Internet X.509 Public Key 1051 Infrastructure Certificate and Certificate Revocation List 1052 (CRL) Profile", RFC 5280, DOI 10.17487/RFC5280, May 2008, 1053 . 1055 [RFC5652] Housley, R., "Cryptographic Message Syntax (CMS)", STD 70, 1056 RFC 5652, DOI 10.17487/RFC5652, September 2009, 1057 . 1059 [RFC5912] Hoffman, P. and J. Schaad, "New ASN.1 Modules for the 1060 Public Key Infrastructure Using X.509 (PKIX)", RFC 5912, 1061 DOI 10.17487/RFC5912, June 2010, 1062 . 1064 [RFC5958] Turner, S., "Asymmetric Key Packages", RFC 5958, 1065 DOI 10.17487/RFC5958, August 2010, 1066 . 1068 [RFC6402] Schaad, J., "Certificate Management over CMS (CMC) 1069 Updates", RFC 6402, DOI 10.17487/RFC6402, November 2011, 1070 . 1072 [RFC6712] Kause, T. and M. Peylo, "Internet X.509 Public Key 1073 Infrastructure -- HTTP Transfer for the Certificate 1074 Management Protocol (CMP)", RFC 6712, 1075 DOI 10.17487/RFC6712, September 2012, 1076 . 1078 [RFC7299] Housley, R., "Object Identifier Registry for the PKIX 1079 Working Group", RFC 7299, DOI 10.17487/RFC7299, July 2014, 1080 . 1082 [RFC8174] Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC 1083 2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174, 1084 May 2017, . 1086 [RFC8615] Nottingham, M., "Well-Known Uniform Resource Identifiers 1087 (URIs)", RFC 8615, DOI 10.17487/RFC8615, May 2019, 1088 . 1090 7.2. Informative References 1092 [I-D.ietf-lamps-lightweight-cmp-profile] 1093 Brockhaus, H., Fries, S., and D. V. Oheimb, "Lightweight 1094 CMP Profile", Work in Progress, Internet-Draft, draft- 1095 ietf-lamps-lightweight-cmp-profile-04, 2 November 2020, 1096 . 1099 [IEEE.802.1AR_2018] 1100 IEEE, "IEEE Standard for Local and metropolitan area 1101 networks - Secure Device Identity", IEEE 802.1AR-2018, 1102 DOI 10.1109/IEEESTD.2018.8423794, 2 August 2018, 1103 . 1105 Appendix A. ASN.1 Modules 1107 A.1. 1988 ASN.1 Module 1109 This section contains the updated ASN.1 module for [RFC4210]. This 1110 module replaces the module in Appendix F of that document. Although 1111 a 2002 ASN.1 module is provided, this 1988 ASN.1 module remains the 1112 normative module as per the policy of the PKIX working group. 1114 PKIXCMP {iso(1) identified-organization(3) 1115 dod(6) internet(1) security(5) mechanisms(5) pkix(7) 1116 id-mod(0) id-mod-cmp2021-88(TBD1)} 1118 DEFINITIONS EXPLICIT TAGS ::= 1119 BEGIN 1121 -- EXPORTS ALL -- 1123 IMPORTS 1125 Certificate, CertificateList, Extensions, AlgorithmIdentifier, 1126 UTF8String, id-kp -- if required; otherwise, comment out 1127 FROM PKIX1Explicit88 {iso(1) identified-organization(3) 1128 dod(6) internet(1) security(5) mechanisms(5) pkix(7) 1129 id-mod(0) id-pkix1-explicit-88(1)} 1131 GeneralName, KeyIdentifier 1132 FROM PKIX1Implicit88 {iso(1) identified-organization(3) 1133 dod(6) internet(1) security(5) mechanisms(5) pkix(7) 1134 id-mod(0) id-pkix1-implicit-88(2)} 1136 CertTemplate, PKIPublicationInfo, EncryptedKey, CertId, 1137 CertReqMessages, Controls, id-regCtrl 1138 FROM PKIXCRMF-2005 {iso(1) identified-organization(3) 1139 dod(6) internet(1) security(5) mechanisms(5) pkix(7) 1140 id-mod(0) id-mod-crmf2005(36)} 1141 -- The import of EncryptedKey is added due to the updates made 1142 -- in CMP Updates [thisRFC]]. EncryptedValue does not need to 1143 -- be imported anymore and is therefore removed here. 1145 -- see also the behavioral clarifications to CRMF codified in 1146 -- Appendix C of this specification 1147 CertificationRequest 1148 FROM PKCS-10 {iso(1) member-body(2) 1149 us(840) rsadsi(113549) 1150 pkcs(1) pkcs-10(10) modules(1) pkcs-10(1)} 1151 -- (specified in RFC 2986 with 1993 ASN.1 syntax and IMPLICIT 1152 -- tags). Alternatively, implementers may directly include 1153 -- the [PKCS10] syntax in this module 1155 localKeyId 1156 FROM PKCS-9 {iso(1) member-body(2) us(840) rsadsi(113549) 1157 pkcs(1) pkcs-9(9) modules(0) pkcs-9(1)} 1158 -- The import of localKeyId is added due to the updates made in 1159 -- CMP Updates [thisRFC] 1161 EnvelopedData, SignedData 1162 FROM CryptographicMessageSyntax2004 { iso(1) 1163 member-body(2) us(840) rsadsi(113549) pkcs(1) pkcs-9(9) 1164 smime(16) modules(0) cms-2004(24) } 1165 -- The import of EnvelopedData and SignedData is added due to 1166 -- the updates made in CMP Updates [thisRFC] 1168 ; 1170 -- the rest of the module contains locally-defined OIDs and 1171 -- constructs 1173 CMPCertificate ::= CHOICE { 1174 x509v3PKCert Certificate 1175 } 1176 -- This syntax, while bits-on-the-wire compatible with the 1177 -- standard X.509 definition of "Certificate", allows the 1178 -- possibility of future certificate types (such as X.509 1179 -- attribute certificates, WAP WTLS certificates, or other kinds 1180 -- of certificates) within this certificate management protocol, 1181 -- should a need ever arise to support such generality. Those 1182 -- implementations that do not foresee a need to ever support 1183 -- other certificate types MAY, if they wish, comment out the 1184 -- above structure and "un-comment" the following one prior to 1185 -- compiling this ASN.1 module. (Note that interoperability 1186 -- with implementations that don't do this will be unaffected by 1187 -- this change.) 1189 -- CMPCertificate ::= Certificate 1191 PKIMessage ::= SEQUENCE { 1192 header PKIHeader, 1193 body PKIBody, 1194 protection [0] PKIProtection OPTIONAL, 1195 extraCerts [1] SEQUENCE SIZE (1..MAX) OF CMPCertificate 1196 OPTIONAL 1197 } 1199 PKIMessages ::= SEQUENCE SIZE (1..MAX) OF PKIMessage 1201 PKIHeader ::= SEQUENCE { 1202 pvno INTEGER { cmp1999(1), cmp2000(2), 1203 cmp2021(3) }, 1204 sender GeneralName, 1205 -- identifies the sender 1206 recipient GeneralName, 1207 -- identifies the intended recipient 1208 messageTime [0] GeneralizedTime OPTIONAL, 1209 -- time of production of this message (used when sender 1210 -- believes that the transport will be "suitable"; i.e., 1211 -- that the time will still be meaningful upon receipt) 1212 protectionAlg [1] AlgorithmIdentifier OPTIONAL, 1213 -- algorithm used for calculation of protection bits 1214 senderKID [2] KeyIdentifier OPTIONAL, 1215 recipKID [3] KeyIdentifier OPTIONAL, 1216 -- to identify specific keys used for protection 1217 transactionID [4] OCTET STRING OPTIONAL, 1218 -- identifies the transaction; i.e., this will be the same in 1219 -- corresponding request, response, certConf, and PKIConf 1220 -- messages 1221 senderNonce [5] OCTET STRING OPTIONAL, 1222 recipNonce [6] OCTET STRING OPTIONAL, 1223 -- nonces used to provide replay protection, senderNonce 1224 -- is inserted by the creator of this message; recipNonce 1225 -- is a nonce previously inserted in a related message by 1226 -- the intended recipient of this message 1227 freeText [7] PKIFreeText OPTIONAL, 1228 -- this may be used to indicate context-specific instructions 1229 -- (this field is intended for human consumption) 1230 generalInfo [8] SEQUENCE SIZE (1..MAX) OF 1231 InfoTypeAndValue OPTIONAL 1232 -- this may be used to convey context-specific information 1233 -- (this field not primarily intended for human consumption) 1234 } 1236 PKIFreeText ::= SEQUENCE SIZE (1..MAX) OF UTF8String 1237 -- text encoded as UTF-8 String [RFC3629] (note: each 1238 -- UTF8String MAY include an [RFC3066] language tag 1239 -- to indicate the language of the contained text 1240 -- see [RFC2482] for details) 1242 PKIBody ::= CHOICE { -- message-specific body elements 1243 ir [0] CertReqMessages, --Initialization Request 1244 ip [1] CertRepMessage, --Initialization Response 1245 cr [2] CertReqMessages, --Certification Request 1246 cp [3] CertRepMessage, --Certification Response 1247 p10cr [4] CertificationRequest, --imported from [PKCS10] 1248 popdecc [5] POPODecKeyChallContent, --pop Challenge 1249 popdecr [6] POPODecKeyRespContent, --pop Response 1250 kur [7] CertReqMessages, --Key Update Request 1251 kup [8] CertRepMessage, --Key Update Response 1252 krr [9] CertReqMessages, --Key Recovery Request 1253 krp [10] KeyRecRepContent, --Key Recovery Response 1254 rr [11] RevReqContent, --Revocation Request 1255 rp [12] RevRepContent, --Revocation Response 1256 ccr [13] CertReqMessages, --Cross-Cert. Request 1257 ccp [14] CertRepMessage, --Cross-Cert. Response 1258 ckuann [15] CAKeyUpdAnnContent, --CA Key Update Ann. 1259 cann [16] CertAnnContent, --Certificate Ann. 1260 rann [17] RevAnnContent, --Revocation Ann. 1261 crlann [18] CRLAnnContent, --CRL Announcement 1262 pkiconf [19] PKIConfirmContent, --Confirmation 1263 nested [20] NestedMessageContent, --Nested Message 1264 genm [21] GenMsgContent, --General Message 1265 genp [22] GenRepContent, --General Response 1266 error [23] ErrorMsgContent, --Error Message 1267 certConf [24] CertConfirmContent, --Certificate confirm 1268 pollReq [25] PollReqContent, --Polling request 1269 pollRep [26] PollRepContent --Polling response 1270 } 1272 PKIProtection ::= BIT STRING 1274 ProtectedPart ::= SEQUENCE { 1275 header PKIHeader, 1276 body PKIBody 1277 } 1279 id-PasswordBasedMac OBJECT IDENTIFIER ::= {1 2 840 113533 7 66 13} 1280 PBMParameter ::= SEQUENCE { 1281 salt OCTET STRING, 1282 -- note: implementations MAY wish to limit acceptable sizes 1283 -- of this string to values appropriate for their environment 1284 -- in order to reduce the risk of denial-of-service attacks 1285 owf AlgorithmIdentifier, 1286 -- AlgId for a One-Way Function (SHA-1 recommended) 1287 iterationCount INTEGER, 1288 -- number of times the OWF is applied 1289 -- note: implementations MAY wish to limit acceptable sizes 1290 -- of this integer to values appropriate for their environment 1291 -- in order to reduce the risk of denial-of-service attacks 1292 mac AlgorithmIdentifier 1293 -- the MAC AlgId (e.g., DES-MAC, Triple-DES-MAC [PKCS11], 1294 } -- or HMAC [RFC2104, RFC2202]) 1296 id-DHBasedMac OBJECT IDENTIFIER ::= {1 2 840 113533 7 66 30} 1297 DHBMParameter ::= SEQUENCE { 1298 owf AlgorithmIdentifier, 1299 -- AlgId for a One-Way Function (SHA-1 recommended) 1300 mac AlgorithmIdentifier 1301 -- the MAC AlgId (e.g., DES-MAC, Triple-DES-MAC [PKCS11], 1302 } -- or HMAC [RFC2104, RFC2202]) 1304 NestedMessageContent ::= PKIMessages 1306 PKIStatus ::= INTEGER { 1307 accepted (0), 1308 -- you got exactly what you asked for 1309 grantedWithMods (1), 1310 -- you got something like what you asked for; the 1311 -- requester is responsible for ascertaining the differences 1312 rejection (2), 1313 -- you don't get it, more information elsewhere in the message 1314 waiting (3), 1315 -- the request body part has not yet been processed; expect to 1316 -- hear more later (note: proper handling of this status 1317 -- response MAY use the polling req/rep PKIMessages specified 1318 -- in Section 5.3.22; alternatively, polling in the underlying 1319 -- transport layer MAY have some utility in this regard) 1320 revocationWarning (4), 1321 -- this message contains a warning that a revocation is 1322 -- imminent 1323 revocationNotification (5), 1324 -- notification that a revocation has occurred 1325 keyUpdateWarning (6) 1326 -- update already done for the oldCertId specified in 1327 -- CertReqMsg 1328 } 1330 PKIFailureInfo ::= BIT STRING { 1331 -- since we can fail in more than one way! 1332 -- More codes may be added in the future if/when required. 1333 badAlg (0), 1334 -- unrecognized or unsupported Algorithm Identifier 1335 badMessageCheck (1), 1336 -- integrity check failed (e.g., signature did not verify) 1337 badRequest (2), 1338 -- transaction not permitted or supported 1339 badTime (3), 1340 -- messageTime was not sufficiently close to the system time, 1341 -- as defined by local policy 1342 badCertId (4), 1343 -- no certificate could be found matching the provided criteria 1344 badDataFormat (5), 1345 -- the data submitted has the wrong format 1346 wrongAuthority (6), 1347 -- the authority indicated in the request is different from the 1348 -- one creating the response token 1349 incorrectData (7), 1350 -- the requester's data is incorrect (for notary services) 1351 missingTimeStamp (8), 1352 -- when the timestamp is missing but should be there 1353 -- (by policy) 1354 badPOP (9), 1355 -- the proof-of-possession failed 1356 certRevoked (10), 1357 -- the certificate has already been revoked 1358 certConfirmed (11), 1359 -- the certificate has already been confirmed 1360 wrongIntegrity (12), 1361 -- invalid integrity, password based instead of signature or 1362 -- vice versa 1363 badRecipientNonce (13), 1364 -- invalid recipient nonce, either missing or wrong value 1365 timeNotAvailable (14), 1366 -- the TSA's time source is not available 1367 unacceptedPolicy (15), 1368 -- the requested TSA policy is not supported by the TSA. 1369 unacceptedExtension (16), 1370 -- the requested extension is not supported by the TSA. 1371 addInfoNotAvailable (17), 1372 -- the additional information requested could not be 1373 -- understood or is not available 1374 badSenderNonce (18), 1375 -- invalid sender nonce, either missing or wrong size 1376 badCertTemplate (19), 1377 -- invalid cert. template or missing mandatory information 1378 signerNotTrusted (20), 1379 -- signer of the message unknown or not trusted 1380 transactionIdInUse (21), 1381 -- the transaction identifier is already in use 1382 unsupportedVersion (22), 1383 -- the version of the message is not supported 1384 notAuthorized (23), 1385 -- the sender was not authorized to make the preceding 1386 -- request or perform the preceding action 1387 systemUnavail (24), 1388 -- the request cannot be handled due to system unavailability 1389 systemFailure (25), 1390 -- the request cannot be handled due to system failure 1391 duplicateCertReq (26) 1392 -- certificate cannot be issued because a duplicate 1393 -- certificate already exists 1394 } 1396 PKIStatusInfo ::= SEQUENCE { 1397 status PKIStatus, 1398 statusString PKIFreeText OPTIONAL, 1399 failInfo PKIFailureInfo OPTIONAL 1400 } 1402 OOBCert ::= CMPCertificate 1404 OOBCertHash ::= SEQUENCE { 1405 hashAlg [0] AlgorithmIdentifier OPTIONAL, 1406 certId [1] CertId OPTIONAL, 1407 hashVal BIT STRING 1408 -- hashVal is calculated over the DER encoding of the 1409 -- self-signed certificate with the identifier certID. 1410 } 1412 POPODecKeyChallContent ::= SEQUENCE OF Challenge 1413 -- One Challenge per encryption key certification request (in the 1414 -- same order as these requests appear in CertReqMessages). 1416 Challenge ::= SEQUENCE { 1417 owf AlgorithmIdentifier OPTIONAL, 1418 -- MUST be present in the first Challenge; MAY be omitted in 1419 -- any subsequent Challenge in POPODecKeyChallContent (if 1420 -- omitted, then the owf used in the immediately preceding 1421 -- Challenge is to be used). 1422 witness OCTET STRING, 1423 -- the result of applying the one-way function (owf) to a 1424 -- randomly-generated INTEGER, A. [Note that a different 1425 -- INTEGER MUST be used for each Challenge.] 1426 challenge OCTET STRING 1427 -- the encryption (under the public key for which the cert. 1428 -- request is being made) of Rand. 1429 } 1431 -- Added in CMP Updates [thisRFC] 1433 Rand ::= SEQUENCE { 1434 -- Rand is encrypted under the public key to form the challenge 1435 -- in POPODecKeyChallContent 1436 int INTEGER, 1437 -- the randomly-generated INTEGER A (above) 1438 sender GeneralName 1439 -- the sender's name (as included in PKIHeader) 1440 } 1442 POPODecKeyRespContent ::= SEQUENCE OF INTEGER 1443 -- One INTEGER per encryption key certification request (in the 1444 -- same order as these requests appear in CertReqMessages). The 1445 -- retrieved INTEGER A (above) is returned to the sender of the 1446 -- corresponding Challenge. 1448 CertRepMessage ::= SEQUENCE { 1449 caPubs [1] SEQUENCE SIZE (1..MAX) OF CMPCertificate 1450 OPTIONAL, 1451 response SEQUENCE OF CertResponse 1452 } 1453 CertResponse ::= SEQUENCE { 1454 certReqId INTEGER, 1455 -- to match this response with corresponding request (a value 1456 -- of 0 is to be used if certReqId is not specified in the 1457 -- corresponding request, which can only be a p10cr) 1458 status PKIStatusInfo, 1459 certifiedKeyPair CertifiedKeyPair OPTIONAL, 1460 rspInfo OCTET STRING OPTIONAL 1461 -- analogous to the id-regInfo-utf8Pairs string defined 1462 -- for regInfo in CertReqMsg [CRMF] 1463 } 1465 CertifiedKeyPair ::= SEQUENCE { 1466 certOrEncCert CertOrEncCert, 1467 privateKey [0] EncryptedKey OPTIONAL, 1468 -- see [CRMF] for comment on encoding 1469 -- Changed from Encrypted Value to EncryptedKey as a CHOICE of 1470 -- EncryptedValue and EnvelopedData due to the changes made in 1471 -- CMP Updates [thisRFC] 1472 -- Using the choice EncryptedValue is bit-compatible to the 1473 -- syntax without this change 1474 publicationInfo [1] PKIPublicationInfo OPTIONAL 1475 } 1477 CertOrEncCert ::= CHOICE { 1478 certificate [0] CMPCertificate, 1479 encryptedCert [1] EncryptedKey 1480 -- Changed from Encrypted Value to EncryptedKey as a CHOICE of 1481 -- EncryptedValue and EnvelopedData due to the changes made in 1482 -- CMP Updates [thisRFC] 1483 -- Using the choice EncryptedValue is bit-compatible to the 1484 -- syntax without this change 1485 } 1487 KeyRecRepContent ::= SEQUENCE { 1488 status PKIStatusInfo, 1489 newSigCert [0] CMPCertificate OPTIONAL, 1490 caCerts [1] SEQUENCE SIZE (1..MAX) OF 1491 CMPCertificate OPTIONAL, 1492 keyPairHist [2] SEQUENCE SIZE (1..MAX) OF 1493 CertifiedKeyPair OPTIONAL 1494 } 1496 RevReqContent ::= SEQUENCE OF RevDetails 1498 RevDetails ::= SEQUENCE { 1499 certDetails CertTemplate, 1500 -- allows requester to specify as much as they can about 1501 -- the cert. for which revocation is requested 1502 -- (e.g., for cases in which serialNumber is not available) 1503 crlEntryDetails Extensions OPTIONAL 1504 -- requested crlEntryExtensions 1505 } 1507 RevRepContent ::= SEQUENCE { 1508 status SEQUENCE SIZE (1..MAX) OF PKIStatusInfo, 1509 -- in same order as was sent in RevReqContent 1510 revCerts [0] SEQUENCE SIZE (1..MAX) OF CertId 1511 OPTIONAL, 1512 -- IDs for which revocation was requested 1513 -- (same order as status) 1514 crls [1] SEQUENCE SIZE (1..MAX) OF CertificateList 1515 OPTIONAL 1516 -- the resulting CRLs (there may be more than one) 1517 } 1519 CAKeyUpdAnnContent ::= SEQUENCE { 1520 oldWithNew CMPCertificate, -- old pub signed with new priv 1521 newWithOld CMPCertificate, -- new pub signed with old priv 1522 newWithNew CMPCertificate -- new pub signed with new priv 1523 } 1525 CertAnnContent ::= CMPCertificate 1527 RevAnnContent ::= SEQUENCE { 1528 status PKIStatus, 1529 certId CertId, 1530 willBeRevokedAt GeneralizedTime, 1531 badSinceDate GeneralizedTime, 1532 crlDetails Extensions OPTIONAL 1533 -- extra CRL details (e.g., crl number, reason, location, etc.) 1534 } 1536 CRLAnnContent ::= SEQUENCE OF CertificateList 1538 CertConfirmContent ::= SEQUENCE OF CertStatus 1540 CertStatus ::= SEQUENCE { 1541 certHash OCTET STRING, 1542 -- the hash of the certificate, using the same hash algorithm 1543 -- as is used to create and verify the certificate signature 1544 certReqId INTEGER, 1545 -- to match this confirmation with the corresponding req/rep 1546 statusInfo PKIStatusInfo OPTIONAL 1547 } 1548 PKIConfirmContent ::= NULL 1550 -- Added in CMP Updates [thisRFC] 1552 RootCaKeyUpdateContent ::= SEQUENCE { 1553 newWithNew CMPCertificate 1554 -- new root CA certificate 1555 newWithOld [0] CMPCertificate OPTIONAL, 1556 -- X.509 certificate containing the new public root CA key 1557 -- signed with the old private root CA key 1558 oldWithNew [1] CMPCertificate OPTIONAL 1559 -- X.509 certificate containing the old public root CA key 1560 -- signed with the new private root CA key 1561 } 1563 -- Added in CMP Updates [thisRFC] 1565 CertReqTemplateContent ::= SEQUENCE { 1566 certTemplate CertTemplate, 1567 -- prefilled certTemplate structure elements 1568 -- The SubjectPublicKeyInfo field in the certTemplate MUST NOT 1569 -- be used. 1570 keySpec Controls OPTIONAL 1571 -- MAY be used to specify supported algorithms. 1572 -- Controls ::= SEQUENCE SIZE(1..MAX) OF AttributeTypeAndValue 1573 -- as specified in CRMF (RFC4211) 1574 } 1576 id-regCtrl-algId OBJECT IDENTIFIER ::= { id-regCtrl TBD3 } 1577 AlgIdCtrl ::= AlgorithmIdentifier 1578 -- SHALL be used to specify suported algorithms other than RSA 1580 id-regCtrl-rsaKeyLen OBJECT IDENTIFIER ::= { id-regCtrl TBD4 } 1581 RsaKeyLenCtrl ::= Integer 1582 -- SHALL be used to specify suported RSA key lengths 1584 InfoTypeAndValue ::= SEQUENCE { 1585 infoType OBJECT IDENTIFIER, 1586 infoValue ANY DEFINED BY infoType OPTIONAL 1587 } 1588 -- Example InfoTypeAndValue contents include, but are not limited 1589 -- to, the following (un-comment in this ASN.1 module and use as 1590 -- appropriate for a given environment): 1591 -- 1592 -- id-it-caProtEncCert OBJECT IDENTIFIER ::= {id-it 1} 1593 -- CAProtEncCertValue ::= CMPCertificate 1594 -- id-it-signKeyPairTypes OBJECT IDENTIFIER ::= {id-it 2} 1595 -- SignKeyPairTypesValue ::= SEQUENCE OF AlgorithmIdentifier 1596 -- id-it-encKeyPairTypes OBJECT IDENTIFIER ::= {id-it 3} 1597 -- EncKeyPairTypesValue ::= SEQUENCE OF AlgorithmIdentifier 1598 -- id-it-preferredSymmAlg OBJECT IDENTIFIER ::= {id-it 4} 1599 -- PreferredSymmAlgValue ::= AlgorithmIdentifier 1600 -- id-it-caKeyUpdateInfo OBJECT IDENTIFIER ::= {id-it 5} 1601 -- CAKeyUpdateInfoValue ::= CAKeyUpdAnnContent 1602 -- id-it-currentCRL OBJECT IDENTIFIER ::= {id-it 6} 1603 -- CurrentCRLValue ::= CertificateList 1604 -- id-it-unsupportedOIDs OBJECT IDENTIFIER ::= {id-it 7} 1605 -- UnsupportedOIDsValue ::= SEQUENCE OF OBJECT IDENTIFIER 1606 -- id-it-keyPairParamReq OBJECT IDENTIFIER ::= {id-it 10} 1607 -- KeyPairParamReqValue ::= OBJECT IDENTIFIER 1608 -- id-it-keyPairParamRep OBJECT IDENTIFIER ::= {id-it 11} 1609 -- KeyPairParamRepValue ::= AlgorithmIdentifer 1610 -- id-it-revPassphrase OBJECT IDENTIFIER ::= {id-it 12} 1611 -- RevPassphraseValue ::= EncryptedKey 1612 -- -- Changed from Encrypted Value to EncryptedKey as a CHOICE 1613 -- -- of EncryptedValue and EnvelopedData due to the changes 1614 -- -- made in CMP Updates [thisRFC] 1615 -- -- Using the choice EncryptedValue is bit-compatible to the 1616 -- -- syntax without this change 1617 -- id-it-implicitConfirm OBJECT IDENTIFIER ::= {id-it 13} 1618 -- ImplicitConfirmValue ::= NULL 1619 -- id-it-confirmWaitTime OBJECT IDENTIFIER ::= {id-it 14} 1620 -- ConfirmWaitTimeValue ::= GeneralizedTime 1621 -- id-it-origPKIMessage OBJECT IDENTIFIER ::= {id-it 15} 1622 -- OrigPKIMessageValue ::= PKIMessages 1623 -- id-it-suppLangTags OBJECT IDENTIFIER ::= {id-it 16} 1624 -- SuppLangTagsValue ::= SEQUENCE OF UTF8String 1625 -- id-it-caCerts OBJECT IDENTIFIER ::= { id-it 17} 1626 -- CaCertsValue ::= SEQUENCE OF CMPCertificate 1627 -- -- id-it-caCerts added in CMP Updates [thisRFC] 1628 -- id-it-rootCaKeyUpdate OBJECT IDENTIFIER ::= { id-it 18} 1629 -- RootCaKeyUpdateValue ::= RootCaKeyUpdateContent 1630 -- -- id-it-rootCaKeyUpdate added in CMP Updates [thisRFC] 1631 -- id-it-certReqTemplate OBJECT IDENTIFIER ::= { id-it 19} 1632 -- CertReqTemplateValue ::= CertReqTemplateContent 1633 -- -- id-it-certReqTemplate added in CMP Updates [thisRFC] 1634 -- 1635 -- where 1636 -- 1637 -- id-pkix OBJECT IDENTIFIER ::= { 1638 -- iso(1) identified-organization(3) 1639 -- dod(6) internet(1) security(5) mechanisms(5) pkix(7)} 1640 -- and 1641 -- id-it OBJECT IDENTIFIER ::= {id-pkix 4} 1642 -- 1643 -- 1644 -- This construct MAY also be used to define new PKIX Certificate 1645 -- Management Protocol request and response messages, or general- 1646 -- purpose (e.g., announcement) messages for future needs or for 1647 -- specific environments. 1649 GenMsgContent ::= SEQUENCE OF InfoTypeAndValue 1651 -- May be sent by EE, RA, or CA (depending on message content). 1652 -- The OPTIONAL infoValue parameter of InfoTypeAndValue will 1653 -- typically be omitted for some of the examples given above. 1654 -- The receiver is free to ignore any contained OBJ. IDs that it 1655 -- does not recognize. If sent from EE to CA, the empty set 1656 -- indicates that the CA may send 1657 -- any/all information that it wishes. 1659 GenRepContent ::= SEQUENCE OF InfoTypeAndValue 1660 -- Receiver MAY ignore any contained OIDs that it does not 1661 -- recognize. 1663 ErrorMsgContent ::= SEQUENCE { 1664 pKIStatusInfo PKIStatusInfo, 1665 errorCode INTEGER OPTIONAL, 1666 -- implementation-specific error codes 1667 errorDetails PKIFreeText OPTIONAL 1668 -- implementation-specific error details 1669 } 1671 PollReqContent ::= SEQUENCE OF SEQUENCE { 1672 certReqId INTEGER 1673 } 1675 PollRepContent ::= SEQUENCE OF SEQUENCE { 1676 certReqId INTEGER, 1677 checkAfter INTEGER, -- time in seconds 1678 reason PKIFreeText OPTIONAL 1679 } 1681 -- 1682 -- Extended Key Usage extension for PKI entities used in CMP 1683 -- operations, added due to the changes made in 1684 -- CMP Updates [thisRFC] 1685 -- The EKUs for the CA and RA are reused from CMC as defined in 1686 -- [RFC6402] 1687 -- 1689 -- id-kp-cmcCA OBJECT IDENTIFIER ::= { id-kp 27 } 1690 -- id-kp-cmcRA OBJECT IDENTIFIER ::= { id-kp 28 } 1691 id-kp-cmKGA OBJECT IDENTIFIER ::= { id-kp 32 } 1692 END -- of CMP module 1694 A.2. 2002 ASN.1 Module 1696 This section contains the updated 2002 ASN.1 module for [RFC5912]. 1697 This module replaces the module in Section 9 of that document. The 1698 module contains those changes to the normative ASN.1 module from 1699 RFC4210 Appendix F [RFC4210] that were to update to 2002 ASN.1 1700 standard done in [RFC5912] as well as changes made in this document. 1702 PKIXCMP-2009 1703 { iso(1) identified-organization(3) dod(6) internet(1) 1704 security(5) mechanisms(5) pkix(7) id-mod(0) 1705 id-mod-cmp2021-02(TBD2) } 1706 DEFINITIONS EXPLICIT TAGS ::= 1707 BEGIN 1708 IMPORTS 1710 AttributeSet{}, Extensions{}, EXTENSION, ATTRIBUTE 1711 FROM PKIX-CommonTypes-2009 1712 {iso(1) identified-organization(3) dod(6) internet(1) security(5) 1713 mechanisms(5) pkix(7) id-mod(0) id-mod-pkixCommon-02(57)} 1715 AlgorithmIdentifier{}, SIGNATURE-ALGORITHM, ALGORITHM, 1716 DIGEST-ALGORITHM, MAC-ALGORITHM 1717 FROM AlgorithmInformation-2009 1718 {iso(1) identified-organization(3) dod(6) internet(1) security(5) 1719 mechanisms(5) pkix(7) id-mod(0) 1720 id-mod-algorithmInformation-02(58)} 1722 Certificate, CertificateList, id-kp 1723 FROM PKIX1Explicit-2009 1724 {iso(1) identified-organization(3) dod(6) internet(1) security(5) 1725 mechanisms(5) pkix(7) id-mod(0) id-mod-pkix1-explicit-02(51)} 1727 GeneralName, KeyIdentifier 1728 FROM PKIX1Implicit-2009 1729 {iso(1) identified-organization(3) dod(6) internet(1) security(5) 1730 mechanisms(5) pkix(7) id-mod(0) id-mod-pkix1-implicit-02(59)} 1732 CertTemplate, PKIPublicationInfo, EncryptedKey, CertId, 1733 CertReqMessages, Controls, id-regCtrl 1734 FROM PKIXCRMF-2009 1735 { iso(1) identified-organization(3) dod(6) internet(1) 1736 security(5) mechanisms(5) pkix(7) id-mod(0) 1737 id-mod-crmf2005-02(55) } 1738 -- The import of EncryptedKey is added due to the updates made 1739 -- in CMP Updates [thisRFC]. EncryptedValue does not need to 1740 -- be imported anymore and is therefore removed here. 1742 -- see also the behavioral clarifications to CRMF codified in 1743 -- Appendix C of this specification 1745 CertificationRequest 1746 FROM PKCS-10 1747 {iso(1) identified-organization(3) dod(6) internet(1) security(5) 1748 mechanisms(5) pkix(7) id-mod(0) id-mod-pkcs10-2009(69)} 1749 -- (specified in RFC 2986 with 1993 ASN.1 syntax and IMPLICIT 1750 -- tags). Alternatively, implementers may directly include 1751 -- the [PKCS10] syntax in this module 1753 localKeyId 1754 FROM PKCS-9 1755 {iso(1) member-body(2) us(840) rsadsi(113549) pkcs(1) pkcs-9(9) 1756 modules(0) pkcs-9(1)} 1757 -- The import of localKeyId is added due to the updates made in 1758 -- CMP Updates [thisRFC] 1760 EnvelopedData, SignedData 1761 FROM CryptographicMessageSyntax-2009 1762 {iso(1) member-body(2) us(840) rsadsi(113549) pkcs(1) pkcs-9(9) 1763 smime(16) modules(0) id-mod-cms-2004-02(41)} 1764 -- The import of EnvelopedData and SignedData is added due to 1765 -- the updates made in CMP Updates [thisRFC] 1766 ; 1768 -- the rest of the module contains locally defined OIDs and 1769 -- constructs 1771 CMPCertificate ::= CHOICE { x509v3PKCert Certificate, ... } 1772 -- This syntax, while bits-on-the-wire compatible with the 1773 -- standard X.509 definition of "Certificate", allows the 1774 -- possibility of future certificate types (such as X.509 1775 -- attribute certificates, WAP WTLS certificates, or other kinds 1776 -- of certificates) within this certificate management protocol, 1777 -- should a need ever arise to support such generality. Those 1778 -- implementations that do not foresee a need to ever support 1779 -- other certificate types MAY, if they wish, comment out the 1780 -- above structure and "uncomment" the following one prior to 1781 -- compiling this ASN.1 module. (Note that interoperability 1782 -- with implementations that don't do this will be unaffected by 1783 -- this change.) 1785 -- CMPCertificate ::= Certificate 1787 PKIMessage ::= SEQUENCE { 1788 header PKIHeader, 1789 body PKIBody, 1790 protection [0] PKIProtection OPTIONAL, 1791 extraCerts [1] SEQUENCE SIZE (1..MAX) OF CMPCertificate 1792 OPTIONAL } 1794 PKIMessages ::= SEQUENCE SIZE (1..MAX) OF PKIMessage 1796 PKIHeader ::= SEQUENCE { 1797 pvno INTEGER { cmp1999(1), cmp2000(2), 1798 cmp2012(3) }, 1799 sender GeneralName, 1800 -- identifies the sender 1801 recipient GeneralName, 1802 -- identifies the intended recipient 1803 messageTime [0] GeneralizedTime OPTIONAL, 1804 -- time of production of this message (used when sender 1805 -- believes that the transport will be "suitable"; i.e., 1806 -- that the time will still be meaningful upon receipt) 1807 protectionAlg [1] AlgorithmIdentifier{ALGORITHM, {...}} 1808 OPTIONAL, 1809 -- algorithm used for calculation of protection bits 1810 senderKID [2] KeyIdentifier OPTIONAL, 1811 recipKID [3] KeyIdentifier OPTIONAL, 1812 -- to identify specific keys used for protection 1813 transactionID [4] OCTET STRING OPTIONAL, 1814 -- identifies the transaction; i.e., this will be the same in 1815 -- corresponding request, response, certConf, and PKIConf 1816 -- messages 1817 senderNonce [5] OCTET STRING OPTIONAL, 1818 recipNonce [6] OCTET STRING OPTIONAL, 1819 -- nonces used to provide replay protection, senderNonce 1820 -- is inserted by the creator of this message; recipNonce 1821 -- is a nonce previously inserted in a related message by 1822 -- the intended recipient of this message 1823 freeText [7] PKIFreeText OPTIONAL, 1824 -- this may be used to indicate context-specific instructions 1825 -- (this field is intended for human consumption) 1826 generalInfo [8] SEQUENCE SIZE (1..MAX) OF 1827 InfoTypeAndValue OPTIONAL 1828 -- this may be used to convey context-specific information 1829 -- (this field not primarily intended for human consumption) 1830 } 1832 PKIFreeText ::= SEQUENCE SIZE (1..MAX) OF UTF8String 1833 -- text encoded as UTF-8 String [RFC3629] (note: each 1834 -- UTF8String MAY include an [RFC3066] language tag 1835 -- to indicate the language of the contained text; 1836 -- see [RFC2482] for details) 1838 PKIBody ::= CHOICE { -- message-specific body elements 1839 ir [0] CertReqMessages, --Initialization Request 1840 ip [1] CertRepMessage, --Initialization Response 1841 cr [2] CertReqMessages, --Certification Request 1842 cp [3] CertRepMessage, --Certification Response 1843 p10cr [4] CertificationRequest, --imported from [PKCS10] 1844 popdecc [5] POPODecKeyChallContent, --pop Challenge 1845 popdecr [6] POPODecKeyRespContent, --pop Response 1846 kur [7] CertReqMessages, --Key Update Request 1847 kup [8] CertRepMessage, --Key Update Response 1848 krr [9] CertReqMessages, --Key Recovery Request 1849 krp [10] KeyRecRepContent, --Key Recovery Response 1850 rr [11] RevReqContent, --Revocation Request 1851 rp [12] RevRepContent, --Revocation Response 1852 ccr [13] CertReqMessages, --Cross-Cert. Request 1853 ccp [14] CertRepMessage, --Cross-Cert. Response 1854 ckuann [15] CAKeyUpdAnnContent, --CA Key Update Ann. 1855 cann [16] CertAnnContent, --Certificate Ann. 1856 rann [17] RevAnnContent, --Revocation Ann. 1857 crlann [18] CRLAnnContent, --CRL Announcement 1858 pkiconf [19] PKIConfirmContent, --Confirmation 1859 nested [20] NestedMessageContent, --Nested Message 1860 genm [21] GenMsgContent, --General Message 1861 genp [22] GenRepContent, --General Response 1862 error [23] ErrorMsgContent, --Error Message 1863 certConf [24] CertConfirmContent, --Certificate confirm 1864 pollReq [25] PollReqContent, --Polling request 1865 pollRep [26] PollRepContent --Polling response 1866 } 1868 PKIProtection ::= BIT STRING 1870 ProtectedPart ::= SEQUENCE { 1871 header PKIHeader, 1872 body PKIBody } 1874 id-PasswordBasedMac OBJECT IDENTIFIER ::= { iso(1) member-body(2) 1875 usa(840) nt(113533) nsn(7) algorithms(66) 13 } 1876 PBMParameter ::= SEQUENCE { 1877 salt OCTET STRING, 1878 -- note: implementations MAY wish to limit acceptable sizes 1879 -- of this string to values appropriate for their environment 1880 -- in order to reduce the risk of denial-of-service attacks 1881 owf AlgorithmIdentifier{DIGEST-ALGORITHM, {...}}, 1882 -- AlgId for a One-Way Function (SHA-1 recommended) 1883 iterationCount INTEGER, 1884 -- number of times the OWF is applied 1885 -- note: implementations MAY wish to limit acceptable sizes 1886 -- of this integer to values appropriate for their environment 1887 -- in order to reduce the risk of denial-of-service attacks 1888 mac AlgorithmIdentifier{MAC-ALGORITHM, {...}} 1889 -- the MAC AlgId (e.g., DES-MAC, Triple-DES-MAC [PKCS11], 1890 -- or HMAC [RFC2104, RFC2202]) 1891 } 1893 id-DHBasedMac OBJECT IDENTIFIER ::= { iso(1) member-body(2) 1894 usa(840) nt(113533) nsn(7) algorithms(66) 30 } 1895 DHBMParameter ::= SEQUENCE { 1896 owf AlgorithmIdentifier{DIGEST-ALGORITHM, {...}}, 1897 -- AlgId for a One-Way Function (SHA-1 recommended) 1898 mac AlgorithmIdentifier{MAC-ALGORITHM, {...}} 1899 -- the MAC AlgId (e.g., DES-MAC, Triple-DES-MAC [PKCS11], 1900 -- or HMAC [RFC2104, RFC2202]) 1901 } 1903 PKIStatus ::= INTEGER { 1904 accepted (0), 1905 -- you got exactly what you asked for 1906 grantedWithMods (1), 1907 -- you got something like what you asked for; the 1908 -- requester is responsible for ascertaining the differences 1909 rejection (2), 1910 -- you don't get it, more information elsewhere in the message 1911 waiting (3), 1912 -- the request body part has not yet been processed; expect to 1913 -- hear more later (note: proper handling of this status 1914 -- response MAY use the polling req/rep PKIMessages specified 1915 -- in Section 5.3.22; alternatively, polling in the underlying 1916 -- transport layer MAY have some utility in this regard) 1917 revocationWarning (4), 1918 -- this message contains a warning that a revocation is 1919 -- imminent 1920 revocationNotification (5), 1921 -- notification that a revocation has occurred 1922 keyUpdateWarning (6) 1923 -- update already done for the oldCertId specified in 1924 -- CertReqMsg 1925 } 1927 PKIFailureInfo ::= BIT STRING { 1928 -- since we can fail in more than one way! 1929 -- More codes may be added in the future if/when required. 1930 badAlg (0), 1931 -- unrecognized or unsupported Algorithm Identifier 1932 badMessageCheck (1), 1933 -- integrity check failed (e.g., signature did not verify) 1934 badRequest (2), 1935 -- transaction not permitted or supported 1936 badTime (3), 1937 -- messageTime was not sufficiently close to the system time, 1938 -- as defined by local policy 1939 badCertId (4), 1940 -- no certificate could be found matching the provided criteria 1941 badDataFormat (5), 1942 -- the data submitted has the wrong format 1943 wrongAuthority (6), 1944 -- the authority indicated in the request is different from the 1945 -- one creating the response token 1946 incorrectData (7), 1947 -- the requester's data is incorrect (for notary services) 1948 missingTimeStamp (8), 1949 -- when the timestamp is missing but should be there 1950 -- (by policy) 1951 badPOP (9), 1952 -- the proof-of-possession failed 1953 certRevoked (10), 1954 -- the certificate has already been revoked 1955 certConfirmed (11), 1956 -- the certificate has already been confirmed 1957 wrongIntegrity (12), 1958 -- invalid integrity, password based instead of signature or 1959 -- vice versa 1960 badRecipientNonce (13), 1961 -- invalid recipient nonce, either missing or wrong value 1962 timeNotAvailable (14), 1963 -- the TSA's time source is not available 1964 unacceptedPolicy (15), 1965 -- the requested TSA policy is not supported by the TSA 1966 unacceptedExtension (16), 1967 -- the requested extension is not supported by the TSA 1968 addInfoNotAvailable (17), 1969 -- the additional information requested could not be 1970 -- understood or is not available 1971 badSenderNonce (18), 1972 -- invalid sender nonce, either missing or wrong size 1973 badCertTemplate (19), 1974 -- invalid cert. template or missing mandatory information 1975 signerNotTrusted (20), 1976 -- signer of the message unknown or not trusted 1977 transactionIdInUse (21), 1978 -- the transaction identifier is already in use 1979 unsupportedVersion (22), 1980 -- the version of the message is not supported 1981 notAuthorized (23), 1982 -- the sender was not authorized to make the preceding 1983 -- request or perform the preceding action 1984 systemUnavail (24), 1985 -- the request cannot be handled due to system unavailability 1986 systemFailure (25), 1987 -- the request cannot be handled due to system failure 1988 duplicateCertReq (26) 1989 -- certificate cannot be issued because a duplicate 1990 -- certificate already exists 1991 } 1993 PKIStatusInfo ::= SEQUENCE { 1994 status PKIStatus, 1995 statusString PKIFreeText OPTIONAL, 1996 failInfo PKIFailureInfo OPTIONAL } 1998 OOBCert ::= CMPCertificate 2000 OOBCertHash ::= SEQUENCE { 2001 hashAlg [0] AlgorithmIdentifier{DIGEST-ALGORITHM, {...}} 2002 OPTIONAL, 2003 certId [1] CertId OPTIONAL, 2004 hashVal BIT STRING 2005 -- hashVal is calculated over the DER encoding of the 2006 -- self-signed certificate with the identifier certID. 2007 } 2009 POPODecKeyChallContent ::= SEQUENCE OF Challenge 2010 -- One Challenge per encryption key certification request (in the 2011 -- same order as these requests appear in CertReqMessages). 2013 Challenge ::= SEQUENCE { 2014 owf AlgorithmIdentifier{DIGEST-ALGORITHM, {...}} 2015 OPTIONAL, 2016 -- MUST be present in the first Challenge; MAY be omitted in 2017 -- any subsequent Challenge in POPODecKeyChallContent (if 2018 -- omitted, then the owf used in the immediately preceding 2019 -- Challenge is to be used). 2020 witness OCTET STRING, 2021 -- the result of applying the one-way function (owf) to a 2022 -- randomly-generated INTEGER, A. [Note that a different 2023 -- INTEGER MUST be used for each Challenge.] 2024 challenge OCTET STRING 2025 -- the encryption (under the public key for which the cert. 2026 -- request is being made) of Rand. 2027 } 2028 -- Added in CMP Updates [thisRFC] 2030 Rand ::= SEQUENCE { 2031 -- Rand is encrypted under the public key to form the challenge 2032 -- in POPODecKeyChallContent 2033 int INTEGER, 2034 -- the randomly-generated INTEGER A (above) 2035 sender GeneralName 2036 -- the sender's name (as included in PKIHeader) 2037 } 2039 POPODecKeyRespContent ::= SEQUENCE OF INTEGER 2040 -- One INTEGER per encryption key certification request (in the 2041 -- same order as these requests appear in CertReqMessages). The 2042 -- retrieved INTEGER A (above) is returned to the sender of the 2043 -- corresponding Challenge. 2045 CertRepMessage ::= SEQUENCE { 2046 caPubs [1] SEQUENCE SIZE (1..MAX) OF CMPCertificate 2047 OPTIONAL, 2048 response SEQUENCE OF CertResponse } 2050 CertResponse ::= SEQUENCE { 2051 certReqId INTEGER, 2052 -- to match this response with the corresponding request (a value 2053 -- of 0 is to be used if certReqId is not specified in the 2054 -- corresponding request, which can only be a p10cr) 2055 status PKIStatusInfo, 2056 certifiedKeyPair CertifiedKeyPair OPTIONAL, 2057 rspInfo OCTET STRING OPTIONAL 2058 -- analogous to the id-regInfo-utf8Pairs string defined 2059 -- for regInfo in CertReqMsg [RFC4211] 2060 } 2062 CertifiedKeyPair ::= SEQUENCE { 2063 certOrEncCert CertOrEncCert, 2064 privateKey [0] EncryptedKey OPTIONAL, 2065 -- see [RFC4211] for comment on encoding 2066 -- Changed from Encrypted Value to EncryptedKey as a CHOICE of 2067 -- EncryptedValue and EnvelopedData due to the changes made in 2068 -- CMP Updates [thisRFC] 2069 -- Using the choice EncryptedValue is bit-compatible to the 2070 -- syntax without this change 2071 publicationInfo [1] PKIPublicationInfo OPTIONAL } 2073 CertOrEncCert ::= CHOICE { 2074 certificate [0] CMPCertificate, 2075 encryptedCert [1] EncryptedKey 2076 -- Changed from Encrypted Value to EncryptedKey as a CHOICE of 2077 -- EncryptedValue and EnvelopedData due to the changes made in 2078 -- CMP Updates [thisRFC] 2079 -- Using the choice EncryptedValue is bit-compatible to the 2080 -- syntax without this change 2081 } 2083 KeyRecRepContent ::= SEQUENCE { 2084 status PKIStatusInfo, 2085 newSigCert [0] CMPCertificate OPTIONAL, 2086 caCerts [1] SEQUENCE SIZE (1..MAX) OF 2087 CMPCertificate OPTIONAL, 2088 keyPairHist [2] SEQUENCE SIZE (1..MAX) OF 2089 CertifiedKeyPair OPTIONAL } 2091 RevReqContent ::= SEQUENCE OF RevDetails 2093 RevDetails ::= SEQUENCE { 2094 certDetails CertTemplate, 2095 -- allows requester to specify as much as they can about 2096 -- the cert. for which revocation is requested 2097 -- (e.g., for cases in which serialNumber is not available) 2098 crlEntryDetails Extensions{{...}} OPTIONAL 2099 -- requested crlEntryExtensions 2100 } 2102 RevRepContent ::= SEQUENCE { 2103 status SEQUENCE SIZE (1..MAX) OF PKIStatusInfo, 2104 -- in same order as was sent in RevReqContent 2105 revCerts [0] SEQUENCE SIZE (1..MAX) OF CertId OPTIONAL, 2106 -- IDs for which revocation was requested 2107 -- (same order as status) 2108 crls [1] SEQUENCE SIZE (1..MAX) OF CertificateList OPTIONAL 2109 -- the resulting CRLs (there may be more than one) 2110 } 2112 CAKeyUpdAnnContent ::= SEQUENCE { 2113 oldWithNew CMPCertificate, -- old pub signed with new priv 2114 newWithOld CMPCertificate, -- new pub signed with old priv 2115 newWithNew CMPCertificate -- new pub signed with new priv 2116 } 2118 CertAnnContent ::= CMPCertificate 2120 RevAnnContent ::= SEQUENCE { 2121 status PKIStatus, 2122 certId CertId, 2123 willBeRevokedAt GeneralizedTime, 2124 badSinceDate GeneralizedTime, 2125 crlDetails Extensions{{...}} OPTIONAL 2126 -- extra CRL details (e.g., crl number, reason, location, etc.) 2127 } 2129 CRLAnnContent ::= SEQUENCE OF CertificateList 2130 PKIConfirmContent ::= NULL 2132 NestedMessageContent ::= PKIMessages 2134 -- Added in CMP Updates [thisRFC] 2136 RootCaKeyUpdateContent ::= SEQUENCE { 2137 newWithNew CMPCertificate 2138 -- new root CA certificate 2139 newWithOld [0] CMPCertificate OPTIONAL, 2140 -- X.509 certificate containing the new public root CA key 2141 -- signed with the old private root CA key 2142 oldWithNew [1] CMPCertificate OPTIONAL 2143 -- X.509 certificate containing the old public root CA key 2144 -- signed with the new private root CA key 2145 } 2147 -- Added in CMP Updates [thisRFC] 2149 CertReqTemplateContent ::= SEQUENCE { 2150 certTemplate CertTemplate, 2151 -- prefilled certTemplate structure elements 2152 -- The SubjectPublicKeyInfo field in the certTemplate MUST NOT 2153 -- be used. 2154 keySpec Controls OPTIONAL 2155 -- MAY be used to specify supported algorithms. 2156 -- Controls ::= SEQUENCE SIZE(1..MAX) OF AttributeTypeAndValue 2157 -- as specified in CRMF (RFC4211) 2158 } 2160 id-regCtrl-algId OBJECT IDENTIFIER ::= { id-regCtrl TBD3 } 2161 AlgIdCtrl ::= AlgorithmIdentifier 2162 -- SHALL be used to specify suported algorithms other than RSA 2164 id-regCtrl-rsaKeyLen OBJECT IDENTIFIER ::= { id-regCtrl TBD4 } 2165 RsaKeyLenCtrl ::= Integer 2166 -- SHALL be used to specify suported RSA key lengths 2168 INFO-TYPE-AND-VALUE ::= TYPE-IDENTIFIER 2170 InfoTypeAndValue ::= SEQUENCE { 2171 infoType INFO-TYPE-AND-VALUE. 2173 &id({SupportedInfoSet}), 2174 infoValue INFO-TYPE-AND-VALUE. 2175 &Type({SupportedInfoSet}{@infoType}) } 2177 SupportedInfoSet INFO-TYPE-AND-VALUE ::= { ... } 2179 -- Example InfoTypeAndValue contents include, but are not limited 2180 -- to, the following (uncomment in this ASN.1 module and use as 2181 -- appropriate for a given environment): 2182 -- 2183 -- id-it-caProtEncCert OBJECT IDENTIFIER ::= {id-it 1} 2184 -- CAProtEncCertValue ::= CMPCertificate 2185 -- id-it-signKeyPairTypes OBJECT IDENTIFIER ::= {id-it 2} 2186 -- SignKeyPairTypesValue ::= SEQUENCE OF 2187 -- AlgorithmIdentifier{{...}} 2188 -- id-it-encKeyPairTypes OBJECT IDENTIFIER ::= {id-it 3} 2189 -- EncKeyPairTypesValue ::= SEQUENCE OF 2190 -- AlgorithmIdentifier{{...}} 2191 -- id-it-preferredSymmAlg OBJECT IDENTIFIER ::= {id-it 4} 2192 -- PreferredSymmAlgValue ::= AlgorithmIdentifier{{...}} 2193 -- id-it-caKeyUpdateInfo OBJECT IDENTIFIER ::= {id-it 5} 2194 -- CAKeyUpdateInfoValue ::= CAKeyUpdAnnContent 2195 -- id-it-currentCRL OBJECT IDENTIFIER ::= {id-it 6} 2196 -- CurrentCRLValue ::= CertificateList 2197 -- id-it-unsupportedOIDs OBJECT IDENTIFIER ::= {id-it 7} 2198 -- UnsupportedOIDsValue ::= SEQUENCE OF OBJECT IDENTIFIER 2199 -- id-it-keyPairParamReq OBJECT IDENTIFIER ::= {id-it 10} 2200 -- KeyPairParamReqValue ::= OBJECT IDENTIFIER 2201 -- id-it-keyPairParamRep OBJECT IDENTIFIER ::= {id-it 11} 2202 -- KeyPairParamRepValue ::= AlgorithmIdentifer 2203 -- id-it-revPassphrase OBJECT IDENTIFIER ::= {id-it 12} 2204 -- RevPassphraseValue ::= EncryptedKey 2205 -- -- Changed from Encrypted Value to EncryptedKey as a CHOICE 2206 -- -- of EncryptedValue and EnvelopedData due to the changes 2207 -- -- made in CMP Updates [thisRFC] 2208 -- -- Using the choice EncryptedValue is bit-compatible to 2209 -- -- the syntax without this change 2210 -- id-it-implicitConfirm OBJECT IDENTIFIER ::= {id-it 13} 2211 -- ImplicitConfirmValue ::= NULL 2212 -- id-it-confirmWaitTime OBJECT IDENTIFIER ::= {id-it 14} 2213 -- ConfirmWaitTimeValue ::= GeneralizedTime 2214 -- id-it-origPKIMessage OBJECT IDENTIFIER ::= {id-it 15} 2215 -- OrigPKIMessageValue ::= PKIMessages 2216 -- id-it-suppLangTags OBJECT IDENTIFIER ::= {id-it 16} 2217 -- SuppLangTagsValue ::= SEQUENCE OF UTF8String 2218 -- id-it-caCerts OBJECT IDENTIFIER ::= { id-it 17} 2219 -- CaCertsValue ::= SEQUENCE OF CMPCertificate 2220 -- -- id-it-caCerts added in CMP Updates [thisRFC] 2221 -- id-it-rootCaKeyUpdate OBJECT IDENTIFIER ::= { id-it 18} 2222 -- RootCaKeyUpdateValue ::= RootCaKeyUpdateContent 2223 -- -- id-it-rootCaKeyUpdate added in CMP Updates [thisRFC] 2224 -- id-it-certReqTemplate OBJECT IDENTIFIER ::= { id-it 19} 2225 -- CertReqTemplateValue ::= CertReqTemplateContent 2226 -- -- id-it-certReqTemplate added in CMP Updates [thisRFC] 2227 -- 2228 -- where 2229 -- 2230 -- id-pkix OBJECT IDENTIFIER ::= { 2231 -- iso(1) identified-organization(3) 2232 -- dod(6) internet(1) security(5) mechanisms(5) pkix(7)} 2233 -- and 2234 -- id-it OBJECT IDENTIFIER ::= {id-pkix 4} 2235 -- 2236 -- 2237 -- This construct MAY also be used to define new PKIX Certificate 2238 -- Management Protocol request and response messages, or general- 2239 -- purpose (e.g., announcement) messages for future needs or for 2240 -- specific environments. 2242 GenMsgContent ::= SEQUENCE OF InfoTypeAndValue 2244 -- May be sent by EE, RA, or CA (depending on message content). 2245 -- The OPTIONAL infoValue parameter of InfoTypeAndValue will 2246 -- typically be omitted for some of the examples given above. 2247 -- The receiver is free to ignore any contained OBJECT IDs that it 2248 -- does not recognize. If sent from EE to CA, the empty set 2249 -- indicates that the CA may send 2250 -- any/all information that it wishes. 2252 GenRepContent ::= SEQUENCE OF InfoTypeAndValue 2253 -- Receiver MAY ignore any contained OIDs that it does not 2254 -- recognize. 2256 ErrorMsgContent ::= SEQUENCE { 2257 pKIStatusInfo PKIStatusInfo, 2258 errorCode INTEGER OPTIONAL, 2259 -- implementation-specific error codes 2260 errorDetails PKIFreeText OPTIONAL 2261 -- implementation-specific error details 2262 } 2264 CertConfirmContent ::= SEQUENCE OF CertStatus 2266 CertStatus ::= SEQUENCE { 2267 certHash OCTET STRING, 2268 -- the hash of the certificate, using the same hash algorithm 2269 -- as is used to create and verify the certificate signature 2270 certReqId INTEGER, 2271 -- to match this confirmation with the corresponding req/rep 2272 statusInfo PKIStatusInfo OPTIONAL } 2274 PollReqContent ::= SEQUENCE OF SEQUENCE { 2275 certReqId INTEGER } 2277 PollRepContent ::= SEQUENCE OF SEQUENCE { 2278 certReqId INTEGER, 2279 checkAfter INTEGER, -- time in seconds 2280 reason PKIFreeText OPTIONAL } 2282 -- 2283 -- Extended Key Usage extension for PKI entities used in CMP 2284 -- operations, added due to the changes made in 2285 -- CMP Updates [thisRFC] 2286 -- The EKUs for the CA and RA are reused from CMC as defined in 2287 -- [RFC6402] 2288 -- 2290 -- id-kp-cmcCA OBJECT IDENTIFIER ::= { id-kp 27 } 2291 -- id-kp-cmcRA OBJECT IDENTIFIER ::= { id-kp 28 } 2292 id-kp-cmKGA OBJECT IDENTIFIER ::= { id-kp 32 } 2294 END 2296 Appendix B. History of changes 2298 Note: This appendix will be deleted in the final version of the 2299 document. 2301 From version 07 -> 08: 2303 * Added a ToDo to Section 2.2 to reflect a current discussion on the 2304 need of an additional CMP-CA role and EKU and differentiation from 2305 CMP-RA 2306 * Added ToDos to Section 2.12 and 2.13 2308 From version 06 -> 07: 2310 * Added David von Oheimb as co-author 2311 * Changed to XML V3 2312 * Added Section 2.3 to enable a CMP protocol version number 3 in the 2313 PKIHeader for cases where EnvelopedData is to be used (see thread 2314 "Mail regarding draft-ietf-lamps-cmp-updates"). 2316 * Added Section 2.4 to refer to [I-D.ietf-lamps-crmf-update-algs] 2317 for the update of id-PasswordBasedMac for PKI message protection 2318 using passwords or shared secrets. 2319 * Updated Section 2.6 to introduce the protocol version number 3 to 2320 properly indicate support of EnvelopedData instead of 2321 EncryptedValue in case a transaction requires use of EnvelopedData 2322 (see thread "Mail regarding draft-ietf-lamps-cmp-updates"). 2323 * Update Section 2.14 to make the minimal changes to the respective 2324 section in CMP more explicit. 2325 * Added Sections 2.15 and 2.16 to address the new cmp2021 protocol 2326 version in Section 7 Version Negotiation. 2327 * Updated Section 2.17 to add new OIDs for id-regCtrl-algId and id- 2328 regCtrl-rsaKeyLen for registration at IANA. 2329 * Added Section 2.20 to update the general rules of interpretation 2330 in Appendix D.1 regarding the new cmp2021 version. 2331 * Added Section 2.21 to update the Algorithm Use Profile in 2332 Appendix D.2 with the reference to the new CMP Algorithms document 2333 as decided at IETF 108. 2334 * Updates Section 3.1 to delete the description of a discovery 2335 mechanism as decided at IETF 108. 2336 * Various changes and corrections in wording. 2338 From version 05 -> 06: 2340 * Added the update of Appendix D.2 with the reference to the new CMP 2341 Algorithms document as decided in IETF 108 2342 * Updated the IANA considerations to register new OIDs for id- 2343 regCtrl-algId and d-regCtrl-rsaKeyLen. 2344 * Minor changes and corrections 2346 From version 04 -> 05: 2348 * Added Section 2.8 and Section 2.9 to clarify the usage of these 2349 general messages types with EC curves (see thread 2350 "AlgorithmIdentifier parameters NULL value - Re: InfoTypeAndValue 2351 in CMP headers") 2352 * Split former section 2.7 on adding 'CA Certificates', 'Root CA 2353 Certificates Update', and 'Certificate Request Template' in three 2354 separate sections for easier readability 2355 * Changed in Section 2.12 the ASN.1 syntax of CertReqTemplateValue 2356 from using reaKeyLen to usage of controls as specified in CRMF 2357 Section 6 [RFC4211] (see thread "dtaft-ietf-lamps-cmp-updates and 2358 rsaKeyLen") 2359 * Updated the IANA considerations in Section 2.17 to introduce new 2360 OID for id-regCtrl-algId and id-regCtrl-rsaKeyLen (see thread 2361 "dtaft-ietf-lamps-cmp-updates and rsaKeyLen") 2363 * Updated the IANA Considerations in and the Appendixes to introduce 2364 new OID for the updates ASN.1 modules (see thread "I-D Action: 2365 draft-ietf-lamps-cmp-updates-04.txt") 2366 * Removed EncryptedValue from and added Controls to the list of 2367 types imported from CRMF [RFC4211] in ASN.1 modules (see thread 2368 "draft-ietf-lamps-cmp-updates and the ASN.1 modules") 2369 * Moved declaration of Rand out of the comment in ASN.1 modules (see 2370 thread "draft-ietf-lamps-cmp-updates and the ASN.1 modules") 2371 * Minor changes and corrections 2373 From version 03 -> 04: 2375 * Added Section 2.7 to introduce three new id-it IDs for uses in 2376 general messages as discussed (see thread "draft-ietf-lamps-cmp- 2377 updates add section to introduce id-it-caCerts, id-it- 2378 rootCaKeyUpdate, and id-it-certReqTemplate") 2379 * Added the new id-it IDs and the /.well-known/cmp to the IANA 2380 Considerations of [RFC4210] in Section 2.9 2381 * Updated the IANA Considerations of [RFC4210] in Section 2.18 2382 * Some changes in wording on Section 3 due to review comments from 2383 Martin Peylo 2385 From version 02 -> 03: 2387 * Added a ToDo on aligning with the CMP Algorithms draft that will 2388 be set up as decided in IETF 108 2389 * Updated section on Encrypted Values in Section 2.6 to add the 2390 AsymmetricKey Package structure to transport a newly generated 2391 private key as decided in IETF 108 2392 * Updated the IANA Considerations of [RFC4210] in Section 2.18 2393 * Added the pre-registered OID in Section 2.18 and the ASN.1 module 2394 * Added Section 3 to document the changes to RFC 6712 [RFC6712] 2395 regarding URI discovery and using the path-prefix of '/.well- 2396 known/' as discussed in IETF 108 2397 * Updated the IANA Considerations section 2398 * Added a complete updated ASN.1 module in 1988 syntax to update 2399 Appendix F of [RFC4210] and a complete updated ASN.1 module in 2400 2002 syntax to update Section 9 of [RFC5912] 2401 * Minor changes in wording 2403 From version 01 -> 02: 2405 * Updated section on EKU OIDs in Section 2.2 as decided in IETF 107 2406 * Changed from symmetric key-encryption to password-based key 2407 management technique in Section 2.6 as discussed with Russ and Jim 2408 on the mailing list 2409 * Defined the attribute containing the key identifier for the 2410 revocation passphrase in Section 2.18 2412 * Moved the change history to the Appendix 2414 From version 00 -> 01: 2416 * Minor changes in wording 2418 From draft-brockhaus-lamps-cmp-updates-03 -> draft-ietf-lamps-cmp- 2419 updates-00: 2421 * Changes required to reflect WG adoption 2423 From version 02 -> 03: 2425 * Added some clarification in Section 2.1 2427 From version 01 -> 02: 2429 * Added clarification to section on multiple protection 2430 * Added clarification on new EKUs after some exchange with Tomas 2431 Gustavsson 2432 * Reused OIDs from RFC 6402 [RFC6402] as suggested by Sean Turner at 2433 IETF 106 2434 * Added clarification on the field containing the key identifier for 2435 a revocation passphrase 2436 * Minor changes in wording 2438 From version 00 -> 01: 2440 * Added a section describing the new extended key usages 2441 * Completed the section on changes to the specification of encrypted 2442 values 2443 * Added a section on clarification to Appendix D.4 2444 * Minor generalization in RFC 4210 [RFC4210] Sections 5.1.3.4 and 2445 5.3.22 2446 * Minor changes in wording 2448 Authors' Addresses 2450 Hendrik Brockhaus 2451 Siemens AG 2453 Email: hendrik.brockhaus@siemens.com 2455 David von Oheimb 2456 Siemens AG 2458 Email: david.von.oheimb@siemens.com