idnits 2.17.1 draft-ietf-smime-cms-auth-enveloped-00.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 14. ** This document has an original RFC 3978 Section 5.4 Copyright Line, instead of the newer IETF Trust Copyright according to RFC 4748. ** The document seems to lack an RFC 3978 Section 5.5 (updated by RFC 4748) Disclaimer -- however, there's a paragraph with a matching beginning. Boilerplate error? ** 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. ** The document seems to lack a 1id_guidelines paragraph about 6 months document validity -- however, there's a paragraph with a matching beginning. Boilerplate error? == 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 is 1 instance of too long lines in the document, the longest one being 1 character 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 RFC 3978 Section 5.4 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 (January 2007) is 6303 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 332 -- Looks like a reference, but probably isn't: '1' on line 334 -- Looks like a reference, but probably isn't: '2' on line 337 ** Obsolete normative reference: RFC 3852 (ref. 'CMS') (Obsoleted by RFC 5652) Summary: 11 errors (**), 0 flaws (~~), 3 warnings (==), 7 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) January 2007 6 The CMS AuthEnvelopedData Content Type 7 9 Status of this Memo 11 By submitting this Internet-Draft, each author represents that any 12 applicable patent or other IPR claims of which he or she is aware 13 have been or will be disclosed, and any of which he or she becomes 14 aware will be disclosed, in accordance with Section 6 of BCP 79. 16 Internet-Drafts are working documents of the Internet Engineering 17 Task Force (IETF), its areas, and its working groups. Note that 18 other groups may also distribute working documents as Internet- 19 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 a "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 AuthEnvelopedData content 36 type is intended for use with authenticated encryption modes. All of 37 the various key management techniques that are supported in the 38 EnvelopedData content type are also supported by the 39 AuthEnvelopedData content type. 41 1. Introduction 43 This document describes an additional content type for the 44 Cryptographic Message Syntax (CMS) [CMS]. The AuthEnvelopedData 45 content type is intended for use with authenticated encryption modes, 46 where an arbitrary content is both authenticated and encrypted. 47 Also, some associated data, in the form of authenticated attributes 48 can also be authenticated. All of the various key management 49 techniques that are supported in the EnvelopedData content type are 50 also supported by the AuthEnvelopedData content type. 52 The AuthEnvelopedData content type, like all of the other CMS content 53 types, employs ASN.1 [X.208-88], and it uses both the Basic Encoding 54 Rules [X.209-88] and the Distinguished Encoding Rules (DER) 55 [X.509-88]. 57 1.1 Terminology 59 In this document, the key words MUST, MUST NOT, REQUIRED, SHOULD, 60 SHOULD NOT, RECOMMENDED, MAY, and OPTIONAL are to be interpreted as 61 described in [STDWORDS]. 63 1.2 Version Numbers 65 The major data structure (AuthEnvelopedData) includes a version 66 number as the first item in the data structure. The version number 67 is intended to avoid ASN.1 decode errors. Some implementations do 68 not check the version number prior to attempting a decode, and if a 69 decode error occurs, then the version number is checked as part of 70 the error handling routine. This is a reasonable approach; it places 71 error processing outside of the fast path. This approach is also 72 forgiving when an incorrect version number is used by the sender. 74 Whenever the structure is updated, a higher version number will be 75 assigned. However, to ensure maximum interoperability the higher 76 version number is only used when the new syntax feature is employed. 77 That is, the lowest version number that supports the generated syntax 78 is used. 80 2. Authenticated-enveloped-data Content Type 82 The authenticated-enveloped-data content type consists of an 83 authenticated and encrypted content of any type and encrypted 84 content-encryption keys for one or more recipients. The combination 85 of the authenticated and encrypted content and one encrypted content- 86 authenticated-encryption key for a recipient is a "digital envelope" 87 for that recipient. Any type of content can be enveloped for an 88 arbitrary number of recipients using any of the supported key 89 management techniques for each recipient. In addition, authenticated 90 but not encrypted attributes may be provided by the originator. 92 The typical application of the authenticated-enveloped-data content 93 type will represent one or more recipients' digital envelopes on an 94 encapsulated content. 96 Authenticated-enveloped-data is constructed by the following steps: 98 1. A content-encryption key for a particular content- 99 authenticated-encryption algorithm is generated at random. 101 2. The content-authenticated-encryption key is encrypted for each 102 recipient. The details of this encryption depend on the key 103 management algorithm used, but four general techniques are 104 supported: 106 key transport: the content-authenticated-encryption key is 107 encrypted in the recipient's public key; 109 key agreement: the recipient's public key and the sender's 110 private key are used to generate a pairwise symmetric key, 111 then the content-authenticated-encryption key is encrypted 112 in the pairwise symmetric key; 114 symmetric key-encryption keys: the content-authenticated- 115 encryption key is encrypted in a previously distributed 116 symmetric key-encryption key; and 118 passwords: the content-authenticated-encryption key is 119 encrypted in a key-encryption key that is derived from a 120 password or other shared secret value. 122 3. For each recipient, the encrypted content-authenticated- 123 encryption key and other recipient-specific information are 124 collected into a RecipientInfo value, defined in Section 6.2 of 125 [CMS]. 127 4. Any attributes that are to be authenticated but not encrypted 128 are collected in the authenticated attributes. 130 5. The attributes collected in step 4 are authenticated and the 131 content is authenticated and encrypted with the content- 132 authenticated-encryption key. If the authenticated encryption 133 algorithm requires the content to be padded to a multiple of some 134 block size, then the padding is added as described in Section 6.3 135 of [CMS]. 137 6. Any attributes that are to be provided without authentication 138 or encryption are collected in the unauthenticated attributes. 140 7. The RecipientInfo values for all the recipients, the 141 authenticated attributes, then unauthenticated attributes, and the 142 authenticated and encrypted content are collected together to form 143 an AuthEnvelopedData value as defined in Section 2.1. 145 A recipient opens the digital envelope by decrypting one of the 146 encrypted content-authenticated-encryption keys, and then using the 147 recovered key to decrypt and verify the integrity of the 148 authenticated and encrypted content as well as verifying the 149 integrity of the authenticated attributes. 151 This section is divided into three parts. The first part describes 152 the AuthEnvelopedData content type, the second part describes the 153 authentication and encryption process, and third part describes the 154 key encryption process. 156 2.1 AuthEnvelopedData Type 158 The following object identifier identifies the authenticated- 159 enveloped-data content type: 161 id-ct-authEnvelopedData OBJECT IDENTIFIER ::= { iso(1) 162 member-body(2) us(840) rsadsi(113549) pkcs(1) pkcs-9(9) 163 smime(16) ct(1) 23 } 165 The authenticated-enveloped-data content type MUST have ASN.1 type 166 AuthEnvelopedData: 168 AuthEnvelopedData ::= SEQUENCE { 169 version CMSVersion, 170 originatorInfo [0] IMPLICIT OriginatorInfo OPTIONAL, 171 recipientInfos RecipientInfos, 172 authAttrs [1] IMPLICIT AuthAttributes OPTIONAL, 173 authEncryptedContentInfo EncryptedContentInfo, 174 mac MessageAuthenticationCode, 175 unauthAttrs [2] IMPLICIT UnauthAttributes OPTIONAL } 177 The fields of type AuthEnvelopedData have the following meanings: 179 version is the syntax version number. It MUST be set to 0. 181 originatorInfo optionally provides information about the 182 originator. It is present only if required by the key management 183 algorithm. It may contain certificates and CRLs, and the 184 OriginatorInfo type is defined in Section 6.1 of [CMS]. 186 recipientInfos is a collection of per-recipient information. 187 There MUST be at least one element in the collection. The 188 RecipientInfo type is defined in Section 6.2 of [CMS]. 190 authAttrs optionally contains the authenticated attributes. The 191 AuthenticatedData content type uses the same type to carry 192 authenticated attributes. The AuthAttributes type is defined in 193 Section 9.1 of [CMS]. Useful attribute types are defined in 194 Section 11 of [CMS]. 196 authEncryptedContentInfo is the authenticated and encrypted 197 content. The EnvelopedData content type uses the same type to 198 carry the encrypted content. The EncryptedContentInfo type is 199 defined in Section 6.1 of [CMS]. 201 mac is the integrity check value (ICV) or message authentication 202 code (MAC) that is generated by the authenticated encryption 203 algorithm. The AuthenticatedData content type uses the same type 204 to carry a MAC. In this case, the MAC covers the authenticated 205 attributes and the content directly, and a digest algorithm is not 206 used. The MessageAuthenticationCode type is defined in Section 9.1 207 of [CMS]. 209 unauthAttrs optionally contains the unauthenticated attributes. 210 The AuthenticatedData content type uses the same type to carry 211 unauthenticated attributes. The UnauthAttributes type is defined 212 in Section 9.1 of [CMS]. Useful attribute types are defined in 213 Section 11 of [CMS]. 215 2.2. Authentication and Encryption Process 217 The content-authenticated-encryption key for the desired content- 218 authenticated-encryption algorithm is randomly generated. 220 If the authenticated encryption algorithm requires the content to be 221 padded to a multiple of some block size, then the padding MUST be 222 added as described in Section 6.3 of [CMS]. This padding method is 223 well defined if and only if number of octets in the block size is 224 less than 256. 226 If optional authenticated attributes are present, then they are DER 227 encoded. The result will be used as the authenticated associated 228 data (AAD) input to the authenticated encryption algorithm. 230 The inputs to the authenticated encryption algorithm are the content 231 (the data, which is padded if necessary), the DER-encoded 232 authenticated attributes (the AAD), and the content-authenticated- 233 encryption key. Under control of a content-authenticated-encryption 234 key, the authenticated encryption operation maps an arbitrary string 235 of octets (the data) to another string of octets (the ciphertext) and 236 it computes an authentication tag over the AAD and the data. The 237 encrypted data is included in the AuthEnvelopedData 238 encryptedContentInfo encryptedContent OCTET STRING, and the 239 authentication tag is included in the AuthEnvelopedData mac. 241 2.3. Key Encryption Process 243 The input to the key encryption process -- the value supplied to the 244 recipient's key-encryption algorithm -- is just the "value" of the 245 content-authenticated-encryption key. 247 Any of the aforementioned key management techniques can be used for 248 each recipient of the same encrypted content. 250 3. Security Considerations 252 This specification defines and additional CMS content type. The 253 security considerations provided in [CMS] apply to this content type 254 as well. 256 Many authenticated encryption algorithms make use of a block cipher 257 in counter mode to provide encryption. When used properly, counter 258 mode provides strong confidentiality. Bellare, Desai, Jokipii, 259 Rogaway show in [BDJR] that the privacy guarantees provided by 260 counter mode are at least as strong as those for CBC mode when using 261 the same block cipher. 263 Unfortunately, it is easy to misuse counter mode. If counter block 264 values are ever used for more that one encryption operation with the 265 same key, then the same key stream will be used to encrypt both 266 plaintexts, and the confidentiality guarantees are voided. 268 Fortunately, the CMS AuthEnvelopedData provides all of the tools 269 needed to avoid misuse of counter mode. When using key transport or 270 key agreement, a fresh key should be generated for each content. 271 However, when using symmetric key-encryption keys or passwords, one 272 cannot assume that a fresh key is generated. Therefore, 273 authenticated encryption algorithms that make use of counter mode 274 must support the use of an unpredictable nonce value in the counter 275 block, and this unpredictable nonce value (sometimes called a "salt") 276 must be carried as an algorithm identifier parameter. 278 There are fairly generic precomputation attacks against all block 279 cipher modes that allow a meet-in-the-middle attack against the key. 280 These attacks require the creation and searching of huge tables of 281 ciphertext associated with known plaintext and known keys. Assuming 282 that the memory and processor resources are available for a 283 precomputation attack, then the theoretical strength of any block 284 cipher mode is limited to 2^(n/2) bits, where n is the number of bits 285 in the key. The use of long keys is the best countermeasure to 286 precomputation attacks. Use of an unpredictable nonce value in the 287 counter block significantly increases the size of the table that the 288 attacker must compute to mount a successful precomputation attack. 290 Implementations must randomly generate content-authenticated- 291 encryption keys, padding, and unpredictable nonce values. Also, the 292 generation of public/private key pairs relies on a random numbers. 293 The use of inadequate pseudo-random number generators (PRNGs) to 294 generate cryptographic keys can result in little or no security. An 295 attacker may find it much easier to reproduce the PRNG environment 296 that produced the keys, searching the resulting small set of 297 possibilities, rather than brute force searching the whole key space. 298 The generation of quality random numbers is difficult. RFC 4086 299 [RANDOM] offers important guidance in this area. 301 4 ASN.1 Module 303 CMS-AuthEnvelopedData-2007 304 { iso(1) member-body(2) us(840) rsadsi(113549) pkcs(1) 305 pkcs-9(9) smime(16) modules(0) cms-authEnvelopedData(31) } 307 DEFINITIONS IMPLICIT TAGS ::= 308 BEGIN 310 -- EXPORTS All 311 -- The types and values defined in this module are exported for use 312 -- in the other ASN.1 modules. Other applications may use them for 313 -- their own purposes. 315 IMPORTS 317 -- Imports from RFC 3852 [CMS], Section 12.1 318 AuthAttributes, CMSVersion, EncryptedContentInfo, 319 MessageAuthenticationCode, OriginatorInfo, RecipientInfos, 320 UnauthAttributes 321 FROM CryptographicMessageSyntax2004 322 { iso(1) member-body(2) us(840) rsadsi(113549) 323 pkcs(1) pkcs-9(9) smime(16) modules(0) 324 cms-2004(24) } ; 326 id-ct-authEnvelopedData OBJECT IDENTIFIER ::= { iso(1) 327 member-body(2) us(840) rsadsi(113549) pkcs(1) pkcs-9(9) 328 smime(16) ct(1) 23 } 330 AuthEnvelopedData ::= SEQUENCE { 331 version CMSVersion, 332 originatorInfo [0] IMPLICIT OriginatorInfo OPTIONAL, 333 recipientInfos RecipientInfos, 334 authAttrs [1] IMPLICIT AuthAttributes OPTIONAL, 335 authEncryptedContentInfo EncryptedContentInfo, 336 mac MessageAuthenticationCode, 337 unauthAttrs [2] IMPLICIT UnauthAttributes OPTIONAL } 339 END -- of CMS-AuthEnvelopedData-2007 341 5. Normative References 343 [CMS] Housley, R., "Cryptographic Message Syntax", 344 RFC 3852, July 2004. 346 [STDWORDS] Bradner, S., "Key Words for Use in RFCs to Indicate 347 Requirement Levels", BCP 14, RFC 2119, March 1997. 349 [X.208-88] CCITT. Recommendation X.208: Specification of Abstract 350 Syntax Notation One (ASN.1). 1988. 352 [X.209-88] CCITT. Recommendation X.209: Specification of Basic 353 Encoding Rules for Abstract Syntax Notation One (ASN.1). 354 1988. 356 [X.509-88] CCITT. Recommendation X.509: The Directory - 357 Authentication Framework. 1988. 359 6. Informative References 361 [BDJR] Bellare, M, Desai, A., Jokipii, E., and P. Rogaway, 362 "A Concrete Security Treatment of Symmetric Encryption: 363 Analysis of the DES Modes of Operation", Proceedings 364 38th Annual Symposium on Foundations of Computer 365 Science, 1997. 367 [RANDOM] Eastlake, D., Schiller, J., and S. Crocker, "Randomness 368 Recommendations for Security", RFC 4086, June 2005. 370 7. Authors' Address 372 Russell Housley 373 Vigil Security, LLC 374 918 Spring Knoll Drive 375 Herndon, VA 20170 376 USA 377 EMail: housley@vigilsec.com 379 Full Copyright Statement 381 Copyright (C) The Internet Society (2007). 383 This document is subject to the rights, licenses and restrictions 384 contained in BCP 78, and except as set forth therein, the authors 385 retain all their rights. 387 This document and translations of it may be copied and furnished to 388 others, and derivative works that comment on or otherwise explain it 389 or assist in its implementation may be prepared, copied, published and 390 distributed, in whole or in part, without restriction of any kind, 391 provided that the above copyright notice and this paragraph are 392 included on all such copies and derivative works. However, this 393 document itself may not be modified in any way, such as by removing 394 the copyright notice or references to the Internet Society or other 395 Internet organizations, except as needed for the purpose of 396 developing Internet standards in which case the procedures for 397 copyrights defined in the Internet Standards process must be 398 followed, or as required to translate it into languages other than 399 English. 401 The limited permissions granted above are perpetual and will not be 402 revoked by the Internet Society or its successors or assigns. 404 This document and the information contained herein 405 are provided on an "AS IS" basis and THE CONTRIBUTOR, THE 406 ORGANIZATION HE/SHE REPRESENTS OR IS SPONSORED BY (IF ANY), THE 407 INTERNET SOCIETY, (THE IETF TRUST) AND THE INTERNET ENGINEERING 408 TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING 409 BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION 410 HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF 411 MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.