idnits 2.17.00 (12 Aug 2021) /tmp/idnits43891/draft-park-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: ---------------------------------------------------------------------------- == 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.) 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 (October 2003) is 6792 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 70, but not defined -- Looks like a reference, but probably isn't: '0' on line 329 -- Looks like a reference, but probably isn't: '1' on line 254 ** 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: 5 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-park-cms-seed-00.txt Jinsu Hyun (KISA) 5 Expires: April 2003 Jaeil Lee (KISA) 6 October 2003 8 Use of the SEED Encryption Algorithm in CMS 10 Status of this Memo 12 This document is an Internet-Draft and is in full conformance with 13 all provisions of Section 10 of RFC2026. 15 Internet-Drafts are working documents of the Internet Engineering 16 Task Force (IETF), its areas, and its working groups. Note that 17 other groups may also distribute working documents as Internet- 18 Drafts. 20 Internet-Drafts are draft documents valid for a maximum of six months 21 and may be updated, replaced, or obsoleted by other documents at any 22 time. It is inappropriate to use Internet-Drafts as reference 23 material or to cite them other than as "work in progress." 25 The list of current Internet-Drafts can be accessed at 26 http://www.ietf.org/ietf/1id-abstracts.txt 28 The list of Internet-Draft Shadow Directories can be accessed at 29 http://www.ietf.org/shadow.html. 31 Comments or suggestions for improvement may be made on the "ietf- 32 smime" mailing list, or directly to the author. 34 Abstract 36 This document specifies the conventions for using the SEED encryption 37 algorithm for encryption with the Cryptographic Message Syntax (CMS). 39 1. Introduction 41 This document specifies the conventions for usting the SEED 42 encryption algorithm [TTASSEED] for encryption with the Cryptographic 43 Message Syntax (CMS) [CMS]. The relevant object identifiers (OIDs) 44 and processing steps are provided so that SEED may be used in the CMS 45 specification (RFC 3369, RFC 3370) for content and key encryption. 47 1.1 SEED 49 SEED is a symmetric encryption algorithm that had been developed by 50 KISA (Korea Information Security Agency) and a group of experts since 51 1998. The input/output block size of SEED is 128-bit and the key 52 length is also 128-bit. SEED has the 16-round Feistel structure. A 53 128-bit input is divided into two 64-bit blocks and the right 64-bit 54 block is an input to the round function with a 64-bit subkey 55 generated from the key scheduling. 57 SEED is easily implemented in various software and hardware because 58 it is designed to increase the efficiency of memory storage and the 59 simplicity in generating keys without degrading the security of the 60 algorithm. In particular, it can be effectively adopted to a 61 computing environment with a restricted resources such as a mobile 62 devices, smart cards and so on. 64 SEED is robust against known attacks including DC (Differential 65 cryptanalysis), LC (Linear cryptanalysis) and related key attacks, 66 etc. SEED has gone through wide public scrutinizing procedures. 67 Especially, it has been evaluated and also considered 68 cryptographically secure by trustworhty organizations such as ISO/IEC 69 JTC 1/SC 27 and Japan CRYTEC (Cryptography Reasearch and Evaluation 70 Comittees) [ISOSEED][CRYPTEC]. 72 SEED is a national industrial association standard [TTASSEED] and is 73 widely used in South Korea for electronic commerce and financial 74 services operated on wired & wireless PKI. 76 1.2 Terminology 78 The key words "MUST", "MUST NOT", "REQUIRED", "SHOULD", "SHOULD NOT", 79 "RECOMMENDED", "MAY", and "OPTIONAL" in this document (in uppercase, 80 as shown) are to be interpreted as described in [RFC2119]. 82 2. Object Identifiers for Content and Key Encryption 84 This section provides the OIDs and processing information necessary 85 for SEED to be used for content and key encryption in CMS. SEED is 86 added to the set of optional symmetric encryption algorithms in CMS 87 by providing two classes of unique object identifiers (OIDs). One 88 OID class defines the content encryption algorithms and the other 89 defines the key encryption algorithms. Thus a CMS agent can apply 90 SEED either for content or key encryption by selecting the 91 corresponding object identifier, supplying the required parameter, 92 and starting the program code. 94 2.1 OIDs for Content Encryption 96 SEED is added to the set of symmetric content encryption algorithms 97 defined in [CMSALG]. The SEED content-encryption algorithm in Cipher 98 Block Chaining (CBC) mode has the following object identifier: 100 id-seedCBC OBJECT IDENTIFIER ::= 101 { iso(1) member-body(2) korea(410) kisa(200004) 102 algorithm(1) seedCBC(4) } 104 The AlgorithmIdentifier parameters field MUST be present, and the 105 parameters field MUST contain the value of IV: 107 SeedCBCParameter ::= SeedIV -- Initialization Vector 109 SeedIV ::= OCTET STRING (SIZE(16)) 111 The plain text is padded according to Section 6.3 of [CMS]. 113 2.2 OIDs for Key Encryption 115 The key-wrap/unwrap procedures used to encrypt/decrypt a SEED 116 content-encryption key (CEK) with a SEED key-encryption key 117 (KEK) are specified in Section 3. Generation and distribution of 118 key-encryption keys are beyond the scope of this document. 120 The SEED key-encryption algorithm has the following object 121 identifier: 123 id-npki-app-cmsSeed-wrap OBJECT IDENTIFIER ::= 124 { iso(1) member-body(2) korea(410) kisa(200004) npki-app(7) 125 smime(1) alg(1) cmsSEED-wrap(1) } 127 The parameter associated with this object identifier MUST be absent, 128 because the key wrapping procedure itself defines how and when to 129 use an IV. 131 3. Key Wrap Algorithm 133 SEED key wrapping and unwrapping is done in conformance with the 134 AES key wrap algorithm [AES-WRAP][RFC3394]. 136 3.1 Notation and Defintions 138 The following notation is used in the description of the key 139 wrapping algorithms: 141 SEED(K, W) Encrypt W using the SEED codebook with key K 142 SEED-1(K, W) Decrypt W using the SEED codebook with key K 143 MSB(j, W) Return the most significant j bits of W 144 LSB(j, W) Return the least significant j bits of W 145 B1 ^ B2 The bitwise exclusive or (XOR) of B1 and B2 146 B1 | B2 Concatenate B1 and B2 147 K The key-encryption key K 148 n The number of 64-bit key data blocks 149 s The number of steps in the wrapping process, 150 s = 6n 151 P[i] The ith plaintext key data block 152 C[i] The ith ciphertext data block 153 A The 64-bit integrity check register 154 R[i] An array of 64-bit registers where 155 i = 0, 1, 2, ..., n 156 A[t], R[i][t] The contents of registers A and R[i] after 157 encryption step t. 158 IV The 64-bit initial value used during the 159 wrapping process. 161 In the key wrap algorithm, the concatenation function will be used to 162 concatenate 64-bit quantities to form the 128-bit input to the SEED 163 codebook. The extraction functions will be used to split the 128-bit 164 output from the SEED codebook into two 64-bit quantities. 166 3.2 SEED Key Wrap 168 Key wrapping with SEED is identical to Section 2.2.1 of [RFC3394] 169 with "AES" replaced by "SEED". 171 The inputs to the key wrapping process are the KEK and the plaintext 172 to be wrapped. The plaintext consists of n 64-bit blocks, containing 173 the key data being wrapped. The key wrapping process is described 174 below. 176 Inputs: Plaintext, n 64-bit values {P1, P2, ..., Pn}, and 177 Key, K (the KEK). 178 Outputs: Ciphertext, (n+1) 64-bit values {C0, C1, ..., Cn}. 180 1) Initialize variables. 182 Set A[0] to an initial value (see Section 3.4) 183 For i = 1 to n 184 R[0][i] = P[i] 186 2) Calculate intermediate values. 188 For t = 1 to s, where s = 6n 189 A[t] = MSB(64, SEED(K, A[t-1] | R[t-1][1])) ^ t 190 For i = 1 to n-1 191 R[t][i] = R[t-1][i+1] 192 R[t][n] = LSB(64, SEED(K, A[t-1] | R[t-1][1])) 194 3) Output the results. 196 Set C[0] = A[t] 197 For i = 1 to n 198 C[i] = R[t][i] 200 An alternative description of the key wrap algorithm involves 201 indexing rather than shifting. This approach allows one to 202 calculate the wrapped key in place, avoiding the rotation in the 203 previous description. This produces identical results and is more 204 easily implemented in software. 206 Inputs: Plaintext, n 64-bit values {P1, P2, ..., Pn}, and 207 Key, K (the KEK). 208 Outputs: Ciphertext, (n+1) 64-bit values {C0, C1, ..., Cn}. 210 1) Initialize variables. 212 Set A = IV, an initial value (see Section 3.4) 213 For i = 1 to n 214 R[i] = P[i] 216 2) Calculate intermediate values. 218 For j = 0 to 5 219 For i=1 to n 220 B = SEED(K, A | R[i]) 221 A = MSB(64, B) ^ t where t = (n*j)+i 222 R[i] = LSB(64, B) 224 3) Output the results. 226 Set C[0] = A 227 For i = 1 to n 228 C[i] = R[i] 230 3.3 SEED Key Unwrap 232 Key unwrapping with SEED is identical to Section 2.2.2 of 233 [RFC3394], with "AES" replaced by "SEED". 235 The inputs to the unwrap process are the KEK and (n+1) 64-bit blocks 236 of ciphertext consisting of previously wrapped key. It returns n 237 blocks of plaintext consisting of the n 64-bit blocks of the 238 decrypted key data. 240 Inputs: Ciphertext, (n+1) 64-bit values {C0, C1, ..., Cn}, and 241 Key, K (the KEK). 242 Outputs: Plaintext, n 64-bit values {P1, P2, ..., Pn}. 244 1) Initialize variables. 246 Set A[s] = C[0] where s = 6n 247 For i = 1 to n 248 R[s][i] = C[i] 250 2) Calculate the intermediate values. 252 For t = s to 1 253 A[t-1] = MSB(64, SEED-1(K, ((A[t] ^ t) | R[t][n])) 254 R[t-1][1] = LSB(64, SEED-1(K, ((A[t]^t) | R[t][n])) 255 For i = 2 to n 256 R[t-1][i] = R[t][i-1] 258 3) Output the results. 260 If A[0] is an appropriate initial value (see Section 3.4), 261 Then 262 For i = 1 to n 263 P[i] = R[0][i] 264 Else 265 Return an error 267 The unwrap algorithm can also be specified as an index based 268 operation, allowing the calculations to be carried out in place. 269 Again, this produces the same results as the register shifting 270 approach. 272 Inputs: Ciphertext, (n+1) 64-bit values {C0, C1, ..., Cn}, and 273 Key, K (the KEK). 274 Outputs: Plaintext, n 64-bit values {P0, P1, K, Pn}. 276 1) Initialize variables. 278 Set A = C[0] 279 For i = 1 to n 280 R[i] = C[i] 282 2) Compute intermediate values. 284 For j = 5 to 0 285 For i = n to 1 286 B = SEED-1(K, (A ^ t) | R[i]) where t = n*j+i 287 A = MSB(64, B) 288 R[i] = LSB(64, B) 290 3) Output results. 292 If A is an appropriate initial value (see Section 3.4), 293 Then 294 For i = 1 to n 295 P[i] = R[i] 296 Else 297 Return an error 299 3.4 Key Data Integrity -- the Initial Value 301 The initial value (IV) refers to the value assigned to A[0] in the 302 first step of the wrapping process. This value is used to obtain an 303 integrity check on the key data. In the final step of the 304 unwrapping process, the recovered value of A[0] is compared to the 305 expected value of A[0]. If there is a match, the key is accepted as 306 valid, and the unwrapping algorithm returns it. If there is not a 307 match, then the key is rejected, and the unwrapping algorithm 308 returns an error. 310 The exact properties achieved by this integrity check depend on the 311 definition of the initial value. Different applications may call 312 for somewhat different properties; for example, whether there is 313 need to determine the integrity of key data throughout its lifecycle 314 or just when it is unwrapped. This specification defines a default 315 initial value that supports integrity of the key data during the 316 period it is wrapped (in Section 3.4.1). Provision is also made to 317 support alternative initial values (in Section 3.4.2). 319 3.4.1 Default Initial Value 321 The default initial value (IV) is defined to be the hexadecimal 322 constant: 324 A[0] = IV = A6A6A6A6A6A6A6A6 326 The use of a constant as the IV supports a strong integrity check on 327 the key data during the period that it is wrapped. If unwrapping 328 produces A[0] = A6A6A6A6A6A6A6A6, then the chance that the key data 329 is corrupt is 2^-64. If unwrapping produces A[0] any other value, 330 then the unwrap must return an error and not return any key data. 332 3.4.2 Alternative Initial Values 334 When the key wrap is used as part of a larger key management 335 protocol or system, the desired scope for data integrity may be more 336 than just the key data or the desired duration for more than just 337 the period that it is wrapped. Also, if the key data is not just an 338 SEED key, it may not always be a multiple of 64 bits. 339 Alternative definitions of the initial value can be used to address 340 such problems. According to [RFC3394], NIST will define alternative 341 initial values in future key management publications as needed. In 342 order to accommodate a set of alternatives that may evolve over 343 time, key wrap implementations that are not application-specific 344 will require some flexibility in the way that the initial value is 345 set and tested. 347 4. SMIMECapabilities Attribute 349 An S/MIME client SHOULD announce the set of cryptographic functions 350 it supports by using the S/MIME capabilities attribute. This 351 attribute provides a partial list of OIDs of cryptographic functions 352 and MUST be signed by the client. The functions' OIDs SHOULD be 353 logically separated in functional categories and MUST be ordered 354 with respect to their preference. 356 RFC 2633 [RFC2633], Section 2.5.2 defines the SMIMECapabilities 357 signed attribute (defined as a SEQUENCE of SMIMECapability 358 SEQUENCEs) to be used to specify a partial list of algorithms that 359 the software announcing the SMIMECapabilities can support. 361 If an S/MIME client is required to support symmetric encryption with 362 SEED, the capabilities attribute MUST contain the SEED OID 363 specified above in the category of symmetric algorithms. The 364 parameter associated with this OID MUST be SeedSMimeCapability. 366 SeedSMimeCapabilty ::= NULL 368 The SMIMECapability SEQUENCE representing SEED MUST be 369 DER-encoded as the following hexadecimal strings: 371 30 0d 06 0a 2a 83 1a 8c 9a 44 07 01 01 01 05 00 373 When a sending agent creates an encrypted message, it has to decide 374 which type of encryption algorithm to use. In general the decision 375 process involves information obtained from the capabilities lists 376 included in messages received from the recipient, as well as other 377 information such as private agreements, user preferences, legal 378 restrictions, and so on. If users require SEED for symmetric 379 encryption, it MUST be supported by the S/MIME clients on both the 380 sending and receiving side, and it MUST be set in the user 381 preferences. 383 5. Security Considerations 385 This document specifies the use of SEED for encrypting the 386 content of a CMS message and for encrypting the symmetric key used 387 to encrypt the content of a CMS message, and the other mechanisms 388 are the same as the existing ones. Therefore, the security 389 considerations described in the CMS specifications [CMS][CMSALG] and 390 the AES key wrap algorithm [AES-WRAP][RFC3394] can be applied to 391 this document. No security problem has been found on SEED 392 [CRYPTREC]. 394 6. Intellectual Property Statement 396 The IETF takes no position regarding the validity or scope of any 397 intellectual property or other rights that might be claimed to 398 pertain to the implementation or use of the technology described 399 in this document or the extent to which any license under such 400 rights might or might not be available; neither does it represent 401 that it has made any effort to identify any such rights. 402 Information on the IETF's procedures with respect to rights in 403 standards-track and standards-related documentation can be found 404 in BCP-11. Copies of claims of rights made available for 405 publication and any assurances of licenses to be made available, 406 or the result of an attempt made to obtain a general license or 407 permission for the use of such proprietary rights by implementors 408 or users of this specification can be obtained from the IETF 409 Secretariat. 411 The IETF invites any interested party to bring to its attention 412 any copyrights, patents or patent applications, or other 413 proprietary rights which may cover technology that may be required 414 to practice this standard. Please address the information to the 415 IETF Executive Director. 417 7. Full Copyright Statement 419 Copyright (C) The Internet Society (2003). All Rights Reserved. 421 This document and translations of it may be copied and furnished 422 to others, and derivative works that comment on or otherwise 423 explain it or assist in its implmentation may be prepared, copied, 424 published and distributed, in whole or in part, without 425 restriction of any kind, provided that the above copyright notice 426 and this paragraph are included on all such copies and derivative 427 works. However, this document itself may not be modified in any 428 way, such as by removing the copyright notice or references to the 429 Internet Society or other Internet organizations, except as needed 430 for the purpose of developing Internet standards in which case the 431 procedures for copyrights defined in the Internet Standards 432 process must be followed, or as required to translate it into 433 languages other than English. 435 The limited permissions granted above are perpetual and will not 436 be revoked by the Internet Society or its successors or assigns. 438 This document and the information contained herein is provided on 439 an "AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET 440 ENGINEERING TASK FORCE DISCLAIMS ALL WARRANTIES, EXPRESS OR 441 IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF 442 THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED 443 WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR 444 PURPOSE." 446 8. References 448 8.1 Normative Reference 450 [CMS] R. Housley, "Cryptographic Message Syntax", RFC 3369, 451 August 2002. 453 [CMSALG] R. Housley, "Cryptographic Message Syntax (CMS) 454 Algorithms", RFC 3370, August 2002. 456 [RFC2119] S. Bradner, "Key words for use in RFCs to Indicate 457 Requirement Levels", BCP 14, RFC 2119, March 1997. 459 [RFC2633] Ramsdell, B., Editor. S/MIME Version 3 Message 460 Specification. RFC 2633. June 1999. 462 [RFC3394] J. Schaad and R. Housley, "Advanced Encryption Standard 463 (AES) Key Wrap Algorithm", RFC 3394, September 2002. 465 [AES-WRAP] National Institute of Standards and Technology. AES Key 466 Wrap Specification. 17 November 2001. 467 http://csrc.nist.gov/encryption/kms/key-wrap.pdf 469 8.2 Informative Reference 471 [TTASSEED] Telecommunications Technology Association (TTA), 472 South Korea, "128-bit Symmetric Block Cipher (SEED)", 473 TTAS.KO-12.0004, September, 1998 (In Korean) 474 http://www.tta.or.kr/English/new/main/index.htm 476 [ISOSEED] ISO/IEC, ISO/IEC JTC1/SC 27 N 256r1, "National Body 477 contributions on NP 18033 Encryption algorithms in 478 response to document SC 27 N 2563", October, 2000 480 [CRYPTREC] Information-technology Promotion Agency (IPA), Japan, 481 CRYPTREC. "SEED Evaluation Report", February, 2002 482 http://www.kisa.or.kr 484 9. Authors' Address 486 Jongwook Park 487 Korea Information Security Agency 488 Phone: +82-2-405-5432 489 FAX: +82-2-405-5499 490 Email: khopri@kisa.or.kr 492 Sungjae Lee 493 Korea Information Security Agency 494 Phone: +82-2-405-5243 495 FAX: +82-2-405-5499 496 Email: sjlee@kisa.or.kr 498 Jinsu Hyun 499 Korea Information Security Agency 500 Phone: +82-2-405-5252 501 FAX: +82-2-405-5499 502 Email: jshyun@kisa.or.kr 504 Jaeil Lee 505 Korea Information Security Agency 506 Phone: +82-2-405-5421 507 FAX: +82-2-405-5499 508 Email: jilee@kisa.or.kr 510 Appendix A ASN.1 Module 512 SeedEncryptionAlgorithmInCMS 513 { iso(1) member-body(2) us(840) rsadsi(113549) pkcs(1) 514 pkcs9(9) smime(16) modules(0) id-mod-cms-seed(?) } 516 DEFINITIONS IMPLICIT TAGS ::= 517 BEGIN 519 id-seedCBC OBJECT IDENTIFIER ::= 520 { iso(1) member-body(2) korea(410) kisa(200004) 521 algorithm(1) seedCBC(4) } 523 -- Initialization Vector 525 SeedCBCParameter ::= SeedIV 527 SeedIV ::= OCTET STRING (SIZE(16)) 529 -- SEED Key Wrap Algorithm identifiers - Parameter is absent. 531 id-npki-app-cmsSeed-wrap OBJECT IDENTIFIER ::= 532 { iso(1) member-body(2) korea(410) kisa(200004) npki-app(7) 533 smime(1) alg(1) cmsSEED-wrap(1) } 535 -- SEED S/MIME Capabilty parameter 537 SeedSMimeCapability ::= NULL 539 END