idnits 2.17.1 draft-ietf-smime-cms-seed-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: ---------------------------------------------------------------------------- ** The document seems to lack a 1id_guidelines paragraph about the list of current Internet-Drafts -- however, there's a paragraph with a matching beginning. Boilerplate error? ** The document seems to lack a 1id_guidelines paragraph about the list of Shadow Directories -- however, there's a paragraph with a matching beginning. Boilerplate error? == 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 12 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.) ** There are 10 instances of too long lines in the document, the longest one being 84 characters in excess of 72. 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 (March 29, 2004) is 7326 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) == Missing Reference: 'CRYPTEC' is mentioned on line 73, but not defined -- Looks like a reference, but probably isn't: '0' on line 332 -- Looks like a reference, but probably isn't: '1' on line 257 ** Obsolete normative reference: RFC 3369 (ref. 'CMS') (Obsoleted by RFC 3852) ** Obsolete normative reference: RFC 2633 (Obsoleted by RFC 3851) ** Downref: Normative reference to an Informational RFC: RFC 3394 -- Possible downref: Non-RFC (?) normative reference: ref. 'AES-WRAP' Summary: 8 errors (**), 0 flaws (~~), 5 warnings (==), 5 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 S/MIME Working Group Jongwook Park (KISA) 3 Internet Draft Sungjae Lee (KISA) 4 Document: draft-ietf-smime-cms-seed-00.txt Jeeyeon Kim (KISA) 5 Expires: September 29, 2004 Jaeil Lee (KISA) 6 Target category : Standard Track March 29, 2004 8 Use of the SEED Encryption Algorithm in CMS 10 draft-ietf-smime-cms-seed-00.txt 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 months 23 and may be updated, replaced, or obsoleted by other documents at any 24 time. It is inappropriate to use Internet-Drafts as reference 25 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 "ietf- 34 smime" mailing list, or directly to the author. 36 Abstract 38 This document specifies the conventions for using the SEED encryption 39 algorithm for encryption with the Cryptographic Message Syntax (CMS). 41 1. Introduction 43 This document specifies the conventions for usting the SEED 44 encryption algorithm [SEED] [TTASSEED] for encryption with the 45 Cryptographic Message Syntax (CMS)[CMS]. The relevant object 46 identifiers (OIDs) and processing steps are provided so that SEED may 47 be used in the CMS specification (RFC 3369, RFC 3370) for content and 48 key encryption. 50 1.1 SEED 52 SEED is a symmetric encryption algorithm that had been developed by 53 KISA (Korea Information Security Agency) and a group of experts since 54 1998. The input/output block size of SEED is 128-bit and the key 55 length is also 128-bit. SEED has the 16-round Feistel structure. A 56 128-bit input is divided into two 64-bit blocks and the right 64-bit 57 block is an input to the round function with a 64-bit subkey 58 generated from the key scheduling. 60 SEED is easily implemented in various software and hardware because 61 it is designed to increase the efficiency of memory storage and the 62 simplicity in generating keys without degrading the security of the 63 algorithm. In particular, it can be effectively adopted to a 64 computing environment with a restricted resources such as a mobile 65 devices, smart cards and so on. 67 SEED is robust against known attacks including DC (Differential 68 cryptanalysis), LC (Linear cryptanalysis) and related key attacks, 69 etc. SEED has gone through wide public scrutinizing procedures. 70 Especially, it has been evaluated and also considered 71 cryptographically secure by trustworhty organizations such as ISO/IEC 72 JTC 1/SC 27 and Japan CRYTEC (Cryptography Reasearch and Evaluation 73 Comittees) [ISOSEED][CRYPTEC]. 75 SEED is a national industrial association standard [TTASSEED] and is 76 widely used in South Korea for electronic commerce and financial 77 services operated on wired & wireless PKI. 79 1.2 Terminology 81 The key words "MUST", "MUST NOT", "REQUIRED", "SHOULD", "SHOULD NOT", 82 "RECOMMENDED", "MAY", and "OPTIONAL" in this document (in uppercase, 83 as shown) are to be interpreted as described in [RFC2119]. 85 2. Object Identifiers for Content and Key Encryption 87 This section provides the OIDs and processing information necessary 88 for SEED to be used for content and key encryption in CMS. SEED is 89 added to the set of optional symmetric encryption algorithms in CMS 90 by providing two classes of unique object identifiers (OIDs). One 91 OID class defines the content encryption algorithms and the other 92 defines the key encryption algorithms. Thus a CMS agent can apply 93 SEED either for content or key encryption by selecting the 94 corresponding object identifier, supplying the required parameter, 95 and starting the program code. 97 2.1 OIDs for Content Encryption 99 SEED is added to the set of symmetric content encryption algorithms 100 defined in [CMSALG]. The SEED content-encryption algorithm in Cipher 101 Block Chaining (CBC) mode has the following object identifier: 103 id-seedCBC OBJECT IDENTIFIER ::= 104 { iso(1) member-body(2) korea(410) kisa(200004) 105 algorithm(1) seedCBC(4) } 107 The AlgorithmIdentifier parameters field MUST be present, and the 108 parameters field MUST contain the value of IV: 110 SeedCBCParameter ::= SeedIV -- Initialization Vector 112 SeedIV ::= OCTET STRING (SIZE(16)) 114 The plain text is padded according to Section 6.3 of [CMS]. 116 2.2 OIDs for Key Encryption 118 The key-wrap/unwrap procedures used to encrypt/decrypt a SEED 119 content-encryption key (CEK) with a SEED key-encryption key 120 (KEK) are specified in Section 3. Generation and distribution of 121 key-encryption keys are beyond the scope of this document. 123 The SEED key-encryption algorithm has the following object 124 identifier: 126 id-npki-app-cmsSeed-wrap OBJECT IDENTIFIER ::= 127 { iso(1) member-body(2) korea(410) kisa(200004) npki-app(7) 128 smime(1) alg(1) cmsSEED-wrap(1) } 130 The parameter associated with this object identifier MUST be absent, 131 because the key wrapping procedure itself defines how and when to 132 use an IV. 134 3. Key Wrap Algorithm 136 SEED key wrapping and unwrapping is done in conformance with the 137 AES key wrap algorithm [AES-WRAP][RFC3394]. 139 3.1 Notation and Defintions 141 The following notation is used in the description of the key 142 wrapping algorithms: 144 SEED(K, W) Encrypt W using the SEED codebook with key K 145 SEED-1(K, W) Decrypt W using the SEED codebook with key K 146 MSB(j, W) Return the most significant j bits of W 147 LSB(j, W) Return the least significant j bits of W 148 B1 ^ B2 The bitwise exclusive or (XOR) of B1 and B2 149 B1 | B2 Concatenate B1 and B2 150 K The key-encryption key K 151 n The number of 64-bit key data blocks 152 s The number of steps in the wrapping process, 153 s = 6n 154 P[i] The ith plaintext key data block 155 C[i] The ith ciphertext data block 156 A The 64-bit integrity check register 157 R[i] An array of 64-bit registers where 158 i = 0, 1, 2, ..., n 159 A[t], R[i][t] The contents of registers A and R[i] after 160 encryption step t. 161 IV The 64-bit initial value used during the 162 wrapping process. 164 In the key wrap algorithm, the concatenation function will be used to 165 concatenate 64-bit quantities to form the 128-bit input to the SEED 166 codebook. The extraction functions will be used to split the 128-bit 167 output from the SEED codebook into two 64-bit quantities. 169 3.2 SEED Key Wrap 171 Key wrapping with SEED is identical to Section 2.2.1 of [RFC3394] 172 with "AES" replaced by "SEED". 174 The inputs to the key wrapping process are the KEK and the plaintext 175 to be wrapped. The plaintext consists of n 64-bit blocks, containing 176 the key data being wrapped. The key wrapping process is described 177 below. 179 Inputs: Plaintext, n 64-bit values {P1, P2, ..., Pn}, and 180 Key, K (the KEK). 181 Outputs: Ciphertext, (n+1) 64-bit values {C0, C1, ..., Cn}. 183 1) Initialize variables. 185 Set A[0] to an initial value (see Section 3.4) 186 For i = 1 to n 187 R[0][i] = P[i] 189 2) Calculate intermediate values. 191 For t = 1 to s, where s = 6n 192 A[t] = MSB(64, SEED(K, A[t-1] | R[t-1][1])) ^ t 193 For i = 1 to n-1 194 R[t][i] = R[t-1][i+1] 195 R[t][n] = LSB(64, SEED(K, A[t-1] | R[t-1][1])) 197 3) Output the results. 199 Set C[0] = A[t] 200 For i = 1 to n 201 C[i] = R[t][i] 203 An alternative description of the key wrap algorithm involves 204 indexing rather than shifting. This approach allows one to 205 calculate the wrapped key in place, avoiding the rotation in the 206 previous description. This produces identical results and is more 207 easily implemented in software. 209 Inputs: Plaintext, n 64-bit values {P1, P2, ..., Pn}, and 210 Key, K (the KEK). 211 Outputs: Ciphertext, (n+1) 64-bit values {C0, C1, ..., Cn}. 213 1) Initialize variables. 215 Set A = IV, an initial value (see Section 3.4) 216 For i = 1 to n 217 R[i] = P[i] 219 2) Calculate intermediate values. 221 For j = 0 to 5 222 For i=1 to n 223 B = SEED(K, A | R[i]) 224 A = MSB(64, B) ^ t where t = (n*j)+i 225 R[i] = LSB(64, B) 227 3) Output the results. 229 Set C[0] = A 230 For i = 1 to n 231 C[i] = R[i] 233 3.3 SEED Key Unwrap 235 Key unwrapping with SEED is identical to Section 2.2.2 of 236 [RFC3394], with "AES" replaced by "SEED". 238 The inputs to the unwrap process are the KEK and (n+1) 64-bit blocks 239 of ciphertext consisting of previously wrapped key. It returns n 240 blocks of plaintext consisting of the n 64-bit blocks of the 241 decrypted key data. 243 Inputs: Ciphertext, (n+1) 64-bit values {C0, C1, ..., Cn}, and 244 Key, K (the KEK). 245 Outputs: Plaintext, n 64-bit values {P1, P2, ..., Pn}. 247 1) Initialize variables. 249 Set A[s] = C[0] where s = 6n 250 For i = 1 to n 251 R[s][i] = C[i] 253 2) Calculate the intermediate values. 255 For t = s to 1 256 A[t-1] = MSB(64, SEED-1(K, ((A[t] ^ t) | R[t][n])) 257 R[t-1][1] = LSB(64, SEED-1(K, ((A[t]^t) | R[t][n])) 258 For i = 2 to n 259 R[t-1][i] = R[t][i-1] 261 3) Output the results. 263 If A[0] is an appropriate initial value (see Section 3.4), 264 Then 265 For i = 1 to n 266 P[i] = R[0][i] 267 Else 268 Return an error 270 The unwrap algorithm can also be specified as an index based 271 operation, allowing the calculations to be carried out in place. 272 Again, this produces the same results as the register shifting 273 approach. 275 Inputs: Ciphertext, (n+1) 64-bit values {C0, C1, ..., Cn}, and 276 Key, K (the KEK). 277 Outputs: Plaintext, n 64-bit values {P0, P1, K, Pn}. 279 1) Initialize variables. 281 Set A = C[0] 282 For i = 1 to n 283 R[i] = C[i] 285 2) Compute intermediate values. 287 For j = 5 to 0 288 For i = n to 1 289 B = SEED-1(K, (A ^ t) | R[i]) where t = n*j+i 290 A = MSB(64, B) 291 R[i] = LSB(64, B) 293 3) Output results. 295 If A is an appropriate initial value (see Section 3.4), 296 Then 297 For i = 1 to n 298 P[i] = R[i] 299 Else 300 Return an error 302 3.4 Key Data Integrity -- the Initial Value 304 The initial value (IV) refers to the value assigned to A[0] in the 305 first step of the wrapping process. This value is used to obtain an 306 integrity check on the key data. In the final step of the 307 unwrapping process, the recovered value of A[0] is compared to the 308 expected value of A[0]. If there is a match, the key is accepted as 309 valid, and the unwrapping algorithm returns it. If there is not a 310 match, then the key is rejected, and the unwrapping algorithm 311 returns an error. 313 The exact properties achieved by this integrity check depend on the 314 definition of the initial value. Different applications may call 315 for somewhat different properties; for example, whether there is 316 need to determine the integrity of key data throughout its lifecycle 317 or just when it is unwrapped. This specification defines a default 318 initial value that supports integrity of the key data during the 319 period it is wrapped (in Section 3.4.1). Provision is also made to 320 support alternative initial values (in Section 3.4.2). 322 3.4.1 Default Initial Value 324 The default initial value (IV) is defined to be the hexadecimal 325 constant: 327 A[0] = IV = A6A6A6A6A6A6A6A6 329 The use of a constant as the IV supports a strong integrity check on 330 the key data during the period that it is wrapped. If unwrapping 331 produces A[0] = A6A6A6A6A6A6A6A6, then the chance that the key data 332 is corrupt is 2^-64. If unwrapping produces A[0] any other value, 333 then the unwrap must return an error and not return any key data. 335 3.4.2 Alternative Initial Values 337 When the key wrap is used as part of a larger key management 338 protocol or system, the desired scope for data integrity may be more 339 than just the key data or the desired duration for more than just 340 the period that it is wrapped. Also, if the key data is not just an 341 SEED key, it may not always be a multiple of 64 bits. 342 Alternative definitions of the initial value can be used to address 343 such problems. According to [RFC3394], NIST will define alternative 344 initial values in future key management publications as needed. In 345 order to accommodate a set of alternatives that may evolve over 346 time, key wrap implementations that are not application-specific 347 will require some flexibility in the way that the initial value is 348 set and tested. 350 4. SMIMECapabilities Attribute 352 An S/MIME client SHOULD announce the set of cryptographic functions 353 it supports by using the S/MIME capabilities attribute. This 354 attribute provides a partial list of OIDs of cryptographic functions 355 and MUST be signed by the client. The functions' OIDs SHOULD be 356 logically separated in functional categories and MUST be ordered 357 with respect to their preference. 359 RFC 2633 [RFC2633], Section 2.5.2 defines the SMIMECapabilities 360 signed attribute (defined as a SEQUENCE of SMIMECapability 361 SEQUENCEs) to be used to specify a partial list of algorithms that 362 the software announcing the SMIMECapabilities can support. 364 If an S/MIME client is required to support symmetric encryption with 365 SEED, the capabilities attribute MUST contain the SEED OID 366 specified above in the category of symmetric algorithms. The 367 parameter associated with this OID MUST be SeedSMimeCapability. 369 SeedSMimeCapabilty ::= NULL 371 The SMIMECapability SEQUENCE representing SEED MUST be 372 DER-encoded as the following hexadecimal strings: 374 30 0A 06 08 2A 83 1A 8C 9A 44 01 04 376 When a sending agent creates an encrypted message, it has to decide 377 which type of encryption algorithm to use. In general the decision 378 process involves information obtained from the capabilities lists 379 included in messages received from the recipient, as well as other 380 information such as private agreements, user preferences, legal 381 restrictions, and so on. If users require SEED for symmetric 382 encryption, it MUST be supported by the S/MIME clients on both the 383 sending and receiving side, and it MUST be set in the user 384 preferences. 386 5. Security Considerations 388 This document specifies the use of SEED for encrypting the 389 content of a CMS message and for encrypting the symmetric key used 390 to encrypt the content of a CMS message, and the other mechanisms 391 are the same as the existing ones. Therefore, the security 392 considerations described in the CMS specifications [CMS][CMSALG] and 393 the AES key wrap algorithm [AES-WRAP][RFC3394] can be applied to 394 this document. No security problem has been found on SEED 395 [CRYPTREC]. 397 6. Intellectual Property Statement 399 The IETF takes no position regarding the validity or scope of any 400 intellectual property or other rights that might be claimed to 401 pertain to the implementation or use of the technology described 402 in this document or the extent to which any license under such 403 rights might or might not be available; neither does it represent 404 that it has made any effort to identify any such rights. 405 Information on the IETF's procedures with respect to rights in 406 standards-track and standards-related documentation can be found 407 in BCP-11. Copies of claims of rights made available for 408 publication and any assurances of licenses to be made available, 409 or the result of an attempt made to obtain a general license or 410 permission for the use of such proprietary rights by implementors 411 or users of this specification can be obtained from the IETF 412 Secretariat. 414 The IETF invites any interested party to bring to its attention 415 any copyrights, patents or patent applications, or other 416 proprietary rights which may cover technology that may be required 417 to practice this standard. Please address the information to the 418 IETF Executive Director. 420 7. Full Copyright Statement 422 Copyright (C) The Internet Society (2003). All Rights Reserved. 424 This document and translations of it may be copied and furnished 425 to others, and derivative works that comment on or otherwise 426 explain it or assist in its implmentation may be prepared, copied, 427 published and distributed, in whole or in part, without 428 restriction of any kind, provided that the above copyright notice 429 and this paragraph are included on all such copies and derivative 430 works. However, this document itself may not be modified in any 431 way, such as by removing the copyright notice or references to the 432 Internet Society or other Internet organizations, except as needed 433 for the purpose of developing Internet standards in which case the 434 procedures for copyrights defined in the Internet Standards 435 process must be followed, or as required to translate it into 436 languages other than English. 438 The limited permissions granted above are perpetual and will not 439 be revoked by the Internet Society or its successors or assigns. 441 This document and the information contained herein is provided on 442 an "AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET 443 ENGINEERING TASK FORCE DISCLAIMS ALL WARRANTIES, EXPRESS OR 444 IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF 445 THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED 446 WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR 447 PURPOSE." 449 8. References 451 8.1 Normative Reference 453 [CMS] R. Housley, "Cryptographic Message Syntax", RFC 3369, 454 August 2002. 456 [CMSALG] R. Housley, "Cryptographic Message Syntax (CMS) 457 Algorithms", RFC 3370, August 2002. 459 [RFC2119] S. Bradner, "Key words for use in RFCs to Indicate 460 Requirement Levels", BCP 14, RFC 2119, March 1997. 462 [RFC2633] Ramsdell, B., Editor. S/MIME Version 3 Message 463 Specification. RFC 2633. June 1999. 465 [RFC3394] J. Schaad and R. Housley, "Advanced Encryption Standard 466 (AES) Key Wrap Algorithm", RFC 3394, September 2002. 468 [AES-WRAP] National Institute of Standards and Technology. AES Key 469 Wrap Specification. 17 November 2001. 470 http://csrc.nist.gov/encryption/kms/key-wrap.pdf 472 8.2 Informative Reference 474 [SEED] KISA, "SEED Algorithm Specification", 475 http://www.kisa.or.kr/seed/seed_eng.html" 477 [TTASSEED] Telecommunications Technology Association (TTA), 478 South Korea, "128-bit Symmetric Block Cipher (SEED)", 479 TTAS.KO-12.0004, September, 1998 (In Korean) 480 http://www.tta.or.kr/English/new/main/index.htm 482 [ISOSEED] ISO/IEC, ISO/IEC JTC1/SC 27 N 256r1, "National Body 483 contributions on NP 18033 Encryption algorithms in 484 response to document SC 27 N 2563", October, 2000 486 [CRYPTREC] Information-technology Promotion Agency (IPA), Japan, 487 CRYPTREC. "SEED Evaluation Report", February, 2002 488 http://www.kisa.or.kr 490 9. Authors' Address 492 Jongwook Park 493 Korea Information Security Agency 494 Phone: +82-2-405-5432 495 FAX : +82-2-405-5499 496 Email: khopri@kisa.or.kr 498 Sungjae Lee 499 Korea Information Security Agency 500 Phone: +82-2-405-5243 501 FAX : +82-2-405-5499 502 Email: sjlee@kisa.or.kr 504 Jeeyeon Kim 505 Korea Information Security Agency 506 Phone: +82-2-405-5238 507 FAX : +82-2-405-5499 508 Email: jykim@kisa.or.kr 510 Jaeil Lee 511 Korea Information Security Agency 512 Phone: +82-2-405-5300 513 FAX : +82-2-405-5499 514 Email: jilee@kisa.or.kr 516 Appendix A ASN.1 Module 518 SeedEncryptionAlgorithmInCMS 519 { iso(1) member-body(2) us(840) rsadsi(113549) pkcs(1) 520 pkcs9(9) smime(16) modules(0) id-mod-cms-seed(?) } 522 DEFINITIONS IMPLICIT TAGS ::= BEGIN 524 id-seedCBC OBJECT IDENTIFIER ::= 525 { iso(1) member-body(2) korea(410) kisa(200004) 526 algorithm(1) seedCBC(4) } 528 -- Initialization Vector 530 SeedCBCParameter ::= SeedIV 532 SeedIV ::= OCTET STRING (SIZE(16)) 534 -- SEED Key Wrap Algorithm identifiers - Parameter is absent. 536 id-npki-app-cmsSeed-wrap OBJECT IDENTIFIER ::= 537 { iso(1) member-body(2) korea(410) kisa(200004) npki-app(7) 538 smime(1) alg(1) cmsSEED-wrap(1) } 540 -- SEED S/MIME Capabilty parameter 542 SeedSMimeCapability ::= NULL 544 END