idnits 2.17.1 draft-ietf-smime-idea-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: ---------------------------------------------------------------------------- ** 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 Internet-Drafts being working documents. == No 'Intended status' indicated for this document; assuming Proposed Standard == The page length should not exceed 58 lines per page, but there was 1 longer page, the longest (page 1) being 339 lines Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- ** The document seems to lack an Abstract section. ** The document seems to lack a Security Considerations section. ** 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 2 characters in excess of 72. ** The document seems to lack a both a reference to RFC 2119 and the recommended RFC 2119 boilerplate, even if it appears to use RFC 2119 keywords. RFC 2119 keyword, line 65: '...ument, the terms MUST, MUST NOT, SHOUL...' RFC 2119 keyword, line 104: '...IV OCTET STRING OPTIONAL -- exactly 8...' RFC 2119 keyword, line 106: '...ied as above, it MUST be used as initi...' RFC 2119 keyword, line 107: '..., the ciphertext MUST NOT include the ...' RFC 2119 keyword, line 108: '...irst 64 bits of the ciphertext MUST be...' (12 more instances...) Miscellaneous warnings: ---------------------------------------------------------------------------- -- 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.) -- Couldn't find a document date in the document -- date freshness check skipped. Checking references for intended status: Proposed Standard ---------------------------------------------------------------------------- (See RFCs 3967 and 4897 for information about using normative references to lower-maturity documents in RFCs) -- Missing reference section? 'IDEA' on line 256 looks like a reference -- Missing reference section? 'SMIME2' on line 232 looks like a reference -- Missing reference section? 'SMIME3' on line 235 looks like a reference -- Missing reference section? 'MUSTSHOULD' on line 238 looks like a reference -- Missing reference section? 'CMS' on line 241 looks like a reference -- Missing reference section? 'PKCS7' on line 243 looks like a reference Summary: 8 errors (**), 0 flaws (~~), 2 warnings (==), 8 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 1 Internet Draft S. Teiwes, 2 draft-ietf-smime-idea-02.txt P. Hartmann, 3 February 22, 1999 D. Kuenzi, 4 Expires in six months iT_Security Ltd. 6 Incorporation of the IDEA Encryption Algorithm in S/MIME 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. Internet-Drafts are 12 working documents of the Internet Engineering Task Force (IETF), 13 its areas, and its working groups. Note that other groups may also 14 distribute working documents as Internet-Drafts. 16 Internet-Drafts are draft documents valid for a maximum of six 17 months and may be updated, replaced, or obsoleted by other documents 18 at any time. It is inappropriate to use Internet-Drafts as reference 19 material or to cite them other than as "work in progress." 21 The list of current Internet-Drafts can be accessed at 22 http://www.ietf.org/ietf/1id-abstracts.txt 24 The list of Internet-Draft Shadow Directories can be accessed at 25 http://www.ietf.org/shadow.html. 27 To view the entire list of current Internet-Drafts, please check the 28 "1id-abstracts.txt" listing contained in the Internet-Drafts Shadow 29 Directories on ftp.is.co.za (Africa), ftp.nordu.net (Northern 30 Europe), ftp.nis.garr.it (Southern Europe), munnari.oz.au (Pacific 31 Rim), ftp.ietf.org (US East Coast), or ftp.isi.edu (US West Coast). 33 1. Introduction 35 This memo specifies how to incorporate IDEA (International Data 36 Encryption Algorithm) [IDEA] into S/MIME [SMIME2, SMIME3] as an 37 additional algorithm for symmetric encryption. Today, IDEA is widely 38 applied in electronic business applications. But it is not 39 considered in the specification [SMIME3]. Encryption algorithms are 40 part of an organizations' security policy. Typically, organizations 41 like to have their own preferences in this respect. Therefore, it is 42 beneficial to have the choice between different well-known encryption 43 algorithms. Especially for those organization who make already use 44 of IDEA on a wide scale it is of high interest that IDEA is also 45 available in S/MIME. It is the intention of this memo to provide the 46 OIDs and algorithms required to include IDEA in S/MIME for symmetric 47 content and key encryption. 49 The general functional capabilities and preferences of S/MIME are 50 specified by the registered list of S/MIME object identifiers (OIDs). 51 This list of OIDs is maintained by the Internet Mail Consortium at 52 . 53 The set of S/MIME functions provided by a client is expressed by the 54 S/MIME capabilities attribute. This attribute contains a list of OIDs 55 of supported cryptographic functions. 57 This draft is being discussed on the "ietf-smime" mailing list. To 58 subscribe, send a message to: 59 ietf-smime-request@imc.org 60 with the single word 61 subscribe 62 in the body of the message. There is a Web site for the mailing list 63 at 65 In this document, the terms MUST, MUST NOT, SHOULD, and SHOULD NOT 66 are used in capital letters. This conforms to the definitions in 67 [MUSTSHOULD]. 69 2. Object Identifier for Content and Key Encryption 71 The Cryptographic Message Syntax [CMS], derived from PKCS#7 [PKCS7], 72 is the framework for the implementation of cryptographic functions in 73 S/MIME. It specifies data formats and encryption processes without 74 naming the cryptographic algorithms. Each algorithm which is used 75 for encryption purposes must be specified by a unique algorithm 76 identifier. For example, in the special case of content encryption 77 the ContentEncryptionAlgorithmIdentifier specifies the algorithm to 78 be applied. However, according to [CMS] any symmetric encryption 79 algorithm that a CMS implementation includes as a content-encryption 80 algorithm must also be included as a key-encryption algorithm. 82 IDEA is added to the set of optional symmetric encryption algorithms 83 in S/MIME by providing two unique object identifiers (OIDs). One OID 84 defines content encryption and the other one key encryption. Thus an 85 S/MIME agent can apply IDEA either for content or key encryption by 86 selecting the corresponding object identifier, supplying the required 87 parameter, and starting the program code. 89 For content encryption the use of IDEA in cipher block chaining (CBC) 90 mode is recommended. The key length is fixed to 128 bits. 92 The IDEA content-encryption algorithm in CBC mode has the object 93 identifier 95 IDEA-CBC OBJECT IDENTIFIER 96 ::= { iso(1) identified-organization(3) 97 usdod(6) oid(1) private(4) enterprises(1) 98 ascom(188) systec(7) security(1) algorithms(1) 2 } 100 The identifier's parameters field contains the initial 101 vector IV as an optional parameter. 103 IDEA-CBCPar ::= SEQUENCE { 104 IV OCTET STRING OPTIONAL -- exactly 8 octets } 106 If IV is specified as above, it MUST be used as initial vector. In 107 this case, the ciphertext MUST NOT include the initial vector. If 108 IV is not specified, the first 64 bits of the ciphertext MUST be 109 considered as the initial vector. However, this alternative of not 110 including the IV SHOULD NOT be applied in S/MIME. 112 The key-wrap/unwrap algorithms used to encrypt/decrypt an IDEA 113 content-encryption key with an IDEA key-encryption key are 114 specified in the following section. Generation and distribution 115 of IDEA key-encryption keys are beyond the scope of this document. 117 The IDEA key-encryption algorithm has the object identifier 119 id-alg-CMSIDEAwrap OBJECT IDENTIFIER 120 ::= { iso(1) identified-organization(3) 121 usdod(6) oid(1) private(4) enterprises(1) 122 ascom(188) systec(7) security(1) algorithms(1) 6 } 124 The identifier's parameters field MUST be NULL. 126 3. Key-Wrapping and Unwrapping 128 In the following subsections IDEA key-wrap and key-unwrap algorithms 129 are specified in conformance with [CMS], section 12.3. 131 3.1 IDEA Key Wrap 133 The IDEA key-wrap algorithm encrypts an IDEA content-encryption key 134 with an IDEA key-encryption key. The IDEA key-wrap algorithm is 135 defined by: 137 1. Let the content-encryption key (16 octets) be called CEK 138 2. Compute an 8 octet key checksum value on CEK as described 139 in [CMS], section 12.6.1, call the result ICV. 140 3. Let CEKICV := CEK || ICV. 141 4. Generate 8 octets at random, call the result IV. 142 5. Encrypt CEKICV using IDEA in CBC mode and the key-encryption key. 143 Use the random value generated in the previous step as the 144 initialization vector (IV). Call the ciphertext TEMP1. 145 6. Let TEMP2 = IV || TEMP1. 146 7. Reverse the order of the octets in TEMP2. That is, the most 147 significant (first) octet is swapped with the least significant 148 (last) octet, and so on. Call the result TEMP3. 149 8. Encrypt TEMP3 using IDEA in CBC mode and the key-encryption key. 150 Use an initialization vector (IV) of 0x4adda22c79e82105. 151 The ciphertext is 32 octets long. 153 3.2 IDEA Key Unwrap 155 The IDEA key-unwrap algorithm decrypts an IDEA content-encryption key 156 using an IDEA key-encryption key. The IDEA key-unwrap algorithm is 157 defined by: 159 1. If the wrapped content-encryption key is not 32 octets, then 160 error. 161 2. Decrypt the wrapped content-encryption key using IDEA in CBC mode 162 with the key-encryption key. Use an initialization vector (IV) 163 of 0x4adda22c79e82105. Call the output TEMP3. 164 3. Reverse the order of the octets in TEMP3. That is, the most 165 significant (first) octet is swapped with the least significant 166 (last) octet, and so on. Call the result TEMP2. 167 4. Decompose the TEMP2 into IV and TEMP1. IV is the most significant 168 (first) 8 octets, and TEMP1 is the remaining (last) 24 octets. 169 5. Decrypt TEMP1 using IDEA in CBC mode with the key-encryption key. 170 Use the IV value from the previous step as the initialization 171 vector. Call the plaintext CEKICV. 172 6. Decompose the CEKICV into CEK and ICV. CEK is the most 173 significant (first) 16 octets, and ICV is the least significant 174 (last) 8 octets. 175 7. Compute an 8 octet key checksum value on CEK as described 176 in [CMS], section 12.6.1. If the computed key checksum value 177 does not match the decrypted key checksum value, ICV, then error. 178 8. Use CEK as the content-encryption key. 180 4. SMIMECapabilities Attribute 182 An S/MIME client can announce the set of cryptographic functions 183 it supports by using the S/MIME capabilities attribute as specified 184 in [SMIME3]. This attribute provides a partial list of OIDs of 185 cryptographic functions and must be signed by the client. These OIDs 186 should be logically separated in functional categories and MUST be 187 ordered with respect to their preference. If an S/MIME client is 188 required to support symmetric encryption and key wrapping based on 189 IDEA, the capabilities attribute MUST contain the above specified 190 OIDs in the category of symmetric algorithms and key encipherment 191 algorithms. IDEA does not require additional OID parameters since 192 it has a fixed key length of 128 bits. 194 The SMIMECapability SEQUENCE representing the IDEA symmetric 195 encrytion algorithm MUST include the IDEA-CBC OID in the capabilityID 196 field and the parameters field MUST be absent. The SMIMECapability 197 SEQUENCE for IDEA encryption SHOULD be included in the symmetric 198 encryption algorithms portion of the SMIMECapabilities list. The 199 SMIMECapability SEQUENCE representing IDEA MUST be DER-encoded as 200 follows: 300F 060B 2B06 0104 0181 3C07 0101 0205 00. 202 The SMIMECapability SEQUENCE representing the IDEA key wrapping 203 algorithm MUST include the id-alg-CMSIDEAwrap OID in the capabilityID 204 field and the parameters field of KeyWrapAlgorithm MUST be absent. 205 The SMIMECapability SEQUENCE for IDEA key wrapping SHOULD be included 206 in the key encipherment algorithms portion of the SMIMECapabilities 207 list. The SMIMECapability SEQUENCE representing IDEA key wrapping 208 MUST be DER-encoded as follows: 300F 060B 2B06 0104 0181 3C07 0101 209 0605 00. 211 5. Activation of IDEA in S/MIME 213 When a sending agent creates an encrypted message, it has to decide 214 which type of encryption algorithm to use. In general the decision 215 process involves information obtained from the capabilities lists 216 included in messages received from the recipient, as well as other 217 information such as private agreements, user preferences, legal 218 restrictions, etc. If users require IDEA for symmetric encryption, 219 it must be supported by the S/MIME clients on both the sending and 220 receiving side, and it must be set in the user preferences. 222 A. References 224 [IDEA] X. Lai, "On the design and security of block ciphers", ETH 225 Series in Information Processing, J.L. Massey (editor), vol. 1, 226 Hartung-Gorre Verlag Konstanz, Technische Hochschule (Zurich), 1992. 227 A. J. Menezes, P.C. v. Oorschot, S.A. Vanstone, "Handbook of Applied 228 Cryptography," CRC Press New York, 1997, p. 265. 229 B. Schneier, "Applied Cryptography," 2nd ed., John Wiley & Sons Inc. 230 New York, 1996, pp. 319-325. 232 [SMIME2] "S/MIME Version 2 Message Specification", RFC 2311, and 233 "S/MIME Version 2 Certificate Handling", RFC 2312. 235 [SMIME3] "S/MIME Version 3 Certificate Handling", RFC 2632, and 236 "S/MIME Version 3 Message Specification", RFC 2633. 238 [MUSTSHOULD] "Key words for use in RFCs to Indicate Requirement 239 Levels", RFC 2119. 241 [CMS] "Cryptographic Message Syntax", RFC 2630. 243 [PKCS7] "PKCS #7: Cryptographic Message Syntax Version 1.5", 244 RFC 2315. 246 B. Comments on IDEA Security and Standards 248 The IDEA algorithm was developed in a joint project involving the 249 Swiss Federal Institute of Technology in Zurich (Dr. X. Lai and 250 Prof. J.L. Massey) and Ascom Ltd. The aim of the project was to 251 develop an encryption algorithm which would replace the DES 252 algorithm. 254 IDEA uses 128-bit secret keys and encrypts one 64-bit block at a 255 time. Experts in cryptography consider IDEA to be a highly secure 256 symmetric cipher [IDEA]. It was particularly strengthened to protect 257 against differential cryptoanalysis attacks. For the full 8-round 258 IDEA there is no attack known which is better than exhaustive search 259 on the total 128-bit key space. 261 IDEA permits the implementation of standard Electronic Data 262 Interchange applications. It has been entered in the ISO/IEC register 263 for encryption algorithms and incorporated in the "SECURITY GUIDE 264 LINES" code list by the UNI/EDIFACT "SECURITY JOINT WORKING GROUP". 266 More information on IDEA can be found at 267 . 269 C. Intellectual Property Notice 271 IDEA (TM) is protected by international copyright law and in addition 272 it has been patented in the United States, Japan, and in most of the 273 European countries. The patent is held by Ascom Ltd. 275 Non-commercial use of IDEA is free. 276 Commercial licenses can be easily obtained via online order or by 277 contacting idea@it-sec.com. Detailed licensing information can be found 278 at . 280 D. Acknowledgements 282 We would like to thank Jim Schaad and Francois Zeller for their 283 contributions to this document. 285 E. Authors' Address 287 iT_Security Ltd. 288 Badenerstrasse 530 290 CH-8048 Zurich, Switzerland 292 Phone: +41 1 236 9900 293 Fax : +41 1 236 9990 294 Email: {stephan.teiwes,peter.hartmann,diego.kuenzi}@it-sec.com 296 F. Full Copyright Statement 298 Copyright (C) The Internet Society (date). All Rights Reserved. 299 This document and translations of it may be copied and furnished to 300 others, and derivative works that comment on or otherwise explain it 301 or assist in its implementation may be prepared, copied, published 302 and distributed, in whole or in part, without restriction of any 303 kind, provided that the above copyright notice and this paragraph 304 are included on all such copies and derivative works. However, this 305 document itself may not be modified in any way, such as by removing 306 the copyright notice or references to the Internet Society or other 307 Internet organizations, except as needed for the purpose of 308 developing Internet standards in which case the procedures for 309 copyrights defined in the Internet Standards process shall be 310 followed, or as required to translate it into languages other than 311 English. 313 The limited permissions granted above are perpetual and will not be 314 revoked by the Internet Society or its successors or assigns. This 315 document and the information contained herein is provided on an "AS 316 IS" basis and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING TASK 317 FORCE DISCLAIMS ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING BUT 318 NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION HEREIN 319 WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF 320 MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.