idnits 2.17.1 draft-ietf-lamps-cmp-updates-02.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 (July 6, 2020) is 1390 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) == Missing Reference: 'IEEE802.1AR' is mentioned on line 246, but not defined -- Looks like a reference, but probably isn't: '0' on line 650 == Missing Reference: 'CRMF' is mentioned on line 645, but not defined -- Looks like a reference, but probably isn't: '1' on line 651 ** Downref: Normative reference to an Informational RFC: RFC 2985 ** Downref: Normative reference to an Informational RFC: RFC 2986 == Outdated reference: A later version (-21) exists of draft-ietf-lamps-lightweight-cmp-profile-01 Summary: 2 errors (**), 0 flaws (~~), 4 warnings (==), 4 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 (if approved) July 6, 2020 5 Intended status: Standards Track 6 Expires: January 7, 2021 8 CMP Updates 9 draft-ietf-lamps-cmp-updates-02 11 Abstract 13 This document contains a set of updates to the base syntax of 14 Certificate Management Protocol (CMP) version 2. This document 15 updates RFC 4210. 17 Specifically, the CMP services updated in this document comprise the 18 enabling of using EnvelopedData instead of EncryptedValue and the 19 definition of extended key usages to identify certificates of CMP 20 endpoints on certification and registration authorities. 22 Status of This Memo 24 This Internet-Draft is submitted in full conformance with the 25 provisions of BCP 78 and BCP 79. 27 Internet-Drafts are working documents of the Internet Engineering 28 Task Force (IETF). Note that other groups may also distribute 29 working documents as Internet-Drafts. The list of current Internet- 30 Drafts is at https://datatracker.ietf.org/drafts/current/. 32 Internet-Drafts are draft documents valid for a maximum of six months 33 and may be updated, replaced, or obsoleted by other documents at any 34 time. It is inappropriate to use Internet-Drafts as reference 35 material or to cite them other than as "work in progress." 37 This Internet-Draft will expire on January 7, 2021. 39 Copyright Notice 41 Copyright (c) 2020 IETF Trust and the persons identified as the 42 document authors. All rights reserved. 44 This document is subject to BCP 78 and the IETF Trust's Legal 45 Provisions Relating to IETF Documents 46 (https://trustee.ietf.org/license-info) in effect on the date of 47 publication of this document. Please review these documents 48 carefully, as they describe your rights and restrictions with respect 49 to this document. Code Components extracted from this document must 50 include Simplified BSD License text as described in Section 4.e of 51 the Trust Legal Provisions and are provided without warranty as 52 described in the Simplified BSD License. 54 Table of Contents 56 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2 57 1.1. Convention and Terminology . . . . . . . . . . . . . . . 3 58 2. Updates to RFC 4210 - Certificate Management Protocol (CMP) . 3 59 2.1. New Section 1.1. - Changes since RFC 4210 . . . . . . . . 3 60 2.2. New Section 4.5 - Extended Key Usage . . . . . . . . . . 4 61 2.3. Replace Section 5.1.3.4 - Multiple Protection . . . . . . 6 62 2.4. Replace Section 5.2.2. - Encrypted Values . . . . . . . . 7 63 2.5. Update Section 5.3.4. - Certification Response . . . . . 8 64 2.6. Replace Section 5.3.19.9. - Revocation Passphrase . . . . 9 65 2.7. Update Section 5.3.22 - Polling Request and Response . . 9 66 2.8. Update Appendix B - The Use of Revocation Passphrase . . 10 67 2.9. Update Appendix C - Request Message Behavioral 68 Clarifications . . . . . . . . . . . . . . . . . . . . . 11 69 2.10. Update Appendix D.4. - Initial Registration/Certification 70 (Basic Authenticated Scheme) . . . . . . . . . . . . . . 12 71 3. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 12 72 4. Security Considerations . . . . . . . . . . . . . . . . . . . 12 73 5. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 12 74 6. References . . . . . . . . . . . . . . . . . . . . . . . . . 12 75 6.1. Normative References . . . . . . . . . . . . . . . . . . 12 76 6.2. Informative References . . . . . . . . . . . . . . . . . 13 77 Appendix A. ASN.1 Modules . . . . . . . . . . . . . . . . . . . 14 78 Appendix B. History of changes . . . . . . . . . . . . . . . . . 15 79 Author's Address . . . . . . . . . . . . . . . . . . . . . . . . 16 81 1. Introduction 83 While using CMP [RFC4210] in industrial and IoT environments and 84 developing the Lightweight CMP Profile 85 [I-D.ietf-lamps-lightweight-cmp-profile] some limitations were 86 identified in the original CMP specification. This document updates 87 RFC 4210 [RFC4210] to overcome these limitations. 89 In general, this document aims to improve the crypto agility of CMP 90 to be flexible to react on future advances in cryptography. 92 This document also introduces new extended key usages to identify CMP 93 endpoints on registration and certification authorities. 95 1.1. Convention and Terminology 97 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 98 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 99 document are to be interpreted as described in RFC 2119 [RFC2119]. 101 In this document, these words will appear with that interpretation 102 only when in ALL CAPS. Lower case uses of these words are not to be 103 interpreted as carrying significance described in RFC 2119. 105 Technical terminology is used in conformance with RFC 4210 [RFC4210], 106 RFC 4211 [RFC4211], and RFC 5280 [RFC5280]. The following key words 107 are used: 109 CA: Certification authority, which issues certificates. 111 RA: Registration authority, an optional system component to which a 112 CA delegates certificate management functions such as 113 authorization checks. 115 KGA: Key generation authority, which generates key pairs on behalf of 116 an EE. The KGA could be co-located with an RA or a CA. 118 EE: End entity, a user, device, or service that holds a PKI 119 certificate. An identifier for the EE is given as its subject 120 of the certificate. 122 2. Updates to RFC 4210 - Certificate Management Protocol (CMP) 124 2.1. New Section 1.1. - Changes since RFC 4210 126 The following subsection describes feature updates to RFC 4210 127 [RFC4210]. They are always related to the base specification. Hence 128 references to the original sections in RFC 4210 [RFC4210] are used 129 whenever possible. 131 Insert this section at the end of the current Section 1. 133 1.1 Changes since RFC 4210 135 The following updates are made in draft-ietf-lamps-cmp-updates: 137 o Add new extended key usages for different CMP server types, e.g. 138 registration authority and certification authority, to express the 139 authorization of the entity identified in the certificate 140 containing the respective extended key usage extension to act as 141 the indicated PKI management entity. 143 o Extend the description of multiple protection to cover additional 144 use cases, e.g., batch processing of messages. 146 o Offering EnvelopedData as the prefered choice next to 147 EncryptedValue to extend crypto agility in CMP. Note that 148 according to RFC 4211 [RFC4211] section 2.1.9 the use of the 149 EncryptedValue structure has been deprecated in favor of the 150 EnvelopedData structure. RFC 4211 [RFC4211] offers the 151 EncryptedKey structure, a choice of EncryptedValue and 152 EnvelopedData for migration to EnvelopedData. For reasons of 153 completeness and consistency the exchange of EncryptedValue is 154 performed for all usages in RFC 4210 [RFC4210]. This includes the 155 protection of centrally generated private keys, encryption of 156 certificates, and revocation passphrases. 158 o Extend the usage of polling also to p10cr messages. 160 2.2. New Section 4.5 - Extended Key Usage 162 The following subsection describes new extended key usages for 163 different CMP server typesspecitied in RFC 4210 [RFC4210]. 165 Insert this section at the end of the current Section 4. 167 4.5 Extended Key Usage 169 The Extended Key Usage (EKU) extension indicates the purposes for 170 which the certified public key may be used. It therefore restricts 171 the use of a certificate to specific applications. 173 A CA may want to delegate parts of their duties to other PKI 174 management entities. The mechanism to prove this delegation 175 explained in this section offers zero-touch means to check the 176 authorization of such delegation. Such delegation could also be 177 expressed by other means, e.g., explicit configuration. 179 To offer automatic validation means for the delegation of a role by a 180 CA, the certificates used by PKI management entities for CMP message 181 protection or signed data for central key generation MUST be issued 182 by the delegating CA and MUST contain the respective EKUs. This 183 proves the authorization of this entity by the delegating CA to act 184 as the PKI management entity as described below. 186 The ASN.1 to define these EKUs is: 188 id-kp-cmcCA OBJECT IDENTIFIER ::= { id-kp 27 } 189 id-kp-cmcRA OBJECT IDENTIFIER ::= { id-kp 28 } 190 id-kp-cmKGA OBJECT IDENTIFIER ::= { id-kp ... } 191 < TBD: id-kp-cmKGA to be defined. > 193 Note: RFC 6402 section 2.10 [RFC6402] specifies OIDs for a CMC CA and 194 a CMC RA. As the functionality of a CA and RA is not specific to 195 whether use CMC or CMP as certificate management protocol, the same 196 OIDs SHALL be used for a CMP CA and a CMP RA. 198 < TBD: The Description of the OIDs needs to be extended to avoid 199 confusion as they currently only refer to CMC endpoints. > 201 The description of the PKI management entity for each of the EKUs is 202 as follows: 204 CMP CA: CMP Certification Authorities are CMP endpoints on CA 205 equipment as described in section 3.1.1.2. The key used in 206 the context of CMP management operations, especially CMP 207 message protection, need not be the same key that signs the 208 certificates. It is necessary, however, to ensure that the 209 entity acting as CMP CA is authorized to do so. Therefore, 210 the CMP CA MUST do one of the following, 212 * use the CA private key on the CMP endpoint, or 214 * explicitly designate this authority to another entity. 216 For automatic validation of such delegation it MUST be 217 indicated by the id-kp-cmcCA extended key usage. This 218 extended key usage MUST be placed into the certificate used 219 on the CA equipment and the CA that delegates this role MUST 220 issue the CMP CA certificate. 222 Note: Using a separate key pair for protecting CMP 223 management operations at the CA decreases the number of 224 operations of the private key used to sign certificates. 226 CMP RA: CMP Registration Authorities are CMP endpoints on RA 227 equipment as described in Section 3.1.1.3. A CMP RA is 228 identified by the id-kp-cmcRA extended key usage. This 229 extended key usage is placed into RA certificates. The CA 230 that delegated this role is identified by the CA that issued 231 the CMP RA certificate. 233 CMP KGA: CMP Key Generation Authorities are identified by the id-kp- 234 cmKGA extended key usage. Though the CMP KGA knows the 235 private key it generated on behalf of the end entity. This 236 is a very sensible service and needs specific authorization. 237 This authorization is either with the CA certificate itself, 238 or indicated by placing the id-kp-cmKGA extended key usage 239 into the CMP RA or CMP CA certificate used to authenticate 240 the origin of the private key, and to express the 241 authorization to offer this service. 243 Note: In device PKIs, especially those issuing IDevID certificates, 244 CA may have very long validity (including the GeneralizedTime value 245 99991231235959Z to indicate a not well-defined expiration date as 246 specified in IEEE 802.1AR Section 8.5 [IEEE802.1AR] and RFC 5280 247 Section 4.1.2.5 [RFC5280]). Such validity periods SHOULD NOT be used 248 for protection of CMP messages. Certificates for delegated CMP 249 message protection (CMP CA, CMP RA, CMP KGA) MUST NOT use indefinite 250 expiration date. 252 2.3. Replace Section 5.1.3.4 - Multiple Protection 254 Section 5.1.3.4 of RFC 4210 [RFC4210] describes the nested message. 255 This document opens the usage of nested messages also for batch 256 transport of PKI messages between different PKI management entities. 258 Replace the text of the section with the following text. 260 In cases where an end entity sends a protected PKI message to an RA, 261 the RA MAY forward that message to a CA, adding its own protection 262 (which MAY be a MAC or a signature, depending on the information and 263 certificates shared between the RA and the CA). There are different 264 use cases for such multi protected messages. 266 o The RA confirms the validation and authorization of a message and 267 forwards the original message unchanged. 269 o The RA collects several messages and forwards them in a batch. 270 This can for instance be used to bridge an off-line connection 271 between two PKI management entities. In communication to the CA 272 request messages and in communication from the CA response or 273 announcement messages will be collected in such batch. 275 o The RA modifies the message(s) in some way (e.g., add or modify 276 particular field values or add new extensions) before forwarding 277 them, then it MAY create its own desired PKIBody. In case the 278 changes made by the RA to PKIMessage breaks the POP, the RA MUST 279 either set the POP RAVerified or include the original PKIMessage 280 from the EE in the generalInfo field of PKIHeader of the nested 281 message (to force the CA to check POP on the original message). 282 The infoType to be used in this situation is {id-it 15} (see 283 Section 5.3.19 for the value of id-it) and the infoValue is 284 PKIMessages (contents MUST be in the same order as the requests in 285 PKIBody). For simplicity reasons, if batching is used in 286 combination with inclusion of the original PKIMessage in the 287 generalInfo field, all messages in the batch MUST be of the same 288 type (e.g., ir). 290 These use cases are accomplished by nesting the messages sent by the 291 PKI entity within a new PKI message. The structure used is as 292 follows. 294 NestedMessageContent ::= PKIMessages 296 (The use of PKIMessages, a SEQUENCE OF PKIMessage, lets the RA batch 297 the requests of several EEs in a single new message.) 299 2.4. Replace Section 5.2.2. - Encrypted Values 301 Section 5.2.2 of RFC 4210 [RFC4210] describes the usage of 302 EncryptedValue to transport encrypted data. This document extends 303 the encryption of data to preferably use EnvelopedData. 305 Replace the text of the section with the following text. 307 Where encrypted data (restricted, in this specification, to be either 308 private keys, certificates, or passwords) are sent in PKI messages, 309 the EncryptedKey data structure is used. 311 EncryptedKey ::= CHOICE { 312 encryptedValue EncryptedValue, -- deprecated 313 envelopedData [0] EnvelopedData } 315 See CRMF [RFC4211] for EncryptedKey and EncryptedValue syntax and for 316 EnvelopedData syntax see CMS [RFC5652]. Using the EncryptedKey data 317 structure, the choice to either use EncryptedValue (for backward 318 compatibility only) or EnvelopedData is offered. The use of the 319 EncryptedValue structure has been deprecated in favor of the 320 EnvelopedData structure. Therefore, it is recommended to use 321 EnvelopedData. 323 The EncryptedKey data structure is used in CMP to either transport a 324 private key, certificate or revocation passphrase in encrypted form. 326 EnvelopedData is used as follows: 328 o Contains only one recepientInfo structure because the content is 329 encrypted only for one recipient. 331 o Contains a private key in a SignedData structure as specified in 332 CMS section 5 [RFC5652] signed by the Key Generation Authority. 334 o Contains a certificate or revocation passphrase directly in the 335 encryptedContent field. 337 Note: When transferring a centrally generated private key in a 338 certificate response message to the EE, the algorithm identifier and 339 the associated public key will anyhow be transported in this response 340 message. Therefore, the private key will not be delivered in a key 341 package structure as specified in [RFC5958] and [RFC6032]. But the 342 wrapping of the private key in a SignedData structure that is wrapped 343 in the EnvelopedData structure as specified in [RFC6032] is applied. 345 The content of the EnvelopedData structure, as specified in CMS 346 section 6 [RFC5652], MUST be encrypted using a newly generated 347 symmetric content-encryption key. This content-encryption key MUST 348 be securely provided to the recipient using one of three key 349 management techniques. 351 The choice of the key management technique to be used by the sender 352 depends on the credential available for the recipient: 354 o Jointly shared secret: The content-encryption key will be 355 protected using the password-based key management technique, as 356 specified in CMS section 6.2.4 [RFC5652]. 358 o Recipient's certificate that contains a key usage extension 359 asserting keyAgreement: The content-encryption key will be 360 protected using the key agreement key management technique, as 361 specified in CMS section 6.2.2 [RFC5652]. 363 o Recipient's certificate that contains a key usage extension 364 asserting keyEncipherment: The content-encryption key will be 365 protected using the key transport key management technique, as 366 specified in CMS section 6.2.1 [RFC5652]. 368 2.5. Update Section 5.3.4. - Certification Response 370 Section 5.3.4 of RFC 4210 [RFC4210] describes the Certification 371 Response. This document updates the syntax by using the parent 372 structure EncryptedKey instead of EncryptedValue as described in 373 Section 2.1 above. 375 Replace the ASN.1 syntax of CertifiedKeyPair and CertOrEncCert with 376 the following text. 378 CertifiedKeyPair ::= SEQUENCE { 379 certOrEncCert CertOrEncCert, 380 privateKey [0] EncryptedKey OPTIONAL, 381 -- see [CRMF] for comment on encoding 382 publicationInfo [1] PKIPublicationInfo OPTIONAL 383 } 385 CertOrEncCert ::= CHOICE { 386 certificate [0] Certificate, 387 encryptedCert [1] EncryptedKey 388 } 390 Add the following paragraphs to the end of the section. 392 The use of EncryptedKey is described in section 5.2.2. 394 2.6. Replace Section 5.3.19.9. - Revocation Passphrase 396 Section 5.3.19.9 of RFC 4210 [RFC4210] describes the provisioning of 397 a revocation passphrase for authenticating a later revocation 398 request. This document updates the handling by using the parent 399 structure EncryptedKey instead of EncryptedValue to transport this 400 information as described in Section 2.1 above. 402 Replace the text of the section with the following text. 404 This MAY be used by the EE to send a passphrase to a CA/RA for the 405 purpose of authenticating a later revocation request (in the case 406 that the appropriate signing private key is no longer available to 407 authenticate the request). See Appendix B for further details on the 408 use of this mechanism. 410 GenMsg: {id-it 12}, EncryptedKey 411 GenRep: {id-it 12}, < absent > 413 The use of EncryptedKey is described in section 5.2.2. 415 2.7. Update Section 5.3.22 - Polling Request and Response 417 Section 5.3.22 of RFC 4210 [RFC4210] describes when and how polling 418 messages are used. This document adds the polling mechanism also to 419 outstanding p10cr transactions. 421 Replace all paragraphs in front of the state machine diagram with the 422 following text. 424 This pair of messages is intended to handle scenarios in which the 425 client needs to poll the server in order to determine the status of 426 an outstanding ir, cr, p10cr, or kur transaction (i.e., when the 427 "waiting" PKIStatus has been received). 429 PollReqContent ::= SEQUENCE OF SEQUENCE { 430 certReqId INTEGER } 432 PollRepContent ::= SEQUENCE OF SEQUENCE { 433 certReqId INTEGER, 434 checkAfter INTEGER, -- time in seconds 435 reason PKIFreeText OPTIONAL } 437 The following clauses describe when polling messages are used, and 438 how they are used. It is assumed that multiple certConf messages can 439 be sent during transactions. There will be one sent in response to 440 each ip, cp, or kup that contains a CertStatus for an issued 441 certificate. 443 1 In response to an ip, cp, or kup message, an EE will send a 444 certConf for all issued certificates and, following the ack, a 445 pollReq for all pending certificates. 447 2 In response to a pollReq, a CA/RA will return an ip, cp, or kup if 448 one or more of the pending certificates is ready; otherwise, it 449 will return a pollRep. 451 3 If the EE receives a pollRep, it will wait for at least as long as 452 the checkAfter value before sending another pollReq. 454 4 If an ip, cp, or kup is received in response to a pollReq, then it 455 will be treated in the same way as the initial response. 457 Note: A p10cr message contains exactly one CertificationRequestInfo 458 data structure as specified in PKCS#10 [RFC2986] but no certificate 459 request number. Therefore, the certReqId MUST be set to 0 in all 460 following messages of this transaction. 462 2.8. Update Appendix B - The Use of Revocation Passphrase 464 Appendix B of RFC 4210 [RFC4210] describes the usage of the 465 revocation passphrase. As this document updates RFC 4210 [RFC4210] 466 to utilize the parent structure EncryptedKey instead of 467 EncryptedValue as described in Section 2.1 above, the description is 468 updated accordingly. 470 Replace the first bullet point of this section with the following 471 text. 473 o The OID and value specified in Section 5.3.19.9 of RFC 4210 474 [RFC4210] MAY be sent in a GenMsg message at any time, or MAY be 475 sent in the generalInfo field of the PKIHeader of any PKIMessage 476 at any time. (In particular, the EncryptedKey as described in 477 section 5.2.2 may be sent in the header of the certConf message 478 that confirms acceptance of certificates requested in an 479 initialization request or certificate request message.) This 480 conveys a revocation passphrase chosen by the entity (i.e., for 481 use of EnvelopedData this is in the decrypted bytes of 482 encryptedContent field and for use of EncryptedValue this is in 483 the decrypted bytes of the encValue field) to the relevant CA/RA; 484 furthermore, the transfer is accomplished with appropriate 485 confidentiality characteristics. 487 Replace the third bullet point of this section with the following 488 text. 490 o When using EnvelopedData the localKeyId attribute as specified in 491 RFC 2985 [RFC2985] and when using EncryptedValue the valueHint 492 field MAY contain a key identifier (chosen by the entity, along 493 with the passphrase itself) to assist in later retrieval of the 494 correct passphrase (e.g., when the revocation request is 495 constructed by the entity and received by the CA/RA). 497 2.9. Update Appendix C - Request Message Behavioral Clarifications 499 Appendix C of RFC 4210 [RFC4210] provides clarifications to the 500 request message behavior. As this document updates RFC 4210 501 [RFC4210] to utilize the parent structure EncryptedKey instead of 502 EncryptedValue as described in Section 2.1 above, the description is 503 updated accordingly. 505 Replace the note coming after the ASN.1 syntax of POPOPrivKey of this 506 section with the following text. 508 -- ********** 509 -- * the type of "thisMessage" is given as BIT STRING in RFC 4211 510 -- * [RFC4211]; it should be "EncryptedKey" (in accordance with 511 -- * Section 5.2.2 of this specification). Therefore, this document 512 -- * makes the behavioral clarification of specifying that the 513 -- * contents of "thisMessage" MUST be encoded either as 514 -- * "EnvelopedData" or "EncryptedValue" (only for backward 515 -- * compatibility) and then wrapped in a BIT STRING. This allows 516 -- * the necessary conveyance and protection of the private key 517 -- * while maintaining bits-on-the-wire compatibility with RFC 4211 518 -- * [RFC4211]. 519 -- ********** 521 2.10. Update Appendix D.4. - Initial Registration/Certification (Basic 522 Authenticated Scheme) 524 Appendix D.4 of RFC 4210 [RFC4210] provides the initial registration/ 525 certification scheme. This scheme shall continue to use 526 EncryptedValue for backward compatibility reasons. 528 Replace the comment after the privateKey field of 529 crc[1].certifiedKeyPair in the syntax of the Initialization Response 530 message with the following text. 532 -- see Appendix C, Request Message Behavioral Clarifications 533 -- for backward compatibility reasons, use EncryptedValue 535 3. IANA Considerations 537 < TBD: A new OID for id-kp-cmKGA needs to be requested. > 539 < TBD: The existing description and information of id-kp-cmcRA and 540 id-kp-cmcCA need to be updated to reflect their extended usage. > 542 4. Security Considerations 544 No changes are made to the existing security considerations of 545 RFC 4210 [RFC4210]. 547 5. Acknowledgements 549 Special thank goes to Jim Schaad for his guidance and the inspiration 550 on structuring and writing this document I got from [RFC6402] that 551 updates CMC. 553 I also like to thank all reviewers of this document for their 554 valuable feedback. 556 6. References 558 6.1. Normative References 560 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 561 Requirement Levels", BCP 14, RFC 2119, 562 DOI 10.17487/RFC2119, March 1997, 563 . 565 [RFC2985] Nystrom, M. and B. Kaliski, "PKCS #9: Selected Object 566 Classes and Attribute Types Version 2.0", RFC 2985, 567 DOI 10.17487/RFC2985, November 2000, 568 . 570 [RFC2986] Nystrom, M. and B. Kaliski, "PKCS #10: Certification 571 Request Syntax Specification Version 1.7", RFC 2986, 572 DOI 10.17487/RFC2986, November 2000, 573 . 575 [RFC4210] Adams, C., Farrell, S., Kause, T., and T. Mononen, 576 "Internet X.509 Public Key Infrastructure Certificate 577 Management Protocol (CMP)", RFC 4210, 578 DOI 10.17487/RFC4210, September 2005, 579 . 581 [RFC4211] Schaad, J., "Internet X.509 Public Key Infrastructure 582 Certificate Request Message Format (CRMF)", RFC 4211, 583 DOI 10.17487/RFC4211, September 2005, 584 . 586 [RFC5280] Cooper, D., Santesson, S., Farrell, S., Boeyen, S., 587 Housley, R., and W. Polk, "Internet X.509 Public Key 588 Infrastructure Certificate and Certificate Revocation List 589 (CRL) Profile", RFC 5280, DOI 10.17487/RFC5280, May 2008, 590 . 592 [RFC5652] Housley, R., "Cryptographic Message Syntax (CMS)", STD 70, 593 RFC 5652, DOI 10.17487/RFC5652, September 2009, 594 . 596 [RFC6402] Schaad, J., "Certificate Management over CMS (CMC) 597 Updates", RFC 6402, DOI 10.17487/RFC6402, November 2011, 598 . 600 6.2. Informative References 602 [I-D.ietf-lamps-lightweight-cmp-profile] 603 Brockhaus, H., Fries, S., and D. Oheimb, "Lightweight CMP 604 Profile", draft-ietf-lamps-lightweight-cmp-profile-01 605 (work in progress), March 2020. 607 [RFC5958] Turner, S., "Asymmetric Key Packages", RFC 5958, 608 DOI 10.17487/RFC5958, August 2010, 609 . 611 [RFC6032] Turner, S. and R. Housley, "Cryptographic Message Syntax 612 (CMS) Encrypted Key Package Content Type", RFC 6032, 613 DOI 10.17487/RFC6032, December 2010, 614 . 616 Appendix A. ASN.1 Modules 618 Changes to the following parts are needed 620 o Import from PKCS-9 622 localKeyId 623 FROM PKCS-9 {iso(1) member-body(2) us(840) rsadsi(113549) pkcs(1) 624 pkcs-9(9) modules(0) pkcs-9(1)} 626 o Import from PKIKXCRMF-2005 628 CertTemplate, PKIPublicationInfo, EncryptedKey, EncryptedValue, 629 CertId, CertReqMessages 630 FROM PKIXCRMF-2005 {iso(1) identified-organization(3) 631 dod(6) internet(1) security(5) mechanisms(5) pkix(7) 632 id-mod(0) id-mod-crmf2005(36)} 634 o Import from CryptographicMessageSyntax2004 636 EnvelopedData, SignedData 637 FROM CryptographicMessageSyntax2004 { iso(1) member-body(2) 638 us(840) rsadsi(113549) pkcs(1) pkcs-9(9) smime(16) 639 modules(0) cms-2004(24) } 641 o In CertifiedKeyPair, CertOrEncCert and id-it-revPassphrase 642 CertifiedKeyPair ::= SEQUENCE { 643 certOrEncCert CertOrEncCert, 644 privateKey [0] EncryptedKey OPTIONAL, 645 -- see [CRMF] for comment on encoding 646 publicationInfo [1] PKIPublicationInfo OPTIONAL 647 } 649 CertOrEncCert ::= CHOICE { 650 certificate [0] CMPCertificate, 651 encryptedCert [1] EncryptedKey 652 } 654 -- id-it-revPassphrase OBJECT IDENTIFIER ::= {id-it 12} 655 -- RevPassphraseValue ::= EncryptedKey 657 -- 658 -- Extended Key Usage extension for PKI entities used in 659 -- CMP operations 660 -- 662 id-kp-cmcCA OBJECT IDENTIFIER ::= { id-kp 27 } 663 id-kp-cmcRA OBJECT IDENTIFIER ::= { id-kp 28 } 664 id-kp-cmKGA OBJECT IDENTIFIER ::= { id-kp ... } 666 < TBD: id-kp-cmKGA to be defined. > 668 < TBD: If needed the complete ASN.1 Module from RFC 4210 section 669 needs to be copied here. > 671 Appendix B. History of changes 673 From version 01 -> 02: 675 o Updated section on EKU OIDs in Section 2.2 as decided in IETF 107 677 o Changed from symmetric key-encryption to password-based key 678 management technique in Section 2.4 as discussed with Russ and Jim 679 on the mailing list 681 o Defined the attribute containing the key identifier for the 682 revocation passphrase in Section 2.8 684 o Moved the change history to the Appendix 686 From version 00 -> 01: 688 o Minor changes in wording 689 From draft-brockhaus-lamps-cmp-updates-03 -> draft-ietf-lamps-cmp- 690 updates-00: 692 o Changes required to reflect WG adoption 694 From version 02 -> 03: 696 o Added some clarification in Section 2.1 698 From version 01 -> 02: 700 o Added clarification to section on multiple protection 702 o Added clarification on new EKUs after some exchange with Tomas 703 Gustavsson 705 o Reused OIDs from RFC 6402 [RFC6402] as suggested by Sean Turner at 706 IETF 106 708 o Added clarification on the field containing the key identifier for 709 a revocation passphrase 711 o Minor changes in wording 713 From version 00 -> 01: 715 o Added a section describing the new extended key usages 717 o Completed the section on changes to the specification of encrypted 718 values 720 o Added a section on clarification to Appendix D.4 722 o Minor generalization in RFC 4210 [RFC4210] Sections 5.1.3.4 and 723 5.3.22 725 o Minor changes in wording 727 Author's Address 729 Hendrik Brockhaus 730 Siemens AG 732 Email: hendrik.brockhaus@siemens.com