idnits 2.17.1 draft-ietf-lamps-cmp-updates-06.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 3 instances of lines with non-RFC6890-compliant IPv4 addresses in the document. If these are example addresses, they should be changed. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust and authors Copyright Line does not match the current year == The document seems to lack the recommended RFC 2119 boilerplate, even if it appears to use RFC 2119 keywords -- however, there's a paragraph with a matching beginning. Boilerplate error? (The document does seem to have the reference to RFC 2119 which the ID-Checklist requires). (Using the creation date from RFC4210, updated by this document, for RFC5378 checks: 2000-03-07) -- The document seems to lack a disclaimer for pre-RFC5378 work, but may have content which was first submitted before 10 November 2008. If you have contacted all the original authors and they are all willing to grant the BCP78 rights to the IETF Trust, then this is fine, and you can ignore this comment. If not, you may need to add the pre-RFC5378 disclaimer. (See the Legal Provisions document at https://trustee.ietf.org/license-info for more information.) -- The document date (November 2, 2020) is 1243 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 1991 == Missing Reference: 'CRMF' is mentioned on line 1320, but not defined -- Looks like a reference, but probably isn't: '1' on line 1994 == Missing Reference: 'PKCS10' is mentioned on line 1695, but not defined -- Looks like a reference, but probably isn't: '2' on line 1940 -- Looks like a reference, but probably isn't: '3' on line 1694 -- Looks like a reference, but probably isn't: '4' on line 1695 -- Looks like a reference, but probably isn't: '5' on line 1696 -- Looks like a reference, but probably isn't: '6' on line 1697 -- Looks like a reference, but probably isn't: '7' on line 1698 -- Looks like a reference, but probably isn't: '8' on line 1699 == Missing Reference: 'RFC3629' is mentioned on line 1685, but not defined == Missing Reference: 'RFC3066' is mentioned on line 1686, but not defined ** Obsolete undefined reference: RFC 3066 (Obsoleted by RFC 4646, RFC 4647) == Missing Reference: 'RFC2482' is mentioned on line 1688, but not defined ** Obsolete undefined reference: RFC 2482 (Obsoleted by RFC 6082) -- Looks like a reference, but probably isn't: '9' on line 1700 -- Looks like a reference, but probably isn't: '10' on line 1701 -- Looks like a reference, but probably isn't: '11' on line 1702 -- Looks like a reference, but probably isn't: '12' on line 1703 -- Looks like a reference, but probably isn't: '13' on line 1704 -- Looks like a reference, but probably isn't: '14' on line 1705 -- Looks like a reference, but probably isn't: '15' on line 1706 -- Looks like a reference, but probably isn't: '16' on line 1708 -- Looks like a reference, but probably isn't: '17' on line 1709 -- Looks like a reference, but probably isn't: '18' on line 1710 -- Looks like a reference, but probably isn't: '19' on line 1711 -- Looks like a reference, but probably isn't: '20' on line 1712 -- Looks like a reference, but probably isn't: '21' on line 1713 -- Looks like a reference, but probably isn't: '22' on line 1714 -- Looks like a reference, but probably isn't: '23' on line 1715 -- Looks like a reference, but probably isn't: '24' on line 1716 -- Looks like a reference, but probably isn't: '25' on line 1717 -- Looks like a reference, but probably isn't: '26' on line 1718 == Missing Reference: 'PKCS11' is mentioned on line 1752, but not defined == Missing Reference: 'RFC2104' is mentioned on line 1753, but not defined == Missing Reference: 'RFC2202' is mentioned on line 1753, but not defined == Outdated reference: A later version (-15) exists of draft-ietf-lamps-cmp-algorithms-00 ** 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 ** Downref: Normative reference to an Informational RFC: RFC 8515 == Outdated reference: A later version (-21) exists of draft-ietf-lamps-lightweight-cmp-profile-03 Summary: 7 errors (**), 0 flaws (~~), 13 warnings (==), 29 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 LAMPS Working Group H. Brockhaus 3 Internet-Draft Siemens 4 Updates: 4210, 6712 (if approved) November 2, 2020 5 Intended status: Standards Track 6 Expires: May 6, 2021 8 CMP Updates 9 draft-ietf-lamps-cmp-updates-06 11 Abstract 13 This document contains a set of updates to the base syntax and 14 transport of Certificate Management Protocol (CMP) version 2. This 15 document updates RFC 4210 and RFC 6712. 17 Specifically, the CMP services updated in this document comprise the 18 enabling of using EnvelopedData instead of EncryptedValue, adding new 19 general message types, the definition of extended key usages to 20 identify certificates of CMP endpoints on certification and 21 registration authorities, and adds an HTTP URI discovery mechanism 22 and extend the URI structure. 24 Status of This Memo 26 This Internet-Draft is submitted in full conformance with the 27 provisions of BCP 78 and BCP 79. 29 Internet-Drafts are working documents of the Internet Engineering 30 Task Force (IETF). Note that other groups may also distribute 31 working documents as Internet-Drafts. The list of current Internet- 32 Drafts is at https://datatracker.ietf.org/drafts/current/. 34 Internet-Drafts are draft documents valid for a maximum of six months 35 and may be updated, replaced, or obsoleted by other documents at any 36 time. It is inappropriate to use Internet-Drafts as reference 37 material or to cite them other than as "work in progress." 39 This Internet-Draft will expire on May 6, 2021. 41 Copyright Notice 43 Copyright (c) 2020 IETF Trust and the persons identified as the 44 document authors. All rights reserved. 46 This document is subject to BCP 78 and the IETF Trust's Legal 47 Provisions Relating to IETF Documents 48 (https://trustee.ietf.org/license-info) in effect on the date of 49 publication of this document. Please review these documents 50 carefully, as they describe your rights and restrictions with respect 51 to this document. Code Components extracted from this document must 52 include Simplified BSD License text as described in Section 4.e of 53 the Trust Legal Provisions and are provided without warranty as 54 described in the Simplified BSD License. 56 Table of Contents 58 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 3 59 1.1. Convention and Terminology . . . . . . . . . . . . . . . 3 60 2. Updates to RFC 4210 - Certificate Management Protocol (CMP) . 3 61 2.1. New Section 1.1. - Changes since RFC 4210 . . . . . . . . 4 62 2.2. New Section 4.5 - Extended Key Usage . . . . . . . . . . 4 63 2.3. Replace Section 5.1.3.4 - Multiple Protection . . . . . . 6 64 2.4. Replace Section 5.2.2. - Encrypted Values . . . . . . . . 7 65 2.5. Update Section 5.3.4. - Certification Response . . . . . 9 66 2.6. Update Section 5.3.19.2. - Signing Key Pair Types . . . . 9 67 2.7. Update Section 5.3.19.3. - Encryption/Key Agreement Key 68 Pair Types . . . . . . . . . . . . . . . . . . . . . . . 10 69 2.8. Replace Section 5.3.19.9. - Revocation Passphrase . . . . 10 70 2.9. New Section 5.3.19.14 - CA Certificates . . . . . . . . . 10 71 2.10. New Section 5.3.19.15 - Root CA Certificates Update . . . 11 72 2.11. New Section 5.3.19.16 - Certificate Request Template . . 11 73 2.12. Update Section 5.3.22 - Polling Request and Response . . 12 74 2.13. Update Section 9 - IANA Considerations . . . . . . . . . 13 75 2.14. Update Appendix B - The Use of Revocation Passphrase . . 14 76 2.15. Update Appendix C - Request Message Behavioral 77 Clarifications . . . . . . . . . . . . . . . . . . . . . 15 78 2.16. Update Appendix D.2. - Algorithm Use Profile . . . . . . 16 79 2.17. Update Appendix D.4. - Initial Registration/Certification 80 (Basic Authenticated Scheme) . . . . . . . . . . . . . . 16 81 3. Updates to RFC 6712 - HTTP Transfer for the Certificate 82 Management Protocol (CMP) . . . . . . . . . . . . . . . . . . 16 83 3.1. New Section 1.1. - Changes since RFC 6712 . . . . . . . . 16 84 3.2. Replace Section 3.6. - HTTP Request-URI . . . . . . . . . 17 85 3.3. Update Section 6. - IANA Considerations . . . . . . . . . 18 86 4. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 18 87 5. Security Considerations . . . . . . . . . . . . . . . . . . . 19 88 6. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 19 89 7. References . . . . . . . . . . . . . . . . . . . . . . . . . 19 90 7.1. Normative References . . . . . . . . . . . . . . . . . . 19 91 7.2. Informative References . . . . . . . . . . . . . . . . . 21 92 Appendix A. ASN.1 Modules . . . . . . . . . . . . . . . . . . . 21 93 A.1. 1988 ASN.1 Module . . . . . . . . . . . . . . . . . . . . 21 94 A.2. 2002 ASN.1 Module . . . . . . . . . . . . . . . . . . . . 33 95 Appendix B. History of changes . . . . . . . . . . . . . . . . . 46 96 Author's Address . . . . . . . . . . . . . . . . . . . . . . . . 49 98 1. Introduction 100 [RFC Editor: please delete]: !!! The change history was moved to 101 Appendix B !!! 103 While using CMP [RFC4210] in industrial and IoT environments and 104 developing the Lightweight CMP Profile 105 [I-D.ietf-lamps-lightweight-cmp-profile] some limitations were 106 identified in the original CMP specification. This document updates 107 RFC 4210 [RFC4210] and RFC 6712 [RFC6712] to overcome these 108 limitations. 110 In general, this document aims to improve the crypto agility of CMP 111 to be flexible to react on future advances in cryptography. 113 This document also introduces new extended key usages to identify CMP 114 endpoints on registration and certification authorities. 116 1.1. Convention and Terminology 118 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 119 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 120 document are to be interpreted as described in BCP 14 [RFC2119] 121 [RFC8174] when, and only when, they appear in all capitals, as shown 122 here. 124 Technical terminology is used in conformance with RFC 4210 [RFC4210], 125 RFC 4211 [RFC4211], and RFC 5280 [RFC5280]. The following key words 126 are used: 128 CA: Certification authority, which issues certificates. 130 RA: Registration authority, an optional system component to which a 131 CA delegates certificate management functions such as 132 authorization checks. 134 KGA: Key generation authority, which generates key pairs on behalf of 135 an EE. The KGA could be co-located with an RA or a CA. 137 EE: End entity, a user, device, or service that holds a PKI 138 certificate. An identifier for the EE is given as its subject 139 of the certificate. 141 2. Updates to RFC 4210 - Certificate Management Protocol (CMP) 142 2.1. New Section 1.1. - Changes since RFC 4210 144 The following subsection describes feature updates to RFC 4210 145 [RFC4210]. They are always related to the base specification. Hence 146 references to the original sections in RFC 4210 [RFC4210] are used 147 whenever possible. 149 Insert this section at the end of the current Section 1. 151 1.1 Changes since RFC 4210 153 The following updates are made in [thisRFC]: 155 o Add new extended key usages for different CMP server types, e.g. 156 registration authority and certification authority, to express the 157 authorization of the entity identified in the certificate 158 containing the respective extended key usage extension to act as 159 the indicated PKI management entity. 161 o Extend the description of multiple protection to cover additional 162 use cases, e.g., batch processing of messages. 164 o Offering EnvelopedData as the preferred choice next to 165 EncryptedValue to extend crypto agility in CMP. Note that 166 according to RFC 4211 [RFC4211] section 2.1.9 the use of the 167 EncryptedValue structure has been deprecated in favor of the 168 EnvelopedData structure. RFC 4211 [RFC4211] offers the 169 EncryptedKey structure, a choice of EncryptedValue and 170 EnvelopedData for migration to EnvelopedData. For reasons of 171 completeness and consistency the exchange of EncryptedValue is 172 performed for all usages in RFC 4210 [RFC4210]. This includes the 173 protection of centrally generated private keys, encryption of 174 certificates, and revocation passphrases. 176 o Adding new general message types to request CA certificates, a 177 root CA update, or a certificate request template. 179 o Extend the usage of polling also to p10cr messages. 181 < TBD: The specification of algorithm profiles seed to be moved to a 182 separate document. > 184 2.2. New Section 4.5 - Extended Key Usage 186 The following subsection describes new extended key usages for 187 different CMP server types specified in RFC 4210 [RFC4210]. 189 Insert this section at the end of the current Section 4. 191 4.5 Extended Key Usage 193 The Extended Key Usage (EKU) extension indicates the purposes for 194 which the certified public key may be used. It therefore restricts 195 the use of a certificate to specific applications. 197 A CA may want to delegate parts of their duties to other PKI 198 management entities. The mechanism to prove this delegation 199 explained in this section offers zero-touch means to check the 200 authorization of such delegation. Such delegation could also be 201 expressed by other means, e.g., explicit configuration. 203 To offer automatic validation means for the delegation of a role by a 204 CA, the certificates used by PKI management entities for CMP message 205 protection or signed data for central key generation MUST be issued 206 by the delegating CA and MUST contain the respective EKUs. This 207 proves the authorization of this entity by the delegating CA to act 208 as the PKI management entity as described below. 210 The ASN.1 to define these EKUs is: 212 id-kp OBJECT IDENTIFIER ::= 213 { iso(1) identified-organization(3) dod(6) internet(1) 214 security(5) mechanisms(5) pkix(7) kp(3) } 216 id-kp-cmcCA OBJECT IDENTIFIER ::= { id-kp 27 } 217 id-kp-cmcRA OBJECT IDENTIFIER ::= { id-kp 28 } 218 id-kp-cmKGA OBJECT IDENTIFIER ::= { id-kp 32 } 220 Note: RFC 6402 section 2.10 [RFC6402] specifies OIDs for a CMC CA and 221 a CMC RA. As the functionality of a CA and RA is not specific to 222 whether use CMC or CMP as certificate management protocol, the same 223 OIDs SHALL be used for a CMP CA and a CMP RA. 225 < TBD: The Description of the OIDs for id-kp-cmcCA and id-kp-cmcRA 226 needs to be extended to avoid confusion as they currently only refer 227 to CMC. > 229 The description of the PKI management entity for each of the EKUs is 230 as follows: 232 CMP CA: CMP Certification Authorities are CMP endpoints on CA 233 equipment as described in section 3.1.1.2. The key used in 234 the context of CMP management operations, especially CMP 235 message protection, need not be the same key that signs the 236 certificates. It is necessary, however, to ensure that the 237 entity acting as CMP CA is authorized to do so. Therefore, 238 the CMP CA MUST do one of the following, 239 * use the CA private key on the CMP endpoint, or 241 * explicitly designate this authority to another entity. 243 For automatic validation of such delegation it MUST be 244 indicated by the id-kp-cmcCA extended key usage. This 245 extended key usage MUST be placed into the certificate used 246 on the CA equipment and the CA that delegates this role MUST 247 issue the CMP CA certificate. 249 Note: Using a separate key pair for protecting CMP 250 management operations at the CA decreases the number of 251 operations of the private key used to sign certificates. 253 CMP RA: CMP Registration Authorities are CMP endpoints on RA 254 equipment as described in Section 3.1.1.3. A CMP RA is 255 identified by the id-kp-cmcRA extended key usage. This 256 extended key usage is placed into RA certificates. The CA 257 that delegated this role is identified by the CA that issued 258 the CMP RA certificate. 260 CMP KGA: CMP Key Generation Authorities are identified by the id-kp- 261 cmKGA extended key usage. Though the CMP KGA knows the 262 private key it generated on behalf of the end entity. This 263 is a very sensitive service and needs specific 264 authorization. This authorization is either with the CA 265 certificate itself, or indicated by placing the id-kp-cmKGA 266 extended key usage into the CMP RA or CMP CA certificate 267 used to authenticate the origin of the private key, and to 268 express the authorization to offer this service. 270 Note: In device PKIs, especially those issuing IDevID certificates, 271 CA may have very long validity (including the GeneralizedTime value 272 99991231235959Z to indicate a not well-defined expiration date as 273 specified in IEEE 802.1AR Section 8.5 [IEEE802.1AR] and RFC 5280 274 Section 4.1.2.5 [RFC5280]). Such validity periods SHOULD NOT be used 275 for protection of CMP messages. Certificates for delegated CMP 276 message protection (CMP CA, CMP RA, CMP KGA) MUST NOT use indefinite 277 expiration date. 279 2.3. Replace Section 5.1.3.4 - Multiple Protection 281 Section 5.1.3.4 of RFC 4210 [RFC4210] describes the nested message. 282 This document opens the usage of nested messages also for batch 283 transport of PKI messages between different PKI management entities. 285 Replace the text of the section with the following text. 287 In cases where an end entity sends a protected PKI message to an RA, 288 the RA MAY forward that message to a CA, adding its own protection 289 (which MAY be a MAC or a signature, depending on the information and 290 certificates shared between the RA and the CA). There are different 291 use cases for such multi protected messages. 293 o The RA confirms the validation and authorization of a message and 294 forwards the original message unchanged. 296 o The RA collects several messages and forwards them in a batch. 297 This can for instance be used to bridge an off-line connection 298 between two PKI management entities. In communication to the CA 299 request messages and in communication from the CA response or 300 announcement messages will be collected in such batch. 302 o The RA modifies the message(s) in some way (e.g., add or modify 303 particular field values or add new extensions) before forwarding 304 them, then it MAY create its own desired PKIBody. In case the 305 changes made by the RA to PKIMessage breaks the POP, the RA MUST 306 either set the POP RAVerified or include the original PKIMessage 307 from the EE in the generalInfo field of PKIHeader of the nested 308 message (to force the CA to check POP on the original message). 309 The infoType to be used in this situation is {id-it 15} (see 310 Section 5.3.19 for the value of id-it) and the infoValue is 311 PKIMessages (contents MUST be in the same order as the requests in 312 PKIBody). For simplicity reasons, if batching is used in 313 combination with inclusion of the original PKIMessage in the 314 generalInfo field, all messages in the batch MUST be of the same 315 type (e.g., ir). 317 These use cases are accomplished by nesting the messages sent by the 318 PKI entity within a new PKI message. The structure used is as 319 follows. 321 NestedMessageContent ::= PKIMessages 323 (The use of PKIMessages, a SEQUENCE OF PKIMessage, lets the RA batch 324 the requests of several EEs in a single new message.) 326 2.4. Replace Section 5.2.2. - Encrypted Values 328 Section 5.2.2 of RFC 4210 [RFC4210] describes the usage of 329 EncryptedValue to transport encrypted data. This document extends 330 the encryption of data to preferably use EnvelopedData. 332 Replace the text of the section with the following text. 334 Where encrypted data (restricted, in this specification, to be either 335 private keys, certificates, or passwords) are sent in PKI messages, 336 the EncryptedKey data structure is used. 338 EncryptedKey ::= CHOICE { 339 encryptedValue EncryptedValue, -- deprecated 340 envelopedData [0] EnvelopedData } 342 See CRMF [RFC4211] for EncryptedKey and EncryptedValue syntax and for 343 EnvelopedData syntax see CMS [RFC5652]. Using the EncryptedKey data 344 structure, the choice to either use EncryptedValue (for backward 345 compatibility only) or EnvelopedData is offered. The use of the 346 EncryptedValue structure has been deprecated in favor of the 347 EnvelopedData structure. Therefore, it is recommended to use 348 EnvelopedData. 350 Note: As we reuse the EncryptedKey structure defined in CRMF 351 [RFC4211], the update is backward compatible. Using the new syntax 352 with the untagged default choice EncryptedValue is bitwise compatible 353 with the old syntax. 355 The EncryptedKey data structure is used in CMP to either transport a 356 private key, certificate or revocation passphrase in encrypted form. 358 EnvelopedData is used as follows: 360 o Contains only one recepientInfo structure because the content is 361 encrypted only for one recipient. 363 o Contains a private key in the AsymmetricKeyPackage structure as 364 defined in RFC 5958 [RFC5958] wrapped in a SignedData structure as 365 specified in CMS section 5 [RFC5652] signed by the Key Generation 366 Authority. 368 o Contains a certificate or revocation passphrase directly in the 369 encryptedContent field. 371 Note: To ensure explicit control of the encoding of the private key 372 according to the specific algorithm the new key pair in an asymmetric 373 key package structure as specified in [RFC5958]. 375 The content of the EnvelopedData structure, as specified in CMS 376 section 6 [RFC5652], MUST be encrypted using a newly generated 377 symmetric content-encryption key. This content-encryption key MUST 378 be securely provided to the recipient using one of three key 379 management techniques. 381 The choice of the key management technique to be used by the sender 382 depends on the credential available for the recipient: 384 o Recipient's certificate that contains a key usage extension 385 asserting keyAgreement: The content-encryption key will be 386 protected using the key agreement key management technique, as 387 specified in CMS section 6.2.2 [RFC5652]. 389 o Recipient's certificate that contains a key usage extension 390 asserting keyEncipherment: The content-encryption key will be 391 protected using the key transport key management technique, as 392 specified in CMS section 6.2.1 [RFC5652]. 394 o Jointly shared secret: The content-encryption key will be 395 protected using the password-based key management technique, as 396 specified in CMS section 6.2.4 [RFC5652]. 398 2.5. Update Section 5.3.4. - Certification Response 400 Section 5.3.4 of RFC 4210 [RFC4210] describes the Certification 401 Response. This document updates the syntax by using the parent 402 structure EncryptedKey instead of EncryptedValue as described in 403 Section 2.1 above. 405 Replace the ASN.1 syntax of CertifiedKeyPair and CertOrEncCert with 406 the following text. 408 CertifiedKeyPair ::= SEQUENCE { 409 certOrEncCert CertOrEncCert, 410 privateKey [0] EncryptedKey OPTIONAL, 411 -- see [CRMF] for comment on encoding 412 publicationInfo [1] PKIPublicationInfo OPTIONAL 413 } 415 CertOrEncCert ::= CHOICE { 416 certificate [0] Certificate, 417 encryptedCert [1] EncryptedKey 418 } 420 Add the following paragraphs to the end of the section. 422 The use of EncryptedKey is described in section 5.2.2. 424 2.6. Update Section 5.3.19.2. - Signing Key Pair Types 426 The following section clarifies the usage of the Signing Key Pair 427 Types PKI general message on referencing EC curves. 429 Insert this note at the end of Section 5.3.19.2. 431 Note: In case you wish to offer several EC curves, you need to put 432 several id-ecPublicKey elements, one each per named curve. 434 2.7. Update Section 5.3.19.3. - Encryption/Key Agreement Key Pair Types 436 The following section clarifies the usage of the Encryption/Key 437 Agreement Key Pair Types PKI general message on referencing EC 438 curves. 440 Insert this note at the end of Section 5.3.19.3. 442 Note: In case you wish to offer several EC curves, you need to put 443 several id-ecPublicKey elements, one each per named curve. 445 2.8. Replace Section 5.3.19.9. - Revocation Passphrase 447 Section 5.3.19.9 of RFC 4210 [RFC4210] describes the provisioning of 448 a revocation passphrase for authenticating a later revocation 449 request. This document updates the handling by using the parent 450 structure EncryptedKey instead of EncryptedValue to transport this 451 information as described in Section 2.1 above. 453 Replace the text of the section with the following text. 455 This MAY be used by the EE to send a passphrase to a CA/RA for the 456 purpose of authenticating a later revocation request (in the case 457 that the appropriate signing private key is no longer available to 458 authenticate the request). See Appendix B for further details on the 459 use of this mechanism. 461 GenMsg: {id-it 12}, EncryptedKey 462 GenRep: {id-it 12}, < absent > 464 The use of EncryptedKey is described in section 5.2.2. 466 2.9. New Section 5.3.19.14 - CA Certificates 468 The following subsection describes the PKI general messages using id- 469 it-caCerts. The use is specified in in Lightweight CMP Profile [I- 470 D.ietf-lamps-lightweight-cmp-profile] Section 4.4. 472 Insert this section after Section 5.3.19.13. 474 2.3.19.14 CA Certificates 475 This MAY be used by the client to get the latest CA intermediate and 476 issuing CA certificates. 478 GenMsg: {id-it 17}, < absent > 479 GenRep: {id-it 17}, SEQUENCE OF CMPCertificate | < absent > 481 2.10. New Section 5.3.19.15 - Root CA Certificates Update 483 The following subsection describes the PKI general messages using id- 484 it-rootCaKeyUpdate. The use is specified in in Lightweight CMP 485 Profile [I-D.ietf-lamps-lightweight-cmp-profile] Section 4.4. 487 Insert this section after new Section 5.3.19.14. 489 5.3.19.15. Root CA Certificates Update 491 This MAY be used by the client to get an update of an existing root 492 CA Certificate. 494 GenMsg: {id-it 18}, < absent > 495 GenRep: {id-it 18}, RootCaKeyUpdateContent | < absent > 497 RootCaKeyUpdateContent ::= SEQUENCE { 498 newWithNew CMPCertificate 499 newWithOld [0] CMPCertificate OPTIONAL, 500 oldWithNew [1] CMPCertificate OPTIONAL 501 } 503 Note: In contrast to CAKeyUpdAnnContent, this type offers omitting 504 newWithOld and oldWithNew in the GenRep message, depending on the 505 needs of the EE. 507 2.11. New Section 5.3.19.16 - Certificate Request Template 509 The following subsection describes the PKI general messages using id- 510 it-certReqTemplate. The use is specified in in Lightweight CMP 511 Profile [I-D.ietf-lamps-lightweight-cmp-profile] Section 4.4. 513 Insert this section after new Section 5.3.19.15. 515 5.3.19.16. Certificate Request Template 517 This MAY be used by the client to get a template with parameters for 518 a future certificate request operation. 520 GenMsg: {id-it 19}, < absent > 521 GenRep: {id-it 19}, CertReqTemplateContent | < absent > 523 CertReqTemplateContent ::= SEQUENCE { 524 certTemplate CertTemplate, 525 controls Controls OPTIONAL 526 } 528 Controls ::= SEQUENCE SIZE(1..MAX) OF AttributeTypeAndValue 530 id-regCtrl-algId OBJECT IDENTIFIER ::= { id-regCtrl TBD3 } 531 AlgIdCtrl ::= AlgorithmIdentifier 533 id-regCtrl-rsaKeyLen OBJECT IDENTIFIER ::= { id-regCtrl TBD4 } 534 RsaKeyLenCtrl ::= Integer 536 < TBD: The OIDs TBD3 and TBD4 have to be registered at IANA. > 538 CertReqTemplateValue contains a prefilled certTemplate to be used for 539 the future certificate request. The SubjectPublicKeyInfo field in 540 the certTemplate MUST NOT be used. In case the PKI management entity 541 wishes to specify supported algorithms, the controls field MUST be 542 used. One AttributeTypeAndValue per supported algorithm MUST be 543 used. 545 Note: The Controls ASN.1 type is defined in CRMF Section 6 [RFC4211] 547 2.12. Update Section 5.3.22 - Polling Request and Response 549 Section 5.3.22 of RFC 4210 [RFC4210] describes when and how polling 550 messages are used. This document adds the polling mechanism also to 551 outstanding p10cr transactions. 553 Replace all paragraphs in front of the state machine diagram with the 554 following text. 556 This pair of messages is intended to handle scenarios in which the 557 client needs to poll the server in order to determine the status of 558 an outstanding ir, cr, p10cr, or kur transaction (i.e., when the 559 "waiting" PKIStatus has been received). 561 PollReqContent ::= SEQUENCE OF SEQUENCE { 562 certReqId INTEGER } 564 PollRepContent ::= SEQUENCE OF SEQUENCE { 565 certReqId INTEGER, 566 checkAfter INTEGER, -- time in seconds 567 reason PKIFreeText OPTIONAL } 569 The following clauses describe when polling messages are used, and 570 how they are used. It is assumed that multiple certConf messages can 571 be sent during transactions. There will be one sent in response to 572 each ip, cp, or kup that contains a CertStatus for an issued 573 certificate. 575 1 In response to an ip, cp, or kup message, an EE will send a 576 certConf for all issued certificates and, following the ack, a 577 pollReq for all pending certificates. 579 2 In response to a pollReq, a CA/RA will return an ip, cp, or kup if 580 one or more of the pending certificates is ready; otherwise, it 581 will return a pollRep. 583 3 If the EE receives a pollRep, it will wait for at least as long as 584 the checkAfter value before sending another pollReq. 586 4 If an ip, cp, or kup is received in response to a pollReq, then it 587 will be treated in the same way as the initial response. 589 Note: A p10cr message contains exactly one CertificationRequestInfo 590 data structure as specified in PKCS#10 [RFC2986] but no certificate 591 request number. Therefore, the certReqId MUST be set to 0 in all 592 following messages of this transaction. 594 2.13. Update Section 9 - IANA Considerations 596 Section 9 of RFC 4210 [RFC4210] contains the IANA Considerations of 597 that document. As this document defines a new and updates two 598 existing Extended Key Usages, the IANA Considerations need to be 599 updated accordingly. 601 Add the following paragraphs between the first and second paragraph 602 of the section. 604 Within the SMI-numbers registry "SMI Security for PKIX Extended Key 605 Purpose Identifiers (1.3.6.1.5.5.7.3)" (see 606 https://www.iana.org/assignments/smi-numbers/smi-numbers.xhtml#smi- 607 numbers-1.3.6.1.5.5.7.3) as defined in RFC 7299 [RFC7299] three 608 changes have been performed. 610 Two existing entries have been updated to also point to this 611 document: 613 Decimal Description References 614 ------- ----------- ------------------ 615 27 id-kp-cmcCA [RFC6402][thisRFC] 616 28 id-kp-cmcRA [RFC6402][thisRFC] 617 One new entry has been added: 619 Decimal Description References 620 ------- ----------- ---------- 621 32 id-kp-cmKGA [thisRFC] 623 Within the SMI-numbers registry "SMI Security for PKIX CMP 624 Information Types (1.3.6.1.5.5.7.4)" (see 625 https://www.iana.org/assignments/smi-numbers/smi-numbers.xhtml#smi- 626 numbers-1.3.6.1.5.5.7.4) as defined in RFC 7299 [RFC7299] three 627 changes have been performed. 629 Three new entry have been added: 631 Decimal Description References 632 ------- --------------------- ---------- 633 17 id-it-caCerts [thisRFC] 634 18 id-it-rootCaKeyUpdate [thisRFC] 635 19 id-it-certReqTemplate [thisRFC] 637 WWithin the SMI-numbers registry " SMI Security for PKIX CRMF 638 Registration Controls (1.3.6.1.5.5.7.5.1)" (see 639 https://www.iana.org/assignments/smi-numbers/smi-numbers.xhtml#smi- 640 numbers-1.3.6.1.5.5.7.5.1) as defined in RFC 7299 [RFC7299] two 641 changes have been performed. 643 Two new entry have been added: 645 Decimal Description References 646 ------- -------------------- ---------- 647 TBD3 id-regCtrl-algId [thisRFC] 648 TBD4 id-regCtrl-rsaKeyLen [thisRFC] 650 2.14. Update Appendix B - The Use of Revocation Passphrase 652 Appendix B of RFC 4210 [RFC4210] describes the usage of the 653 revocation passphrase. As this document updates RFC 4210 [RFC4210] 654 to utilize the parent structure EncryptedKey instead of 655 EncryptedValue as described in Section 2.1 above, the description is 656 updated accordingly. 658 Replace the first bullet point of this section with the following 659 text. 661 o The OID and value specified in Section 5.3.19.9 of RFC 4210 662 [RFC4210] MAY be sent in a GenMsg message at any time, or MAY be 663 sent in the generalInfo field of the PKIHeader of any PKIMessage 664 at any time. (In particular, the EncryptedKey as described in 665 section 5.2.2 may be sent in the header of the certConf message 666 that confirms acceptance of certificates requested in an 667 initialization request or certificate request message.) This 668 conveys a revocation passphrase chosen by the entity (i.e., for 669 use of EnvelopedData this is in the decrypted bytes of 670 encryptedContent field and for use of EncryptedValue this is in 671 the decrypted bytes of the encValue field) to the relevant CA/RA; 672 furthermore, the transfer is accomplished with appropriate 673 confidentiality characteristics. 675 Replace the third bullet point of this section with the following 676 text. 678 o When using EnvelopedData the localKeyId attribute as specified in 679 RFC 2985 [RFC2985] and when using EncryptedValue the valueHint 680 field MAY contain a key identifier (chosen by the entity, along 681 with the passphrase itself) to assist in later retrieval of the 682 correct passphrase (e.g., when the revocation request is 683 constructed by the entity and received by the CA/RA). 685 2.15. Update Appendix C - Request Message Behavioral Clarifications 687 Appendix C of RFC 4210 [RFC4210] provides clarifications to the 688 request message behavior. As this document updates RFC 4210 689 [RFC4210] to utilize the parent structure EncryptedKey instead of 690 EncryptedValue as described in Section 2.1 above, the description is 691 updated accordingly. 693 Replace the note coming after the ASN.1 syntax of POPOPrivKey of this 694 section with the following text. 696 -- ********** 697 -- * the type of "thisMessage" is given as BIT STRING in RFC 4211 698 -- * [RFC4211]; it should be "EncryptedKey" (in accordance with 699 -- * Section 5.2.2 of this specification). Therefore, this document 700 -- * makes the behavioral clarification of specifying that the 701 -- * contents of "thisMessage" MUST be encoded either as 702 -- * "EnvelopedData" or "EncryptedValue" (only for backward 703 -- * compatibility) and then wrapped in a BIT STRING. This allows 704 -- * the necessary conveyance and protection of the private key 705 -- * while maintaining bits-on-the-wire compatibility with RFC 4211 706 -- * [RFC4211]. 707 -- ********** 709 2.16. Update Appendix D.2. - Algorithm Use Profile 711 Appendix D.2 of RFC 4210 [RFC4210] provides a list of Algorithms 712 implementations must support when claiming conformance with PKI 713 Management Message Profiles as specified in CMP Appendix D.2 714 [RFC4210]. 716 Replace the text of the section with the following text. 718 For specifications of algorithms identifiers and respective 719 conventions for conforming implementations, please refer to CMP 720 Algorithms Appendix A.1 [I-D.ietf-lamps-cmp-algorithms]. 722 2.17. Update Appendix D.4. - Initial Registration/Certification (Basic 723 Authenticated Scheme) 725 Appendix D.4 of RFC 4210 [RFC4210] provides the initial registration/ 726 certification scheme. This scheme shall continue to use 727 EncryptedValue for backward compatibility reasons. 729 Replace the comment after the privateKey field of 730 crc[1].certifiedKeyPair in the syntax of the Initialization Response 731 message with the following text. 733 -- see Appendix C, Request Message Behavioral Clarifications 734 -- for backward compatibility reasons, use EncryptedValue 736 3. Updates to RFC 6712 - HTTP Transfer for the Certificate Management 737 Protocol (CMP) 739 3.1. New Section 1.1. - Changes since RFC 6712 741 The following subsection describes feature updates to RFC 6712 742 [RFC6712]. They are always related to the base specification. Hence 743 references to the original sections in RFC 6712 [RFC6712] are used 744 whenever possible. 746 Insert this section at the end of the current Section 1. 748 1.1 Changes since RFC 6712 750 The following updates are made in draft-ietf-lamps-cmp-updates: 752 o Add an HTTP URI discovery mechanism and extend the URI structure. 754 3.2. Replace Section 3.6. - HTTP Request-URI 756 Section 3.6 of RFC 6712 [RFC6712] specifies the used HTTP URIs. This 757 document adds a discovery mechanism and extends the URIs. 759 Replace the text of the section with the following text. 761 Each CMP server on a PKI management entity supporting HTTP or HTTPS 762 transport MUST support the use of the path-prefix of '/.well-known/' 763 as defined in RFC 8515 [RFC8515] and the registered name of 'cmp' to 764 ease interworking in a multi-vendor environment. 766 The CMP client needs to be configured with sufficient information to 767 form the CMP server URI. This is at least the authority portion of 768 the URI, e.g., 'www.example.com:80', or the full operational path of 769 the PKI management entity. Additional arbitrary label, e.g., 770 'profileLabel' and 'operationLabel', may be configured as a separate 771 component or as part of the full operational path to provide further 772 information. The 'profileLabel' may support addressing multiple CAs 773 or certificate profiles and the 'operationLabel' may support 774 addressing PKI management operation specific endpoints. A valid full 775 operational path can look like this: 777 1 http://www.example.com/.well-known/cmp 779 2 http://www.example.com/.well-known/cmp/operationLabel 781 3 http://www.example.com/.well-known/cmp/profileLabel 783 4 http://www.example.com/.well-known/cmp/profileLabel/operationLabel 785 The discovery of supported endpoints as defined above will provide 786 the information to the CMP client how to contact the PKI management 787 entity and, if available, how to request enrolment for a specific 788 certificate profile or revoke a certificate at a specific CA. 790 Querying the PKI management entity, the CMP client will get a list of 791 potential endpoints supported by the PKI management entity. 793 Performing a GET on "/.well-known/cmp" to the default port MUST 794 return a set of links to endpoints available from the CMP server. In 795 addition to the link also the expected format of the data object is 796 provided as content type (ct). 798 < TBD: It needs to be discussed if the discovery should be performed 799 using GET on "/.well-known/cmp" or GET on "/.well-known" only. > 800 The following provides an illustrative example for a PKI management 801 entity supporting various PKI management operations for various 802 certificate profiles and CAs. 804 Detailed message description: 806 REQ: GET /.well-known/cmp 808 RES: Content 809 ;ct=pkixcmp 810 ;ct=pkixcmp 811 ;ct=pkixcmp 812 ;ct=pkixcmp 813 ;ct=pkixcmp 814 ;ct=pkixcmp 815 ;ct=pkixcmp 816 ;ct=pkixcmp 818 3.3. Update Section 6. - IANA Considerations 820 Section 6 of RFC 6712 [RFC6712] contains the IANA Considerations of 821 that document. As this document defines a new well-known URI, the 822 IANA Considerations need to be updated accordingly. 824 Add the following text between the first and second paragraph of the 825 section. 827 Within the well-known URI registry (see 828 https://www.iana.org/assignments/well-known-uris/well-known- 829 uris.xhtml#well-known-uris-1) as defined in RFC 8515 [RFC8515] the 830 following change has been performed. 832 One new name entry has been added: 834 URI suffix Change controller 835 ----------- ----------------- 836 cmp IETF 838 4. IANA Considerations 840 This document contains an update to the IANA Consideration sections 841 to be added to [RFC4210] and [RFC6712]. 843 < TBD: This document updates the ASN.1 modules of RFC 4210 Appendix F 844 [RFC4210] and RFC 5912 Section 9 [RFC5912]. New OIDs TBD1 and TBD2 845 need to be registered to identify the updates ASN.1 modules. > 846 < TBD: New OIDs TBD3 (id-regCtrl-algId) and TBD4 (id-regCtrl- 847 rsaKeyLen) need to be registered. > 849 < TBD: The existing description and information of id-kp-cmcRA and 850 id-kp-cmcCA need to be updated to reflect their extended usage. > 852 5. Security Considerations 854 No changes are made to the existing security considerations of 855 RFC 4210 [RFC4210] and RFC 6712 [RFC6712]. 857 6. Acknowledgements 859 Special thank goes to Jim Schaad for his guidance and the inspiration 860 on structuring and writing this document I got from [RFC6402] that 861 updates CMC. Special thank also goes also to Russ Housley and Tomas 862 Gustavsson for reviewing and providing valuable suggestions on the 863 approvement of this document. 865 I also like to thank all reviewers of this document for their 866 valuable feedback. 868 7. References 870 7.1. Normative References 872 [I-D.ietf-lamps-cmp-algorithms] 873 Brockhaus, H., "CMP Algorithms", draft-ietf-lamps-cmp- 874 algorithms-00 (work in progress), October 2020. 876 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 877 Requirement Levels", BCP 14, RFC 2119, 878 DOI 10.17487/RFC2119, March 1997, 879 . 881 [RFC2985] Nystrom, M. and B. Kaliski, "PKCS #9: Selected Object 882 Classes and Attribute Types Version 2.0", RFC 2985, 883 DOI 10.17487/RFC2985, November 2000, 884 . 886 [RFC2986] Nystrom, M. and B. Kaliski, "PKCS #10: Certification 887 Request Syntax Specification Version 1.7", RFC 2986, 888 DOI 10.17487/RFC2986, November 2000, 889 . 891 [RFC4210] Adams, C., Farrell, S., Kause, T., and T. Mononen, 892 "Internet X.509 Public Key Infrastructure Certificate 893 Management Protocol (CMP)", RFC 4210, 894 DOI 10.17487/RFC4210, September 2005, 895 . 897 [RFC4211] Schaad, J., "Internet X.509 Public Key Infrastructure 898 Certificate Request Message Format (CRMF)", RFC 4211, 899 DOI 10.17487/RFC4211, September 2005, 900 . 902 [RFC5280] Cooper, D., Santesson, S., Farrell, S., Boeyen, S., 903 Housley, R., and W. Polk, "Internet X.509 Public Key 904 Infrastructure Certificate and Certificate Revocation List 905 (CRL) Profile", RFC 5280, DOI 10.17487/RFC5280, May 2008, 906 . 908 [RFC5652] Housley, R., "Cryptographic Message Syntax (CMS)", STD 70, 909 RFC 5652, DOI 10.17487/RFC5652, September 2009, 910 . 912 [RFC5912] Hoffman, P. and J. Schaad, "New ASN.1 Modules for the 913 Public Key Infrastructure Using X.509 (PKIX)", RFC 5912, 914 DOI 10.17487/RFC5912, June 2010, 915 . 917 [RFC5958] Turner, S., "Asymmetric Key Packages", RFC 5958, 918 DOI 10.17487/RFC5958, August 2010, 919 . 921 [RFC6402] Schaad, J., "Certificate Management over CMS (CMC) 922 Updates", RFC 6402, DOI 10.17487/RFC6402, November 2011, 923 . 925 [RFC6712] Kause, T. and M. Peylo, "Internet X.509 Public Key 926 Infrastructure -- HTTP Transfer for the Certificate 927 Management Protocol (CMP)", RFC 6712, 928 DOI 10.17487/RFC6712, September 2012, 929 . 931 [RFC7299] Housley, R., "Object Identifier Registry for the PKIX 932 Working Group", RFC 7299, DOI 10.17487/RFC7299, July 2014, 933 . 935 [RFC8174] Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC 936 2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174, 937 May 2017, . 939 [RFC8515] Jethanandani, M. and M. Reina Ortega, "URN Namespace for 940 ETSI Documents", RFC 8515, DOI 10.17487/RFC8515, February 941 2019, . 943 7.2. Informative References 945 [I-D.ietf-lamps-lightweight-cmp-profile] 946 Brockhaus, H., Fries, S., and D. Oheimb, "Lightweight CMP 947 Profile", draft-ietf-lamps-lightweight-cmp-profile-03 948 (work in progress), October 2020. 950 [IEEE802.1AR] 951 IEEE, "802.1AR Secure Device Identifier", June 2018, 952 . 955 Appendix A. ASN.1 Modules 957 A.1. 1988 ASN.1 Module 959 This section contains the updated ASN.1 module for [RFC4210]. This 960 module replaces the module in Appendix F of that document. Although 961 a 2002 ASN.1 module is provided, this remains the normative module as 962 per the policy of the PKIX working group. 964 PKIXCMP {iso(1) identified-organization(3) 965 dod(6) internet(1) security(5) mechanisms(5) pkix(7) 966 id-mod(0) id-mod-cmp2020-88(TBD1)} 968 DEFINITIONS EXPLICIT TAGS ::= 970 BEGIN 972 -- EXPORTS ALL -- 974 IMPORTS 976 Certificate, CertificateList, Extensions, AlgorithmIdentifier, 977 UTF8String, id-kp -- if required; otherwise, comment out 978 FROM PKIX1Explicit88 {iso(1) identified-organization(3) 979 dod(6) internet(1) security(5) mechanisms(5) pkix(7) 980 id-mod(0) id-pkix1-explicit-88(1)} 982 GeneralName, KeyIdentifier 983 FROM PKIX1Implicit88 {iso(1) identified-organization(3) 984 dod(6) internet(1) security(5) mechanisms(5) pkix(7) 985 id-mod(0) id-pkix1-implicit-88(2)} 987 CertTemplate, PKIPublicationInfo, EncryptedKey, CertId, 988 CertReqMessages, Controls, id-regCtrl 989 FROM PKIXCRMF-2005 {iso(1) identified-organization(3) 990 dod(6) internet(1) security(5) mechanisms(5) pkix(7) 991 id-mod(0) id-mod-crmf2005(36)} 992 -- The import of EncryptedKey is added due to the updates made 993 -- in CMP Updates [thisRFC]]. EncryptedValue does not need to 994 -- be imported anymore and is therefore removed here. 996 -- see also the behavioral clarifications to CRMF codified in 997 -- Appendix C of this specification 998 CertificationRequest 999 FROM PKCS-10 {iso(1) member-body(2) 1000 us(840) rsadsi(113549) 1001 pkcs(1) pkcs-10(10) modules(1) pkcs-10(1)} 1002 -- (specified in RFC 2986 with 1993 ASN.1 syntax and IMPLICIT 1003 -- tags). Alternatively, implementers may directly include 1004 -- the [PKCS10] syntax in this module 1006 localKeyId 1007 FROM PKCS-9 {iso(1) member-body(2) us(840) rsadsi(113549) 1008 pkcs(1) pkcs-9(9) modules(0) pkcs-9(1)} 1009 -- The import of localKeyId is added due to the updates made in 1010 -- CMP Updates [thisRFC] 1012 EnvelopedData, SignedData 1013 FROM CryptographicMessageSyntax2004 { iso(1) 1014 member-body(2) us(840) rsadsi(113549) pkcs(1) pkcs-9(9) 1015 smime(16) modules(0) cms-2004(24) } 1016 -- The import of EnvelopedData and SignedData is added due to 1017 -- the updates made in CMP Updates [thisRFC] 1019 ; 1021 -- the rest of the module contains locally-defined OIDs and 1022 -- constructs 1024 CMPCertificate ::= CHOICE { 1025 x509v3PKCert Certificate 1026 } 1027 -- This syntax, while bits-on-the-wire compatible with the 1028 -- standard X.509 definition of "Certificate", allows the 1029 -- possibility of future certificate types (such as X.509 1030 -- attribute certificates, WAP WTLS certificates, or other kinds 1031 -- of certificates) within this certificate management protocol, 1032 -- should a need ever arise to support such generality. Those 1033 -- implementations that do not foresee a need to ever support 1034 -- other certificate types MAY, if they wish, comment out the 1035 -- above structure and "un-comment" the following one prior to 1036 -- compiling this ASN.1 module. (Note that interoperability 1037 -- with implementations that don't do this will be unaffected by 1038 -- this change.) 1040 -- CMPCertificate ::= Certificate 1042 PKIMessage ::= SEQUENCE { 1043 header PKIHeader, 1044 body PKIBody, 1045 protection [0] PKIProtection OPTIONAL, 1046 extraCerts [1] SEQUENCE SIZE (1..MAX) OF CMPCertificate 1047 OPTIONAL 1048 } 1050 PKIMessages ::= SEQUENCE SIZE (1..MAX) OF PKIMessage 1052 PKIHeader ::= SEQUENCE { 1053 pvno INTEGER { cmp1999(1), cmp2000(2) }, 1054 sender GeneralName, 1055 -- identifies the sender 1056 recipient GeneralName, 1057 -- identifies the intended recipient 1058 messageTime [0] GeneralizedTime OPTIONAL, 1059 -- time of production of this message (used when sender 1060 -- believes that the transport will be "suitable"; i.e., 1061 -- that the time will still be meaningful upon receipt) 1062 protectionAlg [1] AlgorithmIdentifier OPTIONAL, 1063 -- algorithm used for calculation of protection bits 1064 senderKID [2] KeyIdentifier OPTIONAL, 1065 recipKID [3] KeyIdentifier OPTIONAL, 1066 -- to identify specific keys used for protection 1067 transactionID [4] OCTET STRING OPTIONAL, 1068 -- identifies the transaction; i.e., this will be the same in 1069 -- corresponding request, response, certConf, and PKIConf 1070 -- messages 1071 senderNonce [5] OCTET STRING OPTIONAL, 1072 recipNonce [6] OCTET STRING OPTIONAL, 1073 -- nonces used to provide replay protection, senderNonce 1074 -- is inserted by the creator of this message; recipNonce 1075 -- is a nonce previously inserted in a related message by 1076 -- the intended recipient of this message 1077 freeText [7] PKIFreeText OPTIONAL, 1078 -- this may be used to indicate context-specific instructions 1079 -- (this field is intended for human consumption) 1080 generalInfo [8] SEQUENCE SIZE (1..MAX) OF 1081 InfoTypeAndValue OPTIONAL 1083 -- this may be used to convey context-specific information 1084 -- (this field not primarily intended for human consumption) 1085 } 1087 PKIFreeText ::= SEQUENCE SIZE (1..MAX) OF UTF8String 1088 -- text encoded as UTF-8 String [RFC3629] (note: each 1089 -- UTF8String MAY include an [RFC3066] language tag 1090 -- to indicate the language of the contained text 1091 -- see [RFC2482] for details) 1093 PKIBody ::= CHOICE { -- message-specific body elements 1094 ir [0] CertReqMessages, --Initialization Request 1095 ip [1] CertRepMessage, --Initialization Response 1096 cr [2] CertReqMessages, --Certification Request 1097 cp [3] CertRepMessage, --Certification Response 1098 p10cr [4] CertificationRequest, --imported from [PKCS10] 1099 popdecc [5] POPODecKeyChallContent, --pop Challenge 1100 popdecr [6] POPODecKeyRespContent, --pop Response 1101 kur [7] CertReqMessages, --Key Update Request 1102 kup [8] CertRepMessage, --Key Update Response 1103 krr [9] CertReqMessages, --Key Recovery Request 1104 krp [10] KeyRecRepContent, --Key Recovery Response 1105 rr [11] RevReqContent, --Revocation Request 1106 rp [12] RevRepContent, --Revocation Response 1107 ccr [13] CertReqMessages, --Cross-Cert. Request 1108 ccp [14] CertRepMessage, --Cross-Cert. Response 1109 ckuann [15] CAKeyUpdAnnContent, --CA Key Update Ann. 1110 cann [16] CertAnnContent, --Certificate Ann. 1111 rann [17] RevAnnContent, --Revocation Ann. 1112 crlann [18] CRLAnnContent, --CRL Announcement 1113 pkiconf [19] PKIConfirmContent, --Confirmation 1114 nested [20] NestedMessageContent, --Nested Message 1115 genm [21] GenMsgContent, --General Message 1116 genp [22] GenRepContent, --General Response 1117 error [23] ErrorMsgContent, --Error Message 1118 certConf [24] CertConfirmContent, --Certificate confirm 1119 pollReq [25] PollReqContent, --Polling request 1120 pollRep [26] PollRepContent --Polling response 1121 } 1123 PKIProtection ::= BIT STRING 1125 ProtectedPart ::= SEQUENCE { 1126 header PKIHeader, 1127 body PKIBody 1128 } 1130 id-PasswordBasedMac OBJECT IDENTIFIER ::= {1 2 840 113533 7 66 13} 1131 PBMParameter ::= SEQUENCE { 1132 salt OCTET STRING, 1133 -- note: implementations MAY wish to limit acceptable sizes 1134 -- of this string to values appropriate for their environment 1135 -- in order to reduce the risk of denial-of-service attacks 1136 owf AlgorithmIdentifier, 1137 -- AlgId for a One-Way Function (SHA-1 recommended) 1138 iterationCount INTEGER, 1139 -- number of times the OWF is applied 1140 -- note: implementations MAY wish to limit acceptable sizes 1141 -- of this integer to values appropriate for their environment 1142 -- in order to reduce the risk of denial-of-service attacks 1143 mac AlgorithmIdentifier 1144 -- the MAC AlgId (e.g., DES-MAC, Triple-DES-MAC [PKCS11], 1145 } -- or HMAC [RFC2104, RFC2202]) 1147 id-DHBasedMac OBJECT IDENTIFIER ::= {1 2 840 113533 7 66 30} 1148 DHBMParameter ::= SEQUENCE { 1149 owf AlgorithmIdentifier, 1150 -- AlgId for a One-Way Function (SHA-1 recommended) 1151 mac AlgorithmIdentifier 1152 -- the MAC AlgId (e.g., DES-MAC, Triple-DES-MAC [PKCS11], 1153 } -- or HMAC [RFC2104, RFC2202]) 1155 NestedMessageContent ::= PKIMessages 1157 PKIStatus ::= INTEGER { 1158 accepted (0), 1159 -- you got exactly what you asked for 1160 grantedWithMods (1), 1161 -- you got something like what you asked for; the 1162 -- requester is responsible for ascertaining the differences 1163 rejection (2), 1164 -- you don't get it, more information elsewhere in the message 1165 waiting (3), 1166 -- the request body part has not yet been processed; expect to 1167 -- hear more later (note: proper handling of this status 1168 -- response MAY use the polling req/rep PKIMessages specified 1169 -- in Section 5.3.22; alternatively, polling in the underlying 1170 -- transport layer MAY have some utility in this regard) 1171 revocationWarning (4), 1172 -- this message contains a warning that a revocation is 1173 -- imminent 1174 revocationNotification (5), 1175 -- notification that a revocation has occurred 1176 keyUpdateWarning (6) 1177 -- update already done for the oldCertId specified in 1178 -- CertReqMsg 1179 } 1181 PKIFailureInfo ::= BIT STRING { 1182 -- since we can fail in more than one way! 1183 -- More codes may be added in the future if/when required. 1184 badAlg (0), 1185 -- unrecognized or unsupported Algorithm Identifier 1186 badMessageCheck (1), 1187 -- integrity check failed (e.g., signature did not verify) 1188 badRequest (2), 1189 -- transaction not permitted or supported 1190 badTime (3), 1191 -- messageTime was not sufficiently close to the system time, 1192 -- as defined by local policy 1193 badCertId (4), 1194 -- no certificate could be found matching the provided criteria 1195 badDataFormat (5), 1196 -- the data submitted has the wrong format 1197 wrongAuthority (6), 1198 -- the authority indicated in the request is different from the 1199 -- one creating the response token 1200 incorrectData (7), 1201 -- the requester's data is incorrect (for notary services) 1202 missingTimeStamp (8), 1203 -- when the timestamp is missing but should be there 1204 -- (by policy) 1205 badPOP (9), 1206 -- the proof-of-possession failed 1207 certRevoked (10), 1208 -- the certificate has already been revoked 1209 certConfirmed (11), 1210 -- the certificate has already been confirmed 1211 wrongIntegrity (12), 1212 -- invalid integrity, password based instead of signature or 1213 -- vice versa 1214 badRecipientNonce (13), 1215 -- invalid recipient nonce, either missing or wrong value 1216 timeNotAvailable (14), 1217 -- the TSA's time source is not available 1218 unacceptedPolicy (15), 1219 -- the requested TSA policy is not supported by the TSA. 1220 unacceptedExtension (16), 1221 -- the requested extension is not supported by the TSA. 1222 addInfoNotAvailable (17), 1223 -- the additional information requested could not be 1224 -- understood or is not available 1225 badSenderNonce (18), 1226 -- invalid sender nonce, either missing or wrong size 1227 badCertTemplate (19), 1228 -- invalid cert. template or missing mandatory information 1229 signerNotTrusted (20), 1230 -- signer of the message unknown or not trusted 1231 transactionIdInUse (21), 1232 -- the transaction identifier is already in use 1233 unsupportedVersion (22), 1234 -- the version of the message is not supported 1235 notAuthorized (23), 1236 -- the sender was not authorized to make the preceding 1237 -- request or perform the preceding action 1238 systemUnavail (24), 1239 -- the request cannot be handled due to system unavailability 1240 systemFailure (25), 1241 -- the request cannot be handled due to system failure 1242 duplicateCertReq (26) 1243 -- certificate cannot be issued because a duplicate 1244 -- certificate already exists 1245 } 1247 PKIStatusInfo ::= SEQUENCE { 1248 status PKIStatus, 1249 statusString PKIFreeText OPTIONAL, 1250 failInfo PKIFailureInfo OPTIONAL 1251 } 1253 OOBCert ::= CMPCertificate 1255 OOBCertHash ::= SEQUENCE { 1256 hashAlg [0] AlgorithmIdentifier OPTIONAL, 1257 certId [1] CertId OPTIONAL, 1258 hashVal BIT STRING 1259 -- hashVal is calculated over the DER encoding of the 1260 -- self-signed certificate with the identifier certID. 1261 } 1263 POPODecKeyChallContent ::= SEQUENCE OF Challenge 1264 -- One Challenge per encryption key certification request (in the 1265 -- same order as these requests appear in CertReqMessages). 1267 Challenge ::= SEQUENCE { 1268 owf AlgorithmIdentifier OPTIONAL, 1269 -- MUST be present in the first Challenge; MAY be omitted in 1270 -- any subsequent Challenge in POPODecKeyChallContent (if 1271 -- omitted, then the owf used in the immediately preceding 1272 -- Challenge is to be used). 1273 witness OCTET STRING, 1274 -- the result of applying the one-way function (owf) to a 1275 -- randomly-generated INTEGER, A. [Note that a different 1276 -- INTEGER MUST be used for each Challenge.] 1277 challenge OCTET STRING 1278 -- the encryption (under the public key for which the cert. 1279 -- request is being made) of Rand. 1280 } 1282 -- Added in CMP Updates [thisRFC] 1284 Rand ::= SEQUENCE { 1285 -- Rand is encrypted under the public key to form the challenge 1286 -- in POPODecKeyChallContent 1287 int INTEGER, 1288 -- the randomly-generated INTEGER A (above) 1289 sender GeneralName 1290 -- the sender's name (as included in PKIHeader) 1291 } 1293 POPODecKeyRespContent ::= SEQUENCE OF INTEGER 1294 -- One INTEGER per encryption key certification request (in the 1295 -- same order as these requests appear in CertReqMessages). The 1296 -- retrieved INTEGER A (above) is returned to the sender of the 1297 -- corresponding Challenge. 1299 CertRepMessage ::= SEQUENCE { 1300 caPubs [1] SEQUENCE SIZE (1..MAX) OF CMPCertificate 1301 OPTIONAL, 1302 response SEQUENCE OF CertResponse 1303 } 1305 CertResponse ::= SEQUENCE { 1306 certReqId INTEGER, 1307 -- to match this response with corresponding request (a value 1308 -- of -1 is to be used if certReqId is not specified in the 1309 -- corresponding request) 1310 status PKIStatusInfo, 1311 certifiedKeyPair CertifiedKeyPair OPTIONAL, 1312 rspInfo OCTET STRING OPTIONAL 1313 -- analogous to the id-regInfo-utf8Pairs string defined 1314 -- for regInfo in CertReqMsg [CRMF] 1315 } 1317 CertifiedKeyPair ::= SEQUENCE { 1318 certOrEncCert CertOrEncCert, 1319 privateKey [0] EncryptedKey OPTIONAL, 1320 -- see [CRMF] for comment on encoding 1321 -- Changed from Encrypted Value to EncryptedKey as a CHOICE of 1322 -- EncryptedValue and EnvelopedData due to the changes made in 1323 -- CMP Updates [thisRFC] 1324 -- Using the choice EncryptedValue is bit-compatible to the 1325 -- syntax without this change 1326 publicationInfo [1] PKIPublicationInfo OPTIONAL 1327 } 1329 CertOrEncCert ::= CHOICE { 1330 certificate [0] CMPCertificate, 1331 encryptedCert [1] EncryptedKey 1332 -- Changed from Encrypted Value to EncryptedKey as a CHOICE of 1333 -- EncryptedValue and EnvelopedData due to the changes made in 1334 -- CMP Updates [thisRFC] 1335 -- Using the choice EncryptedValue is bit-compatible to the 1336 -- syntax without this change 1337 } 1339 KeyRecRepContent ::= SEQUENCE { 1340 status PKIStatusInfo, 1341 newSigCert [0] CMPCertificate OPTIONAL, 1342 caCerts [1] SEQUENCE SIZE (1..MAX) OF 1343 CMPCertificate OPTIONAL, 1344 keyPairHist [2] SEQUENCE SIZE (1..MAX) OF 1345 CertifiedKeyPair OPTIONAL 1346 } 1348 RevReqContent ::= SEQUENCE OF RevDetails 1350 RevDetails ::= SEQUENCE { 1351 certDetails CertTemplate, 1352 -- allows requester to specify as much as they can about 1353 -- the cert. for which revocation is requested 1354 -- (e.g., for cases in which serialNumber is not available) 1355 crlEntryDetails Extensions OPTIONAL 1356 -- requested crlEntryExtensions 1357 } 1359 RevRepContent ::= SEQUENCE { 1360 status SEQUENCE SIZE (1..MAX) OF PKIStatusInfo, 1361 -- in same order as was sent in RevReqContent 1362 revCerts [0] SEQUENCE SIZE (1..MAX) OF CertId 1363 OPTIONAL, 1364 -- IDs for which revocation was requested 1365 -- (same order as status) 1366 crls [1] SEQUENCE SIZE (1..MAX) OF CertificateList 1367 OPTIONAL 1368 -- the resulting CRLs (there may be more than one) 1369 } 1370 CAKeyUpdAnnContent ::= SEQUENCE { 1371 oldWithNew CMPCertificate, -- old pub signed with new priv 1372 newWithOld CMPCertificate, -- new pub signed with old priv 1373 newWithNew CMPCertificate -- new pub signed with new priv 1374 } 1376 CertAnnContent ::= CMPCertificate 1378 RevAnnContent ::= SEQUENCE { 1379 status PKIStatus, 1380 certId CertId, 1381 willBeRevokedAt GeneralizedTime, 1382 badSinceDate GeneralizedTime, 1383 crlDetails Extensions OPTIONAL 1384 -- extra CRL details (e.g., crl number, reason, location, etc.) 1385 } 1387 CRLAnnContent ::= SEQUENCE OF CertificateList 1389 CertConfirmContent ::= SEQUENCE OF CertStatus 1391 CertStatus ::= SEQUENCE { 1392 certHash OCTET STRING, 1393 -- the hash of the certificate, using the same hash algorithm 1394 -- as is used to create and verify the certificate signature 1395 certReqId INTEGER, 1396 -- to match this confirmation with the corresponding req/rep 1397 statusInfo PKIStatusInfo OPTIONAL 1398 } 1400 PKIConfirmContent ::= NULL 1402 -- Added in CMP Updates [thisRFC] 1404 RootCaKeyUpdateContent ::= SEQUENCE { 1405 newWithNew CMPCertificate 1406 -- new root CA certificate 1407 newWithOld [0] CMPCertificate OPTIONAL, 1408 -- X.509 certificate containing the new public root CA key 1409 -- signed with the old private root CA key 1410 oldWithNew [1] CMPCertificate OPTIONAL 1411 -- X.509 certificate containing the old public root CA key 1412 -- signed with the new private root CA key 1413 } 1415 -- Added in CMP Updates [thisRFC] 1417 CertReqTemplateContent ::= SEQUENCE { 1418 certTemplate CertTemplate, 1419 -- prefilled certTemplate structure elements 1420 -- The SubjectPublicKeyInfo field in the certTemplate MUST NOT 1421 -- be used. 1422 controls Controls OPTIONAL 1423 -- MAY be used to specify supported algorithms. 1424 -- Controls ::= SEQUENCE SIZE(1..MAX) OF AttributeTypeAndValue 1425 -- as specified in CRMF (RFC4211) 1426 } 1428 id-regCtrl-algId OBJECT IDENTIFIER ::= { id-regCtrl TBD3 } 1429 AlgIdCtrl ::= AlgorithmIdentifier 1430 -- SHALL be used to specify suported algorithms other than RSA 1432 id-regCtrl-rsaKeyLen OBJECT IDENTIFIER ::= { id-regCtrl TBD4 } 1433 RsaKeyLenCtrl ::= Integer 1434 -- SHALL be used to specify suported RSA key lengths 1436 InfoTypeAndValue ::= SEQUENCE { 1437 infoType OBJECT IDENTIFIER, 1438 infoValue ANY DEFINED BY infoType OPTIONAL 1439 } 1440 -- Example InfoTypeAndValue contents include, but are not limited 1441 -- to, the following (un-comment in this ASN.1 module and use as 1442 -- appropriate for a given environment): 1443 -- 1444 -- id-it-caProtEncCert OBJECT IDENTIFIER ::= {id-it 1} 1445 -- CAProtEncCertValue ::= CMPCertificate 1446 -- id-it-signKeyPairTypes OBJECT IDENTIFIER ::= {id-it 2} 1447 -- SignKeyPairTypesValue ::= SEQUENCE OF AlgorithmIdentifier 1448 -- id-it-encKeyPairTypes OBJECT IDENTIFIER ::= {id-it 3} 1449 -- EncKeyPairTypesValue ::= SEQUENCE OF AlgorithmIdentifier 1450 -- id-it-preferredSymmAlg OBJECT IDENTIFIER ::= {id-it 4} 1451 -- PreferredSymmAlgValue ::= AlgorithmIdentifier 1452 -- id-it-caKeyUpdateInfo OBJECT IDENTIFIER ::= {id-it 5} 1453 -- CAKeyUpdateInfoValue ::= CAKeyUpdAnnContent 1454 -- id-it-currentCRL OBJECT IDENTIFIER ::= {id-it 6} 1455 -- CurrentCRLValue ::= CertificateList 1456 -- id-it-unsupportedOIDs OBJECT IDENTIFIER ::= {id-it 7} 1457 -- UnsupportedOIDsValue ::= SEQUENCE OF OBJECT IDENTIFIER 1458 -- id-it-keyPairParamReq OBJECT IDENTIFIER ::= {id-it 10} 1459 -- KeyPairParamReqValue ::= OBJECT IDENTIFIER 1460 -- id-it-keyPairParamRep OBJECT IDENTIFIER ::= {id-it 11} 1461 -- KeyPairParamRepValue ::= AlgorithmIdentifer 1462 -- id-it-revPassphrase OBJECT IDENTIFIER ::= {id-it 12} 1463 -- RevPassphraseValue ::= EncryptedKey 1464 -- -- Changed from Encrypted Value to EncryptedKey as a CHOICE 1465 -- -- of EncryptedValue and EnvelopedData due to the changes 1466 -- -- made in CMP Updates [thisRFC] 1467 -- -- Using the choice EncryptedValue is bit-compatible to the 1468 -- -- syntax without this change 1469 -- id-it-implicitConfirm OBJECT IDENTIFIER ::= {id-it 13} 1470 -- ImplicitConfirmValue ::= NULL 1471 -- id-it-confirmWaitTime OBJECT IDENTIFIER ::= {id-it 14} 1472 -- ConfirmWaitTimeValue ::= GeneralizedTime 1473 -- id-it-origPKIMessage OBJECT IDENTIFIER ::= {id-it 15} 1474 -- OrigPKIMessageValue ::= PKIMessages 1475 -- id-it-suppLangTags OBJECT IDENTIFIER ::= {id-it 16} 1476 -- SuppLangTagsValue ::= SEQUENCE OF UTF8String 1477 -- id-it-caCerts OBJECT IDENTIFIER ::= { id-it 17} 1478 -- CaCertsValue ::= SEQUENCE OF CMPCertificate 1479 -- -- id-it-caCerts added in CMP Updates [thisRFC] 1480 -- id-it-rootCaKeyUpdate OBJECT IDENTIFIER ::= { id-it 18} 1481 -- RootCaKeyUpdateValue ::= RootCaKeyUpdateContent 1482 -- -- id-it-rootCaKeyUpdate added in CMP Updates [thisRFC] 1483 -- id-it-certReqTemplate OBJECT IDENTIFIER ::= { id-it 19} 1484 -- CertReqTemplateValue ::= CertReqTemplateContent 1485 -- -- id-it-certReqTemplate added in CMP Updates [thisRFC] 1486 -- 1487 -- where 1488 -- 1489 -- id-pkix OBJECT IDENTIFIER ::= { 1490 -- iso(1) identified-organization(3) 1491 -- dod(6) internet(1) security(5) mechanisms(5) pkix(7)} 1492 -- and 1493 -- id-it OBJECT IDENTIFIER ::= {id-pkix 4} 1494 -- 1495 -- 1496 -- This construct MAY also be used to define new PKIX Certificate 1497 -- Management Protocol request and response messages, or general- 1498 -- purpose (e.g., announcement) messages for future needs or for 1499 -- specific environments. 1501 GenMsgContent ::= SEQUENCE OF InfoTypeAndValue 1503 -- May be sent by EE, RA, or CA (depending on message content). 1504 -- The OPTIONAL infoValue parameter of InfoTypeAndValue will 1505 -- typically be omitted for some of the examples given above. 1506 -- The receiver is free to ignore any contained OBJ. IDs that it 1507 -- does not recognize. If sent from EE to CA, the empty set 1508 -- indicates that the CA may send 1509 -- any/all information that it wishes. 1511 GenRepContent ::= SEQUENCE OF InfoTypeAndValue 1512 -- Receiver MAY ignore any contained OIDs that it does not 1513 -- recognize. 1515 ErrorMsgContent ::= SEQUENCE { 1516 pKIStatusInfo PKIStatusInfo, 1517 errorCode INTEGER OPTIONAL, 1518 -- implementation-specific error codes 1519 errorDetails PKIFreeText OPTIONAL 1520 -- implementation-specific error details 1521 } 1523 PollReqContent ::= SEQUENCE OF SEQUENCE { 1524 certReqId INTEGER 1525 } 1527 PollRepContent ::= SEQUENCE OF SEQUENCE { 1528 certReqId INTEGER, 1529 checkAfter INTEGER, -- time in seconds 1530 reason PKIFreeText OPTIONAL 1531 } 1533 -- 1534 -- Extended Key Usage extension for PKI entities used in CMP 1535 -- operations, added due to the changes made in 1536 -- CMP Updates [thisRFC] 1537 -- The EKUs for the CA and RA are reused from CMC as defined in 1538 -- [RFC6402] 1539 -- 1541 -- id-kp-cmcCA OBJECT IDENTIFIER ::= { id-kp 27 } 1542 -- id-kp-cmcRA OBJECT IDENTIFIER ::= { id-kp 28 } 1543 id-kp-cmKGA OBJECT IDENTIFIER ::= { id-kp 32 } 1545 END -- of CMP module 1547 A.2. 2002 ASN.1 Module 1549 This section contains the updated 2002 ASN.1 module for [RFC5912]. 1550 This module replaces the module in Section 9 of that document. The 1551 module contains those changes that were done to update to 2002 ASN.1 1552 standard done in [RFC5912] as well as changes made for this document. 1554 < TBD: Dose this document then also updates [RFC5912]? > 1556 PKIXCMP-2009 1557 { iso(1) identified-organization(3) dod(6) internet(1) 1558 security(5) mechanisms(5) pkix(7) id-mod(0) 1559 id-mod-cmp2020-02(TBD2) } 1560 DEFINITIONS EXPLICIT TAGS ::= 1561 BEGIN 1562 IMPORTS 1563 AttributeSet{}, Extensions{}, EXTENSION, ATTRIBUTE 1564 FROM PKIX-CommonTypes-2009 1565 {iso(1) identified-organization(3) dod(6) internet(1) security(5) 1566 mechanisms(5) pkix(7) id-mod(0) id-mod-pkixCommon-02(57)} 1568 AlgorithmIdentifier{}, SIGNATURE-ALGORITHM, ALGORITHM, 1569 DIGEST-ALGORITHM, MAC-ALGORITHM 1570 FROM AlgorithmInformation-2009 1571 {iso(1) identified-organization(3) dod(6) internet(1) security(5) 1572 mechanisms(5) pkix(7) id-mod(0) 1573 id-mod-algorithmInformation-02(58)} 1575 Certificate, CertificateList, id-kp 1576 FROM PKIX1Explicit-2009 1577 {iso(1) identified-organization(3) dod(6) internet(1) security(5) 1578 mechanisms(5) pkix(7) id-mod(0) id-mod-pkix1-explicit-02(51)} 1580 GeneralName, KeyIdentifier 1581 FROM PKIX1Implicit-2009 1582 {iso(1) identified-organization(3) dod(6) internet(1) security(5) 1583 mechanisms(5) pkix(7) id-mod(0) id-mod-pkix1-implicit-02(59)} 1585 CertTemplate, PKIPublicationInfo, EncryptedKey, CertId, 1586 CertReqMessages, Controls, id-regCtrl 1587 FROM PKIXCRMF-2009 1588 { iso(1) identified-organization(3) dod(6) internet(1) 1589 security(5) mechanisms(5) pkix(7) id-mod(0) 1590 id-mod-crmf2005-02(55) } 1591 -- The import of EncryptedKey is added due to the updates made 1592 -- in CMP Updates [thisRFC]. EncryptedValue does not need to 1593 -- be imported anymore and is therefore removed here. 1595 -- see also the behavioral clarifications to CRMF codified in 1596 -- Appendix C of this specification 1598 CertificationRequest 1599 FROM PKCS-10 1600 {iso(1) identified-organization(3) dod(6) internet(1) security(5) 1601 mechanisms(5) pkix(7) id-mod(0) id-mod-pkcs10-2009(69)} 1602 -- (specified in RFC 2986 with 1993 ASN.1 syntax and IMPLICIT 1603 -- tags). Alternatively, implementers may directly include 1604 -- the [PKCS10] syntax in this module 1606 localKeyId 1607 FROM PKCS-9 1608 {iso(1) member-body(2) us(840) rsadsi(113549) pkcs(1) pkcs-9(9) 1609 modules(0) pkcs-9(1)} 1610 -- The import of localKeyId is added due to the updates made in 1611 -- CMP Updates [thisRFC] 1613 EnvelopedData, SignedData 1614 FROM CryptographicMessageSyntax-2009 1615 {iso(1) member-body(2) us(840) rsadsi(113549) pkcs(1) pkcs-9(9) 1616 smime(16) modules(0) id-mod-cms-2004-02(41)} 1617 -- The import of EnvelopedData and SignedData is added due to 1618 -- the updates made in CMP Updates [thisRFC] 1619 ; 1621 -- the rest of the module contains locally defined OIDs and 1622 -- constructs 1624 CMPCertificate ::= CHOICE { x509v3PKCert Certificate, ... } 1625 -- This syntax, while bits-on-the-wire compatible with the 1626 -- standard X.509 definition of "Certificate", allows the 1627 -- possibility of future certificate types (such as X.509 1628 -- attribute certificates, WAP WTLS certificates, or other kinds 1629 -- of certificates) within this certificate management protocol, 1630 -- should a need ever arise to support such generality. Those 1631 -- implementations that do not foresee a need to ever support 1632 -- other certificate types MAY, if they wish, comment out the 1633 -- above structure and "uncomment" the following one prior to 1634 -- compiling this ASN.1 module. (Note that interoperability 1635 -- with implementations that don't do this will be unaffected by 1636 -- this change.) 1638 -- CMPCertificate ::= Certificate 1640 PKIMessage ::= SEQUENCE { 1641 header PKIHeader, 1642 body PKIBody, 1643 protection [0] PKIProtection OPTIONAL, 1644 extraCerts [1] SEQUENCE SIZE (1..MAX) OF CMPCertificate 1645 OPTIONAL } 1647 PKIMessages ::= SEQUENCE SIZE (1..MAX) OF PKIMessage 1649 PKIHeader ::= SEQUENCE { 1650 pvno INTEGER { cmp1999(1), cmp2000(2) }, 1651 sender GeneralName, 1652 -- identifies the sender 1653 recipient GeneralName, 1654 -- identifies the intended recipient 1655 messageTime [0] GeneralizedTime OPTIONAL, 1656 -- time of production of this message (used when sender 1657 -- believes that the transport will be "suitable"; i.e., 1658 -- that the time will still be meaningful upon receipt) 1659 protectionAlg [1] AlgorithmIdentifier{ALGORITHM, {...}} 1660 OPTIONAL, 1661 -- algorithm used for calculation of protection bits 1662 senderKID [2] KeyIdentifier OPTIONAL, 1663 recipKID [3] KeyIdentifier OPTIONAL, 1664 -- to identify specific keys used for protection 1665 transactionID [4] OCTET STRING OPTIONAL, 1666 -- identifies the transaction; i.e., this will be the same in 1667 -- corresponding request, response, certConf, and PKIConf 1668 -- messages 1669 senderNonce [5] OCTET STRING OPTIONAL, 1670 recipNonce [6] OCTET STRING OPTIONAL, 1671 -- nonces used to provide replay protection, senderNonce 1672 -- is inserted by the creator of this message; recipNonce 1673 -- is a nonce previously inserted in a related message by 1674 -- the intended recipient of this message 1675 freeText [7] PKIFreeText OPTIONAL, 1676 -- this may be used to indicate context-specific instructions 1677 -- (this field is intended for human consumption) 1678 generalInfo [8] SEQUENCE SIZE (1..MAX) OF 1679 InfoTypeAndValue OPTIONAL 1680 -- this may be used to convey context-specific information 1681 -- (this field not primarily intended for human consumption) 1682 } 1684 PKIFreeText ::= SEQUENCE SIZE (1..MAX) OF UTF8String 1685 -- text encoded as UTF-8 String [RFC3629] (note: each 1686 -- UTF8String MAY include an [RFC3066] language tag 1687 -- to indicate the language of the contained text; 1688 -- see [RFC2482] for details) 1690 PKIBody ::= CHOICE { -- message-specific body elements 1691 ir [0] CertReqMessages, --Initialization Request 1692 ip [1] CertRepMessage, --Initialization Response 1693 cr [2] CertReqMessages, --Certification Request 1694 cp [3] CertRepMessage, --Certification Response 1695 p10cr [4] CertificationRequest, --imported from [PKCS10] 1696 popdecc [5] POPODecKeyChallContent, --pop Challenge 1697 popdecr [6] POPODecKeyRespContent, --pop Response 1698 kur [7] CertReqMessages, --Key Update Request 1699 kup [8] CertRepMessage, --Key Update Response 1700 krr [9] CertReqMessages, --Key Recovery Request 1701 krp [10] KeyRecRepContent, --Key Recovery Response 1702 rr [11] RevReqContent, --Revocation Request 1703 rp [12] RevRepContent, --Revocation Response 1704 ccr [13] CertReqMessages, --Cross-Cert. Request 1705 ccp [14] CertRepMessage, --Cross-Cert. Response 1706 ckuann [15] CAKeyUpdAnnContent, --CA Key Update Ann. 1708 cann [16] CertAnnContent, --Certificate Ann. 1709 rann [17] RevAnnContent, --Revocation Ann. 1710 crlann [18] CRLAnnContent, --CRL Announcement 1711 pkiconf [19] PKIConfirmContent, --Confirmation 1712 nested [20] NestedMessageContent, --Nested Message 1713 genm [21] GenMsgContent, --General Message 1714 genp [22] GenRepContent, --General Response 1715 error [23] ErrorMsgContent, --Error Message 1716 certConf [24] CertConfirmContent, --Certificate confirm 1717 pollReq [25] PollReqContent, --Polling request 1718 pollRep [26] PollRepContent --Polling response 1719 } 1721 PKIProtection ::= BIT STRING 1723 ProtectedPart ::= SEQUENCE { 1724 header PKIHeader, 1725 body PKIBody } 1727 id-PasswordBasedMac OBJECT IDENTIFIER ::= { iso(1) member-body(2) 1728 usa(840) nt(113533) nsn(7) algorithms(66) 13 } 1729 PBMParameter ::= SEQUENCE { 1730 salt OCTET STRING, 1731 -- note: implementations MAY wish to limit acceptable sizes 1732 -- of this string to values appropriate for their environment 1733 -- in order to reduce the risk of denial-of-service attacks 1734 owf AlgorithmIdentifier{DIGEST-ALGORITHM, {...}}, 1735 -- AlgId for a One-Way Function (SHA-1 recommended) 1736 iterationCount INTEGER, 1737 -- number of times the OWF is applied 1738 -- note: implementations MAY wish to limit acceptable sizes 1739 -- of this integer to values appropriate for their environment 1740 -- in order to reduce the risk of denial-of-service attacks 1741 mac AlgorithmIdentifier{MAC-ALGORITHM, {...}} 1742 -- the MAC AlgId (e.g., DES-MAC, Triple-DES-MAC [PKCS11], 1743 -- or HMAC [RFC2104, RFC2202]) 1744 } 1746 id-DHBasedMac OBJECT IDENTIFIER ::= { iso(1) member-body(2) 1747 usa(840) nt(113533) nsn(7) algorithms(66) 30 } 1748 DHBMParameter ::= SEQUENCE { 1749 owf AlgorithmIdentifier{DIGEST-ALGORITHM, {...}}, 1750 -- AlgId for a One-Way Function (SHA-1 recommended) 1751 mac AlgorithmIdentifier{MAC-ALGORITHM, {...}} 1752 -- the MAC AlgId (e.g., DES-MAC, Triple-DES-MAC [PKCS11], 1753 -- or HMAC [RFC2104, RFC2202]) 1754 } 1755 PKIStatus ::= INTEGER { 1756 accepted (0), 1757 -- you got exactly what you asked for 1758 grantedWithMods (1), 1759 -- you got something like what you asked for; the 1760 -- requester is responsible for ascertaining the differences 1761 rejection (2), 1762 -- you don't get it, more information elsewhere in the message 1763 waiting (3), 1764 -- the request body part has not yet been processed; expect to 1765 -- hear more later (note: proper handling of this status 1766 -- response MAY use the polling req/rep PKIMessages specified 1767 -- in Section 5.3.22; alternatively, polling in the underlying 1768 -- transport layer MAY have some utility in this regard) 1769 revocationWarning (4), 1770 -- this message contains a warning that a revocation is 1771 -- imminent 1772 revocationNotification (5), 1773 -- notification that a revocation has occurred 1774 keyUpdateWarning (6) 1775 -- update already done for the oldCertId specified in 1776 -- CertReqMsg 1777 } 1779 PKIFailureInfo ::= BIT STRING { 1780 -- since we can fail in more than one way! 1781 -- More codes may be added in the future if/when required. 1782 badAlg (0), 1783 -- unrecognized or unsupported Algorithm Identifier 1784 badMessageCheck (1), 1785 -- integrity check failed (e.g., signature did not verify) 1786 badRequest (2), 1787 -- transaction not permitted or supported 1788 badTime (3), 1789 -- messageTime was not sufficiently close to the system time, 1790 -- as defined by local policy 1791 badCertId (4), 1792 -- no certificate could be found matching the provided criteria 1793 badDataFormat (5), 1794 -- the data submitted has the wrong format 1795 wrongAuthority (6), 1796 -- the authority indicated in the request is different from the 1797 -- one creating the response token 1798 incorrectData (7), 1799 -- the requester's data is incorrect (for notary services) 1800 missingTimeStamp (8), 1801 -- when the timestamp is missing but should be there 1802 -- (by policy) 1803 badPOP (9), 1804 -- the proof-of-possession failed 1805 certRevoked (10), 1806 -- the certificate has already been revoked 1807 certConfirmed (11), 1808 -- the certificate has already been confirmed 1809 wrongIntegrity (12), 1810 -- invalid integrity, password based instead of signature or 1811 -- vice versa 1812 badRecipientNonce (13), 1813 -- invalid recipient nonce, either missing or wrong value 1814 timeNotAvailable (14), 1815 -- the TSA's time source is not available 1816 unacceptedPolicy (15), 1817 -- the requested TSA policy is not supported by the TSA 1818 unacceptedExtension (16), 1819 -- the requested extension is not supported by the TSA 1820 addInfoNotAvailable (17), 1821 -- the additional information requested could not be 1822 -- understood or is not available 1823 badSenderNonce (18), 1824 -- invalid sender nonce, either missing or wrong size 1825 badCertTemplate (19), 1826 -- invalid cert. template or missing mandatory information 1827 signerNotTrusted (20), 1828 -- signer of the message unknown or not trusted 1829 transactionIdInUse (21), 1830 -- the transaction identifier is already in use 1831 unsupportedVersion (22), 1832 -- the version of the message is not supported 1833 notAuthorized (23), 1834 -- the sender was not authorized to make the preceding 1835 -- request or perform the preceding action 1836 systemUnavail (24), 1837 -- the request cannot be handled due to system unavailability 1838 systemFailure (25), 1839 -- the request cannot be handled due to system failure 1840 duplicateCertReq (26) 1841 -- certificate cannot be issued because a duplicate 1842 -- certificate already exists 1843 } 1845 PKIStatusInfo ::= SEQUENCE { 1846 status PKIStatus, 1847 statusString PKIFreeText OPTIONAL, 1848 failInfo PKIFailureInfo OPTIONAL } 1850 OOBCert ::= CMPCertificate 1851 OOBCertHash ::= SEQUENCE { 1852 hashAlg [0] AlgorithmIdentifier{DIGEST-ALGORITHM, {...}} 1853 OPTIONAL, 1854 certId [1] CertId OPTIONAL, 1855 hashVal BIT STRING 1856 -- hashVal is calculated over the DER encoding of the 1857 -- self-signed certificate with the identifier certID. 1858 } 1860 POPODecKeyChallContent ::= SEQUENCE OF Challenge 1861 -- One Challenge per encryption key certification request (in the 1862 -- same order as these requests appear in CertReqMessages). 1864 Challenge ::= SEQUENCE { 1865 owf AlgorithmIdentifier{DIGEST-ALGORITHM, {...}} 1866 OPTIONAL, 1867 -- MUST be present in the first Challenge; MAY be omitted in 1868 -- any subsequent Challenge in POPODecKeyChallContent (if 1869 -- omitted, then the owf used in the immediately preceding 1870 -- Challenge is to be used). 1871 witness OCTET STRING, 1872 -- the result of applying the one-way function (owf) to a 1873 -- randomly-generated INTEGER, A. [Note that a different 1874 -- INTEGER MUST be used for each Challenge.] 1875 challenge OCTET STRING 1876 -- the encryption (under the public key for which the cert. 1877 -- request is being made) of Rand. 1878 } 1880 -- Added in CMP Updates [thisRFC] 1882 Rand ::= SEQUENCE { 1883 -- Rand is encrypted under the public key to form the challenge 1884 -- in POPODecKeyChallContent 1885 int INTEGER, 1886 -- the randomly-generated INTEGER A (above) 1887 sender GeneralName 1888 -- the sender's name (as included in PKIHeader) 1889 } 1891 POPODecKeyRespContent ::= SEQUENCE OF INTEGER 1892 -- One INTEGER per encryption key certification request (in the 1893 -- same order as these requests appear in CertReqMessages). The 1894 -- retrieved INTEGER A (above) is returned to the sender of the 1895 -- corresponding Challenge. 1897 CertRepMessage ::= SEQUENCE { 1898 caPubs [1] SEQUENCE SIZE (1..MAX) OF CMPCertificate 1899 OPTIONAL, 1900 response SEQUENCE OF CertResponse } 1902 CertResponse ::= SEQUENCE { 1903 certReqId INTEGER, 1904 -- to match this response with the corresponding request (a value 1905 -- of -1 is to be used if certReqId is not specified in the 1906 -- corresponding request) 1907 status PKIStatusInfo, 1908 certifiedKeyPair CertifiedKeyPair OPTIONAL, 1909 rspInfo OCTET STRING OPTIONAL 1910 -- analogous to the id-regInfo-utf8Pairs string defined 1911 -- for regInfo in CertReqMsg [RFC4211] 1912 } 1914 CertifiedKeyPair ::= SEQUENCE { 1915 certOrEncCert CertOrEncCert, 1916 privateKey [0] EncryptedKey OPTIONAL, 1917 -- see [RFC4211] for comment on encoding 1918 -- Changed from Encrypted Value to EncryptedKey as a CHOICE of 1919 -- EncryptedValue and EnvelopedData due to the changes made in 1920 -- CMP Updates [thisRFC] 1921 -- Using the choice EncryptedValue is bit-compatible to the 1922 -- syntax without this change 1923 publicationInfo [1] PKIPublicationInfo OPTIONAL } 1925 CertOrEncCert ::= CHOICE { 1926 certificate [0] CMPCertificate, 1927 encryptedCert [1] EncryptedKey 1928 -- Changed from Encrypted Value to EncryptedKey as a CHOICE of 1929 -- EncryptedValue and EnvelopedData due to the changes made in 1930 -- CMP Updates [thisRFC] 1931 -- Using the choice EncryptedValue is bit-compatible to the 1932 -- syntax without this change 1933 } 1935 KeyRecRepContent ::= SEQUENCE { 1936 status PKIStatusInfo, 1937 newSigCert [0] CMPCertificate OPTIONAL, 1938 caCerts [1] SEQUENCE SIZE (1..MAX) OF 1939 CMPCertificate OPTIONAL, 1940 keyPairHist [2] SEQUENCE SIZE (1..MAX) OF 1941 CertifiedKeyPair OPTIONAL } 1943 RevReqContent ::= SEQUENCE OF RevDetails 1945 RevDetails ::= SEQUENCE { 1946 certDetails CertTemplate, 1947 -- allows requester to specify as much as they can about 1948 -- the cert. for which revocation is requested 1949 -- (e.g., for cases in which serialNumber is not available) 1950 crlEntryDetails Extensions{{...}} OPTIONAL 1951 -- requested crlEntryExtensions 1952 } 1954 RevRepContent ::= SEQUENCE { 1955 status SEQUENCE SIZE (1..MAX) OF PKIStatusInfo, 1956 -- in same order as was sent in RevReqContent 1957 revCerts [0] SEQUENCE SIZE (1..MAX) OF CertId OPTIONAL, 1958 -- IDs for which revocation was requested 1959 -- (same order as status) 1960 crls [1] SEQUENCE SIZE (1..MAX) OF CertificateList OPTIONAL 1961 -- the resulting CRLs (there may be more than one) 1962 } 1964 CAKeyUpdAnnContent ::= SEQUENCE { 1965 oldWithNew CMPCertificate, -- old pub signed with new priv 1966 newWithOld CMPCertificate, -- new pub signed with old priv 1967 newWithNew CMPCertificate -- new pub signed with new priv 1968 } 1970 CertAnnContent ::= CMPCertificate 1972 RevAnnContent ::= SEQUENCE { 1973 status PKIStatus, 1974 certId CertId, 1975 willBeRevokedAt GeneralizedTime, 1976 badSinceDate GeneralizedTime, 1977 crlDetails Extensions{{...}} OPTIONAL 1978 -- extra CRL details (e.g., crl number, reason, location, etc.) 1979 } 1981 CRLAnnContent ::= SEQUENCE OF CertificateList 1982 PKIConfirmContent ::= NULL 1984 NestedMessageContent ::= PKIMessages 1986 -- Added in CMP Updates [thisRFC] 1988 RootCaKeyUpdateContent ::= SEQUENCE { 1989 newWithNew CMPCertificate 1990 -- new root CA certificate 1991 newWithOld [0] CMPCertificate OPTIONAL, 1992 -- X.509 certificate containing the new public root CA key 1993 -- signed with the old private root CA key 1994 oldWithNew [1] CMPCertificate OPTIONAL 1995 -- X.509 certificate containing the old public root CA key 1996 -- signed with the new private root CA key 1997 } 1999 -- Added in CMP Updates [thisRFC] 2001 CertReqTemplateContent ::= SEQUENCE { 2002 certTemplate CertTemplate, 2003 -- prefilled certTemplate structure elements 2004 -- The SubjectPublicKeyInfo field in the certTemplate MUST NOT 2005 -- be used. 2006 controls Controls OPTIONAL 2007 -- MAY be used to specify supported algorithms. 2008 -- Controls ::= SEQUENCE SIZE(1..MAX) OF AttributeTypeAndValue 2009 -- as specified in CRMF (RFC4211) 2010 } 2012 id-regCtrl-algId OBJECT IDENTIFIER ::= { id-regCtrl TBD3 } 2013 AlgIdCtrl ::= AlgorithmIdentifier 2014 -- SHALL be used to specify suported algorithms other than RSA 2016 id-regCtrl-rsaKeyLen OBJECT IDENTIFIER ::= { id-regCtrl TBD4 } 2017 RsaKeyLenCtrl ::= Integer 2018 -- SHALL be used to specify suported RSA key lengths 2020 INFO-TYPE-AND-VALUE ::= TYPE-IDENTIFIER 2022 InfoTypeAndValue ::= SEQUENCE { 2023 infoType INFO-TYPE-AND-VALUE. 2024 &id({SupportedInfoSet}), 2025 infoValue INFO-TYPE-AND-VALUE. 2026 &Type({SupportedInfoSet}{@infoType}) } 2028 SupportedInfoSet INFO-TYPE-AND-VALUE ::= { ... } 2030 -- Example InfoTypeAndValue contents include, but are not limited 2031 -- to, the following (uncomment in this ASN.1 module and use as 2032 -- appropriate for a given environment): 2033 -- 2034 -- id-it-caProtEncCert OBJECT IDENTIFIER ::= {id-it 1} 2035 -- CAProtEncCertValue ::= CMPCertificate 2036 -- id-it-signKeyPairTypes OBJECT IDENTIFIER ::= {id-it 2} 2037 -- SignKeyPairTypesValue ::= SEQUENCE OF 2038 -- AlgorithmIdentifier{{...}} 2039 -- id-it-encKeyPairTypes OBJECT IDENTIFIER ::= {id-it 3} 2040 -- EncKeyPairTypesValue ::= SEQUENCE OF 2041 -- AlgorithmIdentifier{{...}} 2042 -- id-it-preferredSymmAlg OBJECT IDENTIFIER ::= {id-it 4} 2043 -- PreferredSymmAlgValue ::= AlgorithmIdentifier{{...}} 2044 -- id-it-caKeyUpdateInfo OBJECT IDENTIFIER ::= {id-it 5} 2045 -- CAKeyUpdateInfoValue ::= CAKeyUpdAnnContent 2046 -- id-it-currentCRL OBJECT IDENTIFIER ::= {id-it 6} 2047 -- CurrentCRLValue ::= CertificateList 2048 -- id-it-unsupportedOIDs OBJECT IDENTIFIER ::= {id-it 7} 2049 -- UnsupportedOIDsValue ::= SEQUENCE OF OBJECT IDENTIFIER 2050 -- id-it-keyPairParamReq OBJECT IDENTIFIER ::= {id-it 10} 2051 -- KeyPairParamReqValue ::= OBJECT IDENTIFIER 2052 -- id-it-keyPairParamRep OBJECT IDENTIFIER ::= {id-it 11} 2053 -- KeyPairParamRepValue ::= AlgorithmIdentifer 2054 -- id-it-revPassphrase OBJECT IDENTIFIER ::= {id-it 12} 2055 -- RevPassphraseValue ::= EncryptedKey 2056 -- -- Changed from Encrypted Value to EncryptedKey as a CHOICE 2057 -- -- of EncryptedValue and EnvelopedData due to the changes 2058 -- -- made in CMP Updates [thisRFC] 2059 -- -- Using the choice EncryptedValue is bit-compatible to 2060 -- -- the syntax without this change 2061 -- id-it-implicitConfirm OBJECT IDENTIFIER ::= {id-it 13} 2062 -- ImplicitConfirmValue ::= NULL 2063 -- id-it-confirmWaitTime OBJECT IDENTIFIER ::= {id-it 14} 2064 -- ConfirmWaitTimeValue ::= GeneralizedTime 2065 -- id-it-origPKIMessage OBJECT IDENTIFIER ::= {id-it 15} 2066 -- OrigPKIMessageValue ::= PKIMessages 2067 -- id-it-suppLangTags OBJECT IDENTIFIER ::= {id-it 16} 2068 -- SuppLangTagsValue ::= SEQUENCE OF UTF8String 2069 -- id-it-caCerts OBJECT IDENTIFIER ::= { id-it 17} 2070 -- CaCertsValue ::= SEQUENCE OF CMPCertificate 2071 -- -- id-it-caCerts added in CMP Updates [thisRFC] 2072 -- id-it-rootCaKeyUpdate OBJECT IDENTIFIER ::= { id-it 18} 2073 -- RootCaKeyUpdateValue ::= RootCaKeyUpdateContent 2074 -- -- id-it-rootCaKeyUpdate added in CMP Updates [thisRFC] 2075 -- id-it-certReqTemplate OBJECT IDENTIFIER ::= { id-it 19} 2076 -- CertReqTemplateValue ::= CertReqTemplateContent 2077 -- -- id-it-certReqTemplate added in CMP Updates [thisRFC] 2078 -- 2079 -- where 2080 -- 2081 -- id-pkix OBJECT IDENTIFIER ::= { 2082 -- iso(1) identified-organization(3) 2083 -- dod(6) internet(1) security(5) mechanisms(5) pkix(7)} 2084 -- and 2085 -- id-it OBJECT IDENTIFIER ::= {id-pkix 4} 2086 -- 2087 -- 2088 -- This construct MAY also be used to define new PKIX Certificate 2089 -- Management Protocol request and response messages, or general- 2090 -- purpose (e.g., announcement) messages for future needs or for 2091 -- specific environments. 2093 GenMsgContent ::= SEQUENCE OF InfoTypeAndValue 2095 -- May be sent by EE, RA, or CA (depending on message content). 2096 -- The OPTIONAL infoValue parameter of InfoTypeAndValue will 2097 -- typically be omitted for some of the examples given above. 2098 -- The receiver is free to ignore any contained OBJECT IDs that it 2099 -- does not recognize. If sent from EE to CA, the empty set 2100 -- indicates that the CA may send 2101 -- any/all information that it wishes. 2103 GenRepContent ::= SEQUENCE OF InfoTypeAndValue 2104 -- Receiver MAY ignore any contained OIDs that it does not 2105 -- recognize. 2107 ErrorMsgContent ::= SEQUENCE { 2108 pKIStatusInfo PKIStatusInfo, 2109 errorCode INTEGER OPTIONAL, 2110 -- implementation-specific error codes 2111 errorDetails PKIFreeText OPTIONAL 2112 -- implementation-specific error details 2113 } 2115 CertConfirmContent ::= SEQUENCE OF CertStatus 2117 CertStatus ::= SEQUENCE { 2118 certHash OCTET STRING, 2119 -- the hash of the certificate, using the same hash algorithm 2120 -- as is used to create and verify the certificate signature 2121 certReqId INTEGER, 2122 -- to match this confirmation with the corresponding req/rep 2123 statusInfo PKIStatusInfo OPTIONAL } 2125 PollReqContent ::= SEQUENCE OF SEQUENCE { 2126 certReqId INTEGER } 2128 PollRepContent ::= SEQUENCE OF SEQUENCE { 2129 certReqId INTEGER, 2130 checkAfter INTEGER, -- time in seconds 2131 reason PKIFreeText OPTIONAL } 2133 -- 2134 -- Extended Key Usage extension for PKI entities used in CMP 2135 -- operations, added due to the changes made in 2136 -- CMP Updates [thisRFC] 2137 -- The EKUs for the CA and RA are reused from CMC as defined in 2138 -- [RFC6402] 2139 -- 2141 -- id-kp-cmcCA OBJECT IDENTIFIER ::= { id-kp 27 } 2142 -- id-kp-cmcRA OBJECT IDENTIFIER ::= { id-kp 28 } 2143 id-kp-cmKGA OBJECT IDENTIFIER ::= { id-kp 32 } 2145 END 2147 Appendix B. History of changes 2149 Note: This appendix will be deleted in the final version of the 2150 document. 2152 From version 05 -> 06: 2154 o Added the update of Appendix D.2 with the reference to the new CMP 2155 Algorithms document as decided in IETF 108 2157 o Updated the IANA considerations to register new OIDs for id- 2158 regCtrl-algId and d-regCtrl-rsaKeyLen. 2160 o Minor changes and corrections 2162 From version 04 -> 05: 2164 o Added Section 2.6 and Section 2.7 to clarify the usage of these 2165 general messages types with EC curves (see thread 2166 "AlgorithmIdentifier parameters NULL value - Re: InfoTypeAndValue 2167 in CMP headers") 2169 o Split former section 2.7 on adding 'CA Certificates', 'Root CA 2170 Certificates Update', and 'Certificate Request Template' in three 2171 separate sections for easier readability 2173 o Changed in Section 2.10 the ASN.1 syntax of CertReqTemplateValue 2174 from using reaKeyLen to usage of controls as specified in CRMF 2175 Section 6 [RFC4211] (see thread "dtaft-ietf-lamps-cmp-updates and 2176 rsaKeyLen") 2178 o Updated the IANA considerations in Section 2.13 to introduce new 2179 OID for id-regCtrl-algId and id-regCtrl-rsaKeyLen (see thread 2180 "dtaft-ietf-lamps-cmp-updates and rsaKeyLen") 2182 o Updated the IANA Considerations in and the Appendixes to introduce 2183 new OID for the updates ASN.1 modules (see thread "I-D Action: 2184 draft-ietf-lamps-cmp-updates-04.txt") 2186 o Removed EncryptedValue from and added Controls to the list of 2187 types imported from CRMF [RFC4211] in ASN.1 modules (see thread 2188 "draft-ietf-lamps-cmp-updates and the ASN.1 modules") 2190 o Moved declaration of Rand out of the comment in ASN.1 modules (see 2191 thread "draft-ietf-lamps-cmp-updates and the ASN.1 modules") 2193 o Minor changes and corrections 2195 From version 03 -> 04: 2197 o Added Section 2.7 to introduce three new id-it IDs for uses in 2198 general messages as discussed (see thread "draft-ietf-lamps-cmp- 2199 updates add section to introduce id-it-caCerts, id-it- 2200 rootCaKeyUpdate, and id-it-certReqTemplate") 2202 o Added the new id-it IDs and the /.well-known/cmp to the IANA 2203 Considerations of [RFC4210] in Section 2.9 2205 o Updated the IANA Considerations of [RFC4210] in Section 2.14 2207 o Some changes in wording on Section 3 due to review comments from 2208 Martin Peylo 2210 From version 02 -> 03: 2212 o Added a ToDo on aligning with the CMP Algorithms draft that will 2213 be set up as decided in IETF 108 2215 o Updated section on Encrypted Values in Section 2.4 to add the 2216 AsymmetricKey Package structure to transport a newly generated 2217 private key as decided in IETF 108 2219 o Updated the IANA Considerations of [RFC4210] in Section 2.14 2221 o Added the pre-registered OID in Section 2.14 and the ASN.1 module 2223 o Added Section 3 to document the changes to RFC 6712 [RFC6712] 2224 regarding URI discovery and using the path-prefix of '/.well- 2225 known/' as discussed in IETF 108 2227 o Updated the IANA Considerations section 2229 o Added a complete updated ASN.1 module in 1988 syntax to update 2230 Appendix F of [RFC4210] and a complete updated ASN.1 module in 2231 2002 syntax to update Section 9 of [RFC5912] 2233 o Minor changes in wording 2234 From version 01 -> 02: 2236 o Updated section on EKU OIDs in Section 2.2 as decided in IETF 107 2238 o Changed from symmetric key-encryption to password-based key 2239 management technique in Section 2.4 as discussed with Russ and Jim 2240 on the mailing list 2242 o Defined the attribute containing the key identifier for the 2243 revocation passphrase in Section 2.14 2245 o Moved the change history to the Appendix 2247 From version 00 -> 01: 2249 o Minor changes in wording 2251 From draft-brockhaus-lamps-cmp-updates-03 -> draft-ietf-lamps-cmp- 2252 updates-00: 2254 o Changes required to reflect WG adoption 2256 From version 02 -> 03: 2258 o Added some clarification in Section 2.1 2260 From version 01 -> 02: 2262 o Added clarification to section on multiple protection 2264 o Added clarification on new EKUs after some exchange with Tomas 2265 Gustavsson 2267 o Reused OIDs from RFC 6402 [RFC6402] as suggested by Sean Turner at 2268 IETF 106 2270 o Added clarification on the field containing the key identifier for 2271 a revocation passphrase 2273 o Minor changes in wording 2275 From version 00 -> 01: 2277 o Added a section describing the new extended key usages 2279 o Completed the section on changes to the specification of encrypted 2280 values 2282 o Added a section on clarification to Appendix D.4 2284 o Minor generalization in RFC 4210 [RFC4210] Sections 5.1.3.4 and 2285 5.3.22 2287 o Minor changes in wording 2289 Author's Address 2291 Hendrik Brockhaus 2292 Siemens AG 2294 Email: hendrik.brockhaus@siemens.com