idnits 2.17.1 draft-ietf-smime-cms-seed-02.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- ** It looks like you're using RFC 3978 boilerplate. You should update this to the boilerplate described in the IETF Trust License Policy document (see https://trustee.ietf.org/license-info), which is required now. -- Found old boilerplate from RFC 3667, Section 5.1 on line 17. -- Found old boilerplate from RFC 3978, Section 5.5 on line 505. -- Found old boilerplate from RFC 3979, Section 5, paragraph 1 on line 478. -- Found old boilerplate from RFC 3979, Section 5, paragraph 2 on line 485. -- Found old boilerplate from RFC 3979, Section 5, paragraph 3 on line 491. ** Found boilerplate matching RFC 3978, Section 5.4, paragraph 1 (on line 497), which is fine, but *also* found old RFC 2026, Section 10.4C, paragraph 1 text on line 37. ** The document seems to lack an RFC 3978 Section 5.1 IPR Disclosure Acknowledgement -- however, there's a paragraph with a matching beginning. Boilerplate error? ** This document has an original RFC 3978 Section 5.4 Copyright Line, instead of the newer IETF Trust Copyright according to RFC 4748. ** The document seems to lack an RFC 3978 Section 5.4 Reference to BCP 78 -- however, there's a paragraph with a matching beginning. Boilerplate error? ** This document has an original RFC 3978 Section 5.5 Disclaimer, instead of the newer disclaimer which includes the IETF Trust according to RFC 4748. ** The document uses RFC 3667 boilerplate or RFC 3978-like boilerplate instead of verbatim RFC 3978 boilerplate. After 6 May 2005, submission of drafts without verbatim RFC 3978 boilerplate is not accepted. The following non-3978 patterns matched text found in the document. That text should be removed or replaced: By submitting this Internet-Draft, I certify that any applicable patent or other IPR claims of which I am aware have been disclosed, or will be disclosed, and any of which I become aware will be disclosed, in accordance with RFC 3668. Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- ** 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 6 months document validity. ** 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 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 (August 2004) is 7191 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 81, but not defined -- Looks like a reference, but probably isn't: '1' on line 287 -- Looks like a reference, but probably isn't: '2' on line 254 -- Looks like a reference, but probably isn't: '0' on line 341 -- Possible downref: Non-RFC (?) normative reference: ref. 'TTASSEED' ** 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 Summary: 15 errors (**), 0 flaws (~~), 4 warnings (==), 11 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 1 S/MIME Working Group Jongwook Park (KISA) 2 Internet Draft Sungjae Lee (KISA) 3 Document: draft-ietf-smime-cms-seed-02.txt Jeeyeon Kim (KISA) 4 Expires: Feburary 2005 Jaeil Lee (KISA) 5 Target category : Standard Track August 2004 7 Use of the SEED Encryption Algorithm 8 in Cryptographic Message Syntax (CMS) 10 12 Status of this Memo 14 By submitting this Internet-Draft, I certify that any applicable 15 patent or other IPR claims of which I am aware have been disclosed, 16 and any of which I become aware will be disclosed, in accordance with 17 RFC 3668. 19 Internet Drafts are working documents of the Internet Engineering 20 Task Force (IETF), its Areas, and its Working Groups. Note that other 21 groups may also distribute working documents as Internet Drafts. 23 Internet Drafts are draft documents valid for a maximum of six 24 months. Internet Drafts may be updated, replaced, or obsoleted by 25 other documents at any time. It is not appropriate to use Internet 26 Drafts as reference material or to cite them other than as a "working 27 draft" or "work in progress". 29 The list of current Internet-Drafts can be accessed at 30 http//www.ietf.org/ietf/1id-abstracts.txt 32 The list of Internet-Draft Shadow Directories can be accessed at 33 http//www.ietf.org/shadow.html. 35 Copyright Notice 37 Copyright (C) The Internet Society (2004). All Rights Reserved. 39 Abstract 41 This document specifies the conventions for using the SEED encryption 42 algorithm for encryption with the Cryptographic Message Syntax (CMS). 44 SEED is added to the set of optional symmetric encryption algorithms 45 in CMS by providing two classes of unique object identifiers (OIDs). 47 One OID class defines the content encryption algorithms and the other 48 defines the key encryption algorithms. 50 1. Introduction 52 This document specifies the conventions for using the SEED encryption 53 algorithm [SEED][TTASSEED] for encryption with the Cryptographic 54 Message Syntax (CMS)[CMS]. The relevant object identifiers (OIDs) and 55 processing steps are provided so that SEED may be used in the CMS 56 specification (RFC 3369, RFC 3370) for content and key encryption. 58 1.1 SEED 60 SEED is a symmetric encryption algorithm that had been developed by 61 KISA (Korea Information Security Agency) and a group of experts since 62 1998. The input/output block size of SEED is 128-bit and the key 63 length is also 128-bit. SEED has the 16-round Feistel structure. A 64 128-bit input is divided into two 64-bit blocks and the right 64-bit 65 block is an input to the round function with a 64-bit subkey 66 generated from the key scheduling. 68 SEED is easily implemented in various software and hardware because 69 it takes less memory to implement that than other algorithms and 70 generates keys without degrading the security of the algorithm. In 71 particular, it can be effectively adopted to a computing environment 72 with a restricted resources such as a mobile devices, smart cards and 73 so on. 75 SEED is robust against known attacks including DC (Differential 76 cryptanalysis), LC (Linear cryptanalysis) and related key attacks, 77 etc. SEED has gone through wide public scrutinizing procedures. 78 Especially, it has been evaluated and also considered 79 cryptographically secure by credible organizations such as ISO/IEC 80 JTC 1/SC 27 and Japan CRYTEC (Cryptography Reasearch and Evaluation 81 Comittees) [ISOSEED][CRYPTEC]. 83 SEED is a national industrial association standard [TTASSEED] and is 84 widely used in South Korea for electronic commerce and financial 85 services operated on wired & wireless communications. 87 1.2 Terminology 89 The key words "MUST", "MUST NOT", "REQUIRED", "SHOULD", "SHOULD NOT", 90 "RECOMMENDED", "MAY", and "OPTIONAL" in this document (in uppercase, 91 as shown) are to be interpreted as described in [RFC2119]. 93 2. Object Identifiers for Content and Key Encryption 95 This section provides the OIDs and processing information necessary 96 for SEED to be used for content and key encryption in CMS. SEED is 97 added to the set of optional symmetric encryption algorithms in CMS 98 by providing two classes of unique object identifiers (OIDs). One OID 99 class defines the content encryption algorithms and the other defines 100 the key encryption algorithms. Thus a CMS agent can apply SEED either 101 for content or key encryption by selecting the corresponding object 102 identifier, supplying the required parameter, and starting the 103 program code. 105 2.1 OIDs for Content Encryption 107 SEED is added to the set of symmetric content encryption algorithms 108 defined in [CMSALG]. The SEED content-encryption algorithm in Cipher 109 Block Chaining (CBC) mode has the following object identifier: 111 id-seedCBC OBJECT IDENTIFIER ::= 112 { iso(1) member-body(2) korea(410) kisa(200004) 113 algorithm(1) seedCBC(4) } 115 The AlgorithmIdentifier parameters field MUST be present, and the 116 parameters field MUST contain the value of Initialization Vector 117 (IV): 119 SeedCBCParameter ::= SeedIV -- Initialization Vector 121 SeedIV ::= OCTET STRING (SIZE(16)) 123 The plain text is padded according to Section 6.3 of [CMS]. 125 2.2 OIDs for Key Encryption 127 The key-wrap/unwrap procedures used to encrypt/decrypt a SEED 128 content-encryption key (CEK) with a SEED key-encryption key (KEK) are 129 specified in Section 3. Generation and distribution of key-encryption 130 keys are beyond the scope of this document. 132 The SEED key-encryption algorithm has the following object 133 identifier: 135 id-npki-app-cmsSeed-wrap OBJECT IDENTIFIER ::= 136 { iso(1) member-body(2) korea(410) kisa(200004) npki-app(7) 137 smime(1) alg(1) cmsSEED-wrap(1) } 139 The parameter associated with this object identifier MUST be absent, 140 because the key wrapping procedure itself defines how and when to use 141 an IV. 143 3. Key Wrap Algorithm 145 SEED key wrapping and unwrapping is done in conformance with the AES 146 key wrap algorithm [RFC3394]. 148 3.1 Notation and Defintions 150 The following notation is used in the description of the key wrapping 151 algorithms: 153 SEED(K, W) Encrypt W using the SEED codebook with key K 154 SEED-1(K, W) Decrypt W using the SEED codebook with key K 155 MSB(j, W) Return the most significant j bits of W 156 LSB(j, W) Return the least significant j bits of W 157 B1 ^ B2 The bitwise exclusive or (XOR) of B1 and B2 158 B1 | B2 Concatenate B1 and B2 159 K The key-encryption key K 160 n The number of 64-bit key data blocks 161 s The number of steps in the wrapping process, 162 s = 6n 163 P[i] The ith plaintext key data block 164 C[i] The ith ciphertext data block 165 A The 64-bit integrity check register 166 R[i] An array of 64-bit registers where 167 i = 0, 1, 2, ..., n 168 A[t], R[t][i] The contents of registers A and R[i] after 169 encryption step t. 170 IV The 64-bit initial value used during the 171 wrapping process. 173 In the key wrap algorithm, the concatenation function will be used to 174 concatenate 64-bit quantities to form the 128-bit input to the SEED 175 codebook. The extraction functions will be used to split the 128-bit 176 output from the SEED codebook into two 64-bit quantities. 178 3.2 SEED Key Wrap 180 Key wrapping with SEED is identical to Section 2.2.1 of [RFC3394] 181 with "AES" replaced by "SEED". 183 The inputs to the key wrapping process are the KEK and the plaintext 184 to be wrapped. The plaintext consists of n 64-bit blocks, containing 185 the key data being wrapped. The key wrapping process is described 186 below. 188 Inputs: Plaintext, n 64-bit values {P[1], P[2], ..., P[n]}, and 189 Key, K (the KEK). 190 Outputs: Ciphertext, (n+1) 64-bit values {C[0], C[1], ..., C[n]}. 192 1) Initialize variables. 194 Set A[0] to an initial value (see Section 3.4) 195 For i = 1 to n 196 R[0][i] = P[i] 198 2) Calculate intermediate values. 200 For t = 1 to s, where s = 6n 201 A[t] = MSB(64, SEED(K, A[t-1] | R[t-1][1])) ^ t 202 For i = 1 to n-1 203 R[t][i] = R[t-1][i+1] 204 R[t][n] = LSB(64, SEED(K, A[t-1] | R[t-1][1])) 206 3) Output the results. 208 Set C[0] = A[s] 209 For i = 1 to n 210 C[i] = R[s][i] 212 An alternative description of the key wrap algorithm involves 213 indexing rather than shifting. This approach allows one to calculate 214 the wrapped key in place, avoiding the rotation in the previous 215 description. This produces identical results and is more easily 216 implemented in software. 218 Inputs: Plaintext, n 64-bit values {P[1], P[2], ..., P[n]}, and 219 Key, K (the KEK). 220 Outputs: Ciphertext, (n+1) 64-bit values {C[0], C[1], ..., C[n]}. 222 1) Initialize variables. 224 Set A = IV, an initial value (see Section 3.4) 225 For i = 1 to n 226 R[i] = P[i] 228 2) Calculate intermediate values. 230 For j = 0 to 5 231 For i=1 to n 232 B = SEED(K, A | R[i]) 233 A = MSB(64, B) ^ t where t = (n*j)+i 234 R[i] = LSB(64, B) 236 3) Output the results. 238 Set C[0] = A 239 For i = 1 to n 240 C[i] = R[i] 242 3.3 SEED Key Unwrap 244 Key unwrapping with SEED is identical to Section 2.2.2 of [RFC3394], 245 with "AES" replaced by "SEED". 247 The inputs to the unwrap process are the KEK and (n+1) 64-bit blocks 248 of ciphertext consisting of previously wrapped key. It returns n 249 blocks of plaintext consisting of the n 64-bit blocks of the 250 decrypted key data. 252 Inputs: Ciphertext, (n+1) 64-bit values {C[0], C[1], ..., C[n]}, 253 and Key, K (the KEK). 254 Outputs: Plaintext, n 64-bit values {P[1], P[2], ..., P[n]}. 256 1) Initialize variables. 258 Set A[s] = C[0] where s = 6n 259 For i = 1 to n 260 R[s][i] = C[i] 262 2) Calculate the intermediate values. 264 For t = s to 1 265 A[t-1] = MSB(64, SEED-1(K, ((A[t] ^ t) | R[t][n])) 266 R[t-1][1] = LSB(64, SEED-1(K, ((A[t]^t) | R[t][n])) 267 For i = 2 to n 268 R[t-1][i] = R[t][i-1] 270 3) Output the results. 272 If A[0] is an appropriate initial value (see Section 3.4), 273 Then 274 For i = 1 to n 275 P[i] = R[0][i] 276 Else 277 Return an error 279 The unwrap algorithm can also be specified as an index based 280 operation, allowing the calculations to be carried out in place. 281 Again, this produces the same results as the register shifting 282 approach. 284 Inputs: Ciphertext, (n+1) 64-bit values {C[0], C[1], ..., C[n]}, 285 and Key, K (the KEK). 287 Outputs: Plaintext, n 64-bit values {P[0], P[1], ..., P[n]}. 289 1) Initialize variables. 291 Set A = C[0] 292 For i = 1 to n 293 R[i] = C[i] 295 2) Compute intermediate values. 297 For j = 5 to 0 298 For i = n to 1 299 B = SEED-1(K, (A ^ t) | R[i]) where t = n*j+i 300 A = MSB(64, B) 301 R[i] = LSB(64, B) 303 3) Output results. 305 If A is an appropriate initial value (see Section 3.4), 306 Then 307 For i = 1 to n 308 P[i] = R[i] 309 Else 310 Return an error 312 3.4 Key Data Integrity -- the Initial Value 314 The initial value (IV) refers to the value assigned to A[0] in the 315 first step of the wrapping process. This value is used to obtain an 316 integrity check on the key data. In the final step of the unwrapping 317 process, the recovered value of A[0] is compared to the expected 318 value of A[0]. If there is a match, the key is accepted as valid, and 319 the unwrapping algorithm returns it. If there is not a match, then 320 the key is rejected, and the unwrapping algorithm returns an error. 322 The exact properties achieved by this integrity check depend on the 323 definition of the initial value. Different applications may call for 324 somewhat different properties; for example, whether there is need to 325 determine the integrity of key data throughout its lifecycle or just 326 when it is unwrapped. This specification defines a default initial 327 value that supports integrity of the key data during the period it is 328 wrapped (in Section 3.4.1). Provision is also made to support 329 alternative initial values (in Section 3.4.2). 331 3.4.1 Default Initial Value 333 The default initial value (IV) is defined to be the hexadecimal 334 constant: 336 A[0] = IV = A6A6A6A6A6A6A6A6 338 The use of a constant as the IV supports a strong integrity check on 339 the key data during the period that it is wrapped. If unwrapping 340 produces A[0] = A6A6A6A6A6A6A6A6, then the chance that the key data 341 is corrupt is 2^-64. If unwrapping produces A[0] any other value, 342 then the unwrap must return an error and not return any key data. 344 3.4.2 Alternative Initial Values 346 When the key wrap is used as part of a larger key management protocol 347 or system, the desired scope for data integrity may be more than just 348 the key data or the desired duration for more than just the period 349 that it is wrapped. Also, if the key data is not just an SEED key, it 350 may not always be a multiple of 64 bits. Alternative definitions of 351 the initial value can be used to address such problems. According to 352 [RFC3394], NIST will define alternative initial values in future key 353 management publications as needed. In order to accommodate a set of 354 alternatives that may evolve over time, key wrap implementations that 355 are not application-specific will require some flexibility in the way 356 that the initial value is set and tested. 358 4. SMIMECapabilities Attribute 360 An S/MIME client SHOULD announce the set of cryptographic functions 361 it supports by using the S/MIME capabilities attribute. This 362 attribute provides a partial list of OIDs of cryptographic functions 363 and MUST be signed by the client. The functions' OIDs SHOULD be 364 logically separated in functional categories and MUST be ordered with 365 respect to their preference. 367 RFC 2633 [RFC2633], Section 2.5.2 defines the SMIMECapabilities 368 signed attribute (defined as a SEQUENCE of SMIMECapability SEQUENCEs) 369 to be used to specify a partial list of algorithms that the software 370 announcing the SMIMECapabilities can support. 372 If an S/MIME client is required to support symmetric encryption with 373 SEED, the capabilities attribute MUST contain the SEED OID specified 374 above in the category of symmetric algorithms. The parameter 375 associated with this OID MUST be SeedSMimeCapability. 377 SeedSMimeCapabilty ::= NULL 379 The SMIMECapability SEQUENCE representing SEED MUST be DER-encoded as 380 the following hexadecimal strings: 382 30 0C 06 08 2A 83 1A 8C 9A 44 01 04 05 00 384 When a sending agent creates an encrypted message, it has to decide 385 which type of encryption algorithm to use. In general the decision 386 process involves information obtained from the capabilities lists 387 included in messages received from the recipient, as well as other 388 information such as private agreements, user preferences, legal 389 restrictions, and so on. If local policy requires the use of SEED for 390 symmetric encryption, then the both the sending and receiving S/MIME 391 clients must support it, and SEED must be configured as the preferred 392 symmetric algorithm. 394 5. Security Considerations 396 This document specifies the use of SEED for encrypting the content of 397 a CMS message and for encrypting the symmetric key used to encrypt 398 the content of a CMS message, and the other mechanisms are the same 399 as the existing ones. Therefore, the security considerations 400 described in the CMS specifications [CMS][CMSALG] and the AES key 401 wrap algorithm [RFC3394] can be applied to this document. No security 402 problem has been found on SEED [CRYPTREC]. 404 6. References 406 6.1 Normative Reference 408 [TTASSEED] Telecommunications Technology Association (TTA), 409 South Korea, "128-bit Symmetric Block Cipher (SEED)", 410 TTAS.KO-12.0004, September, 1998 (In Korean) 411 http://www.tta.or.kr/English/new/main/index.htm 413 [CMS] R. Housley, "Cryptographic Message Syntax", RFC 3369, 414 August 2002. 416 [CMSALG] R. Housley, "Cryptographic Message Syntax (CMS) 417 Algorithms", RFC 3370, August 2002. 419 [RFC2633] Ramsdell, B., Editor. S/MIME Version 3 Message 420 Specification. RFC 2633. June 1999. 422 [RFC3394] J. Schaad and R. Housley, "Advanced Encryption Standard 423 (AES) Key Wrap Algorithm", RFC 3394, September 2002. 425 [RFC2119] S. Bradner, "Key words for use in RFCs to Indicate 426 Requirement Levels", BCP 14, RFC 2119, March 1997. 428 6.2 Informative Reference 430 [SEED] Jongwook Park, Sungjae Lee, Jeeyeon Kim, Jaeil Lee, 431 "The SEED Encryption Algorithm", draft-park-seed-01.txt 433 [ISOSEED] ISO/IEC, ISO/IEC JTC1/SC 27 N 256r1, "National Body 434 contributions on NP 18033 Encryption algorithms in 435 response to document SC 27 N 2563", October, 2000 437 [CRYPTREC] Information-technology Promotion Agency (IPA), Japan, 438 CRYPTREC. "SEED Evaluation Report", February, 2002 439 http://www.kisa.or.kr 441 7. Authors' Address 443 Jongwook Park 444 Korea Information Security Agency 445 78, Garak-Dong, Songpa-Gu, Seoul, 138-803 446 REPUBLIC OF KOREA 447 Phone: +82-2-405-5432 448 FAX : +82-2-405-5499 449 Email: khopri@kisa.or.kr 451 Sungjae Lee 452 Korea Information Security Agency 453 Phone: +82-2-405-5243 454 FAX : +82-2-405-5499 455 Email: sjlee@kisa.or.kr 457 Jeeyeon Kim 458 Korea Information Security Agency 459 Phone: +82-2-405-5238 460 FAX : +82-2-405-5499 461 Email: jykim@kisa.or.kr 463 Jaeil Lee 464 Korea Information Security Agency 465 Phone: +82-2-405-5300 466 FAX : +82-2-405-5499 467 Email: jilee@kisa.or.kr 469 8. Intellectual Property Statement 471 The IETF takes no position regarding the validity or scope of any 472 Intellectual Property Rights or other rights that might be claimed to 473 pertain to the implementation or use of the technology described in 474 this document or the extent to which any license under such rights 475 might or might not be available; nor does it represent that it has 476 made any independent effort to identify any such rights. Information 477 on the procedures with respect to rights in RFC documents can be 478 found in BCP 78 and BCP 79. 480 Copies of IPR disclosures made to the IETF Secretariat and any 481 assurances of licenses to be made available, or the result of an 482 attempt made to obtain a general license or permission for the use of 483 such proprietary rights by implementers or users of this 484 specification can be obtained from the IETF on-line IPR repository at 485 http://www.ietf.org/ipr. 487 The IETF invites any interested party to bring to its attention any 488 copyrights, patents or patent applications, or other proprietary 489 rights that may cover technology that may be required to implement 490 this standard. Please address the information to the IETF at ietf- 491 ipr@ietf.org. 493 9. Full Copyright Statement 495 Copyright (C) The Internet Society (2004). This document is subject 496 to the rights, licenses and restrictions contained in BCP 78 and 497 except as set forth therein, the authors retain all their rights. 499 This document and the information contained herein are provided on an 500 "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS 501 OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE INTERNET 502 ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR IMPLIED, 503 INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE 504 INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED 505 WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. 507 Appendix. ASN.1 Module 509 SeedEncryptionAlgorithmInCMS 510 { iso(1) member-body(2) us(840) rsadsi(113549) pkcs(1) 511 pkcs9(9) smime(16) modules(0) id-mod-cms-seed(24) } 513 DEFINITIONS IMPLICIT TAGS ::= 515 BEGIN 517 id-seedCBC OBJECT IDENTIFIER ::= 518 { iso(1) member-body(2) korea(410) kisa(200004) 519 algorithm(1) seedCBC(4) } 521 -- Initialization Vector (IV) 522 SeedCBCParameter ::= SeedIV 523 SeedIV ::= OCTET STRING (SIZE(16)) 525 -- SEED Key Wrap Algorithm identifiers - Parameter is absent. 527 id-npki-app-cmsSeed-wrap OBJECT IDENTIFIER ::= 528 { iso(1) member-body(2) korea(410) kisa(200004) npki-app(7) 529 smime(1) alg(1) cmsSEED-wrap(1) } 531 -- SEED S/MIME Capabilty parameter 533 SeedSMimeCapability ::= NULL 535 END