idnits 2.17.1 draft-ietf-smime-camellia-04.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 (June 2003) is 7621 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 363 -- Looks like a reference, but probably isn't: '1' on line 288 == Unused Reference: 'AES' is defined on line 441, but no explicit reference was found in the text == Unused Reference: 'DES' is defined on line 445, 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 Sony Computer Entertainment Inc. 4 Document: draft-ietf-smime-camellia-04.txt A. Kato 5 Expires: December 2003 NTT Software Corporation 6 June 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 Note: 49 This work was done when the first author worked for NTT. 51 1.1 Camellia 53 Camellia was jointly developed by Nippon Telegraph and Telephone 54 Corporation and Mitsubishi Electric Corporation in 2000. Camellia 55 specifies the 128-bit block size and 128-, 192-, and 256-bit key 56 sizes, the same interface as the Advanced Encryption Standard (AES). 57 Camellia is characterized by its suitability for both software and 58 hardware implementations as well as its high level of security. 59 From a practical viewpoint, it is designed to enable flexibility in 60 software and hardware implementations on 32-bit processors widely 61 used over the Internet and many applications, 8-bit processors used 62 in smart cards, cryptographic hardware, embedded systems, and so on 63 [CamelliaTech]. Moreover, its key setup time is excellent, and its 64 key agility is superior to that of AES. 66 Camellia has been scrutinized by the wide cryptographic community 67 during several projects for evaluating crypto algorithms. In 68 particular, Camellia was selected as a recommended cryptographic 69 primitive by the EU NESSIE (New European Schemes for Signatures, 70 Integrity and Encryption) project [NESSIE] and also included in 71 the list of cryptographic techniques for Japanese e-Government 72 systems which were selected by the Japan CRYPTREC (Cryptography 73 Research and Evaluation Committees) [CRYPTREC]. 75 1.2 Terminology 77 The key words "MUST", "MUST NOT", "REQUIRED", "SHOULD", "SHOULD 78 NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this document (in 79 uppercase, as shown) are to be interpreted as described in 80 [RFC2119]. 82 2. Object Identifiers for Content and Key Encryption 84 This section provides the OIDs and processing information necessary 85 for Camellia to be used for content and key encryption in CMS. 87 Camellia is added to the set of optional symmetric encryption 88 algorithms in CMS by providing two classes of unique object 89 identifiers (OIDs). One OID class defines the content encryption 90 algorithms and the other defines the key encryption algorithms. 91 Thus a CMS agent can apply Camellia either for content or key 92 encryption by selecting the corresponding object identifier, 93 supplying the required parameter, and starting the program code. 95 2.1 OIDs for Content Encryption 97 Camellia is added to the set of symmetric content encryption 98 algorithms defined in [CMSALG]. The Camellia content-encryption 99 algorithm, in Cipher Block Chaining (CBC) mode, for the three 100 different key sizes are identified by the following object 101 identifiers: 103 id-camellia128-cbc OBJECT IDENTIFIER ::= 104 { iso(1) member-body(2) 392 200011 61 security(1) 105 algorithm(1) symmetric-encryption-algorithm(1) 106 camellia128-cbc(2) } 108 id-camellia192-cbc OBJECT IDENTIFIER ::= 109 { iso(1) member-body(2) 392 200011 61 security(1) 110 algorithm(1) symmetric-encryption-algorithm(1) 111 camellia192-cbc(3) } 113 id-camellia256-cbc OBJECT IDENTIFIER ::= 114 { iso(1) member-body(2) 392 200011 61 security(1) 115 algorithm(1) symmetric-encryption-algorithm(1) 116 camellia256-cbc(4) } 118 The AlgorithmIdentifier parameters field MUST be present, and the 119 parameters field MUST contain the value of IV: 121 CamelliaCBCParameter ::= CamelliaIV -- Initialization Vector 123 CamelliaIV ::= OCTET STRING (SIZE(16)) 125 The plain text is padded according to Section 6.3 of [CMS]. 127 2.2 OIDs for Key Encryption 129 The key-wrap/unwrap procedures used to encrypt/decrypt a Camellia 130 content-encryption key (CEK) with a Camellia key-encryption key 131 (KEK) are specified in Section 3. Generation and distribution of 132 key-encryption keys are beyond the scope of this document. 134 The Camellia key-encryption algorithm has the following object 135 identifier: 137 id-camellia128-wrap OBJECT IDENTIFIER ::= 138 { iso(1) member-body(2) 392 200011 61 security(1) 139 algorithm(1) key-wrap-algorithm(3) 140 camellia128-wrap(2) } 142 id-camellia192-wrap OBJECT IDENTIFIER ::= 143 { iso(1) member-body(2) 392 200011 61 security(1) 144 algorithm(1) key-wrap-algorithm(3) 145 camellia192-wrap(3) } 147 id-camellia256-wrap OBJECT IDENTIFIER ::= 148 { iso(1) member-body(2) 392 200011 61 security(1) 149 algorithm(1) key-wrap-algorithm(3) 150 camellia256-wrap(4) } 152 In all cases the parameters field of AlgorithmIdentifier MUST be 153 ABSENT, because the key wrapping procedure itself defines how and 154 when to use an IV. The OID gives the KEK key size, but does not 155 make any statements as to the size of the wrapped Camellia CEK. 156 Implementations MAY use different KEK and CEK sizes. 157 Implementations MUST support the CEK and the KEK having the 158 same length. If different lengths are supported, the KEK MUST be 159 of equal or greater length than the CEK. 161 3. Key Wrap Algorithm 162 Camellia key wrapping and unwrapping is done in conformance with the 163 AES key wrap algorithm [AES-WRAP][RFC3394], because Camellia and AES 164 have the same block and key sizes, i.e. the block size of 128 bits 165 and key sizes of 128, 192, and 256 bits. 167 3.1 Notation and Definitions 169 The following notation is used in the description of the key 170 wrapping algorithms: 172 Camellia(K, W) 173 Encrypt W using the Camellia codebook with key K 174 Camellia-1(K, W) 175 Decrypt W using the Camellia codebook with key K 176 MSB(j, W) Return the most significant j bits of W 177 LSB(j, W) Return the least significant j bits of W 178 B1 ^ B2 The bitwise exclusive or (XOR) of B1 and B2 179 B1 | B2 Concatenate B1 and B2 180 K The key-encryption key K 181 n The number of 64-bit key data blocks 182 s The number of steps in the wrapping process, s = 6n 183 P[i] The ith plaintext key data block 184 C[i] The ith ciphertext data block 185 A The 64-bit integrity check register 186 R[i] An array of 64-bit registers where 187 i = 0, 1, 2, ..., n 188 A[t], R[i][t] The contents of registers A and R[i] after encryption 189 step t. 190 IV The 64-bit initial value used during the wrapping 191 process. 193 In the key wrap algorithm, the concatenation function will be used 194 to concatenate 64-bit quantities to form the 128-bit input to the 195 Camellia codebook. The extraction functions will be used to split 196 the 128-bit output from the Camellia codebook into two 64-bit 197 quantities. 199 3.2 Camellia Key Wrap 201 Key wrapping with Camellia is identical to Section 2.2.1 of 202 [RFC3394] with "AES" replaced by "Camellia". 204 The inputs to the key wrapping process are the KEK and the plaintext 205 to be wrapped. The plaintext consists of n 64-bit blocks, 206 containing the key data being wrapped. The key wrapping process is 207 described below. 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 A0 to an initial value (see Section 3.4) 216 For i = 1 to n 217 R[0][i] = P[i] 219 2) Calculate intermediate values. 221 For t = 1 to s, where s = 6n 222 A[t] = MSB(64, Camellia(K, A[t-1] | R[t-1][1])) ^ t 223 For i = 1 to n-1 224 R[t][i] = R[t-1][i+1] 225 R[t][n] = LSB(64, Camellia(K, A[t-1] | R[t-1][1])) 227 3) Output the results. 229 Set C[0] = A[t] 230 For i = 1 to n 231 C[i] = R[t][i] 233 An alternative description of the key wrap algorithm involves 234 indexing rather than shifting. This approach allows one to 235 calculate the wrapped key in place, avoiding the rotation in the 236 previous description. This produces identical results and is more 237 easily implemented in software. 239 Inputs: Plaintext, n 64-bit values {P1, P2, ..., Pn}, and 240 Key, K (the KEK). 241 Outputs: Ciphertext, (n+1) 64-bit values {C0, C1, ..., Cn}. 243 1) Initialize variables. 245 Set A = IV, an initial value (see Section 3.4) 246 For i = 1 to n 247 R[i] = P[i] 249 2) Calculate intermediate values. 251 For j = 0 to 5 252 For i=1 to n 253 B = Camellia(K, A | R[i]) 254 A = MSB(64, B) ^ t where t = (n*j)+i 255 R[i] = LSB(64, B) 257 3) Output the results. 259 Set C[0] = A 260 For i = 1 to n 261 C[i] = R[i] 263 3.3 Camellia Key Unwrap 265 Key unwrapping with Camellia is identical to Section 2.2.2 of 267 [RFC3394], with "AES" replaced by "Camellia". 269 The inputs to the unwrap process are the KEK and (n+1) 64-bit blocks 270 of ciphertext consisting of previously wrapped key. It returns n 271 blocks of plaintext consisting of the n 64-bit blocks of the 272 decrypted key data. 274 Inputs: Ciphertext, (n+1) 64-bit values {C0, C1, ..., Cn}, and 275 Key, K (the KEK). 276 Outputs: Plaintext, n 64-bit values {P1, P2, ..., Pn}. 278 1) Initialize variables. 280 Set A[s] = C[0] where s = 6n 281 For i = 1 to n 282 R[s][i] = C[i] 284 2) Calculate the intermediate values. 286 For t = s to 1 287 A[t-1] = MSB(64, Camellia-1(K, ((A[t] ^ t) | R[t][n])) 288 R[t-1][1] = LSB(64, Camellia-1(K, ((A[t]^t) | R[t][n])) 289 For i = 2 to n 290 R[t-1][i] = R[t][i-1] 292 3) Output the results. 294 If A[0] is an appropriate initial value (see Section 3.4), 295 Then 296 For i = 1 to n 297 P[i] = R[0][i] 298 Else 299 Return an error 301 The unwrap algorithm can also be specified as an index based 302 operation, allowing the calculations to be carried out in place. 303 Again, this produces the same results as the register shifting 304 approach. 306 Inputs: Ciphertext, (n+1) 64-bit values {C0, C1, ..., Cn}, and 307 Key, K (the KEK). 308 Outputs: Plaintext, n 64-bit values {P0, P1, K, Pn}. 310 1) Initialize variables. 312 Set A = C[0] 313 For i = 1 to n 314 R[i] = C[i] 316 2) Compute intermediate values. 318 For j = 5 to 0 319 For i = n to 1 320 B = Camellia-1(K, (A ^ t) | R[i]) where t = n*j+i 321 A = MSB(64, B) 322 R[i] = LSB(64, B) 324 3) Output results. 326 If A is an appropriate initial value (see Section 3.4), 327 Then 328 For i = 1 to n 329 P[i] = R[i] 330 Else 331 Return an error 333 3.4 Key Data Integrity -- the Initial Value 335 The initial value (IV) refers to the value assigned to A[0] in the 336 first step of the wrapping process. This value is used to obtain an 337 integrity check on the key data. In the final step of the 338 unwrapping process, the recovered value of A[0] is compared to the 339 expected value of A[0]. If there is a match, the key is accepted as 340 valid, and the unwrapping algorithm returns it. If there is not a 341 match, then the key is rejected, and the unwrapping algorithm 342 returns an error. 344 The exact properties achieved by this integrity check depend on the 345 definition of the initial value. Different applications may call 346 for somewhat different properties; for example, whether there is 347 need to determine the integrity of key data throughout its lifecycle 348 or just when it is unwrapped. This specification defines a default 349 initial value that supports integrity of the key data during the 350 period it is wrapped (in Section 3.4.1). Provision is also made to 351 support alternative initial values (in Section 3.4.2). 353 3.4.1 Default Initial Value 355 The default initial value (IV) is defined to be the hexadecimal 356 constant: 358 A[0] = IV = A6A6A6A6A6A6A6A6 360 The use of a constant as the IV supports a strong integrity check on 361 the key data during the period that it is wrapped. If unwrapping 362 produces A[0] = A6A6A6A6A6A6A6A6, then the chance that the key data 363 is corrupt is 2^-64. If unwrapping produces A[0] any other value, 364 then the unwrap must return an error and not return any key data. 366 3.4.2 Alternative Initial Values 368 When the key wrap is used as part of a larger key management 369 protocol or system, the desired scope for data integrity may be more 370 than just the key data or the desired duration for more than just 371 the period that it is wrapped. Also, if the key data is not just an 372 Camellia key, it may not always be a multiple of 64 bits. 373 Alternative definitions of the initial value can be used to address 374 such problems. According to [RFC3394], NIST will define alternative 375 initial values in future key management publications as needed. In 376 order to accommodate a set of alternatives that may evolve over 377 time, key wrap implementations that are not application-specific 378 will require some flexibility in the way that the initial value is 379 set and tested. 381 4. SMIMECapabilities Attribute 383 An S/MIME client SHOULD announce the set of cryptographic functions 384 it supports by using the S/MIME capabilities attribute. This 385 attribute provides a partial list of OIDs of cryptographic functions 386 and MUST be signed by the client. The functions' OIDs SHOULD be 387 logically separated in functional categories and MUST be ordered 388 with respect to their preference. 390 RFC 2633 [RFC2633], Section 2.5.2 defines the SMIMECapabilities 391 signed attribute (defined as a SEQUENCE of SMIMECapability 392 SEQUENCEs) to be used to specify a partial list of algorithms that 393 the software announcing the SMIMECapabilities can support. 395 If an S/MIME client is required to support symmetric encryption with 396 Camellia, the capabilities attribute MUST contain the Camellia OID 397 specified above in the category of symmetric algorithms. The 398 parameter associated with this OID MUST be CamelliaSMimeCapability. 400 CamelliaSMimeCapabilty ::= NULL 402 The SMIMECapability SEQUENCE representing Camellia MUST be 403 DER-encoded as the following hexadecimal strings: 405 Key Size Capability 406 128 30 0f 06 0b 2a 83 08 8c 9a 4b 3d 01 01 01 02 05 00 407 196 30 0f 06 0b 2a 83 08 8c 9a 4b 3d 01 01 01 03 05 00 408 256 30 0f 06 0b 2a 83 08 8c 9a 4b 3d 01 01 01 04 05 00 410 When a sending agent creates an encrypted message, it has to decide 411 which type of encryption algorithm to use. In general the decision 412 process involves information obtained from the capabilities lists 413 included in messages received from the recipient, as well as other 414 information such as private agreements, user preferences, legal 415 restrictions, and so on. If users require Camellia for symmetric 416 encryption, it MUST be supported by the S/MIME clients on both the 417 sending and receiving side, and it MUST be set in the user 418 preferences. 420 5. Security Considerations 422 This document specifies the use of Camellia for encrypting the 423 content of a CMS message and for encrypting the symmetric key used 424 to encrypt the content of a CMS message, and the other mechanisms 425 are the same as the existing ones. Therefore, the security 426 considerations described in the CMS specifications [CMS][CMSALG] and 427 the AES key wrap algorithm [AES-WRAP][RFC3394] can be applied to 428 this document. No security problem has been found on Camellia 430 [CRYPTREC][NESSIE]. 432 6. Intellectual Property Statement 434 Mitsubishi Electric Corporation and Nippon Telegraph and Telephone 435 Corporation have pending applications or filed patents which are 436 essential to Camellia. License policy for these essential patents 437 will be available on the IETF page of Intellectual Property Rights 438 Notices. 440 References 441 [AES] National Institute of Standards. 442 FIPS Pub 197: Advanced Encryption Standard (AES). 26 443 November 2001. 445 [DES] National Institute of Standards and Technology. 446 FIPS Pub 46: Data Encryption Standard. 15 January 1977. 448 [AES-WRAP] National Institute of Standards and Technology. AES Key 449 Wrap Specification. 17 November 2001. 450 http://csrc.nist.gov/encryption/kms/key-wrap.pdf 452 [CamelliaID] J. Nakajima and S. Moriai, "A Description of the 453 Camellia Encryption Algorithm", Internet-Draft, July 2001. 454 draft-nakajima-camellia-02.txt 456 [CamelliaSpec] K. Aoki, T. Ichikawa, M. Kanda, M. Matsui, S. Moriai, 457 J. Nakajima, and T. Tokita "Specification of Camellia - a 458 128-bit Block Cipher". http://info.isl.ntt.co.jp/camellia/ 460 [CamelliaTech] K. Aoki, T. Ichikawa, M. Kanda, M. Matsui, S. Moriai, 461 J. Nakajima, and T. Tokita "Camellia: A 128-Bit Block Cipher 462 Suitable for Multiple Platforms - Design and Analysis -", In 463 Selected Areas in Cryptography, 7th Annual International 464 Workshop, SAC 2000, August 2000, Proceedings, Lecture Notes in 465 Computer Science 2012, pp.39--56, Springer-Verlag, 2001. 467 [CMS] R. Housley, "Cryptographic Message Syntax", RFC 3369, August 468 2002. 470 [CMSALG] R. Housley, "Cryptographic Message Syntax (CMS) 471 Algorithms", RFC 3370, August 2002. 473 [CRYPTREC] Information-technology Promotion Agency (IPA), Japan, 474 CRYPTREC. http://www.ipa.go.jp/security/enc/CRYPTREC/index-e.html 476 [NESSIE] New European Schemes for Signatures, Integrity and 477 Encryption (NESSIE) project. http://www.cryptonessie.org 479 [RFC2119] S. Bradner, "Key words for use in RFCs to Indicate 480 Requirement Levels", BCP 14, RFC 2119, March 1997. 482 [RFC2633] Ramsdell, B., Editor. S/MIME Version 3 Message 483 Specification. RFC 2633. June 1999. 485 [RFC3394] J. Schaad and R. Housley, "Advanced Encryption Standard 486 (AES) Key Wrap Algorithm", RFC 3394, September 2002. 488 Authors' Address 490 Shiho Moriai 491 Sony Computer Entertainment Inc. 492 Phone: +81-3-6438-7523 493 FAX: +81-3-6438-8629 494 Email: camellia@isl.ntt.co.jp (Camellia team) 495 shiho@rc.scei.sony.co.jp (Shiho Moriai) 497 Akihiro Kato 498 NTT Software Corporation 499 Phone: +81-45-212-7404 500 FAX: +81-45-212-7410 501 Email: akato@po.ntts.co.jp 503 Appendix A ASN.1 Module 505 CamelliaEncryptionAlgorithmInCMS 506 { iso(1) member-body(2) us(840) rsadsi(113549) pkcs(1) 507 pkcs9(9) smime(16) modules(0) id-mod-cms-camellia(23) } 509 DEFINITIONS IMPLICIT TAGS ::= 510 BEGIN 512 -- Camellia using CBC-chaining mode for key sizes of 128, 192, 256 514 id-camellia128-cbc OBJECT IDENTIFIER ::= 515 { iso(1) member-body(2) 392 200011 61 security(1) 516 algorithm(1) symmetric-encryption-algorithm(1) 517 camellia128-cbc(2) } 519 id-camellia192-cbc OBJECT IDENTIFIER ::= 520 { iso(1) member-body(2) 392 200011 61 security(1) 521 algorithm(1) symmetric-encryption-algorithm(1) 522 camellia192-cbc(3) } 524 id-camellia256-cbc OBJECT IDENTIFIER ::= 525 { iso(1) member-body(2) 392 200011 61 security(1) 526 algorithm(1) symmetric-encryption-algorithm(1) 527 camellia256-cbc(4) } 529 -- Camellia-IV is a the parameter for all the above object identifiers. 531 Camellia-IV ::= OCTET STRING (SIZE(16)) 533 -- Camellia S/MIME Capabilty parameter for all the above object 534 -- identifiers. 536 CamelliaSMimeCapability ::= NULL 538 -- Camellia Key Wrap Algorithm identifiers - Parameter is absent. 540 id-camellia128-wrap OBJECT IDENTIFIER ::= 541 { iso(1) member-body(2) 392 200011 61 security(1) 542 algorithm(1) key-wrap-algorithm(3) 543 camellia128-wrap(2) } 545 id-camellia192-wrap OBJECT IDENTIFIER ::= 546 { iso(1) member-body(2) 392 200011 61 security(1) 547 algorithm(1) key-wrap-algorithm(3) 548 camellia192-wrap(3) } 550 id-camellia256-wrap OBJECT IDENTIFIER ::= 551 { iso(1) member-body(2) 392 200011 61 security(1) 552 algorithm(1) key-wrap-algorithm(3) 553 camellia256-wrap(4) } 555 END