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