idnits 2.17.1 draft-ietf-smime-idea-00.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- ** Cannot find the required boilerplate sections (Copyright, IPR, etc.) in this document. Expected boilerplate is as follows today (2024-04-25) according to https://trustee.ietf.org/license-info : IETF Trust Legal Provisions of 28-dec-2009, Section 6.a: This Internet-Draft is submitted in full conformance with the provisions of BCP 78 and BCP 79. IETF Trust Legal Provisions of 28-dec-2009, Section 6.b(i), paragraph 2: Copyright (c) 2024 IETF Trust and the persons identified as the document authors. All rights reserved. IETF Trust Legal Provisions of 28-dec-2009, Section 6.b(i), paragraph 3: This document is subject to BCP 78 and the IETF Trust's Legal Provisions Relating to IETF Documents (https://trustee.ietf.org/license-info) in effect on the date of publication of this document. Please review these documents carefully, as they describe your rights and restrictions with respect to this document. Code Components extracted from this document must include Simplified BSD License text as described in Section 4.e of the Trust Legal Provisions and are provided without warranty as described in the Simplified BSD License. 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. ** The document seems to lack a 1id_guidelines paragraph about the list of current Internet-Drafts. ** The document seems to lack a 1id_guidelines paragraph about the list of Shadow Directories. == 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 232 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 are 2 instances of lines with control characters in the document. ** 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 52: '... According to S/MIME v3 [SMIME3] sending and receiving agents MUST...' RFC 2119 keyword, line 54: '... decryption. Receiving agents SHOULD also support RC2 [RC2] at a key...' RFC 2119 keyword, line 63: '...draft, the terms MUST, MUST NOT, SHOUL...' RFC 2119 keyword, line 100: '...ryption purposes MUST be specified by ...' RFC 2119 keyword, line 104: '...only that agents MUST provide DES EDE3...' (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 167 looks like a reference -- Missing reference section? 'SMIME2' on line 171 looks like a reference -- Missing reference section? 'SMIME3' on line 174 looks like a reference -- Missing reference section? 'MIME' on line 33 looks like a reference -- Missing reference section? '3DES' on line 186 looks like a reference -- Missing reference section? 'DES' on line 189 looks like a reference -- Missing reference section? 'RC2' on line 193 looks like a reference -- Missing reference section? 'MUSTSHOULD' on line 195 looks like a reference -- Missing reference section? 'PKCS7' on line 198 looks like a reference -- Missing reference section? 'MIME-SPEC' on line 178 looks like a reference Summary: 10 errors (**), 0 flaws (~~), 2 warnings (==), 12 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 Internet Draft S. Teiwes, 3 draft-ietf-smime-idea-00.txt P. Hartmann, 4 March 29, 1999 D. Kuenzi, 5 Expires in six months Ascom Systec Ltd. 7 Incorporation of IDEA encryption algorithm in S/MIME 9 Status of this memo 11 This document is an Internet-Draft. Internet-Drafts are working 12 documents of the Internet Engineering Task Force (IETF), its areas, 13 and its working groups. Note that other groups may also distribute 14 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 To view the entire list of current Internet-Drafts, please check the 22 "1id-abstracts.txt" listing contained in the Internet-Drafts Shadow 23 Directories on ftp.is.co.za (Africa), ftp.nordu.net (Northern 24 Europe), ftp.nis.garr.it (Southern Europe), munnari.oz.au (Pacific 25 Rim), ftp.ietf.org (US East Coast), or ftp.isi.edu (US West Coast). 27 1. Introduction 29 This memo describes how to incorporate the IDEA (International Data 30 Encryption Algorithm) [IDEA] encryption algorithm into S/MIME 31 (Secure/Multipurpose Internet Mail Extensions) [SMIME2, SMIME3]. The 32 S/MIME standard provides a consistent way to send and receive secure 33 MIME [MIME] data. Information security services are implemented on 34 the basis of a set of cryptographic functions. Thus, digital 35 signatures are used for secure authentication, non-repudiation of 36 origin, and data integrity, whereas data encryption is used to assure 37 data security and privacy. 39 S/MIME is constructed as an open system. Its functionality for 40 information security purposes can be flexibly extended to meet new 41 requirements. At the same time it is assured that extended systems 42 will be compatible with non-extended systems. 44 The general functional capabilities and preferences of S/MIME are 45 specified by the registered list of S/MIME object identifiers (OIDs). 46 This list of OIDs is maintained by the Internet Mail Consortium at 47 . 48 The set of S/MIME functions provided by a client is expressed by the 49 S/MIME capabilities attribute. This attribute contains a list of OIDs 50 of supported cryptographic functions. 52 According to S/MIME v3 [SMIME3] sending and receiving agents MUST 53 provide the DES EDE3 CBC [3DES] [DES] for content encryption and 54 decryption. Receiving agents SHOULD also support RC2 [RC2] at a key 55 size of 40 bits. However, there are no general restrictions on the 56 application of encryption algorithms in S/MIME as long as they are 57 specified by a valid object identifier. The ability of strong 58 encryption is of general interest, but it is of particular interest 59 for instance in electronic commerce applications. Thus, the extension 60 of the S/MIME capabilities by the strong and efficient IDEA 61 encryption algorithm is benificial. 63 Throughout this draft, the terms MUST, MUST NOT, SHOULD, and SHOULD 64 NOT are used in capital letters. This conforms to the definitions in 65 [MUSTSHOULD]. 67 This draft is being discussed on the "ietf-smime" mailing list. To 68 subscribe, send a message to: 69 ietf-smime-request@imc.org 70 with the single word 71 subscribe 72 in the body of the message. There is a Web site for the mailing list 73 at 75 2. Comments On The IDEA Encryption Algorithm 77 The IDEA algorithm was developed in a joint project involving the 78 Swiss Federal Institute of Technology in Zurich (Dr. X. Lai and 79 Prof. J.L. Massey) and Ascom Ltd. The aim of the project was to 80 develop an encryption algorithm which would replace the DES 81 algorithm. IDEA uses a 128-bit secret key and encrypts one 64-bit 82 block at a time. The algorithm is generally considered to be very 83 secure. It was particularly strengthened to protect against 84 differential cryptoanalysis attacks. 86 IDEA permits the implementation of standard Electronic Data 87 Interchange applications. It has been entered in the ISO/IEC register 88 for encryption algorithms and incorporated in the "SECURITY GUIDE 89 LINES" code list by the UNI/EDIFACT "SECURITY JOINT WORKING GROUP". 91 More information on IDEA and source code can be found at 92 . 94 3. IDEA Object Identifier For S/MIME 96 The PKCS #7 message format [PKCS7] is the framework for the 97 implementation of cryptographic functions in S/MIME. It specifies 98 data formats and encryption processes without naming the 99 cryptographic algorithms. A concrete algorithm which is used for 100 encryption purposes MUST be specified by a unique algorithm 101 identifier. In the special case of content encryption, the 102 ContentEncryptionAlgorithmIdentifier specifies the applied algorithm. 104 S/MIME v3 requires only that agents MUST provide DES EDE3 CBC for 105 content encryption, whereas RC2/40-bit is specified as optional. 106 IDEA can be simply added to the set of optional content encryption 107 algorithms by providing its unique S/MIME object identifier. This 108 corresponds to the ContentEncryptionAlgorithmIdentifier of PKCS #7. 109 An S/MIME agent can apply the IDEA algorithm for content encryption 110 simply by selecting its object identifier, supplying the required 111 parameter, and starting the corresponding program code. 113 For strong content encryption the use of IDEA in cipher block 114 chaining (CBC) mode is recommended. The key length is fixed to 128 115 bits. The object identifier for IDEA in CBC mode is given by 117 IDEA-CBC OBJECT IDENTIFIER 118 ::= {iso(1) identified-organization(3) 119 usdod(6) oid(1) private(4) enterprises(1) 120 as(188) sys(7) sec(1) alg(1) 2} 122 The algorithm's initial vector iv is an optional parameter 124 IDEA-CBCPar ::= SEQUENCE { 125 iv OCTET STRING OPTIONAL -- 8 octets } 127 If iv is specified as above, it MUST be used as initial vector. In 128 this case, the ciphertext MUST NOT include the initial vector. If 129 iv is not specified, the first 64 bits of the ciphertext MUST be 130 taken as the initial vector. 132 4. Consequence On S/MIME Capabilities Attribute 134 An S/MIME client SHOULD announce the set of cryptographic functions 135 it supports by using the S/MIME capabilities attribute. This 136 attribute provides a partial list of OIDs of cryptographic functions 137 and MUST be signed by the client. The function's OIDs SHOULD be 138 logically separated in functional categories and MUST be ordered with 139 respect to their preference. If an S/MIME client is required to 140 support strong encryption by IDEA-CBC, the capabilities attribute 141 MUST contain the above specified OID in the category of symmetric 142 algorithms. IDEA-CBC does not require additional OID parameters as a 143 fixed key length of 128 bits is propagated. 145 5. Activation of IDEA In S/MIME 147 When a sending agent creates an encrypted message, it has to decide 148 which type of encryption algorithm to use. In general, the decision 149 process involves using information obtained from the capabilities 150 lists included in messages received from the recipient, as well as 151 out-of-band information such as private agreements, user preferences, 152 legal restrictions, etc. 154 For example, in the broad field of electronic commerce weak 155 encryption, as represented by RC2/40, is regarded to be unacceptable. 156 Strong encryption can be enforced on the basis of a security policy. 157 This policy SHOULD include an agreement on at least one desired 158 strong encryption algorithms to be used in S/MIME. In this case it 159 is required that S/MIME clients both at the sending and the 160 receiving end MUST support the desired encryption algorithms. Thus, 161 if IDEA-CBC is chosen to be used as encryption algorithm, it MUST 162 be supported by the S/MIME clients and it MUST be set in the user 163 preferences. 165 A. References 167 [IDEA] X. Lai, "On the design and security of block ciphers", ETH 168 Series in Information Processing, J.L. Massey (editor), vol. 1, 169 Hartung-Gorre Verlag Konstanz, Technische Hochschule (Zurich), 1992. 171 [SMIME2] "S/MIME Version 2 Message Specification", RFC 2311, and 172 "S/MIME Version 2 Certificate Handling", RFC 2312. 174 [SMIME3] "S/MIME Version 3 Message Specification", Internet Draft 175 draft-ietf-smime-msg-xx, and "S/MIME Version 3 Certificate 176 Handling", Internet Draft draft-ietf-smime-cert-xx. 178 [MIME-SPEC] The primary definition of MIME. 179 "MIME Part 1: Format of Internet Message Bodies", RFC 2045; 180 "MIME Part 2: Media Types", RFC 2046; 181 "MIME Part 3: Message Header Extensions for Non-ASCII Text", 182 RFC 2047; 183 "MIME Part 4: Registration Procedures", RFC 2048; 184 "MIME Part 5: Conformance Criteria and Examples", RFC 2049 186 [3DES] W. Tuchman, "Hellman Presents No Shortcut Solutions To DES," 187 IEEE Spectrum, vol. 16, no. 7, July 1979, pp. 40-41. 189 [DES] ANSI X3.106, "American National Standard for Information 190 Systems- Data Link Encryption," American National Standards 191 Institute, 1983. 193 [RC2] "A Description of the RC2 (r) Encryption Algorithm", RFC 2268 195 [MUSTSHOULD] "Key words for use in RFCs to Indicate Requirement 196 Levels", RFC 2119 198 [PKCS7] "PKCS #7: Cryptographic Message Syntax Version 1.5", RFC 2315 200 B. Intellectual Property Notice 202 IDEA (TM) is protected by international copyright law and in addition 203 it has been patented in the United States and in most of the European 204 countries. The patent is held by Ascom Ltd. 206 Non-commercial use of IDEA is free. 207 Commercial licenses can be obtained by contacting idea@ascom.ch. 209 C. Authors' Address 211 Ascom Systec Ltd. 212 Gewerbepark 213 P.O.Box 214 5506 Maegenwil, Switzerland 216 Phone: +41 62 889 5964 217 Email: {stephan.teiwes,peter.hartmann,diego.kuenzi}@ascom.ch