idnits 2.17.1 draft-brockhaus-lamps-cmp-updates-03.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- No issues found here. Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- No issues found here. Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- No issues found here. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust and authors Copyright Line does not match the current year (Using the creation date from RFC4210, updated by this document, for RFC5378 checks: 2000-03-07) -- The document seems to lack a disclaimer for pre-RFC5378 work, but may have content which was first submitted before 10 November 2008. If you have contacted all the original authors and they are all willing to grant the BCP78 rights to the IETF Trust, then this is fine, and you can ignore this comment. If not, you may need to add the pre-RFC5378 disclaimer. (See the Legal Provisions document at https://trustee.ietf.org/license-info for more information.) -- The document date (January 28, 2020) is 1543 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 258, but not defined -- Looks like a reference, but probably isn't: '0' on line 670 == Missing Reference: 'CRMF' is mentioned on line 665, but not defined -- Looks like a reference, but probably isn't: '1' on line 671 ** Downref: Normative reference to an Informational RFC: RFC 2985 ** Downref: Normative reference to an Informational RFC: RFC 2986 == Outdated reference: A later version (-03) exists of draft-brockhaus-lamps-lightweight-cmp-profile-02 Summary: 2 errors (**), 0 flaws (~~), 4 warnings (==), 4 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 Internet Engineering Task Force H. Brockhaus 3 Internet-Draft Siemens 4 Updates: 4210 (if approved) January 28, 2020 5 Intended status: Standards Track 6 Expires: July 31, 2020 8 CMP Updates 9 draft-brockhaus-lamps-cmp-updates-03 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 July 31, 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 version 02 -> 03: 85 o Added some clarification in Section 3.1. 87 From version 01 -> 02: 89 o Added clarification to section on multiple protection 91 o Added clarification on new EKUs after some exchange with Tomas 92 Gustavsson 94 o Reused OIDs from RFC 6402 [RFC6402] as suggested by Sean Turner at 95 IETF 106 97 o Added clarification on the field containing the key identifier for 98 a revocation passphrase 100 o Minor changes in wording 102 From version 00 -> 01: 104 o Added a section describing the new extended key usages 106 o Completed the section on changes to the specification of encrypted 107 values 109 o Added a section on clarification to Appendix D.4 111 o Minor generalization in RFC 4210 [RFC4210] Sections 5.1.3.4 and 112 5.3.22 114 o Minor changes in wording 116 2. Introduction 118 While using CMP [RFC4210] in industrial and IoT environments and 119 developing the Lightweight CMP Profile 120 [I-D.brockhaus-lamps-lightweight-cmp-profile] some limitations were 121 identified in the original CMP specification. This document updates 122 RFC 4210 [RFC4210] to overcome these limitations. 124 In general, this document aims to improve the crypto agility of CMP 125 to be flexible to react on future advances in cryptography. 127 This document also introduces new extended key usages to identify CMP 128 endpoints on registration and certification authorities. 130 2.1. Convention and Terminology 132 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 133 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 134 document are to be interpreted as described in RFC 2119 [RFC2119]. 136 In this document, these words will appear with that interpretation 137 only when in ALL CAPS. Lower case uses of these words are not to be 138 interpreted as carrying significance described in RFC 2119. 140 Technical terminology is used in conformance with RFC 4210 [RFC4210], 141 RFC 4211 [RFC4211], and RFC 5280 [RFC5280]. The following key words 142 are used: 144 CA: Certification authority, which issues certificates. 146 RA: Registration authority, an optional system component to which a 147 CA delegates certificate management functions such as 148 authorization checks. 150 KGA: Key generation authority, which generates key pairs on behalf of 151 an EE. The KGA could be co-located with an RA or a CA. 153 EE: End entity, a user, device, or service that holds a PKI 154 certificate. An identifier for the EE is given as its subject 155 of the certificate. 157 3. Updates to RFC 4210 - Certificate Management Protocol (CMP) 159 3.1. New Section 1.1. - Changes since RFC 4210 161 The following subsections describe feature updates to RFC 4210 162 [RFC4210]. They are always related to the base specification. Hence 163 references to the original sections in RFC 4210 [RFC4210] are used 164 whenever possible. 166 Insert this section at the end of the current Section 1. 168 The following updates are made in draft-brockhaus-lamps-cmp-updates: 170 o Add new extended key usages for different CMP server types, e.g. 171 registration authority and certification authority, to express the 172 authorization of the entity identified in the certificate 173 containing the respective extended key usage extension to act as 174 the indicated PKI management component. 176 o Extend the description of multiple protection to cover additional 177 use cases, e.g., batch processing of messages. 179 o Offering EnvelopedData as another choice next to EncryptedValue to 180 extend crypto agility in CMP. Note that according to RFC 4211 181 [RFC4211] section 2.1.9 the use of the EncryptedValue structure 182 has been deprecated in favor of the EnvelopedData structure. For 183 reasons of completeness and consistency the exchange of 184 EncryptedValue with EncryptedKey is performed not only where 185 required for the needed crypto agility for protection of centrally 186 generated private keys, but also for other purposes like 187 encryption of certificates and revocation passphrases. 189 o Extend the usage of polling also to p10cr messages. 191 3.2. New Section 4.5 - Extended Key Usage 193 Insert this section. 195 The Extended Key Usage (EKU) extension indicates the purposes for 196 which the certified public key may be used. It therefore restricts 197 the use of a certificate to specific applications. Certificates used 198 for CMP message protection or signed data for central key generation 199 SHOULD use one of the following EKUs to express its authorization for 200 acting as the PKI management entities described below. The ASN.1 to 201 define these EKUs is: 203 id-kp-cmpCA OBJECT IDENTIFIER ::= { id-kp 27 } 204 id-kp-cmpRA OBJECT IDENTIFIER ::= { id-kp 28 } 205 id-kp-cmpKGA OBJECT IDENTIFIER ::= { id-kp ... } 207 < TBD: id-kp-cmpKGA to be defined. > 209 Note: RFC 6402 section 2.10 [RFC6402] specifies OIDs for a CMC CA and 210 a CMC RA. As the functionality of a CA and RA is not specific to 211 whether use CMC or CMP as certificate management protocol, the same 212 OIDs SHALL be used for a cmpCA and a cmpRA. 214 < TBD: It needs to be clarified, if the Name and Description of the 215 OIDs can be adapted or extended to avoid confusion as they currently 216 only refer to CMC endpoints. > 218 The description of the PKI entity for each of the EKUs is as follows: 220 CMP Certification Authorities are CMP endpoints on CA equipment as 221 described in section 3.1.1.2. The key used in the context of CMP 222 management operations, especially CMP message protection, need not be 223 the same key that signs the certificates. It is necessary, however, 224 to ensure that the entity acting as cmpCA is authorized to do so. 225 Therefore, the cmpCA MUST do one of the following, 227 o use the CA private key on the CMP endpoint, or 229 o explicitly designate this authority to another entity. 231 CMP message protection delegation on the CA SHALL be designated by 232 the inclusion of id-kp-cmpCA in an extended key usage certificate 233 extension included in the CMP response signer's certificate. This 234 certificate MUST be issued directly by the CA that is identified in 235 the request. 237 Note: Using a separate key pair for protecting CMP management 238 operations at the CA decreases the number of operations of the 239 private key used to sign certificates. 241 CMP Registration Authorities are CMP endpoints on RA equipment as 242 described in section 3.1.1.3. A cmpRA is identified by the id-kp- 243 cmpRA extended key usage. This extended key usage is placed into RA 244 certificates. 246 CMP Key Generation Authorities are identified by the id-kp-cmpKGA 247 extended key usage. Though the cmpKGA knows the private key it 248 generated on behalf of the end entity, this is a very sensible 249 service and needs specific authorization. This authorization is 250 either with the CA certificate itself, or indicated by placing the 251 id-kp-cmpKGA extended key usage into the cmpRA or cmpCA certificate 252 used to authenticate the origin of the private key to express the 253 authorization to offer this service. 255 Note: In device PKIs, especially those issuing IDevID certificates, 256 CA may have very long validity (including the GeneralizedTime value 257 99991231235959Z to indicate an indefinite expiration date as 258 specified in IEEE 802.1AR section 8.5 [IEEE802.1AR] and RFC 5280 259 Section 4.1.2.5 [RFC5280]). Such validity periods SHOULD NOT be used 260 for protection of CMP messages. Certificates for delegated CMP 261 message protection (cmpCA, cmpRA, cmpKGA) MUST NOT use indefinite 262 expiration date. 264 < TBD: In bigger PKI installations the CA equipment may host, and an 265 RA equipment may serve several CAs. These CAs, especially those 266 issuing IDevID certificates may have very long validities and use 267 specific algorithms not suitable for protection of day-to-day PKI 268 management operations on a CMC, CMP or TLS level. Therefore, it may 269 be an advantage to utilize a specific 'Infrastructure' CA for issuing 270 CMC, CMP and TLS certificates to protect PKI management operations 271 for other CAs hosted on that PKI. A mechanism would be needed to 272 securely delegate authorization to act as a cmpCA, cmpRA, or cmpKGA 273 for a specific CA without directly issuing the cmpCA, cmpRA, and 274 cmpKGA certificates. I am happy for any suitable suggestions to 275 address this issue. > 277 3.3. Replace Section 5.1.3.4 - Multiple Protection 279 Section 5.1.3.4 of RFC 4210 [RFC4210] describes the nested message. 280 This document opens the usage of nested messages also for batch 281 transport of PKI messages between different PKI management entities. 283 Replace the text of the section with the following text. 285 In cases where an end entity sends a protected PKI message to an RA, 286 the RA MAY forward that message to a CA, adding its own protection 287 (which MAY be a MAC or a signature, depending on the information and 288 certificates shared between the RA and the CA). There are different 289 use cases for such multi protected messages. 291 o The RA confirms the validation and authorization of a message and 292 forwards the original message unchanged. 294 o The RA collects several messages and forwards them in a batch. 295 This can for instance be used to bridge an off-line connection 296 between two PKI management entities. In an up-stream connection 297 request messages and in a down-stream connection response or 298 announcement messages will be collected in the batch. 300 o The RA modifies the message(s) in some way (e.g., add or modify 301 particular field values or add new extensions) before forwarding 302 them, then it MAY create its own desired PKIBody. In case the 303 changes made by the RA to PKIMessage breaks the POP, the RA MUST 304 either set the POP RAVerified or include the original PKIMessage 305 from the EE in the generalInfo field of PKIHeader of the nested 306 message (to force the CA to check POP on the original message). 307 The infoType to be used in this situation is {id-it 15} (see 308 Section 5.3.19 for the value of id-it) and the infoValue is 309 PKIMessages (contents MUST be in the same order as the requests in 310 PKIBody). For simplicity reasons, if batching is used in 311 combination with inclusion of the original PKIMessage in the 312 generalInfo field, all messages in the batch MUST be of the same 313 type (e.g., ir). 315 These use cases are accomplished by nesting the messages sent by the 316 end entity within a new PKI message. The structure used is as 317 follows. 319 NestedMessageContent ::= PKIMessages 321 (The use of PKIMessages, a SEQUENCE OF PKIMessage, lets the RA batch 322 the requests of several EEs in a single new message.) 324 3.4. Replace Section 5.2.2. - Encrypted Values 326 Section 5.2.2 of RFC 4210 [RFC4210] describes the usage of 327 EncryptedValue to transport encrypted data. This document extends 328 the encryption of data to also use EnvelopedData. 330 Replace the text of the section with the following text. 332 Where encrypted data (restricted, in this specification, to be either 333 private keys, certificates or passwords) are sent in PKI messages, 334 the EncryptedKey data structure is used. 336 EncryptedKey ::= CHOICE { 337 encryptedValue EncryptedValue, -- deprecated 338 envelopedData [0] EnvelopedData } 340 See CRMF [RFC4211] for EncryptedKey and EncryptedValue syntax and for 341 EnvelopedData syntax see CMS [RFC5652]. Using the EncryptedKey data 342 structure, the choice to either use EncryptedValue (for backward 343 compatibility only) or EnvelopedData is offered. The use of the 344 EncryptedValue structure has been deprecated in favor of the 345 EnvelopedData structure. Therefore, it is recommended to use 346 EnvelopedData. 348 The EncryptedKey data structure is used in CMP to either transport a 349 private key, certificate or revocation passphrase in encrypted form. 351 EnvelopedData is used as follows: 353 o Contains only one recepientInfo structure because the content is 354 encrypted only for one recipient. 356 o Contains private key in a SignedData structure as specified in CMS 357 section 5 [RFC5652] signed by the Key Generation Authority. 359 o Contains certificate or revocation passphrase directly in the 360 encryptedContent field. 362 Note: When transferring a centrally generated private key in a 363 certificate response message to the EE, the algorithm identifier and 364 the associated public key will anyhow be transported in this response 365 message. Therefore, the private key will not be delivered in a key 366 package structure as specified in [RFC5958] and [RFC6032]. But the 367 wrapping of the private key in a SignedData structure that is wrapped 368 in the EnvelopedData structure as specified in [RFC6032] is applied. 370 The content of the EnvelopedData structure, as specified in CMS 371 section 3 [RFC5652], MUST be encrypted using a newly generated 372 symmetric content-encryption key. This content-encryption key MUST 373 be securely provided to the recipient using one of three key 374 management techniques. 376 The choice of the key management technique to be used by the sender 377 depends on the credential available for the recipient: 379 o Jointly shared secret: The content-encryption key will be 380 protected using the symmetric key-encryption key management 381 technique, as specified in CMS section 5.2.3 [RFC5652]. 383 o Recipient's certificate that contains a key usage extension 384 asserting keyAgreement: The content-encryption key will be 385 protected using the key agreement key management technique, as 386 specified in CMS section 5.2.2 [RFC5652]. 388 o Recipient's certificate that contains a key usage extension 389 asserting keyEncipherment: The content-encryption key will be 390 protected using the key transport key management technique, as 391 specified in CMS section 5.2.1 [RFC5652]. 393 3.5. Update Section 5.3.4. - Certification Response 395 Section 5.3.4 of RFC 4210 [RFC4210] describes the Certification 396 Response. This document updates the syntax by using EncryptedKey 397 instead of EncryptedValue as described in Section 3.1 above. 399 Replace the ASN.1 syntax of CertifiedKeyPair and CertOrEncCert with 400 the following text. 402 CertifiedKeyPair ::= SEQUENCE { 403 certOrEncCert CertOrEncCert, 404 privateKey [0] EncryptedKey OPTIONAL, 405 -- see [CRMF] for comment on encoding 406 publicationInfo [1] PKIPublicationInfo OPTIONAL 407 } 409 CertOrEncCert ::= CHOICE { 410 certificate [0] Certificate, 411 encryptedCert [1] EncryptedKey 412 } 414 Add the following paragraphs to the end of the section. 416 The use of EncryptedKey is described in section 5.2.2. 418 3.6. Replace Section 5.3.19.9. - Revocation Passphrase 420 Section 5.3.19.9 of RFC 4210 [RFC4210] describes the provisioning of 421 a revocation passphrase for authenticating a later revocation 422 request. This document updates the handling by using EncryptedKey 423 instead of EncryptedValue to transport this information as described 424 in Section 3.1 above. 426 Replace the text of the section with the following text. 428 This MAY be used by the EE to send a passphrase to a CA/RA for the 429 purpose of authenticating a later revocation request (in the case 430 that the appropriate signing private key is no longer available to 431 authenticate the request). See Appendix B for further details on the 432 use of this mechanism. 434 GenMsg: {id-it 12}, EncryptedKey 435 GenRep: {id-it 12}, < absent > 437 The use of EncryptedKey is described in section 5.2.2. 439 3.7. Update Section 5.3.22 - Polling Request and Response 441 Section 5.3.22 of RFC 4210 [RFC4210] describes when and how polling 442 messages are used. This document adds the polling mechanism also to 443 outstanding p10cr transactions. 445 Replace all paragraphs in front of the state machine diagram with the 446 following text. 448 This pair of messages is intended to handle scenarios in which the 449 client needs to poll the server in order to determine the status of 450 an outstanding ir, cr, p10cr, or kur transaction (i.e., when the 451 "waiting" PKIStatus has been received). 453 PollReqContent ::= SEQUENCE OF SEQUENCE { 454 certReqId INTEGER } 456 PollRepContent ::= SEQUENCE OF SEQUENCE { 457 certReqId INTEGER, 458 checkAfter INTEGER, -- time in seconds 459 reason PKIFreeText OPTIONAL } 461 The following clauses describe when polling messages are used, and 462 how they are used. It is assumed that multiple certConf messages can 463 be sent during transactions. There will be one sent in response to 464 each ip, cp, or kup that contains a CertStatus for an issued 465 certificate. 467 1 In response to an ip, cp, or kup message, an EE will send a 468 certConf for all issued certificates and, following the ack, a 469 pollReq for all pending certificates. 471 2 In response to a pollReq, a CA/RA will return an ip, cp, or kup if 472 one or more of the pending certificates is ready; otherwise, it 473 will return a pollRep. 475 3 If the EE receives a pollRep, it will wait for at least as long as 476 the checkAfter value before sending another pollReq. 478 4 If an ip, cp, or kup is received in response to a pollReq, then it 479 will be treated in the same way as the initial response. 481 Note: A p10cr message contains exactly one CertificationRequestInfo 482 data structure as specified in PKCS#10 [RFC2986] but not certificate 483 request number. Therefore, the certReqId MUST be set to 0 in all 484 following messages of this transaction. 486 3.8. Update Appendix B - The Use of Revocation Passphrase 488 Appendix B of RFC 4210 [RFC4210] describes the usage of the 489 revocation passphrase. As this document updates RFC 4210 [RFC4210] 490 to utilize EncryptedKey instead of EncryptedValue as described in 491 Section 3.1 above, the description is updated accordingly. 493 Replace the first bullet point of this section with the following 494 text. 496 o The OID and value specified in Section 5.3.19.9 of RFC 4210 497 [RFC4210] MAY be sent in a GenMsg message at any time, or MAY be 498 sent in the generalInfo field of the PKIHeader of any PKIMessage 499 at any time. (In particular, the EncryptedKey as described in 500 section 5.2.2 may be sent in the header of the certConf message 501 that confirms acceptance of certificates requested in an 502 initialization request or certificate request message.) This 503 conveys a revocation passphrase chosen by the entity (i.e., for 504 use of EnvelopedData this is in the decrypted bytes of 505 encryptedContent of the EnvelopedData structure and for use of 506 EncryptedValue this is in the decrypted bytes of the encValue 507 field) to the relevant CA/RA; furthermore, the transfer is 508 accomplished with appropriate confidentiality characteristics. 510 Replace the third bullet point of this section with the following 511 text. 513 o When using EnvelopedData the unprotectedAttrs and when using 514 EncryptedValue the valueHint field MAY contain a key identifier 515 (chosen by the entity, along with the passphrase itself) to assist 516 in later retrieval of the correct passphrase (e.g., when the 517 revocation request is constructed by the entity and received by 518 the CA/RA). 520 < TBD: The attribute structure containing the key identifier in the 521 unprotectedAttr field could either be pkcs-9-at-friendlyName or pkcs- 522 9-at-localKeyId as specified in RFC 2985 section 5.5 [RFC2985]. Are 523 there preferences for either one? > 525 3.9. Update Appendix C - Request Message Behavioral Clarifications 527 Appendix C of RFC 4210 [RFC4210] provides clarifications to the 528 request message behavior. As this document updates RFC 4210 529 [RFC4210] to utilize EncryptedKey instead of EncryptedValue as 530 described in Section 3.1 above, the description is updated 531 accordingly. 533 Replace the note coming after the ASN.1 syntax of POPOPrivKey of this 534 section with the following text. 536 -- ********** 537 -- * the type of "thisMessage" is given as BIT STRING in RFC 4211 538 -- * [RFC4211]; it should be "EncryptedKey" (in accordance with 539 -- * Section 5.2.2, "Encrypted Values", of this specification). 540 -- * Therefore, this document makes the behavioral clarification of 541 -- * specifying that the contents of "thisMessage" MUST be encoded 542 -- * either as EnvelopedData or EncryptedValue (only for backward 543 -- * compatibility) and then wrapped in a BIT STRING. This allows 544 -- * the necessary conveyance and protection of the private key 545 -- * while maintaining bits-on-the-wire compatibility with RFC 4211 546 -- * [RFC4211]. 547 -- ********** 549 3.10. Update Appendix D.4. - Initial Registration/Certification (Basic 550 Authenticated Scheme) 552 Appendix D.4 of RFC 4210 [RFC4210] provides the initial registration/ 553 certification scheme. This scheme shall continue to use 554 EncryptedValue for backward compatibility reasons. 556 Replace the comment after the privateKey field of 557 crc[1].certifiedKeyPair in the syntax of the Initialization Response 558 message with the following text. 560 -- see Appendix C, Request Message Behavioral Clarifications 561 -- for backward compatibility reasons, use EncryptedValue 563 4. IANA Considerations 565 < TBD: Add any IANA considerations > 567 5. Security Considerations 569 No changes are made to the existing security considerations of 570 RFC 4210 [RFC4210]. 572 6. Acknowledgements 574 Special thank goes to Jim Schaad for his guidance and the inspiration 575 on structuring and writing this document I got from [RFC6402] that 576 updates CMC. 578 I also like to thank all reviewers of this document for their 579 valuable feedback. 581 7. References 583 7.1. Normative References 585 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 586 Requirement Levels", BCP 14, RFC 2119, 587 DOI 10.17487/RFC2119, March 1997, 588 . 590 [RFC2985] Nystrom, M. and B. Kaliski, "PKCS #9: Selected Object 591 Classes and Attribute Types Version 2.0", RFC 2985, 592 DOI 10.17487/RFC2985, November 2000, 593 . 595 [RFC2986] Nystrom, M. and B. Kaliski, "PKCS #10: Certification 596 Request Syntax Specification Version 1.7", RFC 2986, 597 DOI 10.17487/RFC2986, November 2000, 598 . 600 [RFC4210] Adams, C., Farrell, S., Kause, T., and T. Mononen, 601 "Internet X.509 Public Key Infrastructure Certificate 602 Management Protocol (CMP)", RFC 4210, 603 DOI 10.17487/RFC4210, September 2005, 604 . 606 [RFC4211] Schaad, J., "Internet X.509 Public Key Infrastructure 607 Certificate Request Message Format (CRMF)", RFC 4211, 608 DOI 10.17487/RFC4211, September 2005, 609 . 611 [RFC5280] Cooper, D., Santesson, S., Farrell, S., Boeyen, S., 612 Housley, R., and W. Polk, "Internet X.509 Public Key 613 Infrastructure Certificate and Certificate Revocation List 614 (CRL) Profile", RFC 5280, DOI 10.17487/RFC5280, May 2008, 615 . 617 [RFC5652] Housley, R., "Cryptographic Message Syntax (CMS)", STD 70, 618 RFC 5652, DOI 10.17487/RFC5652, September 2009, 619 . 621 [RFC6402] Schaad, J., "Certificate Management over CMS (CMC) 622 Updates", RFC 6402, DOI 10.17487/RFC6402, November 2011, 623 . 625 7.2. Informative References 627 [I-D.brockhaus-lamps-lightweight-cmp-profile] 628 Brockhaus, H., Fries, S., and D. Oheimb, "Lightweight CMP 629 Profile", draft-brockhaus-lamps-lightweight-cmp-profile-02 630 (work in progress), December 2019. 632 [RFC5958] Turner, S., "Asymmetric Key Packages", RFC 5958, 633 DOI 10.17487/RFC5958, August 2010, 634 . 636 [RFC6032] Turner, S. and R. Housley, "Cryptographic Message Syntax 637 (CMS) Encrypted Key Package Content Type", RFC 6032, 638 DOI 10.17487/RFC6032, December 2010, 639 . 641 Appendix A. ASN.1 Modules 643 Changes to the following parts are needed 645 o Import from PKCS-9 647 friendlyName, localKeyId 648 FROM PKCS-9 {iso(1) member-body(2) us(840) rsadsi(113549) pkcs(1) 649 pkcs-9(9) modules(0) pkcs-9(1)} 651 < TBD: Either friendlyName or localKeyId need to be imported here. > 653 o Import from PKIKXCRMF-2005 654 CertTemplate, PKIPublicationInfo, EncryptedKey, CertId, 655 CertReqMessages 656 FROM PKIXCRMF-2005 {iso(1) identified-organization(3) 657 dod(6) internet(1) security(5) mechanisms(5) pkix(7) 658 id-mod(0) id-mod-crmf2005(36)} 660 o In CertifiedKeyPair, CertOrEncCert and id-it-revPassphrase 662 CertifiedKeyPair ::= SEQUENCE { 663 certOrEncCert CertOrEncCert, 664 privateKey [0] EncryptedKey OPTIONAL, 665 -- see [CRMF] for comment on encoding 666 publicationInfo [1] PKIPublicationInfo OPTIONAL 667 } 669 CertOrEncCert ::= CHOICE { 670 certificate [0] CMPCertificate, 671 encryptedCert [1] EncryptedKey 672 } 674 -- id-it-revPassphrase OBJECT IDENTIFIER ::= {id-it 12} 675 -- RevPassphraseValue ::= EncryptedKey 677 -- 678 -- Extended Key Usage extension for PKI entities used in 679 -- CMP operations 680 -- 682 id-kp-cmpCA OBJECT IDENTIFIER ::= { id-kp 27 } 683 id-kp-cmpRA OBJECT IDENTIFIER ::= { id-kp 28 } 684 id-kp-cmpKGA OBJECT IDENTIFIER ::= { id-kp ... } 686 < TBD: id-kp-cmpKGA to be defined. > 688 < TBD: If needed the complete ASN.1 Module from RFC 4210 section 689 needs to be copied here. > 691 Author's Address 693 Hendrik Brockhaus 694 Siemens AG 695 Otto-Hahn-Ring 6 696 Munich 81739 697 Germany 699 Email: hendrik.brockhaus@siemens.com 700 URI: http://www.siemens.com/