idnits 2.17.1 draft-ietf-lamps-cmp-updates-01.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 (March 4, 2020) is 1507 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 292, but not defined -- Looks like a reference, but probably isn't: '0' on line 693 == Missing Reference: 'CRMF' is mentioned on line 688, but not defined -- Looks like a reference, but probably isn't: '1' on line 694 ** 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-00 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) March 4, 2020 5 Intended status: Standards Track 6 Expires: September 5, 2020 8 CMP Updates 9 draft-ietf-lamps-cmp-updates-01 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 September 5, 2020. 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. History of changes . . . . . . . . . . . . . . . . . . . . . 2 57 2. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 3 58 2.1. Convention and Terminology . . . . . . . . . . . . . . . 3 59 3. Updates to RFC 4210 - Certificate Management Protocol (CMP) . 4 60 3.1. New Section 1.1. - Changes since RFC 4210 . . . . . . . . 4 61 3.2. New Section 4.5 - Extended Key Usage . . . . . . . . . . 5 62 3.3. Replace Section 5.1.3.4 - Multiple Protection . . . . . . 7 63 3.4. Replace Section 5.2.2. - Encrypted Values . . . . . . . . 8 64 3.5. Update Section 5.3.4. - Certification Response . . . . . 9 65 3.6. Replace Section 5.3.19.9. - Revocation Passphrase . . . . 10 66 3.7. Update Section 5.3.22 - Polling Request and Response . . 10 67 3.8. Update Appendix B - The Use of Revocation Passphrase . . 11 68 3.9. Update Appendix C - Request Message Behavioral 69 Clarifications . . . . . . . . . . . . . . . . . . . . . 12 70 3.10. Update Appendix D.4. - Initial Registration/Certification 71 (Basic Authenticated Scheme) . . . . . . . . . . . . . . 13 72 4. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 13 73 5. Security Considerations . . . . . . . . . . . . . . . . . . . 13 74 6. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 13 75 7. References . . . . . . . . . . . . . . . . . . . . . . . . . 14 76 7.1. Normative References . . . . . . . . . . . . . . . . . . 14 77 7.2. Informative References . . . . . . . . . . . . . . . . . 15 78 Appendix A. ASN.1 Modules . . . . . . . . . . . . . . . . . . . 15 79 Author's Address . . . . . . . . . . . . . . . . . . . . . . . . 16 81 1. History of changes 83 From version 00 -> 01: 85 o Minor changes in wording 87 From draft-brockhaus-lamps-cmp-updates-03 -> draft-ietf-lamps-cmp- 88 updates-00: 90 o Changes required to reflect WG adoption 92 From version 02 -> 03: 94 o Added some clarification in Section 3.1 96 From version 01 -> 02: 98 o Added clarification to section on multiple protection 100 o Added clarification on new EKUs after some exchange with Tomas 101 Gustavsson 103 o Reused OIDs from RFC 6402 [RFC6402] as suggested by Sean Turner at 104 IETF 106 106 o Added clarification on the field containing the key identifier for 107 a revocation passphrase 109 o Minor changes in wording 111 From version 00 -> 01: 113 o Added a section describing the new extended key usages 115 o Completed the section on changes to the specification of encrypted 116 values 118 o Added a section on clarification to Appendix D.4 120 o Minor generalization in RFC 4210 [RFC4210] Sections 5.1.3.4 and 121 5.3.22 123 o Minor changes in wording 125 2. Introduction 127 While using CMP [RFC4210] in industrial and IoT environments and 128 developing the Lightweight CMP Profile 129 [I-D.ietf-lamps-lightweight-cmp-profile] some limitations were 130 identified in the original CMP specification. This document updates 131 RFC 4210 [RFC4210] to overcome these limitations. 133 In general, this document aims to improve the crypto agility of CMP 134 to be flexible to react on future advances in cryptography. 136 This document also introduces new extended key usages to identify CMP 137 endpoints on registration and certification authorities. 139 2.1. Convention and Terminology 141 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 142 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 143 document are to be interpreted as described in RFC 2119 [RFC2119]. 145 In this document, these words will appear with that interpretation 146 only when in ALL CAPS. Lower case uses of these words are not to be 147 interpreted as carrying significance described in RFC 2119. 149 Technical terminology is used in conformance with RFC 4210 [RFC4210], 150 RFC 4211 [RFC4211], and RFC 5280 [RFC5280]. The following key words 151 are used: 153 CA: Certification authority, which issues certificates. 155 RA: Registration authority, an optional system component to which a 156 CA delegates certificate management functions such as 157 authorization checks. 159 KGA: Key generation authority, which generates key pairs on behalf of 160 an EE. The KGA could be co-located with an RA or a CA. 162 EE: End entity, a user, device, or service that holds a PKI 163 certificate. An identifier for the EE is given as its subject 164 of the certificate. 166 3. Updates to RFC 4210 - Certificate Management Protocol (CMP) 168 3.1. New Section 1.1. - Changes since RFC 4210 170 The following subsection describes feature updates to RFC 4210 171 [RFC4210]. They are always related to the base specification. Hence 172 references to the original sections in RFC 4210 [RFC4210] are used 173 whenever possible. 175 Insert this section at the end of the current Section 1. 177 1.1 Changes since RFC 4210 179 The following updates are made in draft-ietf-lamps-cmp-updates: 181 o Add new extended key usages for different CMP server types, e.g. 182 registration authority and certification authority, to express the 183 authorization of the entity identified in the certificate 184 containing the respective extended key usage extension to act as 185 the indicated PKI management entity. 187 o Extend the description of multiple protection to cover additional 188 use cases, e.g., batch processing of messages. 190 o Offering EnvelopedData as the prefered choice next to 191 EncryptedValue to extend crypto agility in CMP. Note that 192 according to RFC 4211 [RFC4211] section 2.1.9 the use of the 193 EncryptedValue structure has been deprecated in favor of the 194 EnvelopedData structure. RFC 4211 [RFC4211] offers the 195 EncryptedKey structure, a choice of EncryptedValue and 196 EnvelopedData for migration to EnvelopedData. For reasons of 197 completeness and consistency the exchange of EncryptedValue is 198 performed for all usages in RFC 4210 [RFC4210]. This includes the 199 protection of centrally generated private keys, encryption of 200 certificates, and revocation passphrases. 202 o Extend the usage of polling also to p10cr messages. 204 3.2. New Section 4.5 - Extended Key Usage 206 The following subsection describes new extended key usages for 207 different CMP server typesspecitied in RFC 4210 [RFC4210]. 209 Insert this section at the end of the current Section 4. 211 4.5 Extended Key Usage 213 The Extended Key Usage (EKU) extension indicates the purposes for 214 which the certified public key may be used. It therefore restricts 215 the use of a certificate to specific applications. 217 A CA may want to delegate parts of their duties to other PKI 218 management entities. The mechanism to prove this delegation 219 explained in this section offers zero-touch means to check the 220 authorization of such delegation. Such delegation could also be 221 expressed by other means, e.g., explicit configuration. 223 To offer automatic validation means for the delegation of a role by a 224 CA, the certificates used by PKI management entities for CMP message 225 protection or signed data for central key generation MUST be issued 226 by the delegating CA and MUST contain the respective EKUs. This 227 proves the authorization of this entity by the delegating CA to act 228 as the PKI management entity as described below. 230 The ASN.1 to define these EKUs is: 232 id-kp-cmpCA OBJECT IDENTIFIER ::= { id-kp 27 } 233 id-kp-cmpRA OBJECT IDENTIFIER ::= { id-kp 28 } 234 id-kp-cmpKGA OBJECT IDENTIFIER ::= { id-kp ... } 236 < TBD: id-kp-cmpKGA to be defined. > 238 Note: RFC 6402 section 2.10 [RFC6402] specifies OIDs for a CMC CA and 239 a CMC RA. As the functionality of a CA and RA is not specific to 240 whether use CMC or CMP as certificate management protocol, the same 241 OIDs SHALL be used for a cmpCA and a cmpRA. 243 < TBD: It needs to be clarified, if the Name and Description of the 244 OIDs can be adapted or extended to avoid confusion as they currently 245 only refer to CMC endpoints. > 247 The description of the PKI management entity for each of the EKUs is 248 as follows: 250 cmpCA: CMP Certification Authorities are CMP endpoints on CA 251 equipment as described in section 3.1.1.2. The key used in 252 the context of CMP management operations, especially CMP 253 message protection, need not be the same key that signs the 254 certificates. It is necessary, however, to ensure that the 255 entity acting as cmpCA is authorized to do so. Therefore, 256 the cmpCA MUST do one of the following, 258 * use the CA private key on the CMP endpoint, or 260 * explicitly designate this authority to another entity. 262 For automatic validation of such delegation it MUST be 263 indicated by the id-kp-cmpCA extended key usage. This 264 extended key usage MUST be placed into the certificate used 265 on the CA equipment and the CA that delegates this role MUST 266 issue the cmpCA certificate. 268 Note: Using a separate key pair for protecting CMP management 269 operations at the CA decreases the number of operations of 270 the private key used to sign certificates. 272 cmpRA: CMP Registration Authorities are CMP endpoints on RA 273 equipment as described in Section 3.1.1.3. A cmpRA is 274 identified by the id-kp-cmpRA extended key usage. This 275 extended key usage is placed into RA certificates. The CA 276 that delegated this role is identified by the CA that issued 277 the cmpRA certificate. 279 cmpKGA: CMP Key Generation Authorities are identified by the id-kp- 280 cmpKGA extended key usage. Though the cmpKGA knows the 281 private key it generated on behalf of the end entity. This 282 is a very sensible service and needs specific authorization. 283 This authorization is either with the CA certificate itself, 284 or indicated by placing the id-kp-cmpKGA extended key usage 285 into the cmpRA or cmpCA certificate used to authenticate the 286 origin of the private key, and to express the authorization 287 to offer this service. 289 Note: In device PKIs, especially those issuing IDevID certificates, 290 CA may have very long validity (including the GeneralizedTime value 291 99991231235959Z to indicate a not well-defined expiration date as 292 specified in IEEE 802.1AR Section 8.5 [IEEE802.1AR] and RFC 5280 293 Section 4.1.2.5 [RFC5280]). Such validity periods SHOULD NOT be used 294 for protection of CMP messages. Certificates for delegated CMP 295 message protection (cmpCA, cmpRA, cmpKGA) MUST NOT use indefinite 296 expiration date. 298 3.3. Replace Section 5.1.3.4 - Multiple Protection 300 Section 5.1.3.4 of RFC 4210 [RFC4210] describes the nested message. 301 This document opens the usage of nested messages also for batch 302 transport of PKI messages between different PKI management entities. 304 Replace the text of the section with the following text. 306 In cases where an end entity sends a protected PKI message to an RA, 307 the RA MAY forward that message to a CA, adding its own protection 308 (which MAY be a MAC or a signature, depending on the information and 309 certificates shared between the RA and the CA). There are different 310 use cases for such multi protected messages. 312 o The RA confirms the validation and authorization of a message and 313 forwards the original message unchanged. 315 o The RA collects several messages and forwards them in a batch. 316 This can for instance be used to bridge an off-line connection 317 between two PKI management entities. In communication to the CA 318 request messages and in communication from the CA response or 319 announcement messages will be collected in such batch. 321 o The RA modifies the message(s) in some way (e.g., add or modify 322 particular field values or add new extensions) before forwarding 323 them, then it MAY create its own desired PKIBody. In case the 324 changes made by the RA to PKIMessage breaks the POP, the RA MUST 325 either set the POP RAVerified or include the original PKIMessage 326 from the EE in the generalInfo field of PKIHeader of the nested 327 message (to force the CA to check POP on the original message). 328 The infoType to be used in this situation is {id-it 15} (see 329 Section 5.3.19 for the value of id-it) and the infoValue is 330 PKIMessages (contents MUST be in the same order as the requests in 331 PKIBody). For simplicity reasons, if batching is used in 332 combination with inclusion of the original PKIMessage in the 333 generalInfo field, all messages in the batch MUST be of the same 334 type (e.g., ir). 336 These use cases are accomplished by nesting the messages sent by the 337 PKI entity within a new PKI message. The structure used is as 338 follows. 340 NestedMessageContent ::= PKIMessages 342 (The use of PKIMessages, a SEQUENCE OF PKIMessage, lets the RA batch 343 the requests of several EEs in a single new message.) 345 3.4. Replace Section 5.2.2. - Encrypted Values 347 Section 5.2.2 of RFC 4210 [RFC4210] describes the usage of 348 EncryptedValue to transport encrypted data. This document extends 349 the encryption of data to preferably use EnvelopedData. 351 Replace the text of the section with the following text. 353 Where encrypted data (restricted, in this specification, to be either 354 private keys, certificates, or passwords) are sent in PKI messages, 355 the EncryptedKey data structure is used. 357 EncryptedKey ::= CHOICE { 358 encryptedValue EncryptedValue, -- deprecated 359 envelopedData [0] EnvelopedData } 361 See CRMF [RFC4211] for EncryptedKey and EncryptedValue syntax and for 362 EnvelopedData syntax see CMS [RFC5652]. Using the EncryptedKey data 363 structure, the choice to either use EncryptedValue (for backward 364 compatibility only) or EnvelopedData is offered. The use of the 365 EncryptedValue structure has been deprecated in favor of the 366 EnvelopedData structure. Therefore, it is recommended to use 367 EnvelopedData. 369 The EncryptedKey data structure is used in CMP to either transport a 370 private key, certificate or revocation passphrase in encrypted form. 372 EnvelopedData is used as follows: 374 o Contains only one recepientInfo structure because the content is 375 encrypted only for one recipient. 377 o Contains a private key in a SignedData structure as specified in 378 CMS section 5 [RFC5652] signed by the Key Generation Authority. 380 o Contains a certificate or revocation passphrase directly in the 381 encryptedContent field. 383 Note: When transferring a centrally generated private key in a 384 certificate response message to the EE, the algorithm identifier and 385 the associated public key will anyhow be transported in this response 386 message. Therefore, the private key will not be delivered in a key 387 package structure as specified in [RFC5958] and [RFC6032]. But the 388 wrapping of the private key in a SignedData structure that is wrapped 389 in the EnvelopedData structure as specified in [RFC6032] is applied. 391 The content of the EnvelopedData structure, as specified in CMS 392 section 3 [RFC5652], MUST be encrypted using a newly generated 393 symmetric content-encryption key. This content-encryption key MUST 394 be securely provided to the recipient using one of three key 395 management techniques. 397 The choice of the key management technique to be used by the sender 398 depends on the credential available for the recipient: 400 o Jointly shared secret: The content-encryption key will be 401 protected using the symmetric key-encryption key management 402 technique, as specified in CMS section 5.2.3 [RFC5652]. 404 o Recipient's certificate that contains a key usage extension 405 asserting keyAgreement: The content-encryption key will be 406 protected using the key agreement key management technique, as 407 specified in CMS section 5.2.2 [RFC5652]. 409 o Recipient's certificate that contains a key usage extension 410 asserting keyEncipherment: The content-encryption key will be 411 protected using the key transport key management technique, as 412 specified in CMS section 5.2.1 [RFC5652]. 414 3.5. Update Section 5.3.4. - Certification Response 416 Section 5.3.4 of RFC 4210 [RFC4210] describes the Certification 417 Response. This document updates the syntax by using the parent 418 structure EncryptedKey instead of EncryptedValue as described in 419 Section 3.1 above. 421 Replace the ASN.1 syntax of CertifiedKeyPair and CertOrEncCert with 422 the following text. 424 CertifiedKeyPair ::= SEQUENCE { 425 certOrEncCert CertOrEncCert, 426 privateKey [0] EncryptedKey OPTIONAL, 427 -- see [CRMF] for comment on encoding 428 publicationInfo [1] PKIPublicationInfo OPTIONAL 429 } 431 CertOrEncCert ::= CHOICE { 432 certificate [0] Certificate, 433 encryptedCert [1] EncryptedKey 434 } 436 Add the following paragraphs to the end of the section. 438 The use of EncryptedKey is described in section 5.2.2. 440 3.6. Replace Section 5.3.19.9. - Revocation Passphrase 442 Section 5.3.19.9 of RFC 4210 [RFC4210] describes the provisioning of 443 a revocation passphrase for authenticating a later revocation 444 request. This document updates the handling by using the parent 445 structure EncryptedKey instead of EncryptedValue to transport this 446 information as described in Section 3.1 above. 448 Replace the text of the section with the following text. 450 This MAY be used by the EE to send a passphrase to a CA/RA for the 451 purpose of authenticating a later revocation request (in the case 452 that the appropriate signing private key is no longer available to 453 authenticate the request). See Appendix B for further details on the 454 use of this mechanism. 456 GenMsg: {id-it 12}, EncryptedKey 457 GenRep: {id-it 12}, < absent > 459 The use of EncryptedKey is described in section 5.2.2. 461 3.7. Update Section 5.3.22 - Polling Request and Response 463 Section 5.3.22 of RFC 4210 [RFC4210] describes when and how polling 464 messages are used. This document adds the polling mechanism also to 465 outstanding p10cr transactions. 467 Replace all paragraphs in front of the state machine diagram with the 468 following text. 470 This pair of messages is intended to handle scenarios in which the 471 client needs to poll the server in order to determine the status of 472 an outstanding ir, cr, p10cr, or kur transaction (i.e., when the 473 "waiting" PKIStatus has been received). 475 PollReqContent ::= SEQUENCE OF SEQUENCE { 476 certReqId INTEGER } 478 PollRepContent ::= SEQUENCE OF SEQUENCE { 479 certReqId INTEGER, 480 checkAfter INTEGER, -- time in seconds 481 reason PKIFreeText OPTIONAL } 483 The following clauses describe when polling messages are used, and 484 how they are used. It is assumed that multiple certConf messages can 485 be sent during transactions. There will be one sent in response to 486 each ip, cp, or kup that contains a CertStatus for an issued 487 certificate. 489 1 In response to an ip, cp, or kup message, an EE will send a 490 certConf for all issued certificates and, following the ack, a 491 pollReq for all pending certificates. 493 2 In response to a pollReq, a CA/RA will return an ip, cp, or kup if 494 one or more of the pending certificates is ready; otherwise, it 495 will return a pollRep. 497 3 If the EE receives a pollRep, it will wait for at least as long as 498 the checkAfter value before sending another pollReq. 500 4 If an ip, cp, or kup is received in response to a pollReq, then it 501 will be treated in the same way as the initial response. 503 Note: A p10cr message contains exactly one CertificationRequestInfo 504 data structure as specified in PKCS#10 [RFC2986] but no certificate 505 request number. Therefore, the certReqId MUST be set to 0 in all 506 following messages of this transaction. 508 3.8. Update Appendix B - The Use of Revocation Passphrase 510 Appendix B of RFC 4210 [RFC4210] describes the usage of the 511 revocation passphrase. As this document updates RFC 4210 [RFC4210] 512 to utilize the parent structure EncryptedKey instead of 513 EncryptedValue as described in Section 3.1 above, the description is 514 updated accordingly. 516 Replace the first bullet point of this section with the following 517 text. 519 o The OID and value specified in Section 5.3.19.9 of RFC 4210 520 [RFC4210] MAY be sent in a GenMsg message at any time, or MAY be 521 sent in the generalInfo field of the PKIHeader of any PKIMessage 522 at any time. (In particular, the EncryptedKey as described in 523 section 5.2.2 may be sent in the header of the certConf message 524 that confirms acceptance of certificates requested in an 525 initialization request or certificate request message.) This 526 conveys a revocation passphrase chosen by the entity (i.e., for 527 use of EnvelopedData this is in the decrypted bytes of 528 encryptedContent field and for use of EncryptedValue this is in 529 the decrypted bytes of the encValue field) to the relevant CA/RA; 530 furthermore, the transfer is accomplished with appropriate 531 confidentiality characteristics. 533 Replace the third bullet point of this section with the following 534 text. 536 o When using EnvelopedData the unprotectedAttrs and when using 537 EncryptedValue the valueHint field MAY contain a key identifier 538 (chosen by the entity, along with the passphrase itself) to assist 539 in later retrieval of the correct passphrase (e.g., when the 540 revocation request is constructed by the entity and received by 541 the CA/RA). 543 < TBD: The attribute structure containing the key identifier in the 544 unprotectedAttr field could either be pkcs-9-at-friendlyName or pkcs- 545 9-at-localKeyId as specified in RFC 2985 section 5.5 [RFC2985]. Are 546 there preferences for either one? > 548 3.9. Update Appendix C - Request Message Behavioral Clarifications 550 Appendix C of RFC 4210 [RFC4210] provides clarifications to the 551 request message behavior. As this document updates RFC 4210 552 [RFC4210] to utilize the parent structure EncryptedKey instead of 553 EncryptedValue as described in Section 3.1 above, the description is 554 updated accordingly. 556 Replace the note coming after the ASN.1 syntax of POPOPrivKey of this 557 section with the following text. 559 -- ********** 560 -- * the type of "thisMessage" is given as BIT STRING in RFC 4211 561 -- * [RFC4211]; it should be "EncryptedKey" (in accordance with 562 -- * Section 5.2.2 of this specification). Therefore, this document 563 -- * makes the behavioral clarification of specifying that the 564 -- * contents of "thisMessage" MUST be encoded either as 565 -- * "EnvelopedData" or "EncryptedValue" (only for backward 566 -- * compatibility) and then wrapped in a BIT STRING. This allows 567 -- * the necessary conveyance and protection of the private key 568 -- * while maintaining bits-on-the-wire compatibility with RFC 4211 569 -- * [RFC4211]. 570 -- ********** 572 3.10. Update Appendix D.4. - Initial Registration/Certification (Basic 573 Authenticated Scheme) 575 Appendix D.4 of RFC 4210 [RFC4210] provides the initial registration/ 576 certification scheme. This scheme shall continue to use 577 EncryptedValue for backward compatibility reasons. 579 Replace the comment after the privateKey field of 580 crc[1].certifiedKeyPair in the syntax of the Initialization Response 581 message with the following text. 583 -- see Appendix C, Request Message Behavioral Clarifications 584 -- for backward compatibility reasons, use EncryptedValue 586 4. IANA Considerations 588 < TBD: Add any IANA considerations > 590 5. Security Considerations 592 No changes are made to the existing security considerations of 593 RFC 4210 [RFC4210]. 595 6. Acknowledgements 597 Special thank goes to Jim Schaad for his guidance and the inspiration 598 on structuring and writing this document I got from [RFC6402] that 599 updates CMC. 601 I also like to thank all reviewers of this document for their 602 valuable feedback. 604 7. References 606 7.1. Normative References 608 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 609 Requirement Levels", BCP 14, RFC 2119, 610 DOI 10.17487/RFC2119, March 1997, 611 . 613 [RFC2985] Nystrom, M. and B. Kaliski, "PKCS #9: Selected Object 614 Classes and Attribute Types Version 2.0", RFC 2985, 615 DOI 10.17487/RFC2985, November 2000, 616 . 618 [RFC2986] Nystrom, M. and B. Kaliski, "PKCS #10: Certification 619 Request Syntax Specification Version 1.7", RFC 2986, 620 DOI 10.17487/RFC2986, November 2000, 621 . 623 [RFC4210] Adams, C., Farrell, S., Kause, T., and T. Mononen, 624 "Internet X.509 Public Key Infrastructure Certificate 625 Management Protocol (CMP)", RFC 4210, 626 DOI 10.17487/RFC4210, September 2005, 627 . 629 [RFC4211] Schaad, J., "Internet X.509 Public Key Infrastructure 630 Certificate Request Message Format (CRMF)", RFC 4211, 631 DOI 10.17487/RFC4211, September 2005, 632 . 634 [RFC5280] Cooper, D., Santesson, S., Farrell, S., Boeyen, S., 635 Housley, R., and W. Polk, "Internet X.509 Public Key 636 Infrastructure Certificate and Certificate Revocation List 637 (CRL) Profile", RFC 5280, DOI 10.17487/RFC5280, May 2008, 638 . 640 [RFC5652] Housley, R., "Cryptographic Message Syntax (CMS)", STD 70, 641 RFC 5652, DOI 10.17487/RFC5652, September 2009, 642 . 644 [RFC6402] Schaad, J., "Certificate Management over CMS (CMC) 645 Updates", RFC 6402, DOI 10.17487/RFC6402, November 2011, 646 . 648 7.2. Informative References 650 [I-D.ietf-lamps-lightweight-cmp-profile] 651 Brockhaus, H., Fries, S., and D. Oheimb, "Lightweight CMP 652 Profile", draft-ietf-lamps-lightweight-cmp-profile-00 653 (work in progress), February 2020. 655 [RFC5958] Turner, S., "Asymmetric Key Packages", RFC 5958, 656 DOI 10.17487/RFC5958, August 2010, 657 . 659 [RFC6032] Turner, S. and R. Housley, "Cryptographic Message Syntax 660 (CMS) Encrypted Key Package Content Type", RFC 6032, 661 DOI 10.17487/RFC6032, December 2010, 662 . 664 Appendix A. ASN.1 Modules 666 Changes to the following parts are needed 668 o Import from PKCS-9 670 friendlyName, localKeyId 671 FROM PKCS-9 {iso(1) member-body(2) us(840) rsadsi(113549) pkcs(1) 672 pkcs-9(9) modules(0) pkcs-9(1)} 674 < TBD: Either friendlyName or localKeyId need to be imported here. > 676 o Import from PKIKXCRMF-2005 678 CertTemplate, PKIPublicationInfo, EncryptedKey, CertId, 679 CertReqMessages 680 FROM PKIXCRMF-2005 {iso(1) identified-organization(3) 681 dod(6) internet(1) security(5) mechanisms(5) pkix(7) 682 id-mod(0) id-mod-crmf2005(36)} 684 o In CertifiedKeyPair, CertOrEncCert and id-it-revPassphrase 685 CertifiedKeyPair ::= SEQUENCE { 686 certOrEncCert CertOrEncCert, 687 privateKey [0] EncryptedKey OPTIONAL, 688 -- see [CRMF] for comment on encoding 689 publicationInfo [1] PKIPublicationInfo OPTIONAL 690 } 692 CertOrEncCert ::= CHOICE { 693 certificate [0] CMPCertificate, 694 encryptedCert [1] EncryptedKey 695 } 697 -- id-it-revPassphrase OBJECT IDENTIFIER ::= {id-it 12} 698 -- RevPassphraseValue ::= EncryptedKey 700 -- 701 -- Extended Key Usage extension for PKI entities used in 702 -- CMP operations 703 -- 705 id-kp-cmpCA OBJECT IDENTIFIER ::= { id-kp 27 } 706 id-kp-cmpRA OBJECT IDENTIFIER ::= { id-kp 28 } 707 id-kp-cmpKGA OBJECT IDENTIFIER ::= { id-kp ... } 709 < TBD: id-kp-cmpKGA to be defined. > 711 < TBD: If needed the complete ASN.1 Module from RFC 4210 section 712 needs to be copied here. > 714 Author's Address 716 Hendrik Brockhaus 717 Siemens AG 718 Otto-Hahn-Ring 6 719 Munich 81739 720 Germany 722 Email: hendrik.brockhaus@siemens.com 723 URI: http://www.siemens.com/