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