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