idnits 2.17.1 draft-ietf-smime-camellia-01.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 7711 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 432 -- Looks like a reference, but probably isn't: '1' on line 290 == Unused Reference: 'AES' is defined on line 455, but no explicit reference was found in the text == Unused Reference: 'DES' is defined on line 459, 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. -------------------------------------------------------------------------------- 1 S/MIME Working Group S. Moriai 2 Internet Draft NTT Corporation 3 Expiration Date: September 2003 A. Kato 4 NTT Software Corporation 5 March 2003 7 Use of the Camellia Encryption Algorithm in CMS 9 11 Status of this Memo 13 This document is an Internet-Draft and is in full conformance with 14 all provisions of Section 10 of RFC2026. 16 Internet-Drafts are working documents of the Internet Engineering 17 Task Force (IETF), its areas, and its working groups. Note that 18 other groups may also distribute working documents as Internet- 19 Drafts. 21 Internet-Drafts are draft documents valid for a maximum of six 22 months and may be updated, replaced, or obsoleted by other documents 23 at any time. It is inappropriate to use Internet-Drafts as 24 reference material or to cite them other than as "work in progress." 26 The list of current Internet-Drafts can be accessed at 27 http://www.ietf.org/ietf/1id-abstracts.txt 29 The list of Internet-Draft Shadow Directories can be accessed at 30 http://www.ietf.org/shadow.html. 32 Comments or suggestions for improvement may be made on the 33 "ietf-smime" mailing list, or directly to the author. 35 Abstract 37 This document specifies how to incorporate the Camellia encryption 38 algorithm into the S/MIME Cryptographic Message Syntax (CMS) as an 39 additional algorithm for symmetric encryption. The relevant object 40 identifiers (OIDs) and processing steps are provided so that 41 Camellia may be used in the CMS specification (RFC 3369, RFC 3370) 42 for content and key encryption. 44 The key words "MUST", "MUST NOT", "REQUIRED", "SHOULD", "SHOULD 45 NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this document (in 46 uppercase, as shown) are to be interpreted as described in 47 [RFC2119]. 49 1. Introduction 51 This document specifies the conventions for using the Camellia 52 encryption algorithm [CamelliaSpec][CamelliaID] for encryption with 53 the Cryptographic Message Syntax (CMS) [CMS]. 55 CMS values are generated using ASN.1 (X.208-88), using the Basic 56 Encoding Rules (BER) (X.209-88) and the Distinguished Encoding Rules 57 (DER) (X.509-88). 59 1.1 Camellia 61 Camellia was jointly developed by Nippon Telegraph and Telephone 62 Corporation and Mitsubishi Electric Corporation in 2000. Camellia 63 specifies the 128-bit block size and 128-, 192-, and 256-bit key 64 sizes, the same interface as the Advanced Encryption Standard (AES). 65 Camellia is characterized by its suitability for both software and 66 hardware implementations as well as its high level of security. 67 From a practical viewpoint, it is designed to enable flexibility in 68 software and hardware implementations on 32-bit processors widely 69 used over the Internet and many applications, 8-bit processors used 70 in smart cards, cryptographic hardware, embedded systems, and so on 71 [CamelliaTech]. Moreover, its key setup time is excellent, and its 72 key agility is superior to that of AES. 74 Camellia has been scrutinized by the wide cryptographic community 75 during several projects for evaluating crypto algorithms. In 76 particular, Camellia was selected as a recommended cryptographic 77 primitive by the EU NESSIE (New European Schemes for Signatures, 78 Integrity and Encryption) project [NESSIE] and also included in the 79 list of cryptographic techniques for Japanese e-Government systems 80 which are selected by the Japan CRYPTREC (Cryptography Research and 81 Evaluation Committees) [CRYPTREC]. 83 2. Object Identifiers for Content and Key Encryption 85 This section provides the OIDs and processing information necessary 86 for Camellia to be used for content and key encryption in CMS. 88 Camellia is added to the set of optional symmetric encryption 89 algorithms in CMS by providing two classes of unique object 90 identifiers (OIDs). One OID class defines the content encryption 91 algorithms and the other defines the key encryption algorithms. 92 Thus a CMS agent can apply Camellia either for content or key 93 encryption by selecting the corresponding object identifier, 94 supplying the required parameter, and starting the program code. 96 2.1 OIDs for Content Encryption 98 Camellia is added to the set of symmetric content encryption 99 algorithms defined in [CMSALG]. The Camellia content-encryption 100 algorithm, in Cipher Block Chaining (CBC) mode, for the three 101 different key sizes are identified by the following object 102 identifiers: 104 id-camellia128-cbc OBJECT IDENTIFIER ::= 105 { iso(1) member-body(2) 392 200011 61 security(1) 106 algorithm(1) symmetric-encryption-algorithm(1) 107 camellia128-cbc(2) } 109 id-camellia192-cbc OBJECT IDENTIFIER ::= 110 { iso(1) member-body(2) 392 200011 61 security(1) 111 algorithm(1) symmetric-encryption-algorithm(1) 112 camellia192-cbc(3) } 114 id-camellia256-cbc OBJECT IDENTIFIER ::= 115 { iso(1) member-body(2) 392 200011 61 security(1) 116 algorithm(1) symmetric-encryption-algorithm(1) 117 camellia256-cbc(4) } 119 The AlgorithmIdentifier parameters field MUST be present, and the 120 parameters field MUST contain the value of IV: 122 CamelliaCBCParameter ::= CamelliaIV -- Initialization Vector 124 CamelliaIV ::= OCTET STRING (SIZE(16)) 126 The plain text is padded according to Section 6.3 of [CMS]. 128 2.2 OIDs for Key Encryption 130 The key-wrap/unwrap procedures used to encrypt/decrypt a Camellia 131 content-encryption key (CEK) with a Camellia key-encryption key 132 (KEK) are specified in Section 3. Generation and distribution of 133 key-encryption keys are beyond the scope of this document. 135 The Camellia key-encryption algorithm has the following object 136 identifier: 138 id-camellia128-wrap OBJECT IDENTIFIER ::= 139 { iso(1) member-body(2) 392 200011 61 security(1) 140 algorithm(1) key-wrap-algorithm(3) 141 camellia128-wrap(2) } 143 id-camellia192-wrap OBJECT IDENTIFIER ::= 144 { iso(1) member-body(2) 392 200011 61 security(1) 145 algorithm(1) key-wrap-algorithm(3) 146 camellia192-wrap(3) } 148 id-camellia256-wrap OBJECT IDENTIFIER ::= 149 { iso(1) member-body(2) 392 200011 61 security(1) 150 algorithm(1) key-wrap-algorithm(3) 151 camellia256-wrap(4) } 153 In all cases the parameters field of AlgorithmIdentifier MUST be 154 absent, because the key wrapping procedure itself defines how and 155 when to use an IV. The OID gives the KEK key size, but does not 156 make any statements as to the size of the wrapped Camellia CEK. 157 Implementations MAY use different KEK and CEK sizes. Implements 158 MUST support the CEK and the KEK having the same length. If 159 different lengths are supported, the KEK MUST be of equal or greater 160 length than the CEK. 162 3. Key Wrap Algorithm 164 Camellia key wrapping and unwrapping is done in conformance with the 165 AES key wrap algorithm [AES-WRAP][RFC3394], because Camellia and AES 166 have the same block and key sizes, i.e. the block size of 128 bits 167 and key sizes of 128, 192, and 256 bits. 169 3.1 Notation and Definitions 171 The following notation is used in the description of the key 172 wrapping algorithms: 174 Camellia(K, W) 175 Encrypt W using the Camellia codebook with key K 176 Camellia-1(K, W) 177 Decrypt W using the Camellia codebook with key K 178 MSB(j, W) Return the most significant j bits of W 179 LSB(j, W) Return the least significant j bits of W 180 B1 ^ B2 The bitwise exclusive or (XOR) of B1 and B2 181 B1 | B2 Concatenate B1 and B2 182 K The key-encryption key K 183 n The number of 64-bit key data blocks 184 s The number of steps in the wrapping process, s = 6n 185 P[i] The ith plaintext key data block 186 C[i] The ith ciphertext data block 187 A The 64-bit integrity check register 188 R[i] An array of 64-bit registers where 189 i = 0, 1, 2, ..., n 190 A[t], R[i][t] The contents of registers A and R[i] after encryption 191 step t. 192 IV The 64-bit initial value used during the wrapping 193 process. 195 In the key wrap algorithm, the concatenation function will be used 196 to concatenate 64-bit quantities to form the 128-bit input to the 197 Camellia codebook. The extraction functions will be used to split 198 the 128-bit output from the Camellia codebook into two 64-bit 199 quantities. 201 3.2 Camellia Key Wrap 203 Key wrapping with Camellia is identical to Section 2.2.1 of 204 [RFC3394] with "AES" replaced by "Camellia". 206 The inputs to the key wrapping process are the KEK and the plaintext 207 to be wrapped. The plaintext consists of n 64-bit blocks, 208 containing the key data being wrapped. The key wrapping process is 209 described below. 211 Inputs: Plaintext, n 64-bit values {P1, P2, ..., Pn}, and 212 Key, K (the KEK). 213 Outputs: Ciphertext, (n+1) 64-bit values {C0, C1, ..., Cn}. 215 1) Initialize variables. 217 Set A0 to an initial value (see Section 3.4) 218 For i = 1 to n 219 R[0][i] = P[i] 221 2) Calculate intermediate values. 223 For t = 1 to s, where s = 6n 224 A[t] = MSB(64, Camellia(K, A[t-1] | R[t-1][1])) ^ t 225 For i = 1 to n-1 226 R[t][i] = R[t-1][i+1] 227 R[t][n] = LSB(64, Camellia(K, A[t-1] | R[t-1][1])) 229 3) Output the results. 231 Set C[0] = A[t] 232 For i = 1 to n 233 C[i] = R[t][i] 235 An alternative description of the key wrap algorithm involves 236 indexing rather than shifting. This approach allows one to 237 calculate the wrapped key in place, avoiding the rotation in the 238 previous description. This produces identical results and is more 239 easily implemented in software. 241 Inputs: Plaintext, n 64-bit values {P1, P2, ..., Pn}, and 242 Key, K (the KEK). 243 Outputs: Ciphertext, (n+1) 64-bit values {C0, C1, ..., Cn}. 245 1) Initialize variables. 247 Set A = IV, an initial value (see Section 3.4) 248 For i = 1 to n 249 R[i] = P[i] 251 2) Calculate intermediate values. 253 For j = 0 to 5 254 For i=1 to n 255 B = Camellia(K, A | R[i]) 256 A = MSB(64, B) ^ t where t = (n*j)+i 257 R[i] = LSB(64, B) 259 3) Output the results. 261 Set C[0] = A 262 For i = 1 to n 263 C[i] = R[i] 265 3.3 Camellia Key Unwrap 267 Key unwrapping with Camellia is identical to Section 2.2.2 of 269 [RFC3394], with "AES" replaced by "Camellia". 271 The inputs to the unwrap process are the KEK and (n+1) 64-bit blocks 272 of ciphertext consisting of previously wrapped key. It returns n 273 blocks of plaintext consisting of the n 64-bit blocks of the 274 decrypted key data. 276 Inputs: Ciphertext, (n+1) 64-bit values {C0, C1, ..., Cn}, and 277 Key, K (the KEK). 278 Outputs: Plaintext, n 64-bit values {P1, P2, ..., Pn}. 280 1) Initialize variables. 282 Set A[s] = C[0] where s = 6n 283 For i = 1 to n 284 R[s][i] = C[i] 286 2) Calculate the intermediate values. 288 For t = s to 1 289 A[t-1] = MSB(64, Camellia-1(K, ((A[t] ^ t) | R[t][n])) 290 R[t-1][1] = LSB(64, Camellia-1(K, ((A[t]^t) | R[t][n])) 291 For i = 2 to n 292 R[t-1][i] = R[t][i-1] 294 3) Output the results. 296 If A[0] is an appropriate initial value (see Section 3.4), 297 Then 298 For i = 1 to n 299 P[i] = R[0][i] 300 Else 301 Return an error 303 The unwrap algorithm can also be specified as an index based 304 operation, allowing the calculations to be carried out in place. 305 Again, this produces the same results as the register shifting 306 approach. 308 Inputs: Ciphertext, (n+1) 64-bit values {C0, C1, ..., Cn}, and 309 Key, K (the KEK). 310 Outputs: Plaintext, n 64-bit values {P0, P1, K, Pn}. 312 1) Initialize variables. 314 Set A = C[0] 315 For i = 1 to n 316 R[i] = C[i] 318 2) Compute intermediate values. 320 For j = 5 to 0 321 For i = n to 1 322 B = Camellia-1(K, (A ^ t) | R[i]) where t = n*j+i 323 A = MSB(64, B) 324 R[i] = LSB(64, B) 326 3) Output results. 328 If A is an appropriate initial value (see Section 3.4), 329 Then 330 For i = 1 to n 331 P[i] = R[i] 332 Else 333 Return an error 335 3.4 Key Data Integrity -- the Initial Value 337 The initial value (IV) refers to the value assigned to A[0] in the 338 first step of the wrapping process. This value is used to obtain an 339 integrity check on the key data. In the final step of the 340 unwrapping process, the recovered value of A[0] is compared to the 341 expected value of A[0]. If there is a match, the key is accepted as 342 valid, and the unwrapping algorithm returns it. If there is not a 343 match, then the key is rejected, and the unwrapping algorithm 344 returns an error. 346 The exact properties achieved by this integrity check depend on the 347 definition of the initial value. Different applications may call 348 for somewhat different properties; for example, whether there is 349 need to determine the integrity of key data throughout its lifecycle 350 or just when it is unwrapped. This specification defines a default 351 initial value that supports integrity of the key data during the 352 period it is wrapped (in Section 3.4.1). Provision is also made to 353 support alternative initial values (in Section 3.4.2). 355 3.4.1 Default Initial Value 357 The default initial value (IV) is defined to be the hexadecimal 358 constant: 360 A[0] = IV = A6A6A6A6A6A6A6A6 362 The use of a constant as the IV supports a strong integrity check on 363 the key data during the period that it is wrapped. If unwrapping 364 produces A[0] = A6A6A6A6A6A6A6A6, then the chance that the key data 365 is corrupt is 2^-64. If unwrapping produces A[0] any other value, 366 then the unwrap must return an error and not return any key data. 368 3.4.2 Alternative Initial Values 370 When the key wrap is used as part of a larger key management 371 protocol or system, the desired scope for data integrity may be more 372 than just the key data or the desired duration for more than just 373 the period that it is wrapped. Also, if the key data is not just an 374 Camellia key, it may not always be a multiple of 64 bits. 375 Alternative definitions of the initial value can be used to address 376 such problems. According to [RFC3394], NIST will define alternative 377 initial values in future key management publications as needed. In 378 order to accommodate a set of alternatives that may evolve over 379 time, key wrap implementations that are not application-specific 380 will require some flexibility in the way that the initial value is 381 set and tested. 383 4. SMIMECapabilities Attribute 385 An S/MIME client SHOULD announce the set of cryptographic functions 386 it supports by using the S/MIME capabilities attribute. This 387 attribute provides a partial list of OIDs of cryptographic functions 388 and MUST be signed by the client. The functions' OIDs SHOULD be 389 logically separated in functional categories and MUST be ordered 390 with respect to their preference. 392 RFC 2633 [RFC2633], Section 2.5.2 defines the SMIMECapabilities 393 signed attribute (defined as a SEQUENCE of SMIMECapability 394 SEQUENCEs) to be used to specify a partial list of algorithms that 395 the software announcing the SMIMECapabilities can support. 397 If an S/MIME client is required to support symmetric encryption with 398 Camellia, the capabilities attribute MUST contain the Camellia OID 399 specified above in the category of symmetric algorithms. The 400 parameter associated with this OID MUST be CamelliaSMimeCapability. 402 CamelliaSMimeCapabilty ::= NULL 404 The SMIMECapability SEQUENCE representing Camellia MUST be 405 DER-encoded as the following hexadecimal strings: 407 Key Size Capability 408 128 30 0d 06 0b 2a 83 08 8c 9a 4b 3d 01 01 01 02 409 196 30 0d 06 0b 2a 83 08 8c 9a 4b 3d 01 01 01 03 410 256 30 0d 06 0b 2a 83 08 8c 9a 4b 3d 01 01 01 04 412 When a sending agent creates an encrypted message, it has to decide 413 which type of encryption algorithm to use. In general the decision 414 process involves information obtained from the capabilities lists 415 included in messages received from the recipient, as well as other 416 information such as private agreements, user preferences, legal 417 restrictions, and so on. If users require Camellia for symmetric 418 encryption, it MUST be supported by the S/MIME clients on both the 419 sending and receiving side, and it MUST be set in the user 420 preferences. 422 5. Security Considerations 424 This document specifies the use of Camellia for encrypting the 425 content of a CMS message and for encrypting the symmetric key used 426 to encrypt the content of a CMS message, and the other mechanisms 427 are the same as the existing ones. Therefore, the security 428 considerations described in the CMS specifications [CMS][CMSALG] and 429 the AES key wrap algorithm [AES-WRAP][RFC3394] can be applied to 430 this document. As described in Section 3.4, the key wrap algorithm 431 includes a strong integrity check on the key data. If unwrapping 432 produces the expected check value in A[0], then the chance that the 433 key data is corrupt is 2^-64. If unwrapping produces an unexpected 434 value, then the algorithm implementation MUST return an error, and 435 it MUST NOT return any key data [AES-WRAP][RFC3394]. In this case, 436 the error message should not include detailed information about the 437 error, since attackers can exploit information in the error message 438 to recover the key data. 440 Implementations must protect the KEK from disclosure. Compromise of 441 the KEK may result in the disclosure of all key data protected with 442 that KEK [RFC3394]. 444 No security problem has been found on Camellia [CRYPTREC][NESSIE]. 446 6. Intellectual Property Statement 448 Mitsubishi Electric Corporation and Nippon Telegraph and Telephone 449 Corporation have pending applications or filed patents which are 450 essential to Camellia. License policy for these essential patents 451 will be available on the IETF page of Intellectual Property Rights 452 Notices. 454 References 455 [AES] National Institute of Standards. 456 FIPS Pub 197: Advanced Encryption Standard (AES). 26 457 November 2001. 459 [DES] National Institute of Standards and Technology. 460 FIPS Pub 46: Data Encryption Standard. 15 January 1977. 462 [AES-WRAP] National Institute of Standards and Technology. AES Key 463 Wrap Specification. 17 November 2001. 464 http://csrc.nist.gov/encryption/kms/key-wrap.pdf 466 [CamelliaID] J. Nakajima and S. Moriai, "A Description of the 467 Camellia Encryption Algorithm", Internet-Draft, July 2001. 468 draft-nakajima-camellia-02.txt 470 [CamelliaSpec] K. Aoki, T. Ichikawa, M. Kanda, M. Matsui, S. Moriai, 471 J. Nakajima, and T. Tokita "Specification of Camellia - a 472 128-bit Block Cipher". http://info.isl.ntt.co.jp/camellia/ 474 [CamelliaTech] K. Aoki, T. Ichikawa, M. Kanda, M. Matsui, S. Moriai, 475 J. Nakajima, and T. Tokita "Camellia: A 128-Bit Block Cipher 476 Suitable for Multiple Platforms - Design and Analysis -", In 477 Selected Areas in Cryptography, 7th Annual International 478 Workshop, SAC 2000, August 2000, Proceedings, Lecture Notes in 479 Computer Science 2012, pp.39--56, Springer-Verlag, 2001. 481 [CMS] R. Housley, "Cryptographic Message Syntax", RFC 3369, August 482 2002. 484 [CMSALG] R. Housley, "Cryptographic Message Syntax (CMS) 485 Algorithms", RFC 3370, August 2002. 487 [CRYPTREC] Information-technology Promotion Agency (IPA), Japan, 488 CRYPTREC. http://www.ipa.go.jp/security/enc/CRYPTREC/index-e.html 490 [NESSIE] New European Schemes for Signatures, Integrity and 491 Encryption (NESSIE) project. http://www.cryptonessie.org 493 [RFC2119] S. Bradner, "Key words for use in RFCs to Indicate 494 Requirement Levels", BCP 14, RFC 2119, March 1997. 496 [RFC2633] Ramsdell, B., Editor. S/MIME Version 3 Message 497 Specification. RFC 2633. June 1999. 499 [RFC3394] J. Schaad and R. Housley, "Advanced Encryption Standard 500 (AES) Key Wrap Algorithm", RFC 3394, September 2002. 502 Authors' Address 504 Shiho Moriai 505 Nippon Telegraph and Telephone Corporation 506 Phone: +81-468-59-2007 507 FAX: +81-468-59-3858 508 Email: shiho@isl.ntt.co.jp 510 Akihiro Kato 511 NTT Software Corporation 512 Phone: +81-45-212-7404 513 FAX: +81-45-212-7410 514 Email: akato@po.ntts.co.jp 516 Appendix A ASN.1 Module 518 DEFINITIONS IMPLICIT TAGS ::= 519 BEGIN 521 -- Camellia using CBC-chaining mode for key sizes of 128, 192, 256 523 id-camellia128-cbc OBJECT IDENTIFIER ::= 524 { iso(1) member-body(2) 392 200011 61 security(1) 525 algorithm(1) symmetric-encryption-algorithm(1) 526 camellia128-cbc(2) } 528 id-camellia192-cbc OBJECT IDENTIFIER ::= 529 { iso(1) member-body(2) 392 200011 61 security(1) 530 algorithm(1) symmetric-encryption-algorithm(1) 531 camellia192-cbc(3) } 533 id-camellia256-cbc OBJECT IDENTIFIER ::= 534 { iso(1) member-body(2) 392 200011 61 security(1) 535 algorithm(1) symmetric-encryption-algorithm(1) 536 camellia256-cbc(4) } 538 -- Camellia-IV is a the parameter for all the above object identifiers. 540 Camellia-IV ::= OCTET STRING (SIZE(16)) 542 -- Camellia S/MIME Capabilty parameter for all the above object 543 -- identifiers. 545 CamelliaSMimeCapability ::= NULL 547 -- Camellia Key Wrap Algorithm identifiers - Parameter is absent 549 id-camellia128-wrap OBJECT IDENTIFIER ::= 550 { iso(1) member-body(2) 392 200011 61 security(1) 551 algorithm(1) key-wrap-algorithm(3) 552 camellia128-wrap(2) } 554 id-camellia192-wrap OBJECT IDENTIFIER ::= 555 { iso(1) member-body(2) 392 200011 61 security(1) 556 algorithm(1) key-wrap-algorithm(3) 557 camellia192-wrap(3) } 559 id-camellia256-wrap OBJECT IDENTIFIER ::= 560 { iso(1) member-body(2) 392 200011 61 security(1) 561 algorithm(1) key-wrap-algorithm(3) 562 camellia256-wrap(4) } 564 END