idnits 2.17.1 draft-ietf-smime-camellia-02.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. ** The abstract seems to contain references ([RFC2119]), which it shouldn't. Please replace those with straight textual mentions of the documents in question. 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 (March 2003) is 7706 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 366 -- Looks like a reference, but probably isn't: '1' on line 291 == Unused Reference: 'AES' is defined on line 443, but no explicit reference was found in the text == Unused Reference: 'DES' is defined on line 447, 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: 10 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 Expiration Date: September 2003 A. Kato 5 NTT Software Corporation 6 March 2003 8 Use of the Camellia Encryption Algorithm in CMS 10 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 23 months and may be updated, replaced, or obsoleted by other documents 24 at any time. It is inappropriate to use Internet-Drafts as 25 reference 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 34 "ietf-smime" mailing list, or directly to the author. 36 Abstract 38 This document specifies how to incorporate the Camellia encryption 39 algorithm into the S/MIME Cryptographic Message Syntax (CMS) as an 40 additional algorithm for symmetric encryption. The relevant object 41 identifiers (OIDs) and processing steps are provided so that 42 Camellia may be used in the CMS specification (RFC 3369, RFC 3370) 43 for content and key encryption. 45 The key words "MUST", "MUST NOT", "REQUIRED", "SHOULD", "SHOULD 46 NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this document (in 47 uppercase, as shown) are to be interpreted as described in 48 [RFC2119]. 50 1. Introduction 52 This document specifies the conventions for using the Camellia 53 encryption algorithm [CamelliaSpec][CamelliaID] for encryption with 54 the Cryptographic Message Syntax (CMS) [CMS]. 56 CMS values are generated using ASN.1 (X.208-88), using the Basic 57 Encoding Rules (BER) (X.209-88) and the Distinguished Encoding Rules 58 (DER) (X.509-88). 60 1.1 Camellia 62 Camellia was jointly developed by Nippon Telegraph and Telephone 63 Corporation and Mitsubishi Electric Corporation in 2000. Camellia 64 specifies the 128-bit block size and 128-, 192-, and 256-bit key 65 sizes, the same interface as the Advanced Encryption Standard (AES). 66 Camellia is characterized by its suitability for both software and 67 hardware implementations as well as its high level of security. 68 From a practical viewpoint, it is designed to enable flexibility in 69 software and hardware implementations on 32-bit processors widely 70 used over the Internet and many applications, 8-bit processors used 71 in smart cards, cryptographic hardware, embedded systems, and so on 72 [CamelliaTech]. Moreover, its key setup time is excellent, and its 73 key agility is superior to that of AES. 75 Camellia has been scrutinized by the wide cryptographic community 76 during several projects for evaluating crypto algorithms. In 77 particular, Camellia was selected as a recommended cryptographic 78 primitive by the EU NESSIE (New European Schemes for Signatures, 79 Integrity and Encryption) project [NESSIE] and also included in the 80 list of cryptographic techniques for Japanese e-Government systems 81 which are selected by the Japan CRYPTREC (Cryptography Research and 82 Evaluation Committees) [CRYPTREC]. 84 2. Object Identifiers for Content and Key Encryption 86 This section provides the OIDs and processing information necessary 87 for Camellia to be used for content and key encryption in CMS. 89 Camellia is added to the set of optional symmetric encryption 90 algorithms in CMS by providing two classes of unique object 91 identifiers (OIDs). One OID class defines the content encryption 92 algorithms and the other defines the key encryption algorithms. 93 Thus a CMS agent can apply Camellia either for content or key 94 encryption by selecting the corresponding object identifier, 95 supplying the required parameter, and starting the program code. 97 2.1 OIDs for Content Encryption 99 Camellia is added to the set of symmetric content encryption 100 algorithms defined in [CMSALG]. The Camellia content-encryption 101 algorithm, in Cipher Block Chaining (CBC) mode, for the three 102 different key sizes are identified by the following object 103 identifiers: 105 id-camellia128-cbc OBJECT IDENTIFIER ::= 106 { iso(1) member-body(2) 392 200011 61 security(1) 107 algorithm(1) symmetric-encryption-algorithm(1) 108 camellia128-cbc(2) } 110 id-camellia192-cbc OBJECT IDENTIFIER ::= 111 { iso(1) member-body(2) 392 200011 61 security(1) 112 algorithm(1) symmetric-encryption-algorithm(1) 113 camellia192-cbc(3) } 115 id-camellia256-cbc OBJECT IDENTIFIER ::= 116 { iso(1) member-body(2) 392 200011 61 security(1) 117 algorithm(1) symmetric-encryption-algorithm(1) 118 camellia256-cbc(4) } 120 The AlgorithmIdentifier parameters field MUST be present, and the 121 parameters field MUST contain the value of IV: 123 CamelliaCBCParameter ::= CamelliaIV -- Initialization Vector 125 CamelliaIV ::= OCTET STRING (SIZE(16)) 127 The plain text is padded according to Section 6.3 of [CMS]. 129 2.2 OIDs for Key Encryption 131 The key-wrap/unwrap procedures used to encrypt/decrypt a Camellia 132 content-encryption key (CEK) with a Camellia key-encryption key 133 (KEK) are specified in Section 3. Generation and distribution of 134 key-encryption keys are beyond the scope of this document. 136 The Camellia key-encryption algorithm has the following object 137 identifier: 139 id-camellia128-wrap OBJECT IDENTIFIER ::= 140 { iso(1) member-body(2) 392 200011 61 security(1) 141 algorithm(1) key-wrap-algorithm(3) 142 camellia128-wrap(2) } 144 id-camellia192-wrap OBJECT IDENTIFIER ::= 145 { iso(1) member-body(2) 392 200011 61 security(1) 146 algorithm(1) key-wrap-algorithm(3) 147 camellia192-wrap(3) } 149 id-camellia256-wrap OBJECT IDENTIFIER ::= 150 { iso(1) member-body(2) 392 200011 61 security(1) 151 algorithm(1) key-wrap-algorithm(3) 152 camellia256-wrap(4) } 154 In all cases the parameters field of AlgorithmIdentifier MUST be 155 absent, because the key wrapping procedure itself defines how and 156 when to use an IV. The OID gives the KEK key size, but does not 157 make any statements as to the size of the wrapped Camellia CEK. 158 Implementations MAY use different KEK and CEK sizes. Implements 159 MUST support the CEK and the KEK having the same length. If 160 different lengths are supported, the KEK MUST be of equal or greater 161 length than the CEK. 163 3. Key Wrap Algorithm 165 Camellia key wrapping and unwrapping is done in conformance with the 166 AES key wrap algorithm [AES-WRAP][RFC3394], because Camellia and AES 167 have the same block and key sizes, i.e. the block size of 128 bits 168 and key sizes of 128, 192, and 256 bits. 170 3.1 Notation and Definitions 172 The following notation is used in the description of the key 173 wrapping algorithms: 175 Camellia(K, W) 176 Encrypt W using the Camellia codebook with key K 177 Camellia-1(K, W) 178 Decrypt W using the Camellia codebook with key K 179 MSB(j, W) Return the most significant j bits of W 180 LSB(j, W) Return the least significant j bits of W 181 B1 ^ B2 The bitwise exclusive or (XOR) of B1 and B2 182 B1 | B2 Concatenate B1 and B2 183 K The key-encryption key K 184 n The number of 64-bit key data blocks 185 s The number of steps in the wrapping process, s = 6n 186 P[i] The ith plaintext key data block 187 C[i] The ith ciphertext data block 188 A The 64-bit integrity check register 189 R[i] An array of 64-bit registers where 190 i = 0, 1, 2, ..., n 191 A[t], R[i][t] The contents of registers A and R[i] after encryption 192 step t. 193 IV The 64-bit initial value used during the wrapping 194 process. 196 In the key wrap algorithm, the concatenation function will be used 197 to concatenate 64-bit quantities to form the 128-bit input to the 198 Camellia codebook. The extraction functions will be used to split 199 the 128-bit output from the Camellia codebook into two 64-bit 200 quantities. 202 3.2 Camellia Key Wrap 204 Key wrapping with Camellia is identical to Section 2.2.1 of 205 [RFC3394] with "AES" replaced by "Camellia". 207 The inputs to the key wrapping process are the KEK and the plaintext 208 to be wrapped. The plaintext consists of n 64-bit blocks, 209 containing the key data being wrapped. The key wrapping process is 210 described below. 212 Inputs: Plaintext, n 64-bit values {P1, P2, ..., Pn}, and 213 Key, K (the KEK). 214 Outputs: Ciphertext, (n+1) 64-bit values {C0, C1, ..., Cn}. 216 1) Initialize variables. 218 Set A0 to an initial value (see Section 3.4) 219 For i = 1 to n 220 R[0][i] = P[i] 222 2) Calculate intermediate values. 224 For t = 1 to s, where s = 6n 225 A[t] = MSB(64, Camellia(K, A[t-1] | R[t-1][1])) ^ t 226 For i = 1 to n-1 227 R[t][i] = R[t-1][i+1] 228 R[t][n] = LSB(64, Camellia(K, A[t-1] | R[t-1][1])) 230 3) Output the results. 232 Set C[0] = A[t] 233 For i = 1 to n 234 C[i] = R[t][i] 236 An alternative description of the key wrap algorithm involves 237 indexing rather than shifting. This approach allows one to 238 calculate the wrapped key in place, avoiding the rotation in the 239 previous description. This produces identical results and is more 240 easily implemented in software. 242 Inputs: Plaintext, n 64-bit values {P1, P2, ..., Pn}, and 243 Key, K (the KEK). 244 Outputs: Ciphertext, (n+1) 64-bit values {C0, C1, ..., Cn}. 246 1) Initialize variables. 248 Set A = IV, an initial value (see Section 3.4) 249 For i = 1 to n 250 R[i] = P[i] 252 2) Calculate intermediate values. 254 For j = 0 to 5 255 For i=1 to n 256 B = Camellia(K, A | R[i]) 257 A = MSB(64, B) ^ t where t = (n*j)+i 258 R[i] = LSB(64, B) 260 3) Output the results. 262 Set C[0] = A 263 For i = 1 to n 264 C[i] = R[i] 266 3.3 Camellia Key Unwrap 268 Key unwrapping with Camellia is identical to Section 2.2.2 of 270 [RFC3394], with "AES" replaced by "Camellia". 272 The inputs to the unwrap process are the KEK and (n+1) 64-bit blocks 273 of ciphertext consisting of previously wrapped key. It returns n 274 blocks of plaintext consisting of the n 64-bit blocks of the 275 decrypted key data. 277 Inputs: Ciphertext, (n+1) 64-bit values {C0, C1, ..., Cn}, and 278 Key, K (the KEK). 279 Outputs: Plaintext, n 64-bit values {P1, P2, ..., Pn}. 281 1) Initialize variables. 283 Set A[s] = C[0] where s = 6n 284 For i = 1 to n 285 R[s][i] = C[i] 287 2) Calculate the intermediate values. 289 For t = s to 1 290 A[t-1] = MSB(64, Camellia-1(K, ((A[t] ^ t) | R[t][n])) 291 R[t-1][1] = LSB(64, Camellia-1(K, ((A[t]^t) | R[t][n])) 292 For i = 2 to n 293 R[t-1][i] = R[t][i-1] 295 3) Output the results. 297 If A[0] is an appropriate initial value (see Section 3.4), 298 Then 299 For i = 1 to n 300 P[i] = R[0][i] 301 Else 302 Return an error 304 The unwrap algorithm can also be specified as an index based 305 operation, allowing the calculations to be carried out in place. 306 Again, this produces the same results as the register shifting 307 approach. 309 Inputs: Ciphertext, (n+1) 64-bit values {C0, C1, ..., Cn}, and 310 Key, K (the KEK). 311 Outputs: Plaintext, n 64-bit values {P0, P1, K, Pn}. 313 1) Initialize variables. 315 Set A = C[0] 316 For i = 1 to n 317 R[i] = C[i] 319 2) Compute intermediate values. 321 For j = 5 to 0 322 For i = n to 1 323 B = Camellia-1(K, (A ^ t) | R[i]) where t = n*j+i 324 A = MSB(64, B) 325 R[i] = LSB(64, B) 327 3) Output results. 329 If A is an appropriate initial value (see Section 3.4), 330 Then 331 For i = 1 to n 332 P[i] = R[i] 333 Else 334 Return an error 336 3.4 Key Data Integrity -- the Initial Value 338 The initial value (IV) refers to the value assigned to A[0] in the 339 first step of the wrapping process. This value is used to obtain an 340 integrity check on the key data. In the final step of the 341 unwrapping process, the recovered value of A[0] is compared to the 342 expected value of A[0]. If there is a match, the key is accepted as 343 valid, and the unwrapping algorithm returns it. If there is not a 344 match, then the key is rejected, and the unwrapping algorithm 345 returns an error. 347 The exact properties achieved by this integrity check depend on the 348 definition of the initial value. Different applications may call 349 for somewhat different properties; for example, whether there is 350 need to determine the integrity of key data throughout its lifecycle 351 or just when it is unwrapped. This specification defines a default 352 initial value that supports integrity of the key data during the 353 period it is wrapped (in Section 3.4.1). Provision is also made to 354 support alternative initial values (in Section 3.4.2). 356 3.4.1 Default Initial Value 358 The default initial value (IV) is defined to be the hexadecimal 359 constant: 361 A[0] = IV = A6A6A6A6A6A6A6A6 363 The use of a constant as the IV supports a strong integrity check on 364 the key data during the period that it is wrapped. If unwrapping 365 produces A[0] = A6A6A6A6A6A6A6A6, then the chance that the key data 366 is corrupt is 2^-64. If unwrapping produces A[0] any other value, 367 then the unwrap must return an error and not return any key data. 369 3.4.2 Alternative Initial Values 371 When the key wrap is used as part of a larger key management 372 protocol or system, the desired scope for data integrity may be more 373 than just the key data or the desired duration for more than just 374 the period that it is wrapped. Also, if the key data is not just an 375 Camellia key, it may not always be a multiple of 64 bits. 376 Alternative definitions of the initial value can be used to address 377 such problems. According to [RFC3394], NIST will define alternative 378 initial values in future key management publications as needed. In 379 order to accommodate a set of alternatives that may evolve over 380 time, key wrap implementations that are not application-specific 381 will require some flexibility in the way that the initial value is 382 set and tested. 384 4. SMIMECapabilities Attribute 386 An S/MIME client SHOULD announce the set of cryptographic functions 387 it supports by using the S/MIME capabilities attribute. This 388 attribute provides a partial list of OIDs of cryptographic functions 389 and MUST be signed by the client. The functions' OIDs SHOULD be 390 logically separated in functional categories and MUST be ordered 391 with respect to their preference. 393 RFC 2633 [RFC2633], Section 2.5.2 defines the SMIMECapabilities 394 signed attribute (defined as a SEQUENCE of SMIMECapability 395 SEQUENCEs) to be used to specify a partial list of algorithms that 396 the software announcing the SMIMECapabilities can support. 398 If an S/MIME client is required to support symmetric encryption with 399 Camellia, the capabilities attribute MUST contain the Camellia OID 400 specified above in the category of symmetric algorithms. The 401 parameter associated with this OID MUST be CamelliaSMimeCapability. 403 CamelliaSMimeCapabilty ::= NULL 405 The SMIMECapability SEQUENCE representing Camellia MUST be 406 DER-encoded as the following hexadecimal strings: 408 Key Size Capability 409 128 30 0f 06 0b 2a 83 08 8c 9a 4b 3d 01 01 01 02 05 00 410 196 30 0f 06 0b 2a 83 08 8c 9a 4b 3d 01 01 01 03 05 00 411 256 30 0f 06 0b 2a 83 08 8c 9a 4b 3d 01 01 01 04 05 00 413 When a sending agent creates an encrypted message, it has to decide 414 which type of encryption algorithm to use. In general the decision 415 process involves information obtained from the capabilities lists 416 included in messages received from the recipient, as well as other 417 information such as private agreements, user preferences, legal 418 restrictions, and so on. If users require Camellia for symmetric 419 encryption, it MUST be supported by the S/MIME clients on both the 420 sending and receiving side, and it MUST be set in the user 421 preferences. 423 5. Security Considerations 425 This document specifies the use of Camellia for encrypting the 426 content of a CMS message and for encrypting the symmetric key used 427 to encrypt the content of a CMS message, and the other mechanisms 428 are the same as the existing ones. Therefore, the security 429 considerations described in the CMS specifications [CMS][CMSALG] and 430 the AES key wrap algorithm [AES-WRAP][RFC3394] can be applied to 431 this document. No security problem has been found on Camellia 432 [CRYPTREC][NESSIE]. 434 6. Intellectual Property Statement 436 Mitsubishi Electric Corporation and Nippon Telegraph and Telephone 437 Corporation have pending applications or filed patents which are 438 essential to Camellia. License policy for these essential patents 439 will be available on the IETF page of Intellectual Property Rights 440 Notices. 442 References 443 [AES] National Institute of Standards. 444 FIPS Pub 197: Advanced Encryption Standard (AES). 26 445 November 2001. 447 [DES] National Institute of Standards and Technology. 448 FIPS Pub 46: Data Encryption Standard. 15 January 1977. 450 [AES-WRAP] National Institute of Standards and Technology. AES Key 451 Wrap Specification. 17 November 2001. 452 http://csrc.nist.gov/encryption/kms/key-wrap.pdf 454 [CamelliaID] J. Nakajima and S. Moriai, "A Description of the 455 Camellia Encryption Algorithm", Internet-Draft, July 2001. 456 draft-nakajima-camellia-02.txt 458 [CamelliaSpec] K. Aoki, T. Ichikawa, M. Kanda, M. Matsui, S. Moriai, 459 J. Nakajima, and T. Tokita "Specification of Camellia - a 460 128-bit Block Cipher". http://info.isl.ntt.co.jp/camellia/ 462 [CamelliaTech] K. Aoki, T. Ichikawa, M. Kanda, M. Matsui, S. Moriai, 463 J. Nakajima, and T. Tokita "Camellia: A 128-Bit Block Cipher 464 Suitable for Multiple Platforms - Design and Analysis -", In 465 Selected Areas in Cryptography, 7th Annual International 466 Workshop, SAC 2000, August 2000, Proceedings, Lecture Notes in 467 Computer Science 2012, pp.39--56, Springer-Verlag, 2001. 469 [CMS] R. Housley, "Cryptographic Message Syntax", RFC 3369, August 470 2002. 472 [CMSALG] R. Housley, "Cryptographic Message Syntax (CMS) 473 Algorithms", RFC 3370, August 2002. 475 [CRYPTREC] Information-technology Promotion Agency (IPA), Japan, 476 CRYPTREC. http://www.ipa.go.jp/security/enc/CRYPTREC/index-e.html 478 [NESSIE] New European Schemes for Signatures, Integrity and 479 Encryption (NESSIE) project. http://www.cryptonessie.org 481 [RFC2119] S. Bradner, "Key words for use in RFCs to Indicate 482 Requirement Levels", BCP 14, RFC 2119, March 1997. 484 [RFC2633] Ramsdell, B., Editor. S/MIME Version 3 Message 485 Specification. RFC 2633. June 1999. 487 [RFC3394] J. Schaad and R. Housley, "Advanced Encryption Standard 488 (AES) Key Wrap Algorithm", RFC 3394, September 2002. 490 Authors' Address 492 Shiho Moriai 493 Nippon Telegraph and Telephone Corporation 494 Phone: +81-468-59-2007 495 FAX: +81-468-59-3858 496 Email: shiho@isl.ntt.co.jp 498 Akihiro Kato 499 NTT Software Corporation 500 Phone: +81-45-212-7404 501 FAX: +81-45-212-7410 502 Email: akato@po.ntts.co.jp 504 Appendix A ASN.1 Module 506 DEFINITIONS IMPLICIT TAGS ::= 507 BEGIN 509 -- Camellia using CBC-chaining mode for key sizes of 128, 192, 256 511 id-camellia128-cbc OBJECT IDENTIFIER ::= 512 { iso(1) member-body(2) 392 200011 61 security(1) 513 algorithm(1) symmetric-encryption-algorithm(1) 514 camellia128-cbc(2) } 516 id-camellia192-cbc OBJECT IDENTIFIER ::= 517 { iso(1) member-body(2) 392 200011 61 security(1) 518 algorithm(1) symmetric-encryption-algorithm(1) 519 camellia192-cbc(3) } 521 id-camellia256-cbc OBJECT IDENTIFIER ::= 522 { iso(1) member-body(2) 392 200011 61 security(1) 523 algorithm(1) symmetric-encryption-algorithm(1) 524 camellia256-cbc(4) } 526 -- Camellia-IV is a the parameter for all the above object identifiers. 528 Camellia-IV ::= OCTET STRING (SIZE(16)) 530 -- Camellia S/MIME Capabilty parameter for all the above object 531 -- identifiers. 533 CamelliaSMimeCapability ::= NULL 535 -- 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