idnits 2.17.1 draft-ietf-smime-camellia-03.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- ** Looks like you're using RFC 2026 boilerplate. This must be updated to follow RFC 3978/3979, as updated by RFC 4748. Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- == No 'Intended status' indicated for this document; assuming Proposed Standard Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- ** The document seems to lack an IANA Considerations section. (See Section 2.2 of https://www.ietf.org/id-info/checklist for how to handle the case when there are no actions for IANA.) ** The document seems to lack separate sections for Informative/Normative References. All references will be assumed normative when checking for downward references. ** There are 2 instances of too long lines in the document, the longest one being 1 character in excess of 72. ** There are 10 instances of lines with control characters in the document. Miscellaneous warnings: ---------------------------------------------------------------------------- == The document seems to lack the recommended RFC 2119 boilerplate, even if it appears to use RFC 2119 keywords -- however, there's a paragraph with a matching beginning. Boilerplate error? (The document does seem to have the reference to RFC 2119 which the ID-Checklist requires). -- The document seems to lack a disclaimer for pre-RFC5378 work, but may have content which was first submitted before 10 November 2008. If you have contacted all the original authors and they are all willing to grant the BCP78 rights to the IETF Trust, then this is fine, and you can ignore this comment. If not, you may need to add the pre-RFC5378 disclaimer. (See the Legal Provisions document at https://trustee.ietf.org/license-info for more information.) -- The document date (April 2003) is 7682 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) -- Looks like a reference, but probably isn't: '0' on line 362 -- Looks like a reference, but probably isn't: '1' on line 287 == Unused Reference: 'AES' is defined on line 438, but no explicit reference was found in the text == Unused Reference: 'DES' is defined on line 442, but no explicit reference was found in the text -- Possible downref: Non-RFC (?) normative reference: ref. 'AES' -- Possible downref: Non-RFC (?) normative reference: ref. 'DES' -- Possible downref: Non-RFC (?) normative reference: ref. 'AES-WRAP' == Outdated reference: A later version (-03) exists of draft-nakajima-camellia-02 ** Downref: Normative reference to an Informational draft: draft-nakajima-camellia (ref. 'CamelliaID') -- Possible downref: Non-RFC (?) normative reference: ref. 'CamelliaSpec' -- Possible downref: Non-RFC (?) normative reference: ref. 'CamelliaTech' ** Obsolete normative reference: RFC 3369 (ref. 'CMS') (Obsoleted by RFC 3852) -- Possible downref: Non-RFC (?) normative reference: ref. 'CRYPTREC' -- Possible downref: Non-RFC (?) normative reference: ref. 'NESSIE' ** Obsolete normative reference: RFC 2633 (Obsoleted by RFC 3851) ** Downref: Normative reference to an Informational RFC: RFC 3394 Summary: 9 errors (**), 0 flaws (~~), 5 warnings (==), 11 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 S/MIME Working Group S. Moriai 3 Internet Draft NTT Corporation 4 Document: draft-ietf-smime-camellia-03.txt A. Kato 5 Expires: October 2003 NTT Software Corporation 6 April 2003 8 Use of the Camellia 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 21 months and may be updated, replaced, or obsoleted by other documents 22 at any time. It is inappropriate to use Internet-Drafts as 23 reference 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 32 "ietf-smime" mailing list, or directly to the author. 34 Abstract 35 This document specifies the conventions for using the Camellia 36 encryption algorithm for encryption with the Cryptographic 37 Message Syntax (CMS). 39 1. Introduction 41 This document specifies the conventions for using the Camellia 42 encryption algorithm [CamelliaSpec][CamelliaID] for encryption with 43 the Cryptographic Message Syntax (CMS) [CMS]. The relevant object 44 identifiers (OIDs) and processing steps are provided so that 45 Camellia may be used in the CMS specification (RFC 3369, RFC 3370) 46 for content and key encryption. 48 1.1 Camellia 50 Camellia was jointly developed by Nippon Telegraph and Telephone 51 Corporation and Mitsubishi Electric Corporation in 2000. Camellia 52 specifies the 128-bit block size and 128-, 192-, and 256-bit key 53 sizes, the same interface as the Advanced Encryption Standard (AES). 55 Camellia is characterized by its suitability for both software and 56 hardware implementations as well as its high level of security. 57 From a practical viewpoint, it is designed to enable flexibility in 58 software and hardware implementations on 32-bit processors widely 59 used over the Internet and many applications, 8-bit processors used 60 in smart cards, cryptographic hardware, embedded systems, and so on 61 [CamelliaTech]. Moreover, its key setup time is excellent, and its 62 key agility is superior to that of AES. 64 Camellia has been scrutinized by the wide cryptographic community 65 during several projects for evaluating crypto algorithms. In 66 particular, Camellia was selected as a recommended cryptographic 67 primitive by the EU NESSIE (New European Schemes for Signatures, 68 Integrity and Encryption) project [NESSIE] and also included in the 69 list of cryptographic techniques for Japanese e-Government systems 70 which are selected by the Japan CRYPTREC (Cryptography Research and 71 Evaluation Committees) [CRYPTREC]. 73 1.2 Terminology 75 The key words "MUST", "MUST NOT", "REQUIRED", "SHOULD", "SHOULD 76 NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this document (in 77 uppercase, as shown) are to be interpreted as described in 78 [RFC2119]. 80 2. Object Identifiers for Content and Key Encryption 82 This section provides the OIDs and processing information necessary 83 for Camellia to be used for content and key encryption in CMS. 85 Camellia is added to the set of optional symmetric encryption 86 algorithms in CMS by providing two classes of unique object 87 identifiers (OIDs). One OID class defines the content encryption 88 algorithms and the other defines the key encryption algorithms. 89 Thus a CMS agent can apply Camellia either for content or key 90 encryption by selecting the corresponding object identifier, 91 supplying the required parameter, and starting the program code. 93 2.1 OIDs for Content Encryption 95 Camellia is added to the set of symmetric content encryption 96 algorithms defined in [CMSALG]. The Camellia content-encryption 97 algorithm, in Cipher Block Chaining (CBC) mode, for the three 98 different key sizes are identified by the following object 99 identifiers: 101 id-camellia128-cbc OBJECT IDENTIFIER ::= 102 { iso(1) member-body(2) 392 200011 61 security(1) 103 algorithm(1) symmetric-encryption-algorithm(1) 104 camellia128-cbc(2) } 106 id-camellia192-cbc OBJECT IDENTIFIER ::= 107 { iso(1) member-body(2) 392 200011 61 security(1) 108 algorithm(1) symmetric-encryption-algorithm(1) 109 camellia192-cbc(3) } 111 id-camellia256-cbc OBJECT IDENTIFIER ::= 112 { iso(1) member-body(2) 392 200011 61 security(1) 113 algorithm(1) symmetric-encryption-algorithm(1) 114 camellia256-cbc(4) } 116 The AlgorithmIdentifier parameters field MUST be present, and the 117 parameters field MUST contain the value of IV: 119 CamelliaCBCParameter ::= CamelliaIV -- Initialization Vector 121 CamelliaIV ::= 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 Camellia 128 content-encryption key (CEK) with a Camellia key-encryption key 129 (KEK) are specified in Section 3. Generation and distribution of 130 key-encryption keys are beyond the scope of this document. 132 The Camellia key-encryption algorithm has the following object 133 identifier: 135 id-camellia128-wrap OBJECT IDENTIFIER ::= 136 { iso(1) member-body(2) 392 200011 61 security(1) 137 algorithm(1) key-wrap-algorithm(3) 138 camellia128-wrap(2) } 140 id-camellia192-wrap OBJECT IDENTIFIER ::= 141 { iso(1) member-body(2) 392 200011 61 security(1) 142 algorithm(1) key-wrap-algorithm(3) 143 camellia192-wrap(3) } 145 id-camellia256-wrap OBJECT IDENTIFIER ::= 146 { iso(1) member-body(2) 392 200011 61 security(1) 147 algorithm(1) key-wrap-algorithm(3) 148 camellia256-wrap(4) } 150 In all cases the parameters field of AlgorithmIdentifier MUST be 151 ABSENT, because the key wrapping procedure itself defines how and 152 when to use an IV. The OID gives the KEK key size, but does not 153 make any statements as to the size of the wrapped Camellia CEK. 154 Implementations MAY use different KEK and CEK sizes. Implements 155 MUST support the CEK and the KEK having the same length. If 156 different lengths are supported, the KEK MUST be of equal or greater 157 length than the CEK. 159 3. Key Wrap Algorithm 161 Camellia key wrapping and unwrapping is done in conformance with the 162 AES key wrap algorithm [AES-WRAP][RFC3394], because Camellia and AES 163 have the same block and key sizes, i.e. the block size of 128 bits 164 and key sizes of 128, 192, and 256 bits. 166 3.1 Notation and Definitions 168 The following notation is used in the description of the key 169 wrapping algorithms: 171 Camellia(K, W) 172 Encrypt W using the Camellia codebook with key K 173 Camellia-1(K, W) 174 Decrypt W using the Camellia codebook with key K 175 MSB(j, W) Return the most significant j bits of W 176 LSB(j, W) Return the least significant j bits of W 177 B1 ^ B2 The bitwise exclusive or (XOR) of B1 and B2 178 B1 | B2 Concatenate B1 and B2 179 K The key-encryption key K 180 n The number of 64-bit key data blocks 181 s The number of steps in the wrapping process, s = 6n 182 P[i] The ith plaintext key data block 183 C[i] The ith ciphertext data block 184 A The 64-bit integrity check register 185 R[i] An array of 64-bit registers where 186 i = 0, 1, 2, ..., n 187 A[t], R[i][t] The contents of registers A and R[i] after encryption 188 step t. 189 IV The 64-bit initial value used during the wrapping 190 process. 192 In the key wrap algorithm, the concatenation function will be used 193 to concatenate 64-bit quantities to form the 128-bit input to the 194 Camellia codebook. The extraction functions will be used to split 195 the 128-bit output from the Camellia codebook into two 64-bit 196 quantities. 198 3.2 Camellia Key Wrap 200 Key wrapping with Camellia is identical to Section 2.2.1 of 201 [RFC3394] with "AES" replaced by "Camellia". 203 The inputs to the key wrapping process are the KEK and the plaintext 204 to be wrapped. The plaintext consists of n 64-bit blocks, 205 containing the key data being wrapped. The key wrapping process is 206 described below. 208 Inputs: Plaintext, n 64-bit values {P1, P2, ..., Pn}, and 209 Key, K (the KEK). 210 Outputs: Ciphertext, (n+1) 64-bit values {C0, C1, ..., Cn}. 212 1) Initialize variables. 214 Set A0 to an initial value (see Section 3.4) 215 For i = 1 to n 216 R[0][i] = P[i] 218 2) Calculate intermediate values. 220 For t = 1 to s, where s = 6n 221 A[t] = MSB(64, Camellia(K, A[t-1] | R[t-1][1])) ^ t 222 For i = 1 to n-1 223 R[t][i] = R[t-1][i+1] 224 R[t][n] = LSB(64, Camellia(K, A[t-1] | R[t-1][1])) 226 3) Output the results. 228 Set C[0] = A[t] 229 For i = 1 to n 230 C[i] = R[t][i] 232 An alternative description of the key wrap algorithm involves 233 indexing rather than shifting. This approach allows one to 234 calculate the wrapped key in place, avoiding the rotation in the 235 previous description. This produces identical results and is more 236 easily implemented in software. 238 Inputs: Plaintext, n 64-bit values {P1, P2, ..., Pn}, and 239 Key, K (the KEK). 240 Outputs: Ciphertext, (n+1) 64-bit values {C0, C1, ..., Cn}. 242 1) Initialize variables. 244 Set A = IV, an initial value (see Section 3.4) 245 For i = 1 to n 246 R[i] = P[i] 248 2) Calculate intermediate values. 250 For j = 0 to 5 251 For i=1 to n 252 B = Camellia(K, A | R[i]) 253 A = MSB(64, B) ^ t where t = (n*j)+i 254 R[i] = LSB(64, B) 256 3) Output the results. 258 Set C[0] = A 259 For i = 1 to n 260 C[i] = R[i] 262 3.3 Camellia Key Unwrap 264 Key unwrapping with Camellia is identical to Section 2.2.2 of 266 [RFC3394], with "AES" replaced by "Camellia". 268 The inputs to the unwrap process are the KEK and (n+1) 64-bit blocks 269 of ciphertext consisting of previously wrapped key. It returns n 270 blocks of plaintext consisting of the n 64-bit blocks of the 271 decrypted key data. 273 Inputs: Ciphertext, (n+1) 64-bit values {C0, C1, ..., Cn}, and 274 Key, K (the KEK). 275 Outputs: Plaintext, n 64-bit values {P1, P2, ..., Pn}. 277 1) Initialize variables. 279 Set A[s] = C[0] where s = 6n 280 For i = 1 to n 281 R[s][i] = C[i] 283 2) Calculate the intermediate values. 285 For t = s to 1 286 A[t-1] = MSB(64, Camellia-1(K, ((A[t] ^ t) | R[t][n])) 287 R[t-1][1] = LSB(64, Camellia-1(K, ((A[t]^t) | R[t][n])) 288 For i = 2 to n 289 R[t-1][i] = R[t][i-1] 291 3) Output the results. 293 If A[0] is an appropriate initial value (see Section 3.4), 294 Then 295 For i = 1 to n 296 P[i] = R[0][i] 297 Else 298 Return an error 300 The unwrap algorithm can also be specified as an index based 301 operation, allowing the calculations to be carried out in place. 302 Again, this produces the same results as the register shifting 303 approach. 305 Inputs: Ciphertext, (n+1) 64-bit values {C0, C1, ..., Cn}, and 306 Key, K (the KEK). 307 Outputs: Plaintext, n 64-bit values {P0, P1, K, Pn}. 309 1) Initialize variables. 311 Set A = C[0] 312 For i = 1 to n 313 R[i] = C[i] 315 2) Compute intermediate values. 317 For j = 5 to 0 318 For i = n to 1 319 B = Camellia-1(K, (A ^ t) | R[i]) where t = n*j+i 320 A = MSB(64, B) 321 R[i] = LSB(64, B) 323 3) Output results. 325 If A is an appropriate initial value (see Section 3.4), 326 Then 327 For i = 1 to n 328 P[i] = R[i] 329 Else 330 Return an error 332 3.4 Key Data Integrity -- the Initial Value 334 The initial value (IV) refers to the value assigned to A[0] in the 335 first step of the wrapping process. This value is used to obtain an 336 integrity check on the key data. In the final step of the 337 unwrapping process, the recovered value of A[0] is compared to the 338 expected value of A[0]. If there is a match, the key is accepted as 339 valid, and the unwrapping algorithm returns it. If there is not a 340 match, then the key is rejected, and the unwrapping algorithm 341 returns an error. 343 The exact properties achieved by this integrity check depend on the 344 definition of the initial value. Different applications may call 345 for somewhat different properties; for example, whether there is 346 need to determine the integrity of key data throughout its lifecycle 347 or just when it is unwrapped. This specification defines a default 348 initial value that supports integrity of the key data during the 349 period it is wrapped (in Section 3.4.1). Provision is also made to 350 support alternative initial values (in Section 3.4.2). 352 3.4.1 Default Initial Value 354 The default initial value (IV) is defined to be the hexadecimal 355 constant: 357 A[0] = IV = A6A6A6A6A6A6A6A6 359 The use of a constant as the IV supports a strong integrity check on 360 the key data during the period that it is wrapped. If unwrapping 361 produces A[0] = A6A6A6A6A6A6A6A6, then the chance that the key data 362 is corrupt is 2^-64. If unwrapping produces A[0] any other value, 363 then the unwrap must return an error and not return any key data. 365 3.4.2 Alternative Initial Values 367 When the key wrap is used as part of a larger key management 368 protocol or system, the desired scope for data integrity may be more 369 than just the key data or the desired duration for more than just 370 the period that it is wrapped. Also, if the key data is not just an 371 Camellia key, it may not always be a multiple of 64 bits. 372 Alternative definitions of the initial value can be used to address 373 such problems. According to [RFC3394], NIST will define alternative 374 initial values in future key management publications as needed. In 375 order to accommodate a set of alternatives that may evolve over 376 time, key wrap implementations that are not application-specific 377 will require some flexibility in the way that the initial value is 378 set and tested. 380 4. SMIMECapabilities Attribute 382 An S/MIME client SHOULD announce the set of cryptographic functions 383 it supports by using the S/MIME capabilities attribute. This 384 attribute provides a partial list of OIDs of cryptographic functions 385 and MUST be signed by the client. The functions' OIDs SHOULD be 386 logically separated in functional categories and MUST be ordered 387 with respect to their preference. 389 RFC 2633 [RFC2633], Section 2.5.2 defines the SMIMECapabilities 390 signed attribute (defined as a SEQUENCE of SMIMECapability 391 SEQUENCEs) to be used to specify a partial list of algorithms that 392 the software announcing the SMIMECapabilities can support. 394 If an S/MIME client is required to support symmetric encryption with 395 Camellia, the capabilities attribute MUST contain the Camellia OID 396 specified above in the category of symmetric algorithms. The 397 parameter associated with this OID MUST be CamelliaSMimeCapability. 399 CamelliaSMimeCapabilty ::= NULL 401 The SMIMECapability SEQUENCE representing Camellia MUST be 402 DER-encoded as the following hexadecimal strings: 404 Key Size Capability 405 128 30 0f 06 0b 2a 83 08 8c 9a 4b 3d 01 01 01 02 05 00 406 196 30 0f 06 0b 2a 83 08 8c 9a 4b 3d 01 01 01 03 05 00 407 256 30 0f 06 0b 2a 83 08 8c 9a 4b 3d 01 01 01 04 05 00 409 When a sending agent creates an encrypted message, it has to decide 410 which type of encryption algorithm to use. In general the decision 411 process involves information obtained from the capabilities lists 412 included in messages received from the recipient, as well as other 413 information such as private agreements, user preferences, legal 414 restrictions, and so on. If users require Camellia for symmetric 415 encryption, it MUST be supported by the S/MIME clients on both the 416 sending and receiving side, and it MUST be set in the user 417 preferences. 419 5. Security Considerations 421 This document specifies the use of Camellia for encrypting the 422 content of a CMS message and for encrypting the symmetric key used 423 to encrypt the content of a CMS message, and the other mechanisms 424 are the same as the existing ones. Therefore, the security 425 considerations described in the CMS specifications [CMS][CMSALG] and 426 the AES key wrap algorithm [AES-WRAP][RFC3394] can be applied to 427 this document. No security problem has been found on Camellia 428 [CRYPTREC][NESSIE]. 430 6. Intellectual Property Statement 431 Mitsubishi Electric Corporation and Nippon Telegraph and Telephone 432 Corporation have pending applications or filed patents which are 433 essential to Camellia. License policy for these essential patents 434 will be available on the IETF page of Intellectual Property Rights 435 Notices. 437 References 438 [AES] National Institute of Standards. 439 FIPS Pub 197: Advanced Encryption Standard (AES). 26 440 November 2001. 442 [DES] National Institute of Standards and Technology. 443 FIPS Pub 46: Data Encryption Standard. 15 January 1977. 445 [AES-WRAP] National Institute of Standards and Technology. AES Key 446 Wrap Specification. 17 November 2001. 447 http://csrc.nist.gov/encryption/kms/key-wrap.pdf 449 [CamelliaID] J. Nakajima and S. Moriai, "A Description of the 450 Camellia Encryption Algorithm", Internet-Draft, July 2001. 451 draft-nakajima-camellia-02.txt 453 [CamelliaSpec] K. Aoki, T. Ichikawa, M. Kanda, M. Matsui, S. Moriai, 454 J. Nakajima, and T. Tokita "Specification of Camellia - a 455 128-bit Block Cipher". http://info.isl.ntt.co.jp/camellia/ 457 [CamelliaTech] K. Aoki, T. Ichikawa, M. Kanda, M. Matsui, S. Moriai, 458 J. Nakajima, and T. Tokita "Camellia: A 128-Bit Block Cipher 459 Suitable for Multiple Platforms - Design and Analysis -", In 460 Selected Areas in Cryptography, 7th Annual International 461 Workshop, SAC 2000, August 2000, Proceedings, Lecture Notes in 462 Computer Science 2012, pp.39--56, Springer-Verlag, 2001. 464 [CMS] R. Housley, "Cryptographic Message Syntax", RFC 3369, August 465 2002. 467 [CMSALG] R. Housley, "Cryptographic Message Syntax (CMS) 468 Algorithms", RFC 3370, August 2002. 470 [CRYPTREC] Information-technology Promotion Agency (IPA), Japan, 471 CRYPTREC. http://www.ipa.go.jp/security/enc/CRYPTREC/index-e.html 473 [NESSIE] New European Schemes for Signatures, Integrity and 474 Encryption (NESSIE) project. http://www.cryptonessie.org 476 [RFC2119] S. Bradner, "Key words for use in RFCs to Indicate 477 Requirement Levels", BCP 14, RFC 2119, March 1997. 479 [RFC2633] Ramsdell, B., Editor. S/MIME Version 3 Message 480 Specification. RFC 2633. June 1999. 482 [RFC3394] J. Schaad and R. Housley, "Advanced Encryption Standard 483 (AES) Key Wrap Algorithm", RFC 3394, September 2002. 485 Authors' Address 487 Shiho Moriai 488 Nippon Telegraph and Telephone Corporation 489 Phone: +81-46-859-2007 490 FAX: +81-46-859-3858 491 Email: camellia@isl.ntt.co.jp 493 Akihiro Kato 494 NTT Software Corporation 495 Phone: +81-45-212-7404 496 FAX: +81-45-212-7410 497 Email: akato@po.ntts.co.jp 499 Appendix A ASN.1 Module 501 CamelliaEncryptionAlgorithmInCMS 502 { iso(1) member-body(2) us(840) rsadsi(113549) pkcs(1) 503 pkcs9(9) smime(16) modules(0) id-mod-cms-camellia(23) } 505 DEFINITIONS IMPLICIT TAGS ::= 506 BEGIN 508 -- Camellia using CBC-chaining mode for key sizes of 128, 192, 256 510 id-camellia128-cbc OBJECT IDENTIFIER ::= 511 { iso(1) member-body(2) 392 200011 61 security(1) 512 algorithm(1) symmetric-encryption-algorithm(1) 513 camellia128-cbc(2) } 515 id-camellia192-cbc OBJECT IDENTIFIER ::= 516 { iso(1) member-body(2) 392 200011 61 security(1) 517 algorithm(1) symmetric-encryption-algorithm(1) 518 camellia192-cbc(3) } 520 id-camellia256-cbc OBJECT IDENTIFIER ::= 521 { iso(1) member-body(2) 392 200011 61 security(1) 522 algorithm(1) symmetric-encryption-algorithm(1) 523 camellia256-cbc(4) } 525 -- Camellia-IV is a the parameter for all the above object identifiers. 527 Camellia-IV ::= OCTET STRING (SIZE(16)) 529 -- Camellia S/MIME Capabilty parameter for all the above object 530 -- identifiers. 532 CamelliaSMimeCapability ::= NULL 534 -- Camellia Key Wrap Algorithm identifiers - Parameter is absent. 536 id-camellia128-wrap OBJECT IDENTIFIER ::= 537 { iso(1) member-body(2) 392 200011 61 security(1) 538 algorithm(1) key-wrap-algorithm(3) 539 camellia128-wrap(2) } 541 id-camellia192-wrap OBJECT IDENTIFIER ::= 542 { iso(1) member-body(2) 392 200011 61 security(1) 543 algorithm(1) key-wrap-algorithm(3) 544 camellia192-wrap(3) } 546 id-camellia256-wrap OBJECT IDENTIFIER ::= 547 { iso(1) member-body(2) 392 200011 61 security(1) 548 algorithm(1) key-wrap-algorithm(3) 549 camellia256-wrap(4) } 551 END