idnits 2.17.1 draft-turner-encryptedkeypackagecontenttype-02.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- No issues found here. Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- No issues found here. Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- No issues found here. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust and authors Copyright Line does not match the current year -- The document date (May 7, 2010) is 5103 days in the past. Is this intentional? -- Found something which looks like a code comment -- if you have code sections in the document, please surround them with '' and '' lines. 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 477 -- Looks like a reference, but probably isn't: '1' on line 478 == Missing Reference: 'RFCXXXX' is mentioned on line 341, but not defined == Outdated reference: A later version (-06) exists of draft-housley-cms-content-constraints-extn-05 == Outdated reference: A later version (-11) exists of draft-ietf-keyprov-symmetrickeyformat-08 ** Downref: Normative reference to an Informational draft: draft-ietf-pkix-new-asn1 (ref. 'RFCTBD3') ** Downref: Normative reference to an Informational draft: draft-ietf-smime-new-asn1 (ref. 'RFCTBD4') Summary: 2 errors (**), 0 flaws (~~), 4 warnings (==), 4 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 1 Network Working Group S. Turner, IECA 2 Internet Draft R. Housley, Vigil Security 3 Intended Status: Standards Track May 7, 2010 4 Expires: November 7, 2010 6 Cryptographic Message Syntax (CMS) 7 Encrypted Key Package Content Type 8 draft-turner-encryptedkeypackagecontenttype-02.txt 10 Abstract 12 This document defines the Cryptographic Message Syntax (CMS) 13 encrypted key package content type, which can be used to encrypt a 14 content that includes a key package, such as a symmetric key package 15 or an asymmetric key package. It is transport independent. CMS can 16 be used to digitally sign, digest, authenticate, or further encrypt 17 this content type. It is designed to be used with the CMS Content 18 Constraints (CCC) extension, which does not constrain the 19 EncryptedData, EnvelopedData, and AuthEnvelopedData. 21 Status of this Memo 23 This Internet-Draft is submitted to IETF in full conformance with the 24 provisions of BCP 78 and BCP 79. 26 Internet-Drafts are working documents of the Internet Engineering 27 Task Force (IETF), its areas, and its working groups. Note that 28 other groups may also distribute working documents as Internet- 29 Drafts. 31 Internet-Drafts are draft documents valid for a maximum of six months 32 and may be updated, replaced, or obsoleted by other documents at any 33 time. It is inappropriate to use Internet-Drafts as reference 34 material or to cite them other than as "work in progress." 36 The list of current Internet-Drafts can be accessed at 37 http://www.ietf.org/ietf/1id-abstracts.txt 39 The list of Internet-Draft Shadow Directories can be accessed at 40 http://www.ietf.org/shadow.html 42 This Internet-Draft will expire on November 7, 2010. 44 Copyright Notice 46 Copyright (c) 2010 IETF Trust and the persons identified as the 47 document authors. All rights reserved. 49 This document is subject to BCP 78 and the IETF Trust's Legal 50 Provisions Relating to IETF Documents 51 (http://trustee.ietf.org/license-info) in effect on the date of 52 publication of this document. Please review these documents 53 carefully, as they describe your rights and restrictions with respect 54 to this document. Code Components extracted from this document must 55 include Simplified BSD License text as described in Section 4.e of 56 the Trust Legal Provisions and are provided without warranty as 57 described in the Simplified BSD License. 59 1. Introduction 61 The Cryptographic Message Syntax (CMS) specification [RFC5652] 62 defines mechanisms to digitally sign, digest, authenticate or encrypt 63 arbitrary message content. Many specifications define content types 64 intended for use with CMS. [RFCTBD1] and [RFCTBD2] define symmetric 65 key package and asymmetric key package content types that can be 66 signed or encrypted using CMS. CMS allows composition of complex 67 messages with an arbitrary number of layers. CMS has been augmented 68 by several specifications ([RFC3274], [RFC4073] and [RFC5083]) that 69 define additional mechanisms to enable creation of messages of 70 arbitrary depth and breadth using a variety of authentication, 71 encryption and compression techniques. 73 The CMS Content Constraints (CCC) certificate extension [CCC] defines 74 an authorization mechanism that allows recipients to determine 75 whether the originator of an authenticated CMS content type is 76 authorized to produce messages of that type. CCC is used to 77 authorize CMS-protected content. CCC cannot be used to constrain the 78 following structures that are used to provide layers of protection: 79 SignedData, EnvelopedData, EncryptedData, DigestData, CompressedData, 80 AuthenticatedData, ContentCollection, ContentWithAttributes or 81 AuthEnvelopedData. 83 Using the existing CMS mechanisms, producers of authenticated 84 plaintext key packages can be authorized by including a CCC extension 85 containing the appropriate content type in the producer's 86 certificate. However, these mechanisms cannot be used to authorize 87 the producers of encrypted key material. In some key management 88 systems, encrypted key packages are exchanged between entities that 89 cannot decrypt the key package. The encrypted key package itself may 90 be authenticated and passed to another entity. In these cases, 91 checking the authorization of the producer of the encrypted key 92 package may be desired at the intermediate points. 94 This document defines the encrypted key package content type, which 95 can be used to encrypt a content that includes a key package, such as 96 a symmetric key package [RFCTBD1] or an asymmetric key package 97 [RFCTBD2]. It is transport independent. The Cryptographic Message 98 Syntax (CMS) [RFC5652] can be used to digitally sign, digest, 99 authenticate, or further encrypt this content type. 101 The encrypted key package content type is designed for use with 102 [CCC]. To authorize an originator's public key to originate an 103 encrypted key package, the object identifier associated with the 104 encrypted key package content type is included in the originator's 105 public key certificate CCC certificate extension. For CCC to 106 function, originators encapsulate the encrypted key package in a 107 SignedData, EnvelopedData, or AuthEnvelopedData, and then during 108 certificate path validation the recipient determines whether the 109 originator is authorized to originate the encrypted key package. 111 In [CCC] terminology, the encrypted key package is a leaf node. 112 Additional authorization checks may be required once the key package 113 is decrypted. For example, the key package shown below consists of a 114 SignedData layer that encapsulates an encrypted key package that 115 encapsulates a SignedData layer containing a symmetric key package. 116 A recipient capable of decrypting the key package would perform the 117 following steps prior to accepting the encapsulated symmetric key 118 material: 120 o Verify the signature on the outer SignedData layer per [RFC5652]. 122 o Build and validate a certification path of the outer signer and 123 confirm the outer signer is authorized to produce the encrypted 124 key package per [RFC5280] and [CCC]. 126 o Decrypt the encrypted key package 128 o Verify the signature on the inner SignedData layer per [RFC5652]. 130 o Build and validate a certification path to the signer of the 131 inner SignedData and confirm the inner signer is authorized to 132 produce the symmetric key package per [RFC5280] and [CCC]. 133 As specified in [CCC], the validator may use the attributes and 134 public keys returned from the second step as inputs for this CMS 135 content constraints processing. 137 o Use the symmetric key material. 139 +--------------------------------------+ 140 | ContentInfo | 141 | | 142 | +----------------------------------+ | 143 | | SignedData | | 144 | | | | 145 | | +------------------------------+ | | 146 | | | EncryptedKeyPackage | | | 147 | | | (encrypted) | | | 148 | | | | | | 149 | | | +-------------------------+ | | | 150 | | | | SignedData | | | | 151 | | | | | | | | 152 | | | | +---------------------+ | | | | 153 | | | | | SymmetricKeyPackage | | | | | 154 | | | | +---------------------+ | | | | 155 | | | +-------------------------+ | | | 156 | | +------------------------------+ | | 157 | +----------------------------------+ | 158 +--------------------------------------+ 160 In the example, authorization of the SymmetricKeyPackage originator 161 need not require an intermediate SignedData layer. For example, if 162 the AuthEnvelopedData option within an EncryptedKeyPackage were used, 163 the second authorization check would be performed beginning with the 164 authEnveloped field. 166 This document also defines an unprotected attribute, Content 167 Decryption Key Identifier, for use with EncryptedData. 169 1.1. Terminology 171 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 172 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 173 document are to be interpreted as described in [RFC2119]. 175 1.2. ASN.1 Syntax Notation 177 The key package is defined using the ASN.1 [X.680], [X.681], [X.682], 178 and [X.683]. 180 2. Encrypted Key Package 182 The encrypted key package content type is used to encrypt a content 183 that includes a key package. This content type is usually used to 184 provide encryption of a key package or a signed key package. This 185 content type makes use of the CMS EncryptedData content type 187 [RFC5652], the CMS EnvelopedData content type [RFC5652], or the CMS 188 AuthEnvelopedData content type [RFC5083] depending on the fields that 189 are needed for key management. The difference between the encrypted 190 key package content type and these three protecting content types is 191 the object identifier and one tag; otherwise, the encrypted key 192 package content type is the same as the selected protecting content 193 type, which is either EncryptedData, EnvelopedData, or 194 AuthEnvelopedData. 196 The encrypted key package content type has the following syntax: 198 ct-encrypted-key-package CONTENT-TYPE ::= 199 { EncryptedKeyPackage IDENTIFIED BY id-ct-KP-encryptedKeyPkg } 201 id-ct-KP-encryptedKeyPkg OBJECT IDENTIFIER ::= 202 { joint-iso-itu-t(2) country(16) us(840) organization(1) 203 gov(101) dod(2) infosec(1) formats(2) 204 key-package-content-types(78) 2 } 206 EncryptedKeyPackage ::= CHOICE { 207 encrypted EncryptedData, 208 enveloped [0] EnvelopedData, 209 authEnveloped [1] AuthEnvelopedData } 211 The EncryptedData structure is used for simple symmetric encryption, 212 where the sender and the receiver already share the necessary 213 encryption key. The EncryptedData structure carries an encryption 214 algorithm identifier, and an unprotected attribute can be used to 215 carry an encryption key identifier if one is needed (see Section 3). 216 See [RFC5652] for further discussion of the EncryptedData fields. 218 The EnvelopedData structure is used for encryption, where transferred 219 key management information enables decryption by the receiver. 220 Encryption details depend on the key management algorithm used. In 221 addition to the key management information, the EnvelopedData 222 structure carries an encryption algorithm identifier. See [RFC5652] 223 for further discussion of the EnvelopedData fields. 225 The AuthEnvelopedData structure is used for authenticated encryption, 226 and it includes key management information in a manner similar to 227 EnvelopedData. Encryption details depend on the key management 228 algorithm used. In addition to the key management information, the 229 AuthEnvelopedData structure carries a message authentication code 230 that covers the content as well as authenticated attributes. See 231 [RFC5083] for further discussion of the AuthEnvelopedData fields. 233 Implementations of this document MUST support the EnvelopedData 234 choice, SHOULD support the EncryptedData choice, and MAY support the 235 AuthEnvelopedData. 237 Implementations that support EnvelopedData and EncryptedData to 238 encapsulate with this content type MUST support an 239 EncryptedKeyPackage that encapsulates either a SignedData [RFC5652] 240 that further encapsulates a SymmetricKeyPackage [RFCTBD1] or a 241 SignedData that further encapsulates an AsymmetricKeyPackage 242 [RFCTBD2]. Implementations that support AuthEnvelopedData to 243 encapsulate with this content type MUST support an 244 EncryptedKeyPackage that encapsulates either a SymmetricKeyPackage 245 [RFCTBD1] or an AsymmetricKeyPackage [RFCTBD2]. It is OPTIONAL for 246 implementations that support AuthEnvelopedData to encapsulate with 247 this content type to support an EncryptedKeyPackage that encapsulates 248 either a SignedData [RFC5652] that further encapsulates a 249 SymmetricKeyPackage [RFCTBD1] or a SignedData that further 250 encapsulates an AsymmetricKeyPackage [RFCTBD2]. Likewise, 251 implementations that process this content type to decrypt the 252 encapsulated data MUST support an EncryptedKeyPackage that 253 encapsulates either a SignedData that further encapsulates a 254 SymmetricKeyPackage or a SignedData that further encapsulates an 255 AsymmetricKeyPackage. An EncryptedKeyPackage content type MUST 256 contain at least one SymmetricKeyPackage or AsymmetricKeyPackage. 257 Implementations MAY support additional encapsulating layers. 259 Note that interoperability between an originator and a recipient that 260 do not support the same inner-most content (e.g., originator supports 261 AsymmetricKeyPackage while recipient supports SymmetricKeyPackage) is 262 not a concern as originators should be aware of the recipient's 263 capabilities; however, the mechanism for the exchange of the 264 recipient's capabilities is beyond the scope of this document. 266 3. Content Decryption Key Identifier 268 The content-decryption-key-identifier attribute can be used to 269 identify the symmetric keying material that is needed for decryption 270 of the EncryptedData content if there is any ambiguity. The 271 ATTRIBUTE definition is taken from [RFCTBD3]. There MUST be only one 272 instance of the content-decryption-key-identifier attribute and there 273 MUST be only one value for the content-decryption-key-identifier 274 attribute. 276 The content-decryption-key-identifier attribute has the following 277 syntax: 279 aa-content-decrypt-key-identifier ATTRIBUTE ::= { 280 TYPE ContentDecryptKeyID 281 IDENTIFIED BY id-aa-KP-contentDecryptKeyID } 283 id-aa-KP-contentDecryptKeyID OBJECT IDENTIFIER ::= { 284 joint-iso-itu-t(2) country(16) us(840) organization(1) gov(101) 285 dod(2) infosec(1) attributes(5) 66 } 287 ContentDecryptKeyID ::= OCTET STRING 289 The content decryption key identifier contains an octet string, and 290 this syntax does not impose any particular structure on the 291 identifier value. 293 Due to multiple layers of encryption, the content-decryption-key- 294 identifier attribute can appear in more than one location in the 295 overall key package. When there are multiple occurrences of the 296 content-decryption-key-identifier attribute, each occurrence is 297 evaluated independently. Each one is used to identify the needed 298 keying material for that layer of encryption. 300 4. Security Considerations 302 Implementers of this protocol are strongly encouraged to consider 303 generally accepted principles of secure key management when 304 integrating this capability within an overall security architecture. 306 The security considerations from [RFC5083], [RFC5652], [RFCTBD1], 307 [RFCTBD2], [RFCTBD3], and [RFCTBD4] apply. If the CCC extension is 308 used as an authorization mechanism, then the security considerations 309 from [CCC] also apply. 311 The encrypted key package content type might not provide proof of 312 origin if the content encryption algorithm does not support 313 authenticated key exchange. To provide proof of origin for this 314 content, another security protocol needs to be used. This is the 315 reason that support for encapsulating the SymmetricKeyPackage and 316 AsymmetricKeypackage with a SignedData content type from [RFC5652] is 317 required for the EnvelopedData and EncryptedData choices. 319 When this content type is used the CMS SignedData [RFC5652] 320 validation rules MUST be used. The PKCS #7 [RFC2315] validation 321 rules MUST NOT be used. 323 5. IANA Considerations 325 This document makes use of object identifiers to identify a CMS 326 content type, a CMS attribute, and the ASN.1 module; all found in 327 Appendix A. All OIDs are registered in an arc delegated by IANA to 328 the SMIME Working Group. No further action by IANA is necessary for 329 this document or any anticipated updates. 331 6. References 333 6.1. Normative References 335 [CCC] Wallace, C., and R. Housley, "Cryptographic Message 336 Syntax (CMS) Content Constraints X.509 Certificate 337 Extension", draft-housley-cms-content-constraints-extn- 338 05.txt, work-in-progress. 340 /** 341 RFC Editor: Please replace [CCC] with [RFCXXXX] where XXXX is the 342 number of the published RFC. Please do this in both the references 343 and the text. 344 **/ 346 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 347 Requirement Levels", BCP 14, RFC 2119, March 1997. 349 [RFC5083] Housley, R., "Cryptographic Message Syntax (CMS) 350 Authenticated-Enveloped-Data Content Type", RFC 5083, 351 November 2007. 353 [RFC5280] Cooper, D., Santesson, S., Farrell, S., Boeyen, S., 354 Housley, R., and W. Polk, "Internet X.509 Public Key 355 Infrastructure Certificate and Certificate Revocation 356 List (CRL) Profile", RFC 5280, May 2008. 358 [RFC5652] Housley, R., "Cryptographic Message Syntax (CMS)", RFC 359 5652, September 2009. 361 [RFCTBD1] Housley, R. and S. Turner, "Symmetric Key package Content 362 Type", draft-ietf-keyprov-symmetrickeyformat-08.txt, 363 work-in-progress. 365 /** 366 RFC Editor: Please replace "TBD1" with the number of the published 367 RFC. Please do this in both the references and the text. 368 **/ 370 [RFCTBD2] Turner, S., "Asymmetric Key Packages", draft-turner- 371 asymmetrickeyformat-05.txt, work-in-progress. 373 /** 374 RFC Editor: Please replace "TB2" with the number of the published 375 RFC. Please do this in both the references and the text. 376 **/ 378 [RFCTBD3] Schaad, J., and P. Hoffman, "New ASN.1 Modules for PKIX", 379 draft-ietf-pkix-new-asn1-08.txt, work-in-progress. 381 /** 382 RFC Editor: Please replace "TBD3" with the number of the published 383 RFC. Please do this in both the references and the text. 384 **/ 386 [RFCTBD4] Schaad, J., and P. Hoffman, "New ASN.1 Modules for 387 SMIME", draft-ietf-smime-new-asn1-07.txt, work-in- 388 progress. 390 /** 391 RFC Editor: Please replace "TBD4" with the number of the published 392 RFC. Please do this in both the references and the text. 393 **/ 395 [X.680] ITU-T Recommendation X.680 (2002) | ISO/IEC 8824-1:2002. 396 Information Technology - Abstract Syntax Notation One. 398 [X.681] ITU-T Recommendation X.681 (2002) | ISO/IEC 8824-2:2002. 399 Information Technology - Abstract Syntax Notation One: 400 Information Object Specification. 402 [X.682] ITU-T Recommendation X.682 (2002) | ISO/IEC 8824-3:2002. 403 Information Technology - Abstract Syntax Notation One: 404 Constraint Specification. 406 [X.683] ITU-T Recommendation X.683 (2002) | ISO/IEC 8824-4:2002. 407 Information Technology - Abstract Syntax Notation One: 408 Parameterization of ASN.1 Specifications. 410 6.2. Informative References 412 [RFC2315] Kaliski, B., "PKCS #7: Cryptographic Message Syntax 413 Version 1.5", RFC 2315, March 1998. 415 [RFC3274] Gutmann, P., "Compressed Data Content Type for 416 Cryptographic Message Syntax (CMS)", RFC 3274, June 2002. 418 [RFC4073] Housley, R., "Protecting Multiple Contents with the 419 Cryptographic Message Syntax (CMS)", RFC 4073, May 2005. 421 Appendix A. ASN.1 Module 423 This appendix provides the normative ASN.1 [X.680] definitions for 424 the structures described in this specification using ASN.1 as defined 425 in [X.680] through [X.683]. 427 EncryptedKeyPackageModuleV1 428 { iso(1) member-body(2) us(840) rsadsi(113549) pkcs(1) pkcs-9(9) 429 smime(16) modules(0) id-mod-encryptedKeyPkgV1(51) } 431 DEFINITIONS IMPLICIT TAGS ::= 433 BEGIN 435 -- EXPORTS ALL -- 437 IMPORTS 439 -- From New SMIME ASN.1 [RFCTBD4] 441 EncryptedData, EnvelopedData, CONTENT-TYPE 442 FROM CryptographicMessageSyntax-2009 443 { iso(1) member-body(2) us(840) rsadsi(113549) pkcs(1) pkcs-9(9) 444 smime(16) modules(0) cms-2004-02(41) } 446 -- From New SMIME ASN.1 [RFCTBD4] 448 AuthEnvelopedData 449 FROM CMS-AuthEnvelopedData-2009 450 { iso(1) member-body(2) us(840) rsadsi(113549) pkcs(1) 451 pkcs-9(9) smime(16) modules(0) cms-authEnvelopedData-02(43) } 453 -- From New PKIX ASN.1 [RFCTBD3] 455 ATTRIBUTE 456 FROM PKIX-CommonTypes-2009 457 { iso(1) identified-organization(3) dod(6) internet(1) 458 security(5) mechanisms(5) pkix(7) id-mod(0) 459 id-mod-pkixCommon-02(57) } 461 ; 463 ContentSet CONTENT-TYPE ::= { 464 ct-encrypted-key-package, 465 ... -- Expect additional content types -- 466 } 468 ct-encrypted-key-package CONTENT-TYPE ::= 469 { EncryptedKeyPackage IDENTIFIED BY id-ct-KP-encryptedKeyPkg } 471 id-ct-KP-encryptedKeyPkg OBJECT IDENTIFIER ::= 472 { joint-iso-itu-t(2) country(16) us(840) organization(1) gov(101) 473 dod(2) infosec(1) formats(2) key-package-content-types(78) 2 } 475 EncryptedKeyPackage ::= CHOICE { 476 encrypted EncryptedData, 477 enveloped [0] EnvelopedData, 478 authEnveloped [1] AuthEnvelopedData } 480 aa-content-decrypt-key-identifier ATTRIBUTE ::= { 481 TYPE ContentDecryptKeyID 482 IDENTIFIED BY id-aa-KP-contentDecryptKeyID } 484 id-aa-KP-contentDecryptKeyID OBJECT IDENTIFIER ::= { 485 joint-iso-itu-t(2) country(16) us(840) organization(1) gov(101) 486 dod(2) infosec(1) attributes(5) 66 } 488 ContentDecryptKeyID ::= OCTET STRING 490 END 492 Authors' Addresses 494 Sean Turner 495 IECA, Inc. 496 3057 Nutley Street, Suite 106 497 Fairfax, VA 22031 498 USA 500 EMail: turners@ieca.com 502 Russ Housley 503 Vigil Security, LLC 504 918 Spring Knoll Drive 505 Herndon, VA 20170 506 USA 508 EMail: housley@vigilsec.com