idnits 2.17.1 draft-ietf-lamps-cmp-updates-03.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 : ---------------------------------------------------------------------------- No issues found here. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust and authors Copyright Line does not match the current year (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 (August 7, 2020) is 1351 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 1716 == Missing Reference: 'CRMF' is mentioned on line 1128, but not defined -- Looks like a reference, but probably isn't: '1' on line 1719 == Missing Reference: 'PKCS10' is mentioned on line 1458, but not defined -- Looks like a reference, but probably isn't: '2' on line 1699 -- Looks like a reference, but probably isn't: '3' on line 1457 -- Looks like a reference, but probably isn't: '4' on line 1458 -- Looks like a reference, but probably isn't: '5' on line 1459 -- Looks like a reference, but probably isn't: '6' on line 1460 -- Looks like a reference, but probably isn't: '7' on line 1461 -- Looks like a reference, but probably isn't: '8' on line 1462 == Missing Reference: 'RFC3629' is mentioned on line 1448, but not defined == Missing Reference: 'RFC3066' is mentioned on line 1449, but not defined ** Obsolete undefined reference: RFC 3066 (Obsoleted by RFC 4646, RFC 4647) == Missing Reference: 'RFC2482' is mentioned on line 1451, but not defined ** Obsolete undefined reference: RFC 2482 (Obsoleted by RFC 6082) -- Looks like a reference, but probably isn't: '9' on line 1463 -- Looks like a reference, but probably isn't: '10' on line 1464 -- Looks like a reference, but probably isn't: '11' on line 1465 -- Looks like a reference, but probably isn't: '12' on line 1466 -- Looks like a reference, but probably isn't: '13' on line 1467 -- Looks like a reference, but probably isn't: '14' on line 1468 -- Looks like a reference, but probably isn't: '15' on line 1469 -- Looks like a reference, but probably isn't: '16' on line 1470 -- Looks like a reference, but probably isn't: '17' on line 1471 -- Looks like a reference, but probably isn't: '18' on line 1472 -- Looks like a reference, but probably isn't: '19' on line 1473 -- Looks like a reference, but probably isn't: '20' on line 1474 -- Looks like a reference, but probably isn't: '21' on line 1475 -- Looks like a reference, but probably isn't: '22' on line 1476 -- Looks like a reference, but probably isn't: '23' on line 1477 -- Looks like a reference, but probably isn't: '24' on line 1478 -- Looks like a reference, but probably isn't: '25' on line 1479 -- Looks like a reference, but probably isn't: '26' on line 1480 == Missing Reference: 'PKCS11' is mentioned on line 1514, but not defined == Missing Reference: 'RFC2104' is mentioned on line 1515, but not defined == Missing Reference: 'RFC2202' is mentioned on line 1515, but not defined ** Downref: Normative reference to an Informational RFC: RFC 2985 ** Downref: Normative reference to an Informational RFC: RFC 2986 ** Obsolete normative reference: RFC 5785 (Obsoleted by RFC 8615) ** Downref: Normative reference to an Informational RFC: RFC 5912 ** Downref: Normative reference to an Informational RFC: RFC 7299 == Outdated reference: A later version (-21) exists of draft-ietf-lamps-lightweight-cmp-profile-02 Summary: 7 errors (**), 0 flaws (~~), 10 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) August 7, 2020 5 Intended status: Standards Track 6 Expires: February 8, 2021 8 CMP Updates 9 draft-ietf-lamps-cmp-updates-03 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, the 19 definition of extended key usages to identify certificates of CMP 20 endpoints on certification and registration authorities, and adds an 21 HTTP URI discovery mechanism and extend the URI structure. 23 Status of This Memo 25 This Internet-Draft is submitted in full conformance with the 26 provisions of BCP 78 and BCP 79. 28 Internet-Drafts are working documents of the Internet Engineering 29 Task Force (IETF). Note that other groups may also distribute 30 working documents as Internet-Drafts. The list of current Internet- 31 Drafts is at https://datatracker.ietf.org/drafts/current/. 33 Internet-Drafts are draft documents valid for a maximum of six months 34 and may be updated, replaced, or obsoleted by other documents at any 35 time. It is inappropriate to use Internet-Drafts as reference 36 material or to cite them other than as "work in progress." 38 This Internet-Draft will expire on February 8, 2021. 40 Copyright Notice 42 Copyright (c) 2020 IETF Trust and the persons identified as the 43 document authors. All rights reserved. 45 This document is subject to BCP 78 and the IETF Trust's Legal 46 Provisions Relating to IETF Documents 47 (https://trustee.ietf.org/license-info) in effect on the date of 48 publication of this document. Please review these documents 49 carefully, as they describe your rights and restrictions with respect 50 to this document. Code Components extracted from this document must 51 include Simplified BSD License text as described in Section 4.e of 52 the Trust Legal Provisions and are provided without warranty as 53 described in the Simplified BSD License. 55 Table of Contents 57 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2 58 1.1. Convention and Terminology . . . . . . . . . . . . . . . 3 59 2. Updates to RFC 4210 - Certificate Management Protocol (CMP) . 3 60 2.1. New Section 1.1. - Changes since RFC 4210 . . . . . . . . 3 61 2.2. New Section 4.5 - Extended Key Usage . . . . . . . . . . 4 62 2.3. Replace Section 5.1.3.4 - Multiple Protection . . . . . . 6 63 2.4. Replace Section 5.2.2. - Encrypted Values . . . . . . . . 7 64 2.5. Update Section 5.3.4. - Certification Response . . . . . 9 65 2.6. Replace Section 5.3.19.9. - Revocation Passphrase . . . . 9 66 2.7. Update Section 5.3.22 - Polling Request and Response . . 10 67 2.8. IANA Considerations . . . . . . . . . . . . . . . . . . . 11 68 2.9. Update Appendix B - The Use of Revocation Passphrase . . 11 69 2.10. Update Appendix C - Request Message Behavioral 70 Clarifications . . . . . . . . . . . . . . . . . . . . . 12 71 2.11. Update Appendix D.4. - Initial Registration/Certification 72 (Basic Authenticated Scheme) . . . . . . . . . . . . . . 12 73 3. Updates to RFC 6712 - HTTP Transfer for the Certificate 74 Management Protocol (CMP) . . . . . . . . . . . . . . . . . . 13 75 3.1. New Section 1.1. - Changes since RFC 6712 . . . . . . . . 13 76 3.2. New Section 3.6. - HTTP Request-URI . . . . . . . . . . . 13 77 4. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 14 78 5. Security Considerations . . . . . . . . . . . . . . . . . . . 15 79 6. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 15 80 7. References . . . . . . . . . . . . . . . . . . . . . . . . . 15 81 7.1. Normative References . . . . . . . . . . . . . . . . . . 15 82 7.2. Informative References . . . . . . . . . . . . . . . . . 16 83 Appendix A. ASN.1 Modules . . . . . . . . . . . . . . . . . . . 17 84 A.1. 1988 ASN.1 Module . . . . . . . . . . . . . . . . . . . . 17 85 A.2. 2002 ASN.1 Module . . . . . . . . . . . . . . . . . . . . 28 86 Appendix B. History of changes . . . . . . . . . . . . . . . . . 39 87 Author's Address . . . . . . . . . . . . . . . . . . . . . . . . 41 89 1. Introduction 91 While using CMP [RFC4210] in industrial and IoT environments and 92 developing the Lightweight CMP Profile 93 [I-D.ietf-lamps-lightweight-cmp-profile] some limitations were 94 identified in the original CMP specification. This document updates 95 RFC 4210 [RFC4210] and RFC 6712 [RFC6712] to overcome these 96 limitations. 98 In general, this document aims to improve the crypto agility of CMP 99 to be flexible to react on future advances in cryptography. 101 This document also introduces new extended key usages to identify CMP 102 endpoints on registration and certification authorities. 104 1.1. Convention and Terminology 106 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 107 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 108 document are to be interpreted as described in RFC 2119 [RFC2119]. 110 In this document, these words will appear with that interpretation 111 only when in ALL CAPS. Lower case uses of these words are not to be 112 interpreted as carrying significance described in RFC 2119. 114 Technical terminology is used in conformance with RFC 4210 [RFC4210], 115 RFC 4211 [RFC4211], and RFC 5280 [RFC5280]. The following key words 116 are used: 118 CA: Certification authority, which issues certificates. 120 RA: Registration authority, an optional system component to which a 121 CA delegates certificate management functions such as 122 authorization checks. 124 KGA: Key generation authority, which generates key pairs on behalf of 125 an EE. The KGA could be co-located with an RA or a CA. 127 EE: End entity, a user, device, or service that holds a PKI 128 certificate. An identifier for the EE is given as its subject 129 of the certificate. 131 2. Updates to RFC 4210 - Certificate Management Protocol (CMP) 133 2.1. New Section 1.1. - Changes since RFC 4210 135 The following subsection describes feature updates to RFC 4210 136 [RFC4210]. They are always related to the base specification. Hence 137 references to the original sections in RFC 4210 [RFC4210] are used 138 whenever possible. 140 Insert this section at the end of the current Section 1. 142 1.1 Changes since RFC 4210 144 The following updates are made in [thisRFC]: 146 o Add new extended key usages for different CMP server types, e.g. 147 registration authority and certification authority, to express the 148 authorization of the entity identified in the certificate 149 containing the respective extended key usage extension to act as 150 the indicated PKI management entity. 152 o Extend the description of multiple protection to cover additional 153 use cases, e.g., batch processing of messages. 155 o Offering EnvelopedData as the preferred choice next to 156 EncryptedValue to extend crypto agility in CMP. Note that 157 according to RFC 4211 [RFC4211] section 2.1.9 the use of the 158 EncryptedValue structure has been deprecated in favor of the 159 EnvelopedData structure. RFC 4211 [RFC4211] offers the 160 EncryptedKey structure, a choice of EncryptedValue and 161 EnvelopedData for migration to EnvelopedData. For reasons of 162 completeness and consistency the exchange of EncryptedValue is 163 performed for all usages in RFC 4210 [RFC4210]. This includes the 164 protection of centrally generated private keys, encryption of 165 certificates, and revocation passphrases. 167 o Extend the usage of polling also to p10cr messages. 169 < TBD: The specification of algorithm profiles seed to be moved to a 170 separate document. > 172 2.2. New Section 4.5 - Extended Key Usage 174 The following subsection describes new extended key usages for 175 different CMP server types specified in RFC 4210 [RFC4210]. 177 Insert this section at the end of the current Section 4. 179 4.5 Extended Key Usage 181 The Extended Key Usage (EKU) extension indicates the purposes for 182 which the certified public key may be used. It therefore restricts 183 the use of a certificate to specific applications. 185 A CA may want to delegate parts of their duties to other PKI 186 management entities. The mechanism to prove this delegation 187 explained in this section offers zero-touch means to check the 188 authorization of such delegation. Such delegation could also be 189 expressed by other means, e.g., explicit configuration. 191 To offer automatic validation means for the delegation of a role by a 192 CA, the certificates used by PKI management entities for CMP message 193 protection or signed data for central key generation MUST be issued 194 by the delegating CA and MUST contain the respective EKUs. This 195 proves the authorization of this entity by the delegating CA to act 196 as the PKI management entity as described below. 198 The ASN.1 to define these EKUs is: 200 id-kp OBJECT IDENTIFIER ::= 201 { iso(1) identified-organization(3) dod(6) internet(1) 202 security(5) mechanisms(5) pkix(7) kp(3) } 204 id-kp-cmcCA OBJECT IDENTIFIER ::= { id-kp 27 } 205 id-kp-cmcRA OBJECT IDENTIFIER ::= { id-kp 28 } 206 id-kp-cmKGA OBJECT IDENTIFIER ::= { id-kp 32 } 208 Note: RFC 6402 section 2.10 [RFC6402] specifies OIDs for a CMC CA and 209 a CMC RA. As the functionality of a CA and RA is not specific to 210 whether use CMC or CMP as certificate management protocol, the same 211 OIDs SHALL be used for a CMP CA and a CMP RA. 213 < TBD: The Description of the OIDs for id-kp-cmcCA and id-kp-cmcRA 214 needs to be extended to avoid confusion as they currently only refer 215 to CMC. > 217 The description of the PKI management entity for each of the EKUs is 218 as follows: 220 CMP CA: CMP Certification Authorities are CMP endpoints on CA 221 equipment as described in section 3.1.1.2. The key used in 222 the context of CMP management operations, especially CMP 223 message protection, need not be the same key that signs the 224 certificates. It is necessary, however, to ensure that the 225 entity acting as CMP CA is authorized to do so. Therefore, 226 the CMP CA MUST do one of the following, 228 * use the CA private key on the CMP endpoint, or 230 * explicitly designate this authority to another entity. 232 For automatic validation of such delegation it MUST be 233 indicated by the id-kp-cmcCA extended key usage. This 234 extended key usage MUST be placed into the certificate used 235 on the CA equipment and the CA that delegates this role MUST 236 issue the CMP CA certificate. 238 Note: Using a separate key pair for protecting CMP 239 management operations at the CA decreases the number of 240 operations of the private key used to sign certificates. 242 CMP RA: CMP Registration Authorities are CMP endpoints on RA 243 equipment as described in Section 3.1.1.3. A CMP RA is 244 identified by the id-kp-cmcRA extended key usage. This 245 extended key usage is placed into RA certificates. The CA 246 that delegated this role is identified by the CA that issued 247 the CMP RA certificate. 249 CMP KGA: CMP Key Generation Authorities are identified by the id-kp- 250 cmKGA extended key usage. Though the CMP KGA knows the 251 private key it generated on behalf of the end entity. This 252 is a very sensitive service and needs specific 253 authorization. This authorization is either with the CA 254 certificate itself, or indicated by placing the id-kp-cmKGA 255 extended key usage into the CMP RA or CMP CA certificate 256 used to authenticate the origin of the private key, and to 257 express the authorization to offer this service. 259 Note: In device PKIs, especially those issuing IDevID certificates, 260 CA may have very long validity (including the GeneralizedTime value 261 99991231235959Z to indicate a not well-defined expiration date as 262 specified in IEEE 802.1AR Section 8.5 [IEEE802.1AR] and RFC 5280 263 Section 4.1.2.5 [RFC5280]). Such validity periods SHOULD NOT be used 264 for protection of CMP messages. Certificates for delegated CMP 265 message protection (CMP CA, CMP RA, CMP KGA) MUST NOT use indefinite 266 expiration date. 268 2.3. Replace Section 5.1.3.4 - Multiple Protection 270 Section 5.1.3.4 of RFC 4210 [RFC4210] describes the nested message. 271 This document opens the usage of nested messages also for batch 272 transport of PKI messages between different PKI management entities. 274 Replace the text of the section with the following text. 276 In cases where an end entity sends a protected PKI message to an RA, 277 the RA MAY forward that message to a CA, adding its own protection 278 (which MAY be a MAC or a signature, depending on the information and 279 certificates shared between the RA and the CA). There are different 280 use cases for such multi protected messages. 282 o The RA confirms the validation and authorization of a message and 283 forwards the original message unchanged. 285 o The RA collects several messages and forwards them in a batch. 286 This can for instance be used to bridge an off-line connection 287 between two PKI management entities. In communication to the CA 288 request messages and in communication from the CA response or 289 announcement messages will be collected in such batch. 291 o The RA modifies the message(s) in some way (e.g., add or modify 292 particular field values or add new extensions) before forwarding 293 them, then it MAY create its own desired PKIBody. In case the 294 changes made by the RA to PKIMessage breaks the POP, the RA MUST 295 either set the POP RAVerified or include the original PKIMessage 296 from the EE in the generalInfo field of PKIHeader of the nested 297 message (to force the CA to check POP on the original message). 298 The infoType to be used in this situation is {id-it 15} (see 299 Section 5.3.19 for the value of id-it) and the infoValue is 300 PKIMessages (contents MUST be in the same order as the requests in 301 PKIBody). For simplicity reasons, if batching is used in 302 combination with inclusion of the original PKIMessage in the 303 generalInfo field, all messages in the batch MUST be of the same 304 type (e.g., ir). 306 These use cases are accomplished by nesting the messages sent by the 307 PKI entity within a new PKI message. The structure used is as 308 follows. 310 NestedMessageContent ::= PKIMessages 312 (The use of PKIMessages, a SEQUENCE OF PKIMessage, lets the RA batch 313 the requests of several EEs in a single new message.) 315 2.4. Replace Section 5.2.2. - Encrypted Values 317 Section 5.2.2 of RFC 4210 [RFC4210] describes the usage of 318 EncryptedValue to transport encrypted data. This document extends 319 the encryption of data to preferably use EnvelopedData. 321 Replace the text of the section with the following text. 323 Where encrypted data (restricted, in this specification, to be either 324 private keys, certificates, or passwords) are sent in PKI messages, 325 the EncryptedKey data structure is used. 327 EncryptedKey ::= CHOICE { 328 encryptedValue EncryptedValue, -- deprecated 329 envelopedData [0] EnvelopedData } 331 See CRMF [RFC4211] for EncryptedKey and EncryptedValue syntax and for 332 EnvelopedData syntax see CMS [RFC5652]. Using the EncryptedKey data 333 structure, the choice to either use EncryptedValue (for backward 334 compatibility only) or EnvelopedData is offered. The use of the 335 EncryptedValue structure has been deprecated in favor of the 336 EnvelopedData structure. Therefore, it is recommended to use 337 EnvelopedData. 339 Note: As we reuse the EncryptedKey structure defined in CRMF 340 [RFC4211], the update is backward compatible. Using the new syntax 341 with the untagged default choice EncryptedValue is bitwise compatible 342 with the old syntax. 344 The EncryptedKey data structure is used in CMP to either transport a 345 private key, certificate or revocation passphrase in encrypted form. 347 EnvelopedData is used as follows: 349 o Contains only one recepientInfo structure because the content is 350 encrypted only for one recipient. 352 o Contains a private key in the AsymmetricKeyPackage structure as 353 defined in RFC 5958 [RFC5958] wrapped in a SignedData structure as 354 specified in CMS section 5 [RFC5652] signed by the Key Generation 355 Authority. 357 o Contains a certificate or revocation passphrase directly in the 358 encryptedContent field. 360 Note: To ensure explicit control of the encoding of the private key 361 according to the specific algorithm the new key pair in an asymmetric 362 key package structure as specified in [RFC5958]. 364 The content of the EnvelopedData structure, as specified in CMS 365 section 6 [RFC5652], MUST be encrypted using a newly generated 366 symmetric content-encryption key. This content-encryption key MUST 367 be securely provided to the recipient using one of three key 368 management techniques. 370 The choice of the key management technique to be used by the sender 371 depends on the credential available for the recipient: 373 o Recipient's certificate that contains a key usage extension 374 asserting keyAgreement: The content-encryption key will be 375 protected using the key agreement key management technique, as 376 specified in CMS section 6.2.2 [RFC5652]. 378 o Recipient's certificate that contains a key usage extension 379 asserting keyEncipherment: The content-encryption key will be 380 protected using the key transport key management technique, as 381 specified in CMS section 6.2.1 [RFC5652]. 383 o Jointly shared secret: The content-encryption key will be 384 protected using the password-based key management technique, as 385 specified in CMS section 6.2.4 [RFC5652]. 387 2.5. Update Section 5.3.4. - Certification Response 389 Section 5.3.4 of RFC 4210 [RFC4210] describes the Certification 390 Response. This document updates the syntax by using the parent 391 structure EncryptedKey instead of EncryptedValue as described in 392 Section 2.1 above. 394 Replace the ASN.1 syntax of CertifiedKeyPair and CertOrEncCert with 395 the following text. 397 CertifiedKeyPair ::= SEQUENCE { 398 certOrEncCert CertOrEncCert, 399 privateKey [0] EncryptedKey OPTIONAL, 400 -- see [CRMF] for comment on encoding 401 publicationInfo [1] PKIPublicationInfo OPTIONAL 402 } 404 CertOrEncCert ::= CHOICE { 405 certificate [0] Certificate, 406 encryptedCert [1] EncryptedKey 407 } 409 Add the following paragraphs to the end of the section. 411 The use of EncryptedKey is described in section 5.2.2. 413 2.6. Replace Section 5.3.19.9. - Revocation Passphrase 415 Section 5.3.19.9 of RFC 4210 [RFC4210] describes the provisioning of 416 a revocation passphrase for authenticating a later revocation 417 request. This document updates the handling by using the parent 418 structure EncryptedKey instead of EncryptedValue to transport this 419 information as described in Section 2.1 above. 421 Replace the text of the section with the following text. 423 This MAY be used by the EE to send a passphrase to a CA/RA for the 424 purpose of authenticating a later revocation request (in the case 425 that the appropriate signing private key is no longer available to 426 authenticate the request). See Appendix B for further details on the 427 use of this mechanism. 429 GenMsg: {id-it 12}, EncryptedKey 430 GenRep: {id-it 12}, < absent > 432 The use of EncryptedKey is described in section 5.2.2. 434 2.7. Update Section 5.3.22 - Polling Request and Response 436 Section 5.3.22 of RFC 4210 [RFC4210] describes when and how polling 437 messages are used. This document adds the polling mechanism also to 438 outstanding p10cr transactions. 440 Replace all paragraphs in front of the state machine diagram with the 441 following text. 443 This pair of messages is intended to handle scenarios in which the 444 client needs to poll the server in order to determine the status of 445 an outstanding ir, cr, p10cr, or kur transaction (i.e., when the 446 "waiting" PKIStatus has been received). 448 PollReqContent ::= SEQUENCE OF SEQUENCE { 449 certReqId INTEGER } 451 PollRepContent ::= SEQUENCE OF SEQUENCE { 452 certReqId INTEGER, 453 checkAfter INTEGER, -- time in seconds 454 reason PKIFreeText OPTIONAL } 456 The following clauses describe when polling messages are used, and 457 how they are used. It is assumed that multiple certConf messages can 458 be sent during transactions. There will be one sent in response to 459 each ip, cp, or kup that contains a CertStatus for an issued 460 certificate. 462 1 In response to an ip, cp, or kup message, an EE will send a 463 certConf for all issued certificates and, following the ack, a 464 pollReq for all pending certificates. 466 2 In response to a pollReq, a CA/RA will return an ip, cp, or kup if 467 one or more of the pending certificates is ready; otherwise, it 468 will return a pollRep. 470 3 If the EE receives a pollRep, it will wait for at least as long as 471 the checkAfter value before sending another pollReq. 473 4 If an ip, cp, or kup is received in response to a pollReq, then it 474 will be treated in the same way as the initial response. 476 Note: A p10cr message contains exactly one CertificationRequestInfo 477 data structure as specified in PKCS#10 [RFC2986] but no certificate 478 request number. Therefore, the certReqId MUST be set to 0 in all 479 following messages of this transaction. 481 2.8. IANA Considerations 483 Section 9 of RFC 4210 [RFC4210] contains the IANA Considerations of 484 that document. As this document defines a new and updates two 485 existing Extended Key Usages, the IANA Considerations need to be 486 updated accordingly. 488 Add the following paragraphs between the first and second paragraph 489 of the section. 491 Within the SMI-numbers registry "SMI Security for PKIX Extended Key 492 Purpose Identifiers (1.3.6.1.5.5.7.3)" (see 493 https://www.iana.org/assignments/smi-numbers/smi-numbers.xhtml#smi- 494 numbers-1.3.6.1.5.5.7.3) as defined in RFC 7299 [RFC7299] three 495 changes have been performed. 497 Two existing entries have been updated to also point to this 498 document: 500 Decimal Description References 501 ------- ----------- ------------------ 502 27 id-kp-cmcCA [RFC6402][thisRFC] 503 28 id-kp-cmcRA [RFC6402][thisRFC] 505 One new entry has been added: 507 Decimal Description References 508 ------- ----------- ---------- 509 32 id-kp-cmKGA [thisRFC] 511 2.9. Update Appendix B - The Use of Revocation Passphrase 513 Appendix B of RFC 4210 [RFC4210] describes the usage of the 514 revocation passphrase. As this document updates RFC 4210 [RFC4210] 515 to utilize the parent structure EncryptedKey instead of 516 EncryptedValue as described in Section 2.1 above, the description is 517 updated accordingly. 519 Replace the first bullet point of this section with the following 520 text. 522 o The OID and value specified in Section 5.3.19.9 of RFC 4210 523 [RFC4210] MAY be sent in a GenMsg message at any time, or MAY be 524 sent in the generalInfo field of the PKIHeader of any PKIMessage 525 at any time. (In particular, the EncryptedKey as described in 526 section 5.2.2 may be sent in the header of the certConf message 527 that confirms acceptance of certificates requested in an 528 initialization request or certificate request message.) This 529 conveys a revocation passphrase chosen by the entity (i.e., for 530 use of EnvelopedData this is in the decrypted bytes of 531 encryptedContent field and for use of EncryptedValue this is in 532 the decrypted bytes of the encValue field) to the relevant CA/RA; 533 furthermore, the transfer is accomplished with appropriate 534 confidentiality characteristics. 536 Replace the third bullet point of this section with the following 537 text. 539 o When using EnvelopedData the localKeyId attribute as specified in 540 RFC 2985 [RFC2985] and when using EncryptedValue the valueHint 541 field MAY contain a key identifier (chosen by the entity, along 542 with the passphrase itself) to assist in later retrieval of the 543 correct passphrase (e.g., when the revocation request is 544 constructed by the entity and received by the CA/RA). 546 2.10. Update Appendix C - Request Message Behavioral Clarifications 548 Appendix C of RFC 4210 [RFC4210] provides clarifications to the 549 request message behavior. As this document updates RFC 4210 550 [RFC4210] to utilize the parent structure EncryptedKey instead of 551 EncryptedValue as described in Section 2.1 above, the description is 552 updated accordingly. 554 Replace the note coming after the ASN.1 syntax of POPOPrivKey of this 555 section with the following text. 557 -- ********** 558 -- * the type of "thisMessage" is given as BIT STRING in RFC 4211 559 -- * [RFC4211]; it should be "EncryptedKey" (in accordance with 560 -- * Section 5.2.2 of this specification). Therefore, this document 561 -- * makes the behavioral clarification of specifying that the 562 -- * contents of "thisMessage" MUST be encoded either as 563 -- * "EnvelopedData" or "EncryptedValue" (only for backward 564 -- * compatibility) and then wrapped in a BIT STRING. This allows 565 -- * the necessary conveyance and protection of the private key 566 -- * while maintaining bits-on-the-wire compatibility with RFC 4211 567 -- * [RFC4211]. 568 -- ********** 570 2.11. Update Appendix D.4. - Initial Registration/Certification (Basic 571 Authenticated Scheme) 573 Appendix D.4 of RFC 4210 [RFC4210] provides the initial registration/ 574 certification scheme. This scheme shall continue to use 575 EncryptedValue for backward compatibility reasons. 577 Replace the comment after the privateKey field of 578 crc[1].certifiedKeyPair in the syntax of the Initialization Response 579 message with the following text. 581 -- see Appendix C, Request Message Behavioral Clarifications 582 -- for backward compatibility reasons, use EncryptedValue 584 3. Updates to RFC 6712 - HTTP Transfer for the Certificate Management 585 Protocol (CMP) 587 3.1. New Section 1.1. - Changes since RFC 6712 589 The following subsection describes feature updates to RFC 6712 590 [RFC6712]. They are always related to the base specification. Hence 591 references to the original sections in RFC 6712 [RFC6712] are used 592 whenever possible. 594 Insert this section at the end of the current Section 1. 596 1.1 Changes since RFC 6712 598 The following updates are made in draft-ietf-lamps-cmp-updates: 600 o Add an HTTP URI discovery mechanism and extend the URI structure. 602 3.2. New Section 3.6. - HTTP Request-URI 604 Section 3.6 of RFC 6712 [RFC6712] specifies the used HTTP URIs. This 605 document adds a discovery mechanism and extends the URIs. 607 Replace the text of the section with the following text. 609 Each PKI management entity supporting HTTP or HTTPS transport MUST 610 support the use of the path-prefix of '/.well-known/' as defined in 611 RFC 5785 [RFC5785] and the registered name of 'cmp' to ease 612 interworking in a multi-vendor environment. 614 The CMP client MUST be configured with sufficient information to form 615 the CMP server URI. This MUST be at least the authority portion of 616 the URI, e.g., 'www.example.com:80', or the full operational path of 617 the PKI management entity. Additional arbitrary label, e.g., 618 'profileLabel' and 'operationLabel', MAY be configured as a separate 619 component or as part of the full operational path to provide further 620 information. The 'profileLabel' MAY support addressing multiple CAs 621 or certificate profiles and the 'operationLabel' may support 622 addressing PKI management operation specific endpoints. A valid full 623 operational path can look like this: 625 1 http://www.example.com/.well-known/cmp 627 2 http://www.example.com/.well-known/cmp/operationLabel 629 3 http://www.example.com/.well-known/cmp/profileLabel 631 4 http://www.example.com/.well-known/cmp/profileLabel/operationLabel 633 The discovery of supported endpoints as defined above will provide 634 the information to the EE, how to contact the PKI management entity 635 and, if available, how to request enrolment for a specific 636 certificate profile or revoke a certificate at a specific CA. 638 Querying the PKI management entity, the EE will get a list of 639 potential endpoints supported by the PKI management entity. 641 Performing a GET on "/.well-known/cmp" to the default port MUST 642 return a set of links to endpoints available from the server. In 643 addition to the link also the expected format of the data object is 644 provided as content type (ct). 646 < TBD: It needs to be discussed if the discovery should be performed 647 using GET on "/.well-known/cmp" or GET on "/.well-known" only. > 649 The following provides an illustrative example for a PKI management 650 entity supporting different PKI management operations for different 651 certificate profiles and CAs. 653 Detailed message description: 655 REQ: GET /.well-known/cmp 657 RES: Content 658 ;ct=pkixcmp 659 ;ct=pkixcmp 660 ;ct=pkixcmp 661 ;ct=pkixcmp 662 ;ct=pkixcmp 663 ;ct=pkixcmp 664 ;ct=pkixcmp 665 ;ct=pkixcmp 667 4. IANA Considerations 669 This document contains an update to the IANA Considerations section 670 to be added to [RFC4210]. 672 < TBD: The existing description and information of id-kp-cmcRA and 673 id-kp-cmcCA need to be updated to reflect their extended usage. > 675 5. Security Considerations 677 No changes are made to the existing security considerations of 678 RFC 4210 [RFC4210] and RFC 6712 [RFC6712]. 680 6. Acknowledgements 682 Special thank goes to Jim Schaad for his guidance and the inspiration 683 on structuring and writing this document I got from [RFC6402] that 684 updates CMC. Special thank also goes also to Russ Housley and Tomas 685 Gustavsson for reviewing and providing valuable suggestions on the 686 approvement of this document. 688 I also like to thank all reviewers of this document for their 689 valuable feedback. 691 7. References 693 7.1. Normative References 695 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 696 Requirement Levels", BCP 14, RFC 2119, 697 DOI 10.17487/RFC2119, March 1997, 698 . 700 [RFC2985] Nystrom, M. and B. Kaliski, "PKCS #9: Selected Object 701 Classes and Attribute Types Version 2.0", RFC 2985, 702 DOI 10.17487/RFC2985, November 2000, 703 . 705 [RFC2986] Nystrom, M. and B. Kaliski, "PKCS #10: Certification 706 Request Syntax Specification Version 1.7", RFC 2986, 707 DOI 10.17487/RFC2986, November 2000, 708 . 710 [RFC4210] Adams, C., Farrell, S., Kause, T., and T. Mononen, 711 "Internet X.509 Public Key Infrastructure Certificate 712 Management Protocol (CMP)", RFC 4210, 713 DOI 10.17487/RFC4210, September 2005, 714 . 716 [RFC4211] Schaad, J., "Internet X.509 Public Key Infrastructure 717 Certificate Request Message Format (CRMF)", RFC 4211, 718 DOI 10.17487/RFC4211, September 2005, 719 . 721 [RFC5280] Cooper, D., Santesson, S., Farrell, S., Boeyen, S., 722 Housley, R., and W. Polk, "Internet X.509 Public Key 723 Infrastructure Certificate and Certificate Revocation List 724 (CRL) Profile", RFC 5280, DOI 10.17487/RFC5280, May 2008, 725 . 727 [RFC5652] Housley, R., "Cryptographic Message Syntax (CMS)", STD 70, 728 RFC 5652, DOI 10.17487/RFC5652, September 2009, 729 . 731 [RFC5785] Nottingham, M. and E. Hammer-Lahav, "Defining Well-Known 732 Uniform Resource Identifiers (URIs)", RFC 5785, 733 DOI 10.17487/RFC5785, April 2010, 734 . 736 [RFC5912] Hoffman, P. and J. Schaad, "New ASN.1 Modules for the 737 Public Key Infrastructure Using X.509 (PKIX)", RFC 5912, 738 DOI 10.17487/RFC5912, June 2010, 739 . 741 [RFC5958] Turner, S., "Asymmetric Key Packages", RFC 5958, 742 DOI 10.17487/RFC5958, August 2010, 743 . 745 [RFC6402] Schaad, J., "Certificate Management over CMS (CMC) 746 Updates", RFC 6402, DOI 10.17487/RFC6402, November 2011, 747 . 749 [RFC6712] Kause, T. and M. Peylo, "Internet X.509 Public Key 750 Infrastructure -- HTTP Transfer for the Certificate 751 Management Protocol (CMP)", RFC 6712, 752 DOI 10.17487/RFC6712, September 2012, 753 . 755 [RFC7299] Housley, R., "Object Identifier Registry for the PKIX 756 Working Group", RFC 7299, DOI 10.17487/RFC7299, July 2014, 757 . 759 7.2. Informative References 761 [I-D.ietf-lamps-lightweight-cmp-profile] 762 Brockhaus, H., Fries, S., and D. Oheimb, "Lightweight CMP 763 Profile", draft-ietf-lamps-lightweight-cmp-profile-02 764 (work in progress), July 2020. 766 [IEEE802.1AR] 767 IEEE, "802.1AR Secure Device Identifier", June 2018, 768 . 771 Appendix A. ASN.1 Modules 773 A.1. 1988 ASN.1 Module 775 This section contains the updated ASN.1 module for [RFC4210]. This 776 module replaces the module in Appendix F of that document. Although 777 a 2002 ASN.1 module is provided, this remains the normative module as 778 per the policy of the PKIX working group. 780 PKIXCMP {iso(1) identified-organization(3) 781 dod(6) internet(1) security(5) mechanisms(5) pkix(7) 782 id-mod(0) id-mod-cmp2000(16)} 784 DEFINITIONS EXPLICIT TAGS ::= 786 BEGIN 788 -- EXPORTS ALL -- 790 IMPORTS 792 Certificate, CertificateList, Extensions, AlgorithmIdentifier, 793 UTF8String, id-kp -- if required; otherwise, comment out 794 FROM PKIX1Explicit88 {iso(1) identified-organization(3) 795 dod(6) internet(1) security(5) mechanisms(5) pkix(7) 796 id-mod(0) id-pkix1-explicit-88(1)} 798 GeneralName, KeyIdentifier 799 FROM PKIX1Implicit88 {iso(1) identified-organization(3) 800 dod(6) internet(1) security(5) mechanisms(5) pkix(7) 801 id-mod(0) id-pkix1-implicit-88(2)} 803 CertTemplate, PKIPublicationInfo, EncryptedKey, EncryptedValue, 804 CertId, CertReqMessages 805 FROM PKIXCRMF-2005 {iso(1) identified-organization(3) 806 dod(6) internet(1) security(5) mechanisms(5) pkix(7) 807 id-mod(0) id-mod-crmf2005(36)} 808 -- The import of EncryptedKey is added due to the updates made 809 -- in this document 811 -- see also the behavioral clarifications to CRMF codified in 812 -- Appendix C of this specification 813 CertificationRequest 814 FROM PKCS-10 {iso(1) member-body(2) 815 us(840) rsadsi(113549) 816 pkcs(1) pkcs-10(10) modules(1) pkcs-10(1)} 817 -- (specified in RFC 2986 with 1993 ASN.1 syntax and IMPLICIT 818 -- tags). Alternatively, implementers may directly include 819 -- the [PKCS10] syntax in this module 821 localKeyId 822 FROM PKCS-9 {iso(1) member-body(2) us(840) rsadsi(113549) 823 pkcs(1) pkcs-9(9) modules(0) pkcs-9(1)} 824 -- The import of localKeyId is added due to the updates made in 825 -- this document 827 EnvelopedData, SignedData 828 FROM CryptographicMessageSyntax2004 { iso(1) 829 member-body(2) us(840) rsadsi(113549) pkcs(1) pkcs-9(9) 830 smime(16) modules(0) cms-2004(24) } 831 -- The import of EnvelopedData and SignedData is added due to 832 -- the updates made in this document 834 ; 836 -- the rest of the module contains locally-defined OIDs and 837 -- constructs 839 CMPCertificate ::= CHOICE { 840 x509v3PKCert Certificate 841 } 842 -- This syntax, while bits-on-the-wire compatible with the 843 -- standard X.509 definition of "Certificate", allows the 844 -- possibility of future certificate types (such as X.509 845 -- attribute certificates, WAP WTLS certificates, or other kinds 846 -- of certificates) within this certificate management protocol, 847 -- should a need ever arise to support such generality. Those 848 -- implementations that do not foresee a need to ever support 849 -- other certificate types MAY, if they wish, comment out the 850 -- above structure and "un-comment" the following one prior to 851 -- compiling this ASN.1 module. (Note that interoperability 852 -- with implementations that don't do this will be unaffected by 853 -- this change.) 855 -- CMPCertificate ::= Certificate 857 PKIMessage ::= SEQUENCE { 858 header PKIHeader, 859 body PKIBody, 860 protection [0] PKIProtection OPTIONAL, 861 extraCerts [1] SEQUENCE SIZE (1..MAX) OF CMPCertificate 862 OPTIONAL 863 } 865 PKIMessages ::= SEQUENCE SIZE (1..MAX) OF PKIMessage 867 PKIHeader ::= SEQUENCE { 868 pvno INTEGER { cmp1999(1), cmp2000(2) }, 869 sender GeneralName, 870 -- identifies the sender 871 recipient GeneralName, 872 -- identifies the intended recipient 873 messageTime [0] GeneralizedTime OPTIONAL, 874 -- time of production of this message (used when sender 875 -- believes that the transport will be "suitable"; i.e., 876 -- that the time will still be meaningful upon receipt) 877 protectionAlg [1] AlgorithmIdentifier OPTIONAL, 878 -- algorithm used for calculation of protection bits 879 senderKID [2] KeyIdentifier OPTIONAL, 880 recipKID [3] KeyIdentifier OPTIONAL, 881 -- to identify specific keys used for protection 882 transactionID [4] OCTET STRING OPTIONAL, 883 -- identifies the transaction; i.e., this will be the same in 884 -- corresponding request, response, certConf, and PKIConf 885 -- messages 886 senderNonce [5] OCTET STRING OPTIONAL, 887 recipNonce [6] OCTET STRING OPTIONAL, 888 -- nonces used to provide replay protection, senderNonce 889 -- is inserted by the creator of this message; recipNonce 890 -- is a nonce previously inserted in a related message by 891 -- the intended recipient of this message 892 freeText [7] PKIFreeText OPTIONAL, 893 -- this may be used to indicate context-specific instructions 894 -- (this field is intended for human consumption) 895 generalInfo [8] SEQUENCE SIZE (1..MAX) OF 896 InfoTypeAndValue OPTIONAL 897 -- this may be used to convey context-specific information 898 -- (this field not primarily intended for human consumption) 899 } 901 PKIFreeText ::= SEQUENCE SIZE (1..MAX) OF UTF8String 902 -- text encoded as UTF-8 String [RFC3629] (note: each 903 -- UTF8String MAY include an [RFC3066] language tag 904 -- to indicate the language of the contained text 905 -- see [RFC2482] for details) 907 PKIBody ::= CHOICE { -- message-specific body elements 908 ir [0] CertReqMessages, --Initialization Request 909 ip [1] CertRepMessage, --Initialization Response 910 cr [2] CertReqMessages, --Certification Request 911 cp [3] CertRepMessage, --Certification Response 912 p10cr [4] CertificationRequest, --imported from [PKCS10] 913 popdecc [5] POPODecKeyChallContent, --pop Challenge 914 popdecr [6] POPODecKeyRespContent, --pop Response 915 kur [7] CertReqMessages, --Key Update Request 916 kup [8] CertRepMessage, --Key Update Response 917 krr [9] CertReqMessages, --Key Recovery Request 918 krp [10] KeyRecRepContent, --Key Recovery Response 919 rr [11] RevReqContent, --Revocation Request 920 rp [12] RevRepContent, --Revocation Response 921 ccr [13] CertReqMessages, --Cross-Cert. Request 922 ccp [14] CertRepMessage, --Cross-Cert. Response 923 ckuann [15] CAKeyUpdAnnContent, --CA Key Update Ann. 924 cann [16] CertAnnContent, --Certificate Ann. 925 rann [17] RevAnnContent, --Revocation Ann. 926 crlann [18] CRLAnnContent, --CRL Announcement 927 pkiconf [19] PKIConfirmContent, --Confirmation 928 nested [20] NestedMessageContent, --Nested Message 929 genm [21] GenMsgContent, --General Message 930 genp [22] GenRepContent, --General Response 931 error [23] ErrorMsgContent, --Error Message 932 certConf [24] CertConfirmContent, --Certificate confirm 933 pollReq [25] PollReqContent, --Polling request 934 pollRep [26] PollRepContent --Polling response 935 } 937 PKIProtection ::= BIT STRING 939 ProtectedPart ::= SEQUENCE { 940 header PKIHeader, 941 body PKIBody 942 } 944 id-PasswordBasedMac OBJECT IDENTIFIER ::= {1 2 840 113533 7 66 13} 945 PBMParameter ::= SEQUENCE { 946 salt OCTET STRING, 947 -- note: implementations MAY wish to limit acceptable sizes 948 -- of this string to values appropriate for their environment 949 -- in order to reduce the risk of denial-of-service attacks 950 owf AlgorithmIdentifier, 951 -- AlgId for a One-Way Function (SHA-1 recommended) 952 iterationCount INTEGER, 953 -- number of times the OWF is applied 954 -- note: implementations MAY wish to limit acceptable sizes 955 -- of this integer to values appropriate for their environment 956 -- in order to reduce the risk of denial-of-service attacks 957 mac AlgorithmIdentifier 958 -- the MAC AlgId (e.g., DES-MAC, Triple-DES-MAC [PKCS11], 959 } -- or HMAC [RFC2104, RFC2202]) 961 id-DHBasedMac OBJECT IDENTIFIER ::= {1 2 840 113533 7 66 30} 962 DHBMParameter ::= SEQUENCE { 963 owf AlgorithmIdentifier, 964 -- AlgId for a One-Way Function (SHA-1 recommended) 965 mac AlgorithmIdentifier 966 -- the MAC AlgId (e.g., DES-MAC, Triple-DES-MAC [PKCS11], 967 } -- or HMAC [RFC2104, RFC2202]) 969 NestedMessageContent ::= PKIMessages 971 PKIStatus ::= INTEGER { 972 accepted (0), 973 -- you got exactly what you asked for 974 grantedWithMods (1), 975 -- you got something like what you asked for; the 976 -- requester is responsible for ascertaining the differences 977 rejection (2), 978 -- you don't get it, more information elsewhere in the message 979 waiting (3), 980 -- the request body part has not yet been processed; expect to 981 -- hear more later (note: proper handling of this status 982 -- response MAY use the polling req/rep PKIMessages specified 983 -- in Section 5.3.22; alternatively, polling in the underlying 984 -- transport layer MAY have some utility in this regard) 985 revocationWarning (4), 986 -- this message contains a warning that a revocation is 987 -- imminent 988 revocationNotification (5), 989 -- notification that a revocation has occurred 990 keyUpdateWarning (6) 991 -- update already done for the oldCertId specified in 992 -- CertReqMsg 993 } 995 PKIFailureInfo ::= BIT STRING { 996 -- since we can fail in more than one way! 997 -- More codes may be added in the future if/when required. 998 badAlg (0), 999 -- unrecognized or unsupported Algorithm Identifier 1000 badMessageCheck (1), 1001 -- integrity check failed (e.g., signature did not verify) 1002 badRequest (2), 1003 -- transaction not permitted or supported 1004 badTime (3), 1005 -- messageTime was not sufficiently close to the system time, 1006 -- as defined by local policy 1007 badCertId (4), 1008 -- no certificate could be found matching the provided criteria 1009 badDataFormat (5), 1010 -- the data submitted has the wrong format 1011 wrongAuthority (6), 1012 -- the authority indicated in the request is different from the 1013 -- one creating the response token 1014 incorrectData (7), 1015 -- the requester's data is incorrect (for notary services) 1016 missingTimeStamp (8), 1017 -- when the timestamp is missing but should be there 1018 -- (by policy) 1019 badPOP (9), 1020 -- the proof-of-possession failed 1021 certRevoked (10), 1022 -- the certificate has already been revoked 1023 certConfirmed (11), 1024 -- the certificate has already been confirmed 1025 wrongIntegrity (12), 1026 -- invalid integrity, password based instead of signature or 1027 -- vice versa 1028 badRecipientNonce (13), 1029 -- invalid recipient nonce, either missing or wrong value 1030 timeNotAvailable (14), 1031 -- the TSA's time source is not available 1032 unacceptedPolicy (15), 1033 -- the requested TSA policy is not supported by the TSA. 1034 unacceptedExtension (16), 1035 -- the requested extension is not supported by the TSA. 1036 addInfoNotAvailable (17), 1037 -- the additional information requested could not be 1038 -- understood or is not available 1039 badSenderNonce (18), 1040 -- invalid sender nonce, either missing or wrong size 1041 badCertTemplate (19), 1042 -- invalid cert. template or missing mandatory information 1043 signerNotTrusted (20), 1044 -- signer of the message unknown or not trusted 1045 transactionIdInUse (21), 1046 -- the transaction identifier is already in use 1047 unsupportedVersion (22), 1048 -- the version of the message is not supported 1049 notAuthorized (23), 1050 -- the sender was not authorized to make the preceding 1051 -- request or perform the preceding action 1052 systemUnavail (24), 1053 -- the request cannot be handled due to system unavailability 1054 systemFailure (25), 1055 -- the request cannot be handled due to system failure 1056 duplicateCertReq (26) 1057 -- certificate cannot be issued because a duplicate 1058 -- certificate already exists 1059 } 1061 PKIStatusInfo ::= SEQUENCE { 1062 status PKIStatus, 1063 statusString PKIFreeText OPTIONAL, 1064 failInfo PKIFailureInfo OPTIONAL 1065 } 1067 OOBCert ::= CMPCertificate 1069 OOBCertHash ::= SEQUENCE { 1070 hashAlg [0] AlgorithmIdentifier OPTIONAL, 1071 certId [1] CertId OPTIONAL, 1072 hashVal BIT STRING 1073 -- hashVal is calculated over the DER encoding of the 1074 -- self-signed certificate with the identifier certID. 1075 } 1077 POPODecKeyChallContent ::= SEQUENCE OF Challenge 1078 -- One Challenge per encryption key certification request (in the 1079 -- same order as these requests appear in CertReqMessages). 1081 Challenge ::= SEQUENCE { 1082 owf AlgorithmIdentifier OPTIONAL, 1083 -- MUST be present in the first Challenge; MAY be omitted in 1084 -- any subsequent Challenge in POPODecKeyChallContent (if 1085 -- omitted, then the owf used in the immediately preceding 1086 -- Challenge is to be used). 1087 witness OCTET STRING, 1088 -- the result of applying the one-way function (owf) to a 1089 -- randomly-generated INTEGER, A. [Note that a different 1090 -- INTEGER MUST be used for each Challenge.] 1091 challenge OCTET STRING 1092 -- the encryption (under the public key for which the cert. 1093 -- request is being made) of Rand, where Rand is specified as 1094 -- Rand ::= SEQUENCE { 1095 -- int INTEGER, 1096 -- - the randomly-generated INTEGER A (above) 1097 -- sender GeneralName 1098 -- - the sender's name (as included in PKIHeader) 1099 -- } 1100 } 1101 POPODecKeyRespContent ::= SEQUENCE OF INTEGER 1102 -- One INTEGER per encryption key certification request (in the 1103 -- same order as these requests appear in CertReqMessages). The 1104 -- retrieved INTEGER A (above) is returned to the sender of the 1105 -- corresponding Challenge. 1107 CertRepMessage ::= SEQUENCE { 1108 caPubs [1] SEQUENCE SIZE (1..MAX) OF CMPCertificate 1109 OPTIONAL, 1110 response SEQUENCE OF CertResponse 1111 } 1113 CertResponse ::= SEQUENCE { 1114 certReqId INTEGER, 1115 -- to match this response with corresponding request (a value 1116 -- of -1 is to be used if certReqId is not specified in the 1117 -- corresponding request) 1118 status PKIStatusInfo, 1119 certifiedKeyPair CertifiedKeyPair OPTIONAL, 1120 rspInfo OCTET STRING OPTIONAL 1121 -- analogous to the id-regInfo-utf8Pairs string defined 1122 -- for regInfo in CertReqMsg [CRMF] 1123 } 1125 CertifiedKeyPair ::= SEQUENCE { 1126 certOrEncCert CertOrEncCert, 1127 privateKey [0] EncryptedKey OPTIONAL, 1128 -- see [CRMF] for comment on encoding 1129 -- Changed from Encrypted Value to EncryptedKey as a CHOICE of 1130 -- EncryptedValue and EnvelopedData due to the changes made in 1131 -- this document 1132 -- Using the choice EncryptedValue is bit-compatible to the 1133 -- syntax without this change 1134 publicationInfo [1] PKIPublicationInfo OPTIONAL 1135 } 1137 CertOrEncCert ::= CHOICE { 1138 certificate [0] CMPCertificate, 1139 encryptedCert [1] EncryptedKey 1140 -- Changed from Encrypted Value to EncryptedKey as a CHOICE of 1141 -- EncryptedValue and EnvelopedData due to the changes made in 1142 -- this document 1143 -- Using the choice EncryptedValue is bit-compatible to the 1144 -- syntax without this change 1145 } 1147 KeyRecRepContent ::= SEQUENCE { 1148 status PKIStatusInfo, 1149 newSigCert [0] CMPCertificate OPTIONAL, 1150 caCerts [1] SEQUENCE SIZE (1..MAX) OF 1151 CMPCertificate OPTIONAL, 1152 keyPairHist [2] SEQUENCE SIZE (1..MAX) OF 1153 CertifiedKeyPair OPTIONAL 1154 } 1156 RevReqContent ::= SEQUENCE OF RevDetails 1158 RevDetails ::= SEQUENCE { 1159 certDetails CertTemplate, 1160 -- allows requester to specify as much as they can about 1161 -- the cert. for which revocation is requested 1162 -- (e.g., for cases in which serialNumber is not available) 1163 crlEntryDetails Extensions OPTIONAL 1164 -- requested crlEntryExtensions 1165 } 1167 RevRepContent ::= SEQUENCE { 1168 status SEQUENCE SIZE (1..MAX) OF PKIStatusInfo, 1169 -- in same order as was sent in RevReqContent 1170 revCerts [0] SEQUENCE SIZE (1..MAX) OF CertId 1171 OPTIONAL, 1172 -- IDs for which revocation was requested 1173 -- (same order as status) 1174 crls [1] SEQUENCE SIZE (1..MAX) OF CertificateList 1175 OPTIONAL 1176 -- the resulting CRLs (there may be more than one) 1177 } 1179 CAKeyUpdAnnContent ::= SEQUENCE { 1180 oldWithNew CMPCertificate, -- old pub signed with new priv 1181 newWithOld CMPCertificate, -- new pub signed with old priv 1182 newWithNew CMPCertificate -- new pub signed with new priv 1183 } 1185 CertAnnContent ::= CMPCertificate 1187 RevAnnContent ::= SEQUENCE { 1188 status PKIStatus, 1189 certId CertId, 1190 willBeRevokedAt GeneralizedTime, 1191 badSinceDate GeneralizedTime, 1192 crlDetails Extensions OPTIONAL 1193 -- extra CRL details (e.g., crl number, reason, location, etc.) 1194 } 1196 CRLAnnContent ::= SEQUENCE OF CertificateList 1197 CertConfirmContent ::= SEQUENCE OF CertStatus 1199 CertStatus ::= SEQUENCE { 1200 certHash OCTET STRING, 1201 -- the hash of the certificate, using the same hash algorithm 1202 -- as is used to create and verify the certificate signature 1203 certReqId INTEGER, 1204 -- to match this confirmation with the corresponding req/rep 1205 statusInfo PKIStatusInfo OPTIONAL 1206 } 1208 PKIConfirmContent ::= NULL 1210 InfoTypeAndValue ::= SEQUENCE { 1211 infoType OBJECT IDENTIFIER, 1212 infoValue ANY DEFINED BY infoType OPTIONAL 1213 } 1214 -- Example InfoTypeAndValue contents include, but are not limited 1215 -- to, the following (un-comment in this ASN.1 module and use as 1216 -- appropriate for a given environment): 1217 -- 1218 -- id-it-caProtEncCert OBJECT IDENTIFIER ::= {id-it 1} 1219 -- CAProtEncCertValue ::= CMPCertificate 1220 -- id-it-signKeyPairTypes OBJECT IDENTIFIER ::= {id-it 2} 1221 -- SignKeyPairTypesValue ::= SEQUENCE OF AlgorithmIdentifier 1222 -- id-it-encKeyPairTypes OBJECT IDENTIFIER ::= {id-it 3} 1223 -- EncKeyPairTypesValue ::= SEQUENCE OF AlgorithmIdentifier 1224 -- id-it-preferredSymmAlg OBJECT IDENTIFIER ::= {id-it 4} 1225 -- PreferredSymmAlgValue ::= AlgorithmIdentifier 1226 -- id-it-caKeyUpdateInfo OBJECT IDENTIFIER ::= {id-it 5} 1227 -- CAKeyUpdateInfoValue ::= CAKeyUpdAnnContent 1228 -- id-it-currentCRL OBJECT IDENTIFIER ::= {id-it 6} 1229 -- CurrentCRLValue ::= CertificateList 1230 -- id-it-unsupportedOIDs OBJECT IDENTIFIER ::= {id-it 7} 1231 -- UnsupportedOIDsValue ::= SEQUENCE OF OBJECT IDENTIFIER 1232 -- id-it-keyPairParamReq OBJECT IDENTIFIER ::= {id-it 10} 1233 -- KeyPairParamReqValue ::= OBJECT IDENTIFIER 1234 -- id-it-keyPairParamRep OBJECT IDENTIFIER ::= {id-it 11} 1235 -- KeyPairParamRepValue ::= AlgorithmIdentifer 1236 -- id-it-revPassphrase OBJECT IDENTIFIER ::= {id-it 12} 1237 -- RevPassphraseValue ::= EncryptedKey 1238 -- -- Changed from Encrypted Value to EncryptedKey as a CHOICE 1239 -- -- of EncryptedValue and EnvelopedData due to the changes 1240 -- -- made in this document 1241 -- -- Using the choice EncryptedValue is bit-compatible to the 1242 -- -- syntax without this change 1243 -- id-it-implicitConfirm OBJECT IDENTIFIER ::= {id-it 13} 1244 -- ImplicitConfirmValue ::= NULL 1245 -- id-it-confirmWaitTime OBJECT IDENTIFIER ::= {id-it 14} 1246 -- ConfirmWaitTimeValue ::= GeneralizedTime 1247 -- id-it-origPKIMessage OBJECT IDENTIFIER ::= {id-it 15} 1248 -- OrigPKIMessageValue ::= PKIMessages 1249 -- id-it-suppLangTags OBJECT IDENTIFIER ::= {id-it 16} 1250 -- SuppLangTagsValue ::= SEQUENCE OF UTF8String 1251 -- 1252 -- where 1253 -- 1254 -- id-pkix OBJECT IDENTIFIER ::= { 1255 -- iso(1) identified-organization(3) 1256 -- dod(6) internet(1) security(5) mechanisms(5) pkix(7)} 1257 -- and 1258 -- id-it OBJECT IDENTIFIER ::= {id-pkix 4} 1259 -- 1260 -- 1261 -- This construct MAY also be used to define new PKIX Certificate 1262 -- Management Protocol request and response messages, or general- 1263 -- purpose (e.g., announcement) messages for future needs or for 1264 -- specific environments. 1266 GenMsgContent ::= SEQUENCE OF InfoTypeAndValue 1268 -- May be sent by EE, RA, or CA (depending on message content). 1269 -- The OPTIONAL infoValue parameter of InfoTypeAndValue will 1270 -- typically be omitted for some of the examples given above. 1271 -- The receiver is free to ignore any contained OBJ. IDs that it 1272 -- does not recognize. If sent from EE to CA, the empty set 1273 -- indicates that the CA may send 1274 -- any/all information that it wishes. 1276 GenRepContent ::= SEQUENCE OF InfoTypeAndValue 1277 -- Receiver MAY ignore any contained OIDs that it does not 1278 -- recognize. 1280 ErrorMsgContent ::= SEQUENCE { 1281 pKIStatusInfo PKIStatusInfo, 1282 errorCode INTEGER OPTIONAL, 1283 -- implementation-specific error codes 1284 errorDetails PKIFreeText OPTIONAL 1285 -- implementation-specific error details 1286 } 1288 PollReqContent ::= SEQUENCE OF SEQUENCE { 1289 certReqId INTEGER 1290 } 1292 PollRepContent ::= SEQUENCE OF SEQUENCE { 1293 certReqId INTEGER, 1294 checkAfter INTEGER, -- time in seconds 1295 reason PKIFreeText OPTIONAL 1296 } 1298 -- 1299 -- Extended Key Usage extension for PKI entities used in CMP 1300 -- operations, added due to the changes made in this document 1301 -- The EKUs for the CA and RA are reused from CMC as defined in 1302 -- [RFC6402] 1303 -- 1305 -- id-kp-cmcCA OBJECT IDENTIFIER ::= { id-kp 27 } 1306 -- id-kp-cmcRA OBJECT IDENTIFIER ::= { id-kp 28 } 1307 id-kp-cmKGA OBJECT IDENTIFIER ::= { id-kp 32 } 1309 END -- of CMP module 1311 A.2. 2002 ASN.1 Module 1313 This section contains the updated 2002 ASN.1 module for [RFC5912]. 1314 This module replaces the module in Section 9 of that document. The 1315 module contains those changes that were done to update to 2002 ASN.1 1316 standard done in [RFC5912] as well as changes made for this document. 1318 < TBD: Dose this document then also updates [RFC5912]? > 1320 < In case the working group sees a need to provide this ASN.1 module 1321 in 2015 syntax, please let me know. > 1323 PKIXCMP-2009 1324 { iso(1) identified-organization(3) dod(6) internet(1) 1325 security(5) mechanisms(5) pkix(7) id-mod(0) 1326 id-mod-cmp2000-02(50) } DEFINITIONS EXPLICIT TAGS ::= 1327 BEGIN 1328 IMPORTS 1330 AttributeSet{}, Extensions{}, EXTENSION, ATTRIBUTE 1331 FROM PKIX-CommonTypes-2009 1332 {iso(1) identified-organization(3) dod(6) internet(1) security(5) 1333 mechanisms(5) pkix(7) id-mod(0) id-mod-pkixCommon-02(57)} 1335 AlgorithmIdentifier{}, SIGNATURE-ALGORITHM, ALGORITHM, 1336 DIGEST-ALGORITHM, MAC-ALGORITHM 1337 FROM AlgorithmInformation-2009 1338 {iso(1) identified-organization(3) dod(6) internet(1) security(5) 1339 mechanisms(5) pkix(7) id-mod(0) 1340 id-mod-algorithmInformation-02(58)} 1342 Certificate, CertificateList, id-kp 1343 FROM PKIX1Explicit-2009 1344 {iso(1) identified-organization(3) dod(6) internet(1) security(5) 1345 mechanisms(5) pkix(7) id-mod(0) id-mod-pkix1-explicit-02(51)} 1347 GeneralName, KeyIdentifier 1348 FROM PKIX1Implicit-2009 1349 {iso(1) identified-organization(3) dod(6) internet(1) security(5) 1350 mechanisms(5) pkix(7) id-mod(0) id-mod-pkix1-implicit-02(59)} 1352 CertTemplate, PKIPublicationInfo, EncryptedKey, EncryptedValue, 1353 CertId,CertReqMessages 1354 FROM PKIXCRMF-2009 1355 { iso(1) identified-organization(3) dod(6) internet(1) 1356 security(5) mechanisms(5) pkix(7) id-mod(0) 1357 id-mod-crmf2005-02(55) } 1358 -- see also the behavioral clarifications to CRMF codified in 1359 -- Appendix C of this specification 1361 CertificationRequest 1362 FROM PKCS-10 1363 {iso(1) identified-organization(3) dod(6) internet(1) security(5) 1364 mechanisms(5) pkix(7) id-mod(0) id-mod-pkcs10-2009(69)} 1365 -- (specified in RFC 2986 with 1993 ASN.1 syntax and IMPLICIT 1366 -- tags). Alternatively, implementers may directly include 1367 -- the [PKCS10] syntax in this module 1369 localKeyId 1370 FROM PKCS-9 1371 {iso(1) member-body(2) us(840) rsadsi(113549) pkcs(1) pkcs-9(9) 1372 modules(0) pkcs-9(1)} 1373 -- The import of localKeyId is added due to the updates made in 1374 -- this document 1376 EnvelopedData, SignedData 1377 FROM CryptographicMessageSyntax-2009 1378 {iso(1) member-body(2) us(840) rsadsi(113549) pkcs(1) pkcs-9(9) 1379 smime(16) modules(0) id-mod-cms-2004-02(41)} 1380 -- The import of EnvelopedData and SignedData is added due to 1381 -- the updates made in this document 1382 ; 1384 -- the rest of the module contains locally defined OIDs and 1385 -- constructs 1387 CMPCertificate ::= CHOICE { x509v3PKCert Certificate, ... } 1388 -- This syntax, while bits-on-the-wire compatible with the 1389 -- standard X.509 definition of "Certificate", allows the 1390 -- possibility of future certificate types (such as X.509 1391 -- attribute certificates, WAP WTLS certificates, or other kinds 1392 -- of certificates) within this certificate management protocol, 1393 -- should a need ever arise to support such generality. Those 1394 -- implementations that do not foresee a need to ever support 1395 -- other certificate types MAY, if they wish, comment out the 1396 -- above structure and "uncomment" the following one prior to 1397 -- compiling this ASN.1 module. (Note that interoperability 1398 -- with implementations that don't do this will be unaffected by 1399 -- this change.) 1401 -- CMPCertificate ::= Certificate 1403 PKIMessage ::= SEQUENCE { 1404 header PKIHeader, 1405 body PKIBody, 1406 protection [0] PKIProtection OPTIONAL, 1407 extraCerts [1] SEQUENCE SIZE (1..MAX) OF CMPCertificate 1408 OPTIONAL } 1410 PKIMessages ::= SEQUENCE SIZE (1..MAX) OF PKIMessage 1412 PKIHeader ::= SEQUENCE { 1413 pvno INTEGER { cmp1999(1), cmp2000(2) }, 1414 sender GeneralName, 1415 -- identifies the sender 1416 recipient GeneralName, 1417 -- identifies the intended recipient 1418 messageTime [0] GeneralizedTime OPTIONAL, 1419 -- time of production of this message (used when sender 1420 -- believes that the transport will be "suitable"; i.e., 1421 -- that the time will still be meaningful upon receipt) 1422 protectionAlg [1] AlgorithmIdentifier{ALGORITHM, {...}} 1423 OPTIONAL, 1424 -- algorithm used for calculation of protection bits 1425 senderKID [2] KeyIdentifier OPTIONAL, 1426 recipKID [3] KeyIdentifier OPTIONAL, 1427 -- to identify specific keys used for protection 1428 transactionID [4] OCTET STRING OPTIONAL, 1429 -- identifies the transaction; i.e., this will be the same in 1430 -- corresponding request, response, certConf, and PKIConf 1431 -- messages 1432 senderNonce [5] OCTET STRING OPTIONAL, 1433 recipNonce [6] OCTET STRING OPTIONAL, 1434 -- nonces used to provide replay protection, senderNonce 1435 -- is inserted by the creator of this message; recipNonce 1436 -- is a nonce previously inserted in a related message by 1437 -- the intended recipient of this message 1438 freeText [7] PKIFreeText OPTIONAL, 1439 -- this may be used to indicate context-specific instructions 1440 -- (this field is intended for human consumption) 1441 generalInfo [8] SEQUENCE SIZE (1..MAX) OF 1442 InfoTypeAndValue OPTIONAL 1443 -- this may be used to convey context-specific information 1444 -- (this field not primarily intended for human consumption) 1445 } 1447 PKIFreeText ::= SEQUENCE SIZE (1..MAX) OF UTF8String 1448 -- text encoded as UTF-8 String [RFC3629] (note: each 1449 -- UTF8String MAY include an [RFC3066] language tag 1450 -- to indicate the language of the contained text; 1451 -- see [RFC2482] for details) 1453 PKIBody ::= CHOICE { -- message-specific body elements 1454 ir [0] CertReqMessages, --Initialization Request 1455 ip [1] CertRepMessage, --Initialization Response 1456 cr [2] CertReqMessages, --Certification Request 1457 cp [3] CertRepMessage, --Certification Response 1458 p10cr [4] CertificationRequest, --imported from [PKCS10] 1459 popdecc [5] POPODecKeyChallContent, --pop Challenge 1460 popdecr [6] POPODecKeyRespContent, --pop Response 1461 kur [7] CertReqMessages, --Key Update Request 1462 kup [8] CertRepMessage, --Key Update Response 1463 krr [9] CertReqMessages, --Key Recovery Request 1464 krp [10] KeyRecRepContent, --Key Recovery Response 1465 rr [11] RevReqContent, --Revocation Request 1466 rp [12] RevRepContent, --Revocation Response 1467 ccr [13] CertReqMessages, --Cross-Cert. Request 1468 ccp [14] CertRepMessage, --Cross-Cert. Response 1469 ckuann [15] CAKeyUpdAnnContent, --CA Key Update Ann. 1470 cann [16] CertAnnContent, --Certificate Ann. 1471 rann [17] RevAnnContent, --Revocation Ann. 1472 crlann [18] CRLAnnContent, --CRL Announcement 1473 pkiconf [19] PKIConfirmContent, --Confirmation 1474 nested [20] NestedMessageContent, --Nested Message 1475 genm [21] GenMsgContent, --General Message 1476 genp [22] GenRepContent, --General Response 1477 error [23] ErrorMsgContent, --Error Message 1478 certConf [24] CertConfirmContent, --Certificate confirm 1479 pollReq [25] PollReqContent, --Polling request 1480 pollRep [26] PollRepContent --Polling response 1481 } 1483 PKIProtection ::= BIT STRING 1485 ProtectedPart ::= SEQUENCE { 1486 header PKIHeader, 1487 body PKIBody } 1489 id-PasswordBasedMac OBJECT IDENTIFIER ::= { iso(1) member-body(2) 1490 usa(840) nt(113533) nsn(7) algorithms(66) 13 } 1491 PBMParameter ::= SEQUENCE { 1492 salt OCTET STRING, 1493 -- note: implementations MAY wish to limit acceptable sizes 1494 -- of this string to values appropriate for their environment 1495 -- in order to reduce the risk of denial-of-service attacks 1496 owf AlgorithmIdentifier{DIGEST-ALGORITHM, {...}}, 1497 -- AlgId for a One-Way Function (SHA-1 recommended) 1498 iterationCount INTEGER, 1499 -- number of times the OWF is applied 1500 -- note: implementations MAY wish to limit acceptable sizes 1501 -- of this integer to values appropriate for their environment 1502 -- in order to reduce the risk of denial-of-service attacks 1503 mac AlgorithmIdentifier{MAC-ALGORITHM, {...}} 1504 -- the MAC AlgId (e.g., DES-MAC, Triple-DES-MAC [PKCS11], 1505 -- or HMAC [RFC2104, RFC2202]) 1506 } 1508 id-DHBasedMac OBJECT IDENTIFIER ::= { iso(1) member-body(2) 1509 usa(840) nt(113533) nsn(7) algorithms(66) 30 } 1510 DHBMParameter ::= SEQUENCE { 1511 owf AlgorithmIdentifier{DIGEST-ALGORITHM, {...}}, 1512 -- AlgId for a One-Way Function (SHA-1 recommended) 1513 mac AlgorithmIdentifier{MAC-ALGORITHM, {...}} 1514 -- the MAC AlgId (e.g., DES-MAC, Triple-DES-MAC [PKCS11], 1515 -- or HMAC [RFC2104, RFC2202]) 1516 } 1518 PKIStatus ::= INTEGER { 1519 accepted (0), 1520 -- you got exactly what you asked for 1521 grantedWithMods (1), 1522 -- you got something like what you asked for; the 1523 -- requester is responsible for ascertaining the differences 1524 rejection (2), 1525 -- you don't get it, more information elsewhere in the message 1526 waiting (3), 1527 -- the request body part has not yet been processed; expect to 1528 -- hear more later (note: proper handling of this status 1529 -- response MAY use the polling req/rep PKIMessages specified 1530 -- in Section 5.3.22; alternatively, polling in the underlying 1531 -- transport layer MAY have some utility in this regard) 1532 revocationWarning (4), 1533 -- this message contains a warning that a revocation is 1534 -- imminent 1535 revocationNotification (5), 1536 -- notification that a revocation has occurred 1537 keyUpdateWarning (6) 1538 -- update already done for the oldCertId specified in 1539 -- CertReqMsg 1540 } 1542 PKIFailureInfo ::= BIT STRING { 1543 -- since we can fail in more than one way! 1544 -- More codes may be added in the future if/when required. 1545 badAlg (0), 1546 -- unrecognized or unsupported Algorithm Identifier 1547 badMessageCheck (1), 1548 -- integrity check failed (e.g., signature did not verify) 1549 badRequest (2), 1550 -- transaction not permitted or supported 1551 badTime (3), 1552 -- messageTime was not sufficiently close to the system time, 1553 -- as defined by local policy 1554 badCertId (4), 1555 -- no certificate could be found matching the provided criteria 1556 badDataFormat (5), 1557 -- the data submitted has the wrong format 1558 wrongAuthority (6), 1559 -- the authority indicated in the request is different from the 1560 -- one creating the response token 1561 incorrectData (7), 1562 -- the requester's data is incorrect (for notary services) 1563 missingTimeStamp (8), 1564 -- when the timestamp is missing but should be there 1565 -- (by policy) 1566 badPOP (9), 1567 -- the proof-of-possession failed 1568 certRevoked (10), 1569 -- the certificate has already been revoked 1570 certConfirmed (11), 1571 -- the certificate has already been confirmed 1572 wrongIntegrity (12), 1573 -- invalid integrity, password based instead of signature or 1574 -- vice versa 1575 badRecipientNonce (13), 1576 -- invalid recipient nonce, either missing or wrong value 1577 timeNotAvailable (14), 1578 -- the TSA's time source is not available 1579 unacceptedPolicy (15), 1580 -- the requested TSA policy is not supported by the TSA 1581 unacceptedExtension (16), 1582 -- the requested extension is not supported by the TSA 1583 addInfoNotAvailable (17), 1584 -- the additional information requested could not be 1585 -- understood or is not available 1586 badSenderNonce (18), 1587 -- invalid sender nonce, either missing or wrong size 1588 badCertTemplate (19), 1589 -- invalid cert. template or missing mandatory information 1590 signerNotTrusted (20), 1591 -- signer of the message unknown or not trusted 1592 transactionIdInUse (21), 1593 -- the transaction identifier is already in use 1594 unsupportedVersion (22), 1595 -- the version of the message is not supported 1596 notAuthorized (23), 1597 -- the sender was not authorized to make the preceding 1598 -- request or perform the preceding action 1599 systemUnavail (24), 1600 -- the request cannot be handled due to system unavailability 1601 systemFailure (25), 1602 -- the request cannot be handled due to system failure 1603 duplicateCertReq (26) 1604 -- certificate cannot be issued because a duplicate 1605 -- certificate already exists 1606 } 1608 PKIStatusInfo ::= SEQUENCE { 1609 status PKIStatus, 1610 statusString PKIFreeText OPTIONAL, 1611 failInfo PKIFailureInfo OPTIONAL } 1613 OOBCert ::= CMPCertificate 1615 OOBCertHash ::= SEQUENCE { 1616 hashAlg [0] AlgorithmIdentifier{DIGEST-ALGORITHM, {...}} 1617 OPTIONAL, 1618 certId [1] CertId OPTIONAL, 1619 hashVal BIT STRING 1620 -- hashVal is calculated over the DER encoding of the 1621 -- self-signed certificate with the identifier certID. 1622 } 1624 POPODecKeyChallContent ::= SEQUENCE OF Challenge 1625 -- One Challenge per encryption key certification request (in the 1626 -- same order as these requests appear in CertReqMessages). 1628 Challenge ::= SEQUENCE { 1629 owf AlgorithmIdentifier{DIGEST-ALGORITHM, {...}} 1630 OPTIONAL, 1631 -- MUST be present in the first Challenge; MAY be omitted in 1632 -- any subsequent Challenge in POPODecKeyChallContent (if 1633 -- omitted, then the owf used in the immediately preceding 1634 -- Challenge is to be used). 1635 witness OCTET STRING, 1636 -- the result of applying the one-way function (owf) to a 1637 -- randomly-generated INTEGER, A. [Note that a different 1638 -- INTEGER MUST be used for each Challenge.] 1639 challenge OCTET STRING 1640 -- the encryption (under the public key for which the cert. 1641 -- request is being made) of Rand, where Rand is specified as 1642 -- Rand ::= SEQUENCE { 1643 -- int INTEGER, 1644 -- - the randomly-generated INTEGER A (above) 1645 -- sender GeneralName 1646 -- - the sender's name (as included in PKIHeader) 1647 -- } 1648 } 1650 POPODecKeyRespContent ::= SEQUENCE OF INTEGER 1651 -- One INTEGER per encryption key certification request (in the 1652 -- same order as these requests appear in CertReqMessages). The 1653 -- retrieved INTEGER A (above) is returned to the sender of the 1654 -- corresponding Challenge. 1656 CertRepMessage ::= SEQUENCE { 1657 caPubs [1] SEQUENCE SIZE (1..MAX) OF CMPCertificate 1658 OPTIONAL, 1659 response SEQUENCE OF CertResponse } 1661 CertResponse ::= SEQUENCE { 1662 certReqId INTEGER, 1663 -- to match this response with the corresponding request (a value 1664 -- of -1 is to be used if certReqId is not specified in the 1665 -- corresponding request) 1666 status PKIStatusInfo, 1667 certifiedKeyPair CertifiedKeyPair OPTIONAL, 1668 rspInfo OCTET STRING OPTIONAL 1669 -- analogous to the id-regInfo-utf8Pairs string defined 1670 -- for regInfo in CertReqMsg [RFC4211] 1671 } 1673 CertifiedKeyPair ::= SEQUENCE { 1674 certOrEncCert CertOrEncCert, 1675 privateKey [0] EncryptedKey OPTIONAL, 1676 -- see [RFC4211] for comment on encoding 1677 -- Changed from Encrypted Value to EncryptedKey as a CHOICE of 1678 -- EncryptedValue and EnvelopedData due to the changes made in 1679 -- this document 1680 -- Using the choice EncryptedValue is bit-compatible to the 1681 -- syntax without this change 1682 publicationInfo [1] PKIPublicationInfo OPTIONAL } 1684 CertOrEncCert ::= CHOICE { 1685 certificate [0] CMPCertificate, 1686 encryptedCert [1] EncryptedKey 1687 -- Changed from Encrypted Value to EncryptedKey as a CHOICE of 1688 -- EncryptedValue and EnvelopedData due to the changes made in 1689 -- this document 1690 -- Using the choice EncryptedValue is bit-compatible to the 1691 -- syntax without this change 1692 } 1694 KeyRecRepContent ::= SEQUENCE { 1695 status PKIStatusInfo, 1696 newSigCert [0] CMPCertificate OPTIONAL, 1697 caCerts [1] SEQUENCE SIZE (1..MAX) OF 1698 CMPCertificate OPTIONAL, 1699 keyPairHist [2] SEQUENCE SIZE (1..MAX) OF 1700 CertifiedKeyPair OPTIONAL } 1702 RevReqContent ::= SEQUENCE OF RevDetails 1704 RevDetails ::= SEQUENCE { 1705 certDetails CertTemplate, 1706 -- allows requester to specify as much as they can about 1707 -- the cert. for which revocation is requested 1708 -- (e.g., for cases in which serialNumber is not available) 1709 crlEntryDetails Extensions{{...}} OPTIONAL 1710 -- requested crlEntryExtensions 1711 } 1713 RevRepContent ::= SEQUENCE { 1714 status SEQUENCE SIZE (1..MAX) OF PKIStatusInfo, 1715 -- in same order as was sent in RevReqContent 1716 revCerts [0] SEQUENCE SIZE (1..MAX) OF CertId OPTIONAL, 1717 -- IDs for which revocation was requested 1718 -- (same order as status) 1719 crls [1] SEQUENCE SIZE (1..MAX) OF CertificateList OPTIONAL 1720 -- the resulting CRLs (there may be more than one) 1721 } 1723 CAKeyUpdAnnContent ::= SEQUENCE { 1724 oldWithNew CMPCertificate, -- old pub signed with new priv 1725 newWithOld CMPCertificate, -- new pub signed with old priv 1726 newWithNew CMPCertificate -- new pub signed with new priv 1727 } 1729 CertAnnContent ::= CMPCertificate 1731 RevAnnContent ::= SEQUENCE { 1732 status PKIStatus, 1733 certId CertId, 1734 willBeRevokedAt GeneralizedTime, 1735 badSinceDate GeneralizedTime, 1736 crlDetails Extensions{{...}} OPTIONAL 1737 -- extra CRL details (e.g., crl number, reason, location, etc.) 1738 } 1740 CRLAnnContent ::= SEQUENCE OF CertificateList 1741 PKIConfirmContent ::= NULL 1743 NestedMessageContent ::= PKIMessages 1745 INFO-TYPE-AND-VALUE ::= TYPE-IDENTIFIER 1747 InfoTypeAndValue ::= SEQUENCE { 1748 infoType INFO-TYPE-AND-VALUE. 1749 &id({SupportedInfoSet}), 1750 infoValue INFO-TYPE-AND-VALUE. 1751 &Type({SupportedInfoSet}{@infoType}) } 1753 SupportedInfoSet INFO-TYPE-AND-VALUE ::= { ... } 1755 -- Example InfoTypeAndValue contents include, but are not limited 1756 -- to, the following (uncomment in this ASN.1 module and use as 1757 -- appropriate for a given environment): 1758 -- 1759 -- id-it-caProtEncCert OBJECT IDENTIFIER ::= {id-it 1} 1760 -- CAProtEncCertValue ::= CMPCertificate 1761 -- id-it-signKeyPairTypes OBJECT IDENTIFIER ::= {id-it 2} 1762 -- SignKeyPairTypesValue ::= SEQUENCE OF 1763 -- AlgorithmIdentifier{{...}} 1764 -- id-it-encKeyPairTypes OBJECT IDENTIFIER ::= {id-it 3} 1765 -- EncKeyPairTypesValue ::= SEQUENCE OF 1766 -- AlgorithmIdentifier{{...}} 1767 -- id-it-preferredSymmAlg OBJECT IDENTIFIER ::= {id-it 4} 1768 -- PreferredSymmAlgValue ::= AlgorithmIdentifier{{...}} 1769 -- id-it-caKeyUpdateInfo OBJECT IDENTIFIER ::= {id-it 5} 1770 -- CAKeyUpdateInfoValue ::= CAKeyUpdAnnContent 1771 -- id-it-currentCRL OBJECT IDENTIFIER ::= {id-it 6} 1772 -- CurrentCRLValue ::= CertificateList 1773 -- id-it-unsupportedOIDs OBJECT IDENTIFIER ::= {id-it 7} 1774 -- UnsupportedOIDsValue ::= SEQUENCE OF OBJECT IDENTIFIER 1775 -- id-it-keyPairParamReq OBJECT IDENTIFIER ::= {id-it 10} 1776 -- KeyPairParamReqValue ::= OBJECT IDENTIFIER 1777 -- id-it-keyPairParamRep OBJECT IDENTIFIER ::= {id-it 11} 1778 -- KeyPairParamRepValue ::= AlgorithmIdentifer 1779 -- id-it-revPassphrase OBJECT IDENTIFIER ::= {id-it 12} 1780 -- RevPassphraseValue ::= EncryptedKey 1781 -- -- Changed from Encrypted Value to EncryptedKey as a CHOICE 1782 -- -- of EncryptedValue and EnvelopedData due to the changes 1783 -- -- made in this document 1784 -- -- Using the choice EncryptedValue is bit-compatible to 1785 -- -- the syntax without this change 1786 -- id-it-implicitConfirm OBJECT IDENTIFIER ::= {id-it 13} 1787 -- ImplicitConfirmValue ::= NULL 1788 -- id-it-confirmWaitTime OBJECT IDENTIFIER ::= {id-it 14} 1789 -- ConfirmWaitTimeValue ::= GeneralizedTime 1790 -- id-it-origPKIMessage OBJECT IDENTIFIER ::= {id-it 15} 1791 -- OrigPKIMessageValue ::= PKIMessages 1792 -- id-it-suppLangTags OBJECT IDENTIFIER ::= {id-it 16} 1793 -- SuppLangTagsValue ::= SEQUENCE OF UTF8String 1794 -- 1795 -- where 1796 -- 1797 -- id-pkix OBJECT IDENTIFIER ::= { 1798 -- iso(1) identified-organization(3) 1799 -- dod(6) internet(1) security(5) mechanisms(5) pkix(7)} 1800 -- and 1801 -- id-it OBJECT IDENTIFIER ::= {id-pkix 4} 1802 -- 1803 -- 1804 -- This construct MAY also be used to define new PKIX Certificate 1805 -- Management Protocol request and response messages, or general- 1806 -- purpose (e.g., announcement) messages for future needs or for 1807 -- specific environments. 1809 GenMsgContent ::= SEQUENCE OF InfoTypeAndValue 1811 -- May be sent by EE, RA, or CA (depending on message content). 1812 -- The OPTIONAL infoValue parameter of InfoTypeAndValue will 1813 -- typically be omitted for some of the examples given above. 1814 -- The receiver is free to ignore any contained OBJECT IDs that it 1815 -- does not recognize. If sent from EE to CA, the empty set 1816 -- indicates that the CA may send 1817 -- any/all information that it wishes. 1819 GenRepContent ::= SEQUENCE OF InfoTypeAndValue 1820 -- Receiver MAY ignore any contained OIDs that it does not 1821 -- recognize. 1823 ErrorMsgContent ::= SEQUENCE { 1824 pKIStatusInfo PKIStatusInfo, 1825 errorCode INTEGER OPTIONAL, 1826 -- implementation-specific error codes 1827 errorDetails PKIFreeText OPTIONAL 1828 -- implementation-specific error details 1829 } 1831 CertConfirmContent ::= SEQUENCE OF CertStatus 1833 CertStatus ::= SEQUENCE { 1834 certHash OCTET STRING, 1835 -- the hash of the certificate, using the same hash algorithm 1836 -- as is used to create and verify the certificate signature 1837 certReqId INTEGER, 1838 -- to match this confirmation with the corresponding req/rep 1839 statusInfo PKIStatusInfo OPTIONAL } 1841 PollReqContent ::= SEQUENCE OF SEQUENCE { 1842 certReqId INTEGER } 1844 PollRepContent ::= SEQUENCE OF SEQUENCE { 1845 certReqId INTEGER, 1846 checkAfter INTEGER, -- time in seconds 1847 reason PKIFreeText OPTIONAL } 1849 -- 1850 -- Extended Key Usage extension for PKI entities used in CMP 1851 -- operations, added due to the changes made in this document 1852 -- The EKUs for the CA and RA are reused from CMC as defined in 1853 -- [RFC6402] 1854 -- 1856 -- id-kp-cmcCA OBJECT IDENTIFIER ::= { id-kp 27 } 1857 -- id-kp-cmcRA OBJECT IDENTIFIER ::= { id-kp 28 } 1858 id-kp-cmKGA OBJECT IDENTIFIER ::= { id-kp 32 } 1860 END 1862 Appendix B. History of changes 1864 Note: This appendix will be deleted in the final version of the 1865 document. 1867 From version 02 -> 03: 1869 o Added a ToDo on aligning with the CMP Algorithms draft that will 1870 be set up as decided in IETF 108 1872 o Updated section on Encrypted Values in Section 2.4 to add the 1873 AsymmetricKey Package structure to transport a newly generated 1874 private key as decided in IETF 108 1876 o Updated the IANA Considerations of [RFC4210] in Section 2.9 1878 o Added the pre-registered OID in Section 2.9 and the ASN.1 module 1880 o Added Section 3Section 3 to document the changes to RFC 6712 1881 [RFC6712] regarding URI discovery and using the path-prefix of 1882 '/.well-known/' as discussed in IETF 108 1884 o Updated the IANA Considerations section 1886 o Added a complete updated ASN.1 module in 1988 syntax to update 1887 Appendix F of [RFC4210] and a complete updated ASN.1 module in 1888 2002 syntax to update Section 9 of [RFC5912] 1890 o Minor changes in wording 1892 From version 01 -> 02: 1894 o Updated section on EKU OIDs in Section 2.2 as decided in IETF 107 1896 o Changed from symmetric key-encryption to password-based key 1897 management technique in Section 2.4 as discussed with Russ and Jim 1898 on the mailing list 1900 o Defined the attribute containing the key identifier for the 1901 revocation passphrase in Section 2.9 1903 o Moved the change history to the Appendix 1905 From version 00 -> 01: 1907 o Minor changes in wording 1909 From draft-brockhaus-lamps-cmp-updates-03 -> draft-ietf-lamps-cmp- 1910 updates-00: 1912 o Changes required to reflect WG adoption 1914 From version 02 -> 03: 1916 o Added some clarification in Section 2.1 1918 From version 01 -> 02: 1920 o Added clarification to section on multiple protection 1922 o Added clarification on new EKUs after some exchange with Tomas 1923 Gustavsson 1925 o Reused OIDs from RFC 6402 [RFC6402] as suggested by Sean Turner at 1926 IETF 106 1928 o Added clarification on the field containing the key identifier for 1929 a revocation passphrase 1931 o Minor changes in wording 1933 From version 00 -> 01: 1935 o Added a section describing the new extended key usages 1937 o Completed the section on changes to the specification of encrypted 1938 values 1940 o Added a section on clarification to Appendix D.4 1942 o Minor generalization in RFC 4210 [RFC4210] Sections 5.1.3.4 and 1943 5.3.22 1945 o Minor changes in wording 1947 Author's Address 1949 Hendrik Brockhaus 1950 Siemens AG 1952 Email: hendrik.brockhaus@siemens.com