idnits 2.17.1 draft-ietf-smime-camellia-00.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 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. ** There are 12 instances of lines with control characters in the document. Miscellaneous warnings: ---------------------------------------------------------------------------- == 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 (October 2002) is 7835 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) -- Possible downref: Non-RFC (?) normative reference: ref. 'AES-WRAP' == Outdated reference: A later version (-03) exists of draft-nakajima-camellia-02 ** Downref: Normative reference to an Informational draft: draft-nakajima-camellia (ref. 'CamelliaID') -- Possible downref: Non-RFC (?) normative reference: ref. 'CamelliaSpec' -- Possible downref: Non-RFC (?) normative reference: ref. 'CamelliaTech' ** Obsolete normative reference: RFC 3369 (ref. 'CMS') (Obsoleted by RFC 3852) ** Downref: Normative reference to an Informational RFC: RFC 3394 Summary: 7 errors (**), 0 flaws (~~), 3 warnings (==), 5 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 S/MIME Working Group S. Moriai 3 Internet Draft Nippon Telegraph and Telephone Corporation 4 Expiration Date: April 2003 A. Kato 5 NTT Software Corporation 6 October 2002 8 Use of the Camellia Encryption Algorithm in CMS 10 12 Status of this Memo 14 This document is an Internet-Draft and is in full conformance with 15 all provisions of Section 10 of RFC2026. 17 Internet-Drafts are working documents of the Internet Engineering 18 Task Force (IETF), its areas, and its working groups. Note that 19 other groups may also distribute working documents as Internet- 20 Drafts. 22 Internet-Drafts are draft documents valid for a maximum of six 23 months and may be updated, replaced, or obsoleted by other documents 24 at any time. It is inappropriate to use Internet-Drafts as 25 reference material or to cite them other than as "work in progress." 27 The list of current Internet-Drafts can be accessed at 28 http://www.ietf.org/ietf/1id-abstracts.txt 30 The list of Internet-Draft Shadow Directories can be accessed at 31 http://www.ietf.org/shadow.html. 33 Comments or suggestions for improvement may be made on the 34 "ietf-smime" mailing list, or directly to the author. 36 Abstract 38 This document specifies how to incorporate the Camellia encryption 39 algorithm into the S/MIME Cryptographic Message Syntax (CMS) as an 40 additional algorithm for symmetric encryption. The relevant OIDs 41 and processing steps are provided so that Camellia may be included 42 in the CMS specification (RFC 3369, RFC 3370) for content and key 43 encryption. 45 1. Introduction 47 This document specifies the conventions for using the Camellia 48 encryption algorithm [CamelliaSpec][CamelliaID] for encryption with 49 the Cryptographic Message Syntax (CMS) [CMS]. 51 Camellia is a block cipher with 128-bit block size and 128-, 192-, 52 and 256-bit keys, i.e. the same interface as the Advanced Encryption 53 Standard (AES). Camellia offers excellent efficiency on both 54 software and hardware platforms in addition to a high level of 55 security [CamelliaTech]. 57 CMS values are generated using ASN.1 (X.208-88), using the Basic 58 Encoding Rules (BER) (X.209-88) and the Distinguished Encoding Rules 59 (DER) (X.509-88). 61 The key words "MUST", "MUST NOT", "REQUIRED", "SHOULD", "SHOULD 62 NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this document (in 63 uppercase, as shown) are to be interpreted as described in 64 [RFC2119]. 66 2. Object Identifiers for Content and Key Encryption 68 This section provides the OIDs and processing information necessary 69 for Camellia to be used for content and key encryption in CMS. 71 Camellia is added to the set of optional symmetric encryption 72 algorithms in CMS by providing two classes of unique object 73 identifiers (OIDs). One OID class defines the content encryption 74 algorithms and the other defines the key encryption algorithms. 75 Thus a CMS agent can apply Camellia either for content or key 76 encryption by selecting the corresponding object identifier, 77 supplying the required parameter, and starting the program code. 79 2.1 OIDs for Content Encryption 81 For content encryption the use of Camellia in cipher block chaining 82 (CBC) mode is RECOMMENDED. The Camellia content-encryption 83 algorithm, in CBC mode, for the three different key sizes are 84 identified by the following object identifiers: 86 id-camellia128-cbc OBJECT IDENTIFIER ::= 87 { iso(1) member-body(2) 392 200011 61 security(1) 88 algorithm(1) symmetric-encryption-algorithm(1) 89 camellia128-cbc(2) } 91 id-camellia192-cbc OBJECT IDENTIFIER ::= 92 { iso(1) member-body(2) 392 200011 61 security(1) 93 algorithm(1) symmetric-encryption-algorithm(1) 94 camellia192-cbc(3) } 96 id-camellia256-cbc OBJECT IDENTIFIER ::= 97 { iso(1) member-body(2) 392 200011 61 security(1) 98 algorithm(1) symmetric-encryption-algorithm(1) 99 camellia256-cbc(4) } 101 To determine the value of IV, the above algorithms take parameter 102 as: 104 CamelliaCBCParameter ::= CamelliaIV -- Initialization Vector 106 CamelliaIV ::= OCTET STRING (SIZE(16)) 108 When these object identifiers are used, plaintext is padded before 109 encrypt it. At least 1 padding octet is appended at the end of the 110 plaintext to make the length of the plaintext to the multiple of 16 111 octets. The value of these octets is as same as the number of 112 appended octets. (e.g., If 10 octets are needed to pad, the value 113 is 0x0a.) 115 2.2 OIDs for Key Encryption 117 The key-wrap/unwrap procedures used to encrypt/decrypt a Camellia 118 content-encryption key (CEK) with a Camellia key-encryption key 119 (KEK) are specified in Section 3. Generation and distribution of 120 key-encryption keys are beyond the scope of this document. 122 The Camellia key-encryption algorithm has the following object 123 identifier: 125    id-camellia128-wrap OBJECT IDENTIFIER ::= 126     { iso(1) member-body(2) 392 200011 61 security(1) 127     algorithm(1) key-wrap-algorithm(3) 128     camellia128-wrap(2) } 130    id-camellia192-wrap OBJECT IDENTIFIER ::= 131     { iso(1) member-body(2) 392 200011 61 security(1) 132     algorithm(1) key-wrap-algorithm(3) 133     camellia192-wrap(3) } 135    id-camellia256-wrap OBJECT IDENTIFIER ::= 136     { iso(1) member-body(2) 392 200011 61 security(1) 137     algorithm(1) key-wrap-algorithm(3) 138     camellia256-wrap(4) } 140 In all cases the parameters field of AlgorithmIdentifier MUST be 141 NULL. The OID gives the KEK key size, but does not make any 142 statements as to the size of the wrapped Camellia CEK. 143 Implementations MAY use different KEK and CEK sizes. Implements 144 MUST support the CEK and the KEK having the same length. If 145 different lengths are supported, the KEK MUST be of equal or greater 146 length than the CEK. 148 We don't need additional parameter information associated with this 149 object identifier contains, because the key wrapping procedure 150 itself defines how and when to use an IV. 152 3. Key Wrap Algorithm 154 Camellia key wrapping and unwrapping is done in conformance with the 155 AES key wrap algorithm [AES-WRAP][RFC3394], because Camellia and AES 156 have the same block and key sizes, i.e. the block size of 128 bits 157 and key sizes of 128, 192, and 256 bits. 159 3.1 Camellia Key Wrap 161 Key wrapping with Camellia is identical to [RFC3394], Section 2.2.1, 162 with "AES" replaced by "Camellia". 164 3.2 Camellia Key Unwrap 166 Key unwrapping with Camellia is identical to [RFC3394], Section 167 2.2.2, with "AES" replaced by "Camellia". 169 4. Security Considerations 171 This document specifies the use of Camellia for encrypting the 172 content of a CMS message and for encrypting the symmetric key used 173 to encrypt the content of a CMS message. Since Camellia supports 174 the key length of 128, 192 and 256 bits, it provides enough security 175 against exhaustive key attacks. Against other attacks Camellia is 176 believed to be secure, and it has withstood extensive cryptanalytic 177 efforts in several open, worldwide cryptographic evaluation 178 projects. 180 For other security considerations, please refer to the security 181 considerations of the CMS specifications [CMS][CMSALG] and the AES 182 key wrap algorithm [AES-WRAP][RFC3394]. 184 5. Intellectual Property Statement 186 Mitsubishi Electric Corporation (Mitsubishi Electric) and Nippon 187 Telegraph and Telephone Corporation (NTT) have pending applications 188 or filed patents which are essential to Camellia. License policy 189 for these essential patents will be available on the IETF page of 190 Intellectual Property Rights Notices. 192 References 194 [AES-WRAP] National Institute of Standards and Technology. AES Key 195 Wrap Specification. 17 November 2001. 196 http://csrc.nist.gov/encryption/kms/key-wrap.pdf 198 [CamelliaID] J. Nakajima and S. Moriai, "A Description of the 199 Camellia Encryption Algorithm", Internet-Draft, July 2001. 200 draft-nakajima-camellia-02.txt 202 [CamelliaSpec] K. Aoki, T. Ichikawa, M. Kanda, M. Matsui, S. Moriai, 203 J. Nakajima, and T. Tokita ``Specification of Camellia - a 204 128-bit Block Cipher''. http://info.isl.ntt.co.jp/camellia/ 206 [CamelliaTech] K. Aoki, T. Ichikawa, M. Kanda, M. Matsui, S. Moriai, 207 J. Nakajima, and T. Tokita ``Camellia: A 128-Bit Block Cipher 208 Suitable for Multiple Platforms - Design and Analysis -'', In 209 Selected Areas in Cryptography, 7th Annual International 210 Workshop, SAC 2000, August 2000, Proceedings, Lecture Notes in 211 Computer Science 2012, pp.39--56, Springer-Verlag, 2001. 213 [CMS] R. Housley, "Cryptographic Message Syntax", RFC 3369, August 214 2002. 216 [CMSALG] R. Housley, "Cryptographic Message Syntax (CMS) 217 Algorithms", RFC 3370, August 2002. 219 [RFC2119] S. Bradner, "Key words for use in RFCs to Indicate 220 Requirement Levels", BCP 14, RFC 2119, March 1997. 222 [RFC3394] J. Schaad and R. Housley, "Advanced Encryption Standard 223 (AES) Key Wrap Algorithm", RFC 3394, September 2002. 225 Authors' Address 227 Shiho Moriai 228 Nippon Telegraph and Telephone Corporation 229 Phone: +81-468-59-2007 230 FAX: +81-468-59-3858 231 Email: shiho@isl.ntt.co.jp 233 Akihiro Kato 234 NTT Software Corporation 235 Phone: +81-45-212-7404 236 FAX: +81-45-212-7410 237 Email: akato@po.ntts.co.jp