idnits 2.17.1 draft-ietf-smime-cast-128-02.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- ** Looks like you're using RFC 2026 boilerplate. This must be updated to follow RFC 3978/3979, as updated by RFC 4748. Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- == No 'Intended status' indicated for this document; assuming Proposed Standard == It seems as if not all pages are separated by form feeds - found 0 form feeds but 6 pages 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.) ** The document seems to lack separate sections for Informative/Normative References. All references will be assumed normative when checking for downward references. ** The abstract seems to contain references ([RFC2144], [RFC2119], [RFC2630]), which it shouldn't. Please replace those with straight textual mentions of the documents in question. 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 -- however, there's a paragraph with a matching beginning. Boilerplate error? (The document does seem to have the reference to RFC 2119 which the ID-Checklist requires). -- 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 (April 2000) is 8777 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) == Unused Reference: 'SMIME2' is defined on line 209, but no explicit reference was found in the text == Unused Reference: 'SMIME3' is defined on line 216, but no explicit reference was found in the text -- Possible downref: Non-RFC (?) normative reference: ref. 'Adams' -- Possible downref: Non-RFC (?) normative reference: ref. 'IPR' ** Downref: Normative reference to an Informational RFC: RFC 2144 ** Obsolete normative reference: RFC 2630 (Obsoleted by RFC 3369, RFC 3370) ** Downref: Normative reference to an Historic RFC: RFC 2312 (ref. 'SMIME2') ** Obsolete normative reference: RFC 2633 (ref. 'SMIME3') (Obsoleted by RFC 3851) Summary: 8 errors (**), 0 flaws (~~), 6 warnings (==), 4 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 1 Internet Draft Carlisle Adams (Entrust Technologies) 2 S/MIME Working Group 3 Expires in 6 months April 2000 5 Use of the CAST-128 Encryption Algorithm in CMS 6 8 Status of this Memo 10 This document is an Internet-Draft and is in full conformance with 11 all provisions of Section 10 of RFC2026. 13 Internet-Drafts are working documents of the Internet Engineering 14 Task Force (IETF), its areas, and its working groups. Note that other 15 groups may also distribute working documents as Internet-Drafts. 17 Internet-Drafts are draft documents valid for a maximum of six months 18 and may be updated, replaced, or obsoleted by other documents at any 19 time. It is inappropriate to use Internet-Drafts as reference 20 material or to cite them other than as "work in progress." 22 The list of current Internet-Drafts can be accessed at 23 http://www.ietf.org/ietf/1id-abstracts.txt 25 The list of Internet-Draft Shadow Directories can be accessed at 26 http://www.ietf.org/shadow.html. 28 This Internet-Draft will expire in October, 2000. Comments or 29 suggestions for improvement may be made on the "ietf-smime" mailing 30 list, or directly to the author. 32 Copyright Notice 34 Copyright (C)The Internet Society (2000). All Rights Reserved. 36 Abstract 38 This document specifies how to incorporate CAST-128 [RFC2144] into 39 the S/MIME Cryptographic Message Syntax (CMS) as an additional 40 algorithm for symmetric encryption. The relevant OIDs and processing 41 steps are provided so that CAST-128 may be included in the CMS 42 specification [RFC2630] for symmetric content and key encryption. 44 The key words "MUST", "MUST NOT", "REQUIRED", "SHOULD", "SHOULD NOT", 45 "RECOMMENDED", "MAY", and "OPTIONAL" in this document (in uppercase, 46 as shown) are to be interpreted as described in [RFC2119]. 48 1. Motivation 50 S/MIME (Secure/Multipurpose Internet Mail Extensions) [SMIME2, 51 SMIME3] is a set of specifications for the secure transport of MIME 52 objects. In the current (S/MIME v3) specifications the mandatory- 53 to-implement symmetric algorithm for content encryption and key 54 encryption is triple-DES (3DES). While this is perfectly acceptable 55 in many cases because the security of 3DES is generally considered to 56 be high, for some environments 3DES may be seen to be too slow. In 57 part to help alleviate such performance concerns, S/MIME has allowed 58 any number of (optional) additional algorithms to be used for 59 symmetric content and key encryption. 61 The CAST-128 encryption algorithm [RFC2144, Adams] is a well-studied 62 symmetric cipher that has a number of appealing features, including 63 relatively high performance and a variable key size (from 40 bits 64 to 128 bits). It is available royalty-free and license-free for 65 commercial and non-commercial uses worldwide [IPR], and therefore 66 is widely used in a number of applications around the Internet. It 67 thus seems to be a suitable optional encryption algorithm for S/MIME. 69 This document describes how to use CAST-128 within the S/MIME CMS 70 specification. 72 2. Specification 74 This section provides the OIDs and processing information necessary 75 for CAST-128 to be used for content and key encryption in CMS. 77 2.1 OIDs for Content and Key Encryption 79 CAST-128 is added to the set of optional symmetric encryption 80 algorithms in CMS by providing two unique object identifiers 81 (OIDs). One OID defines the content encryption algorithm and the 82 other defines the key encryption algorithm. Thus a CMS agent can 83 apply CAST-128 either for content or key encryption by selecting the 84 corresponding object identifier, supplying the required parameter, and 85 starting the program code. 87 For content encryption the use of CAST-128 in cipher block chaining 88 (CBC) mode is RECOMMENDED. The key length is variable (from 40 to 128 89 bits in 1-octet increments). 91 The CAST-128 content-encryption algorithm in CBC mode has the 92 following object identifier: 94 cast5CBC OBJECT IDENTIFIER ::= {iso(1) member-body(2) 95 us(840) nt(113533) nsn(7) algorithms(66) 10} 97 The parameter associated with this object identifier contains the 98 initial vector IV and the key length: 100 cast5CBCParameters ::= SEQUENCE { 101 iv OCTET STRING DEFAULT 0, 102 -- Initialization vector 103 keyLength INTEGER 104 -- Key length, in bits 105 } 107 Comments regarding the use of the IV may be found in [RFC2144]. 109 The key-wrap/unwrap procedures used to encrypt/decrypt a CAST-128 110 content-encryption key with a CAST-128 key-encryption key are 111 specified in the Section 2.2. Generation and distribution of 112 key-encryption keys are beyond the scope of this document. 114 The CAST-128 key-encryption algorithm has the following object 115 identifier: 117 cast5CMSkeywrap OBJECT IDENTIFIER ::= { iso(1) 118 member-body(2) us(840) nt(113533) nsn(7) 119 algorithms(66) 15} 121 The parameter associated with this object identifier contains only 122 the key length (because the key wrapping procedure itself defines 123 how and when to use an IV): 125 cast5CMSkeywrapParameter ::= INTEGER 126 -- key length, in bits 128 2.2 Key Wrapping and Unwrapping 130 CAST-128 key wrapping and unwrapping is done in conformance with CMS 131 [RFC2630]. 133 2.2.1 CAST-128 Key Wrap 135 Key wrapping with CAST-128 is identical to [RFC2630], Sections 12.6.1 136 and 12.6.4, with "RC2" replaced by "CAST-128" in the introduction to 137 12.6.4. Only 128-bit CAST-128 keys may be used as key-encryption 138 keys, and they MUST be used with the cast5CMSkeywrapParameter set to 139 128. It is RECOMMENDED that the size of the content-encryption key 140 and the size of the key-encryption key be equal (since the security 141 of the content will be at most the smaller of these two values). 143 2.2.2 CAST-128 Key Unwrap 145 Key unwrapping with CAST-128 is identical to [RFC2630], Sections 146 12.6.1 and 12.6.5, with "RC2" replaced by "CAST-128" in the 147 introduction to 12.6.5. 149 3. Using CAST-128 in S/MIME Clients 151 An S/MIME client SHOULD announce the set of cryptographic functions 152 it supports by using the S/MIME capabilities attribute. This 153 attribute provides a partial list of OIDs of cryptographic functions 154 and MUST be signed by the client. The functions' OIDs SHOULD be 155 logically separated in functional categories and MUST be ordered with 156 respect to their preference. If an S/MIME client is required to 157 support symmetric encryption with CAST-128, the capabilities attribute 158 MUST contain the cast5CBC OID specified above in the category of 159 symmetric algorithms. The parameter associated with this OID (see 160 above) MUST be used to indicate supported key length. For example, 161 when the supported key length is 128 bits, the SMIMECapability 162 SEQUENCE representing CAST-128 MUST be DER-encoded as the following 163 hexadecimal string: 164 301106092A864886F67D07420A300402020080. 166 When a sending agent creates an encrypted message, it has to decide 167 which type of encryption algorithm to use. In general the decision 168 process involves information obtained from the capabilities lists 169 included in messages received from the recipient, as well as other 170 information such as private agreements, user preferences, legal 171 restrictions, and so on. If users require CAST-128 for symmetric 172 encryption, it MUST be supported by the S/MIME clients on both the 173 sending and receiving side, and it MUST be set in the user 174 preferences. 176 4. Security Considerations 178 This document specifies the use of the CAST-128 symmetric cipher for 179 encrypting the content of a CMS message and for encrypting the 180 symmetric key used to encrypt the content of a CMS message. 181 Although CAST-128 allows keys of variable length to be used, it must 182 be recognized that smaller key sizes (e.g., 40, 56, or 64 bits) may be 183 unacceptably weak for some environments. The use of larger key sizes 184 (e.g., 128 bits) is always RECOMMENDED (when relevant import, export, 185 or other laws permit). It is also RECOMMENDED that the size of the 186 content-encryption key and the size of the key-encryption key be equal 187 (since the security of the content will be at most the smaller of 188 these two values). 190 References 192 [Adams] C. Adams, "Constructing Symmetric Ciphers using the CAST 193 Design Procedure", Designs, Codes, and Cryptography, vol.12, 194 no.3, November 1997, pp.71-104. 196 [IPR] See the "IETF Page of Intellectual Property Rights Notices", 197 http://www.ietf.cnri.reston.va.us/ipr.html 199 [RFC2144] C. Adams, "The CAST-128 Encryption Algorithm", Internet 200 Request for Comments RFC 2144, May 1997. 202 [RFC2119] S. Bradner, "Key words for use in RFCs to Indicate 203 Requirement Levels", Internet Request for Comments RFC 2119, 204 March 1997. 206 [RFC2630] R. Housley, "Cryptographic Message Syntax", Internet 207 Request for Comments RFC 2630, June 1999. 209 [SMIME2] S. Dusse, P. Hoffman, B. Ramsdell, L. Lundblade, L. Repka, 210 "S/MIME Version 2 Message Specification", Internet Request 211 for Comments RFC 2311, March 1998. 212 S. Dusse, P. Hoffman, B. Ramsdell, J. Weinstein, "S/MIME 213 Version 2 Certificate Handling", Internet Request for 214 Comments RFC 2312, March 1998. 216 [SMIME3] B. Ramsdell, "S/MIME Version 3 Certificate Handling", 217 Internet Request for Comments RFC 2632, June 1999. 218 B. Ramsdell, "S/MIME Version 3 Message Specification", 219 Internet Request for Comments RFC 2633, June 1999. 221 Author's Address 223 Carlisle Adams 224 Entrust Technologies 225 750 Heron Road, Suite E08, 226 Ottawa, Ontario, Canada K1V 1A7 227 E-Mail: cadams@entrust.com 229 Full Copyright Statement 231 Copyright (C) The Internet Society (1999). All Rights Reserved. 233 This document and translations of it may be copied and furnished to 234 others, and derivative works that comment on or otherwise explain it 235 or assist in its implementation may be prepared, copied, published 236 and distributed, in whole or in part, without restriction of any 237 kind, provided that the above copyright notice and this paragraph are 238 included on all such copies and derivative works. However, this 239 document itself may not be modified in any way, such as by removing 240 the copyright notice or references to the Internet Society or other 241 Internet organizations, except as needed for the purpose of 242 developing Internet standards in which case the procedures for 243 copyrights defined in the Internet Standards process must be 244 followed, or as required to translate it into languages other than 245 English. 247 The limited permissions granted above are perpetual and will not be 248 revoked by the Internet Society or its successors or assigns. 250 This document and the information contained herein is provided on an 251 "AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING 252 TASK FORCE DISCLAIMS ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING 253 BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION 254 HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF 255 MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.