idnits 2.17.1 draft-brockhaus-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 (July 7, 2019) is 1753 days in the past. Is this intentional? Checking references for intended status: Proposed Standard ---------------------------------------------------------------------------- (See RFCs 3967 and 4897 for information about using normative references to lower-maturity documents in RFCs) -- Looks like a reference, but probably isn't: '0' on line 407 == Missing Reference: 'CRMF' is mentioned on line 402, but not defined -- Looks like a reference, but probably isn't: '1' on line 408 == Unused Reference: 'RFC6712' is defined on line 372, but no explicit reference was found in the text Summary: 0 errors (**), 0 flaws (~~), 3 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) July 7, 2019 5 Intended status: Standards Track 6 Expires: January 8, 2020 8 CMP Updates 9 draft-brockhaus-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: 18 Enable protection of server-side key generation using elliptic curve 19 algorithms and the definition of an extended key usage to identify 20 certificates of CMP endpoints on registration authorities and 21 certification authorities. 23 Status of This Memo 25 This Internet-Draft is submitted in full conformance with the 26 provisions of BCP 78 and BCP 79. 28 Internet-Drafts are working documents of the Internet Engineering 29 Task Force (IETF). Note that other groups may also distribute 30 working documents as Internet-Drafts. The list of current Internet- 31 Drafts is at https://datatracker.ietf.org/drafts/current/. 33 Internet-Drafts are draft documents valid for a maximum of six months 34 and may be updated, replaced, or obsoleted by other documents at any 35 time. It is inappropriate to use Internet-Drafts as reference 36 material or to cite them other than as "work in progress." 38 This Internet-Draft will expire on January 8, 2020. 40 Copyright Notice 42 Copyright (c) 2019 IETF Trust and the persons identified as the 43 document authors. All rights reserved. 45 This document is subject to BCP 78 and the IETF Trust's Legal 46 Provisions Relating to IETF Documents 47 (https://trustee.ietf.org/license-info) in effect on the date of 48 publication of this document. Please review these documents 49 carefully, as they describe your rights and restrictions with respect 50 to this document. Code Components extracted from this document must 51 include Simplified BSD License text as described in Section 4.e of 52 the Trust Legal Provisions and are provided without warranty as 53 described in the Simplified BSD License. 55 Table of Contents 57 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2 58 1.1. Convention and Terminology . . . . . . . . . . . . . . . 3 59 2. Updates to RFC 4210 - Certificate Management Protocol (CMP) . 3 60 2.1. New Section 1.1. - Changes since RFC 4210 . . . . . . . . 3 61 2.2. Replace Section 5.2.2. - Encrypted Values . . . . . . . . 4 62 2.3. Update Section 5.3.4. - Certification Response . . . . . 5 63 2.4. Update Section 5.3.19.9. - Revocation Passphrase . . . . 5 64 2.5. Update Appendix B - The Use of Revocation Passphrase . . 6 65 2.6. Update Appendix C - Request Message Behavioral 66 Clarifications . . . . . . . . . . . . . . . . . . . . . 7 67 2.7. Update Appendix D.4. - Request Message Behavioral 68 Clarifications . . . . . . . . . . . . . . . . . . . . . 7 69 2.8. Insert section for EKUs like kp-id-cmpRA definition at an 70 appropriate location. . . . . . . . . . . . . . . . . . . 7 71 3. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 7 72 4. Security Considerations . . . . . . . . . . . . . . . . . . . 8 73 5. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 8 74 6. References . . . . . . . . . . . . . . . . . . . . . . . . . 8 75 6.1. Normative References . . . . . . . . . . . . . . . . . . 8 76 6.2. Informative References . . . . . . . . . . . . . . . . . 9 77 Appendix A. ASN.1 Modules . . . . . . . . . . . . . . . . . . . 9 78 Author's Address . . . . . . . . . . . . . . . . . . . . . . . . 9 80 1. Introduction 82 While using CMP [RFC4210] in industrial and IoT environments and 83 developing the Lightweight CMP Profile 84 [I-D.brockhaus-lamps-industrial-cmp-profile] some limitations were 85 identified in the original CMP specification. This document updates 86 RFC 4210 [RFC4210] to overcome these limitations. 88 In general this document aims to improve the crypto agility of CMP to 89 be flexible to react on future advances in cryptography. 91 This document also introduces a new extended key usage to identify 92 CMP services on registration and certification authorities. 94 < TBD: While implementing CMP we identified some wording that could 95 be more precise. It can be discussed if such wording issued need to 96 be addressed in the context of this document or not. > 98 1.1. Convention and Terminology 100 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 101 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 102 document are to be interpreted as described in RFC 2119 [RFC2119]. 104 In this document, these words will appear with that interpretation 105 only when in ALL CAPS. Lower case uses of these words are not to be 106 interpreted as carrying significance described in RFC 2119. 108 Technical terminology is used in conformance with RFC 4210 [RFC4210], 109 RFC 4211 [RFC4211], and RFC 5280 [RFC5280]. The following key words 110 are used: 112 CA: Certification authority, which issues certificates. 114 RA: Registration authority, an optional system component to which 115 a CA delegates certificate management functions such as 116 authorization checks. 118 EE: End entity, a user or device or service that holds a PKI 119 certificate. An identifier for the EE is given as the 120 subject of the certificate. 122 2. Updates to RFC 4210 - Certificate Management Protocol (CMP) 124 2.1. New Section 1.1. - Changes since RFC 4210 126 The following subsections describe feature updates to RFC 4210 127 [RFC4210]. They are always related to the base specification. Hence 128 references to the original sections in RFC 4210 are used whenever 129 possible. 131 Insert this section at the end of the current Section 1. 133 The following updates were made since RFC 4210: 135 o Offering envelopedData as another choice next to EncryptedValue to 136 extend crypto agility in CMP. . Note that according to RFC 4211 137 [RFC4211] section 2.1.9 the use of the EncryptedValue structure 138 has been deprecated in favor of the EnvelopedData structure. For 139 reasons of completeness and consistency the exchange of 140 EncryptedValue with EncryptedKey is performed not only where 141 required for the needed crypto agility for protection of centrally 142 generated private key, but also for other purposes like encryption 143 of revocation passphrases. 145 o Add new extended key usages for different CMP server types, e.g. 146 Registration authority and certification authority. 148 2.2. Replace Section 5.2.2. - Encrypted Values 150 Section 5.2.2 of RFC 4210 [RFC4210] describes the usage of 151 EncryptedValue to transport encrypted data. 153 Replace the text of the section with the following text. 155 Where encrypted data (restricted, in this specification, to be either 156 private keys, certificates or passwords) are sent in PKI messages, 157 the EncryptedKey data structure is used. 159 EncryptedKey ::= CHOICE { 160 encryptedValue EncryptedValue, -- deprecated 161 envelopedData [0] EnvelopedData } 163 See CRMF [RFC4211] for EncryptedKey and EncryptedValue syntax. 165 Using this data structure, it offers the choice to either use 166 EncryptedValue or EnvelopedData. As EncryptedValue offers only key 167 transport, e.g. using RSA or symmetic encryption, EnvelopedData 168 offers further key management techniques, e.g. key agreement, and 169 more crypto agility. Note that according to RFC 4211 [RFC4211] 170 section 2.1.9 the use of the EncryptedValue structure has been 171 deprecated in favor of the EnvelopedData structure. Therefore, it is 172 recommended to use EnvelopedData. 174 See CMS [RFC5652] for EnvelopedData syntax. 176 Using envelopedData within CMP contains only one recepientInfo 177 structure because the content is encrypted only for one recipient. 179 < TBD: Explain the detailed usage of the different key management 180 techniques (e.g. key transport, key agreement, and previously 181 distributed symmetric key-encryption keys) for encryption of the 182 respective private key, certificate or revocation passphrase as 183 specified for EnvelopedData in section 6 in CMS [RFC5652]. > 185 Use of either EnvelopedData or EncryptedValue (for backward 186 compatibility only) requires that the creator and intended recipient 187 be able to encrypt and decrypt, respectively. Typically, this will 188 mean that the sender and recipient have, or are able to generate, a 189 shared secret key. 191 < TBD: Description of EnvelopedData structure parts which are used 192 and filled to support application in CMP > 193 If EncryptedValue is used by the sender and the recipient of the 194 PKIMessage already possesses a private key usable for decryption, 195 then the encSymmKey field MAY contain a session key encrypted using 196 the recipient's public key. 198 2.3. Update Section 5.3.4. - Certification Response 200 Section 5.3.4 of RFC 4210 [RFC4210] describes the Certification 201 Response. This document updates the syntax by using EncryptedKey 202 instead of EncryptedValue as described in Section 2.1 above. 204 Replace the ASN.1 syntax of CertifiedKeyPair and CertorEncCert with 205 the following text. 207 CertifiedKeyPair ::= SEQUENCE { 208 certOrEncCert CertOrEncCert, 209 privateKey [0] EncryptedKey OPTIONAL, 210 -- see [CRMF] for comment on encoding 211 publicationInfo [1] PKIPublicationInfo OPTIONAL 212 } 214 CertOrEncCert ::= CHOICE { 215 certificate [0] Certificate, 216 encryptedCert [1] EncryptedKey 217 } 219 < Question to Jim Schaad: Simply exchanging EncryptedValue with 220 EncryptedKey is what I understood from our discussion back in April. 221 Is it completely backwards compatible to current ASN.1 Syntax of 222 RFC4210? > 224 Add the following paragraphs to the end of the section. 226 In case EnvelopedData is the choice used for EncryptedKey, the 227 encrypted private key or certificate MUST be placed in the 228 envelopedData encryptedContentInfo encryptedContent OCTET STRING. 229 Note that according to RFC 4211 [RFC4211] section 2.1.9 the use of 230 the EncryptedValue structure has been deprecated in favor of the 231 EnvelopedData structure. 233 2.4. Update Section 5.3.19.9. - Revocation Passphrase 235 Section 5.3.19.9 of RFC 4210 [RFC4210] describes the provisioning of 236 a revocation passphrase for authenticating a later revocation 237 request. This document updates the handling by using EncryptedKey 238 instead of EncryptedValue to transport this information as described 239 in Section 2.1 above. 241 Replace the text of the section with the following text. 243 The revocation passphrase MAY be used by the EE to send a passphrase 244 to a CA/RA for the purpose of authenticating a later revocation 245 request (in the case that the appropriate signing private key is no 246 longer available to authenticate the request). See Appendix B for 247 further details on the use of this mechanism. 249 GenMsg: {id-it 12}, EncryptedKey 250 GenRep: {id-it 12}, < absent > 252 In case EnvelopedData is the choice used for EncryptedKey, the 253 encrypted revocation passphrase MUST be placed in the envelopedData 254 encryptedContentInfo encryptedContent OCTET STRING. Note that 255 according to RFC 4211 [RFC4211] section 2.1.9 the use of the 256 EncryptedValue structure has been deprecated in favor of the 257 EnvelopedData structure. 259 2.5. Update Appendix B - The Use of Revocation Passphrase 261 Appendix B of RFC 4210 [RFC4210] describes the usage of the 262 revocation passphrases. As this document updates RFC 4210 [RFC4210] 263 to utilize EncryptedKey in favor of EncryptedValue as described in 264 Section 2.1 above, the description is updated accordingly. 266 Replace the first bullet point of this section with the following 267 text. 269 o The OID and value specified in Section 5.3.19.9 of RFC 4210 270 [RFC4210] MAY be sent in a GenMsg message at any time, or MAY be 271 sent in the generalInfo field of the PKIHeader of any PKIMessage 272 at any time. (In particular, the EncryptedKey may be sent in the 273 header of the certConf message that confirms acceptance of 274 certificates requested in an initialization request or certificate 275 request message.) This conveys a revocation passphrase chosen by 276 the entity (i.e., and for use of EnvelopedData this is in the 277 decrypted bytes of encryptedContent of the EnvelopedData structure 278 and for use of EncryptedValue this is in the decrypted bytes of 279 the encValue field) to the relevant CA/RA; furthermore, the 280 transfer is accomplished with appropriate confidentiality 281 characteristics. Note that according to RFC 4211 [RFC4211] 282 section 2.1.9 the use of the EncryptedValue structure has been 283 deprecated in favor of the EnvelopedData structure. 285 Replace the third bullet point of this section with the following 286 text. 288 o When using EnvelopedData the contentType of EncryptedContentInfo 289 and when using EncryptedValue the valueHint field MAY contain a 290 key identifier (chosen by the entity, along with the passphrase 291 itself) to assist in later retrieval of the correct passphrase 292 (e.g., when the revocation request is constructed by the entity 293 and received by the CA/RA). 295 2.6. Update Appendix C - Request Message Behavioral Clarifications 297 Appendix C of [RFC4210] provides clarifications to the request 298 message behavior. As this document updates [RFC4210] to utilize 299 EncryptedKey in favor of EncryptedValue as described in Section 2.1 300 above, the description is updated accordingly. 302 Replace the note coming after the ASN.1 syntax of POPOPrivKey of this 303 section with the following text. 305 -- ********** 306 -- * the type of "thisMessage" is given as BIT STRING in RFC 4211 307 -- * [RFC4211]; it should be "EncryptedKey" (in accordance with 308 -- * Section 5.2.2, "Encrypted Values", of this specification). 309 -- * Therefore, this document makes the behavioral clarification of 310 -- * specifying that the contents of "thisMessage" MUST be encoded 311 -- * either as EnvelopedData or EncryptedValue (only for backward 312 -- * compatibility) and then wrapped in a BIT STRING. This allows 313 -- * the necessary conveyance and protection of the private key 314 -- * while maintaining bits-on-the-wire compatibility with RFC 4211 315 -- * [RFC4211]. 316 -- ********** 318 2.7. Update Appendix D.4. - Request Message Behavioral Clarifications 320 < TBD, add further details on crc[1].certifiedKeyPair, e.g. refer to 321 usage of EncryptedValue protected with the pre-shared symmetric 322 MACing key using SYM_PENC_ALG. > 324 2.8. Insert section for EKUs like kp-id-cmpRA definition at an 325 appropriate location. 327 < Details need to be defined later > 329 3. IANA Considerations 331 333 4. Security Considerations 335 No changes are made to the existing security considerations of 336 RFC 4210 [RFC4210]. 338 5. Acknowledgements 340 We would like to thank the various reviewers of this document. 342 6. References 344 6.1. Normative References 346 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 347 Requirement Levels", BCP 14, RFC 2119, 348 DOI 10.17487/RFC2119, March 1997, 349 . 351 [RFC4210] Adams, C., Farrell, S., Kause, T., and T. Mononen, 352 "Internet X.509 Public Key Infrastructure Certificate 353 Management Protocol (CMP)", RFC 4210, 354 DOI 10.17487/RFC4210, September 2005, 355 . 357 [RFC4211] Schaad, J., "Internet X.509 Public Key Infrastructure 358 Certificate Request Message Format (CRMF)", RFC 4211, 359 DOI 10.17487/RFC4211, September 2005, 360 . 362 [RFC5280] Cooper, D., Santesson, S., Farrell, S., Boeyen, S., 363 Housley, R., and W. Polk, "Internet X.509 Public Key 364 Infrastructure Certificate and Certificate Revocation List 365 (CRL) Profile", RFC 5280, DOI 10.17487/RFC5280, May 2008, 366 . 368 [RFC5652] Housley, R., "Cryptographic Message Syntax (CMS)", STD 70, 369 RFC 5652, DOI 10.17487/RFC5652, September 2009, 370 . 372 [RFC6712] Kause, T. and M. Peylo, "Internet X.509 Public Key 373 Infrastructure -- HTTP Transfer for the Certificate 374 Management Protocol (CMP)", RFC 6712, 375 DOI 10.17487/RFC6712, September 2012, 376 . 378 6.2. Informative References 380 [I-D.brockhaus-lamps-industrial-cmp-profile] 381 Brockhaus, H., Fries, S., and D. Oheimb, "Lightweight 382 Industrial CMP Profile", draft-brockhaus-lamps-industrial- 383 cmp-profile-00 (work in progress), March 2019. 385 Appendix A. ASN.1 Modules 387 Changes to the following parts are needed 389 o Import from PKIKXCRMF-2005 391 CertTemplate, PKIPublicationInfo, EncryptedKey, CertId, 392 CertReqMessages 393 FROM PKIXCRMF-2005 {iso(1) identified-organization(3) 394 dod(6) internet(1) security(5) mechanisms(5) pkix(7) 395 id-mod(0) id-mod-crmf2005(36)} 397 o In CertifiedKeyPair, CertOrEncCert and id-it-revPassphrase 399 CertifiedKeyPair ::= SEQUENCE { 400 certOrEncCert CertOrEncCert, 401 privateKey [0] EncryptedKey OPTIONAL, 402 -- see [CRMF] for comment on encoding 403 publicationInfo [1] PKIPublicationInfo OPTIONAL 404 } 406 CertOrEncCert ::= CHOICE { 407 certificate [0] CMPCertificate, 408 encryptedCert [1] EncryptedKey 409 } 411 -- id-it-revPassphrase OBJECT IDENTIFIER ::= {id-it 12} 412 -- RevPassphraseValue ::= EncryptedKey 414 < TBD: If needed the complete ASN.1 Module from RFC 4210 section 415 needs to be copied here to be changed. > 417 Author's Address 418 Hendrik Brockhaus 419 Siemens AG 420 Otto-Hahn-Rin 6 421 Munich 81739 422 Germany 424 Email: hendrik.brockhaus@siemens.com 425 URI: http://www.siemens.com/