idnits 2.17.1 draft-ietf-lamps-cmp-updates-04.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 (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 (September 8, 2020) is 1324 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 1859 == Missing Reference: 'CRMF' is mentioned on line 1205, but not defined -- Looks like a reference, but probably isn't: '1' on line 1862 == Missing Reference: 'PKCS10' is mentioned on line 1568, but not defined -- Looks like a reference, but probably isn't: '2' on line 1809 -- Looks like a reference, but probably isn't: '3' on line 1567 -- Looks like a reference, but probably isn't: '4' on line 1568 -- Looks like a reference, but probably isn't: '5' on line 1569 -- Looks like a reference, but probably isn't: '6' on line 1570 -- Looks like a reference, but probably isn't: '7' on line 1571 -- Looks like a reference, but probably isn't: '8' on line 1572 == Missing Reference: 'RFC3629' is mentioned on line 1558, but not defined == Missing Reference: 'RFC3066' is mentioned on line 1559, but not defined ** Obsolete undefined reference: RFC 3066 (Obsoleted by RFC 4646, RFC 4647) == Missing Reference: 'RFC2482' is mentioned on line 1561, but not defined ** Obsolete undefined reference: RFC 2482 (Obsoleted by RFC 6082) -- Looks like a reference, but probably isn't: '9' on line 1573 -- Looks like a reference, but probably isn't: '10' on line 1574 -- Looks like a reference, but probably isn't: '11' on line 1575 -- Looks like a reference, but probably isn't: '12' on line 1576 -- Looks like a reference, but probably isn't: '13' on line 1577 -- Looks like a reference, but probably isn't: '14' on line 1578 -- Looks like a reference, but probably isn't: '15' on line 1579 -- Looks like a reference, but probably isn't: '16' on line 1580 -- Looks like a reference, but probably isn't: '17' on line 1581 -- Looks like a reference, but probably isn't: '18' on line 1582 -- Looks like a reference, but probably isn't: '19' on line 1583 -- Looks like a reference, but probably isn't: '20' on line 1584 -- Looks like a reference, but probably isn't: '21' on line 1585 -- Looks like a reference, but probably isn't: '22' on line 1586 -- Looks like a reference, but probably isn't: '23' on line 1587 -- Looks like a reference, but probably isn't: '24' on line 1588 -- Looks like a reference, but probably isn't: '25' on line 1589 -- Looks like a reference, but probably isn't: '26' on line 1590 == Missing Reference: 'PKCS11' is mentioned on line 1624, but not defined == Missing Reference: 'RFC2104' is mentioned on line 1625, but not defined == Missing Reference: 'RFC2202' is mentioned on line 1625, but not defined ** 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-02 Summary: 7 errors (**), 0 flaws (~~), 11 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) September 8, 2020 5 Intended status: Standards Track 6 Expires: March 12, 2021 8 CMP Updates 9 draft-ietf-lamps-cmp-updates-04 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 March 12, 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.19. - PKI General Message Content . . 10 67 2.8. Update Section 5.3.22 - Polling Request and Response . . 11 68 2.9. Update Section 9 - IANA Considerations . . . . . . . . . 12 69 2.10. Update Appendix B - The Use of Revocation Passphrase . . 13 70 2.11. Update Appendix C - Request Message Behavioral 71 Clarifications . . . . . . . . . . . . . . . . . . . . . 13 72 2.12. Update Appendix D.4. - Initial Registration/Certification 73 (Basic Authenticated Scheme) . . . . . . . . . . . . . . 14 74 3. Updates to RFC 6712 - HTTP Transfer for the Certificate 75 Management Protocol (CMP) . . . . . . . . . . . . . . . . . . 14 76 3.1. New Section 1.1. - Changes since RFC 6712 . . . . . . . . 14 77 3.2. New Section 3.6. - HTTP Request-URI . . . . . . . . . . . 15 78 3.3. Update Section 6. - IANA Considerations . . . . . . . . . 16 79 4. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 16 80 5. Security Considerations . . . . . . . . . . . . . . . . . . . 17 81 6. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 17 82 7. References . . . . . . . . . . . . . . . . . . . . . . . . . 17 83 7.1. Normative References . . . . . . . . . . . . . . . . . . 17 84 7.2. Informative References . . . . . . . . . . . . . . . . . 18 85 Appendix A. ASN.1 Modules . . . . . . . . . . . . . . . . . . . 19 86 A.1. 1988 ASN.1 Module . . . . . . . . . . . . . . . . . . . . 19 87 A.2. 2002 ASN.1 Module . . . . . . . . . . . . . . . . . . . . 31 88 Appendix B. History of changes . . . . . . . . . . . . . . . . . 43 89 Author's Address . . . . . . . . . . . . . . . . . . . . . . . . 45 91 1. Introduction 93 While using CMP [RFC4210] in industrial and IoT environments and 94 developing the Lightweight CMP Profile 95 [I-D.ietf-lamps-lightweight-cmp-profile] some limitations were 96 identified in the original CMP specification. This document updates 97 RFC 4210 [RFC4210] and RFC 6712 [RFC6712] to overcome these 98 limitations. 100 In general, this document aims to improve the crypto agility of CMP 101 to be flexible to react on future advances in cryptography. 103 This document also introduces new extended key usages to identify CMP 104 endpoints on registration and certification authorities. 106 1.1. Convention and Terminology 108 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 109 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 110 document are to be interpreted as described in RFC 2119 [RFC2119]. 112 In this document, these words will appear with that interpretation 113 only when in ALL CAPS. Lower case uses of these words are not to be 114 interpreted as carrying significance described in RFC 2119. 116 Technical terminology is used in conformance with RFC 4210 [RFC4210], 117 RFC 4211 [RFC4211], and RFC 5280 [RFC5280]. The following key words 118 are used: 120 CA: Certification authority, which issues certificates. 122 RA: Registration authority, an optional system component to which a 123 CA delegates certificate management functions such as 124 authorization checks. 126 KGA: Key generation authority, which generates key pairs on behalf of 127 an EE. The KGA could be co-located with an RA or a CA. 129 EE: End entity, a user, device, or service that holds a PKI 130 certificate. An identifier for the EE is given as its subject 131 of the certificate. 133 2. Updates to RFC 4210 - Certificate Management Protocol (CMP) 135 2.1. New Section 1.1. - Changes since RFC 4210 137 The following subsection describes feature updates to RFC 4210 138 [RFC4210]. They are always related to the base specification. Hence 139 references to the original sections in RFC 4210 [RFC4210] are used 140 whenever possible. 142 Insert this section at the end of the current Section 1. 144 1.1 Changes since RFC 4210 145 The following updates are made in [thisRFC]: 147 o Add new extended key usages for different CMP server types, e.g. 148 registration authority and certification authority, to express the 149 authorization of the entity identified in the certificate 150 containing the respective extended key usage extension to act as 151 the indicated PKI management entity. 153 o Extend the description of multiple protection to cover additional 154 use cases, e.g., batch processing of messages. 156 o Offering EnvelopedData as the preferred choice next to 157 EncryptedValue to extend crypto agility in CMP. Note that 158 according to RFC 4211 [RFC4211] section 2.1.9 the use of the 159 EncryptedValue structure has been deprecated in favor of the 160 EnvelopedData structure. RFC 4211 [RFC4211] offers the 161 EncryptedKey structure, a choice of EncryptedValue and 162 EnvelopedData for migration to EnvelopedData. For reasons of 163 completeness and consistency the exchange of EncryptedValue is 164 performed for all usages in RFC 4210 [RFC4210]. This includes the 165 protection of centrally generated private keys, encryption of 166 certificates, and revocation passphrases. 168 o Extend the usage of polling also to p10cr messages. 170 < TBD: The specification of algorithm profiles seed to be moved to a 171 separate document. > 173 2.2. New Section 4.5 - Extended Key Usage 175 The following subsection describes new extended key usages for 176 different CMP server types specified in RFC 4210 [RFC4210]. 178 Insert this section at the end of the current Section 4. 180 4.5 Extended Key Usage 182 The Extended Key Usage (EKU) extension indicates the purposes for 183 which the certified public key may be used. It therefore restricts 184 the use of a certificate to specific applications. 186 A CA may want to delegate parts of their duties to other PKI 187 management entities. The mechanism to prove this delegation 188 explained in this section offers zero-touch means to check the 189 authorization of such delegation. Such delegation could also be 190 expressed by other means, e.g., explicit configuration. 192 To offer automatic validation means for the delegation of a role by a 193 CA, the certificates used by PKI management entities for CMP message 194 protection or signed data for central key generation MUST be issued 195 by the delegating CA and MUST contain the respective EKUs. This 196 proves the authorization of this entity by the delegating CA to act 197 as the PKI management entity as described below. 199 The ASN.1 to define these EKUs is: 201 id-kp OBJECT IDENTIFIER ::= 202 { iso(1) identified-organization(3) dod(6) internet(1) 203 security(5) mechanisms(5) pkix(7) kp(3) } 205 id-kp-cmcCA OBJECT IDENTIFIER ::= { id-kp 27 } 206 id-kp-cmcRA OBJECT IDENTIFIER ::= { id-kp 28 } 207 id-kp-cmKGA OBJECT IDENTIFIER ::= { id-kp 32 } 209 Note: RFC 6402 section 2.10 [RFC6402] specifies OIDs for a CMC CA and 210 a CMC RA. As the functionality of a CA and RA is not specific to 211 whether use CMC or CMP as certificate management protocol, the same 212 OIDs SHALL be used for a CMP CA and a CMP RA. 214 < TBD: The Description of the OIDs for id-kp-cmcCA and id-kp-cmcRA 215 needs to be extended to avoid confusion as they currently only refer 216 to CMC. > 218 The description of the PKI management entity for each of the EKUs is 219 as follows: 221 CMP CA: CMP Certification Authorities are CMP endpoints on CA 222 equipment as described in section 3.1.1.2. The key used in 223 the context of CMP management operations, especially CMP 224 message protection, need not be the same key that signs the 225 certificates. It is necessary, however, to ensure that the 226 entity acting as CMP CA is authorized to do so. Therefore, 227 the CMP CA MUST do one of the following, 229 * use the CA private key on the CMP endpoint, or 231 * explicitly designate this authority to another entity. 233 For automatic validation of such delegation it MUST be 234 indicated by the id-kp-cmcCA extended key usage. This 235 extended key usage MUST be placed into the certificate used 236 on the CA equipment and the CA that delegates this role MUST 237 issue the CMP CA certificate. 239 Note: Using a separate key pair for protecting CMP 240 management operations at the CA decreases the number of 241 operations of the private key used to sign certificates. 243 CMP RA: CMP Registration Authorities are CMP endpoints on RA 244 equipment as described in Section 3.1.1.3. A CMP RA is 245 identified by the id-kp-cmcRA extended key usage. This 246 extended key usage is placed into RA certificates. The CA 247 that delegated this role is identified by the CA that issued 248 the CMP RA certificate. 250 CMP KGA: CMP Key Generation Authorities are identified by the id-kp- 251 cmKGA extended key usage. Though the CMP KGA knows the 252 private key it generated on behalf of the end entity. This 253 is a very sensitive service and needs specific 254 authorization. This authorization is either with the CA 255 certificate itself, or indicated by placing the id-kp-cmKGA 256 extended key usage into the CMP RA or CMP CA certificate 257 used to authenticate the origin of the private key, and to 258 express the authorization to offer this service. 260 Note: In device PKIs, especially those issuing IDevID certificates, 261 CA may have very long validity (including the GeneralizedTime value 262 99991231235959Z to indicate a not well-defined expiration date as 263 specified in IEEE 802.1AR Section 8.5 [IEEE802.1AR] and RFC 5280 264 Section 4.1.2.5 [RFC5280]). Such validity periods SHOULD NOT be used 265 for protection of CMP messages. Certificates for delegated CMP 266 message protection (CMP CA, CMP RA, CMP KGA) MUST NOT use indefinite 267 expiration date. 269 2.3. Replace Section 5.1.3.4 - Multiple Protection 271 Section 5.1.3.4 of RFC 4210 [RFC4210] describes the nested message. 272 This document opens the usage of nested messages also for batch 273 transport of PKI messages between different PKI management entities. 275 Replace the text of the section with the following text. 277 In cases where an end entity sends a protected PKI message to an RA, 278 the RA MAY forward that message to a CA, adding its own protection 279 (which MAY be a MAC or a signature, depending on the information and 280 certificates shared between the RA and the CA). There are different 281 use cases for such multi protected messages. 283 o The RA confirms the validation and authorization of a message and 284 forwards the original message unchanged. 286 o The RA collects several messages and forwards them in a batch. 287 This can for instance be used to bridge an off-line connection 288 between two PKI management entities. In communication to the CA 289 request messages and in communication from the CA response or 290 announcement messages will be collected in such batch. 292 o The RA modifies the message(s) in some way (e.g., add or modify 293 particular field values or add new extensions) before forwarding 294 them, then it MAY create its own desired PKIBody. In case the 295 changes made by the RA to PKIMessage breaks the POP, the RA MUST 296 either set the POP RAVerified or include the original PKIMessage 297 from the EE in the generalInfo field of PKIHeader of the nested 298 message (to force the CA to check POP on the original message). 299 The infoType to be used in this situation is {id-it 15} (see 300 Section 5.3.19 for the value of id-it) and the infoValue is 301 PKIMessages (contents MUST be in the same order as the requests in 302 PKIBody). For simplicity reasons, if batching is used in 303 combination with inclusion of the original PKIMessage in the 304 generalInfo field, all messages in the batch MUST be of the same 305 type (e.g., ir). 307 These use cases are accomplished by nesting the messages sent by the 308 PKI entity within a new PKI message. The structure used is as 309 follows. 311 NestedMessageContent ::= PKIMessages 313 (The use of PKIMessages, a SEQUENCE OF PKIMessage, lets the RA batch 314 the requests of several EEs in a single new message.) 316 2.4. Replace Section 5.2.2. - Encrypted Values 318 Section 5.2.2 of RFC 4210 [RFC4210] describes the usage of 319 EncryptedValue to transport encrypted data. This document extends 320 the encryption of data to preferably use EnvelopedData. 322 Replace the text of the section with the following text. 324 Where encrypted data (restricted, in this specification, to be either 325 private keys, certificates, or passwords) are sent in PKI messages, 326 the EncryptedKey data structure is used. 328 EncryptedKey ::= CHOICE { 329 encryptedValue EncryptedValue, -- deprecated 330 envelopedData [0] EnvelopedData } 332 See CRMF [RFC4211] for EncryptedKey and EncryptedValue syntax and for 333 EnvelopedData syntax see CMS [RFC5652]. Using the EncryptedKey data 334 structure, the choice to either use EncryptedValue (for backward 335 compatibility only) or EnvelopedData is offered. The use of the 336 EncryptedValue structure has been deprecated in favor of the 337 EnvelopedData structure. Therefore, it is recommended to use 338 EnvelopedData. 340 Note: As we reuse the EncryptedKey structure defined in CRMF 341 [RFC4211], the update is backward compatible. Using the new syntax 342 with the untagged default choice EncryptedValue is bitwise compatible 343 with the old syntax. 345 The EncryptedKey data structure is used in CMP to either transport a 346 private key, certificate or revocation passphrase in encrypted form. 348 EnvelopedData is used as follows: 350 o Contains only one recepientInfo structure because the content is 351 encrypted only for one recipient. 353 o Contains a private key in the AsymmetricKeyPackage structure as 354 defined in RFC 5958 [RFC5958] wrapped in a SignedData structure as 355 specified in CMS section 5 [RFC5652] signed by the Key Generation 356 Authority. 358 o Contains a certificate or revocation passphrase directly in the 359 encryptedContent field. 361 Note: To ensure explicit control of the encoding of the private key 362 according to the specific algorithm the new key pair in an asymmetric 363 key package structure as specified in [RFC5958]. 365 The content of the EnvelopedData structure, as specified in CMS 366 section 6 [RFC5652], MUST be encrypted using a newly generated 367 symmetric content-encryption key. This content-encryption key MUST 368 be securely provided to the recipient using one of three key 369 management techniques. 371 The choice of the key management technique to be used by the sender 372 depends on the credential available for the recipient: 374 o Recipient's certificate that contains a key usage extension 375 asserting keyAgreement: The content-encryption key will be 376 protected using the key agreement key management technique, as 377 specified in CMS section 6.2.2 [RFC5652]. 379 o Recipient's certificate that contains a key usage extension 380 asserting keyEncipherment: The content-encryption key will be 381 protected using the key transport key management technique, as 382 specified in CMS section 6.2.1 [RFC5652]. 384 o Jointly shared secret: The content-encryption key will be 385 protected using the password-based key management technique, as 386 specified in CMS section 6.2.4 [RFC5652]. 388 2.5. Update Section 5.3.4. - Certification Response 390 Section 5.3.4 of RFC 4210 [RFC4210] describes the Certification 391 Response. This document updates the syntax by using the parent 392 structure EncryptedKey instead of EncryptedValue as described in 393 Section 2.1 above. 395 Replace the ASN.1 syntax of CertifiedKeyPair and CertOrEncCert with 396 the following text. 398 CertifiedKeyPair ::= SEQUENCE { 399 certOrEncCert CertOrEncCert, 400 privateKey [0] EncryptedKey OPTIONAL, 401 -- see [CRMF] for comment on encoding 402 publicationInfo [1] PKIPublicationInfo OPTIONAL 403 } 405 CertOrEncCert ::= CHOICE { 406 certificate [0] Certificate, 407 encryptedCert [1] EncryptedKey 408 } 410 Add the following paragraphs to the end of the section. 412 The use of EncryptedKey is described in section 5.2.2. 414 2.6. Replace Section 5.3.19.9. - Revocation Passphrase 416 Section 5.3.19.9 of RFC 4210 [RFC4210] describes the provisioning of 417 a revocation passphrase for authenticating a later revocation 418 request. This document updates the handling by using the parent 419 structure EncryptedKey instead of EncryptedValue to transport this 420 information as described in Section 2.1 above. 422 Replace the text of the section with the following text. 424 This MAY be used by the EE to send a passphrase to a CA/RA for the 425 purpose of authenticating a later revocation request (in the case 426 that the appropriate signing private key is no longer available to 427 authenticate the request). See Appendix B for further details on the 428 use of this mechanism. 430 GenMsg: {id-it 12}, EncryptedKey 431 GenRep: {id-it 12}, < absent > 433 The use of EncryptedKey is described in section 5.2.2. 435 2.7. Update Section 5.3.19. - PKI General Message Content 437 The following subsections describes IDs for new examples 438 InfoTypeAndValue to be used in general messages content specified in 439 RFC 4210 [RFC4210]. 441 Section 5.3.19 of RFC 4210 [RFC4210] describes various PKI general 442 messages and the respective OIDs. This document adds three 443 additional subsection to introduce the new IDs id-it-caCerts, id-it- 444 rootCaKeyUpdate, and id-it-certReqTemplate to the support messages as 445 defined in Lightweight CMP Profile 446 [I-D.ietf-lamps-lightweight-cmp-profile] Section 4.4. 448 Add these new subsections at the end of this section with the 449 following text. 451 2.3.19.14 CA Certificates 453 This MAY be used by the client to get the latest CA intermediate and 454 issuing CA certificates. 456 GenMsg: {id-it 17}, < absent > 457 GenRep: {id-it 17}, CaCertsValue | < absent > 459 5.3.19.15. Root CA Certificates Update 461 This MAY be used by the client to get an update of an existing root 462 CA Certificate. 464 GenMsg: {id-it 18}, < absent > 465 GenRep: {id-it 18}, RootCaKeyUpdateValue | < absent > 467 Note: In contrast to CAKeyUpdAnnContent, this type offers omitting 468 newWithOld and oldWithNew in the GenRep message, depending on the 469 needs of the EE. 471 5.3.19.16. Certificate Request Template 473 This MAY be used by the client to get a template with parameters for 474 a future certificate request operation. 476 GenMsg: {id-it 19}, < absent > 477 GenRep: {id-it 19}, CertReqTemplateValue | < absent > 479 2.8. Update Section 5.3.22 - Polling Request and Response 481 Section 5.3.22 of RFC 4210 [RFC4210] describes when and how polling 482 messages are used. This document adds the polling mechanism also to 483 outstanding p10cr transactions. 485 Replace all paragraphs in front of the state machine diagram with the 486 following text. 488 This pair of messages is intended to handle scenarios in which the 489 client needs to poll the server in order to determine the status of 490 an outstanding ir, cr, p10cr, or kur transaction (i.e., when the 491 "waiting" PKIStatus has been received). 493 PollReqContent ::= SEQUENCE OF SEQUENCE { 494 certReqId INTEGER } 496 PollRepContent ::= SEQUENCE OF SEQUENCE { 497 certReqId INTEGER, 498 checkAfter INTEGER, -- time in seconds 499 reason PKIFreeText OPTIONAL } 501 The following clauses describe when polling messages are used, and 502 how they are used. It is assumed that multiple certConf messages can 503 be sent during transactions. There will be one sent in response to 504 each ip, cp, or kup that contains a CertStatus for an issued 505 certificate. 507 1 In response to an ip, cp, or kup message, an EE will send a 508 certConf for all issued certificates and, following the ack, a 509 pollReq for all pending certificates. 511 2 In response to a pollReq, a CA/RA will return an ip, cp, or kup if 512 one or more of the pending certificates is ready; otherwise, it 513 will return a pollRep. 515 3 If the EE receives a pollRep, it will wait for at least as long as 516 the checkAfter value before sending another pollReq. 518 4 If an ip, cp, or kup is received in response to a pollReq, then it 519 will be treated in the same way as the initial response. 521 Note: A p10cr message contains exactly one CertificationRequestInfo 522 data structure as specified in PKCS#10 [RFC2986] but no certificate 523 request number. Therefore, the certReqId MUST be set to 0 in all 524 following messages of this transaction. 526 2.9. Update Section 9 - IANA Considerations 528 Section 9 of RFC 4210 [RFC4210] contains the IANA Considerations of 529 that document. As this document defines a new and updates two 530 existing Extended Key Usages, the IANA Considerations need to be 531 updated accordingly. 533 Add the following paragraphs between the first and second paragraph 534 of the section. 536 Within the SMI-numbers registry "SMI Security for PKIX Extended Key 537 Purpose Identifiers (1.3.6.1.5.5.7.3)" (see 538 https://www.iana.org/assignments/smi-numbers/smi-numbers.xhtml#smi- 539 numbers-1.3.6.1.5.5.7.3) as defined in RFC 7299 [RFC7299] three 540 changes have been performed. 542 Two existing entries have been updated to also point to this 543 document: 545 Decimal Description References 546 ------- ----------- ------------------ 547 27 id-kp-cmcCA [RFC6402][thisRFC] 548 28 id-kp-cmcRA [RFC6402][thisRFC] 550 One new entry has been added: 552 Decimal Description References 553 ------- ----------- ---------- 554 32 id-kp-cmKGA [thisRFC] 556 Within the SMI-numbers registry "SMI Security for PKIX CMP 557 Information Types (1.3.6.1.5.5.7.4)" (see 558 https://www.iana.org/assignments/smi-numbers/smi-numbers.xhtml#smi- 559 numbers-1.3.6.1.5.5.7.4) as defined in RFC 7299 [RFC7299] three 560 changes have been performed. 562 Three new entry have been added: 564 Decimal Description References 565 ------- --------------------- ---------- 566 17 id-it-caCerts [thisRFC] 567 18 id-it-rootCaKeyUpdate [thisRFC] 568 19 id-it-certReqTemplate [thisRFC] 570 2.10. Update Appendix B - The Use of Revocation Passphrase 572 Appendix B of RFC 4210 [RFC4210] describes the usage of the 573 revocation passphrase. As this document updates RFC 4210 [RFC4210] 574 to utilize the parent structure EncryptedKey instead of 575 EncryptedValue as described in Section 2.1 above, the description is 576 updated accordingly. 578 Replace the first bullet point of this section with the following 579 text. 581 o The OID and value specified in Section 5.3.19.9 of RFC 4210 582 [RFC4210] MAY be sent in a GenMsg message at any time, or MAY be 583 sent in the generalInfo field of the PKIHeader of any PKIMessage 584 at any time. (In particular, the EncryptedKey as described in 585 section 5.2.2 may be sent in the header of the certConf message 586 that confirms acceptance of certificates requested in an 587 initialization request or certificate request message.) This 588 conveys a revocation passphrase chosen by the entity (i.e., for 589 use of EnvelopedData this is in the decrypted bytes of 590 encryptedContent field and for use of EncryptedValue this is in 591 the decrypted bytes of the encValue field) to the relevant CA/RA; 592 furthermore, the transfer is accomplished with appropriate 593 confidentiality characteristics. 595 Replace the third bullet point of this section with the following 596 text. 598 o When using EnvelopedData the localKeyId attribute as specified in 599 RFC 2985 [RFC2985] and when using EncryptedValue the valueHint 600 field MAY contain a key identifier (chosen by the entity, along 601 with the passphrase itself) to assist in later retrieval of the 602 correct passphrase (e.g., when the revocation request is 603 constructed by the entity and received by the CA/RA). 605 2.11. Update Appendix C - Request Message Behavioral Clarifications 607 Appendix C of RFC 4210 [RFC4210] provides clarifications to the 608 request message behavior. As this document updates RFC 4210 609 [RFC4210] to utilize the parent structure EncryptedKey instead of 610 EncryptedValue as described in Section 2.1 above, the description is 611 updated accordingly. 613 Replace the note coming after the ASN.1 syntax of POPOPrivKey of this 614 section with the following text. 616 -- ********** 617 -- * the type of "thisMessage" is given as BIT STRING in RFC 4211 618 -- * [RFC4211]; it should be "EncryptedKey" (in accordance with 619 -- * Section 5.2.2 of this specification). Therefore, this document 620 -- * makes the behavioral clarification of specifying that the 621 -- * contents of "thisMessage" MUST be encoded either as 622 -- * "EnvelopedData" or "EncryptedValue" (only for backward 623 -- * compatibility) and then wrapped in a BIT STRING. This allows 624 -- * the necessary conveyance and protection of the private key 625 -- * while maintaining bits-on-the-wire compatibility with RFC 4211 626 -- * [RFC4211]. 627 -- ********** 629 2.12. Update Appendix D.4. - Initial Registration/Certification (Basic 630 Authenticated Scheme) 632 Appendix D.4 of RFC 4210 [RFC4210] provides the initial registration/ 633 certification scheme. This scheme shall continue to use 634 EncryptedValue for backward compatibility reasons. 636 Replace the comment after the privateKey field of 637 crc[1].certifiedKeyPair in the syntax of the Initialization Response 638 message with the following text. 640 -- see Appendix C, Request Message Behavioral Clarifications 641 -- for backward compatibility reasons, use EncryptedValue 643 3. Updates to RFC 6712 - HTTP Transfer for the Certificate Management 644 Protocol (CMP) 646 3.1. New Section 1.1. - Changes since RFC 6712 648 The following subsection describes feature updates to RFC 6712 649 [RFC6712]. They are always related to the base specification. Hence 650 references to the original sections in RFC 6712 [RFC6712] are used 651 whenever possible. 653 Insert this section at the end of the current Section 1. 655 1.1 Changes since RFC 6712 657 The following updates are made in draft-ietf-lamps-cmp-updates: 659 o Add an HTTP URI discovery mechanism and extend the URI structure. 661 3.2. New Section 3.6. - HTTP Request-URI 663 Section 3.6 of RFC 6712 [RFC6712] specifies the used HTTP URIs. This 664 document adds a discovery mechanism and extends the URIs. 666 Replace the text of the section with the following text. 668 Each CMP server on a PKI management entity supporting HTTP or HTTPS 669 transport MUST support the use of the path-prefix of '/.well-known/' 670 as defined in RFC 8515 [RFC8515] and the registered name of 'cmp' to 671 ease interworking in a multi-vendor environment. 673 The CMP client needs to be configured with sufficient information to 674 form the CMP server URI. This is at least the authority portion of 675 the URI, e.g., 'www.example.com:80', or the full operational path of 676 the PKI management entity. Additional arbitrary label, e.g., 677 'profileLabel' and 'operationLabel', may be configured as a separate 678 component or as part of the full operational path to provide further 679 information. The 'profileLabel' may support addressing multiple CAs 680 or certificate profiles and the 'operationLabel' may support 681 addressing PKI management operation specific endpoints. A valid full 682 operational path can look like this: 684 1 http://www.example.com/.well-known/cmp 686 2 http://www.example.com/.well-known/cmp/operationLabel 688 3 http://www.example.com/.well-known/cmp/profileLabel 690 4 http://www.example.com/.well-known/cmp/profileLabel/operationLabel 692 The discovery of supported endpoints as defined above will provide 693 the information to the CMP client how to contact the PKI management 694 entity and, if available, how to request enrolment for a specific 695 certificate profile or revoke a certificate at a specific CA. 697 Querying the PKI management entity, the CMP client will get a list of 698 potential endpoints supported by the PKI management entity. 700 Performing a GET on "/.well-known/cmp" to the default port MUST 701 return a set of links to endpoints available from the CMP server. In 702 addition to the link also the expected format of the data object is 703 provided as content type (ct). 705 < TBD: It needs to be discussed if the discovery should be performed 706 using GET on "/.well-known/cmp" or GET on "/.well-known" only. > 707 The following provides an illustrative example for a PKI management 708 entity supporting various PKI management operations for various 709 certificate profiles and CAs. 711 Detailed message description: 713 REQ: GET /.well-known/cmp 715 RES: Content 716 ;ct=pkixcmp 717 ;ct=pkixcmp 718 ;ct=pkixcmp 719 ;ct=pkixcmp 720 ;ct=pkixcmp 721 ;ct=pkixcmp 722 ;ct=pkixcmp 723 ;ct=pkixcmp 725 3.3. Update Section 6. - IANA Considerations 727 Section 6 of RFC 6712 [RFC6712] contains the IANA Considerations of 728 that document. As this document defines a new well-known URI, the 729 IANA Considerations need to be updated accordingly. 731 Add the following text between the first and second paragraph of the 732 section. 734 Within the well-known URI registry (see 735 https://www.iana.org/assignments/well-known-uris/well-known- 736 uris.xhtml#well-known-uris-1) as defined in RFC 8515 [RFC8515] the 737 following change has been performed. 739 One new name entry has been added: 741 URI suffix Change controller 742 ----------- ----------------- 743 cmp IETF 745 4. IANA Considerations 747 This document contains an update to the IANA Consideration sections 748 to be added to [RFC4210] and [RFC6712]. 750 < TBD: The existing description and information of id-kp-cmcRA and 751 id-kp-cmcCA need to be updated to reflect their extended usage. > 753 5. Security Considerations 755 No changes are made to the existing security considerations of 756 RFC 4210 [RFC4210] and RFC 6712 [RFC6712]. 758 6. Acknowledgements 760 Special thank goes to Jim Schaad for his guidance and the inspiration 761 on structuring and writing this document I got from [RFC6402] that 762 updates CMC. Special thank also goes also to Russ Housley and Tomas 763 Gustavsson for reviewing and providing valuable suggestions on the 764 approvement of this document. 766 I also like to thank all reviewers of this document for their 767 valuable feedback. 769 7. References 771 7.1. Normative References 773 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 774 Requirement Levels", BCP 14, RFC 2119, 775 DOI 10.17487/RFC2119, March 1997, 776 . 778 [RFC2985] Nystrom, M. and B. Kaliski, "PKCS #9: Selected Object 779 Classes and Attribute Types Version 2.0", RFC 2985, 780 DOI 10.17487/RFC2985, November 2000, 781 . 783 [RFC2986] Nystrom, M. and B. Kaliski, "PKCS #10: Certification 784 Request Syntax Specification Version 1.7", RFC 2986, 785 DOI 10.17487/RFC2986, November 2000, 786 . 788 [RFC4210] Adams, C., Farrell, S., Kause, T., and T. Mononen, 789 "Internet X.509 Public Key Infrastructure Certificate 790 Management Protocol (CMP)", RFC 4210, 791 DOI 10.17487/RFC4210, September 2005, 792 . 794 [RFC4211] Schaad, J., "Internet X.509 Public Key Infrastructure 795 Certificate Request Message Format (CRMF)", RFC 4211, 796 DOI 10.17487/RFC4211, September 2005, 797 . 799 [RFC5280] Cooper, D., Santesson, S., Farrell, S., Boeyen, S., 800 Housley, R., and W. Polk, "Internet X.509 Public Key 801 Infrastructure Certificate and Certificate Revocation List 802 (CRL) Profile", RFC 5280, DOI 10.17487/RFC5280, May 2008, 803 . 805 [RFC5652] Housley, R., "Cryptographic Message Syntax (CMS)", STD 70, 806 RFC 5652, DOI 10.17487/RFC5652, September 2009, 807 . 809 [RFC5912] Hoffman, P. and J. Schaad, "New ASN.1 Modules for the 810 Public Key Infrastructure Using X.509 (PKIX)", RFC 5912, 811 DOI 10.17487/RFC5912, June 2010, 812 . 814 [RFC5958] Turner, S., "Asymmetric Key Packages", RFC 5958, 815 DOI 10.17487/RFC5958, August 2010, 816 . 818 [RFC6402] Schaad, J., "Certificate Management over CMS (CMC) 819 Updates", RFC 6402, DOI 10.17487/RFC6402, November 2011, 820 . 822 [RFC6712] Kause, T. and M. Peylo, "Internet X.509 Public Key 823 Infrastructure -- HTTP Transfer for the Certificate 824 Management Protocol (CMP)", RFC 6712, 825 DOI 10.17487/RFC6712, September 2012, 826 . 828 [RFC7299] Housley, R., "Object Identifier Registry for the PKIX 829 Working Group", RFC 7299, DOI 10.17487/RFC7299, July 2014, 830 . 832 [RFC8515] Jethanandani, M. and M. Reina Ortega, "URN Namespace for 833 ETSI Documents", RFC 8515, DOI 10.17487/RFC8515, February 834 2019, . 836 7.2. Informative References 838 [I-D.ietf-lamps-lightweight-cmp-profile] 839 Brockhaus, H., Fries, S., and D. Oheimb, "Lightweight CMP 840 Profile", draft-ietf-lamps-lightweight-cmp-profile-02 841 (work in progress), July 2020. 843 [IEEE802.1AR] 844 IEEE, "802.1AR Secure Device Identifier", June 2018, 845 . 848 Appendix A. ASN.1 Modules 850 A.1. 1988 ASN.1 Module 852 This section contains the updated ASN.1 module for [RFC4210]. This 853 module replaces the module in Appendix F of that document. Although 854 a 2002 ASN.1 module is provided, this remains the normative module as 855 per the policy of the PKIX working group. 857 PKIXCMP {iso(1) identified-organization(3) 858 dod(6) internet(1) security(5) mechanisms(5) pkix(7) 859 id-mod(0) id-mod-cmp2000(16)} 861 DEFINITIONS EXPLICIT TAGS ::= 863 BEGIN 865 -- EXPORTS ALL -- 867 IMPORTS 869 Certificate, CertificateList, Extensions, AlgorithmIdentifier, 870 UTF8String, id-kp -- if required; otherwise, comment out 871 FROM PKIX1Explicit88 {iso(1) identified-organization(3) 872 dod(6) internet(1) security(5) mechanisms(5) pkix(7) 873 id-mod(0) id-pkix1-explicit-88(1)} 875 GeneralName, KeyIdentifier 876 FROM PKIX1Implicit88 {iso(1) identified-organization(3) 877 dod(6) internet(1) security(5) mechanisms(5) pkix(7) 878 id-mod(0) id-pkix1-implicit-88(2)} 880 CertTemplate, PKIPublicationInfo, EncryptedKey, EncryptedValue, 881 CertId, CertReqMessages 882 FROM PKIXCRMF-2005 {iso(1) identified-organization(3) 883 dod(6) internet(1) security(5) mechanisms(5) pkix(7) 884 id-mod(0) id-mod-crmf2005(36)} 885 -- The import of EncryptedKey is added due to the updates made 886 -- in CMP Updates [thisRFC] 888 -- see also the behavioral clarifications to CRMF codified in 889 -- Appendix C of this specification 890 CertificationRequest 891 FROM PKCS-10 {iso(1) member-body(2) 892 us(840) rsadsi(113549) 893 pkcs(1) pkcs-10(10) modules(1) pkcs-10(1)} 894 -- (specified in RFC 2986 with 1993 ASN.1 syntax and IMPLICIT 895 -- tags). Alternatively, implementers may directly include 896 -- the [PKCS10] syntax in this module 898 localKeyId 899 FROM PKCS-9 {iso(1) member-body(2) us(840) rsadsi(113549) 900 pkcs(1) pkcs-9(9) modules(0) pkcs-9(1)} 901 -- The import of localKeyId is added due to the updates made in 902 -- CMP Updates [thisRFC] 904 EnvelopedData, SignedData 905 FROM CryptographicMessageSyntax2004 { iso(1) 906 member-body(2) us(840) rsadsi(113549) pkcs(1) pkcs-9(9) 907 smime(16) modules(0) cms-2004(24) } 908 -- The import of EnvelopedData and SignedData is added due to 909 -- the updates made in CMP Updates [thisRFC] 911 ; 913 -- the rest of the module contains locally-defined OIDs and 914 -- constructs 916 CMPCertificate ::= CHOICE { 917 x509v3PKCert Certificate 918 } 919 -- This syntax, while bits-on-the-wire compatible with the 920 -- standard X.509 definition of "Certificate", allows the 921 -- possibility of future certificate types (such as X.509 922 -- attribute certificates, WAP WTLS certificates, or other kinds 923 -- of certificates) within this certificate management protocol, 924 -- should a need ever arise to support such generality. Those 925 -- implementations that do not foresee a need to ever support 926 -- other certificate types MAY, if they wish, comment out the 927 -- above structure and "un-comment" the following one prior to 928 -- compiling this ASN.1 module. (Note that interoperability 929 -- with implementations that don't do this will be unaffected by 930 -- this change.) 932 -- CMPCertificate ::= Certificate 934 PKIMessage ::= SEQUENCE { 935 header PKIHeader, 936 body PKIBody, 937 protection [0] PKIProtection OPTIONAL, 938 extraCerts [1] SEQUENCE SIZE (1..MAX) OF CMPCertificate 939 OPTIONAL 940 } 942 PKIMessages ::= SEQUENCE SIZE (1..MAX) OF PKIMessage 943 PKIHeader ::= SEQUENCE { 944 pvno INTEGER { cmp1999(1), cmp2000(2) }, 945 sender GeneralName, 946 -- identifies the sender 947 recipient GeneralName, 948 -- identifies the intended recipient 949 messageTime [0] GeneralizedTime OPTIONAL, 950 -- time of production of this message (used when sender 951 -- believes that the transport will be "suitable"; i.e., 952 -- that the time will still be meaningful upon receipt) 953 protectionAlg [1] AlgorithmIdentifier OPTIONAL, 954 -- algorithm used for calculation of protection bits 955 senderKID [2] KeyIdentifier OPTIONAL, 956 recipKID [3] KeyIdentifier OPTIONAL, 957 -- to identify specific keys used for protection 958 transactionID [4] OCTET STRING OPTIONAL, 959 -- identifies the transaction; i.e., this will be the same in 960 -- corresponding request, response, certConf, and PKIConf 961 -- messages 962 senderNonce [5] OCTET STRING OPTIONAL, 963 recipNonce [6] OCTET STRING OPTIONAL, 964 -- nonces used to provide replay protection, senderNonce 965 -- is inserted by the creator of this message; recipNonce 966 -- is a nonce previously inserted in a related message by 967 -- the intended recipient of this message 968 freeText [7] PKIFreeText OPTIONAL, 969 -- this may be used to indicate context-specific instructions 970 -- (this field is intended for human consumption) 971 generalInfo [8] SEQUENCE SIZE (1..MAX) OF 972 InfoTypeAndValue OPTIONAL 973 -- this may be used to convey context-specific information 974 -- (this field not primarily intended for human consumption) 975 } 977 PKIFreeText ::= SEQUENCE SIZE (1..MAX) OF UTF8String 978 -- text encoded as UTF-8 String [RFC3629] (note: each 979 -- UTF8String MAY include an [RFC3066] language tag 980 -- to indicate the language of the contained text 981 -- see [RFC2482] for details) 983 PKIBody ::= CHOICE { -- message-specific body elements 984 ir [0] CertReqMessages, --Initialization Request 985 ip [1] CertRepMessage, --Initialization Response 986 cr [2] CertReqMessages, --Certification Request 987 cp [3] CertRepMessage, --Certification Response 988 p10cr [4] CertificationRequest, --imported from [PKCS10] 989 popdecc [5] POPODecKeyChallContent, --pop Challenge 990 popdecr [6] POPODecKeyRespContent, --pop Response 991 kur [7] CertReqMessages, --Key Update Request 992 kup [8] CertRepMessage, --Key Update Response 993 krr [9] CertReqMessages, --Key Recovery Request 994 krp [10] KeyRecRepContent, --Key Recovery Response 995 rr [11] RevReqContent, --Revocation Request 996 rp [12] RevRepContent, --Revocation Response 997 ccr [13] CertReqMessages, --Cross-Cert. Request 998 ccp [14] CertRepMessage, --Cross-Cert. Response 999 ckuann [15] CAKeyUpdAnnContent, --CA Key Update Ann. 1000 cann [16] CertAnnContent, --Certificate Ann. 1001 rann [17] RevAnnContent, --Revocation Ann. 1002 crlann [18] CRLAnnContent, --CRL Announcement 1003 pkiconf [19] PKIConfirmContent, --Confirmation 1004 nested [20] NestedMessageContent, --Nested Message 1005 genm [21] GenMsgContent, --General Message 1006 genp [22] GenRepContent, --General Response 1007 error [23] ErrorMsgContent, --Error Message 1008 certConf [24] CertConfirmContent, --Certificate confirm 1009 pollReq [25] PollReqContent, --Polling request 1010 pollRep [26] PollRepContent --Polling response 1011 } 1013 PKIProtection ::= BIT STRING 1015 ProtectedPart ::= SEQUENCE { 1016 header PKIHeader, 1017 body PKIBody 1018 } 1020 id-PasswordBasedMac OBJECT IDENTIFIER ::= {1 2 840 113533 7 66 13} 1021 PBMParameter ::= SEQUENCE { 1022 salt OCTET STRING, 1023 -- note: implementations MAY wish to limit acceptable sizes 1024 -- of this string to values appropriate for their environment 1025 -- in order to reduce the risk of denial-of-service attacks 1026 owf AlgorithmIdentifier, 1027 -- AlgId for a One-Way Function (SHA-1 recommended) 1028 iterationCount INTEGER, 1029 -- number of times the OWF is applied 1030 -- note: implementations MAY wish to limit acceptable sizes 1031 -- of this integer to values appropriate for their environment 1032 -- in order to reduce the risk of denial-of-service attacks 1033 mac AlgorithmIdentifier 1034 -- the MAC AlgId (e.g., DES-MAC, Triple-DES-MAC [PKCS11], 1035 } -- or HMAC [RFC2104, RFC2202]) 1037 id-DHBasedMac OBJECT IDENTIFIER ::= {1 2 840 113533 7 66 30} 1038 DHBMParameter ::= SEQUENCE { 1039 owf AlgorithmIdentifier, 1040 -- AlgId for a One-Way Function (SHA-1 recommended) 1041 mac AlgorithmIdentifier 1042 -- the MAC AlgId (e.g., DES-MAC, Triple-DES-MAC [PKCS11], 1043 } -- or HMAC [RFC2104, RFC2202]) 1045 NestedMessageContent ::= PKIMessages 1047 PKIStatus ::= INTEGER { 1048 accepted (0), 1049 -- you got exactly what you asked for 1050 grantedWithMods (1), 1051 -- you got something like what you asked for; the 1052 -- requester is responsible for ascertaining the differences 1053 rejection (2), 1054 -- you don't get it, more information elsewhere in the message 1055 waiting (3), 1056 -- the request body part has not yet been processed; expect to 1057 -- hear more later (note: proper handling of this status 1058 -- response MAY use the polling req/rep PKIMessages specified 1059 -- in Section 5.3.22; alternatively, polling in the underlying 1060 -- transport layer MAY have some utility in this regard) 1061 revocationWarning (4), 1062 -- this message contains a warning that a revocation is 1063 -- imminent 1064 revocationNotification (5), 1065 -- notification that a revocation has occurred 1066 keyUpdateWarning (6) 1067 -- update already done for the oldCertId specified in 1068 -- CertReqMsg 1069 } 1071 PKIFailureInfo ::= BIT STRING { 1072 -- since we can fail in more than one way! 1073 -- More codes may be added in the future if/when required. 1074 badAlg (0), 1075 -- unrecognized or unsupported Algorithm Identifier 1076 badMessageCheck (1), 1077 -- integrity check failed (e.g., signature did not verify) 1078 badRequest (2), 1079 -- transaction not permitted or supported 1080 badTime (3), 1081 -- messageTime was not sufficiently close to the system time, 1082 -- as defined by local policy 1083 badCertId (4), 1084 -- no certificate could be found matching the provided criteria 1085 badDataFormat (5), 1086 -- the data submitted has the wrong format 1087 wrongAuthority (6), 1088 -- the authority indicated in the request is different from the 1089 -- one creating the response token 1090 incorrectData (7), 1091 -- the requester's data is incorrect (for notary services) 1092 missingTimeStamp (8), 1093 -- when the timestamp is missing but should be there 1094 -- (by policy) 1095 badPOP (9), 1096 -- the proof-of-possession failed 1097 certRevoked (10), 1098 -- the certificate has already been revoked 1099 certConfirmed (11), 1100 -- the certificate has already been confirmed 1101 wrongIntegrity (12), 1102 -- invalid integrity, password based instead of signature or 1103 -- vice versa 1104 badRecipientNonce (13), 1105 -- invalid recipient nonce, either missing or wrong value 1106 timeNotAvailable (14), 1107 -- the TSA's time source is not available 1108 unacceptedPolicy (15), 1109 -- the requested TSA policy is not supported by the TSA. 1110 unacceptedExtension (16), 1111 -- the requested extension is not supported by the TSA. 1112 addInfoNotAvailable (17), 1113 -- the additional information requested could not be 1114 -- understood or is not available 1115 badSenderNonce (18), 1116 -- invalid sender nonce, either missing or wrong size 1117 badCertTemplate (19), 1118 -- invalid cert. template or missing mandatory information 1119 signerNotTrusted (20), 1120 -- signer of the message unknown or not trusted 1121 transactionIdInUse (21), 1122 -- the transaction identifier is already in use 1123 unsupportedVersion (22), 1124 -- the version of the message is not supported 1125 notAuthorized (23), 1126 -- the sender was not authorized to make the preceding 1127 -- request or perform the preceding action 1128 systemUnavail (24), 1129 -- the request cannot be handled due to system unavailability 1130 systemFailure (25), 1131 -- the request cannot be handled due to system failure 1132 duplicateCertReq (26) 1133 -- certificate cannot be issued because a duplicate 1134 -- certificate already exists 1135 } 1137 PKIStatusInfo ::= SEQUENCE { 1138 status PKIStatus, 1139 statusString PKIFreeText OPTIONAL, 1140 failInfo PKIFailureInfo OPTIONAL 1141 } 1143 OOBCert ::= CMPCertificate 1145 OOBCertHash ::= SEQUENCE { 1146 hashAlg [0] AlgorithmIdentifier OPTIONAL, 1147 certId [1] CertId OPTIONAL, 1148 hashVal BIT STRING 1149 -- hashVal is calculated over the DER encoding of the 1150 -- self-signed certificate with the identifier certID. 1151 } 1153 POPODecKeyChallContent ::= SEQUENCE OF Challenge 1154 -- One Challenge per encryption key certification request (in the 1155 -- same order as these requests appear in CertReqMessages). 1157 Challenge ::= SEQUENCE { 1158 owf AlgorithmIdentifier OPTIONAL, 1159 -- MUST be present in the first Challenge; MAY be omitted in 1160 -- any subsequent Challenge in POPODecKeyChallContent (if 1161 -- omitted, then the owf used in the immediately preceding 1162 -- Challenge is to be used). 1163 witness OCTET STRING, 1164 -- the result of applying the one-way function (owf) to a 1165 -- randomly-generated INTEGER, A. [Note that a different 1166 -- INTEGER MUST be used for each Challenge.] 1167 challenge OCTET STRING 1168 -- the encryption (under the public key for which the cert. 1169 -- request is being made) of Rand, where Rand is specified as 1170 -- Rand ::= SEQUENCE { 1171 -- int INTEGER, 1172 -- - the randomly-generated INTEGER A (above) 1173 -- sender GeneralName 1174 -- - the sender's name (as included in PKIHeader) 1175 -- } 1176 } 1178 POPODecKeyRespContent ::= SEQUENCE OF INTEGER 1179 -- One INTEGER per encryption key certification request (in the 1180 -- same order as these requests appear in CertReqMessages). The 1181 -- retrieved INTEGER A (above) is returned to the sender of the 1182 -- corresponding Challenge. 1184 CertRepMessage ::= SEQUENCE { 1185 caPubs [1] SEQUENCE SIZE (1..MAX) OF CMPCertificate 1186 OPTIONAL, 1187 response SEQUENCE OF CertResponse 1188 } 1190 CertResponse ::= SEQUENCE { 1191 certReqId INTEGER, 1192 -- to match this response with corresponding request (a value 1193 -- of -1 is to be used if certReqId is not specified in the 1194 -- corresponding request) 1195 status PKIStatusInfo, 1196 certifiedKeyPair CertifiedKeyPair OPTIONAL, 1197 rspInfo OCTET STRING OPTIONAL 1198 -- analogous to the id-regInfo-utf8Pairs string defined 1199 -- for regInfo in CertReqMsg [CRMF] 1200 } 1202 CertifiedKeyPair ::= SEQUENCE { 1203 certOrEncCert CertOrEncCert, 1204 privateKey [0] EncryptedKey OPTIONAL, 1205 -- see [CRMF] for comment on encoding 1206 -- Changed from Encrypted Value to EncryptedKey as a CHOICE of 1207 -- EncryptedValue and EnvelopedData due to the changes made in 1208 -- CMP Updates [thisRFC] 1209 -- Using the choice EncryptedValue is bit-compatible to the 1210 -- syntax without this change 1211 publicationInfo [1] PKIPublicationInfo OPTIONAL 1212 } 1214 CertOrEncCert ::= CHOICE { 1215 certificate [0] CMPCertificate, 1216 encryptedCert [1] EncryptedKey 1217 -- Changed from Encrypted Value to EncryptedKey as a CHOICE of 1218 -- EncryptedValue and EnvelopedData due to the changes made in 1219 -- CMP Updates [thisRFC] 1220 -- Using the choice EncryptedValue is bit-compatible to the 1221 -- syntax without this change 1222 } 1224 KeyRecRepContent ::= SEQUENCE { 1225 status PKIStatusInfo, 1226 newSigCert [0] CMPCertificate OPTIONAL, 1227 caCerts [1] SEQUENCE SIZE (1..MAX) OF 1228 CMPCertificate OPTIONAL, 1229 keyPairHist [2] SEQUENCE SIZE (1..MAX) OF 1230 CertifiedKeyPair OPTIONAL 1231 } 1233 RevReqContent ::= SEQUENCE OF RevDetails 1235 RevDetails ::= SEQUENCE { 1236 certDetails CertTemplate, 1237 -- allows requester to specify as much as they can about 1238 -- the cert. for which revocation is requested 1239 -- (e.g., for cases in which serialNumber is not available) 1240 crlEntryDetails Extensions OPTIONAL 1241 -- requested crlEntryExtensions 1242 } 1244 RevRepContent ::= SEQUENCE { 1245 status SEQUENCE SIZE (1..MAX) OF PKIStatusInfo, 1246 -- in same order as was sent in RevReqContent 1247 revCerts [0] SEQUENCE SIZE (1..MAX) OF CertId 1248 OPTIONAL, 1249 -- IDs for which revocation was requested 1250 -- (same order as status) 1251 crls [1] SEQUENCE SIZE (1..MAX) OF CertificateList 1252 OPTIONAL 1253 -- the resulting CRLs (there may be more than one) 1254 } 1256 CAKeyUpdAnnContent ::= SEQUENCE { 1257 oldWithNew CMPCertificate, -- old pub signed with new priv 1258 newWithOld CMPCertificate, -- new pub signed with old priv 1259 newWithNew CMPCertificate -- new pub signed with new priv 1260 } 1262 CertAnnContent ::= CMPCertificate 1264 RevAnnContent ::= SEQUENCE { 1265 status PKIStatus, 1266 certId CertId, 1267 willBeRevokedAt GeneralizedTime, 1268 badSinceDate GeneralizedTime, 1269 crlDetails Extensions OPTIONAL 1270 -- extra CRL details (e.g., crl number, reason, location, etc.) 1271 } 1273 CRLAnnContent ::= SEQUENCE OF CertificateList 1275 CertConfirmContent ::= SEQUENCE OF CertStatus 1277 CertStatus ::= SEQUENCE { 1278 certHash OCTET STRING, 1279 -- the hash of the certificate, using the same hash algorithm 1280 -- as is used to create and verify the certificate signature 1281 certReqId INTEGER, 1282 -- to match this confirmation with the corresponding req/rep 1283 statusInfo PKIStatusInfo OPTIONAL 1284 } 1286 PKIConfirmContent ::= NULL 1288 -- Added in CMP Updates [thisRFC] 1290 RootCaKeyUpdateContent ::= SEQUENCE { 1291 newWithNew CMPCertificate 1292 -- new root CA certificate 1293 newWithOld [0] CMPCertificate OPTIONAL, 1294 -- X.509 certificate containing the new public root CA key 1295 -- signed with the old private root CA key 1296 oldWithNew [1] CMPCertificate OPTIONAL 1297 -- old root CA key certificate 1298 } 1300 -- Added in CMP Updates [thisRFC] 1302 CertReqTemplateContent ::= SEQUENCE { 1303 certTemplate CertTemplate, 1304 -- prefilled certTemplate structure elements 1305 rsaKeyLen INTEGER OPTIONAL 1306 -- Any reasonable RSA key length, if subjectPublicKeyInfo 1307 -- of the certTemplate has the OID rsaEncryption. 1308 } 1310 InfoTypeAndValue ::= SEQUENCE { 1311 infoType OBJECT IDENTIFIER, 1312 infoValue ANY DEFINED BY infoType OPTIONAL 1313 } 1314 -- Example InfoTypeAndValue contents include, but are not limited 1315 -- to, the following (un-comment in this ASN.1 module and use as 1316 -- appropriate for a given environment): 1317 -- 1318 -- id-it-caProtEncCert OBJECT IDENTIFIER ::= {id-it 1} 1319 -- CAProtEncCertValue ::= CMPCertificate 1320 -- id-it-signKeyPairTypes OBJECT IDENTIFIER ::= {id-it 2} 1321 -- SignKeyPairTypesValue ::= SEQUENCE OF AlgorithmIdentifier 1322 -- id-it-encKeyPairTypes OBJECT IDENTIFIER ::= {id-it 3} 1323 -- EncKeyPairTypesValue ::= SEQUENCE OF AlgorithmIdentifier 1324 -- id-it-preferredSymmAlg OBJECT IDENTIFIER ::= {id-it 4} 1325 -- PreferredSymmAlgValue ::= AlgorithmIdentifier 1326 -- id-it-caKeyUpdateInfo OBJECT IDENTIFIER ::= {id-it 5} 1327 -- CAKeyUpdateInfoValue ::= CAKeyUpdAnnContent 1328 -- id-it-currentCRL OBJECT IDENTIFIER ::= {id-it 6} 1329 -- CurrentCRLValue ::= CertificateList 1330 -- id-it-unsupportedOIDs OBJECT IDENTIFIER ::= {id-it 7} 1331 -- UnsupportedOIDsValue ::= SEQUENCE OF OBJECT IDENTIFIER 1332 -- id-it-keyPairParamReq OBJECT IDENTIFIER ::= {id-it 10} 1333 -- KeyPairParamReqValue ::= OBJECT IDENTIFIER 1334 -- id-it-keyPairParamRep OBJECT IDENTIFIER ::= {id-it 11} 1335 -- KeyPairParamRepValue ::= AlgorithmIdentifer 1336 -- id-it-revPassphrase OBJECT IDENTIFIER ::= {id-it 12} 1337 -- RevPassphraseValue ::= EncryptedKey 1338 -- -- Changed from Encrypted Value to EncryptedKey as a CHOICE 1339 -- -- of EncryptedValue and EnvelopedData due to the changes 1340 -- -- made in CMP Updates [thisRFC] 1341 -- -- Using the choice EncryptedValue is bit-compatible to the 1342 -- -- syntax without this change 1343 -- id-it-implicitConfirm OBJECT IDENTIFIER ::= {id-it 13} 1344 -- ImplicitConfirmValue ::= NULL 1345 -- id-it-confirmWaitTime OBJECT IDENTIFIER ::= {id-it 14} 1346 -- ConfirmWaitTimeValue ::= GeneralizedTime 1347 -- id-it-origPKIMessage OBJECT IDENTIFIER ::= {id-it 15} 1348 -- OrigPKIMessageValue ::= PKIMessages 1349 -- id-it-suppLangTags OBJECT IDENTIFIER ::= {id-it 16} 1350 -- SuppLangTagsValue ::= SEQUENCE OF UTF8String 1351 -- id-it-caCerts OBJECT IDENTIFIER ::= { id-it 17} 1352 -- CaCertsValue ::= SEQUENCE OF CMPCertificate 1353 -- -- id-it-caCerts added in CMP Updates [thisRFC] 1354 -- id-it-rootCaKeyUpdate OBJECT IDENTIFIER ::= { id-it 18} 1355 -- RootCaKeyUpdateValue ::= RootCaKeyUpdateContent 1356 -- -- id-it-rootCaKeyUpdate added in CMP Updates [thisRFC] 1357 -- id-it-certReqTemplate OBJECT IDENTIFIER ::= { id-it 19} 1358 -- CertReqTemplateValue ::= CertReqTemplateContent 1359 -- -- id-it-certReqTemplate added in CMP Updates [thisRFC] 1360 -- 1361 -- where 1362 -- 1363 -- id-pkix OBJECT IDENTIFIER ::= { 1364 -- iso(1) identified-organization(3) 1365 -- dod(6) internet(1) security(5) mechanisms(5) pkix(7)} 1366 -- and 1367 -- id-it OBJECT IDENTIFIER ::= {id-pkix 4} 1368 -- 1369 -- 1370 -- This construct MAY also be used to define new PKIX Certificate 1371 -- Management Protocol request and response messages, or general- 1372 -- purpose (e.g., announcement) messages for future needs or for 1373 -- specific environments. 1375 GenMsgContent ::= SEQUENCE OF InfoTypeAndValue 1377 -- May be sent by EE, RA, or CA (depending on message content). 1378 -- The OPTIONAL infoValue parameter of InfoTypeAndValue will 1379 -- typically be omitted for some of the examples given above. 1380 -- The receiver is free to ignore any contained OBJ. IDs that it 1381 -- does not recognize. If sent from EE to CA, the empty set 1382 -- indicates that the CA may send 1383 -- any/all information that it wishes. 1385 GenRepContent ::= SEQUENCE OF InfoTypeAndValue 1386 -- Receiver MAY ignore any contained OIDs that it does not 1387 -- recognize. 1389 ErrorMsgContent ::= SEQUENCE { 1390 pKIStatusInfo PKIStatusInfo, 1391 errorCode INTEGER OPTIONAL, 1392 -- implementation-specific error codes 1393 errorDetails PKIFreeText OPTIONAL 1394 -- implementation-specific error details 1395 } 1397 PollReqContent ::= SEQUENCE OF SEQUENCE { 1398 certReqId INTEGER 1399 } 1401 PollRepContent ::= SEQUENCE OF SEQUENCE { 1402 certReqId INTEGER, 1403 checkAfter INTEGER, -- time in seconds 1404 reason PKIFreeText OPTIONAL 1405 } 1407 -- 1408 -- Extended Key Usage extension for PKI entities used in CMP 1409 -- operations, added due to the changes made in 1410 -- CMP Updates [thisRFC] 1411 -- The EKUs for the CA and RA are reused from CMC as defined in 1412 -- [RFC6402] 1413 -- 1415 -- id-kp-cmcCA OBJECT IDENTIFIER ::= { id-kp 27 } 1416 -- id-kp-cmcRA OBJECT IDENTIFIER ::= { id-kp 28 } 1417 id-kp-cmKGA OBJECT IDENTIFIER ::= { id-kp 32 } 1419 END -- of CMP module 1421 A.2. 2002 ASN.1 Module 1423 This section contains the updated 2002 ASN.1 module for [RFC5912]. 1424 This module replaces the module in Section 9 of that document. The 1425 module contains those changes that were done to update to 2002 ASN.1 1426 standard done in [RFC5912] as well as changes made for this document. 1428 < TBD: Dose this document then also updates [RFC5912]? > 1430 < In case the working group sees a need to provide this ASN.1 module 1431 in 2015 syntax, please let me know. > 1433 PKIXCMP-2009 1434 { iso(1) identified-organization(3) dod(6) internet(1) 1435 security(5) mechanisms(5) pkix(7) id-mod(0) 1436 id-mod-cmp2000-02(50) } DEFINITIONS EXPLICIT TAGS ::= 1437 BEGIN 1438 IMPORTS 1440 AttributeSet{}, Extensions{}, EXTENSION, ATTRIBUTE 1441 FROM PKIX-CommonTypes-2009 1442 {iso(1) identified-organization(3) dod(6) internet(1) security(5) 1443 mechanisms(5) pkix(7) id-mod(0) id-mod-pkixCommon-02(57)} 1445 AlgorithmIdentifier{}, SIGNATURE-ALGORITHM, ALGORITHM, 1446 DIGEST-ALGORITHM, MAC-ALGORITHM 1447 FROM AlgorithmInformation-2009 1448 {iso(1) identified-organization(3) dod(6) internet(1) security(5) 1449 mechanisms(5) pkix(7) id-mod(0) 1450 id-mod-algorithmInformation-02(58)} 1452 Certificate, CertificateList, id-kp 1453 FROM PKIX1Explicit-2009 1454 {iso(1) identified-organization(3) dod(6) internet(1) security(5) 1455 mechanisms(5) pkix(7) id-mod(0) id-mod-pkix1-explicit-02(51)} 1457 GeneralName, KeyIdentifier 1458 FROM PKIX1Implicit-2009 1459 {iso(1) identified-organization(3) dod(6) internet(1) security(5) 1460 mechanisms(5) pkix(7) id-mod(0) id-mod-pkix1-implicit-02(59)} 1462 CertTemplate, PKIPublicationInfo, EncryptedKey, EncryptedValue, 1463 CertId,CertReqMessages 1464 FROM PKIXCRMF-2009 1465 { iso(1) identified-organization(3) dod(6) internet(1) 1466 security(5) mechanisms(5) pkix(7) id-mod(0) 1467 id-mod-crmf2005-02(55) } 1468 -- see also the behavioral clarifications to CRMF codified in 1469 -- Appendix C of this specification 1471 CertificationRequest 1472 FROM PKCS-10 1473 {iso(1) identified-organization(3) dod(6) internet(1) security(5) 1474 mechanisms(5) pkix(7) id-mod(0) id-mod-pkcs10-2009(69)} 1475 -- (specified in RFC 2986 with 1993 ASN.1 syntax and IMPLICIT 1476 -- tags). Alternatively, implementers may directly include 1477 -- the [PKCS10] syntax in this module 1479 localKeyId 1480 FROM PKCS-9 1481 {iso(1) member-body(2) us(840) rsadsi(113549) pkcs(1) pkcs-9(9) 1482 modules(0) pkcs-9(1)} 1483 -- The import of localKeyId is added due to the updates made in 1484 -- CMP Updates [thisRFC] 1486 EnvelopedData, SignedData 1487 FROM CryptographicMessageSyntax-2009 1488 {iso(1) member-body(2) us(840) rsadsi(113549) pkcs(1) pkcs-9(9) 1489 smime(16) modules(0) id-mod-cms-2004-02(41)} 1490 -- The import of EnvelopedData and SignedData is added due to 1491 -- the updates made in CMP Updates [thisRFC] 1492 ; 1494 -- the rest of the module contains locally defined OIDs and 1495 -- constructs 1497 CMPCertificate ::= CHOICE { x509v3PKCert Certificate, ... } 1498 -- This syntax, while bits-on-the-wire compatible with the 1499 -- standard X.509 definition of "Certificate", allows the 1500 -- possibility of future certificate types (such as X.509 1501 -- attribute certificates, WAP WTLS certificates, or other kinds 1502 -- of certificates) within this certificate management protocol, 1503 -- should a need ever arise to support such generality. Those 1504 -- implementations that do not foresee a need to ever support 1505 -- other certificate types MAY, if they wish, comment out the 1506 -- above structure and "uncomment" the following one prior to 1507 -- compiling this ASN.1 module. (Note that interoperability 1508 -- with implementations that don't do this will be unaffected by 1509 -- this change.) 1511 -- CMPCertificate ::= Certificate 1513 PKIMessage ::= SEQUENCE { 1514 header PKIHeader, 1515 body PKIBody, 1516 protection [0] PKIProtection OPTIONAL, 1517 extraCerts [1] SEQUENCE SIZE (1..MAX) OF CMPCertificate 1518 OPTIONAL } 1520 PKIMessages ::= SEQUENCE SIZE (1..MAX) OF PKIMessage 1522 PKIHeader ::= SEQUENCE { 1523 pvno INTEGER { cmp1999(1), cmp2000(2) }, 1524 sender GeneralName, 1525 -- identifies the sender 1526 recipient GeneralName, 1527 -- identifies the intended recipient 1528 messageTime [0] GeneralizedTime OPTIONAL, 1529 -- time of production of this message (used when sender 1530 -- believes that the transport will be "suitable"; i.e., 1531 -- that the time will still be meaningful upon receipt) 1532 protectionAlg [1] AlgorithmIdentifier{ALGORITHM, {...}} 1533 OPTIONAL, 1534 -- algorithm used for calculation of protection bits 1535 senderKID [2] KeyIdentifier OPTIONAL, 1536 recipKID [3] KeyIdentifier OPTIONAL, 1537 -- to identify specific keys used for protection 1538 transactionID [4] OCTET STRING OPTIONAL, 1539 -- identifies the transaction; i.e., this will be the same in 1540 -- corresponding request, response, certConf, and PKIConf 1541 -- messages 1542 senderNonce [5] OCTET STRING OPTIONAL, 1543 recipNonce [6] OCTET STRING OPTIONAL, 1544 -- nonces used to provide replay protection, senderNonce 1545 -- is inserted by the creator of this message; recipNonce 1546 -- is a nonce previously inserted in a related message by 1547 -- the intended recipient of this message 1548 freeText [7] PKIFreeText OPTIONAL, 1549 -- this may be used to indicate context-specific instructions 1550 -- (this field is intended for human consumption) 1551 generalInfo [8] SEQUENCE SIZE (1..MAX) OF 1552 InfoTypeAndValue OPTIONAL 1553 -- this may be used to convey context-specific information 1554 -- (this field not primarily intended for human consumption) 1555 } 1557 PKIFreeText ::= SEQUENCE SIZE (1..MAX) OF UTF8String 1558 -- text encoded as UTF-8 String [RFC3629] (note: each 1559 -- UTF8String MAY include an [RFC3066] language tag 1560 -- to indicate the language of the contained text; 1561 -- see [RFC2482] for details) 1563 PKIBody ::= CHOICE { -- message-specific body elements 1564 ir [0] CertReqMessages, --Initialization Request 1565 ip [1] CertRepMessage, --Initialization Response 1566 cr [2] CertReqMessages, --Certification Request 1567 cp [3] CertRepMessage, --Certification Response 1568 p10cr [4] CertificationRequest, --imported from [PKCS10] 1569 popdecc [5] POPODecKeyChallContent, --pop Challenge 1570 popdecr [6] POPODecKeyRespContent, --pop Response 1571 kur [7] CertReqMessages, --Key Update Request 1572 kup [8] CertRepMessage, --Key Update Response 1573 krr [9] CertReqMessages, --Key Recovery Request 1574 krp [10] KeyRecRepContent, --Key Recovery Response 1575 rr [11] RevReqContent, --Revocation Request 1576 rp [12] RevRepContent, --Revocation Response 1577 ccr [13] CertReqMessages, --Cross-Cert. Request 1578 ccp [14] CertRepMessage, --Cross-Cert. Response 1579 ckuann [15] CAKeyUpdAnnContent, --CA Key Update Ann. 1580 cann [16] CertAnnContent, --Certificate Ann. 1581 rann [17] RevAnnContent, --Revocation Ann. 1582 crlann [18] CRLAnnContent, --CRL Announcement 1583 pkiconf [19] PKIConfirmContent, --Confirmation 1584 nested [20] NestedMessageContent, --Nested Message 1585 genm [21] GenMsgContent, --General Message 1586 genp [22] GenRepContent, --General Response 1587 error [23] ErrorMsgContent, --Error Message 1588 certConf [24] CertConfirmContent, --Certificate confirm 1589 pollReq [25] PollReqContent, --Polling request 1590 pollRep [26] PollRepContent --Polling response 1591 } 1593 PKIProtection ::= BIT STRING 1595 ProtectedPart ::= SEQUENCE { 1596 header PKIHeader, 1597 body PKIBody } 1599 id-PasswordBasedMac OBJECT IDENTIFIER ::= { iso(1) member-body(2) 1600 usa(840) nt(113533) nsn(7) algorithms(66) 13 } 1601 PBMParameter ::= SEQUENCE { 1602 salt OCTET STRING, 1603 -- note: implementations MAY wish to limit acceptable sizes 1604 -- of this string to values appropriate for their environment 1605 -- in order to reduce the risk of denial-of-service attacks 1606 owf AlgorithmIdentifier{DIGEST-ALGORITHM, {...}}, 1607 -- AlgId for a One-Way Function (SHA-1 recommended) 1608 iterationCount INTEGER, 1609 -- number of times the OWF is applied 1610 -- note: implementations MAY wish to limit acceptable sizes 1611 -- of this integer to values appropriate for their environment 1612 -- in order to reduce the risk of denial-of-service attacks 1613 mac AlgorithmIdentifier{MAC-ALGORITHM, {...}} 1614 -- the MAC AlgId (e.g., DES-MAC, Triple-DES-MAC [PKCS11], 1615 -- or HMAC [RFC2104, RFC2202]) 1616 } 1618 id-DHBasedMac OBJECT IDENTIFIER ::= { iso(1) member-body(2) 1619 usa(840) nt(113533) nsn(7) algorithms(66) 30 } 1620 DHBMParameter ::= SEQUENCE { 1621 owf AlgorithmIdentifier{DIGEST-ALGORITHM, {...}}, 1622 -- AlgId for a One-Way Function (SHA-1 recommended) 1623 mac AlgorithmIdentifier{MAC-ALGORITHM, {...}} 1624 -- the MAC AlgId (e.g., DES-MAC, Triple-DES-MAC [PKCS11], 1625 -- or HMAC [RFC2104, RFC2202]) 1626 } 1628 PKIStatus ::= INTEGER { 1629 accepted (0), 1630 -- you got exactly what you asked for 1631 grantedWithMods (1), 1632 -- you got something like what you asked for; the 1633 -- requester is responsible for ascertaining the differences 1634 rejection (2), 1635 -- you don't get it, more information elsewhere in the message 1636 waiting (3), 1637 -- the request body part has not yet been processed; expect to 1638 -- hear more later (note: proper handling of this status 1639 -- response MAY use the polling req/rep PKIMessages specified 1640 -- in Section 5.3.22; alternatively, polling in the underlying 1641 -- transport layer MAY have some utility in this regard) 1642 revocationWarning (4), 1643 -- this message contains a warning that a revocation is 1644 -- imminent 1645 revocationNotification (5), 1646 -- notification that a revocation has occurred 1647 keyUpdateWarning (6) 1648 -- update already done for the oldCertId specified in 1649 -- CertReqMsg 1650 } 1652 PKIFailureInfo ::= BIT STRING { 1653 -- since we can fail in more than one way! 1654 -- More codes may be added in the future if/when required. 1655 badAlg (0), 1656 -- unrecognized or unsupported Algorithm Identifier 1657 badMessageCheck (1), 1658 -- integrity check failed (e.g., signature did not verify) 1659 badRequest (2), 1660 -- transaction not permitted or supported 1661 badTime (3), 1662 -- messageTime was not sufficiently close to the system time, 1663 -- as defined by local policy 1664 badCertId (4), 1665 -- no certificate could be found matching the provided criteria 1666 badDataFormat (5), 1667 -- the data submitted has the wrong format 1668 wrongAuthority (6), 1669 -- the authority indicated in the request is different from the 1670 -- one creating the response token 1671 incorrectData (7), 1672 -- the requester's data is incorrect (for notary services) 1673 missingTimeStamp (8), 1674 -- when the timestamp is missing but should be there 1675 -- (by policy) 1676 badPOP (9), 1677 -- the proof-of-possession failed 1678 certRevoked (10), 1679 -- the certificate has already been revoked 1680 certConfirmed (11), 1681 -- the certificate has already been confirmed 1682 wrongIntegrity (12), 1683 -- invalid integrity, password based instead of signature or 1684 -- vice versa 1685 badRecipientNonce (13), 1686 -- invalid recipient nonce, either missing or wrong value 1687 timeNotAvailable (14), 1688 -- the TSA's time source is not available 1689 unacceptedPolicy (15), 1690 -- the requested TSA policy is not supported by the TSA 1691 unacceptedExtension (16), 1692 -- the requested extension is not supported by the TSA 1693 addInfoNotAvailable (17), 1694 -- the additional information requested could not be 1695 -- understood or is not available 1696 badSenderNonce (18), 1697 -- invalid sender nonce, either missing or wrong size 1698 badCertTemplate (19), 1699 -- invalid cert. template or missing mandatory information 1700 signerNotTrusted (20), 1701 -- signer of the message unknown or not trusted 1702 transactionIdInUse (21), 1703 -- the transaction identifier is already in use 1704 unsupportedVersion (22), 1705 -- the version of the message is not supported 1706 notAuthorized (23), 1707 -- the sender was not authorized to make the preceding 1708 -- request or perform the preceding action 1709 systemUnavail (24), 1710 -- the request cannot be handled due to system unavailability 1711 systemFailure (25), 1712 -- the request cannot be handled due to system failure 1713 duplicateCertReq (26) 1714 -- certificate cannot be issued because a duplicate 1715 -- certificate already exists 1716 } 1718 PKIStatusInfo ::= SEQUENCE { 1719 status PKIStatus, 1720 statusString PKIFreeText OPTIONAL, 1721 failInfo PKIFailureInfo OPTIONAL } 1723 OOBCert ::= CMPCertificate 1725 OOBCertHash ::= SEQUENCE { 1726 hashAlg [0] AlgorithmIdentifier{DIGEST-ALGORITHM, {...}} 1727 OPTIONAL, 1728 certId [1] CertId OPTIONAL, 1729 hashVal BIT STRING 1730 -- hashVal is calculated over the DER encoding of the 1731 -- self-signed certificate with the identifier certID. 1732 } 1734 POPODecKeyChallContent ::= SEQUENCE OF Challenge 1735 -- One Challenge per encryption key certification request (in the 1736 -- same order as these requests appear in CertReqMessages). 1738 Challenge ::= SEQUENCE { 1739 owf AlgorithmIdentifier{DIGEST-ALGORITHM, {...}} 1740 OPTIONAL, 1741 -- MUST be present in the first Challenge; MAY be omitted in 1742 -- any subsequent Challenge in POPODecKeyChallContent (if 1743 -- omitted, then the owf used in the immediately preceding 1744 -- Challenge is to be used). 1745 witness OCTET STRING, 1746 -- the result of applying the one-way function (owf) to a 1747 -- randomly-generated INTEGER, A. [Note that a different 1748 -- INTEGER MUST be used for each Challenge.] 1749 challenge OCTET STRING 1750 -- the encryption (under the public key for which the cert. 1751 -- request is being made) of Rand, where Rand is specified as 1752 -- Rand ::= SEQUENCE { 1753 -- int INTEGER, 1754 -- - the randomly-generated INTEGER A (above) 1755 -- sender GeneralName 1756 -- - the sender's name (as included in PKIHeader) 1757 -- } 1758 } 1760 POPODecKeyRespContent ::= SEQUENCE OF INTEGER 1761 -- One INTEGER per encryption key certification request (in the 1762 -- same order as these requests appear in CertReqMessages). The 1763 -- retrieved INTEGER A (above) is returned to the sender of the 1764 -- corresponding Challenge. 1766 CertRepMessage ::= SEQUENCE { 1767 caPubs [1] SEQUENCE SIZE (1..MAX) OF CMPCertificate 1768 OPTIONAL, 1769 response SEQUENCE OF CertResponse } 1771 CertResponse ::= SEQUENCE { 1772 certReqId INTEGER, 1773 -- to match this response with the corresponding request (a value 1774 -- of -1 is to be used if certReqId is not specified in the 1775 -- corresponding request) 1776 status PKIStatusInfo, 1777 certifiedKeyPair CertifiedKeyPair OPTIONAL, 1778 rspInfo OCTET STRING OPTIONAL 1779 -- analogous to the id-regInfo-utf8Pairs string defined 1780 -- for regInfo in CertReqMsg [RFC4211] 1781 } 1783 CertifiedKeyPair ::= SEQUENCE { 1784 certOrEncCert CertOrEncCert, 1785 privateKey [0] EncryptedKey OPTIONAL, 1786 -- see [RFC4211] for comment on encoding 1787 -- Changed from Encrypted Value to EncryptedKey as a CHOICE of 1788 -- EncryptedValue and EnvelopedData due to the changes made in 1789 -- CMP Updates [thisRFC] 1790 -- Using the choice EncryptedValue is bit-compatible to the 1791 -- syntax without this change 1792 publicationInfo [1] PKIPublicationInfo OPTIONAL } 1794 CertOrEncCert ::= CHOICE { 1795 certificate [0] CMPCertificate, 1796 encryptedCert [1] EncryptedKey 1797 -- Changed from Encrypted Value to EncryptedKey as a CHOICE of 1798 -- EncryptedValue and EnvelopedData due to the changes made in 1799 -- CMP Updates [thisRFC] 1800 -- Using the choice EncryptedValue is bit-compatible to the 1801 -- syntax without this change 1802 } 1804 KeyRecRepContent ::= SEQUENCE { 1805 status PKIStatusInfo, 1806 newSigCert [0] CMPCertificate OPTIONAL, 1807 caCerts [1] SEQUENCE SIZE (1..MAX) OF 1808 CMPCertificate OPTIONAL, 1809 keyPairHist [2] SEQUENCE SIZE (1..MAX) OF 1810 CertifiedKeyPair OPTIONAL } 1812 RevReqContent ::= SEQUENCE OF RevDetails 1814 RevDetails ::= SEQUENCE { 1815 certDetails CertTemplate, 1816 -- allows requester to specify as much as they can about 1817 -- the cert. for which revocation is requested 1818 -- (e.g., for cases in which serialNumber is not available) 1819 crlEntryDetails Extensions{{...}} OPTIONAL 1820 -- requested crlEntryExtensions 1821 } 1823 RevRepContent ::= SEQUENCE { 1824 status SEQUENCE SIZE (1..MAX) OF PKIStatusInfo, 1825 -- in same order as was sent in RevReqContent 1826 revCerts [0] SEQUENCE SIZE (1..MAX) OF CertId OPTIONAL, 1827 -- IDs for which revocation was requested 1828 -- (same order as status) 1829 crls [1] SEQUENCE SIZE (1..MAX) OF CertificateList OPTIONAL 1830 -- the resulting CRLs (there may be more than one) 1831 } 1833 CAKeyUpdAnnContent ::= SEQUENCE { 1834 oldWithNew CMPCertificate, -- old pub signed with new priv 1835 newWithOld CMPCertificate, -- new pub signed with old priv 1836 newWithNew CMPCertificate -- new pub signed with new priv 1837 } 1839 CertAnnContent ::= CMPCertificate 1841 RevAnnContent ::= SEQUENCE { 1842 status PKIStatus, 1843 certId CertId, 1844 willBeRevokedAt GeneralizedTime, 1845 badSinceDate GeneralizedTime, 1846 crlDetails Extensions{{...}} OPTIONAL 1847 -- extra CRL details (e.g., crl number, reason, location, etc.) 1848 } 1850 CRLAnnContent ::= SEQUENCE OF CertificateList 1851 PKIConfirmContent ::= NULL 1852 NestedMessageContent ::= PKIMessages 1854 -- Added in CMP Updates [thisRFC] 1856 RootCaKeyUpdateContent ::= SEQUENCE { 1857 newWithNew CMPCertificate 1858 -- new root CA certificate 1859 newWithOld [0] CMPCertificate OPTIONAL, 1860 -- X.509 certificate containing the new public root CA key 1861 -- signed with the old private root CA key 1862 oldWithNew [1] CMPCertificate OPTIONAL 1863 -- old root CA key certificate 1864 } 1866 -- Added in CMP Updates [thisRFC] 1868 CertReqTemplateContent ::= SEQUENCE { 1869 certTemplate CertTemplate, 1870 -- prefilled certTemplate structure elements 1871 rsaKeyLen INTEGER OPTIONAL 1872 -- Any reasonable RSA key length, if subjectPublicKeyInfo 1873 -- of the certTemplate has the OID rsaEncryption. 1874 } 1876 INFO-TYPE-AND-VALUE ::= TYPE-IDENTIFIER 1878 InfoTypeAndValue ::= SEQUENCE { 1879 infoType INFO-TYPE-AND-VALUE. 1880 &id({SupportedInfoSet}), 1881 infoValue INFO-TYPE-AND-VALUE. 1882 &Type({SupportedInfoSet}{@infoType}) } 1884 SupportedInfoSet INFO-TYPE-AND-VALUE ::= { ... } 1886 -- Example InfoTypeAndValue contents include, but are not limited 1887 -- to, the following (uncomment in this ASN.1 module and use as 1888 -- appropriate for a given environment): 1889 -- 1890 -- id-it-caProtEncCert OBJECT IDENTIFIER ::= {id-it 1} 1891 -- CAProtEncCertValue ::= CMPCertificate 1892 -- id-it-signKeyPairTypes OBJECT IDENTIFIER ::= {id-it 2} 1893 -- SignKeyPairTypesValue ::= SEQUENCE OF 1894 -- AlgorithmIdentifier{{...}} 1895 -- id-it-encKeyPairTypes OBJECT IDENTIFIER ::= {id-it 3} 1896 -- EncKeyPairTypesValue ::= SEQUENCE OF 1897 -- AlgorithmIdentifier{{...}} 1898 -- id-it-preferredSymmAlg OBJECT IDENTIFIER ::= {id-it 4} 1899 -- PreferredSymmAlgValue ::= AlgorithmIdentifier{{...}} 1900 -- id-it-caKeyUpdateInfo OBJECT IDENTIFIER ::= {id-it 5} 1901 -- CAKeyUpdateInfoValue ::= CAKeyUpdAnnContent 1902 -- id-it-currentCRL OBJECT IDENTIFIER ::= {id-it 6} 1903 -- CurrentCRLValue ::= CertificateList 1904 -- id-it-unsupportedOIDs OBJECT IDENTIFIER ::= {id-it 7} 1905 -- UnsupportedOIDsValue ::= SEQUENCE OF OBJECT IDENTIFIER 1906 -- id-it-keyPairParamReq OBJECT IDENTIFIER ::= {id-it 10} 1907 -- KeyPairParamReqValue ::= OBJECT IDENTIFIER 1908 -- id-it-keyPairParamRep OBJECT IDENTIFIER ::= {id-it 11} 1909 -- KeyPairParamRepValue ::= AlgorithmIdentifer 1910 -- id-it-revPassphrase OBJECT IDENTIFIER ::= {id-it 12} 1911 -- RevPassphraseValue ::= EncryptedKey 1912 -- -- Changed from Encrypted Value to EncryptedKey as a CHOICE 1913 -- -- of EncryptedValue and EnvelopedData due to the changes 1914 -- -- made in CMP Updates [thisRFC] 1915 -- -- Using the choice EncryptedValue is bit-compatible to 1916 -- -- the syntax without this change 1917 -- id-it-implicitConfirm OBJECT IDENTIFIER ::= {id-it 13} 1918 -- ImplicitConfirmValue ::= NULL 1919 -- id-it-confirmWaitTime OBJECT IDENTIFIER ::= {id-it 14} 1920 -- ConfirmWaitTimeValue ::= GeneralizedTime 1921 -- id-it-origPKIMessage OBJECT IDENTIFIER ::= {id-it 15} 1922 -- OrigPKIMessageValue ::= PKIMessages 1923 -- id-it-suppLangTags OBJECT IDENTIFIER ::= {id-it 16} 1924 -- SuppLangTagsValue ::= SEQUENCE OF UTF8String 1925 -- id-it-caCerts OBJECT IDENTIFIER ::= { id-it 17} 1926 -- CaCertsValue ::= SEQUENCE OF CMPCertificate 1927 -- -- id-it-caCerts added in CMP Updates [thisRFC] 1928 -- id-it-rootCaKeyUpdate OBJECT IDENTIFIER ::= { id-it 18} 1929 -- RootCaKeyUpdateValue ::= RootCaKeyUpdateContent 1930 -- -- id-it-rootCaKeyUpdate added in CMP Updates [thisRFC] 1931 -- id-it-certReqTemplate OBJECT IDENTIFIER ::= { id-it 19} 1932 -- CertReqTemplateValue ::= CertReqTemplateContent 1933 -- -- id-it-certReqTemplate added in CMP Updates [thisRFC] 1934 -- 1935 -- where 1936 -- 1937 -- id-pkix OBJECT IDENTIFIER ::= { 1938 -- iso(1) identified-organization(3) 1939 -- dod(6) internet(1) security(5) mechanisms(5) pkix(7)} 1940 -- and 1941 -- id-it OBJECT IDENTIFIER ::= {id-pkix 4} 1942 -- 1943 -- 1944 -- This construct MAY also be used to define new PKIX Certificate 1945 -- Management Protocol request and response messages, or general- 1946 -- purpose (e.g., announcement) messages for future needs or for 1947 -- specific environments. 1949 GenMsgContent ::= SEQUENCE OF InfoTypeAndValue 1951 -- May be sent by EE, RA, or CA (depending on message content). 1952 -- The OPTIONAL infoValue parameter of InfoTypeAndValue will 1953 -- typically be omitted for some of the examples given above. 1954 -- The receiver is free to ignore any contained OBJECT IDs that it 1955 -- does not recognize. If sent from EE to CA, the empty set 1956 -- indicates that the CA may send 1957 -- any/all information that it wishes. 1959 GenRepContent ::= SEQUENCE OF InfoTypeAndValue 1960 -- Receiver MAY ignore any contained OIDs that it does not 1961 -- recognize. 1963 ErrorMsgContent ::= SEQUENCE { 1964 pKIStatusInfo PKIStatusInfo, 1965 errorCode INTEGER OPTIONAL, 1966 -- implementation-specific error codes 1967 errorDetails PKIFreeText OPTIONAL 1968 -- implementation-specific error details 1969 } 1971 CertConfirmContent ::= SEQUENCE OF CertStatus 1973 CertStatus ::= SEQUENCE { 1974 certHash OCTET STRING, 1975 -- the hash of the certificate, using the same hash algorithm 1976 -- as is used to create and verify the certificate signature 1977 certReqId INTEGER, 1978 -- to match this confirmation with the corresponding req/rep 1979 statusInfo PKIStatusInfo OPTIONAL } 1981 PollReqContent ::= SEQUENCE OF SEQUENCE { 1982 certReqId INTEGER } 1984 PollRepContent ::= SEQUENCE OF SEQUENCE { 1985 certReqId INTEGER, 1986 checkAfter INTEGER, -- time in seconds 1987 reason PKIFreeText OPTIONAL } 1989 -- 1990 -- Extended Key Usage extension for PKI entities used in CMP 1991 -- operations, added due to the changes made in 1992 -- CMP Updates [thisRFC] 1993 -- The EKUs for the CA and RA are reused from CMC as defined in 1994 -- [RFC6402] 1995 -- 1996 -- id-kp-cmcCA OBJECT IDENTIFIER ::= { id-kp 27 } 1997 -- id-kp-cmcRA OBJECT IDENTIFIER ::= { id-kp 28 } 1998 id-kp-cmKGA OBJECT IDENTIFIER ::= { id-kp 32 } 2000 END 2002 Appendix B. History of changes 2004 Note: This appendix will be deleted in the final version of the 2005 document. 2007 From version 03 -> 04: 2009 o Added Section 2.7 to introduce three new id-it IDs for uses in 2010 general messages as discussed (see thread "draft-ietf-lamps-cmp- 2011 updates add section to introduce id-it-caCerts, id-it- 2012 rootCaKeyUpdate, and id-it-certReqTemplate") 2014 o Added the new id-it IDs and the /.well-known/cmp to the IANA 2015 Considerations of [RFC4210] in Section 2.9 2017 o Updated the IANA Considerations of [RFC4210] in Section 2.10 2019 o Some changes in wording on Section 3 due to review comments from 2020 Martin Peylo 2022 From version 02 -> 03: 2024 o Added a ToDo on aligning with the CMP Algorithms draft that will 2025 be set up as decided in IETF 108 2027 o Updated section on Encrypted Values in Section 2.4 to add the 2028 AsymmetricKey Package structure to transport a newly generated 2029 private key as decided in IETF 108 2031 o Updated the IANA Considerations of [RFC4210] in Section 2.10 2033 o Added the pre-registered OID in Section 2.10 and the ASN.1 module 2035 o Added Section 3 to document the changes to RFC 6712 [RFC6712] 2036 regarding URI discovery and using the path-prefix of '/.well- 2037 known/' as discussed in IETF 108 2039 o Updated the IANA Considerations section 2041 o Added a complete updated ASN.1 module in 1988 syntax to update 2042 Appendix F of [RFC4210] and a complete updated ASN.1 module in 2043 2002 syntax to update Section 9 of [RFC5912] 2045 o Minor changes in wording 2047 From version 01 -> 02: 2049 o Updated section on EKU OIDs in Section 2.2 as decided in IETF 107 2051 o Changed from symmetric key-encryption to password-based key 2052 management technique in Section 2.4 as discussed with Russ and Jim 2053 on the mailing list 2055 o Defined the attribute containing the key identifier for the 2056 revocation passphrase in Section 2.10 2058 o Moved the change history to the Appendix 2060 From version 00 -> 01: 2062 o Minor changes in wording 2064 From draft-brockhaus-lamps-cmp-updates-03 -> draft-ietf-lamps-cmp- 2065 updates-00: 2067 o Changes required to reflect WG adoption 2069 From version 02 -> 03: 2071 o Added some clarification in Section 2.1 2073 From version 01 -> 02: 2075 o Added clarification to section on multiple protection 2077 o Added clarification on new EKUs after some exchange with Tomas 2078 Gustavsson 2080 o Reused OIDs from RFC 6402 [RFC6402] as suggested by Sean Turner at 2081 IETF 106 2083 o Added clarification on the field containing the key identifier for 2084 a revocation passphrase 2086 o Minor changes in wording 2088 From version 00 -> 01: 2090 o Added a section describing the new extended key usages 2091 o Completed the section on changes to the specification of encrypted 2092 values 2094 o Added a section on clarification to Appendix D.4 2096 o Minor generalization in RFC 4210 [RFC4210] Sections 5.1.3.4 and 2097 5.3.22 2099 o Minor changes in wording 2101 Author's Address 2103 Hendrik Brockhaus 2104 Siemens AG 2106 Email: hendrik.brockhaus@siemens.com