idnits 2.17.1 draft-ietf-smime-cms-auth-enveloped-02.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- ** It looks like you're using RFC 3978 boilerplate. You should update this to the boilerplate described in the IETF Trust License Policy document (see https://trustee.ietf.org/license-info), which is required now. -- Found old boilerplate from RFC 3978, Section 5.1 on line 15. -- Found old boilerplate from RFC 3978, Section 5.5, updated by RFC 4748 on line 430. ** The document seems to lack an RFC 3979 Section 5, para. 1 IPR Disclosure Acknowledgement. ** The document seems to lack an RFC 3979 Section 5, para. 2 IPR Disclosure Acknowledgement. ** The document seems to lack an RFC 3979 Section 5, para. 3 IPR Disclosure Invitation. Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- ** Missing expiration date. The document expiration date should appear on the first and last page. == No 'Intended status' indicated for this document; assuming Proposed Standard Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- ** The document seems to lack an IANA Considerations section. (See Section 2.2 of https://www.ietf.org/id-info/checklist for how to handle the case when there are no actions for IANA.) ** There are 3 instances of too long lines in the document, the longest one being 4 characters in excess of 72. -- The draft header indicates that this document updates RFC3852, but the abstract doesn't seem to mention this, which it should. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust Copyright Line does not match the current year == The document seems to lack the recommended RFC 2119 boilerplate, even if it appears to use RFC 2119 keywords. (The document does seem to have the reference to RFC 2119 which the ID-Checklist requires). (Using the creation date from RFC3852, updated by this document, for RFC5378 checks: 2004-03-16) -- 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 2007) is 6279 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 347 -- Looks like a reference, but probably isn't: '1' on line 349 -- Looks like a reference, but probably isn't: '2' on line 352 ** Obsolete normative reference: RFC 3852 (ref. 'CMS') (Obsoleted by RFC 5652) Summary: 8 errors (**), 0 flaws (~~), 3 warnings (==), 8 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 S/MIME Working Group R. Housley 3 Internet-Draft Vigil Security 4 Updates: 3852 (if approved) February 2007 6 Cryptographic Message Syntax (CMS) 7 Authenticated-Enveloped-Data Content Type 8 10 Status of this Memo 12 By submitting this Internet-Draft, each author represents that any 13 applicable patent or other IPR claims of which he or she is aware 14 have been or will be disclosed, and any of which he or she becomes 15 aware will be disclosed, in accordance with Section 6 of BCP 79. 17 Internet-Drafts are working documents of the Internet Engineering 18 Task Force (IETF), its areas, and its working groups. Note that other 19 groups may also distribute working documents as Internet-Drafts. 21 Internet-Drafts are draft documents valid for a maximum of six months 22 and may be updated, replaced, or obsoleted by other documents at any 23 time. It is inappropriate to use Internet-Drafts as reference 24 material or to cite them other than as "work in progress." 26 The list of current Internet-Drafts can be accessed at 27 http://www.ietf.org/1id-abstracts.html 29 The list of Internet-Draft Shadow Directories can be accessed at 30 http://www.ietf.org/shadow.html 32 Abstract 34 This document describes an additional content type for the 35 Cryptographic Message Syntax (CMS). The authenticated-enveloped-data 36 content type is intended for use with authenticated encryption modes. 37 All of the various key management techniques that are supported in 38 the CMS enveloped-data content type are also supported by the CMS 39 authenticated-enveloped-data content type. 41 1. Introduction 43 This document describes an additional content type for the 44 Cryptographic Message Syntax (CMS) [CMS]. The authenticated- 45 enveloped-data content type is intended for use with authenticated 46 encryption modes, where an arbitrary content is both authenticated 47 and encrypted. Also, some associated data, in the form of 48 authenticated attributes can also be authenticated. All of the 49 various key management techniques that are supported in the CMS 50 enveloped-data content type are also supported by the CMS 51 authenticated-enveloped-data content type. 53 The conventions for using the AES-CCM and the AES-GCM authenticated 54 encryption algorithms with the CMS authenticated-enveloped-data 55 content type defined in this document can be found in [AEALGS]. 57 The authenticated-enveloped-data content type, like all of the other 58 CMS content types, employs ASN.1 [X.208-88], and it uses both the 59 Basic Encoding Rules [X.209-88] and the Distinguished Encoding Rules 60 (DER) [X.509-88]. 62 1.1 Terminology 64 In this document, the key words MUST, MUST NOT, REQUIRED, SHOULD, 65 SHOULD NOT, RECOMMENDED, MAY, and OPTIONAL are to be interpreted as 66 described in [STDWORDS]. 68 1.2 Version Numbers 70 The major data structure (AuthEnvelopedData) includes a version 71 number as the first item in the data structure. The version number 72 is intended to avoid ASN.1 decode errors. Some implementations do 73 not check the version number prior to attempting a decode, and then 74 if a decode error occurs, the version number is checked as part of 75 the error handling routine. This is a reasonable approach; it places 76 error processing outside of the fast path. This approach is also 77 forgiving when an incorrect version number is used by the sender. 79 Whenever the structure is updated, a higher version number will be 80 assigned. However, to ensure maximum interoperability the higher 81 version number is only used when the new syntax feature is employed. 82 That is, the lowest version number that supports the generated syntax 83 is used. 85 2. Authenticated-enveloped-data Content Type 87 The authenticated-enveloped-data content type consists of an 88 authenticated and encrypted content of any type and encrypted 89 content-authenticated-encryption keys for one or more recipients. 90 The combination of the authenticated and encrypted content and one 91 encrypted content-authenticated-encryption key for a recipient is a 92 "digital envelope" for that recipient. Any type of content can be 93 enveloped for an arbitrary number of recipients using any of the 94 supported key management techniques for each recipient. In addition, 95 authenticated but not encrypted attributes may be provided by the 96 originator. 98 The typical application of the authenticated-enveloped-data content 99 type will represent one or more recipients' digital envelopes on an 100 encapsulated content. 102 Authenticated-enveloped-data is constructed by the following steps: 104 1. A content-authenticated-encryption key for a particular 105 content-authenticated-encryption algorithm is generated at random. 107 2. The content-authenticated-encryption key is encrypted for each 108 recipient. The details of this encryption depend on the key 109 management algorithm used, but four general techniques are 110 supported: 112 key transport: the content-authenticated-encryption key is 113 encrypted in the recipient's public key; 115 key agreement: the recipient's public key and the sender's 116 private key are used to generate a pairwise symmetric key- 117 encryption key, then the content-authenticated-encryption 118 key is encrypted in the pairwise symmetric key-encryption 119 key; 121 symmetric key-encryption keys: the content-authenticated- 122 encryption key is encrypted in a previously distributed 123 symmetric key-encryption key; and 125 passwords: the content-authenticated-encryption key is 126 encrypted in a key-encryption key that is derived from a 127 password or other shared secret value. 129 3. For each recipient, the encrypted content-authenticated- 130 encryption key and other recipient-specific information are 131 collected into a RecipientInfo value, defined in Section 6.2 of 132 [CMS]. 134 4. Any attributes that are to be authenticated but not encrypted 135 are collected in the authenticated attributes. 137 5. The attributes collected in step 4 are authenticated and the 138 content is authenticated and encrypted with the content- 139 authenticated-encryption key. If the authenticated encryption 140 algorithm requires either the additional authenticated data (AAD) 141 or the content to be padded to a multiple of some block size, then 142 the padding is added as described in Section 6.3 of [CMS]. 144 6. Any attributes that are to be provided without authentication 145 or encryption are collected in the unauthenticated attributes. 147 7. The RecipientInfo values for all the recipients, the 148 authenticated attributes, then unauthenticated attributes, and the 149 authenticated and encrypted content are collected together to form 150 an AuthEnvelopedData value as defined in Section 2.1. 152 A recipient opens the digital envelope by decrypting one of the 153 encrypted content-authenticated-encryption keys, and then using the 154 recovered key to decrypt and verify the integrity of the 155 authenticated and encrypted content as well as verifying the 156 integrity of the authenticated attributes. 158 This section is divided into three parts. The first part describes 159 the AuthEnvelopedData content type, the second part describes the 160 authentication and encryption process, and third part describes the 161 key encryption process. 163 2.1 AuthEnvelopedData Type 165 The following object identifier identifies the authenticated- 166 enveloped-data content type: 168 id-ct-authEnvelopedData OBJECT IDENTIFIER ::= { iso(1) 169 member-body(2) us(840) rsadsi(113549) pkcs(1) pkcs-9(9) 170 smime(16) ct(1) 23 } 172 The authenticated-enveloped-data content type MUST have ASN.1 type 173 AuthEnvelopedData: 175 AuthEnvelopedData ::= SEQUENCE { 176 version CMSVersion, 177 originatorInfo [0] IMPLICIT OriginatorInfo OPTIONAL, 178 recipientInfos RecipientInfos, 179 authAttrs [1] IMPLICIT AuthAttributes OPTIONAL, 180 authEncryptedContentInfo EncryptedContentInfo, 181 mac MessageAuthenticationCode, 182 unauthAttrs [2] IMPLICIT UnauthAttributes OPTIONAL } 184 The fields of type AuthEnvelopedData have the following meanings: 186 version is the syntax version number. It MUST be set to 0. 188 originatorInfo optionally provides information about the 189 originator. It is present only if required by the key 190 management algorithm. It may contain certificates and CRLs, 191 and the OriginatorInfo type is defined in Section 6.1 of [CMS]. 193 recipientInfos is a collection of per-recipient information. 194 There MUST be at least one element in the collection. The 195 RecipientInfo type is defined in Section 6.2 of [CMS]. 197 authAttrs optionally contains the authenticated attributes. The 198 CMS authenticated-data content type uses the same type to carry 199 authenticated attributes. The AuthAttributes type is defined 200 in Section 9.1 of [CMS]; however, in this case, there is no 201 requirement to include the message-digest attribute. Useful 202 attribute types are defined in Section 11 of [CMS]. 204 authEncryptedContentInfo is the authenticated and encrypted 205 content. The CMS enveloped-data content type uses the same 206 type to carry the encrypted content. The EncryptedContentInfo 207 type is defined in Section 6.1 of [CMS]. 209 mac is the integrity check value (ICV) or message authentication 210 code (MAC) that is generated by the authenticated encryption 211 algorithm. The CMS authenticated-data content type uses the 212 same type to carry a MAC. In this case, the MAC covers the 213 authenticated attributes and the content directly, and a digest 214 algorithm is not used. The MessageAuthenticationCode type is 215 defined in Section 9.1 of [CMS]. 217 unauthAttrs optionally contains the unauthenticated attributes. 218 The CMS authenticated-data content type uses the same type to 219 carry unauthenticated attributes. The UnauthAttributes type is 220 defined in Section 9.1 of [CMS]. Useful attribute types are 221 defined in Section 11 of [CMS]. 223 2.2. Authentication and Encryption Process 225 The content-authenticated-encryption key for the desired content- 226 authenticated-encryption algorithm is randomly generated. 228 If the authenticated encryption algorithm requires the content to be 229 padded to a multiple of some block size, then the padding MUST be 230 added as described in Section 6.3 of [CMS]. This padding method is 231 well defined if and only if the number of octets in the block size is 232 less than 256. 234 If optional authenticated attributes are present, then they are DER 235 encoded. The result will be used as the authenticated associated 236 data (AAD) input to the authenticated encryption algorithm. If the 237 authenticated encryption algorithm requires the AAD to be padded to a 238 multiple of some block size, then the padding MUST be added as 239 described in Section 6.3 of [CMS]. This padding method is well 240 defined if and only if number of octets in the block size is less 241 than 256. 243 The inputs to the authenticated encryption algorithm are the content 244 (the data, which is padded if necessary), the DER-encoded 245 authenticated attributes (the AAD, which is padded if necessary), and 246 the content-authenticated-encryption key. Under control of a 247 content-authenticated-encryption key, the authenticated encryption 248 operation maps an arbitrary string of octets (the data) to another 249 string of octets (the ciphertext) and it computes an authentication 250 tag over the AAD and the data. The encrypted data is included in the 251 AuthEnvelopedData authEncryptedContentInfo encryptedContent as an 252 OCTET STRING, and the authentication tag is included in the 253 AuthEnvelopedData mac. 255 2.3. Key Encryption Process 257 The input to the key encryption process -- the value supplied to the 258 recipient's key-encryption algorithm -- is just the "value" of the 259 content-authenticated-encryption key. 261 Any of the aforementioned key management techniques can be used for 262 each recipient of the same encrypted content. 264 3. Security Considerations 266 This specification defines an additional CMS content type. The 267 security considerations provided in [CMS] apply to this content type 268 as well. 270 Many authenticated encryption algorithms make use of a block cipher 271 in counter mode to provide encryption. When used properly, counter 272 mode provides strong confidentiality. Bellare, Desai, Jokipii, 273 Rogaway show in [BDJR] that the privacy guarantees provided by 274 counter mode are at least as strong as those for CBC mode when using 275 the same block cipher. 277 Unfortunately, it is easy to misuse counter mode. If counter block 278 values are ever used for more that one encryption operation with the 279 same key, then the same key stream will be used to encrypt both 280 plaintexts, and the confidentiality guarantees are voided. 282 Fortunately, the CMS authenticated-enveloped-data content type 283 provides all of the tools needed to avoid misuse of counter mode. 284 When using key transport or key agreement, a fresh key should be 285 generated for each content. However, when using symmetric key- 286 encryption keys or passwords, one cannot assume that a fresh key is 287 generated. Therefore, authenticated encryption algorithms that make 288 use of counter mode must support the use of an unpredictable nonce 289 value in the counter block, and this unpredictable nonce value 290 (sometimes called a "salt") must be carried as an algorithm 291 identifier parameter. 293 There are fairly generic precomputation attacks against all block 294 cipher modes that allow a meet-in-the-middle attack against the key. 295 These attacks require the creation and searching of huge tables of 296 ciphertext associated with known plaintext and known keys. Assuming 297 that the memory and processor resources are available for a 298 precomputation attack, then the theoretical strength of any block 299 cipher mode is limited to 2^(n/2) bits, where n is the number of bits 300 in the key. The use of long keys is the best countermeasure to 301 precomputation attacks. Use of an unpredictable nonce value in the 302 counter block significantly increases the size of the table that the 303 attacker must compute to mount a successful precomputation attack. 305 Implementations must randomly generate content-authenticated- 306 encryption keys, padding, and unpredictable nonce values. Also, the 307 generation of public/private key pairs relies on a random numbers. 308 The use of inadequate pseudo-random number generators (PRNGs) to 309 generate cryptographic keys can result in little or no security. An 310 attacker may find it much easier to reproduce the PRNG environment 311 that produced the keys, searching the resulting small set of 312 possibilities, rather than brute force searching the whole key space. 313 The generation of quality random numbers is difficult. RFC 4086 314 [RANDOM] offers important guidance in this area. 316 4 ASN.1 Module 318 CMS-AuthEnvelopedData-2007 319 { iso(1) member-body(2) us(840) rsadsi(113549) pkcs(1) 320 pkcs-9(9) smime(16) modules(0) cms-authEnvelopedData(31) } 322 DEFINITIONS IMPLICIT TAGS ::= 323 BEGIN 325 -- EXPORTS All 326 -- The types and values defined in this module are exported for use 327 -- in the other ASN.1 modules. Other applications may use them for 328 -- their own purposes. 330 IMPORTS 332 -- Imports from RFC 3852 [CMS], Section 12.1 333 AuthAttributes, CMSVersion, EncryptedContentInfo, 334 MessageAuthenticationCode, OriginatorInfo, RecipientInfos, 335 UnauthAttributes 336 FROM CryptographicMessageSyntax2004 337 { iso(1) member-body(2) us(840) rsadsi(113549) 338 pkcs(1) pkcs-9(9) smime(16) modules(0) 339 cms-2004(24) } ; 341 id-ct-authEnvelopedData OBJECT IDENTIFIER ::= { iso(1) 342 member-body(2) us(840) rsadsi(113549) pkcs(1) pkcs-9(9) 343 smime(16) ct(1) 23 } 345 AuthEnvelopedData ::= SEQUENCE { 346 version CMSVersion, 347 originatorInfo [0] IMPLICIT OriginatorInfo OPTIONAL, 348 recipientInfos RecipientInfos, 349 authAttrs [1] IMPLICIT AuthAttributes OPTIONAL, 350 authEncryptedContentInfo EncryptedContentInfo, 351 mac MessageAuthenticationCode, 352 unauthAttrs [2] IMPLICIT UnauthAttributes OPTIONAL } 354 END -- of CMS-AuthEnvelopedData-2007 356 5. Normative References 358 [CMS] Housley, R., "Cryptographic Message Syntax", 359 RFC 3852, July 2004. 361 [STDWORDS] Bradner, S., "Key Words for Use in RFCs to Indicate 362 Requirement Levels", BCP 14, RFC 2119, March 1997. 364 [X.208-88] CCITT. Recommendation X.208: Specification of Abstract 365 Syntax Notation One (ASN.1). 1988. 367 [X.209-88] CCITT. Recommendation X.209: Specification of Basic 368 Encoding Rules for Abstract Syntax Notation One (ASN.1). 369 1988. 371 [X.509-88] CCITT. Recommendation X.509: The Directory - 372 Authentication Framework. 1988. 374 6. Informative References 376 [AEALGS] Housley, R., "Using AES-CCM and AES-GCM Authenticated 377 Encryption in the Cryptographic Message Syntax (CMS)", 378 work in progress. draft-ietf-smime-cms-aes-ccm-and-gcm. 380 [BDJR] Bellare, M., Desai, A., Jokipii, E., and P. Rogaway, 381 "A Concrete Security Treatment of Symmetric Encryption: 382 Analysis of the DES Modes of Operation", Proceedings 383 38th Annual Symposium on Foundations of Computer 384 Science, 1997. 386 [RANDOM] Eastlake, D., Schiller, J., and S. Crocker, "Randomness 387 Recommendations for Security", RFC 4086, June 2005. 389 7. Authors' Address 391 Russell Housley 392 Vigil Security, LLC 393 918 Spring Knoll Drive 394 Herndon, VA 20170 395 USA 396 EMail: housley@vigilsec.com 398 Copyright and IPR Statements 400 Copyright (C) The IETF Trust (2007). 402 This document is subject to the rights, licenses and restrictions 403 contained in BCP 78, and except as set forth therein, the authors 404 retain all their rights. 406 This document and translations of it may be copied and furnished to 407 others, and derivative works that comment on or otherwise explain it 408 or assist in its implementation may be prepared, copied, published and 409 distributed, in whole or in part, without restriction of any kind, 410 provided that the above copyright notice and this paragraph are 411 included on all such copies and derivative works. However, this 412 document itself may not be modified in any way, such as by removing 413 the copyright notice or references to the Internet Society or other 414 Internet organizations, except as needed for the purpose of 415 developing Internet standards in which case the procedures for 416 copyrights defined in the Internet Standards process must be 417 followed, or as required to translate it into languages other than 418 English. 420 The limited permissions granted above are perpetual and will not be 421 revoked by the Internet Society or its successors or assigns. 423 This document and the information contained herein 424 are provided on an "AS IS" basis and THE CONTRIBUTOR, THE 425 ORGANIZATION HE/SHE REPRESENTS OR IS SPONSORED BY (IF ANY), THE 426 INTERNET SOCIETY, THE IETF TRUST AND THE INTERNET ENGINEERING TASK FORCE 427 DISCLAIM ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING BUT NOT LIMITED TO 428 ANY WARRANTY THAT THE USE OF THE INFORMATION HEREIN WILL NOT 429 INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF MERCHANTABILITY 430 OR FITNESS FOR A PARTICULAR PURPOSE.